Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #2682 > unrolled thread

Calculator Accuracy

Back to article view | Back to comp.misc

Contents

  Calculator Accuracy Gordon Henderson <gordon+usenet@drogon.net> - 2014-05-08 07:00 +0000
    Re: Calculator Accuracy David Hume <David.Hume@example.com> - 2014-05-08 08:39 +0100
    Re: Calculator Accuracy Andy Burns <usenet.feb2014@adslpipe.co.uk> - 2014-05-08 09:14 +0100
      Re: Calculator Accuracy Andy Burns <usenet.feb2014@adslpipe.co.uk> - 2014-05-12 19:02 +0100
    Re: Calculator Accuracy "BartC" <bc@freeuk.com> - 2014-05-08 09:43 +0100
      Re: Calculator Accuracy Tim Streater <timstreater@greenbee.net> - 2014-05-08 09:53 +0100
        Re: Calculator Accuracy "BartC" <bc@freeuk.com> - 2014-05-08 10:22 +0100
          Re: Calculator Accuracy David Hume <David.Hume@example.com> - 2014-05-08 12:17 +0100
            Re: Calculator Accuracy RS Wood <rsw@therandymon.com> - 2014-05-08 14:09 +0000
              Re: Calculator Accuracy David Hume <David.Hume@example.com> - 2014-05-08 16:04 +0100
              Re: Calculator Accuracy Rich <rich@example.com> - 2014-05-08 16:49 +0000
                Re: Calculator Accuracy Rich <rich@example.com> - 2014-05-09 00:03 +0000
              Re: Calculator Accuracy Rich <rich@example.com> - 2014-05-09 00:10 +0000
                Re: Calculator Accuracy RS Wood <rsw@therandymon.com> - 2014-05-09 21:32 +0000
                  Re: Calculator Accuracy Rich <rich@example.com> - 2014-05-10 03:30 +0000
              Re: Calculator Accuracy "G. Paul Ziemba" <paul+usenet@w6yx.stanford.edu> - 2014-05-09 03:43 +0000
      Re: Calculator Accuracy David Hume <David.Hume@example.com> - 2014-05-08 10:55 +0100
        Re: Calculator Accuracy "BartC" <bc@freeuk.com> - 2014-05-08 11:23 +0100
        Re: Calculator Accuracy Hils <hils@saynotospam.net> - 2014-05-08 12:09 +0100
          Re: Calculator Accuracy Hils <hils@saynotospam.net> - 2014-05-08 23:02 +0100
            Re: Calculator Accuracy Marc Auslander <marcslists@gmail.NOSPAM.com> - 2014-05-08 19:51 -0400
              Re: Calculator Accuracy Will Honea <whonea@whonea.net> - 2014-05-08 18:19 -0600
          Re: Calculator Accuracy Eric Pozharski <whynot@pozharski.name> - 2014-05-09 15:19 +0300
            Re: Calculator Accuracy David Hume <David.Hume@example.com> - 2014-05-09 19:06 +0100
              Re: Calculator Accuracy Eric Pozharski <whynot@pozharski.name> - 2014-05-10 08:38 +0300
                Re: Calculator Accuracy Eric Pozharski <whynot@pozharski.name> - 2014-05-12 09:30 +0300
            Re: Calculator Accuracy David Hume <David.Hume@example.com> - 2014-05-10 00:00 +0100
        Re: Calculator Accuracy Rich <rich@example.com> - 2014-05-08 11:40 +0000
    Re: Calculator Accuracy Rich <rich@example.com> - 2014-05-08 11:32 +0000
    Re: Calculator Accuracy Anssi Saari <as@sci.fi> - 2014-05-08 20:20 +0300
      Re: Calculator Accuracy Gordon Henderson <gordon+usenet@drogon.net> - 2014-05-08 17:40 +0000
        Re: Calculator Accuracy David Hume <David.Hume@example.com> - 2014-05-09 08:43 +0100
          Re: Calculator Accuracy Rich <rich@example.com> - 2014-05-09 10:42 +0000
          Re: Calculator Accuracy Whiskers <catwheezel@operamail.com> - 2014-05-09 21:56 +0100
        Re: Calculator Accuracy Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2014-05-12 13:50 +0100
    Re: Calculator Accuracy Caecilius <nospam@spamless.invalid> - 2014-05-08 19:34 +0100
    Re: Calculator Accuracy Caecilius <nospam@spamless.invalid> - 2014-05-08 19:38 +0100
      Re: Calculator Accuracy Hils <hils@saynotospam.net> - 2014-05-08 22:06 +0100
    Re: Calculator Accuracy Paul Sture <nospam@sture.ch> - 2014-05-10 21:24 +0200
    Re: Calculator Accuracy Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-11 16:22 +0000
      Re: Calculator Accuracy Will Honea <whonea@whonea.net> - 2014-05-11 15:41 -0600
        Re: Calculator Accuracy Tim Streater <timstreater@greenbee.net> - 2014-05-11 23:02 +0100
    Re: Calculator Accuracy David Harmon <source@netcom.com> - 2014-05-12 18:20 -0700
    Re: Calculator Accuracy Yeechang Lee <ylee@pobox.com> - 2014-07-25 20:26 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#2715

