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.
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 ?
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.
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).
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.
X11Basic version 1.27-62
Code:
Expected output:
8462696833
Acuall output:
-30246248
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)
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.
This does also work. Hm...
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 ?
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.
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).
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.