#### Do you have a question? Post it now! No Registration Necessary

Re: Extending floating point precision

Bryan Hackney wrote:

I keep thinking that maybe, just maybe there is a way...

Let's look at it again; if you start with this (done in

the hardware FPU)...

Double-precision 64 bit

1 11 52 <-- Width

+--+---------+--------------------+

|Si| Exp | Mantissa |

+--+---------+--------------------+

|63|62 52|51 0| <-- Bit #

length 64 bits

sign 1 bit

exponent 11 bits

mantissa 52 bits(+1)

bias 1,023

..and then you try to combine a most significant and

least significant portion so as to get this:

1 22 105

+---+-------------+-----------------------------------+

|Si | Exp | Mantissa |

+---+-------------+-----------------------------------+

|127|126 105|104 0|

length 128 bits

sign 1 bit

exponent 22 bits

mantissa 105 bits(+1)

bias 2,097,151

..then clearly losing a quantum of precision on the boundary

hoses everything to the right of that boundary.

But what happens if you dump that double-precision 64-bit

starting point and instead start with an extended-

precision 80-bit starting point (still done in the the

hardware FPU)?

1 22 105 <-- Width

+--+-----------+---------------------------+

|Si| Exp | Mantissa |

+--+-----------+---------------------------+

|79|78 64|63 0| <-- Bit #

length 80 bits

sign 1 bit

exponent 15 bits

mantissa 64 bits

bias 16,383

Now, instead of trying to combine two 52-bit mantissas to get

a 105-bit mantissa, you combine two

***64***-bit mantissas.

What I am thinking (and I might very well be wrong about this),

is that bit 0 might suffer from normalization and rounding,

but bit 12 probably won't. In other words, by starting with

a 22-bit exponent and a 64 bit mantissa and then truncating

it to an 11-bit exponent 52 bit mantissa, I suspect that you

get the same result as you would have had your original double-

precision 64-bit value had no normalization and rounding.

Or do you?

--

Guy Macon <http://www.guymacon.com/

Guy Macon <http://www.guymacon.com/

Re: Extending floating point precision

Paul Burke wrote:

My windows box says that the .zip at http://www.mpfr.org/mpfr-current /

is corrupt. I will look at the .tar.gz when I reboot into Linux.

I suspect that I will find that it's built out of ordinary fixed

point instructions; Restricting myself to floating point instructions

is rather a lot like restricting my poetry to iambic pentameter. :)

Re: Extending floating point precision

You seem to have something against the form.

What reason, though, I really could not say.

E'en floating point instructions can be fine

if learning code technique is what you seek,

or perhaps bringing brain cells greater fit-

ness. (Use a rhyming meter? Not this one.)

mlp

Re: Extending floating point precision

Yes, it certainly is possible and there are several well-known math packages

like Maple, Mathematica, (maybe Matlab as well) that will do

arbitrary-precision arithmetic in both fixed point and floating point.

Depending on which platform you are using, these programs will either use the

co-processor or do the floating point calculations entierly in software, or a

combination of both. About 10 years ago, you could buy an ISA card called the

"Dubner Cruncher" that would do arithmetic on huge numbers (2000 digits or

more) entirely in hardware. If you want source code for doing arbitrary

precision fixed point and floating math, I believe YACAS is fully open source

and it can do both.

--Tom.

Re: Extending floating point precision

Tom wrote:

That would certainly accomplish the task, but it wouldn't be the learning

experience I was seeking. I already have libraries with source and have

written my own routines using fixed point instructions; what I am trying

to do is to fix a hole in my knowledge - how to do it within the constraints

of using the operations in an FPU as my starting point. It's something

that I should already know, but I have a tendency to just use the FPU as

if it was a fast library call.

I am still working on building up 128 bit floating point routines out

of 64-bit or 80-bit floating point routines as opposed to integer math.

right now I am struggling with the fact that the most-significant part

mucks about with the lowest bit to make it normal or to round it, and

that hoses any hope of adding on a bunch of precision with the least-

significant part. I have just started on it though.

Re: Extending floating point precision

[%X]

