Bug of DIV (integer division) #7

Open
opened 2 months ago by RUBarzan · 6 comments

X11Basic version 1.27-62

Code:

mx = 600851475143
print mx div 71
quit

Expected output:
8462696833

Acuall output:
-30246248

X11Basic version 1.27-62 Code: ``` mx = 600851475143 print mx div 71 quit ``` Expected output: 8462696833 Acuall output: -30246248
Owner

Hi RUBarzan,

yes, confirmed, thanx for reporting this.

the number 600851475143 seems to be too big for a normal (float) variable.
It seems to be a problem with the DIV operator on floats.

You can use an arbitrary big interger variable instead:

(workaround)


mx&=600851475143
a=(mx& div 71)
print a
quit

Will work as expected.

However I think you are right, something is strange here because 600851475143
really should fit into a 64bt float. So I consider this as a real bug which should be fixed.

Hi RUBarzan, yes, confirmed, thanx for reporting this. <s>the number 600851475143 seems to be too big for a normal (float) variable. </s> It seems to be a problem with the DIV operator on floats. You can use an arbitrary big interger variable instead: (workaround) <pre> mx&=600851475143 a=(mx& div 71) print a quit </pre> Will work as expected. However I think you are right, something is strange here because 600851475143 really should fit into a 64bt float. So I consider this as a real bug which should be fixed.
Owner
mx=600851475143.1
print mx

gg&=mx
print gg&
a=(gg& div 71)
print a
quit

This does also work. Hm...

<pre> mx=600851475143.1 print mx gg&=mx print gg& a=(gg& div 71) print a quit </pre> This does also work. Hm...
kollo added the
bug
confirmed
labels 2 months ago
Owner

The problem starts as soon as the number (mx) is bigger than 2140000000. So I guess, the float is converted to integer (32bit) bevor applying the DIV operator. 2^(32-1)=2147483648

The is no way to know if the number stored in a float (64 bit) still fits in a 32bit integer without evaluating the actual value of the variable. ANd I think the interpreter should not do this. So the default treatment of the operands of DIV is to convert them to 32bit integer befor applying the operator. Only if you use the big integer variables in the expression then the interpreter can know that the number should not be converted to standard 32bit integer but to arbitrary int instead and then the DIV operator is applyed for arbint.

If one would change the default behaviour (always convert float to arbint) this would slow down the operation much even for normal small numbers... So maybe I would not want to fix this. What do you think? Is this really a bug?

Maybe instead explain this in the manual ?

The problem starts as soon as the number (mx) is bigger than 2140000000. So I guess, the float is converted to integer (32bit) bevor applying the DIV operator. 2^(32-1)=2147483648 The is no way to know if the number stored in a float (64 bit) still fits in a 32bit integer without evaluating the actual value of the variable. ANd I think the interpreter should not do this. So the default treatment of the operands of DIV is to convert them to 32bit integer befor applying the operator. Only if you use the big integer variables in the expression then the interpreter can know that the number should not be converted to standard 32bit integer but to arbitrary int instead and then the DIV operator is applyed for arbint. If one would change the default behaviour (always convert float to arbint) this would slow down the operation much even for normal small numbers... So maybe I would not want to fix this. What do you think? Is this really a bug? Maybe instead explain this in the manual ?
Poster

I think you should definitely fix it! If you leave it as it is, it makes the code un-reliable. Explaining it in the manual makes it complicated, So maybe the best option is to explain it in the manual and then fix it in near future.

Thanks a lot.

I think you should definitely fix it! If you leave it as it is, it makes the code un-reliable. Explaining it in the manual makes it complicated, So maybe the best option is to explain it in the manual and then fix it in near future. Thanks a lot.
Owner
I think you can change the default variable type from 64 bit to 32 bit. 64 bit integers are really unnecessary unless we are dealing with mathematical problems.

Well that ist the problem, a 32 bit integer variable cannot hold the value 600851475143. However the reason why X11-Basic does not produce an error message is, that by default the value is stored in a normal 64bit float variable. There no problem occurs but when applying an operator which works on 32bit int the value neded to be converted (without checking).

``` I think you can change the default variable type from 64 bit to 32 bit. 64 bit integers are really unnecessary unless we are dealing with mathematical problems. ``` Well that ist the problem, a 32 bit integer variable cannot hold the value 600851475143. However the reason why X11-Basic does not produce an error message is, that by default the value is stored in a normal 64bit float variable. There no problem occurs but when applying an operator which works on 32bit int the value neded to be converted (without checking).
Owner

I think you should definitely fix it! If you leave it as it is, it makes the code un-reliable. Explaining it in the manual makes it complicated, So maybe the best option is to explain it in the manual and then fix it in near future.

If I knew how to best fix it, I would. Maybe: Whenever a value is converted from float to int the range must be checked and an error should be thrown if the value would get truncated.

> I think you should definitely fix it! If you leave it as it is, it makes the code un-reliable. Explaining it in the manual makes it complicated, So maybe the best option is to explain it in the manual and then fix it in near future. > If I knew how to best fix it, I would. Maybe: Whenever a value is converted from float to int the range must be checked and an error should be thrown if the value would get truncated.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.