newRPL: inexact numbers
12-23-2014, 05:34 PM
Post: #1
 Claudio L. Senior Member Posts: 1,883 Joined: Dec 2013
newRPL: inexact numbers
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?
12-23-2014, 09:42 PM
Post: #2
 Paul Dale Senior Member Posts: 1,837 Joined: Dec 2013
RE: newRPL: inexact numbers
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
12-24-2014, 02:32 AM
Post: #3
 Claudio L. Senior Member Posts: 1,883 Joined: Dec 2013
RE: newRPL: inexact numbers
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.
12-29-2014, 05:32 PM
Post: #4
 Claudio L. Senior Member Posts: 1,883 Joined: Dec 2013
RE: newRPL: inexact numbers
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.
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)