D-79
===
Subject: Re: HP49G+ (48?) Documentation
Last week a birdy told me that HP will be publishing an AUR for the 49G+.
No word when it will be released.
: It's obvious the 49G+ user's guide doesn't owe much to HP:  too many
typos,
: misplaced apostrophes, etc, and it's difficult for me to take my pc to
bed
: with me. I would really like a good book on the 49, or even the 48 if
: experts think it's worthwhile.
===
Subject: Re: Is MetaKernel 2.30 actually MetaKernel 2.29?
Ok nevermind. I found the answers to my own questions after some
searching. I guess Mk2.30 is indeed MK2.29 and that editing an array
does cause warmstarts (and to my knowledge this was not fixed). It
appears that the elements of the array somehow get altered during the
decompile. *sigh*
===
Subject: Re: IDN and Exact Mode
SIZE returns a list of reals regardless of the exact/approx flag. Try using
Bob
===
Subject: Re: Thinning the calculator herd
Ok, the two cards are sold so I have a HP48GX in perfect working condition
to sell. $125 shipped in CONUS. The HP49G+ is also still for sale for $50
shipped in CONUS.
Best,
-Al
--
Vote for Pedro
===
Subject: Re: Auto-Erase
Hello !
Are you developing a userRPL virus ?
(just a thought)
manjo

===
Subject: Re: HP49G+ (48?) Documentation
I hope they put it out in hard copy. Either way, any documentation aside
from the manual that shipped with the 49G+ is helpful. Now, if only HP
would fix the keypad problem and give me a larger ENTER key...
I can dream, can't I?
John
===
Subject: Re: Is MetaKernel 2.30 actually MetaKernel 2.29?
I just checked -- you in fact don't need the entries table stored in
port 0 and the problems still exist. Also, all MK flags can be set to
default. I'm pretty sure it is a bug either in the decompiler. Take
that same matrix produced by the program and simply edit it (via
command line and not matrix editor). You'll probably notice some
corruption in the entries. It doesn't even matter if you press [ON] to
cancel your editing.
I managed to cause a memory clear by changing the size of the matrix to
{ 7 9 }. This seems like a serious problem if you intend to work with
large data sets stored in arrays. For now, I'm putting MK on the
'tinker-only' list (used only for tinkering and bug hunting).
===
Subject: Re: 49G+ Equation Library SOLV & Flag 117
Where did you get that the source code wasn't available anymore ?
There has been work done so it worked on the 49g (like working with the
new Equation Writer etc..)
Jean-Yves
===
Subject: Re: RREFMOD
Wow,
This is the first time ever I hear someone using my lib. It should be
an error.
Hope you like it
Luis
===
Subject: Re: RREFMOD
format=flowed;
reply-type=original
The library is very useful and I use it frequently.
To Mr. Adder
If you don't want to use CMtx49,
the correctness of the result I show can be checked by built-in commands
RCI, RCIJ, INVMOD etc.
===
Subject: Re: RREFMOD
The thing is, this particular matrix is just a test case for a program
I have written and I know that the answer you gave is correct in this
case. What I don't know is why did RREFMOD give the answer it did and I
don't know what other failure modes it has, so I don't feel happy using
it in my own program at the moment. So I may have to base my program on
something else, possibly CMtx49.
Adder
===
Subject: Re: RREFMOD
format=flowed;
reply-type=original
I see.
One way to check RREFMOD may be confirming the outputs of
RREFMOD for many random matrices or special matrices
by using RCI, RCIJ, INVMOD etc.
Many softwares suppose to be checked like that.
Another way may be to read the source file of CAS of HP-49G.
This can  be downloaded from
http://www.hpcalc.org/details.php?id=5997
Matsubara

===
Subject: Re: RREFMOD
For that link, I thank you greatly! I have been trying to disassemble
RREFMOD using Jazz without much success, now I don't have to.
Adder
===
Subject: Re: HP49G, hard to print pdfs
I use a laser
===
Subject: Re: convolution for 49g+ ?
OK
I C
Well, then it's better to always use ARM for !
since small factorials has never been a speed problem 4 me
===
Subject: Re: convolution for 49g+ ?
I agree - for most purposes it wouldn't be a problem if 50! takes a few
ms more or less.
Steen
===
Subject: Re: convolution for 49g+ ?
If the coefficients are reals or integers it might be. I doubt it if
the coefficients are algebraic objects (how would you in C multiply two
HP algebraic objects and simplify the result, without partially
implementing your own CAS?). But HPGCC can't take a list of the stack
yet (IIRC) - it'll have to be exploded and popped one item at a time,
or converted into a string and handled proprietary in C - both
approaches using SysRPL first and creating overhead.
That's what I meant by sensible input. It's not that common, I should
think, to manipulate 200-degree polynomials on a calculator.
But why don't someone try it out? Sometimes the real world surprise us
:-)
Steen
===
Subject: Re: convolution for 49g+ ?
what I had in mind was convoluting arrays of ~100 to ~500 elements.
===
Subject: Re: convolution for 49g+ ?
Well, if it's possible on a calc without too much fuss, it'd be
possible on the 49G+.
Steen
===
Subject: Re: updating the 49g+ to rev 2.0
connectivity files and will try the upgrade shortly.
Randy
===
Subject: NIPUNA for the HP49g+
Check out
http://www.greengurus.com/software/Nipuna.html
Any interest?
Haven't looked at HP website for a while. Does anyone know if HP has built

an overhead prjector for the HP49g+?
Walt.
===
Subject: Re: HP49G/G+ Vs Palm
Problems with the 49G+ keyboard aside, I personally prefer a real
calculator over an emulator on a Palm any day. I own a Tungsten C with
a built-in keyboard and I love it for what it was designed for.
However, nothing beats the convenience of a calculator for quick math
problems (and answers).
On a side note, this thread is quickly deteriorating into one of those
religious questions. Calm yourselves, people.
John