BigNum on 50g possible in UserRPL?

[oliverue]

I'm a bit confused about BigNum on the 50g.

I understand there's an internal ability for arbitrary precision
integers but at the same time there's a display limit for the length
of a number to 33 columns. Is that right?

In what sense are BigNums supported on the user level, then?
Can you type "500 !" and get a BigNum result?
Can you calculate with BigNums in UserRPL? Could I see an example?

In ND1, I can compute the last digits of Graham's number (or any power
tower of 3) with code like this
\<< \-> nDigits \<<
3 \->toBig \-> three \<<
10 \->toBig nDigits POW \-> m \<<
three
1 nDigits START
three SWAP m modpow
NEXT
\->STR "..." SWAP +
\>> \>> \>> \>>

where \->toBig and modpow are special ND1 calls.

Is there a "Working with BigNums" document or manual chapter for the
50g, maybe?

Many thanks!

Oliver

[MACH]

Hi!, Oliver:

You can use in HP50G ... n^499, but ... if # n ≥ # 1000000000000 (base
10), only the 12 most significant decimal digits are preserved, in the
resulting mantissa.

Best Regards.
MACH.

[John H Meyers]

On 12/28/2010 4:46 PM, oliverue wrote:

> I'm a bit confused about BigNum on the 50g.
>
> I understand there's an internal ability for arbitrary precision
> integers but at the same time there's a display limit for the length
> of a number to 33 columns. Is that right?

No -- available memory is the only limit,
quite the same for long integers as for long strings.

Long strings or long integers can be displayed
either by scrolling or by line-wrapping
(built-in display functions scroll, but programs
can instead arrange for line wrapping).

"33 columns" is merely the number of "minifont" characters
which fit in the width of the LCD, but this no more limits
the capability of complete display by scrolling or line wrapping
than does the size or resolution of a computer monitor
or an application window.

> In what sense are BigNums supported on the user level, then?
> Can you type "500 !" and get a BigNum result?

Just about instantaneously, in my Windows emulator (Emu48),
which is of course many times faster than a real calculator,
unless set for "authentic calculator speed," which is approximately
the original slow Saturn speed (of original HP49G),
rather than ARM-emulated speed of later models.

> Can you calculate with BigNums in UserRPL?

Math functions (including MOD) are UserRPL,
so yes, of course.

Built-in CAS primality testing and factoring commands,
however, were made time-dependent and/or otherwise
not absolutely rigorous (I've forgotten some of the details),
which unfortunately can deliver misleading results.

You would have to avoid those few commands
and use proper programming of your own (or anyone else's)
to assure true results for cryptography applications, for example.

[r->] [OFF]

[oliverue]

John.

Ok, thanks a lot.

I've only ever played with HP-48, having been quite unaware of the
BigNum addition in the 49-series. I'll dig out an emulator and play
(or, indeed, buy a 50g; it's about time...).

Given the new Integer type it sounds like no explicit conversion to
BigNum is needed. I wonder about this design decision, though. I've
seen posts that recommend conversion to real to avoid speed surprises
in UserRPL. (I understand that a mode flag is all that it takes to be
always Real. But I don't particularly like bit-fiddling in programs.
My preference would be to have explicit promotion of a type via
command.)

I suppose my program above, then, would work as long as there's a
MODPOW instruction (I'm not yet seeing it in the reference manual and
the expense of a non-fused modpow--that is, separate pow and mod
commands--is much greater in this specific case.)

--O

[oliverue]

> You can use in HP50G ... n^499, but ... if # n ≥ # 1000000000000 (base
> 10), only the 12 most significant decimal digits are preserved, in the
> resulting mantissa.
>
> Best Regards.
> MACH.

Thanks.
But I can still scroll? Or set a flag and get a scrollable result?

--O

[John H Meyers]

On 12/28/2010 8:34 PM, oliverue wrote:

> Given the new Integer type it sounds like no explicit conversion to
> BigNum is needed. I wonder about this design decision, though. I've
> seen posts that recommend conversion to real to avoid speed surprises
> in UserRPL.

Only for loop counters in programs.

A "BigNum" is not normally used as a loop counter in a program, right?
(except by those "immortals" who live forever
and can afford to wait to see whether it ever halts :)

> My preference would be to have explicit promotion of a type via
> command.

Automatic acceptance and conversion of "integer" for commands expecting "real,"
explicit R->I, I->R (limited by 12-digit fixed mantissa of reals).

> I suppose my program above, then, would work as long as there's a
> MODPOW instruction (I'm not yet seeing it in the reference manual

Look for POWMOD :)

I think it's time to stop worrying and start programming ;-)

[r->] [OFF]

[George Litauszky]

I wrote a small RSA cryptography application.

Public keys: n= 299 és E= 5.
Secret key: D= 53.

Encode.
Input: Character string
Output: Encoded list of numbers
<< DUPDUP SIZE S ->
<< S 1 - 1 SWAP
FOR N
NUM SWAP TAIL DUP
NEXT
DROP NUM S ->LIST
>>
299 MODSTO 5 POWMOD
13 MODSTO
>>

Decode:
Input: Encoded list of numbers
Output: Decoded character string

<< 299 MODSTO 53 POWMOD 13 MODSTO
CHR ΣLIST >>

And I tried a power 999^999 with ZINT-s.
Run time: 39 min 49.44 sec
Digits: 29994

[oliverue]

John, POWMOD it is. Got all the pointers now I was looking for. Thanks!

[oliverue]

George,

Thanks for the example!

> And I tried a power 999^999 with ZINT-s.
> Run time: 39 min 49.44 sec

This time just for 999^999?
Can you explain the "with ZINT-s" part?

> Digits: 29994

Is this a typo? I'm seeing 2999 digits for the decimal result of
999^999.

[George Litauszky]

>Is this a typo? I'm seeing 2999 digits for the decimal result of
>999^999.

Yes it is, I'm sorry.
The correct version is: 999^9999
The digits are 29993 with the SIZE command and not 29994, I'm sorry too.

ZINT is the name of the number format: Infinite precision integer.