[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC project: new graphics backend
From: |
Igor V. Burago |
Subject: |
Re: GSoC project: new graphics backend |
Date: |
Sat, 21 Mar 2009 00:15:27 +1000 |
> 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.
> 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.
> 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!
> 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.
--
Igor V. Burago
- Re: GSoC project: new graphics backend, (continued)
- Re: GSoC project: new graphics backend, Igor V. Burago, 2009/03/20
- Re: GSoC project: new graphics backend, Shai Ayal, 2009/03/20
- Re: GSoC project: new graphics backend, Igor V. Burago, 2009/03/20
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/20
- Re: GSoC project: new graphics backend, Igor V. Burago, 2009/03/20
- Re: GSoC project: new graphics backend, John Swensen, 2009/03/20
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/20
- Re: GSoC project: new graphics backend, Jaroslav Hajek, 2009/03/20
Re: GSoC project: new graphics backend, Eric S. Carlson, 2009/03/22
- Re: GSoC project: new graphics backend, Ben Abbott, 2009/03/22
- Re: GSoC project: new graphics backend, Søren Hauberg, 2009/03/22
- Re: GSoC project: new graphics backend, Eric S. Carlson, 2009/03/22
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/23
- Re: GSoC project: new graphics backend, Eric S. Carlson, 2009/03/24
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/26
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/26