▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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 1e33 as the result which looks very promising. 10 Phi Phi^1 returns infinity in normal mode and (10  5e13) 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?
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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?
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
WOW, more than 6000!?
This WP34s is more and more turning into a monster machine ... :)
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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. :)
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 1e32 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 1e24 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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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. ;)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Nice suggestion :)
The 34S should be good for trig arguments up to the largest decimal64 value (circa 10^384).
 Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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. ;)
Posts: 653
Threads: 26
Joined: Aug 2010
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 1E20 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
Posts: 66
Threads: 2
Joined: Aug 2007
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!
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 653
Threads: 26
Joined: Aug 2010
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 userprogrammed function is expected to return a full precision result (i.e. correct in all returned (standardprecision) digits) the calculation usually has to be done with some additional guard digits. You can't expect a 10digit 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 builtin functions. That's what I always missed on my other calculators.
Dieter
