as the one or other in this newsgroup may know, there is a "quick and
dirty" benchmark for "measuring" both speed, and precision of any kind of
computer called after the autor "Savage-Test". It was first published in
the special IBM issue of Byte magazine in 1985 (vol. 10, No. 11,
page 67). After that this test found a farther audience through an
article in "Sky & Telescope (March, 1987, page 309) by (today Col. Dr.)
T.S. Kelso.
Basically, this test starts with a real a=1 loops 2499 times over
a=tan(atn(exp(ln(sqrt(a*a)))))+1, which in theory gives the answer
2500. Stopping the time for this test gives an idea about processing
speed (especially for transcendental functions), and comparing the
relative error (a_final-2500)/2500 says something about the builtin
precision (again especially for transcendental functions).
Now here come my results (HP49G in approximate mode):
calculator digits language rel. error time
HP49G 12 UsrRPL -2.054E-7 120s
HP49G 12 SysRPL -2.054E-7 96s
HP49G 15 SysRPL -3.572E-9 138s
TI-86 14 TI-Basic -3.081E-9 433s
TI-86 14 Z80-Assembler -3.081E-9 328s
The HP49G uses a 4MHz Saturn, whereas the TI-86 has a 6MHz Z80.
-------------------------------------------------------------------------
Ralf Fritzsch
Bundesanstalt fuer Wasserbau Federal Waterways Engineering and Research
Dienststelle Kueste Institute - Department Hamburg
-------------------------------------------------------------------------
Unix _IS_ user friendly - it's just selective about who its friends are.
-------------------------------------------------------------------------
The SysRPL 12-Digit test only needs 84.64s with the display turned off
(according to TEVAL). This is nearly 12% less. What about turning it off
automatically/flag-controlled for time-consuming CAS commands like RISCH
or even SOLVE?
But how did you implement it using long reals? I can't find a %%ATAN
function...
Thomas
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT/M d- s+: a--- C+++ UL++++ P+++ L++>+++
E?>+ W++ N++ o K w--- O? M? VMS? PS+ PE-
Y+ PGP+ !tv b++ D- G e+ h! r-- x?
------END GEEK CODE BLOCK------
Interesting..., I had no idea that Col Kelso was involved in any calculator
benchmarks. He is now the Vice-Commandant of the United States Air Force
Institute of Technology (where I'm a graduate student right now...)
AL
TI-92+ 14 TI-Basic -3.081e-9 255s
TI-92+ 14 TI-ASM (BCD) -3.081e-9 72s
Unfortunately binary ASM for TI-92+ does not exist yet.
TI-92+ uses Motorola 68000 10MHz
> Ralf Fritzsch
> Bundesanstalt fuer Wasserbau Federal Waterways Engineering and Research
> Dienststelle Kueste Institute - Department Hamburg
> -------------------------------------------------------------------------
> Unix _IS_ user friendly - it's just selective about who its friends are.
> -------------------------------------------------------------------------
--
+-------------------------------------------------------+
| Anna i Jacek Marchel |
| |
| e-mail: mar...@home.com |
| WWW: http://members.home.net/marchel/ |
+-------------------------------------------------------+
I get
115s
93s
(no %%ATAN?)
respectively. Too bad it's not operations that can be done with bints :-)
Regards
Steen
>Ralf Fritzsch wrote:
>>
>> Now here come my results (HP49G in approximate mode):
>>
>> calculator digits language rel. error time
>> HP49G 12 UsrRPL -2.054E-7 120s
>> HP49G 12 SysRPL -2.054E-7 96s
>> HP49G 15 SysRPL -3.572E-9 138s
>> TI-86 14 TI-Basic -3.081E-9 433s
>> TI-86 14 Z80-Assembler -3.081E-9 328s
>>
>> The HP49G uses a 4MHz Saturn, whereas the TI-86 has a 6MHz Z80.
>> -------------------------------------------------------------------------
>
> TI-92+ 14 TI-Basic -3.081e-9 255s
> TI-92+ 14 TI-ASM (BCD) -3.081e-9 72s
>
>Unfortunately binary ASM for TI-92+ does not exist yet.
>TI-92+ uses Motorola 68000 10MHz
Here are my results according to TIM of the Hack library:
HP48GX 15 Saturn ASM -3.572e-9 70s
*HP48GX 15 Saturn ASM -3.572e-9 61.5s
* The display and keyboard scanning were turned off for this test.
( The clock speed on my machine was around 3.92MHz. Also note that
these tests was conducted in radian mode. )
Looks like the HP is the winner ( at least in the BCD case ).
And here is the code for your reference ( Jazz syntax ):
CODE
speedup EQU 0
SQRTF EQU #2B9F3
LNF EQU #2B698
EXPF EQU #2B6AA
ATANF EQU #2B6FB
TANF EQU #2B6F2
GETANGMODE EQU #2AEF6
PUSH%%LOOP EQU #2A235
GOSBVL =SAVPTR
IF speedup
GOSBVL =DispOff
INTOFF
ENDIF
A=0 W
B=0 W
P= 14
B=B+1 P
P= 0
LC(5) #2498
R4=C.F A
GOSBVL GETANGMODE
SETDEC
- C=B W
D=C W
C=A W
GOSBVL =MULTF
GOSBVL SQRTF
GOSBVL LNF
GOSBVL EXPF
GOSBVL ATANF
GOSBVL TANF
C=0 W
D=0 W
P= 14
D=D+1 P
GOSBVL =RADDF
C=R4.F A
C=C-1 A
R4=C.F A
GONC -
IF speedup
GOSBVL =DispOn
INTON
ENDIF
GOVLNG PUSH%%LOOP
ENDCODE
----------------------------------------------------------------------------------
Jonathan Busby - <jdb@UH!ESPRLhouston.rr.com>
Remove the random permutation of "HPRULES!" from my e-mail address
before replying.
I did it that way:
%%1
SWAP
DUP
%%*
%%1
%%+
%%SQRT
%%/
%%ACOSRAD
since arctan(x)=arccos(1/sqrt(1+x^2))
Anyone out there with a more clever idea?
>In article <3AB8A372...@iname.com>, t.r...@iname.com says...
>>...
>>But how did you implement it using long reals? I can't find a %%ATAN
>>function...
>>...
>
>I did it that way:
>
>%%1
>SWAP
>DUP
>%%*
>%%1
>%%+
>%%SQRT
>%%/
>%%ACOSRAD
>
>since arctan(x)=arccos(1/sqrt(1+x^2))
>
>Anyone out there with a more clever idea?
With a little assembly we can do it smaller and faster. Here is a
version for the 48:
CODE
POP1%% EQU #2A060
GETANGMODE EQU #2AEF6
ATANF EQU #2B6FB
PUSH%%LOOP EQU #2A235
GOSBVL POP1%%
GOSBVL GETANGMODE
GOSBVL ATANF
GOVLNG PUSH%%LOOP
ENDCODE
Note that this version reads the current angle mode and acts
accordingly.
> On 22 Mar 2001 05:16:59 GMT, Frit...@Hamburg.BAW.DE (Ralf Fritzsch)
> wrote:
>
> >In article <3AB8A372...@iname.com>, t.r...@iname.com says...
> >>...
> >>But how did you implement it using long reals? I can't find a %%ATAN
> >>function...
> >>...
> >
> >since arctan(x)=arccos(1/sqrt(1+x^2))
But only for positive x.
For negative x, arctan(x) = -arccos(1/sqrt(1+x^2))
And for all real x, arctan(x)=arcsin(x/sqrt(1+x^2))
Of course you are right, but:
1<=x<=2500+little error, so x IS always positive during Savage Test.
Cheers
Dave Scott
TI81
basic 345s -2.04E-7
HP48G+speedup
userRPL
135s -2.05E-7
H48G
userRPL 168s -2.05E-7
TI92+ approx basic 207s -3.08E-9
TI92+ exaxt basic 1402s 0
Why do I get 2.05E-7 on the HP48G instead of 4E-7?
It's not true in general, but at least for the Savage test. The reason is
the different internal representation for REALs; HP's UsrRPL yields 12
digits precision, all of which are showed in the display, whereas the TI
has 14 digits precision, of which 12 digits are shown. It's clear that
the results are more precise if you carry more digits.
OTOH, programming in HP's SysRPL gives you 15 digits precision - and now
comes the real interesting fact: TI's result with 14 digits is more
precise than HP's with 15 digits. Maybe this comes from the fact that TI
uses binary coded decimals (BCD) for representing reals?? This would be
true if you only do N floating point adds with REALs having no more than
14-log(N) digits, since the result in this case would be exact (no
rounding through decimal <-> binary conversions). But in our case the
most work is done with transcendental functions - it seems that in the
average they are more precise implemented on TI than on HP.
Hope that helps,
> In article <20010324221144...@ng-fx1.aol.com>, dscot...@aol.com says...
> >
> >It seems the TIs are 100 times more accurate that the HP. 2E-7 versus 3E-9. Is
> >this true? What would limit the accuracy of an HP-49?
> >...
>
> It's not true in general, but at least for the Savage test. The reason is
> the different internal representation for REALs; HP's UsrRPL yields 12
> digits precision, all of which are showed in the display, whereas the TI
> has 14 digits precision, of which 12 digits are shown. It's clear that
> the results are more precise if you carry more digits.
> OTOH, programming in HP's SysRPL gives you 15 digits precision - and now
> comes the real interesting fact: TI's result with 14 digits is more
> precise than HP's with 15 digits.
This is where you are incorrect. Although I might like to believe that
the implementation is more precise in TI calcs than in HP calcs, probably
the real reason that this particular test was more accurate is because
assembly programming and C programming both make use of 16-digit internal
BCD reals, not 14. Reals are 10 bytes long: 8 bytes (16-digits) for the
mantissa, and 2 bytes for the exponent.
I think that I'm nevertheless correct ;-)
Regarding to Assembly Studio 8x documentation about OP registers, the ten
bytes of a TI REAL are spended as follows:
first byte: sign byte: Bit 0 = 0 if real, 1 if complex
Bits 1-6 = 0
Bit 7 = 0 if positive, 1 if negative
next two bytes: biased exponent
remaining seven bytes: mantissa in BCD format, thus giving only 14 digits.
By the way, differing from HP's approach (additional precision for the
SysRPL extended (or long) reals), TI Assembly language gives no
additional precision over TI Basic (and thus the same results for both
TI Basic, and TI Assembly Savage test).
Greetings from Hamburg,