Weird Math Result

[MrLeadFoot]

Why does WinBatch evaluate this to be 0, when it really equals .9?

Code Select Expand

a=1080
b=1200
MessageText= a / b
Message("",MessageText)

[JTaylor]

Because you are working with integers.  Try a = 1080.00 and see if that helps.  With WinBatch's automagical data typing you sometimes have to give it a nudge.   Similar in that sometimes when you are trying to do math it will fail because it thinks it is a string and adding zero to it will solve the problem.  I have seen the latter with ADODB returns.

Jim

[td]

I prefer flexible data typing to automagical data typing, but I guess either one gets the point across. Another term for it is negative data typing, which sounds, well, too negative.

[JTaylor]

I think I got that term from Marty.

Jim

[snowsnowsnow]

Note that this is not all that specific to scripting (interpreted) languages, e.g., WinBatch.  C has a similar issue.  See the following tcc command line (this is on Linux, but you could do pretty much the same test using Windows and the Windows version of TCC - or any other Windows C compiler - or you could use WSL, I suppose...);

Code Select Expand

$ tcc - -run << 'EOF'
#include <stdio.h>
int main(void) { printf("%g\n",1+1080.0/1200.0); }
EOF
1.9
$

That works as expected, but if you leave out the .0s, then you get a garbage result (because the type of the expression ends up being int, not double, as is expected by the %g format).

This sort of thing tripped me up a lot in my early days of C programming.  Fortran has similar issues.

Note: I hope it is clear why I included "1+" in the calculation.

[snowsnowsnow]

Hey - I see that they've improved the "Code Block" functionality on this board.  Line numbers (cool) and highlighting (way cool!).  (I looked back at my previous post in the IC54 thread - it looks much better now)

Talk about squeaking wheels getting greased...

[td]

It's not the best because it doesn't automagically recognize the WIL language. It is an improvement until a better solution is found.

[spl]

Because you are working with integers.  Try a = 1080.00 and see if that helps.  With WinBatch's automagical data typing you sometimes have to give it a nudge.   Similar in that sometimes when you are trying to do math it will fail because it thinks it is a string and adding zero to it will solve the problem.  I have seen the latter with ADODB returns.

Jim

Right, and and don't get confused with WB's decimal(#number) thinking that might create a decimal output. It is intended to work with pre-established floating point.

[td]

I think I got that term from Marty.

Jim

I got "negative typing" from Marty as well. I was struggling for a word in a conversation, and he suggested that one. He said he had heard it somewhere.