Re: octave presentation, part 2

[Jaroslav Hajek]

On Wed, Nov 19, 2008 at 1:30 PM, David Bateman
<address@hidden> wrote:
> Jaroslav Hajek wrote:
>>
>> hello,
>>
>> following the success of my first talk about Octave at Prague
>> university, I'm giving one more speech tomorrow. This time, I've been
>> directly asked by a student for more detailed feature overview &
>> comparison with Matlab. Please find the draft presentation attached.
>> Features are presented as keywords, with colors used to distinguish
>> status (common, Octave-only, added in 3.2, improved in 3.2, missing).
>> Not suprisingly I know best about the features I've been involved
>> with, but I'd like to cover the rest as well, especially plotting.
>> Feel free to suggest additions & modifications. I may yet add some myself.
>>
>> cheers
>>
>
> Here are the things I think you've got wrong or need clarification:
>
> "Nested Functions" aren't included in Octave at all. The variable scoping
> rules in Matlab for nested functions is different than sub-functions. Note
> however that Octave had sub-functions before matlab did.

Thanks for the clarification. I suspected there was a catch, but I wasn't sure.

>
> "try/catch" isn't an extension it is also in Matlab..

Ah, you're right, of course.

> Matlab introduced in
> 2008a the OnCleanup function that has similar functionality to the
> unwind_protect structure, though I think the Octave way of doing it is
> cleaner.

unwind_protect (though I'd prefer try/finally as in C++) is much
cleaner, because it is, at least to me, completely
unclear in what order the various variables are destroyed at the end
of the function.

>
> What do you mean by "closures"?

The ability of anonymous function handles to grab values from their scope, see
http://en.wikipedia.org/wiki/Closure_(computer_science)

>
> The "GSVD" function is part of the linear-algebra package of octave-forge
>

I'll mention this. Are there plans to include it in Octave?

>
> The sparse SVD is part of the arpack package of octave-forge for license
> reasons...
>

To be mentioned, too.

> You can write a C mex wrapper to a fortran function and so I'm not sure this
> is a real limitation.
>

True, but still in Fortran you can bypass the wrapper, right?


> Regards
> David
>
>
>
>

thanks for your comments, David



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz