Thread Subject: significant digits

Hello, everyone,
How do I make the result of a calculation to exactly n significant digits. The "format" commands are not flexible in this regard.
e.g. say I want to calculate pi to an accuracy of n significant digits.

"Oluwa KuIse" <wespeakforex@yahoo.com> wrote in message
news:gcc4hm$ivj$1@fred.mathworks.com...
> Hello, everyone,
> How do I make the result of a calculation to exactly n significant digits.
> The "format" commands are not flexible in this regard.
> e.g. say I want to calculate pi to an accuracy of n significant digits.

I do not think you can control this. The default in matlab is double
precision (64 bit floating point arithmetic), and you can't tell Matlab to
do the computation in say 40 bits. (you could however use 32 bit floating
point arithmetic (single precision), help single()

You could always truncation or round to desired number of significant
digits I suppose, after the computation is done. maybe something like this

EDU>> a=pi
a =
   3.141592653589793

EDU>> round(a*100)/100
ans =
   3.140000000000000

But why would you want to reduce number of sig. digits? it is better to use
more bits, and use format to display the result. May be I misunderstood what
you wanted to do.

Nasser

Oluwa KuIse wrote:

> How do I make the result of a calculation to exactly n significant digits. The
> "format" commands are not flexible in this regard.
> e.g. say I want to calculate pi to an accuracy of n significant digits.

If you had the symbolic toolbox, you could use the Digits function to set the
working precision of the calculation (which would all have to be done inside the
symbolic toolbox.) If you do not have the symbolic toolbox, there is a file
you can download from the Matlab File Exchange (FEX) that can do indefinite precision,
but possibly you need to be using MS Windows for it.

But the two similar methods above are concerned with the precision of the
representation of any one number in a calculation. As you know, any time you
apply a binary operator to two numbers, the result has a lower precision than
either of the original numbers: the uncertainty of the final digit
"contaminates" the calculation. e.g, 0.5 + 0.5 + 0.5 + 0.5 could be anywhere
from 0.45 + 0.45 + 0.45 + 0.45 = 1.8 to 0.55 + 0.55 + 0.55 + 0.55 = 2.2
and 0.1 * 0.8 could be anywhere from 0.05 * 0.85 = 0.0425 to 0.15 * 0.75 = 0.1125.

Thus, in order to arrive at a -result- with a particular number of significant
digits by using fixed precision at each step, you need to use a higher
intermediate precision, and how much intermediate precision you will need will
depend upon a precise numeric analysis of the algorithm.


*Usually* when people are asked to calculate Pi to a particular number of
significant digits, and that number of digits is realistically achievable
within the limits of IEEE double precision, what they are being asked is to
do a numeric calculation iteratively, and to keep performing iterations until
the point at which it can be proven that additional steps will not affect
the significant digit in question. Which is a very different matter from
performing the calculation itself with a particular number of significant digits.

These things are very messed up as MATLAB always adds stupid numbers here and there because of its 2^-n representation. Sometimes I read a paper and see the results but when I reproduce it with the same parameters (mostly) as in the paper I get different numbers in the 12th or so digit.

Also I tried to develop a simple chopping/truncation code using floor but again MATLAB sometimes adds a small number that ruins everything. My advise is don't trouble yourself with this topic unless it's really important.

"Husam Aldahiyat" <numandina@gmail.com> wrote in message
news:gcdenn$67b$1@fred.mathworks.com...
> These things are very messed up as MATLAB always adds stupid numbers here
> and there because of its 2^-n representation. Sometimes I read a paper and
> see the results but when I reproduce it with the same parameters (mostly)
> as in the paper I get different numbers in the 12th or so digit.

This problem with "stupid numbers" and "2^-n representation" isn't limited
to MATLAB. Try writing up this small C++ function:


#include <iostream>
int main(void)
{
double x = 0.1;
double y = 0.0;
y = x+x+x;
std::cout << "y = " << y << " and y-0.3 = " << y-0.3 << std::endl;
return 0;
}


y-0.3 will not be equal to 0 nor should it be, since x is not exactly one
tenth but is the closest double precision value to one tenth representable
in IEEE double precision.

*snip*

--
Steve Lord
slord@mathworks.com

"Steven Lord" <slord@mathworks.com> wrote in message <gcdg6v$lt9$1@fred.mathworks.com>...
>
> "Husam Aldahiyat" <numandina@gmail.com> wrote in message
> news:gcdenn$67b$1@fred.mathworks.com...
> > These things are very messed up as MATLAB always adds stupid numbers here
> > and there because of its 2^-n representation. Sometimes I read a paper and
> > see the results but when I reproduce it with the same parameters (mostly)
> > as in the paper I get different numbers in the 12th or so digit.
>
> This problem with "stupid numbers" and "2^-n representation" isn't limited
> to MATLAB. Try writing up this small C++ function:
>
>
> #include <iostream>
> int main(void)
> {
> double x = 0.1;
> double y = 0.0;
> y = x+x+x;
> std::cout << "y = " << y << " and y-0.3 = " << y-0.3 << std::endl;
> return 0;
> }
>
>
> y-0.3 will not be equal to 0 nor should it be, since x is not exactly one
> tenth but is the closest double precision value to one tenth representable
> in IEEE double precision.
>
> *snip*

Lack of understanding leads to finger-pointing and accusations as ever. What can you do?

Maybe there is a way of using ML to demonstrate the foibles of different number representations? A selling point rather than the same answer over and over again to the next crowd of un-washeds?

I never said MATLAB was the only language with this problem, so I don't know what you're trying to prove there, buddy.

I think the scientist Babbage tried to make a mechanical computer that uses decimal representation for numbers using little gears or something. If that computer ran MATLAB (in a world where computers were mechanical instead of electrical, maybe in another dimension) we wouldn't have theseproblems with significant digits :p

Husam Aldahiyat wrote:
> These things are very messed up as MATLAB always adds stupid numbers here and there
> because of its 2^-n representation.

Matlab uses the processor's native IEEE 754 binary floating point representations.
This is an international standard since 1985. The allowance for decimal arithmetic
was incorporated into the standard only earlier this year, 2008, and few processors
support it yet; certainly you cannot blame Matlab for not supporting a new
method of doing fundamental arithmetic when the standard on how to do so was not
even standardized until after the current version Matlab (R2008a) was released!

> Sometimes I read a paper and see the results
> but when I reproduce it with the same parameters (mostly) as in the paper I get
> different numbers in the 12th or so digit.

That probably isn't due to the binary floating point representation: that is probably
due to differences in rounding modes. IEEE 754 defines several rounding modes,
many of which are optional (if I recall correctly), and different processors
implement different rounding modes. In some cases, using different rounding modes
can be significantly slower on some processors. The majority of programs do not
force particular rounding modes and instead the current processor rounding mode
(which might have been set by the operating system.) Matlab in MS Windows allows
the user to control the rounding mode to some extent.

Another factor to take into account is that Pentium V class processors (but
not necessarily their clones) do arithmetic internally at 80 bits instead of at
64 bits. For performance, programs written in other computer languages may
stream together these 80 bit in-register operations, using a chain of
extended precision calculations. This is a technical violation of IEEE 754, which
allows the processor to perform the calculation in however many extended bits
it wants, but requires that at -each step- that the number be rounded as if
the calculation had been done in 64 bit registers.

> Also I tried to develop a simple chopping/truncation code using floor but again MATLAB sometimes adds a small number that ruins everything.

I don't think you understand the fundamental limitations of computer arithmetic.

Suppose Matlab did not use binary floating point arithmetic. Suppose it did floating
point arithmetic in some other base, B, that all numbers were expressed as
integral multiples of B^n (n possibly negative). Like trinary (B=3) or decimal
(B=10). Now, take any number P such that P and B are relatively prime --
for example, P=7 is relatively prime to B=3 or B=10 (but would not be if
you happened to be using a base 21 numbering system for example.). Now
express 1/P as an exact integral multiple of B^n for some n. You simply cannot
do it: if the numeric base B is relatively prime to the number whose reciprical
is being taken, then 1/P will have an infinite expansion in base B.
For example, 1/7 in trinary (B=3) is 0.(0102120)repeated. No matter how
many finite digits you have in your floating point expansion, at -some- point
you will have to truncate the expansion, and at that point the representation
of 1/P will stop being exact. Similarily, 1/3, 1/6, 1/7, 1/9, 1/11, 1/12, 1/13,
1/14, 1/15, 1/17, 1/18, 1/19 (etc) have no *possible* exact floating point
representation in base 10 arithmetic. And there are an infinite number of these
"*cannot* -possibly- be exactly represented" numbers for any fixed integer base B.

If you want to expand into a more complex scheme such as variable integer bases
rather than a fixed integer base, you still run into the problem that there are
an uncountable number of numbers that cannot possibly be represented that way:
the transcendental numbers:
http://en.wikipedia.org/wiki/Transcendental_number

Thank you Walter Roberson. I learned something and corrected a previous mistake.

Walter Roberson <roberson@hushmail.com> wrote in message <dfsGk.44954$aM2.42397@newsfe10.iad>...
> Husam Aldahiyat wrote:
> > These things are very messed up as MATLAB always adds stupid numbers here and there
> > because of its 2^-n representation.
>
> Matlab uses the processor's native IEEE 754 binary floating point representations.
> This is an international standard since 1985. The allowance for decimal arithmetic
> was incorporated into the standard only earlier this year, 2008, and few processors
> support it yet; certainly you cannot blame Matlab for not supporting a new
> method of doing fundamental arithmetic when the standard on how to do so was not
> even standardized until after the current version Matlab (R2008a) was released!
>
> > Sometimes I read a paper and see the results
> > but when I reproduce it with the same parameters (mostly) as in the paper I get
> > different numbers in the 12th or so digit.
>
> That probably isn't due to the binary floating point representation: that is probably
> due to differences in rounding modes. IEEE 754 defines several rounding modes,
> many of which are optional (if I recall correctly), and different processors
> implement different rounding modes. In some cases, using different rounding modes
> can be significantly slower on some processors. The majority of programs do not
> force particular rounding modes and instead the current processor rounding mode
> (which might have been set by the operating system.) Matlab in MS Windows allows
> the user to control the rounding mode to some extent.
>
> Another factor to take into account is that Pentium V class processors (but
> not necessarily their clones) do arithmetic internally at 80 bits instead of at
> 64 bits. For performance, programs written in other computer languages may
> stream together these 80 bit in-register operations, using a chain of
> extended precision calculations. This is a technical violation of IEEE 754, which
> allows the processor to perform the calculation in however many extended bits
> it wants, but requires that at -each step- that the number be rounded as if
> the calculation had been done in 64 bit registers.
>
> > Also I tried to develop a simple chopping/truncation code using floor but again MATLAB sometimes adds a small number that ruins everything.
>
> I don't think you understand the fundamental limitations of computer arithmetic.
>
> Suppose Matlab did not use binary floating point arithmetic. Suppose it did floating
> point arithmetic in some other base, B, that all numbers were expressed as
> integral multiples of B^n (n possibly negative). Like trinary (B=3) or decimal
> (B=10). Now, take any number P such that P and B are relatively prime --
> for example, P=7 is relatively prime to B=3 or B=10 (but would not be if
> you happened to be using a base 21 numbering system for example.). Now
> express 1/P as an exact integral multiple of B^n for some n. You simply cannot
> do it: if the numeric base B is relatively prime to the number whose reciprical
> is being taken, then 1/P will have an infinite expansion in base B.
> For example, 1/7 in trinary (B=3) is 0.(0102120)repeated. No matter how
> many finite digits you have in your floating point expansion, at -some- point
> you will have to truncate the expansion, and at that point the representation
> of 1/P will stop being exact. Similarily, 1/3, 1/6, 1/7, 1/9, 1/11, 1/12, 1/13,
> 1/14, 1/15, 1/17, 1/18, 1/19 (etc) have no *possible* exact floating point
> representation in base 10 arithmetic. And there are an infinite number of these
> "*cannot* -possibly- be exactly represented" numbers for any fixed integer base B.
>
> If you want to expand into a more complex scheme such as variable integer bases
> rather than a fixed integer base, you still run into the problem that there are
> an uncountable number of numbers that cannot possibly be represented that way:
> the transcendental numbers:
> http://en.wikipedia.org/wiki/Transcendental_number

"Husam Aldahiyat" <numandina@gmail.com> wrote in message
news:gcdj4t$m53$1@fred.mathworks.com...
>I never said MATLAB was the only language with this problem, so I don't
>know what you're trying to prove there, buddy.

It wasn't clear from your comment "because of its 2^-n representation"
whether you were aware that behavior is not specific to MATLAB. I just
wanted to point out that it's not.

> I think the scientist Babbage tried to make a mechanical computer that
> uses decimal representation for numbers using little gears or something.
> If that computer ran MATLAB (in a world where computers were mechanical
> instead of electrical, maybe in another dimension) we wouldn't have
> theseproblems with significant digits :p

I know from your use of :p that you intended this as a joke, but on a
serious note, we would still have problems with significant digits even if
we were using decimal calculators instead of binary calculators. It would
just happen with 1/3 instead of 1/10, because in decimal you can exactly
represent 1/10 in a finite number of decimal places (0.1) but you can't
exactly represent 1/3 (0.3333333...) As an example, perform these
computations using pencil and paper to six [or any finite number of your
choice] decimal places:


x = 1;
y = 3;
z = x/y;
one = z+z+z


Is one exactly equal to 1? No, it isn't, since z is not exactly equal to
one third. [Remember, you computed z to a finite number of decimal places.]
The value z is the closest representation to one third in the N decimal
place number representation. Things are a little more complicated in IEEE
double precision (since now you need to work with exponents as well) but
they're similar.

--
Steve Lord
slord@mathworks.com