On 2/14/2013 6:18 AM, Bruno Luong wrote: > dpb <firstname.lastname@example.org> wrote in message <email@example.com>... > >> >> But even 'doc colon' is essentially narrative examples of what it does >> w/ certain values--it doesn't say a thing about complex--nor does it >> intimate there's a problem with it. So, it isn't completely defined or >> at least user-documented; > > But I never say the contrary dpb.
Well, that's progress, then....surely seemed to me you were arguing that the original expression should have had some known meaning discernible a priori.
> IIRC, the behavior of a:b:c when a, b, c are (pure real) arrays are > documented recently, (after the thread I provide the like earlier). > > But the behavior for complex ins't (yet?) documenetd. Though the same > behavior is reproductible in all MATLAB versions: it operates only on > real part first element of the inputs. That's logical and meaningful IMO.
That's certainly one possible implementation--the point is again that unless and until it is documented it isn't... :)
> There are many things that are not documented. Just take a look at > Yair's blog. Are things discussed there are meaningless to you? I thing > Yair's blog is the most useful blog concerning MATLAB. > > In many languages - even a strict one like C - the behavior of many > function is not completely defined (such as malloc(0), or something as > simple as the bit shift (a >> b)). The specific compiler will implement > specific behavior, yet all of them are meaningful. Just like MATLAB colon.
But there's a very big difference -- take malloc() since you bring it up. The C Standard states that malloc() w/ a size_t argument of zero is implementation defined (w/ two possible conforming results).
While it isn't unique it's much more useful information to the developer than if it weren't mentioned what happens--when one knows where "there be dragons" regions are, then it is possible to know one needs to take appropriate steps to avoid or slay same.
My complaint is (and has been for a long time) that that type of completeness that a Standard language tries to incorporate is mostly missing in Matlab documentation as there is no Standard document the general user/public is allowed to see.
The documentation tends to be example-based rather than definitive statement-based, even for base language elements. Thus the need for poking around and finding out what undocumented things do do--which, of course, since they are undocumented means if you rely upon them you may find out your code broken at some point down the road.