Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
'find' returns non-integer indices (potential bug?)

Subject: 'find' returns non-integer indices (potential bug?)

From: Tamar Friedlander

Date: 30 Dec, 2008 13:38:01

Message: 1 of 18

After extensive use in a simiulation, it occurs once in a while that 'find' returns non-integer indices! (happened in Matlab 7.5.0)

Typing the index in a long format I received something like: 61,143.000001. Trying to round the indices didn't help either.

This happens at different timings and seems unrelated to the simulation code, and is unreproducible if the very same code line is retyped.

Is it a bug or could I be misusing 'find'?
Does anyone know how to avoid it (except for re-writing the code which will not use 'find')?

Subject: 'find' returns non-integer indices (potential bug?)

From: Rune Allnor

Date: 30 Dec, 2008 14:53:32

Message: 2 of 18

On 30 Des, 14:38, "Tamar Friedlander" <tammy_in_the_an...@yahoo.com>
wrote:
> After extensive use in a simiulation, it occurs once in a while that 'find' returns non-integer indices! (happened in Matlab 7.5.0)

Do you have an example where this happens?

> Typing the index in a long format I received something like: 61,143.000001. Trying to round the indices didn't help either.
>
> This happens at different timings and seems unrelated to the simulation code, and is unreproducible if the very same code line is retyped.
>
> Is it a bug or could I be misusing 'find'?
> Does anyone know how to avoid it (except for re-writing the code which will not use 'find')?

This is likely a consequence of matlab not being a typed language.
Everything is represented as double-precision floating point numbers.
Integers are represented as floats to within numerical precision.
In the example above it seems that the deviation from the integer
value happens at the significant digit near the floating point
accuracy.

Rune

Subject: 'find' returns non-integer indices (potential bug?)

From: Loren Shure

Date: 30 Dec, 2008 15:38:52

Message: 3 of 18

In article <gjd87p$q3m$1@fred.mathworks.com>,
tammy_in_the_andes@yahoo.com says...
> After extensive use in a simiulation, it occurs once in a while that 'find' returns non-integer indices! (happened in Matlab 7.5.0)
>
> Typing the index in a long format I received something like: 61,143.000001. Trying to round the indices didn't help either.
>
> This happens at different timings and seems unrelated to the simulation code, and is unreproducible if the very same code line is retyped.
>
> Is it a bug or could I be misusing 'find'?
> Does anyone know how to avoid it (except for re-writing the code which will not use 'find')?
>
>
>

Are you sure you are not doing some arithmetic after the call to find
that causes this? Perhaps you can narrow down code to a reproducible
example and post that code.

--
Loren
http://blogs.mathworks.com/loren

Subject: 'find' returns non-integer indices (potential bug?)

From: Steve Eddins

Date: 30 Dec, 2008 15:53:04

Message: 4 of 18

Rune Allnor wrote:
> On 30 Des, 14:38, "Tamar Friedlander" <tammy_in_the_an...@yahoo.com>
> wrote:
>> After extensive use in a simiulation, it occurs once in a while that 'find' returns non-integer indices! (happened in Matlab 7.5.0)
>
> Do you have an example where this happens?
>
>> Typing the index in a long format I received something like: 61,143.000001. Trying to round the indices didn't help either.
>>
>> This happens at different timings and seems unrelated to the simulation code, and is unreproducible if the very same code line is retyped.
>>
>> Is it a bug or could I be misusing 'find'?
>> Does anyone know how to avoid it (except for re-writing the code which will not use 'find')?
>
> This is likely a consequence of matlab not being a typed language.

MATLAB is a dynamically typed language.

> Everything is represented as double-precision floating point numbers.

That hasn't been true for more than ten years.

> Integers are represented as floats to within numerical precision.

Although that's no longer always true, it is accurate with respect to
the output of find, which does return double-precision floats. However,
there is no floating-point arithmetic going on in the internal code. If
find really is returning a noninteger value, it's a plain ol' bug having
nothing whatever to do with types, floating-point, etc.

