Thread Subject:

What a hell is wrong with logical indexing??? Really???

People,

check this out. I always thought I could treat 0-1 resulting from the logical operations as numbers. But apparently not. Why? It is completely unintuitive and dangerous. Can somebody give me a meaning of the following example?

a = rand(100,1);
i = a<0.5;
i = i.^2;
i(i==0) = 2;
unique(i)

ans =

     1
     2

i = a<0.5;
i(i==0) = 2;
unique(i)

ans =

     1

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrujad$fmn$1@fred.mathworks.com>...
> People,
>
> check this out. I always thought I could treat 0-1 resulting from the logical operations as numbers. But apparently not. Why? It is completely unintuitive and dangerous. Can somebody give me a meaning of the following example?
>
> a = rand(100,1);
> i = a<0.5;
> i = i.^2;
> i(i==0) = 2;
> unique(i)
>
> ans =
>
> 1
> 2
>
> i = a<0.5;
> i(i==0) = 2;
> unique(i)
>
> ans =
>
> 1

Try this:
%%%
a = rand(100,1);
i = a<0.5;
i = i.^2;
i(i==0) = 2;
class(i)
unique(i)

%%%
a = rand(100,1);
i = a<0.5;
i(i==0) = 2;
class(i)
unique(i)

%% Explanation
1st case: Squaring the i-vector turns it into a double so that values can be anything.
2nd case: The vector is logical so saying anything other than zero is true and it turns it to 1.

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message
news:hrujad$fmn$1@fred.mathworks.com...
> People,
>
> check this out. I always thought I could treat 0-1 resulting from the
> logical operations as numbers.

Of course.

> But apparently not. Why? It is completely unintuitive and dangerous. Can
> somebody give me a meaning of the following example?
>
> a = rand(100,1);
> i = a<0.5;
> i = i.^2;

The above line converts i from being a _logical_ array into a _double_
array. [You can confirm this by looking at WHOS or by asking for its
CLASS.] When you do so ...

> i(i==0) = 2;

this replaces all 0's in the double array with the double value 2.
Therefore the array has two unique values, as your unique call indicated.

> unique(i)
>
> ans =
>
> 1
> 2
>
> i = a<0.5;
> i(i==0) = 2;

When you perform the above line, you're assigning the double value 2 into a
_logical_ array. Therefore, the double value 2 needs to be converted into a
logical value, and what is it converted into?

>> x = logical(2)

x =

     1

The LOGICAL function converts 0 into false, errors if given a NaN or a
complex value, and converts all other values (1, 2, pi, -73, Inf, 1.234567,
etc.) into true. Therefore, when you perform the above operation the
logical array i contains only true values, and so ...

> unique(i)
>
> ans =
>
> 1

there is only one value in your logical array, true. This is the correct
behavior.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

Nothing seems out of sorts to me. In the first case you are assigning a double to a double. In the second case you are assigning a double to a logical, so MATLAB preserves the logical. Sort of like this:

A = 3;
A(2) = uint8(9);
A(3) = 'r';
whos A

Now as for the warning in your case, yet none in the above example, I question that.

Hi Steve,

thanks for the reply. I don't know about others, but I always cared about logical arrays as simply arrays that contain just 0 and 1's. It is quite disturbing that logical arrays can behave differently from arrays consisting of 0 and 1's (double). You explanation is about how things work in Matlab, and its good to know. But why Matlab should be so obsessed with preserving "logicalness" of the array - that I don't understand. Given than most users probably treat those arrays just like I do.

Really, what's this thing about "logicalness"? Its clearly not needed for the indexing purposes. For example, when I write X(ix), why should I care of ix is double or logical, as long as it contains 0 and 1's?

Sergei

