newRPL: inexact numbers - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: Not HP Calculators (/forum-7.html) +--- Forum: Not quite HP Calculators - but related (/forum-8.html) +--- Thread: newRPL: inexact numbers (/thread-2701.html) newRPL: inexact numbers - Claudio L. - 12-23-2014 05:34 PM Another idea: The mpdecimal library on which newRPL is based, has a flag that indicates when an operation result is inexact. This could be used to keep a flag within each number that would specify whether it's an exact number or an inexact result. For example: 2 INV --> 0.5 (exact) 3 INV --> 0.33333 (inexact) This flag can be carried over through the mathematical operations. to indicate whether a result obtained has any error from calculations or if the result is exact. Could this be something worth implementing? RE: newRPL: inexact numbers - Paul Dale - 12-23-2014 09:42 PM I'd have though implementing interval arithmetic would be more useful. So you not only know that the result isn't exact, you also have bounds on its inexactness. Unfortunately, the inexact flag is set for almost all floating point operations which means having numbers inherit it will make almost all number inexact very quickly (assuming an operation on an inexact number remains inexact regardless). It is best used for checking single operations when you really need to know if there is a rounding step and completely ignored the rest of the time. - Pauli RE: newRPL: inexact numbers - Claudio L. - 12-24-2014 02:32 AM You're right, it will be ignored 99% of the time, and carrying the flag takes a small overhead, so is probably not worth it. RE: newRPL: inexact numbers - Claudio L. - 12-29-2014 05:32 PM In the other thread about symbolic numbers, the trailing dot was used to specify "exact" vs. "approximated" numbers. This same concept can be used to achieve what this thread was proposing: if any operation comes up with the "inexact" flag, its result will be an "approx." number, which will be displayed with a trailing dot. The result of any numeric operation will be an "approx" number if either: a) The result of the operation has the "inexact" bit set b) Any input to the operator is an approx. number 2 INV --> 0.5 (exact) 2. INV --> 0.5. (approx) 3 INV --> 0.33333333. (approx) Since this had to be implemented for the CAS to work properly without an exact/approx. mode, the overhead was already there. I already implemented it and is being tested. Next demo will come with this feature.