number of digits in Maple

[pluton]

Hi,

If I understood well current computer can numerically handle 16 digits in floating points numbers. In Maple, the number of Digits can be controlled with th command Digits but looks like there is no difference between Numerical and Symbolic calculations. If I use kernelopts(maxdigits); my computer says 268435448 and I understand that Maple will use this number of digits for symbolic calculations but what about numerical calculations ?

Thank you

[Thomas D. Dean]

Look at ? Digits
? evalf/details

Try evalf(Pi,100);

Tom Dean

[G. A. Edgar]

In article <ZL2dnfHe9_8P6ZfS...@megapath.net>, Thomas D.

Also try this:

restart;
A := evalf(sqrt(2));
Digits := 50;
B := evalf(sqrt(2));
B-A;

--
G. A. Edgar http://www.math.ohio-state.edu/~edgar/

[pluton]

but what about the so-called floating point arithmetic? I thought a computer could not store more the 16 digits on average?

[Thomas D. Dean]

pluton wrote:
> but what about the so-called floating point arithmetic? I thought a computer could not store more the 16 digits on average?

? Digits talks about software floating point. This is not limited to 16
digits.

True, hardware floating point is limited to something like 16 digits on
a 32-bit CPU.

I believe Maple uses hardware floating point for some things like plot.

Tom Dean

[pluton]

ok, it sounds like what I am talking about is the format float64 but as you said, computers are not limited to it.

[Axel Vogt]

As G A Edgar says/shows: you can choose what you want.

The system will find a way. Roughly: many digits are like
n-tuples of bytes, just as float64 is a n-tuple of ...

Holds for any CAS (if it allows it), not only Maple.

[acer]

As others have explained, by itself "floating point" does not
necessarily mean 64bit double precision hardware floating-point. Maple
can do software floating-point computation, at Digits working
precision. The GnuMP library is used for some parts of software
floating-point computations. (See http://gmplib.org/ for more on
that.)

So, perhaps you are wondering whether Maple will always do numeric
computations only using software floating-point. The answer, in large
part, is no. Quite often it will use hardware double floating-point,
if Digits<=15, for numeric problems where the input is all numeric and
wholly (or sometimes partially) floating-point. Here below are some
places where that is the case,

compiled C (various dynamic libs in Maple's bin.xxxx folders):
- sin, exp, sinh, etc, only where necessary to attain accuracy not
always available by OS runtime
- LinearAlgebra (also including modular LA)
- Statistics
- Optimization (LP, QP, LS, entirely double precision)
- dsolve/numeric
- pdsolve/numeric
- DiscreteTransforms
- CurveFitting
- etc, that I forget

alternative interpreter that is double precision, named evalhf:
- evalhf'able procedures run wrapped with evalhf()

compiled procedures, using `Compiler` routine:
- behind the scenes this takes a maple language user-written proc,
generates C source,
compiles it, links it into a dynamic lib, dlsym opens that
function in that dy-lib,
and provides an entry point that looks acts just like the original
user-written proc.

floating-point arithmetic, etc, inside regular proc's which have
`option hfloat`

arithmetic and special functions of scalar floating-point numbers,
whether that happen to be
scalar HFloat or scalar SFloat (latter requires intermediate
conversion).

Now, someone else here mentioned `plot`. What the plotting routines do
is (if Digits<=15) attempt to
run the procedure, or evaluate the expressions, under the above-
mentioned evalhf double-precision
alternative interpreter. If for some reason that fails (the evalhf
interpreter is more limited in the
scope of its functionality) then the plotting routines fall back to
software floating-point.

The reason for all of this, of course, is primarily the speed benefit.
Careful timings can reveal quite
a step increase in computation time, as these kinds of computation go
over the Digits=15 threshhold.
Also, software floats are stored as DAGs and memory managed, while
most of the above double-
precision operations do not require that (HFloats being an exception).
So additional memory management
is another cost that begins to accrue, with higher software floating-
point. It's an interesting question:
whether it would be worthwhile to replicate some of the double-
precision functionality listed above using
an efficient compiled quadruple-precision scheme, so as to mitigate
the penalty of the sharp rise in timing
as the Digits setting increased above 15 in value.

Hope that helps,
acer

[pluton]

ok, clarified. Thanks a lot to all of you.