> When you perform the above line, you're assigning the double value 2 into a
> _logical_ array. Therefore, the double value 2 needs to be converted into a
> logical value, and what is it converted into?
>
> >> x = logical(2)
>
> x =
>
> 1
>
> The LOGICAL function converts 0 into false, errors if given a NaN or a
> complex value, and converts all other values (1, 2, pi, -73, Inf, 1.234567,
> etc.) into true. Therefore, when you perform the above operation the
> logical array i contains only true values, and so ...
>
> > unique(i)
> >
> > ans =
> >
> > 1
>
> there is only one value in your logical array, true. This is the correct
> behavior.
>
> --
> Steve Lord
> slord@mathworks.com
> comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
>

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hruo0e$5f8$1@fred.mathworks.com>...
> Hi Steve,
>
> thanks for the reply. I don't know about others, but I always cared about logical arrays as simply arrays that contain just 0 and 1's. It is quite disturbing that logical arrays can behave differently from arrays consisting of 0 and 1's (double). You explanation is about how things work in Matlab, and its good to know. But why Matlab should be so obsessed with preserving "logicalness" of the array - that I don't understand. Given than most users probably treat those arrays just like I do.
>
> Really, what's this thing about "logicalness"? Its clearly not needed for the indexing purposes. For example, when I write X(ix), why should I care of ix is double or logical, as long as it contains 0 and 1's?
>

Let's say it's a double:
A = [4 5 6; 6 7 2];
idx = [1 1 0 0 1 1]; %double
A(idx) is now going to try and reference A(0) which in MATLAB is undefined. It would also be referencing A(1) multiple times. This would be pretty useless but it's very important for other indexing. Such as:
idx = [1 3 5];
A(idx);
     ans = 4 5 6

I doubt anyone with much MATLAB experience has an issue with this functionality.

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hruo0e$5f8$1@fred.mathworks.com>...
>
> Really, what's this thing about "logicalness"? Its clearly not needed for the indexing purposes. For example, when I write X(ix), why should I care of ix is double or logical, as long as it contains 0 and 1's?
>
> Sergei
>

Well, storage of only 1 byte per element rather than 8 bytes for one thing, and no way for floating point errors to mess things up for another.

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hruo0e$5f8$1@fred.mathworks.com>...
> Hi Steve,
>
> thanks for the reply. I don't know about others, but I always cared about logical arrays as simply arrays that contain just 0 and 1's. It is quite disturbing that logical arrays can behave differently from arrays consisting of 0 and 1's (double). You explanation is about how things work in Matlab, and its good to know. But why Matlab should be so obsessed with preserving "logicalness" of the array - that I don't understand. Given than most users probably treat those arrays just like I do.
>
> Really, what's this thing about "logicalness"? Its clearly not needed for the indexing purposes. For example, when I write X(ix), why should I care of ix is double or logical, as long as it contains 0 and 1's?
>
> Sergei

  Sergei, I'll give you an example of why the distinction needs to be made between logical variables and numbers that are 1's and 0's. Suppose that x is equal to the vector [5,7]. Then x([true,true]) would need to be [5,7] according to the rules of logical indexing, while x([1,1]) of necessity has to be equal to [5,5] according to the rules of numerical indexing.

  For this reason Mathworks had no choice but to eventually make this distinction between the two classes, logical and numerical. In the early version of matlab (4b) which I have, the distinction was *not* made and it led to much trouble for me in avoiding this pitfall.

Roger Stafford

"Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in message <hruq21$nef$1@fred.mathworks.com>...
> "Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hruo0e$5f8$1@fred.mathworks.com>...
> > Hi Steve,
> >
> > thanks for the reply. I don't know about others, but I always cared about logical arrays as simply arrays that contain just 0 and 1's. It is quite disturbing that logical arrays can behave differently from arrays consisting of 0 and 1's (double). You explanation is about how things work in Matlab, and its good to know. But why Matlab should be so obsessed with preserving "logicalness" of the array - that I don't understand. Given than most users probably treat those arrays just like I do.
> >
> > Really, what's this thing about "logicalness"? Its clearly not needed for the indexing purposes. For example, when I write X(ix), why should I care of ix is double or logical, as long as it contains 0 and 1's?
> >
> > Sergei
>
> Sergei, I'll give you an example of why the distinction needs to be made between logical variables and numbers that are 1's and 0's. Suppose that x is equal to the vector [5,7]. Then x([true,true]) would need to be [5,7] according to the rules of logical indexing, while x([1,1]) of necessity has to be equal to [5,5] according to the rules of numerical indexing.
>
> For this reason Mathworks had no choice but to eventually make this distinction between the two classes, logical and numerical. In the early version of matlab (4b) which I have, the distinction was *not* made and it led to much trouble for me in avoiding this pitfall.
>
> Roger Stafford

Can you give an explanation for why Matlab shouldn't assume that a double array containing only 0s and 1s is intended as a logical index? It would encourage bad style, but as far as I can see it would be totally unambiguous.