However, I do not usually start out by assuming a trouble report is
really a bug, especially in this case, where I haven't yet seen a line
of code. So I don't really know how find has been called, and if
anything else might have operated on the output from find between the
call and when the output was displayed. For all we know from the
information posted so far, the root cause could be a user-written
MEX-file that has corrupted MATLAB's internal data structures. Or maybe
earlier code has actually assigned a value to a variable called "find",
so that later code is actually indexing into that variable instead of
calling the function "find". Either of those explanations strike me as
more likely than an actual bug in find.

To the original poster, Tamar, I suggest setting a conditional
breakpoint on the line containing the call to find, so that the debugger
will stop there if any of the output values are nonempty. You might be
able to find a reproducible test case that way. Oh, and double-check
that you aren't using "find" as a variable name somewhere.

---
Steve Eddins
http://blogs.mathworks.com/steve/

Subject: 'find' returns non-integer indices (potential bug?)

From: Tamar Friedlander

Date: 30 Dec, 2008 15:59:02

Message: 5 of 18

My code (a little simplified) is this:

dilution = rand (size(S)) > ((length(S) - N0) / length(S));
diluted_S = S (find(dilution));
S = diluted_S;

There is no arithmetics involved. What I do is randomly choose some of the indices in 'S' and throw them away.

Occassionally, this causes an error with error message about non-integer indices, while most of the time the code works properly.
I checked, and to my surprise the indices returned by 'find' were indeed non-integers!

Any idea?

Thanks,
Tamar.

Loren Shure <loren@mathworks.com> wrote in message <MPG.23c40a995544ece0989912@news.mathworks.com>...
> In article <gjd87p$q3m$1@fred.mathworks.com>,
> tammy_in_the_andes@yahoo.com says...
> > After extensive use in a simiulation, it occurs once in a while that 'find' returns non-integer indices! (happened in Matlab 7.5.0)
> >
> > Typing the index in a long format I received something like: 61,143.000001. Trying to round the indices didn't help either.
> >
> > This happens at different timings and seems unrelated to the simulation code, and is unreproducible if the very same code line is retyped.
> >
> > Is it a bug or could I be misusing 'find'?
> > Does anyone know how to avoid it (except for re-writing the code which will not use 'find')?
> >
> >
> >
>
> Are you sure you are not doing some arithmetic after the call to find
> that causes this? Perhaps you can narrow down code to a reproducible
> example and post that code.
>
> --
> Loren
> http://blogs.mathworks.com/loren

Subject: 'find' returns non-integer indices (potential bug?)

From: Rune Allnor

Date: 30 Dec, 2008 16:07:30

Message: 6 of 18

On 30 Des, 16:53, Steve Eddins <Steve.Edd...@mathworks.com> wrote:
> Rune Allnor wrote:
> > On 30 Des, 14:38, "Tamar Friedlander" <tammy_in_the_an...@yahoo.com>
> > wrote:
> >> After extensive use in a simiulation, it occurs once in a while that '=
find' returns non-integer indices! (happened in Matlab 7.5.0)
...
> > Integers are represented as floats to within numerical precision.
>
> Although that's no longer always true, it is accurate with respect to
> the output of find, which does return double-precision floats. =A0However=
,
> there is no floating-point arithmetic going on in the internal code.

It doesn't need to be. All it takes to generate this type of error
is a 'sufficiently large' round-off error when representing the
integer as a float. But those errors ought to be on the order of
numerical precision, eps('double'), which is a bit smaller than
1e-12.

> =A0If
> find really is returning a noninteger value, it's a plain ol' bug having
> nothing whatever to do with types, floating-point, etc.

FIND has been around a bit too long for such a bug to have
survived. But as you say, there could be any one of several
reasons to cause the error - it would help to see some code.

Rune

Subject: 'find' returns non-integer indices (potential bug?)

From: Tamar Friedlander

Date: 30 Dec, 2008 16:10:03

Message: 7 of 18

Hi,

I am not using 'find' as a variable, and there is no MEX-file involved in my code either.

