Octave's and Matlab's limitations

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Octave's and Matlab's limitations

Sergei Steshenko




----- Original Message -----

> From: c. <[hidden email]>
> To: Francesco Potortì <[hidden email]>
> Cc: Sergei Steshenko <[hidden email]>; "[hidden email]" <[hidden email]>; Jake <[hidden email]>
> Sent: Thursday, November 22, 2012 11:54 AM
> Subject: Re: Octave's and Matlab's limitations
>
>
> On 22 Nov 2012, at 10:49, Francesco Potortì wrote:
>
>>>  Though I agree with you that typically more than one language is
>>>  necessary, there is _nothing_ Matlab/Octave can do and other language
>>>  can't with the same ease or even easier and more elegantly and less
>>>  bug-prone.
>>
>>  I think that the winning feature of Octave is the index notation and the
>>  ease to access submatrices with a readable and intuitive syntax.  That
>>  is, what is known as the Matlab index notation.  Are there any other
>>  languages that allow such indexing power and clarity?
>
> I'd say Fortran 2003, but I think all of Jordi's objections (plus MANY
> more) would apply
> to that language as well, furthermore most compilers are lagging behind in
> implementation of
> the full standard.
>
> These languages are specifically designed to facilitate handling arrays of
> numbers,
> if that's want you want they are both amazingly powerful and convenient.
>
> c.
>

And I should add that "late" Fortran version are even object-oriented (if one wishes to use the feature) and syntax is greatly improved compared to Fortran IV (which I used for some time being much younger).

Seeing "late" Fortran code I almost undersand it not even learning the language - it is pretty readable by itself.

Regards,
  Sergei.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Octave's and Matlab's limitations

Sergei Steshenko
In reply to this post by Francesco Potortì




----- Original Message -----

> From: Francesco Potortì <[hidden email]>
> To: Jordi Gutiérrez Hermoso <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>; Sergei Steshenko <[hidden email]>
> Sent: Thursday, November 22, 2012 3:51 PM
> Subject: Re: Octave's and Matlab's limitations
>
>> Numpy's indexing is essentially the same except it's 0-based to
>> conform to general Python usage. Numpy can't extend the Python
>> language beyond what Python itself allows, though, so things like [A;
>> B] to concatenate matrices in Octave become np.vertcat([A, B]) or
>> something like that, can't exactly remember. I don't think this is a
>> huge loss, however.
>
> I think it is.  Being able to catenate and mix ways of indexing id a
> huge plus from my point of view.
>
>> There is nothing all that magical about Octave indexing.
>
> I see.  But again, is there another language (preferably an interpreted
> one) that allows things like
>
>   A([1:2:97 98 99],[1:end-1]) = (B > C);
>
> or
>
>   A(A > 0) += 128;
>
> ?
>
> --
> Francesco Potortì (ricercatore)        Voice:  +39.050.315.3058 (op.2111)
> ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
> via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
> (entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it
>

I think

A(A > 0) += 128;

can be done even in C++.

I.e. it will look like

A[A > 0] += 128

, and '[...]' can be overloaded along with '>'.

Regards,
  Sergei.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Octave's and Matlab's limitations

c.-2
In reply to this post by Sergei Steshenko

On 22 Nov 2012, at 19:16, Sergei Steshenko wrote:

> And I should add that "late" Fortran version are even object-oriented (if one wishes to use the feature) and syntax is greatly improved compared to Fortran IV (which I used for some time being much younger).
>
> Seeing "late" Fortran code I almost undersand it not even learning the language - it is pretty readable by itself.

yes, modern fortran is very nice and powerful ...
unfortunately very few compilers support all features of the standard,
and even fewer general purpose libraries are compatible with modern fortran.

> Regards,
>   Sergei.
c.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Octave's and Matlab's limitations

Sergei Steshenko
In reply to this post by Dimitri Maziuk




----- Original Message -----

> From: Dimitri Maziuk <[hidden email]>
> To: Sergei Steshenko <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
> Sent: Thursday, November 22, 2012 8:10 PM
> Subject: Re: Octave's and Matlab's limitations
>
> On 11/21/2012 6:45 PM, Sergei Steshenko wrote:
>>
>
>>>  I like Perl, and I do not write it this way. The example you gave is
> unfair in
>>>  several respects:
>
> Yes, and quite deliberately, too. ;) My point was that to someone who hasn't
> touched math since Scientific Computing 201 and matlab -- never (we did it in
> C), e.g. "A([1:2:97 98 99],[1:end-1]) = (B > C);" quoted downthread
> looks no different from obfuscated perl.
>
> I do spell things out and never use "$_" either (when I have to write
> perl).
>
[snip]
>
> Dima
>

Me too, but one shouldn't be a dogmatic. For example, in 'map' and 'grep' '$_' is _quite_ in order. A typical Perl idiom is converting an array into hash whose keys are the array elements and whose values don't matter - the hash is intended to be used later for existence checks.

So, it's quite OK IMO to write

my %hash; map {$hash{$_} = ''} @array;

Or, if one wants to find elements with 'foo' substring, it's quite OK to write

grep(/foo/, @array)
.

Regards,
  Sergei.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
123