[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: policy for release branch
From: |
Daniel J Sebald |
Subject: |
Re: policy for release branch |
Date: |
Sat, 13 Jun 2009 22:55:12 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
Robert T. Short wrote:
Well, now. Make a list of things octave does better. Send that to The
Mathworks
as a feature request. *If* they decide they care, MATLAB will do all of those
things
and more by the next release. They have resources that we don't.
In the macroscopic view, I see your point. Matlab covers much more ground than
Octave. However, I often feel more proficient when working in Octave. A lot
of Matlab's perceived advantage is due to a lot of features that sometimes seem
of questionable benefit; and the fact that people are enamored with GUIs (GUIs
have their place, yes).
For example, the default for Matlab is to not print the contents of an array if the array
size is too large. I suppose viewing data is what the GUI based "variables
window" is for. But one has to double click 3 or 4 times to get to a spread
sheet-like view of the data desired--whew. In Octave, the data is displayed in a pager
no matter the quantity requested, a pager which allows easy searching.
Users denounce gnuplot, but in my opinion Octave w/ gnuplot offers far more
versatility as far as graphics output formats. Gnuplot plots have just as nice
appearance compared to those from Matlab. Matlab plotting has its own quirks
as far as layout, etc. Also, if one is running a lengthy simulation or
whatnot, the Octave/gnuplot plots can be examine while the Octave is still
running. That doesn't work so well in Matlab.
EVERY OTHER
PERSON in that initial group has stayed with MATLAB because they don't have
to build from source, they can buy toolboxes that are uniformly reliable, they
don't have to worry about crashes, etc., etc.
Matlab hangs on occassion. Actually, it is probably a Windows issue, but hey.
Octave became very robust about five years ago. John always seemed to put
crash bugs at top priority when they were reported, and I think he gradually
did some code restructuring and improvement.
My contributions took months, but were really minor. I did hold the
release up for a week or two right at the very end (actually, I REQUESTED
that we hold up for a week or two), but it was for a couple of quick but
very important items - important, given that everything else was in place.
No biggy in the grand scheme of things.
Dan
- policy for release branch, (continued)
- policy for release branch, John W. Eaton, 2009/06/11
- Re: policy for release branch, Robert T. Short, 2009/06/12
- Re: policy for release branch, Daniel J Sebald, 2009/06/12
- Re: policy for release branch, Jaroslav Hajek, 2009/06/13
- Re: policy for release branch, Robert T. Short, 2009/06/13
- Re: policy for release branch, Jaroslav Hajek, 2009/06/13
- Re: policy for release branch, Robert T. Short, 2009/06/13
- Re: policy for release branch, Daniel J Sebald, 2009/06/14
- Re: policy for release branch, Robert T. Short, 2009/06/14
- Re: policy for release branch,
Daniel J Sebald <=
- Re: policy for release branch, Robert T. Short, 2009/06/14
- Re: policy for release branch, Daniel J Sebald, 2009/06/14
- Re: desired features for gp backend? (was: policy for release branch), Ben Abbott, 2009/06/14
- Re: desired features for gp backend?, Robert T. Short, 2009/06/14
- Re: desired features for gp backend?, John W. Eaton, 2009/06/16
- Re: desired features for gp backend?, Daniel J Sebald, 2009/06/18
- Re: desired features for gp backend?, John W. Eaton, 2009/06/18
- Re: desired features for gp backend?, Daniel J Sebald, 2009/06/18
- Re: desired features for gp backend?, John W. Eaton, 2009/06/18
- Re: desired features for gp backend?, Daniel J Sebald, 2009/06/14