Tamar.

Steve Eddins <Steve.Eddins@mathworks.com> wrote in message <gjdg50$st3$1@fred.mathworks.com>...
> Rune Allnor wrote:
> > On 30 Des, 14:38, "Tamar Friedlander" <tammy_in_the_an...@yahoo.com>
> > wrote:
> >> After extensive use in a simiulation, it occurs once in a while that 'find' returns non-integer indices! (happened in Matlab 7.5.0)
> >
> > Do you have an example where this happens?
> >
> >> Typing the index in a long format I received something like: 61,143.000001. Trying to round the indices didn't help either.
> >>
> >> This happens at different timings and seems unrelated to the simulation code, and is unreproducible if the very same code line is retyped.
> >>
> >> Is it a bug or could I be misusing 'find'?
> >> Does anyone know how to avoid it (except for re-writing the code which will not use 'find')?
> >
> > This is likely a consequence of matlab not being a typed language.
>
> MATLAB is a dynamically typed language.
>
> > Everything is represented as double-precision floating point numbers.
>
> That hasn't been true for more than ten years.
>
> > Integers are represented as floats to within numerical precision.
>
> Although that's no longer always true, it is accurate with respect to
> the output of find, which does return double-precision floats. However,
> there is no floating-point arithmetic going on in the internal code. If
> find really is returning a noninteger value, it's a plain ol' bug having
> nothing whatever to do with types, floating-point, etc.
>
> However, I do not usually start out by assuming a trouble report is
> really a bug, especially in this case, where I haven't yet seen a line
> of code. So I don't really know how find has been called, and if
> anything else might have operated on the output from find between the
> call and when the output was displayed. For all we know from the
> information posted so far, the root cause could be a user-written
> MEX-file that has corrupted MATLAB's internal data structures. Or maybe
> earlier code has actually assigned a value to a variable called "find",
> so that later code is actually indexing into that variable instead of
> calling the function "find". Either of those explanations strike me as
> more likely than an actual bug in find.
>
> To the original poster, Tamar, I suggest setting a conditional
> breakpoint on the line containing the call to find, so that the debugger
> will stop there if any of the output values are nonempty. You might be
> able to find a reproducible test case that way. Oh, and double-check
> that you aren't using "find" as a variable name somewhere.
>
> ---
> Steve Eddins
> http://blogs.mathworks.com/steve/

Subject: 'find' returns non-integer indices (potential bug?)

From: Steve Eddins

Date: 30 Dec, 2008 16:22:44

Message: 8 of 18

Tamar Friedlander wrote:
> My code (a little simplified) is this:
>
> dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> diluted_S = S (find(dilution));
> S = diluted_S;
>
> There is no arithmetics involved. What I do is randomly choose some of the indices in 'S' and throw them away.
>
> Occassionally, this causes an error with error message about non-integer indices, while most of the time the code works properly.
> I checked, and to my surprise the indices returned by 'find' were indeed non-integers!
>
> Any idea?
>
> Thanks,
> Tamar.

Use dbstop if error to stop when the error occurs to try to get a
reproducible test case. When stopped in the debugger, try this at the
command line:

    which -all find

If you get a reproducible test case, consider contacting tech support
(www.mathworks.com/support/).

You don't really need to the call to find in your code. You could do this:

     diluted_S = S(dilution);

---
Steve Eddins
http://blogs.mathworks.com/steve/

Subject: 'find' returns non-integer indices (potential bug?)

From: Tamar Friedlander

Date: 30 Dec, 2008 19:17:01

Message: 9 of 18

Thanks,
Tamar.

