Octave Forge

On Sat, Aug 29, 2009 at 12:23 AM, Alex
Lancaster<alexl@...> wrote:

> which produces the error:
>
> warning: lo_ieee_init: unrecognized floating point format!
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> mkdir (/tmp/oct-Me8WmG)
> untar (/var/tmp/java-1.2.6.tar.gz, /tmp/oct-Me8WmG)
> error: memory exhausted or requested size too large for range of Octave's index type -- eval failed
>
> I'm not sure how to debug much further than this.
>

I can reproduce this error on FC11 (i386) with octave 3.2.2 as well. I
did few steps futher:

try to install java package from the octave prompt:

octave:1> pkg install java-1.2.6.tar.gz
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
__java__.cc: In function ‘void initialize_jvm()’:
__java__.cc:385: warning: deprecated conversion from string constant to ‘char*’
... < few warnings deleted > ...

2 problems (2 warnings)error: memory exhausted or requested size too
large for range of Octave's index type -- trying to return to prompt
octave:1>

Then I tried to build the package in bash shell with ./configure and
make, then it succeeds:

2 problems (2 warnings)rm -f octave.jar
jar cf octave.jar  org/octave/ClassHelper.class
org/octave/OctClassLoader.class  org/octave/Octave.class
org/octave/OctaveReference.class  org/octave/Matrix.class

It appears to me that it is this "jar cf ... " command that crashes
octave's pkg.
So may be it is an octave bug. Crossposting to the octave mailing list...


> More details available on the Fedora downstream bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=510841
>
> Note that ppc, ppc64 and x86_64 builds all seem to complete correctly.
>
> Alex
>
>

Dmitri.
--

On 29-Aug-2009, Dmitri A. Sergatskov wrote:

| On Sat, Aug 29, 2009 at 12:23 AM, Alex
| Lancaster<alexl@...> wrote:
| 
| > which produces the error:
| >
| > warning: lo_ieee_init: unrecognized floating point format!

I think the first thing to do is find why this is happening.  It may
not solve your other problems, but this is a serious error for Octave,
so you should find out why it is happening and fix it.  Maybe we
should make it fatal instead of just a warning.

jwe

On Sat, Aug 29, 2009 at 11:07 AM, John W. Eaton<jwe@...> wrote:
> On 29-Aug-2009, Dmitri A. Sergatskov wrote:
>
> | On Sat, Aug 29, 2009 at 12:23 AM, Alex
> | Lancaster<alexl@...> wrote:
> |
> | > which produces the error:
> | >
> | > warning: lo_ieee_init: unrecognized floating point format!
>
> I think the first thing to do is find why this is happening.  It may
> not solve your other problems, but this is a serious error for Octave,
> so you should find out why it is happening and fix it.  Maybe we
> should make it fatal instead of just a warning.
>
> jwe
>

OK. I compiled octave 3.2.3_rc1 against self-compiled combined
lapack-3.2.1 + ATLAS-3.9.14 and the ieee warning gone and java package
compiles and installs fine. (I had tried 3.2.3_rc1 against Fedora's
lapack/blas or
ATLAS and it was failing the same way as 3.2.2).

Dmitri.
--

BTW, while looking into this, I checked netlib's paranoia
(against  gcc version 4.4.1 20090725 (Red Hat 4.4.1-2))

While on x86_64 it passed all tests with flying colors even with highest level
of optimization, on i386 it failed quite miserably:

===============================
gcc -O0 -o paranoia paranoia.c -lm

<skipping some passed tests>

Running test of square root(x).
Testing if sqrt(X * X) == X for 20 Integers X.
Test for sqrt monotonicity.
sqrt has passed a test for Monotonicity.
Testing whether sqrt is rounded or chopped.
Square root is neither chopped nor correctly rounded.
Observed errors run from -5.0000000e-01 to 5.0000000e-01 ulps.

Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065218e+00 as X -> 1.
DEFECT:  Calculated 7.38905609548934539e+00 for
	(1 + (-1.11022302462515654e-16) ^ (-1.80143985094819840e+16);
	differs from correct value by -3.44130679508225512e-09 .
	This much error may spoil financial
	calculations involving tiny interest rates.

<deletia>
====================

Now trying with -O2

<deletia>

Checking for guard digit in *, /, and -.
SERIOUS DEFECT:  - lacks Guard Digit, so cancellation is obscured.

Checking rounding on multiply, divide and add/subtract.
* is neither chopped nor correctly rounded.
/ is neither chopped nor correctly rounded.
Addition/Subtraction neither rounds nor chops.
Sticky bit used incorrectly or not at all.
FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.

Running test of square root(x).
Testing if sqrt(X * X) == X for 20 Integers X.
Test for sqrt monotonicity.
DEFECT:  sqrt(X) is non-monotonic for X near 2.0000000e+00 .
Testing whether sqrt is rounded or chopped.
Square root is neither chopped nor correctly rounded.
Observed errors run from -5.5000000e+00 to 5.0000000e-01 ulps.
SERIOUS DEFECT:  sqrt gets too many last digits wrong.

Testing powers Z^i for small Integers Z and i.
DEFECT:  computing
	(1.30000000000000000e+01) ^ (1.70000000000000000e+01)
	yielded 8.65041591938133811e+18;
	which compared unequal to correct 8.65041591938133914e+18 ;
		they differ by -1.02400000000000000e+03 .
Errors like this may invalidate financial calculations
	involving interest rates.
Similar discrepancies have occurred 4 times.

Seeking Underflow thresholds UfThold and E0.
FAILURE:  multiplication gets too many last digits wrong.

Smallest strictly positive number found is E0 = 0 .
FAILURE:  Either accuracy deteriorates as numbers
approach a threshold = 0.00000000000000000e+00
 coming down from 0.00000000000000000e+00
 or else multiplication gets too many last digits wrong.
Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065041e+00 as X -> 1.
DEFECT:  Calculated 1.00000000000000000e+00 for
	(1 + (0.00000000000000000e+00) ^ (inf);
	differs from correct value by -6.38905609893065041e+00 .
	This much error may spoil financial
	calculations involving tiny interest rates.

Searching for Overflow threshold:
This may generate an error.
Can `Z = -Y' overflow?
Trying it on Y = -inf .
finds a FLAW:  -(-Y) differs from Y.
Overflow threshold is V  = -inf .
Overflow saturates at V0 = inf .
No Overflow should be signaled for V * 1 = -inf
                           nor for V / 1 = -inf .
Any overflow signal separating this * from the one
above is a DEFECT.
FAILURE:  Comparisons involving +--inf, +-inf
and +-0 are confused by Overflow.

SERIOUS DEFECT:    X / X differs from 1 when X = -inf
  instead, X / X - 1/2 - 1/2 = nan .
SERIOUS DEFECT:    X / X differs from 1 when X = 0.00000000000000000e+00
  instead, X / X - 1/2 - 1/2 = nan .

The number of  FAILUREs  encountered =       4.
The number of  SERIOUS DEFECTs  discovered = 4.
The number of  DEFECTs  discovered =         3.
The number of  FLAWs  discovered =           2.

The arithmetic diagnosed has unacceptable Serious Defects.
Potentially fatal FAILURE may have spoiled this program's subsequent diagnoses.
END OF TEST.
===========================================

 -mieee-fp does not seem to change anything....

FWIW.

Dmitri.
--

On 29-Aug-2009, Dmitri A. Sergatskov wrote:

| On Sat, Aug 29, 2009 at 11:07 AM, John W. Eaton<jwe@...> wrote:
| > On 29-Aug-2009, Dmitri A. Sergatskov wrote:
| >
| > | On Sat, Aug 29, 2009 at 12:23 AM, Alex
| > | Lancaster<alexl@...> wrote:
| > |
| > | > which produces the error:
| > | >
| > | > warning: lo_ieee_init: unrecognized floating point format!
| >
| > I think the first thing to do is find why this is happening.  It may
| > not solve your other problems, but this is a serious error for Octave,
| > so you should find out why it is happening and fix it.  Maybe we
| > should make it fatal instead of just a warning.
| >
| > jwe
| >
| 
| OK. I compiled octave 3.2.3_rc1 against self-compiled combined
| lapack-3.2.1 + ATLAS-3.9.14 and the ieee warning gone and java package
| compiles and installs fine. (I had tried 3.2.3_rc1 against Fedora's
| lapack/blas or
| ATLAS and it was failing the same way as 3.2.2).

I was thinking that the version of ATLAS or BLAS shouldn't have
anything to do with this warning, but then I realized that we now use
D1MACH to compute some machine constants and then compare them against
some known values to determine the floating point format (see
liboctave/mach-info.cc).  The D1MACH function in Octave used to be
implemented using some old code from netlib (machar.c) but now uses
the DLAMCH function from LAPACK.  So I suppose the warning about
unrecognized floating point format could happen if the DLAMCH function
is miscompiled.

jwe

On Sun, Aug 30, 2009 at 4:21 AM, John W. Eaton<jwe@...> wrote:
> I was thinking that the version of ATLAS or BLAS shouldn't have
> anything to do with this warning, but then I realized that we now use
> D1MACH to compute some machine constants and then compare them against
> some known values to determine the floating point format (see
> liboctave/mach-info.cc).  The D1MACH function in Octave used to be
> implemented using some old code from netlib (machar.c) but now uses
> the DLAMCH function from LAPACK.  So I suppose the warning about
> unrecognized floating point format could happen if the DLAMCH function
> is miscompiled.

I remember that I had a similar problem when using MSVC/f2c. I don't
remember exactly all bits and pieces (as I don't have my laptop under
the hand), but I had to disable optimization when compiling the related
files in LAPACK.

Michael.

> On 29-Aug-2009, Dmitri A. Sergatskov wrote:

>> On Sat, Aug 29, 2009 at 11:07 AM, John W. Eaton<jwe@...> wrote:
>>> On 29-Aug-2009, Dmitri A. Sergatskov wrote:
>>
>> | On Sat, Aug 29, 2009 at 12:23 AM, Alex
>> | Lancaster<alexl@...> wrote:
>> |
>> | > which produces the error:
>> | >
>> | > warning: lo_ieee_init: unrecognized floating point format!
>>
>> I think the first thing to do is find why this is happening.  It may
>> not solve your other problems, but this is a serious error for Octave,
>> so you should find out why it is happening and fix it.  Maybe we
>> should make it fatal instead of just a warning.
>>
>> jwe

> OK. I compiled octave 3.2.3_rc1 against self-compiled combined
> lapack-3.2.1 + ATLAS-3.9.14 and the ieee warning gone and java
> package compiles and installs fine. (I had tried 3.2.3_rc1 against
> Fedora's lapack/blas or ATLAS and it was failing the same way as
> 3.2.2).

Hi Dmitri,

That's good news.  So what do we need to do to fix this in Fedora
rawhide?  Update to octave 3.2.3_rc1 for one, obviously, and then do
we need to upgrade Fedora's lapack and Atlas packages, or are there
additional configuration changes in their (or octave/octave-forge)
spec files?

Alex

On Mon, Aug 31, 2009 at 1:28 AM, Alex
Lancaster<alexl@...> wrote:

> Hi Dmitri,
>
> That's good news.  So what do we need to do to fix this in Fedora
> rawhide?  Update to octave 3.2.3_rc1 for one, obviously, and then do
> we need to upgrade Fedora's lapack and Atlas packages, or are there
> additional configuration changes in their (or octave/octave-forge)
> spec files?
>

The main issue is that gcc 4.4.1 appears to have problems on i386.
That leads to mis-compiled DLAMCH routine from lapack 3.1.1.
I do not know why the problem goes avay with lapack 3.2.1,
perhaps it is re-written and more robust now, or it gets compiled
with different optimization flags.
As things stands now, the octave 3.2.2 (from RPM package) on i386
will not pass "make check" test.

> Alex
>

Dmitri.
--

Apparently dlamch used to be compiled on Fedora with -Os
optimization. May be it was OK before, but now it is definitely too
much. When i recompiled dlamch with  "-ffloat-store -O0"
(as well as slamch and few others,
actually I just replaced -Os flag in the Makefile with "-ffloat-store -O0)
lapack works fine.
I am not sure if -ffloat-store is redundant in this context, but I
decided it would not hurt.

I filled a bug report against lapack on Fedora's bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=520518

FYI.

Dmitri.
--