octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OF packages using Matlab-compatible code (was "pending dataframe-1.2


From: Oliver Heimlich
Subject: Re: OF packages using Matlab-compatible code (was "pending dataframe-1.2.0 release")
Date: Tue, 22 Aug 2017 01:30:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 21.08.2017 10:20, Juan Pablo Carbajal wrote:
>>> I agree.  In addition to Doctest which was already mentioned, Symbolic
>>> also tries to use Matlab-compatible syntax.
>>>
>>> 1.  Having people run it on Matlab has caught some bugs that I otherwise
>>> might not have found.
>>>
>>> 2.  We might uncover and fix incompatibilities in core Octave. This has
>>> happened with Doctest (the implementation of "evalc" for example).
>>>
>>> 3.  Its not inconceivable that a Matlab user might choose an Octave-Forge
>>> package and thus be drawn towards software freedom.
>>>
> I agree with all the points but there is more considerations to throw in.
> In particular, since this is a personal decision, having
> M-compatibility or not in a package is up to the developers.

Yes, that should mainly be decided by those directly affected from the
extra work.

> Also, if the package offers something that is not so easily found in
> proprietary software, then it is worth considering (from the ethical
> point of view) to force it t run only on free software by using
> octave's pidgin.

Just to throw in another argument, I once got a request whether the
interval package could be run in Scilab, which is free software (GPL 2.0).

One reason why this would not have been an easy task is that the package
sticks to Octave's syntax which is not supported by Scilab.

I don't know of any examples, but in general it should be a good idea to
share packages between Octave and Scilab (at least better than sharing
with Matlab).  Again, this would only be reasonable in an m-file lingua
franca.

Oliver



reply via email to

[Prev in Thread] Current Thread [Next in Thread]