Steve Eddins <Steve.Eddins@mathworks.com> wrote in message <gjdhsk$g0g$1@fred.mathworks.com>...
> Tamar Friedlander wrote:
> > My code (a little simplified) is this:
> >
> > dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> > diluted_S = S (find(dilution));
> > S = diluted_S;
> >
> > There is no arithmetics involved. What I do is randomly choose some of the indices in 'S' and throw them away.
> >
> > Occassionally, this causes an error with error message about non-integer indices, while most of the time the code works properly.
> > I checked, and to my surprise the indices returned by 'find' were indeed non-integers!
> >
> > Any idea?
> >
> > Thanks,
> > Tamar.
>
> Use dbstop if error to stop when the error occurs to try to get a
> reproducible test case. When stopped in the debugger, try this at the
> command line:
>
> which -all find
>
> If you get a reproducible test case, consider contacting tech support
> (www.mathworks.com/support/).
>
> You don't really need to the call to find in your code. You could do this:
>
> diluted_S = S(dilution);
>
> ---
> Steve Eddins
> http://blogs.mathworks.com/steve/

Subject: 'find' returns non-integer indices (potential bug?)

From: Jos

Date: 30 Dec, 2008 22:51:03

Message: 10 of 18

"Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gjdgg6$kme$1@fred.mathworks.com>...
> My code (a little simplified) is this:
>
> dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> diluted_S = S (find(dilution));
> S = diluted_S;
>
> There is no arithmetics involved. What I do is randomly choose some of the indices in 'S' and throw them away.
>
> Occassionally, this causes an error with error message about non-integer indices, while most of the time the code works properly.

What was the error message?

> I checked, and to my surprise the indices returned by 'find' were indeed non-integers!

How, precisely, did you check this in the above code?

>
> Any idea?
>

Not yet, you need to give more detailed information.

Jos

Subject: 'find' returns non-integer indices (potential bug?)

From: Tamar Friedlander

Date: 31 Dec, 2008 12:53:01

Message: 11 of 18

I used the code lines I wrote above, and from time to time the program stopped with the error message:

??? Subscript indices must either be real positive integers or logicals.

pointing to the lines I wrote above.

To enquire the source of this problem I substituted the indices into an intermediate variable, and then checked whether they were integers:

dilution = rand (size(S)) > ((length(S) - N0) / length(S));
AA = find(dilution));
   if sum (mod (AA, 1)) ~=0,
       error ('Non-integer index !!!')
 end;

The program occassionally stopped with this error message, meaning that some of the indices were non-integers.

Then I typed in the command window:
>>format long

to present the full representation of these variables.
>>[I,J]=find(mod(AA,1));
>>AA(J)
gave me numbers like:
61143.000001 etc.

I should also add that these line were in a loop that was repeated many times in the program. The problem seemed to occur at a random timing in the program (87th iteration, 52nd iteration and usually not at all).
So I couldn't find any syntax error directly related to my code.
Even after the program stopped with that error message, if I copied the problematic line into the command line, it was run properly and didn't produce the same error message.

Tamar.

"Jos " <#10584@fileexchange.com> wrote in message <gje8km$437$1@fred.mathworks.com>...
> "Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gjdgg6$kme$1@fred.mathworks.com>...
> > My code (a little simplified) is this:
> >
> > dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> > diluted_S = S (find(dilution));
> > S = diluted_S;
> >
> > There is no arithmetics involved. What I do is randomly choose some of the indices in 'S' and throw them away.
> >
> > Occassionally, this causes an error with error message about non-integer indices, while most of the time the code works properly.
>
> What was the error message?
>
> > I checked, and to my surprise the indices returned by 'find' were indeed non-integers!
>
> How, precisely, did you check this in the above code?
>
> >
> > Any idea?
> >
>
> Not yet, you need to give more detailed information.
>
> Jos

Subject: 'find' returns non-integer indices (potential bug?)

From: Matt

Date: 31 Dec, 2008 17:53:02

Message: 12 of 18

"Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gjfpvd$amc$1@fred.mathworks.com>...
> I used the code lines I wrote above, and from time to time the program stopped with the error message:
>
> ??? Subscript indices must either be real positive integers or logicals.
>
> pointing to the lines I wrote above.
>
> To enquire the source of this problem I substituted the indices into an intermediate variable, and then checked whether they were integers:
>
> dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> AA = find(dilution));
> if sum (mod (AA, 1)) ~=0,
> error ('Non-integer index !!!')
> end;
>
> The program occassionally stopped with this error message, meaning that some of the indices were non-integers.


