COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### Baffling colon behaviour

• Email
• Follow

I am puzzled by the following (observed in 2009a 64 bit Linux and 2010a 64 bit Windows):

>> [a, b, c] = deal(1, :, 2);
>> strcmp(b, ':')

ans =

1

I can't fit this into any of my mental schema relating to how things should work, or find any documentation that would explain it. I feel I must be missing something (quite possible at 1 am, as it is here) - can anyone shed any light please?

I can't find a bugreport, but I'm beginning to wonder if I've found a bug.

(For anyone who doesn't see the problem: deal is a function, not an array. You'd expect a naked colon to be meaningless as an argument, and for the first line of my example to cause an error. To get a string back is very strange.)
 0

See related articles to this posting

Using 2007b:

>> [a, b, c] = deal(1, :, 2);
??? At compilation, "deal" was determined to be a variable and this
variable is uninitialized.  "deal" is also a function name and previous versions of MATLAB would have called the function.
However, MATLAB 7 forbids the use of the same name in the same
context as both a function and a variable.

What does:
>>which deal
say?
 0

"Matt Fig" <spamanon@yahoo.com> wrote in message <horhtp$q5e$1@fred.mathworks.com>...
> What does:
> >>which deal
> say?

>> which deal
C:\Program Files\MATLAB\R2010a\toolbox\matlab\datatypes\deal.m
 0

Matt: thanks, that's given me something to think about. In 2010a the behaviour you see is preserved (with a shorter message) if there are only 2 arguments to deal:

>> [a, b] = deal(1,:)
??? Undefined variable deal.

I can understand this: if there's a naked colon, then deal must be a variable not a function, it's not defined, so error.

It's looking increasingly as if there is a bug for more than 2 arguments: the function is being called, and a representation of the lexical token is being passed to it without any attempt at evaluation.
 0

Did they change DEAL.m?  Is it still just basically:

varargout = varargin;

or what?
 0

"Matt Fig" <spamanon@yahoo.com> wrote in message <hork53$pjn$1@fred.mathworks.com>...
> Did they change DEAL.m?  Is it still just basically:
>
> varargout = varargin;
>
> or what?

It's not a problem with deal - I was just using deal to demonstrate the problem. It's any case where a naked colon appears as one of three arguments to a function.
 0

5 Replies
263 Views

Similar Articles

12/10/2013 4:36:09 PM
[PageSpeed]

Similar Artilces:

strange behaviour of IF statement
that, as desired, the second one will not test J .LT. I unless STRING .NES. "". However, I get different behaviour using the two constructs above for the case the J IS defined. How can this be? Phillip Helbig---remove CLOTHES to reply wrote: > > The original code is quite long, so I haven't tried to come up with a > compact example yet. > > Basically, I had something like > > $IF STRING .NES. "" .AND. J .LT. I >$ THEN > $K = J >$ GOTO SOME_LABEL > $ENDIF > > In some circumstances, however, J is not defined, namely when > > STRING .EQS. "" > > Thus, I changed the code above to > >$ IF STRING .NES. "" > $THEN >$ IF J .LT. I > $THEN >$ K = J > $GOTO SOME_LABEL >$ ENDIF > $ENDIF > > It seems to me that the two constructs are logically equivalent, except > that, as desired, the second one will not test J .LT. I unless > STRING .NES. "". However, I get different behaviour using the two > constructs above for the case the J IS defined. How can Eventual undefined behaviour differently, and the compiler could no longer > prove it would be called unconditionally, then the compiler would have to > accept the code. if i was defined as an unsigned variable, the behaviour is well defined and I see no reason for the compiler to complain. If it is smart enough, it will optimize to loop away. With i as an int, it depends on the implementation whether the behaviour is undefined or not. The compiler could detect the inevitable integer overflow and complain about it, or even refuse to produce an executable, but on most architectures the behaviour is defined and the loop can be optimized away. -- Chqrlie. On Fri, 14 Sep 2007 19:31:09 +0200, Charlie Gordon wrote: > "Harald van D?k" <truedfx@gmail.com> a écrit dans le message de news: > fcecig$2a9$1@news1.zwoll1.ov.home.nl... >> On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote: >>> int i ; >>> >>> for (i=1 ; i != 0 ; i++) ; > > With i as an int, it depends on the implementation whether the behaviour > is undefined or not. The compiler could detect the inevitable integer > overflow and complain about Weird Loop Behaviour Hi, In the following code, I am trying to run "black" screen for 3 seconds and respectively 2 seconds "white" screen. Black routine takes 3 seconds and white 2 seconds, 2 x black + white = 8 seconds which should be the expected value but when I run it I get black-white-black- white instead of black-white-black. Couldn't figure out what is wrong thus sharing the code as well ; white = False while(end<8.00): end = time.time() - start if white: screen.fill((255, 255, 255)) time.sleep(2) else: screen.fill((0, 0, 0)) time.sleep(3 Strange behaviour of a design I am working now for some days on a strange behaviour of a fpga. The design is complete synchron. I have the problem that when I change in a state machine a signal, then the design doesn't function any more. The problem is a can not locate where it come from, because when I add some debug information the design works again. In Simulation I can't see something wrong. Has anybody an idea what could be wrong? On Aug 29, 6:08 am, markus.j...@de.bosch.com wrote: > I am working now for some days on a strange behaviour of a fpga. > The design is complete synchron. > I have.....@Unisys.com> wrote: > On Aug 29, 6:08 am, markus.j...@de.bosch.com wrote: > > > I am working now for some days on a strange behaviour of a fpga. > > The design is complete synchron. > > I have the problem that when I change in a state machine a signal, > > then the design doesn't function any more. > > The problem is a can not locate where it come from, because when I > > add > > some debug information the design works again. > > In Simulation I can't see something wrong. > > > Has anybody an idea what could be wrong mysterious Jlist behaviour (valuechanged) Dear all, Every time I klick in a Jlist to change its value, it turns out valueChanged() is called twice, both times with the new seleceted index value. I am not doubleclicking inadvertently. I don't like it, because alle the work that is to be done on changing the selected value is carried out twice as well, of course. Does anybody know why two valauechanged events are sent and how I can get rid of this behaviour? tia, Winston In article <3fc7fffa$0$4393$e4fe514c@dreader9.news.xs4all.nl>, wnstnsmith@yahoo.com wrote: >Dear all, > >Every time I klick in a Jlist to change its value, it turns out >valueChanged() is called twice, both times with the new seleceted index >value. I am not doubleclicking inadvertently. >I don't like it, because alle the work that is to be done on changing the >selected value is carried out twice as well, of course. Does anybody know >why two valauechanged events are sent and how I can get rid of this >behaviour? > >tia, > >Winston I don't know if you can get rid of this behavior, but you can deal with it. In the valueChanged() method, there is a ListSelectionEvent object available, which

Strange behaviour of Catch statement
Hello all, I'm having a very weird problem regarding the use of the catch statement. I can't give the source of this program, because it's much too big. I have some statements in my code, which look like this: catch {array unset tags} My problem is that, if I load a kind of file in my application, the catch statement works fine. However, if I load a different kind of file, an error is raised and it seems like the catch statement is gone! Don't look at the "file loading" part, because it has nothing to do with the problem. The problem is that every type of file causes a certain program flow, this flow however, is always exactly same. My worry is about the fact that at some points the catch statement just doesn't work and an error is raised. I checked the group for possible bugs or programming mistakes, but I couldn't find anything. Is there any kind of bug or strange behaviour of tcl familiar regarding the catch statement? - Maurice Maurice van Vugt wrote: > My problem is that, if I load a kind of file in my application, the > catch statement works fine. However, if I load a different kind of > file, an error is raised

Weird Graphics Behaviour-Mathematica 4.2
Hello everyone, Something really strange happened and maybe someone can shed a light. All of suddent, Mathematica CANNOT display any graphics . Specifically, when I issue a graphics command (i.e. Plot, ListPlot, Graphics primitives), it outputs a blank space and the Window title line keeps flickering the name of the working window. It is not that the graphics are not created i.e. I can take the FullForm of any graphics command and see the internal representation, it is their rendering that is not taking place. Furthermore I can copy the (invisible) graphic into other appl

Unusual behaviour opening Word document
If I do not have the indicated Word document open (on my Win XP Pro machine with PHP 5.2), the following will open and display it: <?php $path = "c:\\path\\to\\word\\document\\mydoc.doc";$doc = new COM($path);$doc->Application->visible = true; ?> However, there will be several identical warnings (14 in number) associated with line 3 (the new COM line): Warning: com::com(): Type library constant emptyenum is already defined in C:\test.php on line 3 Am I getting lucky that the doc is opened at all (and hence the warnings are not bugs), or should this behaviour...;visible = true; > ?> > > However, there will be several identical warnings (14 in number) > associated with line 3 (the new COM line): > > Warning: com::com(): Type library constant emptyenum is already defined > in C:\test.php on line 3 > > Am I getting lucky that the doc is opened at all (and hence the > warnings are not bugs), or should this behaviour be reported? This > type of functionality works fine in vbscript: > > Path = "c:\path\to\word\document\mydoc.doc" > Set doc = CreateObject(Path) > doc.Application.visible = true > >

Strange behaviour of "Del" key
Hello, I have a sun6 (GB) keyboard on a Sun Blade running SunOS 5.8. I want to use the "Del" key (keycode 83) so that I can combine it with "Alt_L" (keycode 233) in my application. However, the "Del" key behaves differently from the other keys in that keypad (Insert, Home, Page Up, End, Page Down) because that is the only key which doesn't combine well with the Alt key. If e.g. I press Alt+End, the xev application output shows that the keycode for End (84) is output, and the state is 0x8, indicating that mod1 is active (Alt) However, pressing Alt+Del does not give the expected keycode output (83) and the state 0x8. Instead, I get 2 FocusOut events, a FocusIn event and a KeyMapNotify event. How can I disable this special behaviour of the Del key, and make it behave like e.g. the "End" key ? Thanks Tor Bye Tor Bye wrote: > If e.g. I press Alt+End, the xev application output shows that the keycode > for End (84) is output, and the > state is 0x8, indicating that mod1 is active (Alt) > > However, pressing Alt+Del does not give the expected keycode output (83) and > the state 0x8. > Instead, I get 2 FocusOut

procmail filter behaviour with long messages
There's something weird going on with procmail, and I'm hoping someone can explain the internal workings of pipes in procmail so I can understand exactly why this happens. The problem is that when I have procmail pipe mail to a filter, short messages get absorbed by the filter but long messages get delivered to the mailbox - and I don't want them to. This happens when I use filters that don't read stdin completely, so clearly it all has something to do with that. Take for example this lone recipe in a .procmailrc :0 * .* | /bin/true This will pipe all incoming mail to