Formula Node Floor(x) Produces Different Result

Question

Hi, A search didn't find anything about the Floor(x) function, so... I'm using LabVIEW 6.0.2, and the Floor(x)function in a Formula Node seems to be producing different results depending on previous calculations. I've got the following 2 lines in a Formula Node:
MSS = Ref / RefDiv;
MDN = floor(RF / MSS);
Ref is always 20.0M, RefDiv always 500.0, and for this calcualtion RF is always 1539.4, all numbers Double with 6 digits of precision. I generate an array of frequencies given a start, step, and frequency count. These frequencies then go to a subVI with a Formula Node that calculates the byte values to send to a couple PLLs.
If Start = 70.1, Step = .025, and Count = 20, at frequency 70.2 the Floor function gives 38.485.
If Start = 70.0, Step = .025, and Count = 20, at frequency 70.2 the Floor function gives 38.484.
I've omitted some calc steps here, but I've verified the starting values in the subVI are the same in both cases. Why the result changes I'm hoping someone can tell me...
Thanks,
Steve

Answer 1

I want to thank those involved again for their help. With ideas and hints from others I found a solution without scaling.
In recap, what had bothered me was it *appeared* like the same subVI was giving correct results one time and incorrect results only randomly. While I understand binary fractional imprecision, I wasn't doing any looped calculations 100+ times or anything.
I did some more checking though. The problem was indeed introduced by cumulative fractional addition. In this case 10 additions were enought to cause the error. Apparently, floor(71.199_94) produces 72.0. However, using a shift register and constant fraction to add an offset to produce an array introduces enough error in under 10 iterations to be a problem. By the time the loop got to what was supposed to be 72.0, it was actually 71.199_84 or something, enough to throw the floor function. Now I understand why the error occurred, and why it wasn't a problem before.
I fixed this problem by changing the real frequency number to a I32 before introduction to the formula node. This corrected the error introduced by the fractional addition by forcing 71.199_84 to 72, instead of letting it propagate through the rest of the calculations. And it was a whole lot easier than changing all the VIs to allow scaling! Also, I prefer to know where and why the problem happened, instead of just scaling all my calcualtions. Maybe I can recoginse potential problems in the future.
My boss wants to go back and look at his program to see if HPVee somehow bypassed the problem or if he did the calculations differently.
Thanks again for the insight and help,
Steve