Could you give us size(S), length(S), and N0 so we can try to reproduce this?

Subject: 'find' returns non-integer indices (potential bug?)

From: Tamar Friedlander

Date: 1 Jan, 2009 09:20:02

Message: 13 of 18

"Matt " <mjacobson.removethis@xorantech.com> wrote in message <gjgbhu$hqd$1@fred.mathworks.com>...
> "Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gjfpvd$amc$1@fred.mathworks.com>...
> > I used the code lines I wrote above, and from time to time the program stopped with the error message:
> >
> > ??? Subscript indices must either be real positive integers or logicals.
> >
> > pointing to the lines I wrote above.
> >
> > To enquire the source of this problem I substituted the indices into an intermediate variable, and then checked whether they were integers:
> >
> > dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> > AA = find(dilution));
> > if sum (mod (AA, 1)) ~=0,
> > error ('Non-integer index !!!')
> > end;
> >
> > The program occassionally stopped with this error message, meaning that some of the indices were non-integers.
>
>
> Could you give us size(S), length(S), and N0 so we can try to reproduce this?
>

Hi,
N0=500000;
S is a vector whose length changes randomly in the simulation and is approximately ~510000.
The simulation randomly chooses indices from S and removes them, to make S of length ~500000 again.

Tamar.

Subject: 'find' returns non-integer indices (potential bug?)

From: Matt

Date: 1 Jan, 2009 14:18:01

Message: 14 of 18

"Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gji1s2$c1i$1@fred.mathworks.com>...
> "Matt " <mjacobson.removethis@xorantech.com> wrote in message <gjgbhu$hqd$1@fred.mathworks.com>...
> > "Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gjfpvd$amc$1@fred.mathworks.com>...
> > > I used the code lines I wrote above, and from time to time the program stopped with the error message:
> > >
> > > ??? Subscript indices must either be real positive integers or logicals.
> > >
> > > pointing to the lines I wrote above.
> > >
> > > To enquire the source of this problem I substituted the indices into an intermediate variable, and then checked whether they were integers:
> > >
> > > dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> > > AA = find(dilution));
> > > if sum (mod (AA, 1)) ~=0,
> > > error ('Non-integer index !!!')
> > > end;
> > >
> > > The program occassionally stopped with this error message, meaning that some of the indices were non-integers.
> >
> >
> > Could you give us size(S), length(S), and N0 so we can try to reproduce this?
> >
>
> Hi,
> N0=500000;
> S is a vector whose length changes randomly in the simulation and is approximately ~510000.
> The simulation randomly chooses indices from S and removes them, to make S of length ~500000 again.
>
> Tamar.


It may lead nowhere, but I would try doing

>> feature accel off

and re-run the code to see if it makes a difference. I've seen reports of the JIT accelerator causing weird problems...

Subject: 'find' returns non-integer indices (potential bug?)

From: Roger Stafford

Date: 1 Jan, 2009 16:33:01

Message: 15 of 18

"Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gji1s2$c1i$1@fred.mathworks.com>...
> N0=500000;
> S is a vector whose length changes randomly in the simulation and is approximately ~510000.
> The simulation randomly chooses indices from S and removes them, to make S of length ~500000 again.
>
> Tamar.

  I think you may have a valid basis for a complaint to Mathworks support, Tamar. Reduced to its essentials, you are claiming that when matlab's 'find' function is applied to a half-million-long logical vector which contains 98 percent true values, occasionally the returned indices are not all exact integers. It is very strange that this bug hasn't turned up long before this, so you shouldn't be surprised at a natural reluctance on Mathworks' part to immediately accept this.

  You also said in your original article, "Trying to round the indices didn't help either." I find that equally if not more remarkable. I have never known matlab's 'round' function to fail to return an integer. Are you very sure of this? If so, this would be another and quite different bug. Can you comment further on your statement. Two such unlikely-sounding bugs occurring together might seem to imply there was something about your particular machine or its settings that was causing the errant performance.

  One further check I would recommend. You gave an example of a non-integer, 61143.000001, obtained using 'format long'. I wish you had done 'format hex' on the number so the individual bits could be deciphered from the hex digit display. The number is off from the exact integer 61143 down somewhere in the lower 18 bits out of a total of 53. I wonder what those errant bits are. I am also quite startled that 'round' is incapable of clearing them away if that is what you are saying.

