Dmitrey | 1 Dec 2006 17:06
Favicon

Re: Bug-octave Digest, Vol 8, Issue 31

Does anybody know when more latest Octave version for windows than 
2.1.73 will be ready?
This one have too many MATLAB incompabilities vs latest 2.9.9
WBR, Dmitrey
Søren Hauberg | 1 Dec 2006 19:36

pkg unload

Hi,
   Currently it isn't possible to unload a package that has been loaded 
using "pkg load package_name". The attached patch allows for this.

The patch does have some problems though:
   First, the patch basicly calls rmpath. So, if the user has been using 
function A from the loaded package, that function will still be 
available after the package has been unloaded. I don't think the package 
manager can fix this. If this is a problem it should be fixed in rmpath.
   Second, if a package has a "bin" directory it will be added to 
EXEC_PATH when the package is loaded. I don't see an easy way to remove 
things from EXEC_PATH, so "pkg unload" doesn't remove the "bin" 
directory from EXEC_PATH.

Søren
Attachment (pkg.patch): text/x-patch, 3006 bytes
_______________________________________________
Bug-octave mailing list
Bug-octave <at> octave.org
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
Justus Piater | 1 Dec 2006 16:41
Picon

plot after hold on with no existing plot causes error

To: bug <at> octave.org
Cc: piater
Subject: plot after hold on with no existing plot causes error

Bug report for Octave 2.9.9 configured for i486-pc-linux-gnu

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

If I set the hold state to on ("hold on") when there is no existing
plot (no open Gnuplot window), and then call plot(...), I receive
"error: must have something to plot", presumably because the
underlying Gnuplot "replot" command does not have anything to replot.

Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Linux tool 2.6.17-2-686 #1 SMP Wed Sep 13 16:34:10 UTC 2006 i686 GNU/Linux
configure opts:   '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib'
'--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man'
'--with-blas=-lblas-3' '--with-lapack=-llapack-3' '--with-hdf5' '--with-fftw'
'--with-f77=/usr/bin/gfortran' '--enable-shared' '--enable-rpath' '--disable-static'
'--build' 'i486-linux-gnu' 'build_alias=i486-linux-gnu' 'CC=/usr/bin/gcc' 'CXX=/usr/bin/g++' 'F77=/usr/bin/gfortran'
Fortran compiler: /usr/bin/gfortran
FFLAGS:           -O2
F2C:              
F2CFLAGS:         
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/4.1.2
-L/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -lhdf5
-lz -lgfortranbegin -lgfortran -lm
(Continue reading)

Dale Grover | 1 Dec 2006 22:16

datestr/weekday/strptime, 2 bugs?

Two distinct bugs around the same function call:

Octave 2.9.9 configured for i386-apple-darwin8.8.1

(Binary for Intel download from hpc.sourceforge.net a week ago.)

(Mac OS X 10.4.8)

If I have the following code:
d=datenum(2007,1,1);
d
datestr(d,"dddd mmmm dd, yyyy")
datestr(d,"dddd")
d=d+1;
datestr(d,"dddd mmmm dd, yyyy")
datestr(d,"dddd")

I get:

octave:19> makeDates
d =  733043
ans = SunSay January 01, 2007
ans = SunSay
ans = SunSay January 02, 2007
ans = SunSay

I believe that the call being made to strptime in weekday is not 
functioning as the code intends--it seems to be using that call to 
have strptime calculate the day of the week from mon/day/year, which 
it does not do on my machine.  All days of the week are returned as 
(Continue reading)

Etienne Grossmann | 4 Dec 2006 07:32

B'*B not symmetric by a few epses

To: bug <at> octave.org
Cc: etienne
Subject: B'*B not symmetric by a few epses
--------
Bug report for Octave 2.9.9 configured for i686-pc-linux-gnu

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

  Matrix built symmetrically ends up not symmetric.

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

octave:54> B = randn (3,10); C = B'*B; max (max (abs (C'-C)))
ans =  8.8818e-16

Fix:
---

  * If possible, replace this item with a description of how to
    fix the problem (if you don't have a fix for the problem, don't
    include this section, but please do submit your report anyway).

Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Linux anonimo 2.6.15 #1 Thu Apr 13 17:20:09 UTC 2006 i686 GNU/Linux
configure opts:   
Fortran compiler: g77
(Continue reading)

David Bateman | 4 Dec 2006 10:47

Re: B'*B not symmetric by a few epses

