Bug SS-2383
1 vote

Bug with matrices calculation ?

Created by AarDvark on 9/3/2016 6:31 PM Last Updated by smath on 1/17/2018 8:50 AM
Logged: 0   (hrs)



Hard to explain textually, but i'm doing matrices operations and theorically should return vector (M) with each row having the same values. Then find the max value and compare (boolean equal) with each row value, it should be true for each row, but it's not.... see attached worksheet.

    smath (Wednesday, January 17, 2018 8:49 AM) #

Agree with Davide. This is rounding related issue which is impossible to avoid.

Situations like this must be handled by creater of the worksheet (like abs(a-b)<tollerance).

    Davide (Sunday, September 4, 2016 6:47 PM) #

CTRL+A -> click on a math region -> Optimization > numeric to switch all to numeric optimization; also, you can force numeric calculation with eval(...)

For me the issue is strictly related to cases in wich boolean equals are involved (even booleans "less/greater than or equal"); in general however the answer is correct since as shown the numbers are not equals; consider even that working with floating points numbers a good practice would be to use something like abs(a-b)<tollerance instead of a≡b (in your case abs(max(H.i)-el(H.i,#))<0.5*10^{-15}*'m ).

    AarDvark (Saturday, September 3, 2016 11:27 PM) #

​Ok thanks! So unless you need a precision higher than 1e-15, would you recommend working strictly with Numeric Optimization? Or only with data used with boolean operators? Is there is a way to specify a global Optimization method for the whole worksheet? Thanks!

    Davide (Saturday, September 3, 2016 7:43 PM) #

Seems a rounding issue due to the different optimizations involved; H.i is defined simbolically (hold the mouse over the loop to see the output), then a numerical comparision is done max(H.i)=el(H.i,#)

as you can see H.i (symbolical) contains 2 "type of numbers" (2nd and 3rd values are different from the others, the maximum while computed numerically)

If you setup the H.i optimization to numeric on his definition, the numerical values truncated at the 15th decimal will be stored (and the issue disappears)


As stated in SS-2300 comments probably a solution might be to store numerical values not truncated and truncate before comparing (and when displying results obviously)