Prev: Simscape>Mechanical Source
Next: ezplot3 and hold bug?
From: freund on 30 May 2010 09:02 Dear Mike, Is there a way to turn on <checkvars> and have it run in the background until turned off? I tested one of my functions that I use all the time by inserting checkvars as the last line, and was amazed to find four instances of shadowing that involved three obscure Matlab functions such as Zb, and a function that I wrote years ago and had stupidly named G1. After the test I decided the shadowing was in these cases innocuous, and deleted checkvars. But it is obviously not practical to check all my functions this way. In many cases functions are deeply nested, and shadowing could have the potential to produce undetected errors. Ideally, checkvars would tell you the name of the m-file and the line number. Thanks, Ize
From: Rune Allnor on 30 May 2010 16:38 On 30 Mai, 15:16, dpb <n...(a)non.net> wrote: > Matt J wrote: > > "Steve Amphlett" <Firstname.Lastn...(a)Where-I-Work.com> wrote in message > > <htt5bg$fl...(a)fred.mathworks.com>... > > >> I still think it's a huge problem with the Matlab language. A massive > >> booby-trap sitting there, waiting. > > ============= > > > I'm actually a bit dumbfounded by how often this occurs. If you're > > trying to use the same name for two different things (function and > > variable), I tend to think that you really don't know what's going on in > > your code. > > OTOH, given the size of the ML namespace, in some ways my surprise is it > doesn't happen even more often... :) > > "i" and "j" are probably the two most common index variables > ubiquitously used in other code; it's essentially automatic to write > them for anybody who's ever written in any other language at all. > > The min() and max() names are, while possibly could claim they always > ought to be minx or miny or somesuch amplified naming convention no > matter what seem perfectly reasonable to use as variable names. And, of > course, if one comes from Fortran (listening, Rune??? :) ) where > function names and variable names are in different name spaces, it's > perfectly permissible So you are saying that it is not the programming language but the programmer's experience that determinec what features he will be allowed to use in his programs...? > (altho I don't recommend it, it makes one not > consider as carefully as otherwise might) in picking names. This is the strength that C++ offers, which I am not aware if exists in other languages: Use the types of the arguments in the function call and allow the *compiler* to determine exactly what version of the function to link with. Works both internally in classes and for free functions. It is an incredibly powerful feature. Once one have tried it, one will never go back. Rune
From: dpb on 30 May 2010 17:00 Rune Allnor wrote: > On 30 Mai, 15:16, dpb <n...(a)non.net> wrote: .... >> The min() and max() names are, while possibly could claim they always >> ought to be minx or miny or somesuch amplified naming convention no >> matter what seem perfectly reasonable to use as variable names. And, of >> course, if one comes from Fortran (listening, Rune??? :) ) where >> function names and variable names are in different name spaces, it's >> perfectly permissible > > So you are saying that it is not the programming language > but the programmer's experience that determinec what features > he will be allowed to use in his programs...? How do you get that from what I wrote? I simply contrasted the syntax of Fortran that can from context determine whether MIN() is a function or array reference and allows both in the same compilation unit whereas, Matlab, otoh, can't. Hence, in Matlab it's the programmer's responsibility to either not use an existing function name or know that they have aliased it. The language doesn't do much (as in anything) to help other than if the particular function is in the syntax-coloring list; otherwise it's completely silent. .... > This is the strength that C++ offers, which I am not aware > if exists in other languages: Use the types of the arguments > in the function call and allow the *compiler* to determine > exactly what version of the function to link with. Works both > internally in classes and for free functions. > > It is an incredibly powerful feature. Once one have tried it, > one will never go back. .... Yes, that is essentially the rule in resolution of Fortran generic function prototypes to the specific function call (believe it or not... :) ). And, yes, it is quite a nice feature, agreed. --
From: dpb on 30 May 2010 22:16 Matt J wrote: > dpb <none(a)non.net> wrote in message > <httojr$f0t$1(a)news.eternal-september.org>... > >> > I'm actually a bit dumbfounded by how often this occurs. If you're > >> trying to use the same name for two different things (function and > >> variable), I tend to think that you really don't know what's going on >> in > your code. >> >> OTOH, given the size of the ML namespace, in some ways my surprise is >> it doesn't happen even more often... :) > > No, the save of the Matlab namespace is not relevant. It is perfectly > harmless to use i, j, min, max, etc... as variable names as long as you > don't then try to use them as functions later on in the same workspace. > The problem only occurs when people deliberately try to use the same > name for 2 different things in the same mfile. Well, I think the namespace size _does_ have quite a lot to do with it myself just from the likelihood standpoint of a name collision. That aliasing is ok from Matlab syntax standpoint just makes the error more difficult to catch when it happens. --
From: Rune Allnor on 31 May 2010 03:12
On 30 Mai, 23:00, dpb <n...(a)non.net> wrote: > Rune Allnor wrote: > > On 30 Mai, 15:16, dpb <n...(a)non.net> wrote: > ... > >> The min() and max() names are, while possibly could claim they always > >> ought to be minx or miny or somesuch amplified naming convention no > >> matter what seem perfectly reasonable to use as variable names. And, of > >> course, if one comes from Fortran (listening, Rune??? :) ) where > >> function names and variable names are in different name spaces, it's > >> perfectly permissible > > > So you are saying that it is not the programming language > > but the programmer's experience that determinec what features > > he will be allowed to use in his programs...? > > How do you get that from what I wrote? Because you said "if one comes from Fortran [...] it permissible..." but without stating what language you ara discussing. You have worked with fortran, I have not. Indicating that you could use these techniques in any other language, wheras I can not. It's a ridiculous statement, so I wonder if you really mean it. .... > > It is an incredibly powerful feature. Once one have tried it, > > one will never go back. > > ... > > Yes, that is essentially the rule in resolution of Fortran generic > function prototypes to the specific function call (believe it or not... > :) ). And, yes, it is quite a nice feature, agreed. So they got one thing right. (When did that happen? From the outset in the early '50s? Some time afterwards? Maybe after C++ demonstrated the technique's power? Too bad, then, that fortran sufferes from just about every other weakness, flaw and blunder in the book. Rune |