> Can you give an explanation for why Matlab shouldn't assume that a double array containing only 0s and 1s is intended as a logical index? It would encourage bad style, but as far as I can see it would be totally unambiguous.
===================

To see that it would be ambiguous, consider the following example and the different behavior that each gives

>> a=10:10:50 %data

a =

    10 20 30 40 50

>> a([1 1 1 1]) %treats the 1s as doubles

ans =

    10 10 10 10


>> a(logical([1 1 1 1])) %treats the 1s as logicals

ans =

    10 20 30 40

>
> Can you give an explanation for why Matlab shouldn't assume that a double array containing only 0s and 1s is intended as a logical index? It would encourage bad style, but as far as I can see it would be totally unambiguous.

% Well if

a = [1 2 3]

% What would be a([1 1 1])?

a(logical([1 1 1]))
a(double([1 1 1]))

% Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hrv26k$q4e$1@fred.mathworks.com>...
>
> >
> > Can you give an explanation for why Matlab shouldn't assume that a double array containing only 0s and 1s is intended as a logical index? It would encourage bad style, but as far as I can see it would be totally unambiguous.
>
> % Well if
>
> a = [1 2 3]
>
> % What would be a([1 1 1])?
>
> a(logical([1 1 1]))
> a(double([1 1 1]))
>
> % Bruno

Right... but that doesn't address my question. Your index array has only 1s. My question concerns the following situation:

>>unique(indexArray)
  [0 1]

Why doesn't Matlab interpret such an array as logical? It would encourage the use of double arrays as logical, which would cause confusion when, for example, a double array suddenly becomes all ones. But why not interpret it as logical, and produce a warning, rather than just producing an error?

I myself have no problem with explicitly converting a double array to logical, I'm just curious what the reasoning is behind this behavior.

"Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in message <hruq21$nef$1@fred.mathworks.com>...

.....

> For this reason Mathworks had no choice but to eventually make this distinction between the two classes, logical and numerical. In the early version of matlab (4b) which I have, the distinction was *not* made and it led to much trouble for me in avoiding this pitfall.
>
> Roger Stafford

Roger, I think yours is one of the best answers. The answers of the sort "Matlab does it like this therefore it should be like this period" are not really inspiring. Still, if you read all of the answers, they are about the same thing: how logicalness of an array can be important for the indexing reasons. While they are informative, still they sort of miss the grain of my example - and the reason for my outrage: when I have logical array on the LHS of the equation, Matlab did something quite unintuitive - it tried to preserve the logical nature of an array, even at the expense of misleading me! Really, when I write a(a==0) = 2 - I expect to have 2's at the place of zeros. I understand logicalness is an important thing, but having correct computations that meet user's expectations is the need number one.

"Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message <hrv2en$d9t$1@fred.mathworks.com>...

> Right... but that doesn't address my question. Your index array has only 1s. My question concerns the following situation:
>
> >>unique(indexArray)
> [0 1]
>
> Why doesn't Matlab interpret such an array as logical?
==============

You're suggesting that indexArray should give one kind of behavior if it contains only 1s and another kind of behavior if it contains 0s as well?

That would at minimum require additional overhead and pre-checking for the presence of zeros.

Aside from that, if indexArray is generated programmatically, you wouldn't know in advance what the composition of 1s and 0s in indexArray will be. You would therefore have to write additional code everytime you wanted to process indexArray: one block to handle a mixture of 0s and 1s and one block to handle the special case where only 1s are present.

"Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <hrv36g$30g$1@fred.mathworks.com>...
> "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message <hrv2en$d9t$1@fred.mathworks.com>...
>
> > Right... but that doesn't address my question. Your index array has only 1s. My question concerns the following situation:
> >
> > >>unique(indexArray)
> > [0 1]
> >
> > Why doesn't Matlab interpret such an array as logical?
> ==============
>
> You're suggesting that indexArray should give one kind of behavior if it contains only 1s and another kind of behavior if it contains 0s as well?
>
> That would at minimum require additional overhead and pre-checking for the presence of zeros.
>
> Aside from that, if indexArray is generated programmatically, you wouldn't know in advance what the composition of 1s and 0s in indexArray will be. You would therefore have to write additional code everytime you wanted to process indexArray: one block to handle a mixture of 0s and 1s and one block to handle the special case where only 1s are present.

