Prev: How to convert sine wave signal to square wave in Simulink?
Next: eigenvalues and eigenvectors in decreasing order
From: John on 27 Sep 2009 11:09
Hello,

I'm having issues with variable residue due to the 15-16 bit decimal precision that Matlab employs in my model. Here are my steps (values are shown with standard 4 bit display truncation):

1) I'm starting with a value such as 0.2288E-8 .
2) I'm then adding a sample value of 1.6034E-14.
3) I then take off the original 0.2288E-8 and am left with the number in 2) (display wise-you'll see the precision in the next step).
4) I then perform some calculations of an amount to remove from 3) which should be the same value added in 2), but after subtracting I am left with a residue on the order of 4E-25 or so.

This is being performed over an entire vector with varying decimal orders (i.e. 8 and 14 and 8 and 16). The min and max of these residues vary from 1E-22 to 1E-34, or so.

I don't have this problem when I add and remove single values, i.e. put on 0.2288E-8 and then calculate that this is the amount I have to take off, and the same with the value in 2). I end up with a clean 0.

I would figure that the solution is to work with the maximum 34 bit decimal precision as this seems to be the problem, but it's not that simple. Or is it?

Is there a way to increase the precision that Matlab uses? Is there another solution?

Thanks.
From: dpb on 27 Sep 2009 11:57
John wrote:
> Hello,
>
> I'm having issues with variable residue due to the 15-16 bit decimal
> precision that Matlab employs in my model. Here are my steps (values
> are shown with standard 4 bit display truncation):
>
> 1) I'm starting with a value such as 0.2288E-8 .
> 2) I'm then adding a sample value of 1.6034E-14.
> 3) I then take off the original 0.2288E-8 and am left with the number in 2)
> 4) I then perform some calculations of an amount to remove from 3)
> which should be the same value added in 2), but after subtracting I
> am left with a residue on the order of 4E-25 or so.
>
> This is being performed over an entire vector with varying decimal
> orders (i.e. 8 and 14 and 8 and 16). The min and max of these
> residues vary from 1E-22 to 1E-34, or so.
>
> I don't have this problem when I add and remove single values, i.e.
> put on 0.2288E-8 and then calculate that this is the amount I have to
> take off, and the same with the value in 2). I end up with a clean 0.
>
>
> I would figure that the solution is to work with the maximum 34 bit
> decimal precision as this seems to be the problem, but it's not that
> simple. Or is it?
>
> Is there a way to increase the precision that Matlab uses? Is there
> another solution?

I don't see why you wouldn't simply move the "problem" out to another
level no matter how much precision you use. Floating point
representation is finite and the answer is virtually always to modify
the algorithm, _not_ add precision.

I guess I don't see enough about the overall objective/problem to see
why simply a tolerance level at which the result is set identically to
zero wouldn't suffice.

In general, the idea of starting w/ a sizable number and adding values
that have only one or two bits of precision in comparison is an
algorithm/implementation fraught w/ error to start with--I'd recommend
rethinking that for starters.

--
From: Rune Allnor on 27 Sep 2009 12:07
On 27 Sep, 17:09, "John" <shei_o...(a)hotmail.com> wrote:
> Hello,
>
> I'm having issues with variable residue due to the 15-16 bit decimal precision that Matlab employs in my model.

That's the inherent precision of working with double-precision
floating point numbers. It's a fact of life that you can't do
much about.

Rune
From: Sebastiaan on 28 Sep 2009 05:03
> Is there a way to increase the precision that Matlab uses? Is there another solution?
>
If you really have to use a higher precision (at a cost of (much) longer computation times), have a look at:

1) symbolic math toolbox
2) MP: http://www.mathworks.com/matlabcentral/fileexchange/6446
3) Wait until Matlab is shipped with quadruple precision

Sebastiaan
From: John on 28 Sep 2009 14:04
dpb <none(a)non.net> wrote in message <h9o29n$l01$1(a)news.eternal-september.org>...
> John wrote:
> > Hello,
> >
> > I'm having issues with variable residue due to the 15-16 bit decimal
> > precision that Matlab employs in my model. Here are my steps (values
> > are shown with standard 4 bit display truncation):
> >
> > 1) I'm starting with a value such as 0.2288E-8 .
> > 2) I'm then adding a sample value of 1.6034E-14.
> > 3) I then take off the original 0.2288E-8 and am left with the number in 2)
> > 4) I then perform some calculations of an amount to remove from 3)
> > which should be the same value added in 2), but after subtracting I
> > am left with a residue on the order of 4E-25 or so.
> >
> > This is being performed over an entire vector with varying decimal
> > orders (i.e. 8 and 14 and 8 and 16). The min and max of these
> > residues vary from 1E-22 to 1E-34, or so.
> >
> > I don't have this problem when I add and remove single values, i.e.
> > put on 0.2288E-8 and then calculate that this is the amount I have to
> > take off, and the same with the value in 2). I end up with a clean 0.
> >
> >
> > I would figure that the solution is to work with the maximum 34 bit
> > decimal precision as this seems to be the problem, but it's not that
> > simple. Or is it?
> >
> > Is there a way to increase the precision that Matlab uses? Is there
> > another solution?
>
> I don't see why you wouldn't simply move the "problem" out to another
> level no matter how much precision you use. Floating point
> representation is finite and the answer is virtually always to modify
> the algorithm, _not_ add precision.
>
> I guess I don't see enough about the overall objective/problem to see
> why simply a tolerance level at which the result is set identically to
> zero wouldn't suffice.
>
> In general, the idea of starting w/ a sizable number and adding values
> that have only one or two bits of precision in comparison is an
> algorithm/implementation fraught w/ error to start with--I'd recommend
> rethinking that for starters.
>
> --

I hadn't thought of that. Is there a way to round to a certain number of decimal places while maintaining the order? i.e. instead of storing 1.0255E-14 to all of its decimal places, does floating point implementation allow me to simplify how many decimal places are stored in Matlab?
 |  Next  |  Last
Pages: 1 2
Prev: How to convert sine wave signal to square wave in Simulink?
Next: eigenvalues and eigenvectors in decreasing order