Windows Calculator on Win 7 64 bit - 8.5254109580232404296378982169825e-33

[toc] | [prev] | [next] | [standalone]

#2717

Marc Auslander wrote:

> Windows Calculator on Win 7 64 bit - 8.5254109580232404296378982169825e-33

Don't forget that pi is an irrational number so register length will affect 
the error bound - and even an infinite register length will still be only an 
approximation.

-- 
Will Honea

[toc] | [prev] | [next] | [standalone]

#2727

with <lkfom3$7ui$1@speranza.aioe.org> Hils wrote:

*SKIP*
> R version 3.1.0:
>
> asin(acos(atan(tan(cos(sin(45*pi/180))))))*180/pi-45
> [1] -7.105427e-15
>
> Gnuplot 4.6:
>
> print asin(acos(atan(tan(cos(sin(45*pi/180))))))*180/pi-45
> -7.105427357601e-15
>
> I'm guessing a common library at work here...

libc, maybe:

	% perl -MMath::Trig -wle '
	print rad2deg( asin acos atan tan cos sin deg2rad 45 ) - 45'
	7.105427357601e-15

Math::BigFloat looks promising (if I would mind to compete with windopws
calculator), however resourceful.  But it's a way too much hassle for
now -- it doesn't have btan() and bacos() methods, so those must be
constructed in place.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#2728

Eric Pozharski <whynot@pozharski.name> writes:

> with <lkfom3$7ui$1@speranza.aioe.org> Hils wrote:
>
> *SKIP*
>> R version 3.1.0:
>>
>> asin(acos(atan(tan(cos(sin(45*pi/180))))))*180/pi-45
>> [1] -7.105427e-15
>>
>> Gnuplot 4.6:
>>
>> print asin(acos(atan(tan(cos(sin(45*pi/180))))))*180/pi-45
>> -7.105427357601e-15
>>
>> I'm guessing a common library at work here...
>
> libc, maybe:
>
> 	% perl -MMath::Trig -wle '
> 	print rad2deg( asin acos atan tan cos sin deg2rad 45 ) - 45'
> 	7.105427357601e-15
>

These aren't the same tests as having the calculator in degrees mode,
because in these tests when the result of sine is passed to cosine it is
treated as radians.

[toc] | [prev] | [next] | [standalone]

#2733

with <7zwqduj07r.fsf@example.com> David Hume wrote:
> Eric Pozharski <whynot@pozharski.name> writes:
>> with <lkfom3$7ui$1@speranza.aioe.org> Hils wrote:

>>> [1] -7.105427e-15

Blame Hils, not me.

*SKIP*
>> libc, maybe:
>> 	% perl -MMath::Trig -wle '
>> 	print rad2deg( asin acos atan tan cos sin deg2rad 45 ) - 45'
>> 	7.105427357601e-15
> These aren't the same tests as having the calculator in degrees mode,
> because in these tests when the result of sine is passed to cosine it
> is treated as radians.

Then -- Viva Radians!

	% perl -MMath::Trig -wle '
	sub x_sin { sin deg2rad shift };
	sub x_asin { rad2deg asin shift };
	sub x_cos { cos deg2rad shift };
	sub x_acos { rad2deg acos shift };          
	sub x_tan { tan deg2rad shift };             
	sub x_atan { rad2deg atan shift };           
	print +( x_asin x_acos x_tan x_atan x_cos x_sin 45 ) - 45' 
	4.6604498038505e-11

Now I'm realy interested how much precision I'll need to beat windopws
calculator with Math::BigFloat.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#2752

with <slrnlmreqo.6fi.whynot@orphan.zombinet> Eric Pozharski wrote:

*SKIP*
> Now I'm realy interested how much precision I'll need to beat windopws
> calculator with Math::BigFloat.

