I->R and R->I without (rounding) errors

[cahlucas]

Hi all,
For several programs, I need two routines that convert exactly between reals and integers and vice versa. And of course without rounding errors. Does anyone know of any suitable programs to do this job? Preferably in system RPL, but it is also allowed in user RPL. Please, anyone, return an answer.

[KeithB]

Are you going to limit the magnitude of the real?
What do you want to do if the real has a fractional part?

[Joe Horn]

(08-03-2021 05:32 PM)cahlucas Wrote:  Hi all,
For several programs, I need two routines that convert exactly between reals and integers and vice versa. And of course without rounding errors. Does anyone know of any suitable programs to do this job? Preferably in system RPL, but it is also allowed in user RPL. Please, anyone, return an answer.

Please give us some examples of where the built-in R->I and I->R functions fail, and of course please accompany each example with the output that you would prefer. Thanks!

[cahlucas]

(08-03-2021 05:44 PM)KeithB Wrote:  Are you going to limit the magnitude of the real?
What do you want to do if the real has a fractional part?

Dear Keith,
The magnitude will not be limited. The fractional part will be rounded to the nearest integer.

[cahlucas]

(08-03-2021 09:21 PM)Joe Horn Wrote:  Please give us some examples of where the built-in R->I and I->R functions fail, and of course please accompany each example with the output that you would prefer. Thanks!

Dear Mr. Horn,
Here is an example from your own creations (B->I and I->B):
2 41 ^ --> 2199023255552
2199023255552 0. + --> 2.19902325555E12 (or I->R)
2.19902325555E12 R->I --> 2199023255550
This should actually return the original number, but the last 2 have become a 0.

[BINUBALL]

(08-04-2021 04:47 AM)cahlucas Wrote:  

(08-03-2021 09:21 PM)Joe Horn Wrote:  Please give us some examples of where the built-in R->I and I->R functions fail, and of course please accompany each example with the output that you would prefer. Thanks!

Dear Mr. Horn,
Here is an example from your own creations (B->I and I->B):
2 41 ^ --> 2199023255552
2199023255552 0. + --> 2.19902325555E12 (or I->R)
2.19902325555E12 R->I --> 2199023255550
This should actually return the original number, but the last 2 have become a 0.

Dear cahlucas,
Unfortunately real on 50g has only 12 digit precision. So after you convert integer to real, last digit is lost. There is no way to get digit beyond 12 digits on real.

[Joe Horn]

(08-04-2021 07:18 AM)BINUBALL Wrote:  

(08-04-2021 04:47 AM)cahlucas Wrote:  Dear Mr. Horn,
Here is an example from your own creations (B->I and I->B):
2 41 ^ --> 2199023255552
2199023255552 0. + --> 2.19902325555E12 (or I->R)
2.19902325555E12 R->I --> 2199023255550
This should actually return the original number, but the last 2 have become a 0.

Dear cahlucas,
Unfortunately real on 50g has only 12 digit precision. So after you convert integer to real, last digit is lost. There is no way to get digit beyond 12 digits on real.

Binuball is correct. It is not the fault of I->R that you see roundoff errors when converting 2^41 to a real. The roundoff is caused by the limitations of reals themselves in RPL. They cannot have more than 12 mantissa digits, no matter what. No amount of System RPL or anything else can change that fact. If you need more than 12 digits of accuracy, then you MUST use some other object type than reals.

[Claudio L.]

(08-04-2021 07:42 AM)Joe Horn Wrote:  

(08-04-2021 07:18 AM)BINUBALL Wrote:  Dear cahlucas,
Unfortunately real on 50g has only 12 digit precision. So after you convert integer to real, last digit is lost. There is no way to get digit beyond 12 digits on real.

Binuball is correct. It is not the fault of I->R that you see roundoff errors when converting 2^41 to a real. The roundoff is caused by the limitations of reals themselves in RPL. They cannot have more than 12 mantissa digits, no matter what. No amount of System RPL or anything else can change that fact. If you need more than 12 digits of accuracy, then you MUST use some other object type than reals.

All of the above is correct, except that using a LongFloat library and converting the integer to a long float instead of a standard real would actually do the trick. So let's say a "certain" amount of code + external libraries might be able to do it.
I could also add the fact that newRPL does not have ANY of the limitations mentioned here. As a matter of fact, the I->R and R->I commands don't exist as they are not needed.

I guess the OP choice is to code around the problem using LongFloat, or get rid of the problem in the first place using newRPL.

