Prev: Is Matlab "libstruct" able to recognize the nested-C structure?
Next: Mex error directory invalid
From: Bruno Luong on 26 Apr 2010 02:26
At this point it seems a rigorous definition is needed to backup such or such claim, otherwise the discussion is a matter of interpretation and not logic (for instant I'm not even sure C is Turing language as you seems to imply Walter).

IIRC,UVM is incomplete (a classical example is: there is no program that can tells whereas any programs stops or run indefinitely; the fact that a given program stops run is then a (true) is a function that is not computable by UTM). I never heard UVM is inconsistent, that must implies CATASTROPHIC consequences, and I'll certainly throw my PC over the window right a away if it was true.

This is however far away from the original topic, which is much simpler and less philosophic.

Bruno
From: Steven Lord on 26 Apr 2010 10:59

"Zaphod " <a3904429(a)owlpic.com> wrote in message
news:hqtsfk$a64$1(a)fred.mathworks.com...
> Walter Roberson <roberson(a)hushmail.com> wrote in message
> <hqthjq$96d$1(a)canopus.cc.umanitoba.ca>...
>> Zaphod wrote:
>> >> Algol 68 was one of the first languages to treat procedures as
>> >> first-class objects; it was also considered for a number of years to
>> >> be too complex for it to be theoretically possible to build a parser
>> >> for.
>>
>> > It doesn't matter that () denotes function calls in these languages. It
>> > also denotes order of evaluation. As long as it is unambiguous, there
>> > should be no problem.
>>
>> Then what is your complaint about Matlab's use of () ? Matlab's () denote
>> order of execution to pretty much the same extent that C's () denote
>> order of execution (Fortran is stricter.) A procedure call using () to
>> denote the argument list is *not* a matter of order of execution.
>
> I said parens can denote several things in a language, namely order,
> invocation, tuples, etc. The key point here is that in this expression:
>
> (@(x) x + 1)(2)
>
> the reasonable result is 3, whereas in Matlab it is a syntax error.

For quite some time, MATLAB permitted arrays of function handles, so this:

S = [@sin, @cos, @tan];

was legal. In that case, what would you have expected this to do?

([@sin, @cos, @tan])(2)

Should this return @cos, the second element of the array of function
handles, or [sin(2) cos(2) tan(2)], the result of evaluating each function
handle in the array with 2 as input?

Note that we have, in the past few releases, deprecated (warned on) the use
of arrays of function handles in favor of cell arrays of function handles;
one main reason for this deprecation was to allow users to call function
handles without FEVAL:

http://www.mathworks.com/access/helpdesk/help/techdoc/rn/f8-1009921.html#f8-1012879

Allowing both arrays of function handles and FEVAL-less invocation would
have lead to this ambiguity.

*snip*

> Yes, there are inconsistencies in other languages. Does this mean we
> cannot point out inconsistencies in Matlab? Pointing out flaws like this
> might lead to a better language. If you find these problems in other
> languages to be a grievance, bring it up in the appropriate forum (as I
> did here).

Pointing them out in this newsgroup may cause some discussion ... but if you
really want to bring it to the attention of the developers, you should
describe your concerns to Technical Support. Keep in mind, though, that
"making MATLAB work like language X" or even "making MATLAB work like
languages X, Y, Z, and Q" may not be a sufficient reason to change the
behavior of MATLAB. After all, to use a different example, C++ is
inconsistent with MATLAB in that its basic data type is not the matrix.
Does that mean C++ should be changed to make its basic data type be a
matrix -- or more to the point, do you think C++ will every be changed that
way? I highly doubt it.

And before you say anything about the relative creation time of those
languages, Cleve said he created the first version of MATLAB in "the late
1970s":

http://www.mathworks.com/company/newsletters/news_notes/clevescorner/dec04.html

Wikipedia indicates Stroustrup began working on C++ in 1979.

http://en.wikipedia.org/wiki/C%2B%2B

Having two languages do things differently is not necessarily a bad thing.
After all, if every language did everything the same as every other
language, we'd have only one language. And I, for one, would not look
forward to learning the new
JavaFortranMATLABSchemeLispSmalltalkShakespeareWhitespacePascalLogoPythonRubyVisualBasicC++
language.

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


From: Bruno Luong on 27 Apr 2010 01:30
"Steven Lord" <slord(a)mathworks.com> wrote in message <hr49p0$273$1(a)fred.mathworks.com>...

>
> For quite some time, MATLAB permitted arrays of function handles, so this:
>
> S = [@sin, @cos, @tan];
>
> was legal. In that case, what would you have expected this to do?
>
> ([@sin, @cos, @tan])(2)
>
> Should this return @cos, the second element of the array of function
> handles, or [sin(2) cos(2) tan(2)], the result of evaluating each function
> handle in the array with 2 as input?

Logically, it should return the same as - whatever it is:
af = [@sin, @cos, @tan];
af(2)

I short, it is The Mathworks's call. There is not issue with such syntax.

*I* would prefer it returns "@cos" for array with length>1. We can alway call

feval(af,2)

to return [sin(2) cos(2) tan(2)].

The same ambiguity some how exists currently in Matlab. For example:

function bar = foo(f)
bar = f(2)
end

Calling
foo(@sin)
foo([1 2 3])

does two different things.

Bruno
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Is Matlab "libstruct" able to recognize the nested-C structure?
Next: Mex error directory invalid