Thread Subject: Find and precision

I need to use the find function on an array that I've created from a textscan of .txt file. The problem is that I've some data that in my array are in the form:

2.142199999999999 instead of 2.1422.

It's very weird, because in my txt file the data are in the form 2.1422.

So my problem is that, when I use the find function I need to find the row in which is stored the 2.1422, but it didn't match it because the number slightly different. Or at least, I guess so.

Do you have any suggestions?

"Luca Zanotti Fragonara" <Luca_Zanotti@libero.it> wrote in message <gbsv71$7mq$1@fred.mathworks.com>...
> I need to use the find function on an array that I've created from a textscan of .txt file. The problem is that I've some data that in my array are in the form:
>
> 2.142199999999999 instead of 2.1422.
>
> It's very weird, because in my txt file the data are in the form 2.1422.
>
> So my problem is that, when I use the find function I need to find the row in which is stored the 2.1422, but it didn't match it because the number slightly different. Or at least, I guess so.
>
> Do you have any suggestions?


one simple workaround would be to round the numbers to your desired precision

numdigit = 4
multiplicator = 10^4

data = round(data*multiplicator)/multiplicator

this is not elegant but works, of course reading the correct content would be better

Thanks, I think too that this is the only easy way.

"Luca Zanotti Fragonara" <Luca_Zanotti@libero.it> wrote in message <gbt1g5$pea$1@fred.mathworks.com>...
> Thanks, I think too that this is the only easy way.
>

Attempts to round numbers like this won't work. Double precision is unable to store a number like 2.1422 exactly (or most decimals for that matter). So you must bear this in mind when comparing values (do not use ==).

There have been a few posts recently questioning the find function. find simply returns the indices of non-zero elements. Its function does not depend on precision in any way. If you pass the result of a bad comparison to find, it'll probably not return what you'd hoped.

I've make a function, NUMCMP, that works with this problem, but I'm not sure if it is the correct way. The user must specify the precision then the decimal point moves to it, rounds and compares.
Although, before I rest all of the inputs by the minimun data, so the moving decimal won't lead to a huge values (for example, when comparing serial dates up to seconds):

>> numcmp(X,'>=',Y,1) % does: (X>=Y) up to 0.1
>> numcmp(X,'>=',Y,5) % does: (X>=Y) up to 0.00001

so use

>> if numcmp(X,'==',2.1422,5), ...

instead of

>> if (X==2.1422), ...

http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=21190



Carlos Vargas

"Carlos Adrian Vargas Aguilera" <nubeobscura@hotmail.com> wrote in message <gbt77t$q6e$1@fred.mathworks.com>...
> I've make a function, NUMCMP, that works with this problem, but I'm not sure if it is the correct way. The user must specify the precision then the decimal point moves to it, rounds and compares.
> Although, before I rest all of the inputs by the minimun data, so the moving decimal won't lead to a huge values (for example, when comparing serial dates up to seconds):
>
> >> numcmp(X,'>=',Y,1) % does: (X>=Y) up to 0.1
> >> numcmp(X,'>=',Y,5) % does: (X>=Y) up to 0.00001
>
> so use
>
> >> if numcmp(X,'==',2.1422,5), ...
>
> instead of
>
> >> if (X==2.1422), ...
>
> http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=21190
>
>
>
> Carlos Vargas

or just simply

round(10.^5 * X) == round(10.^5 * Y)

Jos

nor ki wrote:
> "Luca Zanotti Fragonara" <Luca_Zanotti@libero.it> wrote in message <gbsv71$7mq$1@fred.mathworks.com>...
>> I need to use the find function on an array that I've created from a textscan
>> of .txt file. The problem is that I've some data that in my array are in the form:
>> 2.142199999999999 instead of 2.1422.
>> It's very weird, because in my txt file the data are in the form 2.1422.
>> So my problem is that, when I use the find function I need to find the row in
>> which is stored the 2.1422, but it didn't match it because the number slightly
>> different. Or at least, I guess so.

> one simple workaround would be to round the numbers to your desired precision

> numdigit = 4
> multiplicator = 10^4
> data = round(data*multiplicator)/multiplicator

No, that doesn't work. Try it yourself:

>> r = rand; sprintf('%.55g\n%.55g', r, round(r*10^4)/10^4)

ans =

0.81472368639317893634910205946653150022029876708984375
0.8146999999999999797495320308371447026729583740234375