Etienne Grossmann wrote:
> To: bug <at> octave.org
> Cc: etienne
> Subject: B'*B not symmetric by a few epses
> --------
> Bug report for Octave 2.9.9 configured for i686-pc-linux-gnu
>
> Description:
> -----------
>
>   Matrix built symmetrically ends up not symmetric.
>
> Repeat-By:
> ---------
>
>
> octave:54> B = randn (3,10); C = B'*B; max (max (abs (C'-C)))
> ans =  8.8818e-16
>   
Where are you getting your blas from? I can't regenerate this problem,
either with the netlib blas or with ATLAS.. I'd say the issue is that
you're either using a blas that sacrifices precision for speed or you've
compiled your blas with something like "-ffast-math"..

D.

--

-- 
David Bateman                                David.Bateman <at> motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
(Continue reading)

Etienne Grossmann | 4 Dec 2006 16:55

Re: B'*B not symmetric by a few epses


  Hi David,

thanks for your quick answer; I use blas from Debian packages:

+++-==============-==============-================================================
ii  blas           1.1-14         Basic Linear Algebra Subroutines, shared library
ii  refblas3       1.2-8          Basic Linear Algebra Subroutines 3, shared libra
ii  refblas3-dev   1.2-8          Basic Linear Algebra Subroutines 3, static libra

  I will look into this.

  Thanks again,

  Etienne

On Mon, Dec 04, 2006 at 10:47:39AM +0100, David Bateman wrote:
# Etienne Grossmann wrote:
# > To: bug <at> octave.org
# > Cc: etienne
# > Subject: B'*B not symmetric by a few epses
# > --------
# > Bug report for Octave 2.9.9 configured for i686-pc-linux-gnu
# >
# > Description:
# > -----------
# >
# >   Matrix built symmetrically ends up not symmetric.
# >
# > Repeat-By:
(Continue reading)

Thomas Weber | 4 Dec 2006 23:08
Picon

Re: B'*B not symmetric by a few epses

Hi Etienne,

Am Montag, 4. Dezember 2006 16:55 schrieb Etienne Grossmann:
> thanks for your quick answer; I use blas from Debian packages:

Are you really sure that you don't have any ATLAS package installed? I can 
confirm this behaviour with 
	atlas3-base-sse
	atlas3-base-sse2
but not with the 'normal' base package (or no ATLAS at all).

	Thomas
Dmitri A. Sergatskov | 4 Dec 2006 23:10
Picon

Re: B'*B not symmetric by a few epses

I can reproduce the problem on x86_64 with ATLAS, but not with Intel's MKL.
With ATLAS the problem gets more obvious for larger matrix sizes:

[dima <at> XXXXX ~]$ octave
GNU Octave, version 2.9.9 (x86_64-redhat-linux-gnu).
Copyright (C) 2006 John W. Eaton.
....

octave:1> b=randn(1000); c = b*b' ; max(max(abs(c-c')))
ans =  5.6843e-14
octave:2> eps
ans =  2.2204e-16

[dima <at> XXXXXX ~]$ LD_PRELOAD=/opt/intel/mkl/8.0.2/lib/em64t/libmkl.so octave
GNU Octave, version 2.9.9 (x86_64-redhat-linux-gnu).
Copyright (C) 2006 John W. Eaton.
....

octave:1> b=randn(1000); c = b*b' ; max(max(abs(c-c')))
ans = 0

( atlas-3.6.0-11.fc6 )

Sincerely,

Dmitri.

On 12/4/06, Etienne Grossmann <etienne <at> tyzx.com> wrote:
>
>   Hi David,
(Continue reading)

David Bateman | 4 Dec 2006 23:16
Picon

Re: B'*B not symmetric by a few epses

Thomas Weber wrote:
> Hi Etienne,
> 
> Am Montag, 4. Dezember 2006 16:55 schrieb Etienne Grossmann:
>> thanks for your quick answer; I use blas from Debian packages:
> 
> Are you really sure that you don't have any ATLAS package installed? I can 
> confirm this behaviour with 
> 	atlas3-base-sse
> 	atlas3-base-sse2
> but not with the 'normal' base package (or no ATLAS at all).
> 
> 	Thomas

I've been linking to matlab's R2006b version of ATLAS recently so as to
remove one variable in my benchmarking against matlab. So yes I'm sure I
used ATLAS, but I used Matlab's version of ATLAS. Is this another
"-ffloat-store" issue?

D.

Gmane