Matt, what would you say about my last post? Do you agree that there should be at least a warning when someone tries to write double into logical? Can you think of any reasons of why preserving logicalness takes precedent? Even if I try to use that array for indexing later, I already know that its not logical, b/c it contains '2'. Also, if it has zeros, Matlab would give me an error, and that's fine. They should do something about this.

> Why doesn't Matlab interpret such an array as logical?

Simply because there is no reason for an algorithm to make any pre assumption about the content of the array.

Assume we have the code:

a = rand(1,2);
b = double(a>0.5)
c = a(b)

Do you want the content of c to be? There are 1/4 chance that b does not contains any 0. So sometime (~1/4) it will return duplicated

a([1 1])

The rest of the time (~3/4) it returns

a(a>0.5);

Do you prefer the above code behave in a random manner with a?

That's how a bad code is built: ill-defined thus unpredicted behavior.

Bruno

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv34k$sic$1@fred.mathworks.com>...
> I understand logicalness is an important thing, but having correct computations that meet user's expectations is the need number one.

No *consistent* behavior is the absolute priority. User expectation comes later, much later.

There should be no room for interpretation in programming.

Bruno

"Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message <hrv1e8$63j$1@fred.mathworks.com>...
> Can you give an explanation for why Matlab shouldn't assume that a double array containing only 0s and 1s is intended as a logical index? It would encourage bad style, but as far as I can see it would be totally unambiguous.
- - - - - - - -
  Alan, you are really missing the point here! Think carefully about what we have said.

  As I know all too well to my sorrow, when a program generates either numerical indices or logical values, there may be no way in advance to know if you might happen to generate, on the one hand all 1's, or on the other hand all true values. In such a case, which can happen all too frequently, there would be no way for matlab to distinguish between the two meanings unless there is a firm understanding about the difference between the two types of variables.

  In my own ancient system where no such distinction was made, the system makes the logical interpretation in case of such ambiguity. That means numerical indexing schemes that otherwise might work very well will often bomb out in such cases, and that in my opinion is totally unacceptable. Even if Mathworks had decided on the opposite interpretation, it would be logical indexing that would sometimes get screwed up. The change they made was absolutely necessary.

Roger Stafford

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message
news:hrv34k$sic$1@fred.mathworks.com...
> "Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in
> message <hruq21$nef$1@fred.mathworks.com>...
>
> .....
>
>> For this reason Mathworks had no choice but to eventually make this
>> distinction between the two classes, logical and numerical. In the early
>> version of matlab (4b) which I have, the distinction was *not* made and
>> it led to much trouble for me in avoiding this pitfall.
>>
>> Roger Stafford
>
> Roger, I think yours is one of the best answers. The answers of the sort
> "Matlab does it like this therefore it should be like this period" are not
> really inspiring. Still, if you read all of the answers, they are about
> the same thing: how logicalness of an array can be important for the
> indexing reasons. While they are informative, still they sort of miss the
> grain of my example - and the reason for my outrage: when I have logical
> array on the LHS of the equation, Matlab did something quite unintuitive -
> it tried to preserve the logical nature of an array, even at the expense
> of misleading me! Really, when I write a(a==0) = 2 - I expect to have 2's
> at the place of zeros. I understand logicalness is an important thing, but
> having correct computations that meet user's expectations is the need
> number one.

So let's take another example, and because logical has only a small number
of values it can take on I'm switching to uint8. The principles are the
same, though.

x = uint8(1:10);
x(x==5) = pi

What should the contents and data type of x be? Remember, pi is not an
integer value and so CANNOT be exactly represented as a uint8. Should we
automatically blow x up into the data type of pi (aka double)? Or should we
convert pi into uint8 (with the result being a uint8 with the value 3) and
the resulting x remains uint8?


Now how about this example:

x = uint8(1:10);
x(x==5) = 1;

What should the contents and data type of x be? Should we automatically
blow x up into the data type of 1 (aka double)? Or should we convert 1 into
uint8 and have x remain uint8? Is your answer to this question consistent
with your answer above?


One more example, and the question is the same -- can you tell me what the
contents and data type of x should be after executing this code?

y = input('Enter a scalar value. ');
x = uint8(1:10);
x(x==5) = y;

"The data type depends on what the user entered for y" is not, IMO, a good
answer.


When performing subscripted assignment with parentheses like this, here's
the rule.

    If the left-hand side (LHS) is not the same data type as the right-hand