If that rounding worked, the second value would be 0.8147 -exactly-.
However, the rounding CANNOT work in any binary floating point number
system, because 1/10 (and hence 1/100, 1/1000 etc) does not have
an exact representation in any finite binary system, just the same
way that you cannot -exactly- represent 1/3 in any finite number
of decimal digits.


You should almost never test for floating point equality. You
should instead test for the value being "close enough". Not

RowsWithMatch = find(any(TheMatrix == 2.1422,2));

but rather something like

RowsWithMatch = find(any(abs(TheMatrix - 2.1422) < 0.0001,2));

where 0.0001 is the (problem-specific) tolerance within which you want
a match to be deemed to have occurred. (The 2 as the second argument of
any() tells any() to look along the rows instead of down the columns.)

This difficulty with inexact representation of numbers applies in *any*
number representation system that uses a finite number of digits -- it
even applies in number representation systems that use variable number bases.
No finite number representation system can -exactly- represent pi
or any other transcendental number.

Walter Roberson <roberson@hushmail.com> wrote in message
>
> No, that doesn't work. Try it yourself:
>
> >> r = rand; sprintf('%.55g\n%.55g', r, round(r*10^4)/10^4)
>
> ans =
>
> 0.81472368639317893634910205946653150022029876708984375
> 0.8146999999999999797495320308371447026729583740234375
>

Understood, and I'm not denying the above results, but(!):

rand('twister',5489) % Get the same number W.R. as above.
r = rand;
.8147 == round(r*10^4)/10^4
ans =

     1

 
> You should almost never test for floating point equality. > You
> should instead test for the value being "close enough".


Agreed!
I am only curious why we get that result that the numbers are equal? Before I became "wiser" to the idea of testing for close enough, I used the "up-down" method of round-then-compare with these types of problems for years. I never found it to fail, probably by luck I admit. Can anyone demonstrate it to fail by following what I did above? For example, calling the next random number:

r = rand;
round(r*10^10)/10^10 == 0.9057919371
ans =

     1


Just curious.

Walter Roberson <roberson@hushmail.com> wrote in message <8QqEk.5075$YN5.2821@newsfe03.iad>...
> nor ki wrote:
> > "Luca Zanotti Fragonara" <Luca_Zanotti@libero.it> wrote in message <gbsv71$7mq$1@fred.mathworks.com>...
> >> I need to use the find function on an array that I've created from a textscan
> >> of .txt file. The problem is that I've some data that in my array are in the form:
> >> 2.142199999999999 instead of 2.1422.
> >> It's very weird, because in my txt file the data are in the form 2.1422.
> >> So my problem is that, when I use the find function I need to find the row in
> >> which is stored the 2.1422, but it didn't match it because the number slightly
> >> different. Or at least, I guess so.
>
> > one simple workaround would be to round the numbers to your desired precision
>
> > numdigit = 4
> > multiplicator = 10^4
> > data = round(data*multiplicator)/multiplicator
>
> No, that doesn't work. Try it yourself:
>
> >> r = rand; sprintf('%.55g\n%.55g', r, round(r*10^4)/10^4)
>
> ans =
>
> 0.81472368639317893634910205946653150022029876708984375
> 0.8146999999999999797495320308371447026729583740234375
>
> If that rounding worked, the second value would be 0.8147 -exactly-.
> However, the rounding CANNOT work in any binary floating point number
> system, because 1/10 (and hence 1/100, 1/1000 etc) does not have
> an exact representation in any finite binary system, just the same
> way that you cannot -exactly- represent 1/3 in any finite number
> of decimal digits.
>
>
> You should almost never test for floating point equality. You
> should instead test for the value being "close enough". Not
>
> RowsWithMatch = find(any(TheMatrix == 2.1422,2));
>
> but rather something like
>
> RowsWithMatch = find(any(abs(TheMatrix - 2.1422) < 0.0001,2));
>
> where 0.0001 is the (problem-specific) tolerance within which you want
> a match to be deemed to have occurred. (The 2 as the second argument of
> any() tells any() to look along the rows instead of down the columns.)
>
> This difficulty with inexact representation of numbers applies in *any*
> number representation system that uses a finite number of digits -- it
> even applies in number representation systems that use variable number bases.
> No finite number representation system can -exactly- represent pi
> or any other transcendental number.

Hello Walter,

thanks for that one

Best
kinor