Jaroslav Hajek | 19 Nov 11:52 2009
Picon

Re: BLAS under Mac OS X 10.6.x



On Thu, Nov 19, 2009 at 3:40 AM, Marius Schamschula <lists <at> schamschula.com> wrote:
Hi all,

In the configuration process for Mac OS X 10.6.x I'm getting the following issue:

configure: WARNING: A BLAS library was detected but found incompatible with your Fortran 77 compiler.  The reference BLAS implementation will be used. To improve performance, consider using a different Fortran compiler or a switch like -ff2c to make your Fortran compiler use a calling convention compatible with the way your BLAS library was compiled, or use a different BLAS library.

I'm configuring using gfortan 4.4.2 which is 64 clean

gfortran --version
GNU Fortran (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYIN

file /usr/local/gcc-4.4/bin/gfortran          
/usr/local/gcc-4.4/bin/gfortran: Mach-O 64-bit executable

The library in questions is Apple's libBLAS:

lipo -detailed_info /System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/libBLAS.dylib
Fat header in: /System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/libBLAS.dylib
fat_magic 0xcafebabe
nfat_arch 3
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    offset 4096
    size 8725280
    align 2^12 (4096)
architecture i386
    cputype CPU_TYPE_I386
    cpusubtype CPU_SUBTYPE_I386_ALL
    offset 8732672
    size 4550288
    align 2^12 (4096)
architecture ppc
    cputype CPU_TYPE_POWERPC
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 13283328
    size 6994800
    align 2^12 (4096)

which includes the x86_64 architecture.

I tried passing the -ff2c flag w/o any effect.

What am I missing?

TIA

Marius
--
Marius Schamschula




What sources are you compiling? Please post your config.log somewhere (or attach compressed).

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
Marius Schamschula | 19 Nov 12:52 2009

Re: BLAS under Mac OS X 10.6.x

Jaroslav,

The source is octave 3.2.3. Here is the config.log file:

Attachment (config.log.gz): application/applefile, 102 bytes
Attachment (config.log.gz): application/x-gzip, 18 KiB


On Nov 19, 2009, at 4:52 AM, Jaroslav Hajek wrote:



On Thu, Nov 19, 2009 at 3:40 AM, Marius Schamschula <lists <at> schamschula.com> wrote:
Hi all,

In the configuration process for Mac OS X 10.6.x I'm getting the following issue:

configure: WARNING: A BLAS library was detected but found incompatible with your Fortran 77 compiler.  The reference BLAS implementation will be used. To improve performance, consider using a different Fortran compiler or a switch like -ff2c to make your Fortran compiler use a calling convention compatible with the way your BLAS library was compiled, or use a different BLAS library.

I'm configuring using gfortan 4.4.2 which is 64 clean

gfortran --version
GNU Fortran (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYIN

file /usr/local/gcc-4.4/bin/gfortran          
/usr/local/gcc-4.4/bin/gfortran: Mach-O 64-bit executable

The library in questions is Apple's libBLAS:

lipo -detailed_info /System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/libBLAS.dylib
Fat header in: /System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/libBLAS.dylib
fat_magic 0xcafebabe
nfat_arch 3
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    offset 4096
    size 8725280
    align 2^12 (4096)
architecture i386
    cputype CPU_TYPE_I386
    cpusubtype CPU_SUBTYPE_I386_ALL
    offset 8732672
    size 4550288
    align 2^12 (4096)
architecture ppc
    cputype CPU_TYPE_POWERPC
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 13283328
    size 6994800
    align 2^12 (4096)

which includes the x86_64 architecture.

I tried passing the -ff2c flag w/o any effect.

What am I missing?

TIA

Marius
--
Marius Schamschula




What sources are you compiling? Please post your config.log somewhere (or attach compressed).

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

--
Marius Schamschula




_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
Jaroslav Hajek | 19 Nov 13:24 2009
Picon

Re: BLAS under Mac OS X 10.6.x



On Thu, Nov 19, 2009 at 12:52 PM, Marius Schamschula <lists <at> schamschula.com> wrote:
Jaroslav,

The source is octave 3.2.3. Here is the config.log file:


According to your config.log, the following test program failed with your configuration, using the command

/usr/local/gcc-4.4/bin/gfortran -fsecond-underscore -ff2c -o conftest -O -mieee-fp -L/usr/local/gcc-4.4/lib/gcc-4.4/ -L/usr/X11R6/lib -L/usr/local/lib -L/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A -lBLAS -lLAPACK conftest.f  -lhdf5 -lz -lm
./conftest

|       program main
|
|       real sdot,a(1),b(1),w
|       external sdot
|       a(1) = 1e0
|       b(1) = 2e0
|       w = sdot(1,a,1,b,1)
|       if (w .ne. a(1)*b(1)) stop 1
|
|       end
 
the program must not crash and must exit with status 0 (the last test must not pass). Please verify. You need to find out why this happens. Most likely this means that the calling convention used (or assumed) for your BLAS does not match gfortran's. Typically this happens for g77-compatible BLASes.
Please note also that if your BLAS uses 64-bit integers, you must enable 64-bit integers for Fortran and compile octave with 64-bit indexing enabled. The development sources of Octave include a check that the integer sizes between C++/Fortran and Fortran/BLAS indeed match.

hth

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
David Bateman | 19 Nov 20:32 2009

Re: eigs crash on a particular spare matrix

Jaroslav Hajek wrote:
>
> If this is a bug in ARPACK (and it seems so), we probably can't fix it in
> Octave. We could at most check whether the values we feed to ARPACK are
> correct. David, will you have time to look at this? If not, I'll put it on
> my long-term list, but don't expect a solution anytime soon.
>
> regards
>
>   
I believe I found this exact problem in the thread

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2006-September/000631.html

and a patch to ARPACK to fix it in the thread

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2006-November/001230.html

that I sent to the ARPACK maintainers in the attached message in 2006 
with no feedback whatsoever. If someone wants to take this up and see a 
fix in ARPACK I'd be happy, but don't want to spend more time on it myself

D.

-- 
David Bateman                                dbateman <at> dbateman.org
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

From: David Bateman <David.Bateman <at> motorola.com>
Subject: Problem with ARPACK for unsymmetric matrices where the Ritz values need reordering
Date: 2006-11-03 11:34:17 GMT
To whom it may concern,

I believe I have found a bug in ARPACK for the case of an unsymmetric 
matrix where the values need reordering while trying to write a binding 
to ARPACK for octave. The issue is with xTRSEN running a value of M that 
exceeds NCONV, M being an output value of xTRSEN, that is returned in 
NCONV effectively replacing it. This results in a segmentation fault in 
the follow xCOPY commands. This can only be guarenteed to be avoided 
with the current code if the size of the vectors for the eigenvalues and 
vectors are ncv (rather than k+1) in size. Please find attached three 
files that I believe demonstrate the issue.

eigs.cc : This is a draft version of my eigs function for octave. It 
currently treats all matrices as sparse and is too monolithic. I'll 
split this up into C++ class and treat full matrices in the need 
future.. This is compiled as "mkoctfile eigs.cc -larpack"
segtest.m: This is a test function, that is called like "segtest(10)" 
within octave 2.9.6 or better that will demonstrate the issue.. The 
seg-fault happens depending on the random starting vector and so this 
might need to be run several times.
patch: This is a proposed patch that appears to address the segmentation 
fault.

Sorry not to supply a smaller test example for you, but I hope the 
problem is obvious enough from the patch not to need one :-). I believe 
that matlab avoids this issue, by using shift-invert for the case in the 
segtest script (I couldn't get matlab to crash), though due to the fact 
that I'm writing an open-source replacement I'm unwilling to examine the 
matlab source for eigs.m to see if this is the case to avoid copyright 
issues...

Regards
David

Attachment (eigs.cc): text/x-c++src, 54 KiB
*** __imagemagick__.cc.~1.1.~	2006-08-20 14:59:36.000000000 +0200
--- __imagemagick__.cc	2006-09-07 16:44:47.636767482 +0200
***************
*** 4,9 ****
--- 4,15 ----
  using namespace std;
  using namespace Magick;

+ unsigned int scaleQuantumToDepth (const Quantum &_quantum, unsigned int depth)
+ {
+   return (static_cast<unsigned int> (static_cast<double>(_quantum) / 
+ 				     QuantumRange * ((1 << depth) - 1)));
+ }
+ 
  octave_value_list read_indexed_images(vector<Image> imvec, Array<int> frameidx, bool wantalpha)
  {
      octave_value_list output;
***************
*** 105,111 ****
  }

  template <class T>
! octave_value_list read_images(vector<Image> imvec, Array<int> frameidx)
  {
    int i;
    T im;  
--- 111,118 ----
  }

  template <class T>
! octave_value_list read_images(vector<Image> imvec, Array<int> frameidx,
! 			      unsigned int depth)
  {
    int i;
    T im;  
***************
*** 113,119 ****
    int columns = imvec[0].baseColumns();
    int nframes = frameidx.length();
    ImageType type = imvec[0].type();
-   
    int x, y, frame;
    const PixelPacket *pix;
    dim_vector idim = dim_vector();
--- 120,125 ----
***************
*** 133,139 ****
  	      i = 0;      
  	      for(y=0; y < rows; y++) {
  		  for(x=0; x < columns; x++) {        
! 		      im(y, x, frame) = pix[i++].red;
  		  }
  	      }
  	  }
--- 139,145 ----
  	      i = 0;      
  	      for(y=0; y < rows; y++) {
  		  for(x=0; x < columns; x++) {        
! 		    im(y, x, frame) = scaleQuantumToDepth (pix[i++].red, depth);
  		  }
  	      }
  	  }
***************
*** 150,158 ****
  		  for(x=0; x < columns; x++) {
  		      idx(1) = x;
  		      idx(2) = 0;
! 		      im(idx) = pix[i].red;
  		      idx(2) = 1;
! 		      im(idx) = pix[i].opacity;
  		      i++;
  		  }
  	      }
