Post Reply 
newRPL: inexact numbers
12-23-2014, 05:34 PM
Post: #1
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?
Find all posts by this user
Quote this message in a reply
12-23-2014, 09:42 PM
Post: #2
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
Find all posts by this user
Quote this message in a reply
12-24-2014, 02:32 AM
Post: #3
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.
Find all posts by this user
Quote this message in a reply
12-29-2014, 05:32 PM
Post: #4
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.
Find all posts by this user
Quote this message in a reply
Post Reply 




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