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.