Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!bionet!arisia!roo!boehm
From: boehm@parc.xerox.com (Hans Boehm)
Newsgroups: comp.benchmarks
Subject: Re: More issues of benchmarking
Message-ID: <658@roo.UUCP>
Date: 6 Dec 90 01:48:36 GMT
References: <7601@eos.arc.nasa.gov> <23410001@misty.boeing.com> <4092@dftsrv.gsfc.nasa.gov>
Sender: news@parc.xerox.com
Lines: 31

In article <4092@dftsrv.gsfc.nasa.gov> buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) writes:

>but a more interesting test would be the following:

>echo 2.1^5000/2^5000 | /bin/time bc
>8840877025741739372995278738276746897465471931986497903162598183670954\
>192449780889302845715668915405005692

>real     2:17.9
>user     2:12.6
>sys         1.5

>which is non-trivial and should give Maple, and other similar programs
>a workout as well.

>B Cing U

>Buck


It's still the case though that different evaluation strategies lead to widely
differing results.  Our calculator, which does ``exact'' real arithmetic with
demand driven evaluation (and thus potentially a lot more work) takes 520 secs
on a SS-1 to compute the result to about 30 digits to the right of the decimal
point.  (This is largely because I have to ask it to compute (2.1^5000) to the
same precision.  The number might be much smaller with a bc like interface.)
However, it computes (2.1/2.0)^5000 to the same precision in 0.6 secs.  It
does this by computing a log and an exponential to the right precision.  I dont
know what dc does.

Hans


Brought to you by Super Global Mega Corp .com