As you may have noticed, I found a change in how one of the math nodes in P7 works, compared to earlier versions. I still don't have direct access to P7, but it appears that the behavious of the Round sub-function on the math_fuction node has changed at the boundary. Coincidentally, in the RISKS Digest (also found as the comp.risks newsgroup, a thread has been running on the problem of badly coded math functions, and how little attention is being paid to checking them. This math problem has been covered in the last two or three issues, and if you're at all involved in programming of math-heavy software, you need to check it out. It doesn't matter much in Poser, but with the sort of problem reported, somebody could completely miss a planet. It's ironic that the first electronic computers were involved in calculating artillery fireing tables, and Babbages attempts at mechanical computers were an effort to fix math errors in navigation tables.

Quote - ... somebody could completely miss a planet

Or not, as the case may be -> http://www.cnn.com/TECH/space/9909/30/mars.metric/

I remember the debacle over the Pentium FDIV bug (due to Intel's initial stance) -> http://en.wikipedia.org/wiki/Pentium_FDIV_bug

There are a few other "urban legend" type tales that I know of involving poor math coding, the one that springs most readily to mind is of F16's crossing of the Equator, they started flying upside down, but fortunately this was spotted during simulator trials.

Maybe we should go back to shifting a bunch of little beads on a wire.  BTW, how many saw the Gordon_S Fontoon: Accounting?
David P. Hoadley

I think it was the image node, that changed, not the math node.

I didn't see fontoon, but it would be a bummer having one's jet flip upside-down . perhaps that's why they haven't been involved in any military actions south of the equator. well, excepting the falklands, of course.

F16s in the Falklands?