>I would not put too much trust in Windows calculator, since there you have no control over the precision at all. The actual CORRECT answer according to https://www.wolframalpha.com/input?i=1%2F3.5 Is 0.285714 Repeating forever
Which is what I get on windows only when using Variables. Var_Ans1 = 2.85714285714285714282E-0001 Which as you can see the .285714 repeats exactly 3 times with two more correct digits, for a total of 20 correct digits before we run out of precision. >It seems to be a windows-specific problem. Here is the result of your program when executed on Linux: > Const_Ans1 = 2.85714298486709594727E-0001 > Var_Ans1 = 2.85714298486709594727E-0001 >As you can see, the result is identical. Great, Linux is consistently giving you the wrong answer, and I notice it's the same wrong I answer I get when I use constants. I don't know why it would be different in Windows than on Linux. I am curious what you get in Linux for: A_const = (2/7); // should be 0.285714 Repeating forever also Or B_const = (2/7)-(1/3.5); //should always be 0; Just for fun I ran it on Turbo Pascal 7.0 for DOS and got: Const_Ans1 = 2.85714285714286E-0001 Var_Ans1 = 2.85714285714286E-0001 I also noticed that re-casting constants is not allowed by Turbo Pascal 7.0, so I removed the unnecessary re-casting so it would compile, but I did get the expected answer even without re-casting it... as I expected I should. The fact that Turbo Pascal gives be the correct answer to 14 digits even though in Turbo Pascal I also divided a byte by a single shows that I should expect my pascal programs to provide THIS correct answer, 0.285714 repeating until you run out of precision, not something else. And it shows that a byte divided by a single is in fact able to be an extended... it also proves that in Pascal the result of a byte divided by a single is NOT limited to single precision. 2.85714298486709594727E-0001 makes no sense to me at all, It's like it did the calculation in Single precision, then stored it in an extended, but if I wanted to work in single precision, I would not have set my variable to extended. There is some flawed logic somewhere that says if you do math with a single, the result is a single, but this is simply not correct, you can divide a byte by a byte and get an extended, and you can divide a single by a single and get an extended, Pascal has ALWAYS worked that way. Forcing the result of an equation to be a single because one term is a single is just not right. James _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal