1 Dec 2006 17:06
1 Dec 2006 19:36
pkg unload
Søren Hauberg <soren <at> hauberg.org>
2006-12-01 18:36:25 GMT
2006-12-01 18:36:25 GMT
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
_______________________________________________ Bug-octave mailing list Bug-octave <at> octave.org https://www.cae.wisc.edu/mailman/listinfo/bug-octave
1 Dec 2006 16:41
plot after hold on with no existing plot causes error
Justus Piater <piater <at> tool.montefiore.ulg.ac.be>
2006-12-01 15:41:11 GMT
2006-12-01 15:41:11 GMT
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)
1 Dec 2006 22:16
datestr/weekday/strptime, 2 bugs?
Dale Grover <dgrover <at> redcedar.com>
2006-12-01 21:16:15 GMT
2006-12-01 21:16:15 GMT
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)
4 Dec 2006 07:32
B'*B not symmetric by a few epses
Etienne Grossmann <etienne <at> tyzx.com>
2006-12-04 06:32:11 GMT
2006-12-04 06:32:11 GMT
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)
4 Dec 2006 10:47
Re: B'*B not symmetric by a few epses
David Bateman <David.Bateman <at> motorola.com>
2006-12-04 09:47:39 GMT
2006-12-04 09:47:39 GMT
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)
4 Dec 2006 16:55
Re: B'*B not symmetric by a few epses
Etienne Grossmann <etienne <at> tyzx.com>
2006-12-04 15:55:02 GMT
2006-12-04 15:55:02 GMT
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)
4 Dec 2006 23:08
Re: B'*B not symmetric by a few epses
Thomas Weber <thomas.weber.mail <at> gmail.com>
2006-12-04 22:08:27 GMT
2006-12-04 22:08:27 GMT
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
4 Dec 2006 23:10
Re: B'*B not symmetric by a few epses
Dmitri A. Sergatskov <dasergatskov <at> gmail.com>
2006-12-04 22:10:23 GMT
2006-12-04 22:10:23 GMT
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)
4 Dec 2006 23:16
Re: B'*B not symmetric by a few epses
David Bateman <adb014 <at> gmail.com>
2006-12-04 22:16:29 GMT
2006-12-04 22:16:29 GMT
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.
RSS Feed