### Author Topic: Unexpected maths results...  (Read 991 times)

#### Coda

• Newbie
• Posts: 8
##### Unexpected maths results...
« on: May 19, 2024, 01:35:51 AM »
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 floatdim answer2 as doubledim answer3 as Ldoubledim answer4 as doubleanswer1 = 4/5answer2 = 4/5answer3 = 4/5Lanswer4 = 4:answer4 = answer4/5print answer1print answer2print answer3print answer4print 4/5`

#### MrBcx

• Hero Member
• Posts: 2147
##### Re: Unexpected maths results...
« Reply #1 on: May 19, 2024, 08:21:59 AM »
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 FLOATDIM answer2 AS DOUBLEDIM answer3 AS LDOUBLEDIM answer4 AS DOUBLEanswer1 = 4 / 5.0 answer2 = 4.0/5answer3 = 4/5.0Lanswer4 = 4 : answer4 = answer4 / 5.0PRINT answer1PRINT answer2PRINT answer3PRINT answer4PRINT 4/5.0PAUSE`

0.8
0.8
0.8
0.8
0.8

Press any key to continue . . .
« Last Edit: May 19, 2024, 08:24:04 AM by MrBcx »

#### airr

• Full Member
• Posts: 157
##### Re: Unexpected maths results...
« Reply #2 on: May 19, 2024, 09:01:17 AM »
Or cast the result of the division

Code: [Select]
`macro KAST(a,b) =( (a)b )dim answer1 as floatdim answer2 as doubledim answer3 as Ldoubledim answer4 as doubleanswer1 = 4.0/5.0answer2 = (double)4/5answer3 = KAST(LDouble,4/5)answer4 = 4:answer4 = answer4/5print answer1print answer2print answer3print answer4print 4/5pause`
AIR.

#### MrBcx

• Hero Member
• Posts: 2147
##### Re: Unexpected maths results...
« Reply #3 on: May 19, 2024, 09:52:59 AM »
Or cast the result of the division

Code: [Select]
`macro KAST(a,b) =( (a)b )dim answer1 as floatdim answer2 as doubledim answer3 as Ldoubledim answer4 as doubleanswer1 = 4.0/5.0answer2 = (double)4/5answer3 = KAST(LDouble,4/5)answer4 = 4:answer4 = answer4/5print answer1print answer2print answer3print answer4print 4/5pause`
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.
« Last Edit: May 19, 2024, 09:55:05 AM by MrBcx »

#### jbk

• Full Member
• Posts: 231
##### Re: Unexpected maths results...
« Reply #4 on: May 19, 2024, 12:58:58 PM »
CAST(LDouble,4)/5 should also work

#### airr

• Full Member
• Posts: 157
##### Re: Unexpected maths results...
« Reply #5 on: May 19, 2024, 01:59:55 PM »
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

• Hero Member
• Posts: 2147
##### Re: Unexpected maths results...
« Reply #6 on: May 19, 2024, 02:38:44 PM »
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 . . .
« Last Edit: May 19, 2024, 02:59:20 PM by MrBcx »

#### Coda

• Newbie
• Posts: 8
##### Re: Unexpected maths results...
« Reply #7 on: June 12, 2024, 09:16:43 AM »
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

• Hero Member
• Posts: 2147
##### Re: Unexpected maths results...
« Reply #8 on: June 12, 2024, 09:51:00 AM »
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

• Newbie
• Posts: 8
##### Re: Unexpected maths results...
« Reply #9 on: June 18, 2024, 04:12:45 PM »
Quote
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
« Last Edit: June 18, 2024, 11:49:10 PM by Coda »