Does using a macro datapoint something like this ‘multiply’ by two?
1 Like
Your wish is our command! We now have a PROD[] macro. Eager to hear if that works for you!
5 Likes
I am mostly using Ifttt for Beeminder=>beeminder recipes. Is this true that one added point can trigger only one recipe? I have a series of recipes triggered by a specific goal being updated. At first, everything worked fine. Then, at some point, I discovered that one of two if not working. (Without any error or anything obvious). Now that you posted this update, I understood I can make use of some more macros and updated the recipes. So, now, the updated one started working, but the other one doesn’t. Is there any inherent limit for the number of recipes triggered by a goal update? It looks like it just stops considering that anything has happened, after it works for the first recipe…
1 Like
Hmm, can’t get the darn thing working.
I’m doing PROD[{{Ingredient}}, 0.5]
Am I just screwing up the notation?
1 Like
Whooops, I just implemented it wrong because of some lazy coding where I left two competing functions in the controller, and then updated the deprecated one instead of the one that’s in use… so smack on the wrist for bad code hygiene. Confirmed it works now.
3 Likes
Would a word count macro be possible? I’m thinking for primarily counting words in RSS items, but I bet there’s a bunch of other things you could use it for.
I could use this to add to my “blog more times/days/words” goals, and @edalfon could use it for their Lang8 IFTTT integration.
2 Likes
WORDCOUNT[] macro added!
2 Likes
Yay word count yay Beeninding Lang-8!
But:
Some languages, like Japanese and Chinese, don’t really use spaces to demarcate words.
Could… we have a CHARCOUNT macro too eventually?
4 Likes
Your wish is our command!
(Updating the wikified docs above now too.)
2 Likes
Did the last change dislodge something? Last night I got an error message with a macro using NUM[]: “Beeminder is expecting a numeric input for the datapoint value, but instead we got NUM[#weighed in at 192.].” (This has worked before.)
Also, suggestion: is TOD[] functionally identical to a hypothetical TIME[]? (I am currently using it that way for amounts of time like 0:30, the way I would enter them on a Beeminder page directly, but I don’t know if it is meant to work in all cases.) If not, can we officially have TIME also?
1 Like
Upon testing, I think you’ve just found a subtle bug with the NUM macro – it seems it fails if the there’s a period immediately following the digits. If I submit a trigger with NUM[#weighed in at 192.] it fails, but with NUM[#weighed in at 192] it succeeds. I guess the period is getting parsed as potentially part of the number but then somewhere else it’s causing an error somehow?
TOD is for pulling the time portion of a string of text with numbers formatted like DD:D (which yes, then gets parsed same as elsewhere on beeminder, so 6:30 would get turned to 6.5 etc).
HMS is for pulling the time portion of a string of text with numbers like Dh DDm DDs, which basically gets converted to D:DD:DD, so is really all the same thing.
1 Like
hi
HMS function generates 5.0 datapoint from "5 hours 34 mins of sleep logged last night misfit via ifttt"
i am correcting entries now. what is correct usage? thanks
Edit: datapoint area value in ifttt recipe > HMS[{{TotalTimeSlept}}]
1 Like
@bee Strava’s IFTTT channel reports activity duration like this:
1 hour, 22 minutes, 17 seconds, or
12345 (number of seconds). HMS[] can’t deal with either of these, even if I make the seconds one into 0h 0m 12345s
I’ve worked around it using the number of seconds and PROD[NumberofSeconds, 0.0002777] for the moment. It would be cool if PROD[] could interpret fractions too.
Good #UVI candidates.
2 Likes
I have also very recently noticed that “HMS” doesn’t do seconds as expected.
Maybe these two observations are reports of the same bug.
2 Likes
Maybe something like MAX? I have a goal where I never want more than 1 per day (dailysweat), even if I did several activities that day that qualify. It isn’t likely to happen often, but it could, especially with this new machine of mine. Or is there some other way to handle that elegantly? Preferably without meta-goals?
A custom goal with aggday set to nonzero does that. It does require a
premium account though. (Documentation on various aggdays here: Documentation of aggregation methods would be nice)
2 Likes
Thanks! I’ve had premium for ages, but haven’t really explored all the options 
Edit: I’m not sure I understand what nonzero will do (is there a reference here in the forums?), so I use max. I tend to always add 1 (0.5 has happened, but that wouldn’t be a problem), and so I will never get more than 1, and that is what I want.
Edit: Turns out that I also was blind last night.
1 Like
Is there any way to avoid an infinite regress?
My use case is this: I want to use IFTTT Macros to give non-linear returns to time spent on something – give an incentive to batching things (higher efficiency from spending more time per session). Doing this with PROD[] is fine and this then gives a value to beeminder, however that value then triggers the trigger again (and soon numbers explode).
This actually seems slightly beyond the OT but going more towards IFTTT-algorithm design, but maybe there is something I am not seeing.
1 Like
I would like to request the following macros:
EQ[A, B] - return 1 if A=B, 0 otherwise
LT[A, B] - return 1 if A < B, 0 otherwise
IF[A, B, C] - return C if A=0, B otherwise
ROUND[A] - return the closest integer to A
FLOOR[A] - return the largest integer less than or equal to A
CEILING[A] - return the smallest integer greater than or equal to A
POSITION[N, L] - return the Nth number in L separated by any non-numeric character (I’m not sure how to handle decimal points)
LENGTH[L] - return the number of numbers in L
MAX[L] - return the largest number in L
MIN[L] - return the smallest number in L
1 Like