WP 34S: Double precision registers - What are your feelings?



#18

I know here are some numerical analysts which may help to decide about a feature in WP 34S which may, or may not, be exposed to the user: double precision registers.

The decimal64 format used for the registers and stack provide 16 decimal digits. The decimal128 variant has room for 34 decimal digits. All internal computations are done to at least 39 digits and then rounded to the register format.

The latest firmware has added commands to switch to decimal128 as the register format, thus exposing much higher precision to the user. The commands in question are DBLON, DBLOFF (in MODE) and DBL? (in TEST). The reason to implement the feature is that we want to implement more algorithms in user code which is hopefully much more compact than the present native implementations are. We do not want to sacrifice accuracy and will therefore use double precision registers internally for this.

The question is: Is it worthwhile - or even dangerous - to expose this to the user. There will certainly be some functions which will not return results accurate to 34 decimal places. On the other hand, there are many that do, most notably the basic arithmetic but also exponentials and logarithms.

As an example, I tried PI LN EXP PI - and got 1e-33 as the result which looks very promising. 10 Phi Phi^-1 returns infinity in normal mode and (10 - 5e-13) in double precision mode as the result. The usable range of the function is obviously considerably expanded.

What are your feelings about the feature? Leave it user accessible or not? Do you have applications for it?


#19

Quote:
What are your feelings about the feature? Leave it user accessible or not? Do you have applications for it?

Well, I can't say if I'll ever really need or use it, but who knows? So I would say: if it's already implemented and working then make it also accessible to the user.

BTW, does this double presision also increase the exponent range, i.e. work with higher exponents than E+/-380?


#20

Quote:
BTW, does this double presision also increase the exponent range, i.e. work with higher exponents than E+/-380?

It does. See here! The exponent range is larger than the display can show. In this case, "HIG" is displayed in the exponent field. We need to modify SHOW to allow a better display of double precision numbers which exceed the range. You can use LOG for a quick estimate. The format is more suited to intermediate results than to final values.


#21

WOW, more than 6000!?

This WP34s is more and more turning into a monster machine ... :-)

#22

Quote:
The exponent range is larger than the display can show. In this case, "HIG" is displayed in the exponent field.

Several functions will break down for arguments with large exponents. For example, the trig functions won't modulo reduce properly but there will be others.


- Pauli

#23

Quote:
You can use LOG for a quick estimate

Well, on the 34s we have this EXP function that should return the exact exponent here. ;-)

Dieter


#24

Quote:
Well, on the 34s we have this EXP function that should return the exact exponent here. ;-)

I know, but LOG is on the keyboard. :-)
#25

Quote:
On the other hand, there are many that do, most notably the basic arithmetic but also exponentials and logarithms.

Basic arithmetic, square root should be correctly rounded. Exponentials could be wrong in the last digit -- I can live with that.

Logarithms won't be so good -- I terminate the series at a relative error of 1e-32 between successive terms. Which means the last two digits could easily be incorrect as could the third last. This is pushing past the bounds of what I deem acceptable in a calculator, at least what is exposed to the user.

Several other functions are, by design, not even close to 34 digits accurate. The statistical functions being some of them -- phi is better than many of the others. Try F or t they won't be as good -- stopping at a relative error of 1e-24 or less between successive methods.

SIN/COS/TAN should be good, their inverses less so. Gamma won't be accurate to all digits e.g.

Don't judge a function from a single or even many evaluations.


- Pauli


#26

Quote:
Don't judge a function from a single or even many evaluations.

No Question! As a compromise, we could deliberately round functions with questionable accuracy to less digits or increase the number of iterations depending on the double precision flag. I'm on the side of rounding to less significant digits for those functions we do not trust.

BTW, I don't think anybody will ever try to calculate sin(10^6000). We can reduce the allowed argument range the same way we reduce the resulting number of figures.


#27

Quote:
BTW, I don't think anybody will ever try to calculate sin(10^6000). We can reduce the allowed argument range the same way we reduce the resulting number of figures.

I'm certain someone will try. I remember comparisons of calculators evaluating SIN(1E90 radians) and comparing the results, that value is pretty large.

There is quite a lot of discussion about argument reduction in the numeric mathematics literature I've got and quite some effort has been put into being able to do the modulo 2 PI reduction trig functions require. Muler's Elementary Functions has an entire chapter dedicated to this topic. A quick google turned up this one. Also this one talking about .NET's failings on this front.


- Pauli


#28

Quote:
I'm certain someone will try. I remember comparisons of calculators evaluating SIN(1E90 radians) and comparing the results, that value is pretty large.

Well, maybe you should implement a new constant with the value "Oops!" and return this value for function calls with such unusual arguments. ;-)

#29

Nice suggestion :-)

The 34S should be good for trig arguments up to the largest decimal64 value (circa 10^384).


- Pauli


#30

Quote:
The 34S should be good for trig arguments up to the largest decimal64 value (circa 10^384).

I would say that's more than enough in a universe with only about 10^80 atoms. ;-)
#31

Usually the error in the final result is significantly less than difference between the last two approximations - since the algorithms converge the error decreases with every iteration. For instance, the method used for the normal quantile has better than quadratic, almost cubic convergence. So if the last two approximations are only 1E-20 apart, the final result usually can be expected to have about 50 valid digits. ;-)

So a closer look at the used methods and their convergence properties may show that the precision is "good enough" even for double precision mode.

However, there is an even better idea: an internal function may accept the desired precision as an additional argument, so that it is evaluated as precisely as required - neither better (slower) nor worse (inexact). So a direct call by the user or within a program may terminate as soon as the result has 16 correct digits, while the internal call of the same function, used within a more complicated algorithm, may return 30+ digits. On the other hand the initial estimates for the quantile functions only require logarithms that are correct in, say, five significant digits. That's why I think such a "flexible precision" approach may be a good idea.

Dieter

#32

Double precision? Yikes! Many struggle with the simpler dangers of floating point and decimal <-> binary conversions.

Yes, it can be dangerous to allow users access to double precision packages and operators.

Yes, it's very useful to those who understand it, and its limitations.

I'd allow it, and hope the manual eventually gets a complete listing of error bounds for the included functions.

Double complex even more so!


#33

Quote:
I'd allow it, and hope the manual eventually gets a complete listing of error bounds for the included functions.

Are you volunteering to do the error analysis involved?
I'm not up to it, I don't feel.


- Pauli

#34

User accessible double precision? Great! No question - yes! yes! yes! Pleeeease keep this feature! That's what I am looking for as long as I use programmable calculators!

There's a simple reason for this: if a user-programmed function is expected to return a full precision result (i.e. correct in all returned (standard-precision) digits) the calculation usually has to be done with some additional guard digits. You can't expect a 10-digit result if the whole calculation is done with not more than the same 10 digits.

So the idea is quite exactly the same as yours: Yes, let's provide the user with the tools that enable him to write his own routines with the same precision as the built-in functions. That's what I always missed on my other calculators.

Dieter


Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 3,280 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 1,847 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 2,590 12-04-2013, 11:14 AM
Last Post: Barry Mead
  HP Prime numerical precision in CAS and HOME Javier Goizueta 5 2,499 11-16-2013, 03:51 AM
Last Post: Paul Dale
  WP 34S/43 ?'s Richard Berler 3 2,115 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 2,243 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 2,747 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 2,977 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 1,994 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 1,795 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany

Forum Jump: