Unexpected maths results...

[Coda]

Hi,

I compiled this for console with lcc. Can someone please explain why I am receiving these strange zero results?

Code: [Select]

dim answer1 as float
dim answer2 as double
dim answer3 as Ldouble
dim answer4 as double

answer1 = 4/5
answer2 = 4/5
answer3 = 4/5L
answer4 = 4:answer4 = answer4/5

print answer1
print answer2
print answer3
print answer4
print 4/5


[MrBcx]

It's a c/c++ compiler thing, all of them, not only Lcc.

Basically, when dealing with floating point operations, your expressions
should include at least one operation that explicitly informs the compiler
that a floating point operation is occurring.

Notice below how I included a decimal zero in arbitrary places.

Code: [Select]

DIM answer1 AS FLOAT
DIM answer2 AS DOUBLE
DIM answer3 AS LDOUBLE
DIM answer4 AS DOUBLE

answer1 = 4 / 5.0
answer2 = 4.0/5
answer3 = 4/5.0L
answer4 = 4 : answer4 = answer4 / 5.0

PRINT answer1
PRINT answer2
PRINT answer3
PRINT answer4
PRINT 4/5.0

PAUSE


 0.8
 0.8
 0.8
 0.8
 0.8

Press any key to continue . . .

[airr]

Or cast the result of the division

Code: [Select]

macro KAST(a,b) =( (a)b )


dim answer1 as float
dim answer2 as double
dim answer3 as Ldouble
dim answer4 as double

answer1 = 4.0/5.0
answer2 = (double)4/5
answer3 = KAST(LDouble,4/5)
answer4 = 4:answer4 = answer4/5

print answer1
print answer2
print answer3
print answer4
print 4/5

pause
AIR.

[MrBcx]

Or cast the result of the division

Code: [Select]

macro KAST(a,b) =( (a)b )


dim answer1 as float
dim answer2 as double
dim answer3 as Ldouble
dim answer4 as double

answer1 = 4.0/5.0
answer2 = (double)4/5
answer3 = KAST(LDouble,4/5)
answer4 = 4:answer4 = answer4/5

print answer1
print answer2
print answer3
print answer4
print 4/5

pause
AIR.

A word of caution.

BCX's forthcoming revised CAST macro uses the form CAST(a,b) =( (a) (b) ) which forces evaluation of both args.
Notice the parenthesis around the "b" arg.  That evaluates differently from the version of KAST that AIR provided. 
The new CAST() macro will result in this:

 0.8
 0.8
 0
 0.8
 0.8

Press any key to continue . . .


That's because the forthcoming CAST(LDouble,4/5)  sees 4/5 as integer division. 
One of those numbers needs a decimal zero, to tell c/c++ compilers to produce the intended results.

[jbk]

CAST(LDouble,4)/5 should also work 

[airr]

BCX's forthcoming revised CAST macro uses the form CAST(a,b) =( (a) (b) ) which forces evaluation of both args.

MrB is correct as usual.

The form I use works in this case (if you want the returned value to be a float/double), but if I'm right it only casts the first number (4) and then divides.  So I think it would be equivalent to (double)(4)/5, with the division happening after the cast (so like 4.0/5), which I believe is what happens with the answer2 variable in the code I posted.


MrB, is what I wrote above more or less correct?  I made the mistake of thinking the the cast would 'convert' both numbers the way I wrote it.   

The learning never ends!

AIR.

[MrBcx]

BCX's forthcoming revised CAST macro uses the form CAST(a,b) =( (a) (b) ) which forces evaluation of both args.

MrB is correct as usual.

The form I use works in this case (if you want the returned value to be a float/double), but if I'm right it only casts the first number (4) and then divides.  So I think it would be equivalent to (double)(4)/5, with the division happening after the cast (so like 4.0/5), which I believe is what happens with the answer2 variable in the code I posted.


MrB, is what I wrote above more or less correct?  I made the mistake of thinking the the cast would 'convert' both numbers the way I wrote it.   

The learning never ends!

AIR.

Armando - I can't say whether your understanding is correct or not.

I can say that your example, compiled w/ MSVC-2022 (crt and ucrt) produces the following,
regardless whether I include ".0" in either the numerator, denominator, both, or neither:

 0.8
 0.8
0.8000000000000000444
 0.8
 0.8

Press any key to continue . . .


All other compilers produce:

 0.8
 0.8
0.8
 0.8
 0.8

Press any key to continue . . .

[Coda]

Ok,

Thankyou everybody for you assistance. That is clear now. This may explain one of the many reasons I struggled and ultimately failed to learn C, or at least learn it well, when I tried about 15 years ago. I did manage to produce one useful app in it though. I was not aware of this facet of the language and felt that as long as the variable I planned to store the answer in was a float, floating point division would be assumed. Clearly not. I guess this error in my thinking stems, at least in part, from the fact that most of the languages I have dealt with in the past have involved having to do something active to insure an integer answer to a division. ie. Code like x = int(y/z) or similar. I am not used to passively getting integers back without extra effort. lol

Thankyou once again.

[MrBcx]

Ok,

Thankyou everybody for you assistance. That is clear now. This may explain one of the many reasons I struggled and ultimately failed to learn C, or at least learn it well, when I tried about 15 years ago. I did manage to produce one useful app in it though. I was not aware of this facet of the language and felt that as long as the variable I planned to store the answer in was a float, floating point division would be assumed. Clearly not. I guess this error in my thinking stems, at least in part, from the fact that most of the languages I have dealt with in the past have involved having to do something active to insure an integer answer to a division. ie. Code like x = int(y/z) or similar. I am not used to passively getting integers back without extra effort. lol

Thankyou once again.

Glad you got it sorted out.  Two points that I can make here. 

1) It would not take me much effort for BCX to automatically assign a decimal component to every literal number that it
    translates.  In other words, during translation BCX could be made to transform MyVar =123 to MyVar=123.0
    One obvious downside of that is that our c/c++ compilers will have to work harder to promote / demote the literal value
    into the value that the statement expects.  Another would be the nearly-certain unintended consequences that would arise.
   Therefore, I'm compelled to leave well enough alone.

2) Another point to remember, and this is documented in the BCX Help file, is that I chose to make INTEGERS the default
    datatype, whereas most of BASICs traditionally default to SINGLE PRECISION FLOATING POINT which for most things
    is completely unnecessary, takes the CPU  longer to process, and ultimately slows down an application.

[Coda]

Therefore, I'm compelled to leave well enough alone.

Fair enough. I'm sure I will survive this hiccough in my BCX adventure now that I know. It's surprising how one can adapt just so long as one knows and hey... I've learned something about C that I previously failed to take in. lol