Doable, except needs loads of time.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#2731

Eric Pozharski <whynot@pozharski.name> writes:

> with <lkfom3$7ui$1@speranza.aioe.org> Hils wrote:
>
> *SKIP*
>> R version 3.1.0:
>>
>> asin(acos(atan(tan(cos(sin(45*pi/180))))))*180/pi-45
>> [1] -7.105427e-15
>>
>> Gnuplot 4.6:
>>
>> print asin(acos(atan(tan(cos(sin(45*pi/180))))))*180/pi-45
>> -7.105427357601e-15
>>
>> I'm guessing a common library at work here...
>
> libc, maybe:
>
> 	% perl -MMath::Trig -wle '
> 	print rad2deg( asin acos atan tan cos sin deg2rad 45 ) - 45'
> 	7.105427357601e-15
>
> Math::BigFloat looks promising (if I would mind to compete with windopws
> calculator), however resourceful.  But it's a way too much hassle for
> now -- it doesn't have btan() and bacos() methods, so those must be
> constructed in place.

gforth:

: PIE 3.1415926535897932385E0 ;

: DEG2RAD PI F* 180E0 F/ ;

: RAD2DEG 180E0 F* PI F/ ;

: TEST 45E0 DEG2RAD FSIN FCOS FTAN FATAN FACOS FASIN RAD2DEG 45E0 F- F. ;

TEST

-0.000000000000007105427357601

[toc] | [prev] | [next] | [standalone]

#2695

David Hume <David.Hume@example.com> wrote:
> "BartC" <bc@freeuk.com> writes:


> > My Casio fx-83 gives 1.2702e-9 degrees (difference from the original 45
> > degrees).
> >
> > (On this algebraic calculator it's entered as
> > invsin(invcos(invtan(tan(cos(sin(45))))))-45.)

> That sounds fun.

> clisp:

> (- (* (/ 180 pi) (asin (acos (atan (tan (cos (sin (* (/ pi 180) 45)))))))) 45)
> -1.7347234759768070944L-17

> We have a winner! :D

Tcl comes very close to clisp's answer:

$ rlwrap tclsh 
% package require units 
2.1.1
% set input [ units::convert "45 degrees" radians ]
0.78539805
% namespace path {::tcl::mathfunc ::tcl::mathop}
% set answer [ - [ asin [ acos [ atan [ tan [ cos [ sin $input ] ] ] ] ] ] $input ]
1.1102230246251565e-16

[toc] | [prev] | [next] | [standalone]

#2694

Gordon Henderson <gordon+usenet@drogon.net> wrote:

> Put calculator into degrees mode, enter 45, then push SIN, COS, TAN,
> then the inverses - INV-TAN, INV-COS and INV-SIN - then subtract 45 and
> see what the result is.
> ...
> Doing it using my RTB BASIC (standard IEEE 64-bit doubles), I end up
> with -3.606714927e-11.

grpn (http://lashwhip.com/grpn.html) returns:

5.698552740796e-12

[toc] | [prev] | [next] | [standalone]

#2707

Gordon Henderson <gordon+usenet@drogon.net> writes:

> With that, you do expect some rounding, but a lot of calculators were
> so far off the mark it was quite incredible.

How far off the mark exactly?

> Doing it using my RTB BASIC (standard IEEE 64-bit doubles), I end up
> with -3.606714927e-11.

I got -7.105427357601002e-15 from Python. My old Casio fx-991 gives
-6.902e-6. My HP48 gives 612.9e-9.

[toc] | [prev] | [next] | [standalone]

#2708

In article <vg3r444gpb0.fsf@coffee.modeemi.fi>, Anssi Saari  <as@sci.fi> wrote:
>Gordon Henderson <gordon+usenet@drogon.net> writes:
>
>> With that, you do expect some rounding, but a lot of calculators were
>> so far off the mark it was quite incredible.
>
>How far off the mark exactly?

From memory (30+ years!) some were out by 10's or 20's. (ie results were 45 +/- 10)

>> Doing it using my RTB BASIC (standard IEEE 64-bit doubles), I end up
>> with -3.606714927e-11.
>
>I got -7.105427357601002e-15 from Python. My old Casio fx-991 gives
>-6.902e-6. My HP48 gives 612.9e-9.

What I've found fascinating in this thread is the range and spread
of the errors we're seeing - it would be interesting to know how many
of those systems used IEEE floating point - which (AIUI) is what the
floating point processor on a typical modern cpu has.

And here is another oddity:

My BASIC intrepreter under x86 Linux (Debian Wheezy), compiled with gcc
4.7.2 gives -3.606714927e-11 as I noted earlier, but the same program,
compiled with gcc 4.6.3 under ARM Linux (Raspberry Pi, Raspbian which
is effectively Debian Wheezy) gives a slightly different error result
of: 5.698552741e-12.

So it's a bonkers test giving bonkers results!

I'll be in a place on Sunday which has a calculator museum - I'll see
how many I can try then..

Gordon

[toc] | [prev] | [next] | [standalone]

#2721

Gordon Henderson <gordon+usenet@drogon.net> writes:

>
> I'll be in a place on Sunday which has a calculator museum - I'll see
> how many I can try then..
>

I am jealous.

I've been trying to find out how old my casio fx-330 is (and how old the
others mentioned are) but got nowhere. I think it is probably early to
mid 1980s. Does anyone have a link with manufacture dates?

