matlab decimal precision
in [Matlab]
|
Prev: How to convert sine wave signal to square wave in Simulink?
Next: eigenvalues and eigenvectors in decreasing order
From: Rune Allnor on 28 Sep 2009 14:35 On 28 Sep, 20:04, "John" <shei_o...(a)hotmail.com> wrote: > dpb <n...(a)non.net> wrote in message <h9o29n$l0...(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? No. Floating point formats define the number of significant bits. You can choose between double-precision and single-precision floating point formats, but that's it. If you want a specific number of decimal places you will have to work from fixed-point formats. Rune
From: dpb on 28 Sep 2009 15:27 John wrote: > 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? Well, whatever you choose for the number of significant places (decimal) there will be values which are not exactly representable in a floating point binary fraction. It's no different than in decimal you can write 1/4 exactly as 0.25000.... but 1/3 is a repeating fraction. It's the same in floating point except the fractions are binary fractions, not decimal. So, rounding in decimal to the nearest N significant digits does _NOT_ equate to rounding the trailing bits in the floating point mantissa to zero. What is the actual problem you're trying to solve here? --
From: dpb on 28 Sep 2009 15:34 Got interrupted, sorry... What I was thinking initially re: tolerance was that if it's the small residual you don't like seeing but would rather see zero identically, choose a tolerance value and do something like x(x<tol) = 0.0; where tol is some arbitrary value like 1E-10 or somesuch; whatever is reasonable for your problem space. --
From: dpb on 28 Sep 2009 16:03
dpb wrote: > Got interrupted, sorry... > > What I was thinking initially re: tolerance was that if it's the small > residual you don't like seeing but would rather see zero identically, > choose a tolerance value and do something like > > x(x<tol) = 0.0; > > where tol is some arbitrary value like 1E-10 or somesuch; whatever is > reasonable for your problem space. And, of course, if it's simply one of what you see for values, you can control the display w/ sprintf() and whatever level of precision you want and similarly save data to a file in text format w/ fprintf using the appropriate formatting and let the i/o library do the rounding for you. I'm out of suggestions... :) -- |