TILE64 embedded multicore processors - Guy Macon

Anybody who tries working in those regions on an 8-bit micro (or anything else for that matter) deserves whatever answers they get. If you try to compute sin(very big number), for instance, you can very quickly get to the point where the answer is "pick a number, any number".

We once had a vendor contact us about the "inaccuracy" of the tan function at a point one bit short of pi/2. They said that our implementation didn't agree with some other implementation to six decimal places. I pointed out that the first digit was doubtful, so the others are irrelevant. Even the NBS Handbook doesn't try to tabulate values in that region.

Some small microcontroller class ones might be :

** simple Inverse scale A = (B * C) / (D * E) ** Polynomial sensor correction - eg thermocouple, or thermister to temperature conversions ** DTMF frequency detection ** Conversion to Decimal Display [In the last case, I recall in our INT libs we expanded the Divide libs, to save both the result and remainder, so that only one divide was needed per display digit. You might be able to do the same ?]

-jg

In article , snipped-for-privacy@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) writes: |>

|> > And the answer is "it depends". It can be negligible, or it can |> > be huge, often depending critically on how accurately you want to |> > calculate the values at the extreme ranges. sin(1.0e300) or |> > pow(1+1.0e-15,1.0e15), for example. |> |> Anybody who tries working in those regions on an 8-bit micro |> (or anything else for that matter) deserves whatever answers |> they get. If you try to compute sin(very big number), for |> instance, you can very quickly get to the point where the |> answer is "pick a number, any number".

Oh, I agree - and have been saying so for years. Now, would you like to tell the IEEE 754R people?

Regards, Nick Maclaren.

The IEEE standards type groups are dominated by the academics who have no touch with reality. Why do you think many implementors ignore the NaNs, infinities, and denormalized numbers features of IEEE 754?

I would hardly call Kahan a dominating academic. Academics don't have the financial support vendor coporations do.

It was amusing at a joint SIGNUM-754 meeting to watch the DEC and IBM reps.

In article , snipped-for-privacy@cse.ucsc.edu (Eugene Miya) writes: |> In article , |> Everett M. Greene wrote: |>

|> >The IEEE standards type groups are dominated by the academics who |> >have no touch with reality. Why do you think many implementors |> >ignore the NaNs, infinities, and denormalized numbers features |> >of IEEE 754? |> |> I would hardly call Kahan a dominating academic. |> Academics don't have the financial support vendor coporations do. |> |> It was amusing at a joint SIGNUM-754 meeting to watch the DEC |> and IBM reps.

Hmm. Have you checked up who was involved in the design of Intel's x86 floating-point?

Regards, Nick Maclaren.

Windows Calculator (Windows 2000 Server, Quad Pentium Pro) says: sin(1.0e300) = -0.98480775301220805936674302458952 while a $20 TI-34II calculator says: sin(1.0e300) = 0.017452406 (0.01745240643728 with hidden digits exposed)

--
Guy Macon

sed)

Given that the representable value closest to 1e300 is probably different on the two systems in question, who's to say that both aren't correct?

My HP20S also says -0.984807753012

Meindert

Nobody.

The only way to calculate the "true" answer would be to do the range reduction while still in decimal mode, and/or convert 1e300 to binary with arbitrary precision.

In both cases you then need an arbitrary (i.e. at least 320 decimal digits) precise approximation to pi to use for range reduction.

I've suggested previously that you should multiply by a pi reciprocal (or 1/(2*pi) etc), stored as an array of float values, each containing

24 bits of the real number.

Doing it this way has the nice property that all factors which are big enough that the product of the factor and the input value will be an integer, can be skipped.

In fact, we probably only need to care about 3-4 elements of the (big!) array, since we can stop when the last (and least significant) element failed to modify the visible (double prec++) result.

Terje

--
- 
"almost all programming can be viewed as an exercise in caching"

In article , Terje Mathisen writes: |>

|> >> Windows Calculator (Windows 2000 Server, Quad Pentium Pro) says: |> >> sin(1.0e300) = -0.98480775301220805936674302458952 |> >> while a $20 TI-34II calculator says: |> >> sin(1.0e300) = 0.017452406 (0.01745240643728 with hidden digits exposed) |> > |> > Given that the representable value closest to 1e300 is probably |> > different on the two systems in question, who's to say that both |> > aren't correct? |> |> Nobody. |> |> The only way to calculate the "true" answer would be to do the range |> reduction while still in decimal mode, and/or convert 1e300 to binary |> with arbitrary precision.

Oh, no! I can think of several other ways of doing it! None are any simpler, of course :-)

For example, start with sin(10^300/2^1000) and use the doubling formula. Oh, what a lovely example of cancellation, so you need to start with quite a lot of digits :-)

That is actually a very practical approach for implementing pow().

Regards, Nick Maclaren.

Not bad, Mathematica computes -0.985750425... in 1000-digit precision.

- FChE

Interesting!

What does Mathematica give you for the Calculator Forensics Equation?

arcsin(arccos(arctan(tan(cos(sin(9))))))

Here are the results on some commonly found calculators:

