Precision issues?

[qrilka]

Is it expected that val has issues with pretty simple maths:

> 3/0.3
9.999999999999999999638599275838165188677243448052489290723920184291763484634438119240953935767453109935097333701144509022736710144954636618289433451003687028470739063831026552792493003758341867827403909345549573387897596864842329098472852609538841709416101724505651633865574921706159667730031303727371884859

[johnblommers]

Is it expected that val has issues with pretty simple maths:

> 3/0.3
9.999999999999999999638599275838165188677243448052489290723920184291763484634438119240953935767453109935097333701144509022736710144954636618289433451003687028470739063831026552792493003758341867827403909345549573387897596864842329098472852609538841709416101724505651633865574921706159667730031303727371884859

Yet this works just fine:

> 3/(3/10)
10
>

And the reason is:

> 0.3
0.30000000000000000001
> x=3/10
0.300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
> 3/x
10
> 

Are we asking that val takes the string 0.3 and notes that it's actually 3/10 that the user meant to write?

[qrilka]

I was just asking about precision loss which could be understandable but not quite helpful for users. BTW docs of val mention bc as prior art but I don't see such a problem there:

~$ echo "3/0.3" | bc
10

[johnblommers]

I was just asking about precision loss which could be understandable but not quite helpful for users. BTW docs of val mention bc as prior art but I don't see such a problem there:

~$ echo "3/0.3" | bc
10

Agree completely. bc is parsing the 0.3 differently. It looks like it's saying OK let's not convert 0.3 to a floating point representation. Is it doing decimal arithmetic internally, I wonder? (Does research). Yes, it is.

Excellent, I learned something.