Roger Stafford

Subject: 'find' returns non-integer indices (potential bug?)

From: Tamar Friedlander

Date: 1 Jan, 2009 17:37:01

Message: 16 of 18

"Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in message <gjir7t$ctl$1@fred.mathworks.com>...
> "Tamar Friedlander" <tammy_in_the_andes@yahoo.com> wrote in message <gji1s2$c1i$1@fred.mathworks.com>...
> > N0=500000;
> > S is a vector whose length changes randomly in the simulation and is approximately ~510000.
> > The simulation randomly chooses indices from S and removes them, to make S of length ~500000 again.
> >
> > Tamar.
>
> I think you may have a valid basis for a complaint to Mathworks support, Tamar. Reduced to its essentials, you are claiming that when matlab's 'find' function is applied to a half-million-long logical vector which contains 98 percent true values, occasionally the returned indices are not all exact integers. It is very strange that this bug hasn't turned up long before this, so you shouldn't be surprised at a natural reluctance on Mathworks' part to immediately accept this.
>
> You also said in your original article, "Trying to round the indices didn't help either." I find that equally if not more remarkable. I have never known matlab's 'round' function to fail to return an integer. Are you very sure of this? If so, this would be another and quite different bug. Can you comment further on your statement. Two such unlikely-sounding bugs occurring together might seem to imply there was something about your particular machine or its settings that was causing the errant performance.
>
> One further check I would recommend. You gave an example of a non-integer, 61143.000001, obtained using 'format long'. I wish you had done 'format hex' on the number so the individual bits could be deciphered from the hex digit display. The number is off from the exact integer 61143 down somewhere in the lower 18 bits out of a total of 53. I wonder what those errant bits are. I am also quite startled that 'round' is incapable of clearing them away if that is what you are saying.
>
> Roger Stafford


Regaeding the usage of 'round', in one of my trials to solve the problem I did the following:

dilution = rand (size(S)) > ((length(S) - N0) / length(S));
AA = round (find(dilution));
if sum (mod (AA, 1)) ~=0,
     error ('Non-integer index !!!')
end;

Surprisingly, I still got the same error message after rounding the indices, but I didn't check the 'round' issue any further.

Machine-related (or maybe Matlab version related)? I also suspected there was something about it.
The code was run so far on 3 different machines with different Matlab versions, but the problem appeared only on 2 of them.

Happy new year,
Tamar.
 

Subject: 'find' returns non-integer indices (potential bug?)

From: Matt

Date: 1 Jan, 2009 18:06:02

Message: 17 of 18


> Regaeding the usage of 'round', in one of my trials to solve the problem I did the following:
>
> dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> AA = round (find(dilution));
> if sum (mod (AA, 1)) ~=0,
> error ('Non-integer index !!!')
> end;

That is pretyt bizarre. It might be good to see the full original code.

Subject: 'find' returns non-integer indices (potential bug?)

From: Paul

Date: 2 Jan, 2009 00:10:04

Message: 18 of 18

"Matt " <mjacobson.removethis@xorantech.com> wrote in message <gjj0m9$lne$1@fred.mathworks.com>...
>
> > Regaeding the usage of 'round', in one of my trials to solve the problem I did the following:
> >
> > dilution = rand (size(S)) > ((length(S) - N0) / length(S));
> > AA = round (find(dilution));
> > if sum (mod (AA, 1)) ~=0,
> > error ('Non-integer index !!!')
> > end;
>
> That is pretyt bizarre. It might be good to see the full original code.

Any chance this is being run on one of the old pentium processors that had the math/divide flaw hardwired into the chip?

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us