octave-task-tracker
[Top][All Lists]
Advanced

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

[Octave-task-tracker] [task #13313] MingW issues for Octave built w --en


From: Philip Nienhuis
Subject: [Octave-task-tracker] [task #13313] MingW issues for Octave built w --enable-64
Date: Fri, 05 Sep 2014 19:43:26 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1

URL:
  <http://savannah.gnu.org/task/?13313>

                 Summary: MingW issues for Octave built w --enable-64
                 Project: GNU Octave
            Submitted by: philipnienhuis
            Submitted on: Fri 05 Sep 2014 09:43:25 PM CEST
         Should Start On: Fri 05 Sep 2014 12:00:00 AM CEST
   Should be Finished on: Fri 05 Sep 2014 12:00:00 AM CEST
                Category: None
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Philip Nienhuis
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
           Fixed Release: None
         Planned Release: None

    _______________________________________________________

Details:

General
=======
Altough formally the --enable-64 flag indicates only 64-bit indexes, Octave
for MinGW built with this flag is really a 64-bit Windows program (Windows XP
32bit complains that "Octave.exe is not a valid win32 program"; on Windows 7,
compatibility settings listed for 64-bit Octave exclude all 32-bit Windows
variants).


HDF5
====
See bug #43101

sparse.tst
==========

  ***** testif HAVE_HDF5   # save hdf5
 savefile = tmpnam ();
 as_save = as;
 save ("-hdf5", savefile, "bf", "as_save", "af");
 clear as_save;
 load (savefile, "as_save");
 unlink (savefile);
 assert (as_save, sparse (af));
!!!!! test failed
save: error while writing 'bf' to hdf5 file


In later builds (after patching hdf5 cf. bug #43101) there's a hard crash.
Note it is the "sparse (af)" in the assert stmt. statement that provokes the
crash, not so much writing/reading the hdf5 file.


Java
====
Octave64 expects a 64-bit JRE. I found that when Octave has been cross-built
on a 64-bit Linux box, it expects jvm.dll to be in C:\Program
Files\Java\jre7\bin\server, however when Octave has been cross-built on 32-bit
Linux (with 32-bit JDK) it expects jvm.dll to be in C:\Program
Files\Java\jre7\bin\client. Simply copying the client subdir + contents to a
server subdir (or vice versa) in the same place in the Java JRE directory tree
suffices.

I think this had better be fixed so that Octave64 always expects jvm.dll to be
in the server/ subdir for 64-bit systems, as seems to be customary for 64-bit
JRE/JDK.

Note: At least on Windows 64-bit it is perfectly possible to have both a
32-bit and a 64-bit JRE (or JDK) coexisting peacefully. The 64-bit one lives
in C:\Program Files\, the 32-bit version in C:\Program Files (X86)\

AFAICS Java class libs (.jar files) are agnostic as to whether they're called
from a 32-bit or a 64-bit JRE. 
BUT... non-Java programs living behind those .jar files do care, e.g.,
OpenOffice or LibreOffice when invoked through the UNO spreadsheet interface
in the io package. I couldn't get 32-bit LibreOffice invoked through
Octave-Forge io package's UNO interface on my 64-bit Win7 box. It only works
with 32-bit Octave.


Octave-Forge packages
=====================
Installation of some OF packages included in mxe-octave fail, apparently
(AFAICS) due to ambiguous casts / data types:

data-smoothing
fl-core
fuzzy-logic
image
io (.mex; already fixed locally, replaced by .oct. Will push later)
netcdf
odepkg
optim
quaternion


Formal Octave test suite
========================
Currently Octave64 crashes on the eig_cc.tst.
That is due to the last 4 tests in eig_cc.tst; luckily, these do not test
actual numerical stuff but merely input validation.
As a kludge, commenting out those tests lets Octave64 finish the test suite.
But obviously that is not the proper way to deal with it.

At first sight, Octave64 may yield several (~12 IIRC) Java-related test
failures. See above (32-bit vs. 64-bit JRE) for a solution.

Next there are several test failure related to tolerances:

chop.m:
=======

>>>>> processing C:\Octave\octave64-3.8.2\share\octave\3.8.2\m\general\chop.m
  ***** assert (chop (e, 3), 2.72)
!!!!! test failed
ASSERT errors for:  assert (chop (e, 3),2.72)

  Location  |  Observed  |  Expected  |  Reason
     ()          2.72         2.72       Abs err 4.4409e-016 exceeds tol 0
  ***** assert (chop (e, 4), 2.718)
!!!!! test failed
ASSERT errors for:  assert (chop (e, 4),2.718)

  Location  |  Observed  |  Expected  |  Reason
     ()         2.718        2.718       Abs err 8.8818e-016 exceeds tol 0
  ***** assert (chop (e, 4, 5), 2.72)
!!!!! test failed
ASSERT errors for:  assert (chop (e, 4, 5),2.72)

  Location  |  Observed  |  Expected  |  Reason
     ()          2.72         2.72       Abs err 4.4409e-016 exceeds tol 0
  ***** assert (chop (e, 4, 7), 2.716)
!!!!! test failed
ASSERT errors for:  assert (chop (e, 4, 7),2.716)

  Location  |  Observed  |  Expected  |  Reason
     ()         2.716        2.716       Abs err 4.4409e-016 exceeds tol 0
  ***** assert (chop (-e, 3), -2.72)
!!!!! test failed
ASSERT errors for:  assert (chop (-e, 3),-2.72)

  Location  |  Observed  |  Expected  |  Reason
     ()         -2.72        -2.72       Abs err 4.4409e-016 exceeds tol 0
  ***** assert (chop (-e, 4), -2.718)
!!!!! test failed
ASSERT errors for:  assert (chop (-e, 4),-2.718)

  Location  |  Observed  |  Expected  |  Reason
     ()         -2.718       -2.718      Abs err 8.8818e-016 exceeds tol 0
  ***** assert (chop (-e, 4, 5), -2.72)
!!!!! test failed
ASSERT errors for:  assert (chop (-e, 4, 5),-2.72)

  Location  |  Observed  |  Expected  |  Reason
     ()         -2.72        -2.72       Abs err 4.4409e-016 exceeds tol 0
  ***** assert (chop (-e, 4, 7), -2.716)
!!!!! test failed
ASSERT errors for:  assert (chop (-e, 4, 7),-2.716)

  Location  |  Observed  |  Expected  |  Reason
     ()         -2.716       -2.716      Abs err 4.4409e-016 exceeds tol 0
  ***** assert (chop (hilb (3), 3), [1,.5,.333;.5,.333,.25;.333,.25,.2])
!!!!! test failed
ASSERT errors for:  assert (chop (hilb (3), 3),[1, .5, .333; .5, .333, .25;
.333, .25, .2])

  Location  |  Observed  |  Expected  |  Reason
   (1,1)          1            1         Abs err 2.2204e-016 exceeds tol 0
   (2,1)         0.5          0.5        Abs err 1.1102e-016 exceeds tol 0
   (3,1)        0.333        0.333       Abs err 5.5511e-017 exceeds tol 0
   (1,2)         0.5          0.5        Abs err 1.1102e-016 exceeds tol 0
   (2,2)        0.333        0.333       Abs err 5.5511e-017 exceeds tol 0
   (3,2)         0.25         0.25       Abs err 5.5511e-017 exceeds tol 0
   (1,3)        0.333        0.333       Abs err 5.5511e-017 exceeds tol 0
   (2,3)         0.25         0.25       Abs err 5.5511e-017 exceeds tol 0
   (3,3)         0.2          0.2        Abs err 2.7756e-017 exceeds tol 0


num2str.m:
==========

>>>>> processing
C:\Octave\octave64-3.8.2\share\octave\3.8.2\m\general\num2str.m
  ***** xtest
 assert (num2str (1e23), "100000000000000000000000");
!!!!! known failure
ASSERT errors for:  assert (num2str (1e23),"100000000000000000000000")

  Location  |  Observed  |  Expected  |  Reason
     []      99999999999999991611392      100000000000000000000000        
Strings don't match


axis.m:
=======

>>>>> processing
C:\Octave\octave64-3.8.2\share\octave\3.8.2\m\plot\appearance\axis.m
  ***** test
 hf = figure ("visible", "off");
 unwind_protect
   a = logspace (-5, 1, 10);
   loglog (a, -a);
   axis tight;
   assert (axis (), [1e-5, 10, -10, -1e-5]);
 unwind_protect_cleanup
   close (hf);
 end_unwind_protect
!!!!! test failed
ASSERT errors for:  assert (axis (),[1e-5, 10, -10, -1e-5])

  Location  |  Observed  |  Expected  |  Reason
    (1)         1e-005       1e-005      Abs err 5.0822e-021 exceeds tol 0
    (4)        -1e-005      -1e-005      Abs err 5.0822e-021 exceeds tol 0

     
assert.m:
=========

>>>>> processing
C:\Octave\octave64-3.8.2\share\octave\3.8.2\m\testfun\assert.m
  ***** test
 x = [-40:0];
 y1 = (10.^x).*(10.^x);
 y2 = 10.^(2*x);
 assert (y1, y2, eps (y1));
 fail ("assert (y1, y2 + eps*1e-70, eps (y1))");
!!!!! test failed
ASSERT errors for:  assert (y1,y2,eps (y1))

  Location  |  Observed  |  Expected  |  Reason
    (11)        1e-060       1e-060      Abs err 4.1454e-076 exceeds tol
1.3818e-076
    (13)        1e-056       1e-056      Abs err 3.3959e-072 exceeds tol
1.132e-072
    (14)        1e-054       1e-054      Abs err 4.3467e-070 exceeds tol
1.4489e-070
    (19)        1e-044       1e-044      Abs err 3.7338e-060 exceeds tol
1.2446e-060
    (22)        1e-038       1e-038      Abs err 2.6101e-054 exceeds tol
1.3051e-054
    (23)        1e-036       1e-036      Abs err 3.341e-052 exceeds tol
1.6705e-052
    (27)        1e-028       1e-028      Abs err 2.2421e-044 exceeds tol
1.121e-044
    (29)        1e-024       1e-024      Abs err 3.6734e-040 exceeds tol
1.8367e-040


All of these appear to be simple tolerance issues.

The below FAIL seems different:

bug-38691.tst
=============

  ***** test
 unwind_protect
   addpath dir1;
   [d1_r, d1_f1, d1_f2, d1_f3] = func1 (0);
   addpath dir2;
   [d2_r, d2_f1, d2_f2, d2_f3] = func1 (0);
   assert (d1_r, 0);
   assert (d2_r, 1);
   assert (d1_f1, "dir1/func1");
   assert (d1_f2, "dir1/func2");
   assert (d1_f3, "dir1/func3");
   assert (d2_f1, "dir2/func1");
   assert (d2_f2, "dir2/func2");
   assert (d2_f3, "dir2/func3");
 unwind_protect_cleanup
   rmpath dir1;
   rmpath dir2;
 end_unwind_protect
!!!!! test failed
ASSERT errors for:  assert (d2_r,1)

  Location  |  Observed  |  Expected  |  Reason
     ()           0            1         Abs err 1 exceeds tol 0


Finally, fcn-handle test has an issue related to Octave's search path.

fcn-handle-derived-resolution.tst
=================================
  ***** test
 p = parent (7);
 assert (numel (p), 7)
!!!!! test failed
'__trace__' undefined near line 2 column 3
  ***** test
 d = derived (13);
 assert (numel (d), 13)
!!!!! test failed
'__trace__' undefined near line 2 column 3
  ***** test
 p = parent (11);
 f = @numel;
 assert (f (p), 11)
!!!!! test failed
'__trace__' undefined near line 2 column 3
  ***** test
 d = parent (21);
 f = @numel;
 assert (f (d), 21)
!!!!! test failed
'__trace__' undefined near line 2 column 3
  ***** test
 o(1) = other (13);
 o(2) = other (42);
 assert (getsize_loop (o), [13, 42])
!!!!! test failed
'__trace__' undefined near line 2 column 3
  ***** test
 o(1) = other (13);
 o(2) = other (42);
 assert (getsize_cellfun (o), [13, 42])
!!!!! test failed
'__trace__' undefined near line 2 column 3
  ***** test
 o(1) = other (13);
 o(2) = other (42);
 assert (getsize_arrayfun (o), [13, 42])
!!!!! test failed
'__trace__' undefined near line 2 column 3


...but when the tests are run manually, they all pass.

So all in all, ignoring eig.cc.tst and HDF5, a 64-bit MinGW Octave-3.8.2 looks
quite usable to me.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?13313>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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