07-26-2024, 12:17 AM
I would look at it a different way - if the value is supposed to be an integer, why aren't you using an integer variable from the start? And if it won't always be an integer, why do you care if it's specifically an integer (vs. just close to an integer)?
The key issue is that even if your floating-point values start out as integers, they might not still be integers when you go to check them. Ex. Operations that should round-trip back to an integer may not do so due to floating-point error, such as several division and multiplication steps. In general it's very hard to guarantee this won't happen, and much easier to simply allow for it to happen and check for values within a certain tolerance of the expected value.
(07-25-2024, 07:40 PM)TerryRitchie Wrote: Could any "floating point anomalies" with QB64 affect the method I have shown above?Yes, the issues are common to all languages that use the IEEE-754 representation of floating-point values (which is most of them).
The key issue is that even if your floating-point values start out as integers, they might not still be integers when you go to check them. Ex. Operations that should round-trip back to an integer may not do so due to floating-point error, such as several division and multiplication steps. In general it's very hard to guarantee this won't happen, and much easier to simply allow for it to happen and check for values within a certain tolerance of the expected value.