Bug SS-2300
3 votes
vote

boolean equal issue (== != <= >=)
Created by Davide on 3/3/2016 1:58 AM Last Updated by Davide on 1/5/2017 12:23 PM
%
 (hrs)
Logged: 0   (hrs)

 Description

Please check this strange behavior of boolean equal vs (non-SI?) units

I was able to reproduce even in previous version of SMath (f.e. SS 0.97.5346)
Skip Navigation Links

    Davide (Thursday, January 5, 2017 5:07 AM) #

Made a survey and the issue is not related to the internal storage nor to the units.

New math for testing:

1143/1250≡3*0.3048=#@#

Long story short, in some cases math on doubles introduces a spurious approximation while comparing (in the case above +1E-16 on the RHS).

    Mike Kaganski (Wednesday, April 6, 2016 10:54 PM) #

This is related to binary representation of floats (and somehow with symbolic/numeric evaluation). Seems that on assignment and evaluation, SMath actually does somehow trim decimal digits after 15th, but inside calculations, it uses full number representation.

(46*'ft-14.0208*'m)*10^15=1.77635683940025*'m

A:46*'ft
(46*'ft-A)*10^15=0
 
A:46*'ft=14.0208*'m
(46*'ft-A)*10^15=1.77635683940025*'m
 
If this truncation was meant to help precise comparison, then I would vote for re-design this decision:
allow variables to always contain non-truncated numbers, but always use truncation (fuzz) on all sorts of comparisons (move the logic from storing to comparing). This would allow a little more precision of computations, while (hopefully) allow more stable comparing.