side (RHS) then the RHS data is converted into the type of LHS and then the
converted data is inserted into LHS.

I think that's a very consistent rule (and so I estimate about 30 seconds
after I post, someone will remind me of a case I've forgotten where it
doesn't hold true. "Subscripting-as-evaluation", like function handles,
doesn't count, and neither does the case where a class author specifically
and explicitly overloads subscripted assignment.) I don't want to have the
special case "unless RHS contains values that don't 'fit' in which case we
convert everything to the class of RHS." at the end of that rule unless it's
absolutely necessary, and IMO it's not.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

"Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <hrv36g$30g$1@fred.mathworks.com>...
> "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message <hrv2en$d9t$1@fred.mathworks.com>...
>
> > Right... but that doesn't address my question. Your index array has only 1s. My question concerns the following situation:
> >
> > >>unique(indexArray)
> > [0 1]
> >
> > Why doesn't Matlab interpret such an array as logical?
> ==============
>
> You're suggesting that indexArray should give one kind of behavior if it contains only 1s and another kind of behavior if it contains 0s as well?
>
> That would at minimum require additional overhead and pre-checking for the presence of zeros.
>
> Aside from that, if indexArray is generated programmatically, you wouldn't know in advance what the composition of 1s and 0s in indexArray will be. You would therefore have to write additional code everytime you wanted to process indexArray: one block to handle a mixture of 0s and 1s and one block to handle the special case where only 1s are present.

Matt, Bruno, Roger, I don't think my question is so outrageous...

I remember an example of a standard Matlab function that computes some statistical metric on arrays columnwise, except when the input is a 3x3. In this case, it reverts to row-wise, or maybe does some 2-dimensional calculation. Unfortunately I do not remember the name of the function, and I may not be recalling the details correctly, but the point is that Matlab is not necessarily 100% consistent. Does anyone else know what I'm talking about?

I'm not arguing FOR inconsistency, just observing that, if I recall correctly, Matlab doesn't have a perfect track record.

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv3lh$44d$1@fred.mathworks.com>...

> Matt, what would you say about my last post? Do you agree that there should be at least a warning when someone tries to write double into logical?
==============

No. You seem to think the user should be free to treat logicals as equivalent to double arrays of 0s and 1s, but I don't really see why.

>Can you think of any reasons of why preserving logicalness takes precedent?
==============

It's a universal rule in MATLAB that whenever you write a scalar of type A to an array element of type B, then a conversion from A to B takes place. Deviating from this rule for logicals only would create confusion and doesn't really make sense.

Consider for example

>> a=uint8(1:3)

a =

    1 2 3

>> a(1)=pi

a =

    3 2 3

You seem to think the result of this should have been

a =

    3.1416 2.0000 3.0000

but it seems purely subjective to me as to which casting precedence is the better one.

Sergei Koulayev wrote:
> Really, when I write a(a==0) = 2 -
> I expect to have 2's at the place of zeros. I understand logicalness is
> an important thing, but having correct computations that meet user's
> expectations is the need number one.

*My* expectation is that when I make an indexed assignment into a
variable, that the variable will not change type underneath me according
to the type of what was assigned in.

What next
A = 'Hello'; A(3) = 37;
I wrote a number in there, so the character string should become
numeric?? Or only if the number written in is non-integral or negative
or exceeds 65537 and is thus not representable as a character?
(Characters have been 16 bits internally since unicode was fully
integrated.)

A = uint8(250:255); A(2) = -5.5;
Now -5.5 is not representable as uint8, so A should become.. what, int8?
int16? float? double ??

The rule in Matlab is that a variable will change its type to the type
of the assigned value only if the entire variable (unsubscripted) is
named as the destination, such as
A = uint8(250:255); A = -5.5; %A becomes double
but not
A = uint8(250:255); A(:) = -5.5; %A stays uint8 and gets assigned all 0

Everybody knows and expects that if you assign a floating point value to
a seletion of an integral array that the floating point value will be
clamped to the range representable by the integral type and that the
value will be rounded. Why do you expect that a different mechanism be
used for logical??

"Steven Lord" <slord@mathworks.com> wrote in message <hrv49e$fd7$1@fred.mathworks.com>...
....

