cloos@acsu.buffalo.edu (James H. Cloos) (05/04/91)
First of all, I would like to say to HP R&D: don't take this as a knock to your efforts on the Eqn Card, but I though that the net would like to know this info: I did a comparison the otehr day of how much memory the GROBs in the Equation Library used both in their current storage method, and if they were compressed with PGROB. For those readers who were not at the CHIP confrence a the Summer CES last June, and haven't seen a copy of the video of it, the GROBs are stored as a list of 2 short integers and a GROB representing the ``interesting'' part of the final product. (Ie., the GROB you see displayed, minus the whitespace frame around it.) They saved a considerable amount of space by doing this. (See below.) I was curious though, how much memory would be consumed by just runing PGROB on the full-screen-sized GROBs. I put the 63 lists on the stack, and this small program to covert these lists to 131x64 GROBs, exactly as they appear on the display, PGROB them, and run BYTES on that, dropping the crc: \<< 1 63 START LIST\-> DROP ROT SB\->R ROT SB\->R R\->PX #131d #64d BLANK SWAP ROT REPL PGROB BYTES SWAP DROP 63 ROLLD NEXT \>> SB\->R takes a short and returns a real. The ASC'ed string looks like: "D9D20ECE8152140FBD81B21301E1A" R\->PX is from Donnelly's TLLIB, and in userlang would look something like: \<< SWAP R\->B SWAP R\->B 2 \->LIST \>> The end result is this: FULL_SIZED_GROBS AS_IN_THE_EQN_CARD USING_PGROB ---------------- ------------------ ----------- 69174 29427 23292.5 By my calculations, having UPGROB as an unnamed XLIB would cost 124.5 bytes for the CODE object itself, plus 2.5 bytes for an entry in a link table. The total savings of using the present method over PGROB would then be 6007.5 bytes. With that amount of ROM left over, they could have added cash flow support to the FIN library (hint, hint)! ;^) Also, my experiences with UPGROB suggest that the speed tradeoff of creating a blank 131x64 GROB, breaking up the list, and doing a REPL vs. having to UPGROB a hex-string would not be noticable. (I've a 256x256 GROB that compresses into 12310 nybbles of information; it takes .475 seconds to uncompress, rounded to the nearest 1000th of a second.) Again, I hope that the R&D people don't take this negatively, but I thought it would be useful to post. It shows just what kind of power it is capable of, ja? Happy coding! -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <> P.S. I just picked up a 32S-II. Can anyone say of Wickes' _Transitions_ would be of any use in helping an RPL programmer get comfortable with RPN programming?