Re: GSoC project: new graphics backend

[Jaroslav Hajek]

On Fri, Mar 20, 2009 at 3:15 PM, Igor V. Burago <address@hidden> wrote:
>> 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...
> Yes, it seems that languages such Python and Ruby becomes an
> multipurpose "glue" between wide variety of software today...
>
>> so it's all about "yes, Python is better, but it's not better enough
>> to be actually better for me".
> By the way, may be you should take a look at Ruby. At my opinion Ruby
> provides simpler and more consistent way to realize functionality of
> Perl and Python.

Actually, a friend of mine and a dedicated Ruby user lobbied for just
the same some time ago, so I tried to go through the tutorial - it was
much like going through the Python tutorial before, but in the end
there was no justification for the switch. I already knew Python, and
there's NumPy, SciPy, SAGE ... it just seems to me Python is more
popular in scientific computing than Ruby.

>
>> Yeah, hey - I have a lot of codes likely to stay in development stage
>> forever :)
> Oh, so do I!..
>
>> 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.
> Last year I sketched a JIT compiler for Octave subset that runs 20 -
> 40 times faster, but unfortunately I found two things: Java bytecode
> isn't a best fit for languages with dynamic typing (such as Octave
> too) and (may be most important :) I still have not time to rewrite it
> for using Parrot bytecode which suits much better.
>

It's been discussed many times on the mailing lists that the tough
part of JIT in Octave is the type inference.
Still, I think that a JIT compiler with even a very limited scope,
like compiling only loops that can be determined upon entry to never
reference out-of-bounds elements, never call functions (or except a
small defined set) and only access built-in arrays or scalars, would
still be a superb thing, and would cover 90% of the need for a JIT in
Octave.
So, contributions are certainly welcome here :)

The upcoming Octave 3.2 has been optimized in a lot of places over
3.0, and more optimizations will come. Octave can now match or even
outperform Matlab for a number of operations, even real codes - but
will still lose by orders of magnitude for the simplest JITable loops.
Of course you can hack a C++ extension for those, which gets you back
in the game, but that just doesn't seem to be a good option for many
users (and of course the C++ API is not stable, but we hope that to
happen).

>> That's its price for being more powerful.
> Absolutely!
>
>> And of course Octave's syntax is much closer to the numerics.
> I agree, it's one of the strongest arguments for Octave and Matlab.
>
>> These two are good examples of features that I think would be good to
>> have in Octave but I never actually needed them.
> It's really necessary things for solving real problems!

Not my real problems, then. Concerning the associative array, I can
usually get away with just using dynamic struct fields or explicit
lookup table for keys + a cell array for values.

>> I was surprised there
>> is no extension package for at least basic support of associative
>> arrays - apparently nobody really needs it.
> Looking for such a library, I was surprised too.
>

I'm ready to write it if I need it :)


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