> I think that's a very consistent rule (and so I estimate about 30 seconds
> after I post, someone will remind me of a case I've forgotten where it
> doesn't hold true. "Subscripting-as-evaluation", like function handles,
> doesn't count, and neither does the case where a class author specifically
> and explicitly overloads subscripted assignment.) I don't want to have the
> special case "unless RHS contains values that don't 'fit' in which case we
> convert everything to the class of RHS." at the end of that rule unless it's
> absolutely necessary, and IMO it's not.
>
> --
> Steve Lord
> slord@mathworks.com
> comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
>

Steve: I know we are talking different languages here, you are the developer, I'm the user. As a user, I don't mind bumping up from logical to double, or from int8 to double, if that's necessary to give me a result I want. Just imagine that I create a variable X somewhere on the line #12 and it just happened to be stored at Integer. Or Logical. Then later at the line #133 I try to write X(3)=pi. I really want this "pi" to be there! Instead of doing just what I told him to do - just put the number in there - Matlab is *invisibly* correcting my operation, giving me a wrong answer that I didn't expect. Who would be happy about that? I want "what you see is what you get" as a consistent behavior.

Sergei Koulayev wrote:
> Do you agree that there
> should be at least a warning when someone tries to write double into
> logical?

Not unless you are also going to start giving a warning every time
someone uses a double (other than 0 or 1) in a logical context such as

if VarName %same as if all(VarName ~= 0)

or

B = ~~A; %same as B = (A ~= 0)


If we are going to have warnings, then let us be consistent and have the
warnings whenever anyone _evaluates_ a double in a logical context and
that double does not happen to be be 0.0 or 1.0.

Wouldn't that be a squawk, the amount of code that would have to be
touched up to avoid triggering "dbstop if warning"...

if logical(VarName) %makes me think of if islogical(VarName)

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv5v5$742$1@fred.mathworks.com>...

>Then later at the line #133 I try to write X(3)=pi. I really want this "pi" to be there!
Instead of doing just what I told him to do - just put the number in there - Matlab is *invisibly* correcting my operation, giving me a wrong answer that I didn't expect.
====================

But then why wouldn't you define X (or convert it) to a data type that can hold pi. You say you don't want MATLAB to invisibly alter your choice of data, but you do seem to want it to invisibly alter your choice of data type. Why is one better than the other?

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv5v5$742$1@fred.mathworks.com>...

> Steve: I know we are talking different languages here, you are the developer, I'm the user. As a user, I don't mind bumping up from logical to double, or from int8 to double, if that's necessary to give me a result I want. Just imagine that I create a variable X somewhere on the line #12 and it just happened to be stored at Integer. Or Logical. Then later at the line #133 I try to write X(3)=pi. I really want this "pi" to be there! Instead of doing just what I told him to do - just put the number in there - Matlab is *invisibly* correcting my operation, giving me a wrong answer that I didn't expect. Who would be happy about that? I want "what you see is what you get" as a consistent behavior.

Oh, but Matlab certainly gives "what you see is what you get", the difficulty for "user" is to see line #133 AND also line #12.

If you see *only* line #133 then what you see is not what MATLAB see.

After all, you are the one who code the line #12, isn't it? Do you have any valid excuse not seeing it?

Bruno

Sergei Koulayev wrote:
> As a user, I don't mind bumping up from logical
> to double, or from int8 to double, if that's necessary to give me a
> result I want. Just imagine that I create a variable X somewhere on the
> line #12 and it just happened to be stored at Integer. Or Logical. Then
> later at the line #133 I try to write X(3)=pi. I really want this "pi"
> to be there! Instead of doing just what I told him to do - just put the
> number in there - Matlab is *invisibly* correcting my operation, giving
> me a wrong answer that I didn't expect. Who would be happy about that? I
> want "what you see is what you get" as a consistent behavior.


I know some languages that can do that with respect to some indexable
objects (e.g., Maple lists), but I cannot think of _any_ language that
will do that for objects that have been formally declared as arrays. I
dunno... LISP might if anything does.

What I would suggest to you, Sergei, is to use cell arrays for all of
your work instead of numeric arrays.

X{3} = pi;

*will* change the datatype of X{3} to double.

You will largely lose the ability to vectorize numeric computations, but
if you want WYSIWYG storage then you are going to lose efficiency anyhow.

"Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <hrv79o$5qa$1@fred.mathworks.com>...
> "Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv5v5$742$1@fred.mathworks.com>...
>
> >Then later at the line #133 I try to write X(3)=pi. I really want this "pi" to be there!
> Instead of doing just what I told him to do - just put the number in there - Matlab is *invisibly* correcting my operation, giving me a wrong answer that I didn't expect.
> ====================
>
> But then why wouldn't you define X (or convert it) to a data type that can hold pi. You say you don't want MATLAB to invisibly alter your choice of data, but you do seem to want it to invisibly alter your choice of data type. Why is one better than the other?

This is because my choice of data has first order effect on the correctness of the numerical results. While the choice of data type - these matter only for storage and maybe for efficiency of computations - clearly, secondary matters. Matlab agrees with this point and creates variables as doubles by default. Indeed, why would you store zeros(1,2) as a double? It is not efficient. Expecting users to track data types is not realistic. I guess this logical thing that I encountered is really the only place where problems might happen.


But going from philosophy to practice, how

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrujad$fmn$1@fred.mathworks.com>...
> People,
>
> check this out. I always thought I could treat 0-1 resulting from the logical operations as numbers. But apparently not. Why? It is completely unintuitive and dangerous. Can somebody give me a meaning of the following example?
>
> a = rand(100,1);
> i = a<0.5;
> i = i.^2;
> i(i==0) = 2;
> unique(i)
>
> ans =
>
> 1
> 2
>
> i = a<0.5;
> i(i==0) = 2;
> unique(i)
>
> ans =
>
> 1

two things
1) there was a pre-LOGICAL era when any array ]0,1[ did the job
2) there is, indeed, an inconsistency on how ML treats LOGICALs
    compared to other classes...

     atf=false;
     atf^pi
% ans = 0
     class(atf)
% ans = logical

     au8=uint8(1);
     au8^pi
%{
??? Error using ==> power
Integers can only be raised to positive integral powers.
%}

just a thought
us

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv8mp$9j2$1@fred.mathworks.com>...
> Expecting users to track data types is not realistic.

Of course it is.

IMHO the three most important commands absolutely must known by new Matlab users are:

DEBUG
SIZE
CLASS

Bruno

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv8mp$9j2$1@fred.mathworks.com>...

> This is because my choice of data has first order effect on the correctness of the numerical results. While the choice of data type - these matter only for storage and maybe for efficiency of computations - clearly, secondary matters.
Matlab agrees with this point and creates variables as doubles by default. Expecting users to track data types is not realistic.
===============

It is a mistake to assume this to be true of all or even most MATLAB users. Many users work very hard to make their code memory and speed efficient and painstakingly select/track the data types of their variables in order to do so. That's why MATLAB has the wide variety of data types that it does and even allows users to create new data types... Your quibbles are based on your own personal ideas of what is dispensible.

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:hrv9fl$1ue$1@fred.mathworks.com...
> "Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message
> <hrv8mp$9j2$1@fred.mathworks.com>...
>> Expecting users to track data types is not realistic.
>
> Of course it is.
>
> IMHO the three most important commands absolutely must known by new Matlab
> users are:
>
> DEBUG
> SIZE
> CLASS

Perhaps this is optimistic, but I would hope that two others were also on
that list; I would even put them before the three you mention:

HELP
DOC

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

"Steven Lord" <slord@mathworks.com> wrote in message <hrva6h$jd7$1@fred.mathworks.com>...
>
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
> news:hrv9fl$1ue$1@fred.mathworks.com...
> > "Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message
> > <hrv8mp$9j2$1@fred.mathworks.com>...
> >> Expecting users to track data types is not realistic.
> >
> > Of course it is.
> >
> > IMHO the three most important commands absolutely must known by new Matlab
> > users are:
> >
> > DEBUG
> > SIZE
> > CLASS
>
> Perhaps this is optimistic, but I would hope that two others were also on
> that list; I would even put them before the three you mention:
>
> HELP
> DOC
>
> --
> Steve Lord

...and let's not forget these

     METHODS
     METHODSVIEW

us

Sergei Koulayev wrote:
> Indeed, why would you store zeros(1,2)
> as a double? It is not efficient.

Not efficient in space, but efficient in CPU processing, as these days I
understand it is not so uncommon to find chips whose double precision
calculation throughput is faster than its best integer calculation
performance.

(The first commercial CPU that I am aware of that had this property was
the MIPS R8000. I seem to recall hearing that some of the Intel Pentium
line had the property that it was faster to add 32 bit integers by
loading them into the floating point unit.)

"Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message <hrv8mp$9j2$1@fred.mathworks.com>...
>
> Expecting users to track data types is not realistic.

That is a ridiculous statement. If a programmer doesn't know about and keep track of the data types he/she is working with and the possible consequences of mixing them in operations in whatever language they are working with, then you have a very poor programmer that can't be trusted to write good code.

James Tursa

Sorry to add to this rather long discussion - but two quick points:

First, it's not a very strong argument to claim something is "unintuitive". Your intuition will be different to mine, especially if we have past experience of different languages. Anyway, if I used my intuition to tell me how to program, I don't think I'd have written a correct program in my life.

Second, C uses the int type for logical data. Java - a more modern and arguably better designed language - has a separate boolean type, even though it follows C in many other ways. Why would the designers of the newer language introduce this distinction? Because it conveys a range of advantages, from efficiency to error checking.

Alan B wrote:
...


> Matt, Bruno, Roger, I don't think my question is so outrageous...
>
> I remember an example of a standard Matlab function that computes some
> statistical metric on arrays columnwise, except when the input is a 3x3.
> In this case, it reverts to row-wise, or maybe does some 2-dimensional
> calculation. Unfortunately I do not remember the name of the function,
> and I may not be recalling the details correctly, but the point is that
> Matlab is not necessarily 100% consistent. Does anyone else know what
> I'm talking about?
>
> I'm not arguing FOR inconsistency, just observing that, if I recall
> correctly, Matlab doesn't have a perfect track record.

Well, by not thinking the question "isn't outrageous", I'd say you're
arguing for inconsistency... :)

Undoubtedly being sorta' an ad hoc language that has evolved there are
some inconsistencies in ML. _BUT_ to consider introducing such a major
behaviorial change between arrays depending only on the values contained
within is truly evil... :(

--

"David Young" <d.s.young.notthisbit@sussex.ac.uk> wrote in message <hrvcto$kc7$1@fred.mathworks.com>...
>
> Second, C uses the int type for logical data.

Well, C does have the _Bool type. The fact that int is often used in programs for logical type data is a programmer choice, not a language specification. Any type that has zero and non-zero values could be used for this as they would have the same effect in logical contexts.

> Java - a more modern and arguably better designed language ...

Hmmmm ... inviting a flame war on the MATLAB newsgroup?

James Tursa

"Walter Roberson" <roberson@hushmail.com> wrote in message
news:9nGEn.49$7d5.4@newsfe17.iad...
> Sergei Koulayev wrote:
>> Indeed, why would you store zeros(1,2)
>> as a double? It is not efficient.
>
> Not efficient in space, but efficient in CPU processing, as these days I
> understand it is not so uncommon to find chips whose double precision
> calculation throughput is faster than its best integer calculation
> performance.

Another reason (that I know Walter knows but Sergei may not) is
preallocation. If you know that you want to end up with a 100-by-100 double
precision matrix, but you don't know the values you want to be in the matrix
when you first create it, it makes sense to allocate enough memory for 10000
elements once rather than allocating enough memory for 1 element, then 2
elements [copying the 1-element region into the 2-element region], then 3
elements [copying the 2-element region into the 3-element region], etc. Now
we _could_ allocate that memory and just leave whatever bits are present in
those memory locations, but if some amount of those elements are going to
end up as zeros, you might want to fill them up with zeros initially and
fill in just the nonzero elements.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

On 5/6/2010 5:00 PM, us wrote:
> "Steven Lord" <slord@mathworks.com> wrote in message
> <hrva6h$jd7$1@fred.mathworks.com>...
>>
>> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
>> news:hrv9fl$1ue$1@fred.mathworks.com...
>> > "Sergei Koulayev" <sergei.koulayev@mathworks.com> wrote in message >
>> <hrv8mp$9j2$1@fred.mathworks.com>...
>> >> Expecting users to track data types is not realistic.
>> >
>> > Of course it is.
>> >
>> > IMHO the three most important commands absolutely must known by new
>> Matlab > users are:
>> >
>> > DEBUG
>> > SIZE
>> > CLASS
>>
>> Perhaps this is optimistic, but I would hope that two others were also
>> on that list; I would even put them before the three you mention:
>>
>> HELP
>> DOC
>>
>> --
>> Steve Lord
>
> ...and let's not forget these
>
> METHODS
> METHODSVIEW
>
> us

Don't forget MINDREAD.