8.99999863704 TI-34/36/37/52/SC10 8.99999864267 HP-19BII/20S/22/27/28/38/39/42/48/49/50/71/75/87 8.99999864268 TI-9/32/40 8.999999007884 TI-60/67/68/80 8.999999616563 TI-74 8.999999616566 TI-81 8.999999738296 TI-95 8.99999986001 HP-33/35 8.9999999695957 TI-73/82/83/84/85/86 8.9999999817692 TI-89/92 9.0000000000000335019 Sharp PC-E500 (double precision mode) 9.000000000029575 HP-95LX 9.000000000029361 HP-100LX/200LX 9.000000000 HP-30 9.00000000733338 Casio fx-82/115/300/991/4800/7300/9700/9750/9800/9850 9.000000098906 Sharp EL-506/535/531/9200/9300/535 9.000000525 Sharp PC-E500 (single precision mode) 9.000000590443 Casio fx-7700/8000/8500/8700/9850G 9.000001077372 TI-30XS/36XII 9.00000229461 TI-30X/30Xa/35X/36X 9.000003512065 TI-30XIIB/30XIIS/34II/40 9.000004661314 TI-SR50/SR51/SR56/SR60/58/59

Calculator Forensics References:

--
Guy Macon

Unless 1e300 is taken to be an exact number, you're working with only one digit accuracy (or even one bit). About all you may be able to say about the answer is that it's somewhere between -1 and +1.

It gives you back 9 degrees (an exact result).

In[1] := ArcSin[ArcCos[ArcTan[Tan[Cos[Sin[9 Degree]]]]]] Out[1] = 9

But things like ArcTan[Tan[x] and even ArcCos[Cos[x]] are only going to reliably behave like inverses of each other on a cheap pocket calculator anyway. This is not really a useful expression for evaluating an industrial-strength computer algebra system.

G.

Free CCalc (Console Calc) gives this, to the 80 digit precision limit.

asin(acos(atan(tan(cos(sin(9)))))) ans =

9.0000000000000000000000000000000000000000000000000000000000000000000000000000000e0

-jg

The calc program (isthe.com) uses arbitrary precision arithmetic and the answer it gives agrees with that given by Mathematica.

Now that's what I call an accurate calculator! Just the thing for solving commonly encountered situations such as measuring the size of the universe in units of Planck's Length or the age of the universe in units of Planck's Time. (Guess which number is larger...)

Here is the Console Calc web page: [

]

For those of us who spend a lot of time in Linux, there is Calc (a C-style arbitrary precision calculator): [

] [ ] And, of course, there are the BC functions from Cyrek the Illogical: [ ] [ ] [ ] [ ] Then again, Real Men use the gnu debugger as a calculator... :) It turns out that the Console Calc answer depends on the mode (Radian or Degree): RADIAN MODE: asin(acos(atan(tan(cos(sin(9)))))) ans=0.424777960769379715387930149838508652591508198125317462924833776923449218858627 ans=0x0000 ans=0b asin(acos(atan(tan(cos(sin(9)))))) +

0.0000000000000000000000000000000000000000000000000000000000000000000000000000001 ans=0.4247779607693797153879301498385086525915081981253174629248337769234492188586271 ans=0x0000 ans=0b DEGREE MODE: asin(acos(atan(tan(cos(sin(9)))))) ans=9 ans=0x0009 ans=0b1001 asin(acos(atan(tan(cos(sin(9)))))) + 0.0000000000000000000000000000000000000000000000000000000000000000000000000000001 ans=9.0000000000000000000000000000000000000000000000000000000000000000000000000000001 ans=0x0009 ans=0b1001 (Tested on Console Calculator v2.2.6c under Windows 2000 Advanced Server on a Quad-Pentium Pro (last stepping) Compaq Proliant 5500R with 3GB of RAM.) There is also an interesting effect concerning rounding and digits displayed: RADIAN MODE asin(acos(atan(tan(cos(sin(9)))))) + 0.000000000000000000000000000000000000000000000000000000000000000000000000000001 ans = 0.424777960769379715387930149838508652591508198125317462924833776923449218858628 asin(acos(atan(tan(cos(sin(9)))))) + 0.00000000000000000000000000000000000000000000000000000000000000000000000000000001 ans = 0.42477796076937971538793014983850865259150819812531746292483377692344921885862701 DEGREE MODE asin(acos(atan(tan(cos(sin(9)))))) + 0.000000000000000000000000000000000000000000000000000000000000000000000000000001 ans = 9.000000000000000000000000000000000000000000000000000000000000000000000000000001 asin(acos(atan(tan(cos(sin(9)))))) + 0.00000000000000000000000000000000000000000000000000000000000000000000000000000001 ans = 9

--
Guy Macon

Here is the Console Calc web page: [

]

ans=0.424777960769379715387930149838508652591508198125317462924833776923449218858627

0.0000000000000000000000000000000000000000000000000000000000000000000000000000001

ans=0.4247779607693797153879301498385086525915081981253174629248337769234492188586271

0.0000000000000000000000000000000000000000000000000000000000000000000000000000001

ans=9.0000000000000000000000000000000000000000000000000000000000000000000000000000001

You've made the same oversight I did :)

This was Scott's reply to that very question yesterday :)

Scott: " it appears to me that the asin(acos(atan(tan(cos(sin(x)))))) == x test is only valid for 0-90'. beyond 90, you should find asin(acos(atan(tan(cos(sin(x)))))) == 90'-x"

OOps, he is of course, quite right - in odd quadrants, it flips, and 9 radians lands in an odd quadrant.

asin(acos(atan(tan(cos(sin(90+30)))))) ans = 60

-jg