[toc] | [prev] | [next] | [standalone]

#2723

David Hume <David.Hume@example.com> wrote:
> Gordon Henderson <gordon+usenet@drogon.net> writes:

> >
> > I'll be in a place on Sunday which has a calculator museum - I'll
> > see how many I can try then..
> >

> I am jealous.

> I've been trying to find out how old my casio fx-330 is (and how old
> the others mentioned are) but got nowhere. I think it is probably
> early to mid 1980s. Does anyone have a link with manufacture dates?

My HP-15C hails from 1984.

[toc] | [prev] | [next] | [standalone]

#2729

On 2014-05-09, David Hume <David.Hume@example.com> wrote:
> Gordon Henderson <gordon+usenet@drogon.net> writes:
>
>>
>> I'll be in a place on Sunday which has a calculator museum - I'll see
>> how many I can try then..
>>
>
> I am jealous.
>
> I've been trying to find out how old my casio fx-330 is (and how old
> the others mentioned are) but got nowhere. I think it is probably
> early to mid 1980s. Does anyone have a link with manufacture dates?

1981, I think.  My FX-702P of similar vintage is around here somewhere.
Beautiful machine.

-- 
-- ^^^^^^^^^^
--  Whiskers 
-- ~~~~~~~~~~

[toc] | [prev] | [next] | [standalone]

#2758

Gordon Henderson wrote:

> In article <vg3r444gpb0.fsf@coffee.modeemi.fi>, Anssi Saari  <as@sci.fi> wrote:
>>Gordon Henderson <gordon+usenet@drogon.net> writes:
>>
>>> With that, you do expect some rounding, but a lot of calculators were
>>> so far off the mark it was quite incredible.
>>
>>How far off the mark exactly?
> 
> From memory (30+ years!) some were out by 10's or 20's. (ie results were 45 +/- 10)
> 

I dug out my old Casio fx-1000 from the late 1970's.  It gives 0.6948
(just those four decimals, although there were more for intermediate
results).  So quite bad by modern standards, but I happily used it
when I was doing maths and science "A levels" (UK exams at age 18).

One thing that surprised me using it again is how slow it is.  Roughly
a whole second for each trig function.  I suppose it must have seemed
normal back then.

-- 
Geoff Clare <netnews@gclare.org.uk>

[toc] | [prev] | [next] | [standalone]

#2710

On Thu, 8 May 2014 07:00:23 +0000 (UTC), Gordon Henderson
<gordon+usenet@drogon.net> wrote:

>The BASIC is 50 thread, having diverged into floating point issues has
>reminded me of a standard test that wa applied in all the schools where
>I lived to determine if a calculator would be suitable for school use.
>
>Put calculator into degrees mode, enter 45, then push SIN, COS, TAN,
>then the inverses - INV-TAN, INV-COS and INV-SIN - then subtract 45 and
>see what the result is.

3.528E-9 on a TI-83 Plus running under TilEm 2.0

I thought it would do better than that to be honest.

[toc] | [prev] | [next] | [standalone]

#2711

On Thu, 8 May 2014 07:00:23 +0000 (UTC), Gordon Henderson
<gordon+usenet@drogon.net> wrote:

>The BASIC is 50 thread, having diverged into floating point issues has
>reminded me of a standard test that wa applied in all the schools where
>I lived to determine if a calculator would be suitable for school use.
>
>Put calculator into degrees mode, enter 45, then push SIN, COS, TAN,
>then the inverses - INV-TAN, INV-COS and INV-SIN - then subtract 45 and
>see what the result is.