Have you looked in the Forth Scientific Library code. It sounds like the

sort of thing that someone like Julian Noble might have accomplished at

some point in his work. Maybe even posting this question to clf would yield

answers for you as well.

Not needing to use FP for much of my control work it is not a question I

have considered myself.

--

********************************************************************

********************************************************************

We've slightly trimmed the long signature. Click to see the full one.

Re: Extending floating point precision

Guy Macon schrieb:

Hello,

if we use a different organisation for quadruple precision like this:

sign 1 bit

exponent 11 bits

mantissa 104 bits(+2)

we can use all given double precision operations to calculate like this:

Every quad number consists of two double numbers, the most and the least

significant part a = a1 + a2

We can add a+b = a1+b1 + a2+b2

multiply a

***b = (a1+a2)***(b1+b2) = a1b1+a2b1+a1b2+a2b2

The subtraction is done like the addition. All these operations will use

the double precision floating point unit.

But the problem is the division a/b = (a1+a2)/(b1+b2)

Calculating the carries is also a problem.

It seems to be easier not to use double fp operations and an exponent of

32 bits and a mantissa of three or four words of 32 bits each.

All operations with these quad fp numbers can be done with integer

operations.

Bye

Re: Extending floating point precision

Hi,

some available options are:

1. The GNU Multiple Precision Arithmetic Library:

http://www.swox.com/gmp/index.orig.html

2. Some packages present on:

http://crd.lbl.gov/~dhbailey/mpdist /

for example the Quad-Double (QD) and/or MPFUN

3.The "doubledouble" package:

http://members.lycos.co.uk/keithmbriggs/doubledouble.html

See also links on:

http://www.mathtools.net/C

http://cliodhna.cop.uop.edu/~hetrick/c-sources.html

ftp://nic.funet.fi/pub/sci/math/multiplePrecision /

Hope it helps,

Best regards,

Jacek.

some available options are:

1. The GNU Multiple Precision Arithmetic Library:

http://www.swox.com/gmp/index.orig.html

2. Some packages present on:

http://crd.lbl.gov/~dhbailey/mpdist /

for example the Quad-Double (QD) and/or MPFUN

3.The "doubledouble" package:

http://members.lycos.co.uk/keithmbriggs/doubledouble.html

See also links on:

http://www.mathtools.net/C

___C______/Extra___precision_computation /http://cliodhna.cop.uop.edu/~hetrick/c-sources.html

ftp://nic.funet.fi/pub/sci/math/multiplePrecision /

Hope it helps,

Best regards,

Jacek.

Re: Extending floating point precision

In misc.business.product-dev,comp.arch.embedded, On 30 Jun 2005

This isn't the answer to what you're asking, but I've got something

on my website (this page is six years old) that you may find

interesting.

I use the FP multiply instruction to do multiplies of 8 (decimal)

digits by 8 digits with 16 digit result and "carry," which is then

used to for multiprecision integer multiplication.

Go here and scroll down to Factorials:

http://www.mindspring.com/~benbradley/number_theory.html

-----

http://www.mindspring.com/~benbradley

This isn't the answer to what you're asking, but I've got something

on my website (this page is six years old) that you may find

interesting.

I use the FP multiply instruction to do multiplies of 8 (decimal)

digits by 8 digits with 16 digit result and "carry," which is then

used to for multiprecision integer multiplication.

Go here and scroll down to Factorials:

http://www.mindspring.com/~benbradley/number_theory.html

-----

http://www.mindspring.com/~benbradley

#### Site Timeline

- » Reverse current into a lithium battery
- — Next thread in » Embedded Programming

- » MSP430, gcc -> IAR
- — Previous thread in » Embedded Programming

- » Getting i2c touchscreen to work on TS4900
- — Newest thread in » Embedded Programming

- » Embedded Ethernet
- — Last Updated thread in » Embedded Programming

- » Soldering to Phosphor-Bronze
- — The site's Newest Thread. Posted in » Hobby Electronics Basics

- » Suggestions for dusk to dawn lighting
- — The site's Last Updated Thread. Posted in » Electronics Repair