b3300876@rick.cs.ubc.ca (george chow) (04/30/91)
Awhile back I posted two questions about doing things in RPL. I got a bunch of
replies back. Here's a summary.
Thanks to the following for eithering following up or emailing a response:
[1] sjthomas@cup.portal.com
[2] f89-mda@nada.kth.se
[3] dcf@zodiac.phy.duke.edu
[4] rouben@math16.math.umbc.edu
[5] sburke@jarthur.Claremont.EDU
[6] @vms3.macc.wisc.edu:KAUFMAN@ETHL.DecNet
There were two suggestions for deletion:
\<<
DUP2
1 SWAP 1 - SUB
3 ROLLD
1 + OVER SIZE SUB
+
\>>
and
\<< SWAP OBJ\-> DUP DUP 3 + ROLL - 2 + ROLL DROP 1 - \->LIST \>>
The former (from [4]) is nicer in that range checking is automatic wheras the
latter (from [5]) would crap out. Alas, there seem to be no way to perform a
deletion efficiently (i.e., in place and with no conversion).
I received three responses wrt uppercase conversion. They are:
[1] rouben@math16.math.umbc.edu
[2] grue@cs.uq.oz.au
[3] bson@wheat-chex.ai.mit.edu
[1] provided a version using the NUM and CHR functions. [3] mentioned that it
would not work with different character sets. This was actually was first
attempt and it is slower than the lookup table method. [2] wrote a Saturn
routine for the conversion. The speed improvement is dramatic. So here are the
various versions.
This was my first attempt (very similar to the one from [1]) that I never posted
but was suggested:
VNUMCHR
\<<
DUP SIZE 1 SWAP
FOR i
DUP i DUP SUB NUM
IF DUP 96 > OVER 123 < AND THEN
32 - CHR i SWAP REPL
ELSE
DROP
END
NEXT
\>>
This was the first lookup table method I tried:
VTABLE1
\<<
DUP SIZE 1 SWAP
FOR i
DUP i DUP SUB
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz"
ROT POS
IF DUP THEN
DUP SUB i SWAP REPL
ELSE
DROP2
END
NEXT
\>>
This was a slightly rearranged lookup table method:
VTABLE2
\<<
DUP SIZE 1 SWAP
FOR i
"abcdefghijklmnopqrstuvwxyz"
OVER i DUP SUB POS
IF DUP THEN
i "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
ROT DUP SUB REPL
ELSE
DROP
END
NEXT
\>>
This is the Saturn version: (in ASC'd form)
"D9D20ECE81D0040D9D2075660CCD20380008FB9760147134164146819F2CECE8
AAE4D71643106AE514A9EC0331B79EAD131FD9EAE1317F9625131FF962C0310E
A6A148161CF8AF2C8F2D760142164808CB2130B2130BDE1"
I timed the three routines with the following: BM \<<
TICKS 1 10
START
"aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ"
<conversion routine>
DROP
NEXT
TICKS - NEG B\->R 8192 /
\>>
and got the following:
VNUMTABLE 29.9 sec
VTABLE1 24.0 sec
VTABLE2 23.6 sec
VML 0.133 sec
It was pointed out to me that Donneley's Toolkit has Saturn version of both of
these functions. I was aware of that and in fact intend to get that toolkit.
However, I wanted to see how far plain RPL will go.
Thanks for all the responses. Just FEI, I needed these routine for my own
address book program. (I know, I know, this is probably the n-th version
being written for the 48 but I didn't like the ones I've seen...) I'll
post mine if anyone's interested. (Maybe I'll try out the new
comp.sys.hp48 group when it becomes official.)
George grue@cs.uq.oz.au (Frobozz) (04/30/91)
In <1991Apr29.174413.5473@rick.cs.ubc.ca> b3300876@rick.cs.ubc.ca (george chow) writes: >Awhile back I posted two questions about doing things in RPL. I got a bunch of >replies back. Here's a summary. >and got the following: > VNUMTABLE 29.9 sec > VTABLE1 24.0 sec > VTABLE2 23.6 sec > VML 0.133 sec Gee, I didn't realise that my routine was that much faster, I never tested it that way. I just put the string on the stack and timed it on my watch and got my estimated timings (<1 second pretty much reguardless of string length :-) >It was pointed out to me that Donneley's Toolkit has Saturn version of both of >these functions. I was aware of that and in fact intend to get that toolkit. >However, I wanted to see how far plain RPL will go. >Thanks for all the responses. Just FEI, I needed these routine for my own >address book program. (I know, I know, this is probably the n-th version >being written for the 48 but I didn't like the ones I've seen...) I'll >post mine if anyone's interested. (Maybe I'll try out the new >comp.sys.hp48 group when it becomes official.) Go ahead and write it, and even post it. Nobody is going to get hurt by it and some people may gain some benefit. I know that I haven't found an address book program that I like much. I have other projects that comsume a lot of my time, if I didn't I'd write such a program (I may eventually anyway). If you do write this and intend to post it to the world at large, could you please avoid using rountines from Donneley's Toolkit. It isn't that the toolkit is bad, I am sure it isn't. It is just that some people do not own the toolkit (I don't and even though I will eventually buy it, I will avoid using its functions in code I write, that I intend to post). Writing your own version of the routines that you need is always possible, you just have to say that the Toolkit contains a faster version of this routine etc etc. Pauli seeya Paul Dale | Internet/CSnet: grue@cs.uq.oz.au Dept of Computer Science| Bitnet: grue%cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@cs.uq.oz | UUCP: uunet!munnari!cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@cs.uq.oz.au --
diamant@hpfcbig.SDE.HP.COM (John Diamant) (05/04/91)
george chow (b3300876@rick.cs.ubc.ca) writes: > and got the following: > VNUMTABLE 29.9 sec > VTABLE1 24.0 sec > VTABLE2 23.6 sec > VML 0.133 sec This is great. The VML routine sounds like it makes this sort of thing practical for large searches (the other ones are all out of the question for a search of a phone directory). > Thanks for all the responses. Just FEI, I needed these routine for my own > address book program. (I know, I know, this is probably the n-th version > being written for the 48 but I didn't like the ones I've seen...) The one I use is a general database program called DB by Ross Barnes. Except for the slow search times and fact that it doesn't alphabetize, I'm pretty happy with it. I did modify it to only search the first field (assuming it's the key) rather than all fields when finding a listing (this has the name in an address book database and is usually what you're searching for). I'll probably add the VML uppercasing routing since it shouldn't affect performance very much. Anyway, I'd be curious to know what it is you don't like about any of the existing address book programs. Please post your thoughts on what you would like to see different in them. John Diamant Software Engineering Systems Division Hewlett Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hpfcla,hplabs}!hpfclp!diamant This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.