important change in mpfr

       Dear mpfr users,

we would like to warn you about an important change in the
next version of
mpfr. Up from the next release (2.3.0) mpfr will use a
decimal internal 
representation instead of a binary one. The main motivation
for that change
is the fact that the revision of IEEE 754 (http://www.validlab.com
/754R/)
will include decimal formats. We anticipate that in ten
years, the main 
machine integer and floating-point formats will be in
decimal, and the
current binary formats will soon become obsolete, and/or
very slow.

We apologize for any problems mpfr users might have. Of
course this will
break the binary compatibility of the library, but we
promise a decimal
compatibility up from version 2.3.0.

We strongly request the GMP developers to anticipate that
decimal change too.
This will boost all applications of GMP and MPFR to bank
accounting.

For the mpfr team,
Paul Zimmermann
_______________________________________________
gmp-discuss mailing list
gmp-discussswox.com
http://s
wox.com/mailman/listinfo/gmp-discuss

Your proposed change sounds like an improvement, but I'd
like to
encourage you to consider using a more traditional
sexagesimal
(radix-60) representation instead.  This would have the
obvious
advantage of being more memory-efficient, and the use of a
sublinear
radix-conversion algorithm should still allow a reasonably
low cost
for converting to decimal (or binary).

I hope that you, Torbjorn, and the other MPFR/GMP developers
give my
proposal the serious consideration that it deserves.  Happy
April 1st.

-- Regards, Will
( mailto:galwaymath.uiuc.edu  http://www.math.uiuc
.edu/~galway )

On Saturday April 1, 2006 at 08:54:03, Paul Zimmermann
wrote:
 >        Dear mpfr users,
 > 
 > we would like to warn you about an important change in
the next version of
 > mpfr. Up from the next release (2.3.0) mpfr will use a
decimal internal 
 > representation instead of a binary one. The main
motivation for that change
 > is the fact that the revision of IEEE 754 (http://www.validlab.com
/754R/)
 > will include decimal formats. We anticipate that in
ten years, the main 
 > machine integer and floating-point formats will be in
decimal, and the
 > current binary formats will soon become obsolete,
and/or very slow.
 > 
 > We apologize for any problems mpfr users might have.
Of course this will
 > break the binary compatibility of the library, but we
promise a decimal
 > compatibility up from version 2.3.0.
 > 
 > We strongly request the GMP developers to anticipate
that decimal change too.
 > This will boost all applications of GMP and MPFR to
bank accounting.
 > 
 > For the mpfr team,
 > Paul Zimmermann
 > _______________________________________________
 > gmp-discuss mailing list
 > gmp-discussswox.com
 > http://s
wox.com/mailman/listinfo/gmp-discuss
_______________________________________________
gmp-discuss mailing list
gmp-discussswox.com
http://s
wox.com/mailman/listinfo/gmp-discuss

Paul.Zimmermannloria.fr (Paul Zimmermann) writes:

  We strongly request the GMP developers to anticipate that
decimal change too.
  This will boost all applications of GMP and MPFR to bank
accounting.
  
I must say that I think is a very serious mistake.  Decimal
arithmetic is known to be very inefficient!

For GMP 5, we will use base-100 arithmetic throughout
(except in
the input an doutput functions that will accept binary
numbers).
Base-100 will be ten times faster than base-10, of course.

-- 
Torbjörn
_______________________________________________
gmp-discuss mailing list
gmp-discussswox.com
http://s
wox.com/mailman/listinfo/gmp-discuss

Torbjorn Granlund wrote:
> Paul.Zimmermannloria.fr (Paul Zimmermann) writes:
> 
>   We strongly request the GMP developers to anticipate
that decimal change too.
>   This will boost all applications of GMP and MPFR to
bank accounting.
>   
> I must say that I think is a very serious mistake. 
Decimal
> arithmetic is known to be very inefficient!
> 
> For GMP 5, we will use base-100 arithmetic throughout
(except in
> the input an doutput functions that will accept binary
numbers).
> Base-100 will be ten times faster than base-10, of
course.
> 
Why not base-1000 then? It will be 100 times faster than
base 10.

Perhaps base-10^k is the best solution after all.
It will be 10^(k-1) times faster than base-10.

--Elias
_______________________________________________
gmp-discuss mailing list
gmp-discussswox.com
http://s
wox.com/mailman/listinfo/gmp-discuss

On 2006-04-04 11:37:24 +0300, Elias P. TSIGARIDAS wrote:
> Torbjorn Granlund wrote:
> > Paul.Zimmermannloria.fr (Paul Zimmermann)
writes:
> > 
> >   We strongly request the GMP developers to
anticipate that
> >   decimal change too. This will boost all
applications of GMP and
> >   MPFR to bank accounting.
> >   
> > I must say that I think is a very serious mistake.
 Decimal
> > arithmetic is known to be very inefficient!
> > 
> > For GMP 5, we will use base-100 arithmetic
throughout (except in
> > the input an doutput functions that will accept
binary numbers).
> > Base-100 will be ten times faster than base-10, of
course.
> > 
> Why not base-1000 then? It will be 100 times faster
than base 10.
> 
> Perhaps base-10^k is the best solution after all.
> It will be 10^(k-1) times faster than base-10.

Yep, but to make some sense to the representation, numbers
should
be represented by a tree: an n-digit number should be
represented
by 2 (n/2)-digit numbers in some high base 10^k, and
recursively. 

-- 
Vincent Lefèvre <vincentvinc17.org> - Web:
<http://www.vinc17.org/>

100% accessible validated (X)HTML - Blog: <http://www.vinc17.org
/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at
LORIA
_______________________________________________
gmp-discuss mailing list
gmp-discussswox.com
http://s
wox.com/mailman/listinfo/gmp-discuss