--- 156,164 ----
  		  for(x=0; x < columns; x++) {
  		      idx(1) = x;
  		      idx(2) = 0;
! 		      im(idx) = scaleQuantumToDepth (pix[i].red, depth);
  		      idx(2) = 1;
! 		      im(idx) = scaleQuantumToDepth (pix[i].opacity, depth);
  		      i++;
  		  }
  	      }
***************
*** 171,181 ****
  		  for(x=0; x < columns; x++) {
  		      idx(1) = x;
  		      idx(2) = 0;
! 		      im(idx) = pix[i].red;
  		      idx(2) = 1;
! 		      im(idx) = pix[i].green;
  		      idx(2) = 2;
! 		      im(idx) = pix[i].blue;
  		      i++;
  		  }
  	      }
--- 177,187 ----
  		  for(x=0; x < columns; x++) {
  		      idx(1) = x;
  		      idx(2) = 0;
! 		      im(idx) = scaleQuantumToDepth (pix[i].red, depth);
  		      idx(2) = 1;
! 		      im(idx) = scaleQuantumToDepth (pix[i].green, depth);
  		      idx(2) = 2;
! 		      im(idx) = scaleQuantumToDepth (pix[i].blue, depth);
  		      i++;
  		  }
  	      }
***************
*** 195,207 ****
  		  for(x=0; x < columns; x++) {
  		      idx(1) = x;
  		      idx(2) = 0;
! 		      im(idx) = pix[i].red;
  		      idx(2) = 1;
! 		      im(idx) = pix[i].green;
  		      idx(2) = 2;
! 		      im(idx) = pix[i].blue;
  		      idx(2) = 3;
! 		      im(idx) = pix[i].opacity;
  		      i++;
  		  }
  	      }