[Arno K]

If you only want to do standard maths on the reals you get from those integers you can take into account the Longfloat library, FIP->Z converts from longfloat to integer and R<->F from real/integer to longfloat.
Arno

[Joe Horn]

Thanks, Claudio and Arno for your excellent suggestions about using the LongFloat library for user-adjustable accuracy. I *love* that library!

May I also suggest looking into the "ExtraFunc49+" library by Steen Schmidt. It performs many operations on integer-type objects blazingly fast, because it doesn't use the 50g's native integer math but rather uses its own math coded in C. For example, it finds the exact 5000th Fibonacci number in less than half a second (all 1045 digits of it). It returns the exact value of 1000! in 1/3 of a second. And so on. Essential for math on large integers.

[John Keith]

I like the LongFloat library as well, but it is slow. I do not know what the speed ratio would be between LongFloat and NewRPL for, say 1000-digit numbers, but I'll bet it is several orders of magnitude. If I were the OP, I would go with Claudio's suggestion.

[ttw]

Another (slow) but as exact as possible is to work with fractions. David Matula wrote some papers on this method back in the 1960s. Multiplication and division are easy but the numbers can get a bit long. Addition and subtraction are longer, A/B + C/D=(AD+BC)/(BD). In all cases, the result should be in lowest terms. In all cases, the size of the numbers gets really big.

The trick is to pick limits for numerators and denominators (these can be different for different terms in the problem even; some things may get a more precise treatment. A useful approximation is that A/B may be approximated by a sequence of fractions: a1/b1, a2/b2,...ak/bk; where the (unique) sequence of fractions satisfies: | A/B - aj/bj | < 1/bj**2

What is nice, is that there are theorems showing some long computations always remain within "nice" bounds. The system has been used to do linear algebra on fractions. In some cases, a result may be known to be an integer but floating-point computation may give zero and the rational (even with the reduction of intermediates) works well.

I've used this a bit working on problems with algebraic numbers (mostly quadratic) by keeping some of the work as symbolic (Sqrt(8)=2*Sqrt(2) with later approximation) and using continued fractions for the rest.

[cahlucas]

(08-04-2021 03:08 PM)Claudio L. Wrote:  I guess the OP choice is to code around the problem using LongFloat, or get rid of the problem in the first place using newRPL.

Dear Claudio,
What is newRPL, and where can I get it?

[BINUBALL]

(08-05-2021 04:47 AM)cahlucas Wrote:  

(08-04-2021 03:08 PM)Claudio L. Wrote:  I guess the OP choice is to code around the problem using LongFloat, or get rid of the problem in the first place using newRPL.

Dear Claudio,
What is newRPL, and where can I get it?

I recommend you to read this thread. newRPL is, shortly, new version of RPL. (But user-made)
I know Claudio can explain this well than me.

[Claudio L.]

(08-05-2021 06:42 AM)BINUBALL Wrote:  

(08-05-2021 04:47 AM)cahlucas Wrote:  Dear Claudio,
What is newRPL, and where can I get it?

I recommend you to read this thread. newRPL is, shortly, new version of RPL. (But user-made)
I know Claudio can explain this well than me.

Yes, the first post in that thread has all the links you need to know what it is, and to download and install it.
newRPL is a replacement OS for several calculator models. It gives you an RPL environment similar to a 50g (if you are familiar with the 48 series or the 50g you'll feel right at home)
Basically, it's roughly at the stage of a 48G (there's a symbolic rules engine, but not a complete CAS). There's no graphics or graphical user interface yet, but the programming part is complete, and most numeric stuff is done. If you find a command you need and it's missing let me know and we can put it in the high priority list to be implemented right away.

So it's basically the same stack and programming language you are used to, but:
* Numbers can use variable precision up to 2000 digits.
* Many of the quirks (like the integers vs. reals you found) aren't there by design.
* There's a bunch of new things that offer "quality of life" improvements over the 50g:
- A desktop version for you to use your favorite IDE for coding and simply copy/paste to test your programs, making coding quicker.
- Full support of UTF8 Unicode strings, so you can copy/pas1te from your favorite text editors
- Full support of USB comms. You can send/receive anything between the desktop and any calculator with newRPL. You can also control the remote device by sending programs to it
- Support for long file names on SD cards, and support for larger SDHC cards on the 50g.

It depends on what you are coding, it may suit your needs. If you are writing a program that needs a UI, then newRPL is not for you (yet). If you just want to write numeric routines that give you results, then it's definitely for you.