Re: GSoC project: new graphics backend

[Jaroslav Hajek]

On Fri, Mar 20, 2009 at 9:04 AM, Igor V. Burago <address@hidden> wrote:
>> The same can be said for Python, and I'm not aware of any Ruby
>> scientific library comparably mature to NumPy/SciPy. Yet somehow SciPy
>> can't replace Octave/Matlab... besides the existing numerical
>> libraries, I think an important reason is that the Octave language,
>> while agreeably being less powerful than Python/Ruby, is also
>> significantly more simple, which seems to be suitable to many
>> scientific programmers.
> It depends on how much do you value language's multipurpose nature.
> Yes, it's simpler to code many numerical computations in Octave. I
> know it well, because I'm involved in process of coding such
> computations.

Yes I know that "you can do everything in Python" is, in theory, a big
advantage. But for most of my work, I have the simple scheme "load
data from files" -> "do bunch of computations" -> "save data to files,
generate reports and plots" which Octave suits fairly well. Of course,
the problem arises when you want to, say, get the data from the web
rather than files, which in Python would be a small step comparably to
the effort in Octave (even when you have urlget). But I must add that
Python is a bit self-defeating here, because it's really not hard to
make Python just use Octave, say, through pipes, and it's way easier
for me than working in Python from start. Of course, such bridges
suffer from portability problems...
so it's all about "yes, Python is better, but it's not better enough
to be actually better for me".

> Till the algorithm is in developing stage Matlab or Octave fits best.

Yeah, hey - I have a lot of codes likely to stay in development stage forever :)

> But sometimes program written in such a language have to strong
> disadvantages:
>  1. Communication with the real world is not so easy (such languages
> lacks many facilities useful for enhanced input/output, GUI, etc. and
> other "technical" libraries).

True, definitely. But since Python and Ruby are such great glue
languages, there's usually a strong competing alternative - do your
computing in Octave, and just glue it with I/O or GUI using Python or
Ruby.
If, for instance, Pytave will ever get mature enough, then things like
Numpy will just lose attractiveness for me.

>  2. Performance. (Sometimes the only reason to reimplement algorithm
> written using Octave or Matlab is slow execution.)

This is typically true for algorithms that don't fit well the
vectorized nature of Octave, and are best expressed in loops.
Octave's internals are, of course, optimized, like Python's, so as
long as you can express your algorithm well using internals, you have
good performance.
Unfortunately, when you don't, my experience shows that while loopy
code is many times faster in Python than in Octave, it is usually
still significantly faster in C++ - and Octave makes it easy to
connect to C++ - so I just do it in C++ even though it's less elegant
than a Python solution.

Hopefully Octave will eventually have JIT compiling at least of the
simple loops. I would, of course, greatly appreciate connecting Octave
and Python, especially using Octave from within Python.

>> Octave's pass-by-value mechanism (with lazy copy-on-write) is
>> something that is *far* more simple to grasp than NumPy's inherited
>> everything-is-a-reference semantics. I do regard myself as moderately
>> experienced Python programmer, yet every now and then I get shot in
>> the foot by the reference semantics in Python. In Octave, you just
>> don't care about mutable and non-mutable objects - everything works
>> *as if* passed by value. Of course there's a big price to pay for that
>> - you can't actually pass-by-reference except by ugly hacks, but after
>> experiencing both Python and Octave I still regard it as a very good
>> trade.
> I think it's a matter of habit.

Yeah, most likely. But the Python/Ruby habit is just harder to grasp,
and somewhat more error-prone, at least until it gets into your veins.
That's its price for being more powerful.
And of course Octave's syntax is much closer to the numerics. Python
is *very* flexible, so it can get really close, but not really there.
A' * B is more readable than A.T * B (the latter gets worse if your
matrices are components, like packet.X.T * data.Y). Not speaking about
the fact that NumPy doesn't seem to use xGEMM(TRANSA='T') in this
case, but that's a matter of better optimization.

> By the way, pass-by-reference reminds
> me another issue. Matlab-like languages often lacks many small but
> very useful things like built-in support for different encoding in
> strings, hashes (assotiative arrays) and powerful mechanisms for
> program organization.

These two are good examples of features that I think would be good to
have in Octave but I never actually needed them. I was surprised there
is no extension package for at least basic support of associative
arrays - apparently nobody really needs it.

> Of course, languages such as Matlab and Octave could be improved to be
> more powerful, but it's not clear for me is this way more
> productive...
>

Depends. For me, improving Octave seemed far more productive than
switching to NumPy. Back then NumPy didn't even have a good free
manual. And believe it or not, I had less difficulty hacking together
a working compiled extension for Octave than for Python.

regards


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