--- 201,213 ----
  		  for(x=0; x < columns; x++) {
  		      idx(1) = x;
  		      idx(2) = 0;
! 		      im(idx) = scaleQuantumToDepth (pix[i].red, depth);
  		      idx(2) = 1;
! 		      im(idx) = scaleQuantumToDepth (pix[i].green, depth);
  		      idx(2) = 2;
! 		      im(idx) = scaleQuantumToDepth (pix[i].blue, depth);
  		      idx(2) = 3;
! 		      im(idx) = scaleQuantumToDepth (pix[i].opacity, depth);
  		      i++;
  		  }
  	      }
***************
*** 217,225 ****
  }

  // instantiate templates
! template octave_value_list read_images<boolNDArray>(vector<Image>, Array<int>);
! template octave_value_list read_images<uint8NDArray>(vector<Image>, Array<int>);
! template octave_value_list read_images<uint16NDArray>(vector<Image>, Array<int>);

  DEFUN_DLD(__magick_read__, args, nargout,
  "function m = __imagemagick_read__(fname[, index])\n\
--- 223,236 ----
  }

  // instantiate templates
! template octave_value_list read_images<boolNDArray>(vector<Image>, Array<int>,
! 						    unsigned int depth);
! template octave_value_list read_images<uint8NDArray>(vector<Image>, 
! 						     Array<int>,
! 						     unsigned int depth);
! template octave_value_list read_images<uint16NDArray>(vector<Image>, 
! 						      Array<int>,
! 						      unsigned int depth);

  DEFUN_DLD(__magick_read__, args, nargout,
  "function m = __imagemagick_read__(fname[, index])\n\
***************
*** 276,297 ****
      if(klass == PseudoClass && nargout > 1) {
  	output = read_indexed_images(imvec, frameidx, (nargout == 3));
      } else {
! 	int depth = imvec[0].modulusDepth();
  	i = 0;
  	while(depth >>= 1) i++;
  	depth = 1 << i;
  	
  	switch(depth) {
  	    case 1:
! 		output = read_images<boolNDArray>(imvec, frameidx);
  	    break;
  	    case 2:
  	    case 4:
  	    case 8:
! 		output = read_images<uint8NDArray>(imvec, frameidx);		
  	    break;
  	    case 16:
! 		output = read_images<uint16NDArray>(imvec, frameidx);		
  	    break;
  	    case 32:
  	    case 64:
--- 287,308 ----
      if(klass == PseudoClass && nargout > 1) {
  	output = read_indexed_images(imvec, frameidx, (nargout == 3));
      } else {
! 	unsigned int depth = imvec[0].modulusDepth();
  	i = 0;
  	while(depth >>= 1) i++;
  	depth = 1 << i;
  	
  	switch(depth) {
  	    case 1:
! 		output = read_images<boolNDArray>(imvec, frameidx, depth);
  	    break;
  	    case 2:
  	    case 4:
  	    case 8:
! 		output = read_images<uint8NDArray>(imvec, frameidx, depth);		
  	    break;
  	    case 16:
! 		output = read_images<uint16NDArray>(imvec, frameidx, depth);		
  	    break;
  	    case 32:
  	    case 64:
function aerr = segtest (iter)
  %% This will seg-fault octave consistently, but not matlab.
  n=20;
  k=4; 
  A = sparse([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],[ones(1,n-2),4*ones(1,n),-ones(1,n-2)]);
  opts.disp = 0; opts.p = 19;
  aerr = 0;
  for i=1:iter
    [v1,d1] = eigs(A, k, 'sr', opts);
    d1 = diag(d1);
    merr = 0;
    for i=1:k
      newerr = max(abs((A - d1(i)*speye(n))*v1(:,i)));
      if (newerr > merr)
        merr = newerr;
      end
    end
    fprintf('Max Err: %g\n', merr);
    if (merr > aerr)
      aerr = merr;
    end
  end
end
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
Peter L. Søndergaard | 19 Nov 00:35 2009
Picon

nargchk always fails

Hi everyone,

I guard all the functions I write with:

error(nargchk(1,4,nargin));

But after the last update to 3.2.3 (in Fedora 11) this construction
always fails.

If I try

a=nargchk(1,4,2);
whos a

I get:

 Attr Name        Size                     Bytes  Class
  ==== ====        ====                     =====  ===== 
       a           0x0                          0  char

An error(a) gives me:

octave:19> error(a)
error:

Where as error([]) does not cause a problem.

On Matlab, nargchk(1,4,2) also returns [] and not ""

This is actually a quite serious bug, as it stops all functions from
working.

Cheers,

Peter.
John W. Eaton | 19 Nov 23:04 2009

nargchk always fails

On 19-Nov-2009, "Peter L." Søndergaard wrote:

| Hi everyone,
| 
| I guard all the functions I write with:
| 
| error(nargchk(1,4,nargin));
| 
| But after the last update to 3.2.3 (in Fedora 11) this construction
| always fails.
| 
| If I try
| 
| a=nargchk(1,4,2);
| whos a
| 
| I get:
| 
|  Attr Name        Size                     Bytes  Class
|   ==== ====        ====                     =====  ===== 
|        a           0x0                          0  char
| 
| An error(a) gives me:
| 
| octave:19> error(a)
| error:
| 
| Where as error([]) does not cause a problem.
| 
| On Matlab, nargchk(1,4,2) also returns [] and not ""
| 
| This is actually a quite serious bug, as it stops all functions from
| working.

This problem has already been reported

  https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-September/009550.html

and I think it is fixed by this change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/ef45d191d833

jwe
Jaroslav Hajek | 20 Nov 10:17 2009
Picon

Re: octave-3.2.3: krylov.m: missing function "swap"



On Sun, Oct 18, 2009 at 1:44 PM, Lukas Reichlin <lukas.reichlin <at> swissonline.ch> wrote:
Dear Octave Community

I noticed that the file krylov.m

http://hg.savannah.gnu.org/hgweb/octave/file/9bc642ea9006/scripts/linear-algebra/krylov.m

uses a trivial function called swap.m. This function has been moved to the control package. Therefore, krylov won't work unless the control package is installed. As a fix, I added the swap routine at the end of the krylov m-file.

Could someone with the necessary rights please commit the change? The new file is attached to this mail.

Regards,
Lukas

Applied. Next time please send a complete patch to source tree or at least include a ChangeLog entry, most likely your contribution will be processed faster.

thanks

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
Jaroslav Hajek | 20 Nov 10:06 2009
Picon

Re: Something wrong with the logical indexing of structure arrays



On Thu, Nov 12, 2009 at 1:18 PM, Daniel Arteaga <daniel.arteaga <at> barcelonamedia.org> wrote:
Subject: Something wrong with the logical indexing of structure arrays
--------
Bug report for Octave 3.2.2 configured for i486-pc-linux-gnu

Description:
-----------

When combining the logical indexing of structure arrays and the use of
the deal() function an unexpected error appears. It looks like that deal
takes as vargout the entire structure without logical indexing. See
following section for the example.

Repeat-By:
---------

st(3).test = [];
a = logical([1 0 1]);
[st(a).test] = deal(1);

The following error appears:

error: A(I) = X: X must have the same size as I

While the expected value for st.test would be:

st(1).test = 1
st(2).test = []
st(3).test = 1

The above code works in Matlab.



I fixed this in the development version:
http://hg.savannah.gnu.org/hgweb/octave/rev/10519b4d6507
not directly applicable to 3.2.x so I'm not sure whether 3.2.x will be fixed.

thanks

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
Jaroslav Hajek | 20 Nov 10:43 2009
Picon

Re: Legend label order



On Fri, Oct 9, 2009 at 2:56 PM, Marco Caliari <marco.caliari <at> univr.it> wrote:
Dear maintainers,

it appears that the changeset

http://hg.savannah.gnu.org/hgweb/octave/rev/350148cc0774

was not ported to 3.2.3 and the following

x=linspace(0,10);,plot(x,x,x,x.^2),legend('linear')

gives a wrong legend label.

Best regards,

Marco

transplanted, thanks

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
Jaroslav Hajek | 20 Nov 10:44 2009
Picon

Re: wavread function bug



2009/10/22 John W. Eaton <jwe <at> octave.org>
On 22-Oct-2009, Piotr Sok�,Bs3 wrote:

| I found a bug in waveread function from audio toolbox: in line 172 there
| is variable "ck_size" and I suppose it should be "data_size".

This problem seems to be fixed in the current sources, but not in the
3.2.x release branch.  Jaroslav, the changeset is here:

 http://hg.savannah.gnu.org/hgweb/octave/rev/70de69177370

Thanks,

jwe

transplanted to 3.2.x

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

Gmane