Re: Question on performance, coding style and competitive software

[Alois Schlögl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Bateman wrote:
> Alois Schlögl wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> John W. Eaton wrote:
>>  
>>> On 22-Apr-2009, Alois Schlögl wrote:
>>>
>>> | (The programm slowed down on Matlab from 13.0 to 66.15 s, though).
>>>
>>> If you care about this, then I guess you should complain to the
>>> MathWorks about the performance of their product...
>>>
>>> | BTW, what are the arguments in favor of using octave-only coding
>>> style ?
>>>
>>> Some of us like it better.  Using endfor, endif, etc. is easier to
>>> read.
>>>     
>>
>>
>> The indentation is the most important to make readable code, the use of
>> endfor, endif etc. is hardly decisive.
>>
>>
>>  
>>> | Yes, the question is closely related to the previous one. Of
>>> course, if
>>> | the toolbox is compatible to matlab, there is no problem for the
>>> matlab
>>> | users. Unfortunately, most toolboxes (all in Octave and
>>> | octave-forge/main and most of octave-forge/extra) are using the
>>> | octave-only coding style.
>>> | | This seems to suggest that a fork is neccessary in order to make the
>>> | toolboxes applicable for matlab users. Is there an alternative ?
>>>
>>> Some of us don't see enhancing Matlab as a goal of the Octave or
>>> Octave Forge projects.  The goal for us is to make Octave better by
>>> writing code for Octave, not Matlab.  Making useful things available
>>> in Octave packages should provide an incentive to use Octave.
>>>
>>> jwe
>>>     
>>
>>
>> I agree that making useful things available for Octave is an incentive
>> to use Octave; however, i do not see how writing octave-only code is
>> decisive for this aim.
>>
>> On the other hand, writing mat-compatible functions can win users for
>> the tools and toolboxes (even if they still prefer the proprietary
>> engine). This could also bring in some additional testers for the
>> toolboxes. It might be also a way to raise the interest of some current
>> mat-users and developers. I think it would be a win for (the idea of)
>> Octave.
>>
>>   
> When I tried using a function name of a function in matlab that was in a
> toolbox as well and I didn't have a license for this toolbox matlab's
> license manager prevented me from using that function even if all the
> code in it was mine.. Perhaps matlab's license manager has improved but
> if it hasn't your idea of getting matlab users to use matlab compatible
> octave-forge toolboxes might be dead in the water.. Frankly I always
> considered this behavior of matlab's a bug as I see no reason I should
> avoid an arbitrary and growing list of function names


This would be certainly an issue. I agree that such behavior is not ok.
Personally, I've not observed this as an issue, biosig, NaN- and
TSA-toolbox are working well with Matlab. Free toolboxes could be useful
to raise this issue and make users aware of this problem.

I've used oct2mat (thanks to you for pointing this out, and thanks to
Thomas for the fix) and compiled the converted functions. This first
version is available here:
http://hci.tugraz.at/~schloegl/matlab/freetb4octmat-0.01.zip

An open question is, whether the discussion about this approach (and
questions of mat-users) can happen here at the octave mailing lists, or
whether this should happen somewhere else. The communication with the
users is important in order to solve the open issues. And the users
should expect a nicer reply than "don't bother us with your
matlab-related problems". On the other hand, some of you might get
annoyed by matlab-related problems.

Are there any suggestions how to address this issue? Perhaps another
mailing list e.g. address@hidden ?


Alois
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknx064ACgkQzSlbmAlvEIiYlACgw1s/bweF92UR91IvrByJ/20L
XUQAn0qj8A4joHzVHSHldsiXuGixTy1k
=ldff
-----END PGP SIGNATURE-----