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.

...also...

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?

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.

It's a rounding error.

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?

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?

thanks again!

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."

which obviously is not correct.