newRPL - build 1255 released! [updated to 1299]

[JoJo1973]

(05-15-2019 09:00 PM)Claudio L. Wrote:  

(05-15-2019 11:47 AM)Gilles Wrote:  Claudio, thanks for your reply. About the IP command, I noticed that the IP command returns an approx or exact number :

1.2 IP returns 1
but
1.2. IP returns 1.
and
1. IP returns 1.

Perhaps it would be more coherent that the IP command always return an exact number :

1. IP -> 1

?

An approximated number can only be guaranteed correct to the number of digits it carries (usually the current system precision), the dot doesn't have any real practical meaning other than confirming to the user that the number he's seeing on the screen may have been subjected to rounding error at the current precision.
IP of an approximated number is still an approximation. Let's say precision is 4 and the "exact" number should've been 0.99999 (5 digits of 9). At the current system precision of 4, the number in question would be represented as 1.000. (4 dgits w/ending dot) If you use IP of that approximated number you'll get 1. (one w/ending dot, not exact). Notice that IP of the exact number would've been 0, so the result of IP too may have been affected by rounding error and is therefore not guaranteed to be exact.

(05-15-2019 11:47 AM)Gilles Wrote:  If not, NewRpl lacks an R->I (or a more generic A->E Approx to exact) command

Why would you care to force an inexact number to be exact? Besides obsessing about whether a number is exact or not, I can't see any practical use for that.
If you can think of a specific use and can convince me to add the command, I'm open to it. I just never found any real case that would need it.

From a numerical stand point, me neither can see a real use case for an approximate to exact conversion, which can be however emulated via the << ->STR RTAIL STR-> >> sequence (of course, the inverse is simply << 0. + >>.

Nevertheless, the string manipulation trick highlights an issue: ->STR respects the current numerical format, therefore if I have set a fancy format for my numbers but need a different one for e.g. result presentation/string manipulation I have to GETNFMT, SETNFMT, do my trick and re-SETNFMT.

It's cumbersome to write and requires unwanted stack manipulation: Claudio, would it be possible in the future to add a ->NFMT command which accepts a number and a format list and does a one-off string conversion?