Wed 10 Jun 2015 08:15:32 AM UTC, comment #13:
I have also confirmed the fix. Great.
(under Lubuntu 14.04 32bit with openjdk-7)
|
Wed 10 Jun 2015 07:16:11 AM UTC, comment #12:
Great, it works for me, thank you Rik.
|
Tue 09 Jun 2015 11:13:38 PM UTC, comment #11:
I committed the change here (http://hg.savannah.gnu.org/hgweb/octave/rev/209ee4a730f6). This will be a part of the 4.0.1 bug release version on the stable branch.
|
Tue 09 Jun 2015 07:16:14 PM UTC, comment #10:
Rik, your patch looks good to me. Seems that somehow I forgot about doubles on my patch. Somehow, the code then falls through the ClassHelper where it is converted to float.
Could you please push it? Does this counts as a 4.0 regression?
I'm guessing we may have some duplicated code between our java and C++ code which I'll need to take a closer look.
|
Mon 08 Jun 2015 07:56:57 PM UTC, comment #9:
I've attached a diff which seems to fix the problem. But Carnë should review since I'm not really a Java expert.
(file #34182)
|
Mon 08 Jun 2015 07:14:33 PM UTC, comment #8:
Actually, the bisection was off slightly. The real changeset that introduced the bug was:
I uncommented out the println() debugging in ClassHelper.java:castArgument and I see
|
Mon 08 Jun 2015 06:56:31 PM UTC, comment #7:
I did a bisection and found that the changeset that introduced the problem was:
I'm adding Carnë to the CC list for this bug. Maybe he will know why this is a problem.
|
Mon 08 Jun 2015 04:24:32 PM UTC, comment #6:
I have replicated the results in comment #5 on 64-bit Ubuntu (12.04 LTS) with both Octave 3.8.2 (works) and Octave 4.0.0 (fails). Maybe it was obvious, but after creating the Myclass.java file I also needed to run 'javac Myclass.java' to create a .class file.
Just quickly glancing through the Mercurial logs, this changeset looks suspicious.
|
Sun 07 Jun 2015 11:53:07 PM UTC, comment #5:
It was actually the CastException in comment #1 that made me suspect there might be an unintended cast from double to float. The cast could lead both to the test failure and to the observed loss of precision introduced in octave 4.0.0.
Below I'll provide a minimal example to show what is described in comment #4.
Java class: myjavapackage/Myclass.java:
Test on octave 3.8.1 (Ubuntu 32bit). Works as expected:
Test on octave 4.0.0 (OpenSuse 34bit). Looses precision when passing double to java:
The test shows that the precision is lost when passing the vector from octave to java.
I tried to find the changes in octave code that could cause the change. As I don't know the code base and beeing familiar with java only I had no success.
Could someone check if it is related to changeset 20122:81fcf4aa9e03 ? In the current file libinterp/octave-value/ov-java.cc at lines 1284-1308 I don't see anything about double type, might it be missing (just a random guess)?
I hope this information is useful.
|
Sun 07 Jun 2015 01:37:19 AM UTC, comment #4:
Possibly only confusing, but here is a related report from Adrian from the octave-maintainer's list.
I'm not sure if the following observation concerning the java interface is related to the topic, but maybe.
When I compare results I get from calculations that are actually done by a java library (input vector passed to a java lib), then I notice that the results are numerically slightly different on different octave versions.
- Octave 3.6.1 (windows) and octave 3.8.1 (linux 64bit) give the same results. The result is actually the same when using java only (reading in data in the java class instead of octave), so I'm convinced it is correct.
- Octave 4.0.0 (both on windows 64bit and linux 64bit) give slightly different results. The first 5 digits are the same, so for my use it is precise enough, but still a bit weird.
When I investigate, it seems that in octave 4.0.0 vectors are passed to the java class with lower precision (maybe float).
Sincerely,
Adrian
(Tested on OpenSuse 13.1 64bit, with OpenJDK 1.7.0 64bit with octave 4.0.0 x86_64 from repositoriy "science")
|
Sat 06 Jun 2015 11:20:40 PM UTC, comment #3:
Mike, Julien
Thank you for your test.
I have also built octave-4.0.0 using openjdk-8.
Is this issue openjdk-7, 32 bit and ubuntu specific?
#Notes
openjdk-8 can be installed to ubuntu (on June 2015) through openjdk-r/ppa
In some situation, you have to add configure option for octave
build.
|
Sat 06 Jun 2015 06:20:49 PM UTC, comment #2:
@Tatsuro: yes, it was using openjdk-7.
I have just built again with openjdk-8 and now all tests pass.
|
Sat 06 Jun 2015 02:31:38 PM UTC, comment #1:
Interesting that this error doesn't show up in the Hydra build of Octave, built against OpenJDK 7 32-bit, see full build log at
https://hydra.nixos.org/build/22885523/log/raw
Excerpts:
|
Sat 06 Jun 2015 05:45:36 AM UTC, original submission:
The topic originally has been discussed at:
http://octave.1599824.n4.nabble.com/Re-ov-java-cc-tst-fails-on-Lubuntu-14-04-td4670605.html
On octave 4.0.0 build with openjdk-7 on 32 bit platform (ubuntu), ov-java.cc-tst fails:
The same fail was observed by Julien Bect with Ubuntu 14.10 / 32 bits / gcc 4.9.1. (Perhaps openjdk-7 is used.)
In the above, only the first test in in failure.
This error appears on octave-4.0.0 + openjdk-7 + 32 bit.
On 64 bit ubuntu with openjdk-7, on 32 bit ubuntu with openjdk-6,
this error does not occur.
The test suggested by Rik,
passes on octave-4.0.0 built with openjdk-7 on 32bit ubuntu.
Rik stated in the thread introduced at the top,
Maybe the default numeric type for a 32-bit JRE is float rather than double? Seems odd though. The 32-bit JRE is supposed to be about the size of references and therefore about the size of addressable
memory.
|