deprecated functions
Jaroslav Hajek
highegg at gmail.com
Wed Mar 4 14:48:39 CST 2009
On Wed, Mar 4, 2009 at 9:20 PM, Jason Riedy <jason at acm.org> wrote:
> And Jaroslav Hajek writes:
>> But it would break backward and Matlab compatibility in a fairly
>> invasive way (infinitely more than the recently discussed NaN issues),
>> so I think a wide agreement is really necessary here.
>
> I don't have a Matlab(TM) license and haven't used it in quite
> some time, so I can't verify that... I'm shocked but not too
> surprised given their market moves.
>
> However, such compatibility would render Octave far less useful
> to me. I use Octave for executable code that can be published
> directly[1]. Having to obscure my code for a system (Matlab(TM))
> that I don't use and have no intention of using would be awful.
>
> Jason
>
Jason,
be sure that I more than heartily agree with you that there's a lot of
"broken" design in Matlab, and the fact that diag, eye etc. return
dense matrices is one of them. (If they returned sparse, we would now
have a natural promotion sequence daigonal -> sparse -> dense for
matrices).
Another instance is that index vectors are reals (grrr) or that int +
double return int... yes it all makes sense w.r.t. bkwd compatibility
and it's all historical, but still it's pain in the ass...
Now, about your suggestion - I think the Octave community has now a
general agreement that pursuing Matlab compatibility to a reasonable
extent, and that extent is fairly high, *is* a good thing for Octave.
Justifying a change that significantly breaks compatibility is
possible (it happened before) but you need to make *really* good
arguments.
cheers
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
More information about the Octave-maintainers
mailing list