I have a goal where the seconds actually matter a lot. I need to know if today I actually have 1 minute to do or just 5 seconds.
Whether I need to do 5 seconds or 59, the interface still shows 00:01 to go for the day.
What ends happening in my specific use case (which I can’t elaborate further on in this thread) is that sometimes I run short of a few seconds and I just add in a “fake” “padding” datapoint for those few seconds, because it would be impractical to actually do the task again and log those in, but it’d be much, much better if I just knew how many seconds I had to do in the first place before starting the task.
You know, if you wanted, you could just put it as a goal option tomorrow. That’s a quick and easy UVI, so you can check that off for the day and watch a movie instead
Ah, display precision was already set to 0.001. If I try to set 0.0000001, I get an error saying min precision should be set to 1e-5 (maybe too nerdy of an error message, format the number differently? dang, that’s an easier UVI though…). So I tried setting 0.00001, but that made no difference. I still can’t seem to see seconds.
Even worse, something I didn’t realize before: I don’t even see seconds in the data page!!! The data itself is fine, downloading the CSV shows the seconds part.
I can hack together something to bookmark that tells me using the API, if this isn’t a priority for the official UI, but I’d argue it’s an actual issue in a “quantified self” service
On a related note and speaking of precision: In the end it all ends up as very imprecise Floats anyhow. They will subtly change their value from what you entered. Especially in the iOS app they are very unwieldy because when you edit a datapoint with a seemingly “integery” looking “hh:mm” datapoint value it will expose you to the underlying Float and there’s no way back from there iirc. Not in the app at least. One solution would be to use some BigDecimal type on Beeminder’s site.
If beeminder were to switch to big decimal from float you could run a simple algorithm for goals that goes through your data points and snaps them to the closest possible human entered value, which should work unless you have goals with truly humongous data points. But to be honest, BigDecimal wouldn’t solve the issue anyhow. What you need is an arbitrary precision fractional number (and you could still run the same algorithm).
Take for instance the following data points, which would be “messed up” with a bigdecimal type:
00:20. You add that as Fraction(20, 60)
00:20:20. You add that as Fraction(20, 60) + Fraction(20, 3600).
00:20:20.20. You add that as Fraction(20, 60) + Fraction(20, 3600) + Fraction(20, 3600 * 10^(ceil(log10(20))))
(The last one using log and ceil is probably messed up, but you could just count the number of digits)
This would be the only way to truly be precise with data entered in any format, both time and other units. Note that a BigDecimal is a subset of a Fractional<BigInt, BigInt> (or similar).
On the other hand, even if I believe that would be the “right” way to store data, complexity vs precision gained in practice might be a reason to not do this, at this point in beeminder’s life.
I think what BigDecimal provides is already good enough for Beeminder. It provides “Immutable, arbitrary-precision signed decimal numbers”. But sure, if you wanted, you could easily build a fraction datatype on top of that. I personally would already be happy if my datapoints retained their value and not change to something else when I merely touch them. Like literally touch them in the iOS app.
True, this was imprecise wording on my end. By the way, it’s also not just a bug in the app. IIRC the website exhibits similar behaviour.
However I have seen how entering some fractional values would result in Beeminder showing slightly different values and that is actually something that would be fixed by using a BigDecimal type.
Well, yeah. I was just using BigDecimal as an example since maybe more people know about it than BigInteger. For all I know JS doesn’t even have a BigDecimal Type, let alone a BigInteger type ¯_(ツ)_/¯
I may or may not have edited my post the second after I hit submit when I realised it wasn’t actually what I wanted to say. Discourse does not show edits that happen within a short time after submitting the post. I would have assumed that it delays mails being sent accordingly, though. I guess it doesn’t?
@eugeniobruno, is it possible to spell out the use case further, where you have 5 seconds of work to do and really don’t want Beeminder conservatively telling you you have a whole minute to do?
[EDIT: I just noticed you specifically said that it wasn’t possible to elaborate the use case! Sorry about that! Maybe by DM? I’m keen to get a sense of this and prioritize it properly and possibly think about tradeoffs if we otherwise prefer sticking to HH:MM.]
[FURTHER EDIT: Maybe hearing more in the abstract would also help. Like why worry about padding and stuff? Why not just take Beeminder at face value when it says you have to do a full 60 seconds of the thing? Does that give you too much safety buffer because your rate is literally like 5 seconds a day?]
