30b missing the mod function?

[hugh steers]

Hi,

Does the 30b have a MOD function, i cant find it? If missing, presumably this would be easy to add to the ROM.

NOTE: i know there is IP and FP, but these are not quite the same. i want to perform A * 10^k mod M, eg with k = 12 and A a 12 digit number. usually MOD is able to do this.

any thoughts?

[Don Shepherd]

Hugh, the 30b doesn't have a mod function. The following snippet will do it, however: / ans(lastx) swap fp(math up) = x

Don

[hugh steers]

thanks for your idea but unfortunately this wont always work.

for example 12345678 EEX 12 mod 7 (correct answer 2)

this works on HPs with the MOD function because it can deal with the 12 zeros in a clever way. unfortunately, this is exactly what i need for my algorithm!

[Don Shepherd]

Yeah, I see what you mean. I tried it on my 33s and it worked.

Don

[Dave Britten]

This raises an interesting question: what is the algorithm behind the built-in MOD function present on various models? I searched around Google for a bit, but didn't find any that looked promising.

[cyrille de Brébisson]

hello,

it's a division, but without calculating the actual division value and stopping once before decimal point occur...

really simple....

regards, cyrille

[Don Shepherd]

Cyrille, simple enough to fit in .....

:)

Don

[hugh steers]

request seconded!

However, there is a problem with moving and adding things to the menus. presumably this would go on the math menu; after ABS maybe. But this practice will break people's programs who are performing MATH menu UP or DOWN commands.

I have a quick suggestion before things start to go bad. maybe HP should promise to only add things to the *end* of menus and people writing program macros always emit key sequences to go _down_ the list and never to trail up a list, otherwise the counts could change and things go bad.

actually, the operation i really want from a calculator is the following:

mulmod(a,b,M) = a*b mod M

with no loss of precision when a, b, and M are 12 digits of mantissa.

alternatively, the implementation of a fused multiply add (FMA), so

FMA(a,b,c) = a*b + c. without loss of precision where possible.

in floating point, then, code mulmod in terms of this as:

q = IP(a*b/M)

r = FMA(a,b,-q*M)

return r

right now, im having a problem with squares. A^2 - B overflows and i lose accuracy (think of A and B as 12 digit mantissas). causes my program to fail sometimes. unfortunately, its not fixable without some kind of extra precision. FMA would fix it, but so could the MOD function (given some hassle).

i started asking myself why, all of a sudden, i am having these problems with the 30b and not older models. the answer is that the other models are too slow to get this far. i've been writing some factorization programs and both (2 different) algorithms have failed as the numbers get close to 12 digits.

but actually, this is what we're going to get, in the absence of any extra precision helper functions. do the older calculators factor 12 digit numbers, and if so, how (apart from trial division!)

so my conclusion is that the 30b (and presumably future models with program capability) have reached the stage where their performance warrants several new numerical primitives in order to really exploit their ability for scientific and engineering applications.

interesting.

[Katie Wasserman]

Hugh,

I agree that adding built-in functions to the 30b is problematic because of the menu navigation needed. Adding functions to the end of the menu items creates its own set of problems since you then have to potentially have many DOWN steps eating up what little program memory there is. However, there are some keystroke combinations that currently exist but don't really do anything useful and could be used for "special" added functions. These are: [STO/RCL] [+,/,*,-] [=]. [RCL] [=] recalls the value of the last menu item, I think that the other commands are waiting for their creator to assign a purpose to them. Because these commands don't do anything, it's hard to realize they exist, but in program mode you'll seem them.

-Katie

[hugh steers]

hey, yes RCL = does recall the last menu. useful. and the others can be programmed, as you say.

how about having a (single digit) number, n, pressed immediately after menu navigate to the `n'th item. this would fix the problem of new additions and the extended UP or DOWN required.

also, whilst we're in request mode :-) ...

more registers!!! i can only find 10, are there more? like .0 etc.

how about .0 through .9 are local to a subroutine! ie "call" pushes them and "rtn" pops them back.

[Katie Wasserman]

There are the 100 indirect registers, of course. You access them with [STO/RCL] [Data/CshFl] and use register 0 as the pointer.

I don't know if there are 8 or 10 bytes per register but there's no memory left. 100 indirect registers + 10 basic ones + 15 stack (mostly in ALG/Chain mode) + many used in the built-in menus + 290 byes of program memory take up all of the 2K of non-volatile RAM.

-Katie

[hugh steers]

Thanks. it would be nice to have a shorter way of accessing those 100 cashflow registers in a program - even if that meant overlapping. ie you can't do both at the same time.

[Bart (UK)]

Katie,

From your description I deduce that the 100 indirect registers are independent of program memory? (Unlike e.g. the 35s where using indirect registers reduces program memory).

I think this is a pity as although it's nice to know that you have these registers over and above programs, I don't see myself making use of more than a dozen and rather have 1k of program memory. (I hardly use them on the 35s).

[Don Shepherd]

Quote:

---

the 100 indirect registers are independent of program memory

---

That is true, unfortunately. The indirect registers are also independent from the 10 standard registers, 0-9. There is no way to get > 290 bytes for program lines. The indirect registers share the same space with cash flow/stats data only, and you cannot get more than 290 bytes of program line space.

[Gene Wright]

Keep in mind that these are statistics / cash flow registers.

Their use as indirect registers is a secondary use.

[Bart (UK)]

Ok, I'm sort of starting to form a picture of the layout of the program/working memory. Thus the indirect registers need to be separate (otherwise using cash flow/stats formulas would overwrite programs). One would have to keep in mind then that using indirect registers will overwrite cash flow/stats data. I assume the manual will explain which registers are used for what data.


edit: i.e. so you could use your own program to manipulate the data further as required.

Edited: 19 Jan 2010, 7:37 a.m.

[Don Shepherd]

Gene is right, the 100 registers are really for stat data and cash flow data. Cash flows and stat data share that space, I believe, and the allocation of the 100 registers between stat data and cash flow data is automatic. You could have 30 x/y pairs of stat data and 20 amt/freq pairs of cash flows, and the system keeps track of what you've got. And you can reference (or over-write) that data via indirect addressing in your program if you want.

But you can't use that space for program lines.

[Patrice]

Hello,

Did you investigated about transforming you problem to avoid floating point loss of precision?

if I understand well your problem, you have:

Quote:

---

mulmod(a,b,M) = a*b mod M

---

which I would rewrite as:

mulmod(a,b,M) = (a*b) mod M

I would transform this as :

mulmod(a,b,M) = ((a mod M) *(b mod M)) mod M

which will not overflow

Patrice

[hugh steers]

unfortunately a and b are already < M.

eg let a = 16777331, b = 453320069

what is a*b (mod 1071514531)

All these numbers fit just fine on the calculator, and so does the answer.

[Katie Wasserman]

I don't think you'll be able to do this easily on the 30b, it sure would be nice to have a remainder function. I wish all calculators had that but surprisingly few do.