And  8.5254109580232404296378982169825e-33 on "calc" on Windows 7
64-bit.

I'm really surprised that Windows calculator does so much better than
an emulated TI-83 Plus.  At least on this rather artificial test.

[toc] | [prev] | [next] | [standalone]

#2712

On 2014-05-08 19:38, Caecilius wrote:
> On Thu, 8 May 2014 07:00:23 +0000 (UTC), Gordon Henderson
> <gordon+usenet@drogon.net> wrote:
> 
>> The BASIC is 50 thread, having diverged into floating point issues has
>> reminded me of a standard test that wa applied in all the schools where
>> I lived to determine if a calculator would be suitable for school use.
>>
>> Put calculator into degrees mode, enter 45, then push SIN, COS, TAN,
>> then the inverses - INV-TAN, INV-COS and INV-SIN - then subtract 45 and
>> see what the result is.
> 
> And  8.5254109580232404296378982169825e-33 on "calc" on Windows 7
> 64-bit.
> 
> I'm really surprised that Windows calculator does so much better than
> an emulated TI-83 Plus.  At least on this rather artificial test.

My Voyage 200 (OS version 2.07) returns 0.

As does LibreOffice Calc 4.1.4.2 from

=DEGREES(ASIN(ACOS(ATAN(TAN(COS(SIN(RADIANS(45))))))))-45

[toc] | [prev] | [next] | [standalone]

#2738

On 2014-05-08, Gordon Henderson <gordon+usenet@drogon.net> wrote:
> The BASIC is 50 thread, having diverged into floating point issues has
> reminded me of a standard test that wa applied in all the schools where
> I lived to determine if a calculator would be suitable for school use.
>
> Put calculator into degrees mode, enter 45, then push SIN, COS, TAN,
> then the inverses - INV-TAN, INV-COS and INV-SIN - then subtract 45 and
> see what the result is.
>
> With that, you do expect some rounding, but a lot of calculators were
> so far off the mark it was quite incredible.
>
> No-longer having a desktop scientific calculator (that works), I've
> just tried it with gcalctool under my Linux desktop and given up. It's
> a bloody calculator for goodness sake, not something I want to TYPE at!!!
>
> Doing it using my RTB BASIC (standard IEEE 64-bit doubles), I end up
> with -3.606714927e-11.

And we didn't have the IEEE floating point standard before the 1980s.

Lots of good reading in this paper:

"Why do we need a floating-point arithmetic standard?
by W. Kahan, University of California at Berkeley, February 12, 1981

<http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf>

Page 5: a table of the different floating point formats and their 
Over/Underflow Thresholds on different machines

Chapter 11 Programmers vs. Users vs. Computer Salesmen (Page 26) 
gives a good explanation:

"For instance, consider an engineer who has to cope with data and results
to 3 or 4 significant decimals; experience teaches him to calculate with
at least 7 or 6 significant decimals, so he looks for applications
programs and computer systems that will guarantee that much accuracy. The
applications programmers, asked to guarantee the correctness of 7 or 8
significant decimals, demand 14 or 15 from their computer system and its
supporting library. The library programmers play it safe too; they ask for
30. Computer architects obligingly offer 33. The engineer who accepts this
rationale may unknowingly be squandering 3/4 of his system’s data memory
and 9/10 of its speed as well as the opportunity to obtain a satisfactory
system on one chip. I think I have exaggerated the situation here, but
only to emphasize how heavily important decisions will hang upon what
the user and various programmers believe to be practical."

-- 
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name                                  -- @gojomo

[toc] | [prev] | [next] | [standalone]

#2746

In message <lkfa27$661$1@dont-email.me> 
  Gordon Henderson <gordon+usenet@drogon.net> wrote:
> The BASIC is 50 thread, having diverged into floating point issues has
> reminded me of a standard test that wa applied in all the schools where
> I lived to determine if a calculator would be suitable for school use.

> Put calculator into degrees mode, enter 45, then push SIN, COS, TAN,
> then the inverses - INV-TAN, INV-COS and INV-SIN - then subtract 45 and
> see what the result is.

PCalc gives me 0

cmpxRPN gives me 7.7825745847804e-11

(both on iOS)

> Doing it using my RTB BASIC (standard IEEE 64-bit doubles), I end up
> with -3.606714927e-11.

What was the cut-off for suitability?

-- 
When the chips are down, the buffalo's empty.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.misc

csiph-web