[Roger Hunter]

(12-31-2013, 04:09 AM)Skywise Wrote: Yep. How you implement a calculation can affect the outcome when precision is involved. This can be a particular issue in strongly typed languages such as XB or C/C++ where commands which mix data types have an implied type conversion.

You may not have explicit types in TB, but TB has to translate things into code the CPU can use, and the CPU *does* have explicit types.

Undoubtedly but TB has no way to use them.

Quote:But your solution technically isn't the same calculation. You changed one of the input values from 6.2 to 62 and rearranged the formula to compensate.

That's correct. I was computing an array index and floating point will get you into trouble there.

Quote:x# = 6.3
y# = 6.2
z = (x#-y#)*10
q = INT(z)

x# and y# are doubles (double precisions floating point). z is an integer (in this case, 32 bit signed). In the calculation there is an implicit type conversion of the result of the calculation into an integer because I'm assigning the answer to z which is an integer, which rounded off the floating point result.

Everything in TB is double precision real. I dislike types; it's extra work the PC should do for me. In QL SuperBasic you could say 2+two and get 4

Roger