Lance Ford Jones

This is a routine I wrote to show a timecode display for a given frame number.

Can anyone explain why these two routines would give different results?

They are identical except for the placement of the yellow floating point number box.

The error first occurs at 27 (frames) but occurs at other numbers as well.

Essentially if the result of the frames calculation passes thru the box the result is correct, otherwise not.

Can anyone explain why these two routines would give different results?
They are identical except for the placement of the yellow floating point number box.
The error first occurs at 27 (frames) but occurs at other numbers as well.
Essentially if the result of the frames calculation passes thru the box the result is correct, otherwise not.


math-weirdness

seems to be a timing/order of operation issue:

Thank you. (but I have a few questions...)

I can see that the trigger object solves the problem, but I can't see why.

How is the trigger object sending three copies of the float different from my routine which simply gets that float to three inlets via patchcords?

And shouldn't the rightmost fork execute first, then the next, right to left, until the leftmost fork executes last?

Why would my routine work if the number passes through a floating point number object and not work if it doesn't?

Forgive the barrage of questions but I'm a teacher and I need to be able to explain why these things happen.

How is the trigger object sending three copies of the float different from my routine which simply gets that float to three inlets via patchcords?
And shouldn't the rightmost fork execute first, then the next, right to left, until the leftmost fork executes last?
Why would my routine work if the number passes through a floating point number object and not work if it doesn't?

Forgive the barrage of questions but I'm a teacher and I need to be able to explain why these things happen.


if it's a timing issue, why does it only happen (and repeatably) on certain numbers?

looking at the picture of the patch i dont see how it could be a order issue. the order is the same in both versions.

what happens if you put a del 0 at the beginning?

looking at the picture of the patch i dont see how it could be a order issue. the order is the same in both versions.  

what happens if you put a del 0 at the beginning?


This makes your patch work without the trigger object:

Why? I don't know. The thing is: if it is critical to do things in a certain order, use trigger! That's probably one of the the single most important lesson for your students.

Then again, like roman said, I can't see how this is even a timing/order issue.

Why? I don't know. The thing is: if it is critical to do things in a certain order, use trigger! That's probably one of the the single most important lesson for your students.
Then again, like roman said, I can't see how this is even a timing/order issue.


float are truncated not rounded when converted to int :

yes rounding error :
float are truncated not rounded when converted to int :


thank you everyone for your thoughtful help.

Roman - what do you mean by “put a del 0 at the beginning” ?

David - a misunderstanding i think - the routine on the right works, the routine on the left should work but doesn’t - i just put the two versions for comparison (you made the left like the right) - i’ll be sure to remind students about the trigger object, i probably under-utilize it.

JVKR - i don’t understand. the patch (adding the “trig i” at the tail of the frames calculation) doesn’t work.

Etienne - you get the award for the code that has freaked me out the most - especially this bit: (why doesn’t the floating point number box show 0.19999999? it appears that it rounds the number up for display and then passes the unrounded number?

if this is a rounding error why does MIB’s “trig f f f” make it work (and again, what i don’t understand about MIB’s solution is that the three floats sent out by the trig object should be the same in value, form, and timing, as my sending the result of the “/ 108000.” to those same three inlets.)

why does it work in my patch when I send the frames calculation through a floating point number box and does not work when i don’t? Etienne’s patch would indicate that the flonum object might display a rounded result but passes an unaltered value?

too often when i’m working in Max i find a workaround to this type of problem and i put the problem out of my mind and go on with my coding. this makes me uncomfortable. either i have a basic misunderstanding of some aspects of max or there are inconsistencies in the way Max executes.

can anyone give a definitive answer here?

the question is: how do i do math in Max with certainty that the result is as accurate as possible?

thank you everyone for your thoughtful help. 

too often when i’m working in Max i find a workaround to this type of problem and i put the problem out of my mind and go on with my coding. this makes me uncomfortable. either i have a basic misunderstanding of some aspects of max or there are inconsistencies in the way Max executes. 

can anyone give a definitive answer here?
the question is: how do i do math in Max with certainty that the result is as accurate as possible?

okay. who knew that flonum's attribute for number of decimal places defaults to zero.

the reference page says (numerous times):

"The number displayed in the number box is sent out the outlet."

math weirdness