[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave from java

From: Kim Hansen
Subject: Re: octave from java
Date: Sun, 17 Apr 2011 11:30:00 +0200

On Fri, Apr 15, 2011 at 15:18, frank buloup <address@hidden> wrote:
> thanks a lot for your reply, you gave me the solution : wrap every
> sent commands in an "eval()" function. THANKS YOU VERY MUCH !!!!!!!

Yes, that trick solved a lot of problems for us, it might cost a
little in performance but I don't know if it is more or less than the
cost of using pipes to talk to octave.

> I was aware of the existence of javaoctave, but never tried it. The solution
> that I've used is not so generic as your and is very linked to our needs.
> But when I was looking for the solution, I've downloaded src of javaoctave
> and
> had a look at it. I've seen that you've wrapped almost every octave type in
> a specific
> octave class. Why did you choose to do that ? Was it impossible to wrap
> octave double, or
> matrix of doubles in native java type double and double[] for instance ?

We have a lot of good reasons for doing it, and not really a reason
for not doing it as the wrappers are very cheap.
It makes it a lot easier to use the structs that we have a common
ancestor. Out matrix class uses 1-base indexes in order to look more
like octave and it is resizeable, we could not get that from

> Have you ever test your
> code in manipulating a huge amount of data (say 500*60000 array of double
> for instance) ?

I just tested it on a small program, it took 50 seconds to put() data
from Java to Octave, and 175 seconds for get() on a fairly slow
laptop. It looks like the limiting factor is octave, it uses 100% cpu
during the entire transfer. If I load or save the same data to a file
in the -text format it takes 25 and 50 seconds, it might be possible
to get the transfer times down to that by looking at the buffering
between Java and octave. Using the same data and loading from stdin
and saving to stdout takes 45 and 150 seconds, I don't really know how
to interpret that, perhaps there should be added some extra buffering
in octave when saving to stdout.

Kim Hansen
Vadgårdsvej 3,
2860 Søborg
Phone: +45 3091 2437

reply via email to

[Prev in Thread] Current Thread [Next in Thread]