From thomas.weber.mail at gmail.com Sun Nov 1 05:18:28 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Sun, 1 Nov 2009 12:18:28 +0100 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <19168.31395.338418.761998@segfault.lan> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> <19167.5201.437449.784544@segfault.lan> <1256221111.21402.15.camel@karaba.cepremap.org> <19168.31395.338418.761998@segfault.lan> Message-ID: <20091101111828.GA10415@atlan> On Thu, Oct 22, 2009 at 11:30:43AM -0400, John W. Eaton wrote: > On 22-Oct-2009, S,Aibastien Villemot wrote: > > | Le mercredi 21 octobre 2009 ,b` 10:01 -0400, John W. Eaton a ,bicrit : > | > OK, this seems better than forcing all of the directories in the load > | > path to be read again. So how about the following change? It seems > | > to work for me. > | > > | > http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0 > | > | Applied on Octave 3.2.3, this patch solves the problem, in particular > | with Dynare. > > The patch modifies the interfaces of some classes, so I'm not sure > whether it is OK for a future 3.2.x release. I'm trying to get a solution for this on 3.2, but I have a question: In src/load-path.cc, the method load_path::dir_info::update() has an if (is_relative) part, in which the cache of already visited directories is checked. Why is this check only done for relative directories? Thomas From jwe at octave.org Sun Nov 1 11:45:24 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 1 Nov 2009 12:45:24 -0500 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <20091101111828.GA10415@atlan> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> <19167.5201.437449.784544@segfault.lan> <1256221111.21402.15.camel@karaba.cepremap.org> <19168.31395.338418.761998@segfault.lan> <20091101111828.GA10415@atlan> Message-ID: <19181.51508.76917.457264@segfault.lan> On 1-Nov-2009, Thomas Weber wrote: | On Thu, Oct 22, 2009 at 11:30:43AM -0400, John W. Eaton wrote: | > On 22-Oct-2009, S,Aibastien Villemot wrote: | > | > | Le mercredi 21 octobre 2009 ,b` 10:01 -0400, John W. Eaton a ,bicrit : | > | > OK, this seems better than forcing all of the directories in the load | > | > path to be read again. So how about the following change? It seems | > | > to work for me. | > | > | > | > http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0 | > | | > | Applied on Octave 3.2.3, this patch solves the problem, in particular | > | with Dynare. | > | > The patch modifies the interfaces of some classes, so I'm not sure | > whether it is OK for a future 3.2.x release. | | I'm trying to get a solution for this on 3.2, but I have a question: | | | In src/load-path.cc, the method load_path::dir_info::update() | has an | if (is_relative) | part, in which the cache of already visited directories is checked. Why | is this check only done for relative directories? Lookups are done by whatever name is in the path. We don't want to have to read the directory contents for relative directories unless we haven't seen them before, so we also keep a list of directory information indexed by absolute names. But we only need to convert relative names to absolute and look them up in the abs_dir_cache. Maybe there is a better way to do this job, but I don't see it. I checked in the following change. It seems to work correctly for me. Does the code make sense now? http://hg.savannah.gnu.org/hgweb/octave/rev/7922a24f78c0 jwe From jwe at octave.org Sun Nov 1 13:01:58 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 1 Nov 2009 14:01:58 -0500 Subject: issorted incompatibility In-Reply-To: <6CA22BF6-CA00-41B0-9934-E2A940761292@gmail.com> References: <536AF70D-EE82-4AF2-B016-B69BF2861ECA@gmail.com> <4AEB3F82.6000200@gmx.net> <6CA22BF6-CA00-41B0-9934-E2A940761292@gmail.com> Message-ID: <19181.56102.568239.636104@segfault.lan> On 31-Oct-2009, Carlo de Falco wrote: | On 30 Oct 2009, at 20:33, Thomas Treichl wrote: | | > Carlo de Falco schrieb: | >> -------- | >> Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1 | > | > Can somebody on a Linux box please check this, too? | > Thanks, | > Thomas | | The behaviour is the same on Fedora 11 I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/7fc1c8c47b86 This change should provide compatibility while also allowing the user to specify the sort mode. jwe From highegg at gmail.com Mon Nov 2 03:52:38 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 10:52:38 +0100 Subject: no match operator on mx-inlines.cc In-Reply-To: <919227.17626.qm@web25502.mail.ukl.yahoo.com> References: <919227.17626.qm@web25502.mail.ukl.yahoo.com> Message-ID: <69d8d540911020152k130da5d3l959cc76145bc6caf@mail.gmail.com> On Fri, Oct 23, 2009 at 2:46 PM, Marco Atzeri wrote: > Hi, > on latest > > $ hg tip > changeset: ? 9757:95ad9c2a27e2 > tag: ? ? ? ? tip > user: ? ? ? ?Jaroslav Hajek > date: ? ? ? ?Fri Oct 23 10:35:59 2009 +0200 > summary: ? ? fix idx_vector construction checks > > building with gcc-4.3.4-1 on cygwin 1.7 > > g++ -c ? ? -I. -I../../octave/liboctave -I.. -I../liboctave -I../src -I../libcruft/misc -I../../octave -I../../octave/liboctave -I../../octave/src -I../../octave/libcruft/misc ?-DHAVE_CONFIG_H -mieee-fp ? -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 ?../../octave/liboctave/CNDArray.cc -o CNDArray.o > ../../octave/liboctave/mx-inlines.cc: In function ?void twosum_accum(T&, T&, const T&) [with T = std::complex]?: > ../../octave/liboctave/mx-inlines.cc:1263: ? instantiated from ?T mx_inline_xsum(const T*, octave_idx_type) [with T = std::complex]? > ../../octave/liboctave/mx-inlines.cc:1289: ? instantiated from ?void mx_inline_xsum(const T*, T*, octave_idx_type, octave_idx_type, octave_idx_type) [with T = std::complex]? > ../../octave/liboctave/CNDArray.cc:669: ? instantiated from here > > > ../../octave/liboctave/mx-inlines.cc:1252: error: no match for ?operator-? in ?s1 - s? > > > ../../octave/liboctave/CMatrix.h:439: note: candidates are: ComplexMatrix operator-(const ComplexMatrix&) > ../../octave/liboctave/CMatrix.h:439: note: ? ? ? ? ? ? ? ? ComplexMatrix operator-(const ComplexMatrix&, const Complex&) > ../../octave/liboctave/CMatrix.h:439: note: ? ? ? ? ? ? ? ? ComplexMatrix operator-(const Complex&, const ComplexMatrix&) > ../../octave/liboctave/CMatrix.h:439: note: ? ? ? ? ? ? ? ? ComplexMatrix operator-(const ComplexMatrix&, const ComplexMatrix&) > > Regards > Marco > > > Hi Marco, does this help? http://hg.savannah.gnu.org/hgweb/octave/rev/82fe4db20dec regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Mon Nov 2 03:54:11 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 10:54:11 +0100 Subject: base class assignment problem (was: Re: very strange bug) In-Reply-To: <19179.9343.346812.992458@segfault.lan> References: <19177.61130.614928.714592@segfault.lan> <744DB5EA-D1E1-4083-B17B-38DD7D084736@swissonline.ch> <19179.9343.346812.992458@segfault.lan> Message-ID: <69d8d540911020154u58c5a1d1xa459a6ab0b121cd@mail.gmail.com> On Fri, Oct 30, 2009 at 6:38 PM, John W. Eaton wrote: > On 30-Oct-2009, Lukas Reichlin wrote: > > | control-oo is here: > | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/ > | > | Download the package with: > | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo.tar.gz?view=tar > | > | Make sure that the "legacy" control package is not in your Octave > | path, because some functions have identical names (Matlab > | compatibility). > | > | I reduced the example as good as possible. If it is still too > | complicated to understand, you will have to wait until Robert posts > | his example next weekend. > > I'm attaching a minimal example. ?Unpack the oo-bug.tar.gz file, cd to > the oo-bug directory and run the bug.m script. > > The problem seems to be that the base class objects are not properly > copied when their fields are modified inside methods. ?I don't have a > solution so it would be great if someone else would like to take a > shot a fixing this problem. > > jwe > > How about this? http://hg.savannah.gnu.org/hgweb/octave/rev/0df32e0b2074 regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Mon Nov 2 03:58:27 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 10:58:27 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <26114361.post@talk.nabble.com> References: <26114361.post@talk.nabble.com> Message-ID: <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov wrote: > Hello, > > I encounter the following problem on Slackware Linux 13.0 with LAPACK 3.2.1 > and Octave 3.2.3. When I run octave it uses almost the whole CPU time on the > machine, without being able to finish. I've traced the problem to the > following: > > # gdb /usr/bin/octave > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-slackware-linux"... > (no debugging symbols found) > (gdb) r > Starting program: /usr/bin/octave > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > (no debugging symbols found) > [New Thread 0xb599e8e0 (LWP 3266)] > (no debugging symbols found) > ^C > Program received signal SIGINT, Interrupt. > [Switching to Thread 0xb599e8e0 (LWP 3266)] > 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 > (gdb) bt > #0 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 > #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 > #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 > #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 > #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so > #5 0xb69f158d in oct_mach_info::init_float_format () from > /usr/lib/octave-3.2.3/liboctave.so > #6 0xb69f1682 in oct_mach_info::oct_mach_info () from > /usr/lib/octave-3.2.3/liboctave.so > #7 0xb69f16ee in oct_mach_info::instance_ok () from > /usr/lib/octave-3.2.3/liboctave.so > #8 0xb69f17b7 in oct_mach_info::native_float_format () from > /usr/lib/octave-3.2.3/liboctave.so > #9 0xb69de464 in octave_ieee_init () from > /usr/lib/octave-3.2.3/liboctave.so > #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so > #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so > #12 0x080486da in main () > (gdb) c > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 > (gdb) bt > #0 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 > #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 > #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 > #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 > #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so > #5 0xb69f158d in oct_mach_info::init_float_format () from > /usr/lib/octave-3.2.3/liboctave.so > #6 0xb69f1682 in oct_mach_info::oct_mach_info () from > /usr/lib/octave-3.2.3/liboctave.so > #7 0xb69f16ee in oct_mach_info::instance_ok () from > /usr/lib/octave-3.2.3/liboctave.so > #8 0xb69f17b7 in oct_mach_info::native_float_format () from > /usr/lib/octave-3.2.3/liboctave.so > #9 0xb69de464 in octave_ieee_init () from > /usr/lib/octave-3.2.3/liboctave.so > #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so > #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so > #12 0x080486da in main () > > It seems, that Octave is stuck on an infinite loop in LAPACK, which in my > case is compiled as a separate shared library by gcc 4.3.3 with flags > "-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I have the > same problem with flags "-fimplicit-none -O2 -march=i486 -mtune=i686 -fPIC" > and also with "-O3" (I've though at one point it may be some optimization > issue). Then, I noticed that octave runs normally if compiled without > system's LAPACK (./configure --without-lapack). In this case LAPACK is > compiled for libcruft with just "-O -mieee-fp" flags. > > Any suggestions? Is the problem in Octave or it's in LAPACK? How could I > help for the resolving of this problem? > the SLAMCH and DLAMCH routines are sensitive to compiler optimizations. I use the settings (in make.inc from LAPACK tarball) NOOPT = -mieee-fp -ffloat-store -fPIC and it works well. I think that in future releases these routines will be replaced by querying Fortran 90 internals. hth -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From marco_atzeri at yahoo.it Mon Nov 2 04:07:17 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Mon, 2 Nov 2009 10:07:17 +0000 (GMT) Subject: no match operator on mx-inlines.cc In-Reply-To: <69d8d540911020152k130da5d3l959cc76145bc6caf@mail.gmail.com> Message-ID: <159395.73283.qm@web25502.mail.ukl.yahoo.com> --- Lun 2/11/09, Jaroslav Hajek ha scritto: > Da: Jaroslav Hajek > Oggetto: Re: no match operator on mx-inlines.cc > A: "Marco Atzeri" > Cc: bug at octave.org > Data: Luned? 2 novembre 2009, 10:52 > On Fri, Oct 23, 2009 at 2:46 PM, > Marco Atzeri > wrote: > > Hi, > > on latest > > > > $ hg tip > > changeset: ? 9757:95ad9c2a27e2 > > tag: ? ? ? ? tip > > user: ? ? ? ?Jaroslav Hajek > > date: ? ? ? ?Fri Oct 23 10:35:59 2009 +0200 > > summary: ? ? fix idx_vector construction checks > > > > building with gcc-4.3.4-1 on cygwin 1.7 > > > > g++ -c ? ? -I. -I../../octave/liboctave -I.. > -I../liboctave -I../src -I../libcruft/misc -I../../octave > -I../../octave/liboctave -I../../octave/src > -I../../octave/libcruft/misc ?-DHAVE_CONFIG_H -mieee-fp ? > -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 > ?../../octave/liboctave/CNDArray.cc -o CNDArray.o > > ../../octave/liboctave/mx-inlines.cc: In function > ?void twosum_accum(T&, T&, const T&) [with T = > std::complex]?: > > ../../octave/liboctave/mx-inlines.cc:1263: ? > instantiated from ?T mx_inline_xsum(const T*, > octave_idx_type) [with T = std::complex]? > > ../../octave/liboctave/mx-inlines.cc:1289: ? > instantiated from ?void mx_inline_xsum(const T*, T*, > octave_idx_type, octave_idx_type, octave_idx_type) [with T = > std::complex]? > > ../../octave/liboctave/CNDArray.cc:669: ? > instantiated from here > > > > > > ../../octave/liboctave/mx-inlines.cc:1252: error: no > match for ?operator-? in ?s1 - s? > > > > > > ../../octave/liboctave/CMatrix.h:439: note: candidates > are: ComplexMatrix operator-(const ComplexMatrix&) > > ../../octave/liboctave/CMatrix.h:439: note: ? ? ? > ? ? ? ? ? ComplexMatrix operator-(const > ComplexMatrix&, const Complex&) > > ../../octave/liboctave/CMatrix.h:439: note: ? ? ? > ? ? ? ? ? ComplexMatrix operator-(const Complex&, > const ComplexMatrix&) > > ../../octave/liboctave/CMatrix.h:439: note: ? ? ? > ? ? ? ? ? ComplexMatrix operator-(const > ComplexMatrix&, const ComplexMatrix&) > > > > Regards > > Marco > > > > > > > > Hi Marco, > does this help? > http://hg.savannah.gnu.org/hgweb/octave/rev/82fe4db20dec > > regards > > -- > RNDr. Jaroslav Hajek Hi Jaroslav, in reality the bug is already disappered, when I downloaded the repository from scratch again. It was probably a mis-configuration caused by me. Sorry for the noise Marco From highegg at gmail.com Mon Nov 2 04:10:48 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 11:10:48 +0100 Subject: no match operator on mx-inlines.cc In-Reply-To: <159395.73283.qm@web25502.mail.ukl.yahoo.com> References: <69d8d540911020152k130da5d3l959cc76145bc6caf@mail.gmail.com> <159395.73283.qm@web25502.mail.ukl.yahoo.com> Message-ID: <69d8d540911020210p2b2ff2bfqa09efefa2d9143d9@mail.gmail.com> On Mon, Nov 2, 2009 at 11:07 AM, Marco Atzeri wrote: > > > --- Lun 2/11/09, Jaroslav Hajek ha scritto: > >> Da: Jaroslav Hajek >> Oggetto: Re: no match operator on mx-inlines.cc >> A: "Marco Atzeri" >> Cc: bug at octave.org >> Data: Luned? 2 novembre 2009, 10:52 >> On Fri, Oct 23, 2009 at 2:46 PM, >> Marco Atzeri >> wrote: >> > Hi, >> > on latest >> > >> > $ hg tip >> > changeset: ? 9757:95ad9c2a27e2 >> > tag: ? ? ? ? tip >> > user: ? ? ? ?Jaroslav Hajek >> > date: ? ? ? ?Fri Oct 23 10:35:59 2009 +0200 >> > summary: ? ? fix idx_vector construction checks >> > >> > building with gcc-4.3.4-1 on cygwin 1.7 >> > >> > g++ -c ? ? -I. -I../../octave/liboctave -I.. >> -I../liboctave -I../src -I../libcruft/misc -I../../octave >> -I../../octave/liboctave -I../../octave/src >> -I../../octave/libcruft/misc ?-DHAVE_CONFIG_H -mieee-fp >> -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 >> ?../../octave/liboctave/CNDArray.cc -o CNDArray.o >> > ../../octave/liboctave/mx-inlines.cc: In function >> ?void twosum_accum(T&, T&, const T&) [with T = >> std::complex]?: >> > ../../octave/liboctave/mx-inlines.cc:1263: >> instantiated from ?T mx_inline_xsum(const T*, >> octave_idx_type) [with T = std::complex]? >> > ../../octave/liboctave/mx-inlines.cc:1289: >> instantiated from ?void mx_inline_xsum(const T*, T*, >> octave_idx_type, octave_idx_type, octave_idx_type) [with T = >> std::complex]? >> > ../../octave/liboctave/CNDArray.cc:669: >> instantiated from here >> > >> > >> > ../../octave/liboctave/mx-inlines.cc:1252: error: no >> match for ?operator-? in ?s1 - s? >> > >> > >> > ../../octave/liboctave/CMatrix.h:439: note: candidates >> are: ComplexMatrix operator-(const ComplexMatrix&) >> > ../../octave/liboctave/CMatrix.h:439: note: >> ? ? ? ? ? ComplexMatrix operator-(const >> ComplexMatrix&, const Complex&) >> > ../../octave/liboctave/CMatrix.h:439: note: >> ? ? ? ? ? ComplexMatrix operator-(const Complex&, >> const ComplexMatrix&) >> > ../../octave/liboctave/CMatrix.h:439: note: >> ? ? ? ? ? ComplexMatrix operator-(const >> ComplexMatrix&, const ComplexMatrix&) >> > >> > Regards >> > Marco >> > >> > >> > >> >> Hi Marco, >> does this help? >> http://hg.savannah.gnu.org/hgweb/octave/rev/82fe4db20dec >> >> regards >> >> -- >> RNDr. Jaroslav Hajek > > Hi Jaroslav, > in reality the bug is already disappered, > when I downloaded the repository from scratch again. > > It was probably a mis-configuration caused by me. > Sorry for the noise > > Marco > OK. Anyway I think the FLOAT_TRUNCATE was probably unnecessary, because when I tested the "extra" summation compiled with -mfpmath=387, I saw no degradation in accuracy, so I guess the guard bits don't spoil the algorithm (though I have no proof). -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From michael.goffioul at gmail.com Mon Nov 2 04:22:33 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Mon, 2 Nov 2009 10:22:33 +0000 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> Message-ID: <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> On Mon, Nov 2, 2009 at 9:58 AM, Jaroslav Hajek wrote: > the SLAMCH and DLAMCH routines are sensitive to compiler > optimizations. I use the settings (in make.inc from LAPACK tarball) > NOOPT ? ?= -mieee-fp -ffloat-store -fPIC > and it works well. I think that in future releases these routines will > be replaced by querying Fortran 90 internals. Will this still be F77 compatible or will it definitely require a F90 compiler? Michael. From highegg at gmail.com Mon Nov 2 04:24:39 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 11:24:39 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> Message-ID: <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> On Mon, Nov 2, 2009 at 11:22 AM, Michael Goffioul wrote: > On Mon, Nov 2, 2009 at 9:58 AM, Jaroslav Hajek wrote: >> the SLAMCH and DLAMCH routines are sensitive to compiler >> optimizations. I use the settings (in make.inc from LAPACK tarball) >> NOOPT ? ?= -mieee-fp -ffloat-store -fPIC >> and it works well. I think that in future releases these routines will >> be replaced by querying Fortran 90 internals. > > Will this still be F77 compatible or will it definitely require a F90 > compiler? > > Michael. > See http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From michael.goffioul at gmail.com Mon Nov 2 04:27:11 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Mon, 2 Nov 2009 10:27:11 +0000 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> Message-ID: <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek wrote: > See > http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure Too bad. I think I'll definitely be out of the game then. Michael. From highegg at gmail.com Mon Nov 2 04:40:52 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 11:40:52 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> Message-ID: <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> On Mon, Nov 2, 2009 at 11:27 AM, Michael Goffioul wrote: > On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek wrote: >> See >> http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure > > Too bad. I think I'll definitely be out of the game then. > > Michael. > I think Octave will long stay buildable with lapack 3.1 and earlier. IMHO we should do so unless F90 becomes also required for Octave. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Mon Nov 2 05:46:15 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 12:46:15 +0100 Subject: fsolve regression In-Reply-To: <19173.63103.72661.381052@segfault.lan> References: <19173.63103.72661.381052@segfault.lan> Message-ID: <69d8d540911020346g1c3a96d2rf8ec243299727c0b@mail.gmail.com> On Mon, Oct 26, 2009 at 8:20 PM, John W. Eaton wrote: > With Octave 3.0.5, fsolve computes a good solution for the following > problem. ?The norm of the function values is approximately 1e-5. ?With > 3.2.3 and Octave from the current hg archive, the norm of the function > values is about 3500. > > jwe > > Er, yes. Believe it or not, in a theoretical sense this is a superior behavior :) Here, fsolve reacts to the fact that the problem is very sensitive. Try adding zerr = z .* (1e-8 * (randn (length (z), 1))); norm (pellet (z + zerr)) to the script. By introducing a *relative* error of order 1e-8, the residual jumps up by more than 6 orders of magnitude (I get 5.9322e-06 -> 25.963). The new fsolve automatically scales the variables by jacobian column norms to get somewhat scaling-independent termination tests. More precisely, the tests are residual <= TolFun * n * norm (dg .* x) norm (dg .* step) <= TolX * norm (dg .* x) the rhs of the first test is an upper bound on the quantity jacobian * e, where e is an error of the order TolFun * x. Ergo, TolFun ~ eps should be close to the best precision achievable (but may be a few magnitueds off, because the upper bound is not accurate). By default, the tolerances are set to sqrt(eps), which seems a good compromise to me. You can achieve what you need by lowering TolFun and TolX as needed (for example, 1e-16 and 1e-12). This strategy has the advantage that, for instance, if you scale half of the variables by 100, you still get the same answer. The original minpack contained a similar strategy for scaling variables. However, it is switched off by default when called via hybrj1, which is done in octave 3.0.x, so 3.0.x's fsolve doesn't have this invariant property. Further, original MINPACK doesn't use a termination test on the residual at all, except for a test for an exact zero. So there doesn't seem to be anything corresponding to TolFun. Maybe there could be an option to disable the smart scaling and just force TolFun and TolX to be hard absolute tolerances? Or should that be the default? I think the current tests are mathematically superior, because they take into account the sensitivity of the problem at hand (which the user may not even be aware of), but maybe they are too hard to understand... -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From martin.ecarnot at free.fr Mon Nov 2 04:12:09 2009 From: martin.ecarnot at free.fr (Martin) Date: Mon, 02 Nov 2009 11:12:09 +0100 Subject: "Power" sign in text function (ver 3.2.2) Message-ID: <1257156729.4aeeb0798f904@imp.free.fr> Hello, Plotting 'r^2' text in a figure: h=text(1,1,'r^2'); Then the instruction: set(h,'fontsize',15); doesn't change text size. whereas: h=text(1,1,'r2'); set(h,'fontsize',15); can do it. Martin From jwe at octave.org Mon Nov 2 10:00:37 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 11:00:37 -0500 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> Message-ID: <19183.549.952812.823846@segfault.lan> On 2-Nov-2009, Jaroslav Hajek wrote: | On Mon, Nov 2, 2009 at 11:27 AM, Michael Goffioul | wrote: | > On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek wrote: | >> See | >> http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure | > | > Too bad. I think I'll definitely be out of the game then. | > | > Michael. | > | | I think Octave will long stay buildable with lapack 3.1 and earlier. | IMHO we should do so unless F90 becomes also required for Octave. Maybe it is time for me to ask again whether we should continue to distribute portions of the reference lapack and blas with Octave. I'd rather not distribute old versions of these libraries with Octave, so maybe now is the time to drop them and simply require that there are external blas and lapack libraries available when building Octave. Comments? jwe From jwe at octave.org Mon Nov 2 10:04:22 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 11:04:22 -0500 Subject: "Power" sign in text function (ver 3.2.2) In-Reply-To: <1257156729.4aeeb0798f904@imp.free.fr> References: <1257156729.4aeeb0798f904@imp.free.fr> Message-ID: <19183.774.360624.5443@segfault.lan> On 2-Nov-2009, Martin wrote: | Hello, | | Plotting 'r^2' text in a figure: | h=text(1,1,'r^2'); | Then the instruction: | set(h,'fontsize',15); | doesn't change text size. | | whereas: h=text(1,1,'r2'); set(h,'fontsize',15); | can do it. This seems to work properly for me with Octave 3.2.3 and gnuplot 4.2.6. What versions of Octave and gnuplot are you using? jwe From jwe at octave.org Mon Nov 2 10:43:23 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 11:43:23 -0500 Subject: base class assignment problem (was: Re: very strange bug) In-Reply-To: <69d8d540911020154u58c5a1d1xa459a6ab0b121cd@mail.gmail.com> References: <19177.61130.614928.714592@segfault.lan> <744DB5EA-D1E1-4083-B17B-38DD7D084736@swissonline.ch> <19179.9343.346812.992458@segfault.lan> <69d8d540911020154u58c5a1d1xa459a6ab0b121cd@mail.gmail.com> Message-ID: <19183.3115.253779.844615@segfault.lan> On 2-Nov-2009, Jaroslav Hajek wrote: | On Fri, Oct 30, 2009 at 6:38 PM, John W. Eaton wrote: | > On 30-Oct-2009, Lukas Reichlin wrote: | > | > | control-oo is here: | > | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/ | > | | > | Download the package with: | > | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo.tar.gz?view=tar | > | | > | Make sure that the "legacy" control package is not in your Octave | > | path, because some functions have identical names (Matlab | > | compatibility). | > | | > | I reduced the example as good as possible. If it is still too | > | complicated to understand, you will have to wait until Robert posts | > | his example next weekend. | > | > I'm attaching a minimal example. ?Unpack the oo-bug.tar.gz file, cd to | > the oo-bug directory and run the bug.m script. | > | > The problem seems to be that the base class objects are not properly | > copied when their fields are modified inside methods. ?I don't have a | > solution so it would be great if someone else would like to take a | > shot a fixing this problem. | > | > jwe | > | > | | How about this? | http://hg.savannah.gnu.org/hgweb/octave/rev/0df32e0b2074 This change fixes the problem for me. Thanks, jwe From highegg at gmail.com Mon Nov 2 11:11:12 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 2 Nov 2009 18:11:12 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <19183.549.952812.823846@segfault.lan> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> <19183.549.952812.823846@segfault.lan> Message-ID: <69d8d540911020911r6287f8b0r977776f582b5f41f@mail.gmail.com> On Mon, Nov 2, 2009 at 5:00 PM, John W. Eaton wrote: > On ?2-Nov-2009, Jaroslav Hajek wrote: > > | On Mon, Nov 2, 2009 at 11:27 AM, Michael Goffioul > | wrote: > | > On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek wrote: > | >> See > | >> http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure > | > > | > Too bad. I think I'll definitely be out of the game then. > | > > | > Michael. > | > > | > | I think Octave will long stay buildable with lapack 3.1 and earlier. > | IMHO we should do so unless F90 becomes also required for Octave. > > Maybe it is time for me to ask again whether we should continue to > distribute portions of the reference lapack and blas with Octave. > > I'd rather not distribute old versions of these libraries with Octave, > so maybe now is the time to drop them and simply require that there > are external blas and lapack libraries available when building Octave. > > Comments? > > jwe > I think the BLAS and LAPACK are a little special in the sense that they're (AFAIK) the only strong requirement for Octave. If any other dependency is missing, Octave will build and work, though with some crippled functionality. OTOH, BLAS and LAPACK are now almost universally available, so maybe nobody actually needs this feature. In that case, I think it's fine to drop these sources. It will also plausibly reduce Octave's code size. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From soren at hauberg.org Mon Nov 2 11:54:31 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Mon, 02 Nov 2009 18:54:31 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <69d8d540911020911r6287f8b0r977776f582b5f41f@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> <19183.549.952812.823846@segfault.lan> <69d8d540911020911r6287f8b0r977776f582b5f41f@mail.gmail.com> Message-ID: <1257184471.3934.1.camel@sh-t400> man, 02 11 2009 kl. 18:11 +0100, skrev Jaroslav Hajek: > I think the BLAS and LAPACK are a little special in the sense that > they're (AFAIK) the only strong requirement for Octave. If any other > dependency is missing, Octave will build and work, though with some > crippled functionality. > OTOH, BLAS and LAPACK are now almost universally available, so maybe > nobody actually needs this feature. In that case, I think it's fine to > drop these sources. It will also plausibly reduce Octave's code size. One advantage of dropping BLAS and LAPACK from the sources is that the user don't end up using these by accident instead of using the system libraries. S?ren From stefan at stefant.org Mon Nov 2 12:15:17 2009 From: stefan at stefant.org (Stefan Hepp) Date: Mon, 02 Nov 2009 19:15:17 +0100 Subject: semilogx fails without warning if x-axis starts with 0 Message-ID: <4AEF21B5.40800@stefant.org> Bug report for Octave 3.2.2 configured for i686-pc-mingw32 Description: ----------- If semilogx is called where the x coordinates start with 0, only an empty window appears without any further error message. In Octave 3.0/gnuplot 4.3.0 a warning was shown that the value 0 is ignored and the rest of the data was plotted. Repeat-By: --------- Execute: semilogx( [0 0.1 1 10], [1 2 3 4] ) Fix: --- Should work similar to Octave 3.0 behaviour or show some error why plotting the data failed. Configuration (please do not edit this section): ----------------------------------------------- uname output: Windows configure opts: Fortran compiler: mingw32-gfortran-4.3.0-dw2 FFLAGS: -O -mieee-fp FLIBS: -lgfortran CPPFLAGS: -march=i686 -mtune=generic -O2 INCFLAGS: -I. -I/octmgw32/octave/octave-3.2.2 -I. -I./liboctave -I./src -I./libcruft/misc -I/octmgw32/octave/octave-3.2.2 -I/octmgw32/octave/octave-3.2.2/liboctave -I/octmgw32/octave/octave-3.2.2/src -I/octmgw32/octave/octave-3.2.2/libcruft/misc C compiler: mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2 for MinGW) CFLAGS: -Wall CPICFLAG: C++ compiler: mingw32-g++-4.3.0-dw2, version4.3.0-dw2 CXXFLAGS: -D_DLL -Wall CXXPICFLAG: LD_CXX: mingw32-g++-4.3.0-dw2 LDFLAGS: -shared-libgcc -Wl,--exclude-libs=-lstdc++_s -Wl,--allow-multiple-definition LIBFLAGS: -L. RLD_FLAG: BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -liberty -lblas -lhdf5 -lz -lm -lgdi32 -lws2_32 -luser32 -lkernel32 LEXLIB: LIBGLOB: -lglob SED: /usr/bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=';' -DSEPCHAR_STR=";" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -Duid_t=int -Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1 -DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_MKSTEMPS=1 -DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 -D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_COPYSIGN=1 -DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=1 -DHAVE__COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1 -DRETSIGTYPE_IS_VOID=1 User-preferences (please do not edit this section): EDITOR = D:\Program Files\Science\Octave 3.2\tools\notepad++\notepad++.exe EXEC_PATH = D:\Program Files\Science\Octave 3.2\MINGW32\bin;D:\Program Files\Science\Octave 3.2\MSYS\bin;D:\Program Files\Science\Octave 3.2\libexec\octave\3.2.2\site\exec\i686-pc-mingw32;D:\Program Files\Science\Octave 3.2\libexec\octave\api-v37\site\exec\i686-pc-mingw32;D:\Program Files\Science\Octave 3.2\libexec\octave\site\exec\i686-pc-mingw32;D:\Program Files\Science\Octave 3.2\libexec\octave\3.2.2\exec\i686-pc-mingw32;D:\Program Files\Science\Octave 3.2\bin;D:\PROGRA~1\Tools\GTK\bin;c:\program files\pc connectivity solution\;d:\development\java\javafx-sdk\bin;d:\development\java\javafx-sdk\emulator\bin;d:\program files\latex\miktex\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;d:\program files\online\putty;d:\development\tools\tortoisesvn\bin;c:\program files\microsoft sql server\100\tools\binn\;c:\program files\microsoft sql server\100\dts\binn\;d:\development\hardware\altera\quartus\bin;D:\Program Files\Science\Matlab\bin\win32;D:\Development\Cuda\Toolkit\bin;D:\Development\Nvidia\Cuda\Toolkit\bin;D:\Development\Nvidia\Cg\bin;D:\Development\Nvidia\gDebugger\gDEBugger\;d:\development\python\python26\scripts;d:\"program files"\science\octave\bin;d:\development\IDE\Visual Studio\VC\bin;D:\Development\Hardware\Altera\modelsim_ase\win32aloem;D:\Development\Studierstube\artoolkitplus\bin\win32;D:\Development\Studierstube\stb4\bin\win32;D:\Development\Studierstube\stb4Applications\bin\win32;D:\Development\Studierstube\stb4Components\bin\win32;D:\Development\Studierstube\openvideo\bin\win32;D:\Development\Studierstube\Coin\bin;D:\Development\Studierstube\ACE_wrappers\lib;D:\Development\Studierstube\dsvl-0.0.8d\bin;D:\Development\Studierstube\opentracker\bin\win32;D:\Development\Studierstube\TinyXMLMod\bin\win32;%FMODROOT%\api;D:\Development\Studierstube\physxl\bin\win32;%AGEIAROOT%\bin\win32 IMAGE_PATH = .;D:\Program Files\Science\Octave 3.2\share\octave\3.2.2\imagelib PAGER = D:\Program Files\Science\Octave 3.2\bin\less.exe PS1 = \s:\#:\w > PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = D:\Program Files\Science\Octave 3.2\bin\gnuplot.exe # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = C:\Documents and Settings\Stefan\.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = D:\Program Files\Science\Octave 3.2\share\info\octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From soren at hauberg.org Mon Nov 2 12:31:41 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Mon, 02 Nov 2009 19:31:41 +0100 Subject: semilogx fails without warning if x-axis starts with 0 In-Reply-To: <4AEF21B5.40800@stefant.org> References: <4AEF21B5.40800@stefant.org> Message-ID: <1257186701.3934.32.camel@sh-t400> man, 02 11 2009 kl. 19:15 +0100, skrev Stefan Hepp: > If semilogx is called where the x coordinates start with 0, only an empty window appears > without any further error message. In Octave 3.0/gnuplot 4.3.0 a warning was shown that the > value 0 is ignored and the rest of the data was plotted. I get the expected (correct) behaviour in the development version on Linux with gnuplot 4.3 (patchlevel 0). S?ren From lindnerben at gmx.net Mon Nov 2 13:52:39 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Mon, 02 Nov 2009 20:52:39 +0100 Subject: case-insensitive file search [was: package installation Octave] In-Reply-To: <20091102125012.161640@gmx.net> References: <20091102125012.161640@gmx.net> Message-ID: <4AEF3887.1070000@gmx.net> Benjamin Lindner wrote: >> On Sat, Oct 31, 2009 at 9:01 PM, Benjamin Lindner >> wrote: >>> Erik Brezet wrote: >>>> On Thu, Oct 15, 2009 at 5:40 PM, Benjamin Lindner >>>> wrote: >>>>> Erik Brezet wrote: >>>>>> Hi, >>>>>> I can't seem to get any packages (tar.gz) installed on Octave in >>>>>> windows. Packages like: RODBC, xlsreadwrite, ga .. >>>>>> Octave gives: error COPYING file missing or other errors. >>>>>> I've got the mingw32 installer for windows. >>>>>> >>>>>> Help? >>>>> Well, not all available forge packages can be successfully built for >> the >>>>> mingw32 build. >>>>> >>>>> Please provide some more information. Which version of octave do you >> have >>>>> installed? Which version of the package do you try to install? Can you >>>>> post >>>>> the commands you executed and octave's error response? >>>>> >>>>> With the 3.2.2 mingw32 installer I can for example install ga-0.9.7 >>>>> without >>>>> errors. >>>>> >>>>> benjamin >>>>> >>>>> >>>>> >>>> Hi Benjamin and Anandaram, >>>> Thanks for your responses. >>>> I've got Octave 3.2.2. I still don't get the packages to work. >>>> For example, I want to install SPCtools: >>>> >>>> ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/tools/spctools >>>> >>>> and I unzip the files in the package directory >>>> "octave\share\octave\packeges\SPCtools" >>>> ,but when I run Octave, it doesn't recognize any of the commands.. >>>> >>> Well, these tools are not an octave-forge-package, so they don't follow >>> octave's packaging rules, and they must not be installed in octave's >>> directory tree (well, it's not forbidden, but I'll encourage you not to >> do >>> so). >>> >>> If you want to use tools like the above, then you must unzip them >> somewhere >>> on your local machine, e.g. into a subdirectory in your home directory, >> and >>> then tell octave where to find it by adding all paths with scripts to >>> octave's searchpath using the command addpath(). >>> If you want to add a directory and all its aubdirectories, you might >> also >>> take a look at genpath(). >>> >>> hope this helps >>> >>> benjamin >>> >> Hi Benjamin, >> I used addpath and genpath to add all the directories of the SPC package. >> When I type "path" they appear in the list, so that seems ok. >> But how do I use the added .m functions now? When I type "help one of >> the functions" Octave >> doesn't recognize the function of the added directories.. >> > > Please keep the discussion on the mailing-list. > > There seems to be a problem with case-sensitive file matching > > C:\temp> type foo.m > function y = foo(x) > > C:\temp> type BAZ.M > function y = baz(x) > > octave:> dir > . .. BAZ.M foo.m > octave:> which foo > `foo' is a function from the file c:\temp\foo.m > octave:> which BAZ > octave:> glob("*.m") > ans = > { > [1,1] = foo.m > } > octave:> glob("*.M") > ans = > { > [1,1] = BAZ.M > } > > ren BAZ.M BAZ.m > > octave:> dir > . .. BAZ.m foo.m > octave:> which baz > octave:> which BAZ > warning: function name `baz' does not agree with function file name `c:\temp\BAZ.m' > `BAZ' is a function from the file c:\temp\BAZ.m > > Octave obviously treats file names case-sensitive which makes little sense on case-insensitive file systems. > Hmm, this needs some investigation. > I'm moving this to the bug list, as I think there is a problem in octave. I modified glob to treat file matches case-insensitive, but octave still does not find functions with a captial 'M' as extension. octave> dir("*.m") baz.M foo.m octave> glob("*.m") ans = { [1,1] = baz.M [2,1] = foo.m } octave> which baz octave> file_in_loadpath ("baz.M") ans = d:\temp\glob\baz.M octave> file_in_loadpath ("baz.m") ans = [](0x0) Which method does octave use when it searches it's loadpath? It's obviously not glob/fnmatch. benjamin From kai.habel at gmx.de Mon Nov 2 14:22:00 2009 From: kai.habel at gmx.de (Kai Habel) Date: Mon, 02 Nov 2009 21:22:00 +0100 Subject: octave crash with repetitive 'clear functions' In-Reply-To: <19177.60543.878467.239711@segfault.lan> References: <4AE04C33.1050001@gmx.de> <20091026200954.229490@gmx.net> <20091026232118.GA10907@atlan> <20091027094933.16510@gmx.net> <19177.60543.878467.239711@segfault.lan> Message-ID: <4AEF3F68.9000902@gmx.de> John W. Eaton schrieb: > On 27-Oct-2009, Kai Habel wrote: > > | -------- Original-Nachricht -------- > | > Datum: Tue, 27 Oct 2009 00:21:18 +0100 > | > Von: Thomas Weber > | > An: Kai Habel > | > CC: Octave Bugs > | > Betreff: Re: octave crash with repetitive \'clear functions\' > | > | > Hi Kai, > | > > | > On Mon, Oct 26, 2009 at 09:09:54PM +0100, Kai Habel wrote: > | > > > | > > -------- Original-Nachricht -------- > | > > > Datum: Thu, 22 Oct 2009 14:12:35 +0200 > | > > > Von: Kai Habel > | > > > An: bug-octave at octave.org > | > > > Betreff: octave crash with repetitive \'clear functions\' > | > > > | > > > While playing with optiplux (optilux.sf.net) again, which is written > | > for > | > > > octave and matlab, I ran into problems. > | > > > > | > > > I could reduce the problem to the following example. When running > | > > > myscript.m, which calls myfun.m octave dies with a segmentation fault > | > at > | > > > the second 'clear functions'. > | > > > > | > > > kai at LxLap:~/hg-octave/octave> cat myscript.m > | > > > clear functions > | > > > myfun > | > > > clear functions > | > > > kai at LxLap:~/hg-octave/octave> cat myfun.m > | > > > function myfun > | > > > function f1 > | > > > function f2 > | > > > kai at LxLap:~/hg-octave/octave> ./run-octave --silent > | > > > adding ssprop to path > | > > > adding optilux to path > | > > > octave:1> myscript > | > > > panic: Segmentation fault -- stopping myself... > | > > > attempting to save variables to `octave-core'... > | > > > save to `octave-core' complete > | > > > Speicherzugriffsfehler > | > > > kai at LxLap:~/hg-octave/octave> > | > > > > | > > > I have observed this with a recent tip (yesterday), but not with the > | > > > mingw octave3.2.2 binary. Can someone confirm this crash? > | > > > > | > > > | > > Nobody? I had the chance to test it on a second Opensuse system and > | > > still see the crash, so I suspect the problem is with octave and not > | > > with my local installation(s). > | > > | > I just tested this on Debian (amd64) and it crashes here as well. Sorry, > | > no more info. I need to get some sleep now. > | > > | > Thomas > | > | Hello Thomas, > | > | thanks for your confirmation. Unfortunatly this beyond my knowledge of octave, so I have to leave the debugging to a core developer. > > I checked in the following change. > > http://hg.savannah.gnu.org/hgweb/octave/rev/5f8971be8e12 > > Thanks, > > jwe > Thanks for fixing. It solves the reported and the original problem on my systems. Kai From jwe at octave.org Mon Nov 2 15:52:11 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 16:52:11 -0500 Subject: case-insensitive file search [was: package installation Octave] In-Reply-To: <4AEF3887.1070000@gmx.net> References: <20091102125012.161640@gmx.net> <4AEF3887.1070000@gmx.net> Message-ID: <19183.21643.994238.343198@segfault.lan> On 2-Nov-2009, Benjamin Lindner wrote: | I'm moving this to the bug list, as I think there is a problem in | octave. I modified glob to treat file matches case-insensitive, but | octave still does not find functions with a captial 'M' as extension. | | octave> dir("*.m") | baz.M foo.m | octave> glob("*.m") | ans = | { | [1,1] = baz.M | [2,1] = foo.m | } | octave> which baz | octave> file_in_loadpath ("baz.M") | ans = d:\temp\glob\baz.M | octave> file_in_loadpath ("baz.m") | ans = [](0x0) | | Which method does octave use when it searches it's loadpath? It's | obviously not glob/fnmatch. It reads the list of files from the directory with readdir. The code that searches the load path is in src/load-path.{h,cc}. But before we make Octave ignore case, I think it would maybe just be simpler to rename the files. jwe From jwe at octave.org Mon Nov 2 20:37:01 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 21:37:01 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <4AEB45DC.7060608@stefant.org> References: <4AEB45DC.7060608@stefant.org> Message-ID: <19183.38733.184096.833426@segfault.lan> On 30-Oct-2009, Stefan Hepp wrote: | Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu | | Description: | ----------- | | If 'plot' is used on a linux server without X (p.e. using ssh), | octave sets terminal 'aqua' to gnuplot, which is not available | (in octave 3.0), and not all diehard console users know/care about | setting GNUTERM (like me :) ). | | Similary, in Octave 3.2 in gnuplot_drawnow.m the Gnuplot terminal | should only be set to X11 if DISPLAY is set (else, set to 'unknown' | again or something). | | It would be nice to have an option/command/.. to prevent plot,etc.. | from displaying the plot, but only store it to a file using 'print'. | (I don't know if there is already such an option, but I could not find one). | | Repeat-By: | --------- | | Run Octave 3.0/3.2 on a linux terminal, unset DISPLAY and GNUTERM | environment variables, execute the following code: | | plot( [1 2 3 2 3] ); | print('test.eps','-deps'); | | | Fix: | --- | | Here is a patch for drawnow.m for octave 3.0 which checks for OS X | first, which works for me: | | diff -ru m.orig/plot/drawnow.m m/plot/drawnow.m | --- m.orig/plot/drawnow.m 2009-10-30 20:00:21.000000000 +0100 | +++ m/plot/drawnow.m 2009-10-30 19:59:45.000000000 +0100 | @@ -160,13 +160,10 @@ | term = "x11"; | elseif (! isunix ()) | term = "windows"; | - else | - ## This should really be checking for os x before setting | - ## the terminal type to aqua, but nobody will notice because | - ## every other unix will be using x11 and windows will be | - ## using windows. Those diehards still running octave from | - ## a linux console know how to set the GNUTERM variable. | + elseif ( ismac () ) | term = "aqua"; | + else | + term = "unknown"; | endif | endif | | @@ -195,10 +192,9 @@ | | elseif (enhanced) | fprintf (plot_stream, "set terminal %s %s\n", term, enh_str); | + elseif ( isempty (getenv ("GNUTERM")) ) | + fprintf (plot_stream, "set terminal %s\n", term); | endif | - ## gnuplot will pick up the GNUTERM environment variable itself | - ## so no need to set the terminal type if not also setting the | - ## figure title or enhanced mode. | | endif | | | For Octave 3.2 the following patch could work, but I have *not* tested it: | | diff -ru scripts.orig/plot/gnuplot_drawnow.m scripts/plot/gnuplot_drawnow.m | --- scripts.orig/plot/gnuplot_drawnow.m 2009-10-30 20:41:19.000000000 +0100 | +++ scripts/plot/gnuplot_drawnow.m 2009-10-30 20:20:52.000000000 +0100 | @@ -326,8 +326,10 @@ | term = "aqua"; | elseif (! isunix ()) | term = "windows"; | - else | + elseif (! isempty( getenv ("DISPLAY")) ) | term = "x11"; | + else | + term = "unknown"; | endif | endif | endfunction 3.0.x is no longer maintained. I checked in your patch for 3.2 to the main development branch: http://hg.savannah.gnu.org/hgweb/octave/rev/4634a0e9ea1b Jaroslav, I don't think this is a regression or a particularly serious bug, but it should be safe to apply the patch to the 3.2.x release branch. Thanks, jwe From jwe at octave.org Mon Nov 2 20:39:43 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 21:39:43 -0500 Subject: Fixing HDF-1.8 API for octave-3.2.x In-Reply-To: <26097695.post@talk.nabble.com> References: <4A905142.8020308@dbateman.org> <19093.59289.539983.77168@segfault.lan> <26097695.post@talk.nabble.com> Message-ID: <19183.38895.838990.990159@segfault.lan> On 28-Oct-2009, dbateman wrote: | Kacper Kowalik wrote: | > | > Attached patches do the following: | > | > 1) octave-3.2.2-drop-ancient-hdf5.diff - removes now obsolete code | > under 'HAVE_H5GGET_NUM_OBJS' | > and 'have_h5giterate_bug' since hdf5>=1.6 includes H5GGET_NUM_OBJS and | > is free of the h5giterate_bug. | > As results it drops compatibility with hdf5-1.2 and hdf5-1.4 | > | > 2) octave-3.2.2-simplify_and_prep_for_hdf5-18.diff - small changes in | > configure.in and config.h.in, | > now if HDF5>=1.8 is present on the system, new flag (HAVE_HDF5_18) is | > defined. | > Unless HDF5-1.8 library was compiled with --with-default-api-version=v16 | > | > 3) octave-3.2.2-add-hdf5_18.diff - brings HDF5-1.8 API octave while | > retaining compatibility with HDF5-1.6 | > | > Best regards, | > Kacper Kowalik | > | > | | Were these patches ever applied? It would be nice to have them in the | development tree to allow the use of HDF 1.8 natively.. No, I don't think they were applied. Do they look OK to you? If so, I have no objection to applying them, though it would be slightly easier to do that if they were hg changesets relative to the current sources instead of simple context diffs relative to Octave 3.2.2. jwe From individ at acc.umu.se Tue Nov 3 02:02:29 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 03 Nov 2009 09:02:29 +0100 Subject: Call user-defined subsref/subsasgn with 1xN structs instead of Nx1 Message-ID: <4AEFE395.809@acc.umu.se> Hello readers of bug-list, I've recently run into a problem where a user-defined subsref is called with Nx1 index structs. This makes it difficult to use for-loops (without transposing). The natural size of structs are row vectors (1xN). I think subsref should be called with 1xN structs, which is what Matlab do too. (The Matlab documentation has very misleading examples where they say the structs are 3-by-1, but nevermind that) Attaching a changeset with parent 9747:7bda650b691a. David -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix_idxargs.changeset Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091103/1df06644/attachment.ksh From individ at acc.umu.se Tue Nov 3 02:23:19 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 03 Nov 2009 09:23:19 +0100 Subject: Allow and ignore extra outargs from user-defined size methods Message-ID: <4AEFE877.1080304@acc.umu.se> Hi bug-list, Making a user-defined size method is tricky business. In order to write it correctly, you have to use varargout, test conditions carefully and so forth. It becomes even trickier when Octave is really picky about this, and won't allow you to cheat the least bit (like skipping varargout). I made Octave ignore extra outargs and also fixed a simple printf error too. Attached changeset, parent: 9747:7bda650b691a. David -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix_size.changeset Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091103/2e0759a2/attachment.ksh From individ at acc.umu.se Tue Nov 3 03:58:45 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 03 Nov 2009 10:58:45 +0100 Subject: Add property FormatSpacing to root Message-ID: <4AEFFED5.2070207@acc.umu.se> Hi bug-list, In Matlab's "display" function help text, there is an example how to implement a user-defined display method. The root property FormatSpacing is used in this example. Octave doesn't have such a property. I attached a changeset that adds a formatspacing root property. David -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: addformatspacing.changeset Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091103/3f06023e/attachment.ksh From matej.tyc at gmail.com Tue Nov 3 04:33:25 2009 From: matej.tyc at gmail.com (=?UTF-8?B?TWF0xJtqICBUw73EjQ==?=) Date: Tue, 3 Nov 2009 11:33:25 +0100 Subject: imread: Problems with higher color depth images Message-ID: <670992c60911030233t18c70fddpda8f5c5eb9f8809b@mail.gmail.com> Bug report for Octave 3.2.3 configured for x86_64-unknown-linux-gnu Description: ----------- I have some higher color depth images (let's say 16-bit grayscale TIFFs). When I load them using ImageJ, they look fine and their color depth is reported correctly, too. However, when I load them into Octave, their color depth is not detected well and I get the usual wrong result - almost black image. I can provide an image file or stuff like that, but maybe the octave configuration is the culprit, so I am not enclosing anything now. Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux chmelik-duo-1 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 10:03:24 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux configure opts: '--prefix=/usr' '--libexecdir=/usr/lib' '--without-hdf5' '--without-umfpack' '--enable-shared' '--disable-static' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe' 'LDFLAGS=-Wl,--hash-style=gnu -Wl,--as-needed' 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe' Fortran compiler: gfortran FFLAGS: -O FLIBS: -L/usr/X11R6/lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../.. -lz -lgfortranbegin -lgfortran -lm -lfreetype -lGL -lGLU CPPFLAGS: -I/usr/include/freetype2 INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.4.1 (GCC) CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe CPICFLAG: -fPIC C++ compiler: g++, version 4.4.1 CXXFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -I/usr/include/freetype2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: -Wl,--hash-style=gnu -Wl,--as-needed LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lz -lm -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_FFTW3=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = vim EXEC_PATH = /usr/lib/octave/3.2.3/site/exec/x86_64-unknown-linux-gnu:/usr/lib/octave/api-v37/site/exec/x86_64-unknown-linux-gnu:/usr/lib/octave/site/exec/x86_64-unknown-linux-gnu:/usr/lib/octave/3.2.3/exec/x86_64-unknown-linux-gnu:/usr/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/matej/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From sergstesh at yahoo.com Tue Nov 3 04:51:25 2009 From: sergstesh at yahoo.com (Sergei Steshenko) Date: Tue, 3 Nov 2009 02:51:25 -0800 (PST) Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> Message-ID: <718275.58909.qm@web112111.mail.gq1.yahoo.com> --- On Mon, 11/2/09, Michael Goffioul wrote: > From: Michael Goffioul > Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so > To: "Jaroslav Hajek" > Cc: "Georgi D. Sotirov" , bug-octave at octave.org > Date: Monday, November 2, 2009, 2:27 AM > On Mon, Nov 2, 2009 at 10:24 AM, > Jaroslav Hajek > wrote: > > See > > http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure > > Too bad. I think I'll definitely be out of the game then. > > Michael. > _______________________________________________ Isn't 'gfortran' coming with latest 'gcc' good enough ? My understanding is that 'gfortran' is f95, i.e. even later than f90. Thanks, Sergei. From highegg at gmail.com Tue Nov 3 04:56:41 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 3 Nov 2009 11:56:41 +0100 Subject: Call user-defined subsref/subsasgn with 1xN structs instead of Nx1 In-Reply-To: <4AEFE395.809@acc.umu.se> References: <4AEFE395.809@acc.umu.se> Message-ID: <69d8d540911030256w28c27889v9d4f5d74b7d00903@mail.gmail.com> On Tue, Nov 3, 2009 at 9:02 AM, David Grundberg wrote: > Hello readers of bug-list, > > I've recently run into a problem where a user-defined subsref is called with > Nx1 index structs. This makes it difficult to use for-loops (without > transposing). > > The natural size of structs are row vectors (1xN). I think subsref should be > called with 1xN structs, which is what Matlab do too. (The Matlab > documentation has very misleading examples where they say the structs are > 3-by-1, but nevermind that) > > Attaching a changeset with parent 9747:7bda650b691a. > I applied it, changing also substruct accordingly: http://hg.savannah.gnu.org/hgweb/octave/rev/fbf15a0f30f0 thanks -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Tue Nov 3 04:57:03 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 3 Nov 2009 11:57:03 +0100 Subject: Allow and ignore extra outargs from user-defined size methods In-Reply-To: <4AEFE877.1080304@acc.umu.se> References: <4AEFE877.1080304@acc.umu.se> Message-ID: <69d8d540911030257nf339837se2812093f714fefd@mail.gmail.com> On Tue, Nov 3, 2009 at 9:23 AM, David Grundberg wrote: > Hi bug-list, > > Making a user-defined size method is tricky business. In order to write it > correctly, you have to use varargout, test conditions carefully and so > forth. It becomes even trickier when Octave is really picky about this, and > won't allow you to cheat the least bit (like skipping varargout). > > I made Octave ignore extra outargs and also fixed a simple printf error too. > Attached changeset, parent: 9747:7bda650b691a. > > David > > > # HG changeset patch > # User David Grundberg > # Date 1257234560 -3600 > # Node ID 4c116b053fedda6b24c004ce6cc541415d26eb3b > # Parent ?7bda650b691a21434cddb2452a0fbc77c558a9ca > Allow and ignore extra outargs from user-defined size methods > > diff -r 7bda650b691a -r 4c116b053fed src/ChangeLog > --- a/src/ChangeLog ? ? Tue Oct 20 15:45:09 2009 +0200 > +++ b/src/ChangeLog ? ? Tue Nov 03 08:49:20 2009 +0100 > @@ -1,3 +1,8 @@ > +2009-11-03 ?David Grundberg ? > + > + ? ? ? * ov-class.cc (octave_class::size): Allow and ignore extra outargs > + ? ? ? from user-defined size methods. > + > ?2009-10-20 ?Jaroslav Hajek ? > > ? ? ? ?* ov-base.h (builtin_type_t): Declare also btyp_num_types. > diff -r 7bda650b691a -r 4c116b053fed src/ov-class.cc > --- a/src/ov-class.cc ? Tue Oct 20 15:45:09 2009 +0200 > +++ b/src/ov-class.cc ? Tue Nov 03 08:49:20 2009 +0100 > @@ -306,10 +306,10 @@ > ? ? ? octave_value_list args (1, octave_value (this)); > > ? ? ? octave_value_list lv = feval (meth.function_value (), args, 1); > - ? ? ?if (lv.length () == 1 && lv(0).is_matrix_type () && lv(0).dims > ().is_vector ()) > + ? ? ?if (lv.length () > 0 && lv(0).is_matrix_type () && lv(0).dims > ().is_vector ()) > ? ? ? ? retval = lv(0).matrix_value (); > ? ? ? else > - ? ? ? ?error ("@%s/size: invalid return value"); > + ? ? ? ?error ("@%s/size: invalid return value", class_name ().c_str ()); > ? ? } > > ? return retval; > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > applied, thanks. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Tue Nov 3 05:01:59 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 3 Nov 2009 12:01:59 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <718275.58909.qm@web112111.mail.gq1.yahoo.com> References: <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <718275.58909.qm@web112111.mail.gq1.yahoo.com> Message-ID: <69d8d540911030301p3e6a8302td3c52bb73ae261d8@mail.gmail.com> On Tue, Nov 3, 2009 at 11:51 AM, Sergei Steshenko wrote: > > > --- On Mon, 11/2/09, Michael Goffioul wrote: > >> From: Michael Goffioul >> Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so >> To: "Jaroslav Hajek" >> Cc: "Georgi D. Sotirov" , bug-octave at octave.org >> Date: Monday, November 2, 2009, 2:27 AM >> On Mon, Nov 2, 2009 at 10:24 AM, >> Jaroslav Hajek >> wrote: >> > See >> > http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure >> >> Too bad. I think I'll definitely be out of the game then. >> >> Michael. >> _______________________________________________ > > > Isn't 'gfortran' coming with latest 'gcc' good enough ? My understanding is > that 'gfortran' is f95, i.e. even later than f90. > > Thanks, > ?Sergei. > gfortran is almost complete f2003 plus a few f2008 features. Yes, it's more than sufficient to compile LAPACK. But IIRC, Michael's problem was elsewhere, something about the runtime libraries (MSVC vs. GCC). -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From tmacchant at yahoo.co.jp Tue Nov 3 05:37:41 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Tue, 3 Nov 2009 20:37:41 +0900 (JST) Subject: imread: Problems with higher color depth images In-Reply-To: <670992c60911030233t18c70fddpda8f5c5eb9f8809b@mail.gmail.com> Message-ID: <20091103113745.53604.qmail@web3813.mail.bbt.yahoo.co.jp> Hello The function imread relies on GraphicsMagick libraries. Your problem perhaps depends on which quantum depth is used on building the GraphicsMagick libraries which are linked to your Octave. Octave/Mingw32 is configured 16bit depth GraphicksMagick libraries. You should ask the octave package maintainer on your platform. I think it is not bug of octave. Regards Tatsuro --- Mat???j T?????? wrote: > Bug report for Octave 3.2.3 configured for x86_64-unknown-linux-gnu > > Description: > ----------- > > I have some higher color depth images (let's say 16-bit grayscale TIFFs). > When I load them using ImageJ, they look fine and their color depth is > reported correctly, too. > However, when I load them into Octave, their color depth is not > detected well and I get the usual wrong result - almost black image. > > I can provide an image file or stuff like that, but maybe the octave > configuration is the culprit, so I am not enclosing anything now. > > Configuration (please do not edit this section): > ----------------------------------------------- > > uname output: Linux chmelik-duo-1 2.6.31-ARCH #1 SMP PREEMPT Fri > Oct 23 10:03:24 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ > 3.00GHz GenuineIntel GNU/Linux > configure opts: '--prefix=/usr' '--libexecdir=/usr/lib' > '--without-hdf5' '--without-umfpack' '--enable-shared' > '--disable-static' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe' > 'LDFLAGS=-Wl,--hash-style=gnu -Wl,--as-needed' 'CXXFLAGS=-march=x86-64 > -mtune=generic -O2 -pipe' > Fortran compiler: gfortran > FFLAGS: -O > FLIBS: -L/usr/X11R6/lib > -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1 > -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../../../lib > -L/lib/../lib -L/usr/lib/../lib > -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/../../.. -lz > -lgfortranbegin -lgfortran -lm -lfreetype -lGL -lGLU > CPPFLAGS: -I/usr/include/freetype2 > INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc > C compiler: gcc, version 4.4.1 (GCC) > CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe > CPICFLAG: -fPIC > C++ compiler: g++, version 4.4.1 > CXXFLAGS: -march=x86-64 -mtune=generic -O2 -pipe > -I/usr/include/freetype2 > CXXPICFLAG: -fPIC > LD_CXX: g++ > LDFLAGS: -Wl,--hash-style=gnu -Wl,--as-needed > LIBFLAGS: -L. > RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 > BLAS_LIBS: -llapack -lblas > FFTW_LIBS: -lfftw3 -lfftw3f > LIBS: -lreadline -lncurses -ldl -lz -lm -lfreetype -lz > -L/usr/X11R6/lib -lGL -lGLU > LEXLIB: > LIBGLOB: > SED: /bin/sed > DEFS: > > -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" > -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 > -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 > -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' > -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 > -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 > -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 > -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_FFTW3=1 -DHAVE_CURL_CURL_H=1 > -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 > -DHAVE_OPENGL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## > _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_GETHOSTNAME=1 > -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 > -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 > -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 > -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 > -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 > -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 > -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 > -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 > -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 > -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 > -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 > -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 > -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 > -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 > -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 > -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 > -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 > -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 > -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 > -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 > -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 > -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 > -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 > -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 > -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 > -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 > -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 > -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 > -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 > -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 > -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 > -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 > -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 > -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 > -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 > -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 > -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 > -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 > -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 > -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 > -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 > -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 > -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 > -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 > -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 > -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 > -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 > -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 > -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 > -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void > -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 > -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 > > User-preferences (please do not edit this section): > -------------------------------------------------- > > EDITOR = vim > EXEC_PATH = > /usr/lib/octave/3.2.3/site/exec/x86_64-unknown-linux-gnu:/usr/lib/octave/api-v37/site/exec/x86_64-unknown-linux-gnu:/usr/lib/octave/site/exec/x86_64-unknown-linux-gnu:/usr/lib/octave/3.2.3/exec/x86_64-unknown-linux-gnu:/usr/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/site:/usr/bin/perlbin/v endor:/usr/bin/perlbin/core > IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib > PAGER = less > PS1 = \s:\#> > PS2 = > > PS4 = + > beep_on_error = 0 > completion_append_char = > crash_dumps_octave_core = 1 > echo_executing_commands = 0 > fixed_point_format = 0 > gnuplot_binary = gnuplot > # gnuplot_command_end = > # gnuplot_command_plot = > # gnuplot_command_replot = > # gnuplot_command_splot = > # gnuplot_command_title = > # gnuplot_command_using = > # gnuplot_command_with = > history_file = /home/matej/.octave_hist > history_size = 1024 > ignore_function_time_stamp = system > info_file = /usr/share/info/octave.info > info_program = info > makeinfo_program = makeinfo > max_recursion_depth = 256 > output_max_field_width = 5 > output_precision = 5 > page_output_immediately = 0 > page_screen_output = 1 > # print_answer_id_name = > print_empty_dimensions = 1 > save_precision = 16 > saving_history = 1 > sighup_dumps_octave_core = 1 > sigterm_dumps_octave_core = 1 > silent_functions = 0 > split_long_rows = 1 > string_fill_char = > struct_levels_to_print = 2 > suppress_verbose_help_message = 0 > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From michael.goffioul at gmail.com Tue Nov 3 05:45:07 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Tue, 3 Nov 2009 11:45:07 +0000 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <718275.58909.qm@web112111.mail.gq1.yahoo.com> References: <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <718275.58909.qm@web112111.mail.gq1.yahoo.com> Message-ID: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> On Tue, Nov 3, 2009 at 10:51 AM, Sergei Steshenko wrote: >> Too bad. I think I'll definitely be out of the game then. >> >> Michael. >> _______________________________________________ > > > Isn't 'gfortran' coming with latest 'gcc' good enough ? My understanding is > that 'gfortran' is f95, i.e. even later than f90. As Jaroslav pointed out, gfortran is not compatible with MS compilers. The only free solution is f2c, which is f77 only. Michael. From sergstesh at yahoo.com Tue Nov 3 05:59:18 2009 From: sergstesh at yahoo.com (Sergei Steshenko) Date: Tue, 3 Nov 2009 03:59:18 -0800 (PST) Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> Message-ID: <408192.85650.qm@web112102.mail.gq1.yahoo.com> --- On Tue, 11/3/09, Michael Goffioul wrote: > From: Michael Goffioul > Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so > To: "Sergei Steshenko" > Cc: "Jaroslav Hajek" , "Georgi D. Sotirov" , bug-octave at octave.org > Date: Tuesday, November 3, 2009, 3:45 AM > On Tue, Nov 3, 2009 at 10:51 AM, > Sergei Steshenko > wrote: > >> Too bad. I think I'll definitely be out of the > game then. > >> > >> Michael. > >> _______________________________________________ > > > > > > Isn't 'gfortran' coming with latest 'gcc' good enough > ? My understanding is > > that 'gfortran' is f95, i.e. even later than f90. > > As Jaroslav pointed out, gfortran is not compatible with MS > compilers. > The only free solution is f2c, which is f77 only. > > Michael. > Well, there is cross-gcc, i.e. you can compile for Windows on a Linux/UNIX box. Though it doesn't guarantee MS compilers compatibility. And there is MinGW 'gcc'. Should 'octave' for Windows be necessarily compiled by MS compilers ? Thanks, Sergei. From daniel at sachse-zhang.com Tue Nov 3 07:50:33 2009 From: daniel at sachse-zhang.com (Antares42) Date: Tue, 3 Nov 2009 05:50:33 -0800 (PST) Subject: imshow, image and imagesc fail on small images Message-ID: <26160128.post@talk.nabble.com> Hi, using Octave 3.2.2 with Gnuplot 4.3.0 under Windows, I found the following confusing behaviour: A=[1 2 3 4; 5 6 7 8]; imshow(A,jet(9)); works while A=[1 2 3; 5 6 7]; imshow(A,jet(9)); does not. (It produces a white image only.) Similarly, colormap hot; A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6; 6 6 6 6 6]; imagesc(A); works while colormap hot; A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6]; imagesc(A); does not. And last but not least colormap(gray(2)); image(eye(5)+1); works, but colormap(gray(2)); image(eye(4)+1); does not. (Same of course for image -> imagesc.) A note: All axes seem to appear correctly. (Or in the case of imshow at least the coordinate system is scaled correctly. Axes can be summoned with "axis on".) No idea what is going on here. Daniel -- View this message in context: http://old.nabble.com/imshow%2C-image-and-imagesc-fail-on-small-images-tp26160128p26160128.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From individ at acc.umu.se Tue Nov 3 08:07:08 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 03 Nov 2009 15:07:08 +0100 Subject: method indexing bug Message-ID: <4AF0390C.5030600@acc.umu.se> Hi bug-list, In an object's subasgn, I want to assign to a object field using object.field(1, :) = [1,2] syntax. This works in Matlab. However, in Octave, I get 'error: a cs-list cannot be further indexed'. I'm attaching a tarball with an example as minimal as I could make it. After extracting the tarball, I can run p=Mini; p.key = 1:2 on rev 9771:4634a0e9ea1b to recreate the error message. Regards, David From individ at acc.umu.se Tue Nov 3 08:08:47 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 03 Nov 2009 15:08:47 +0100 Subject: method indexing bug In-Reply-To: <4AF0390C.5030600@acc.umu.se> References: <4AF0390C.5030600@acc.umu.se> Message-ID: <4AF0396F.2040009@acc.umu.se> David Grundberg wrote: > Hi bug-list, > > In an object's subasgn, I want to assign to a object field using > > object.field(1, :) = [1,2] > > syntax. This works in Matlab. However, in Octave, I get 'error: a > cs-list cannot be further indexed'. > > I'm attaching a tarball with an example as minimal as I could make it. > After extracting the tarball, I can run > > p=Mini; p.key = 1:2 > > on rev 9771:4634a0e9ea1b to recreate the error message. > > Regards, > David > Naturally, it helps if I actually attach the tarball. -------------- next part -------------- A non-text attachment was scrubbed... Name: Mini.tar.gz Type: application/x-gzip Size: 590 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091103/daaecce1/attachment.bin From jwe at octave.org Tue Nov 3 09:20:03 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 10:20:03 -0500 Subject: system() returning the wrong process return code under windows In-Reply-To: <4AE60277.2070809@gmx.net> References: <4AE3450B.50104@gmx.net> <128f38bd0910241359m63b5a189re5ba0480c6bf54e@mail.gmail.com> <4AE58672.8060607@gmx.net> <19173.48665.115355.211683@segfault.lan> <4AE60277.2070809@gmx.net> Message-ID: <19184.18979.46294.990965@segfault.lan> On 26-Oct-2009, Benjamin Lindner wrote: | > I hesitate to add more checks for systems/versions instead of | > features, so I would prefer it if this check were done with a | > configure test instaead. Then we would know from the configure test | > instead of having to enumerate the list of systems, and if the bug is | > fixed in the future, Octave will not have to change in order to work | > correctly. Maybe something that defines BROKEN_SYSTEM_EXIT_STATUS or | > similar? Maybe there is already a test for this in the autoconf macro | > archive. | > | > Or, is there really no bug in Windows here? Are we just using | > WIFEXITED and WEXITSTATUS incorrectly? | | Hmm, as far as I can see, the WIFEXITED and WEXITSTATUS are not | available as a standard on a windows system. | So one has to define them for windows platform, and the current | definition in syswait.h is incorrect for the windows platform. | | Now maybe my patch is not correct either, it just worked for me. | | On windows, _cwait (the implementation of the waitpid() macro in | syswait.h) stores the return code of the process, without any | transformation. And returns -1 if the process did not successfully exit. | So does pclose. | So the default macro implementation of checking the low-byte as status | and returning only the high as exit code does not work on windows. | | ( http://msdn.microsoft.com/en-us/library/zb9ehy71%28VS.80%29.aspx ) | ( http://msdn.microsoft.com/en-us/library/25xdhsd2%28VS.80%29.aspx ) Once we switch to automake and start using gnulib, we can fix this problem with a gnulib module: http://www.gnu.org/software/gnulib/MODULES.html#module=sys_wait The gnulib sys_wait.h.in file includes these lines: #else /* Native Windows API. */ # include # define waitpid(pid,statusp,options) _cwait (statusp, pid, WAIT_CHILD) /* The following macros apply to an argument x, that is a status of a process, as returned by waitpid() or, equivalently, _cwait() or GetExitCodeProcess(). This value is simply an 'int', not composed of bit fields. */ /* When an unhandled fatal signal terminates a process, the exit code is 3. */ # define WIFSIGNALED(x) ((x) == 3) # define WIFEXITED(x) ((x) != 3) # define WIFSTOPPED(x) 0 /* The signal that terminated a process is not known posthum. */ # define WTERMSIG(x) SIGTERM # define WEXITSTATUS(x) (x) /* There are no core dumps. */ # define WCOREDUMP(x) 0 #endif This is one of the big reasons I want to start using gnulib in Octave. There is a lot of portability experience expressed in the gnulib sources, and I don't think it makes a lot of sense for us to continue reinventing and rediscovering all these things ourselves, and then only having that experience reflected in the Octave sources. So I expect we will have some immediate benefits if we start using gnulib. If there are problems with it, then we can help to improve gnulib and everyone benefits, not just Octave users. jwe From mikulik at physics.muni.cz Tue Nov 3 10:31:53 2009 From: mikulik at physics.muni.cz (Petr Mikulik) Date: Tue, 3 Nov 2009 17:31:53 +0100 (CET) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <19183.38733.184096.833426@segfault.lan> References: <4AEB45DC.7060608@stefant.org> <19183.38733.184096.833426@segfault.lan> Message-ID: > | + else > | + term = "unknown"; It may be convenient to use the "dumb" terminal instead. However, $ GNUTERM=dumb octave octave> plot(1:100); does not draw anything in Octave 3.2.x while it works correctly in 3.0.x. Isn't the stdout of gnuplot redirected to /dev/null? --- PM From jwe at octave.org Tue Nov 3 10:39:42 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 11:39:42 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: References: <4AEB45DC.7060608@stefant.org> <19183.38733.184096.833426@segfault.lan> Message-ID: <19184.23758.696083.673263@segfault.lan> On 3-Nov-2009, Petr Mikulik wrote: | > | + else | > | + term = "unknown"; | | It may be convenient to use the "dumb" terminal instead. However, | | $ GNUTERM=dumb octave | octave> plot(1:100); | | does not draw anything in Octave 3.2.x while it works correctly in 3.0.x. Here is what I see with 3.2.3: $ GNUTERM=dumb octave3.2 GNU Octave, version 3.2.3 Copyright (C) 2009 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Octave was configured for "x86_64-pc-linux-gnu". Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). For information about changes from previous versions, type `news'. octave3.2:1> line Error: terminal "dumb" does not support continuous colors. octave3.2:2> No plot appears. | Isn't the stdout of gnuplot redirected to /dev/null? I don't see any code in Octave for doing that. jwe From jwe at octave.org Tue Nov 3 13:54:19 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 14:54:19 -0500 Subject: imshow, image and imagesc fail on small images In-Reply-To: <26160128.post@talk.nabble.com> References: <26160128.post@talk.nabble.com> Message-ID: <19184.35435.297864.313832@segfault.lan> On 3-Nov-2009, Antares42 wrote: | using Octave 3.2.2 with Gnuplot 4.3.0 under Windows, I found the following | confusing behaviour: | | A=[1 2 3 4; 5 6 7 8]; | imshow(A,jet(9)); | | works while | | A=[1 2 3; 5 6 7]; | imshow(A,jet(9)); | | does not. (It produces a white image only.) Similarly, | | colormap hot; | A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6; 6 6 6 6 6]; | imagesc(A); | | works while | | colormap hot; | A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6]; | imagesc(A); | | does not. And last but not least | | colormap(gray(2)); | image(eye(5)+1); | | works, but | | colormap(gray(2)); | image(eye(4)+1); | | does not. (Same of course for image -> imagesc.) | | A note: All axes seem to appear correctly. (Or in the case of imshow at | least the coordinate system is scaled correctly. Axes can be summoned with | "axis on".) I can't duplicate this problem with Octave 3.2.3 on a Debian system with gnuplot4.2.6. jwe From michael.goffioul at gmail.com Tue Nov 3 14:39:28 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Tue, 3 Nov 2009 20:39:28 +0000 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <408192.85650.qm@web112102.mail.gq1.yahoo.com> References: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> <408192.85650.qm@web112102.mail.gq1.yahoo.com> Message-ID: <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> On Tue, Nov 3, 2009 at 11:59 AM, Sergei Steshenko wrote: > > > --- On Tue, 11/3/09, Michael Goffioul wrote: > >> From: Michael Goffioul >> Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so >> To: "Sergei Steshenko" >> Cc: "Jaroslav Hajek" , "Georgi D. Sotirov" , bug-octave at octave.org >> Date: Tuesday, November 3, 2009, 3:45 AM >> On Tue, Nov 3, 2009 at 10:51 AM, >> Sergei Steshenko >> wrote: >> >> Too bad. I think I'll definitely be out of the >> game then. >> >> >> >> Michael. >> >> _______________________________________________ >> > >> > >> > Isn't 'gfortran' coming with latest 'gcc' good enough >> ? My understanding is >> > that 'gfortran' is f95, i.e. even later than f90. >> >> As Jaroslav pointed out, gfortran is not compatible with MS >> compilers. >> The only free solution is f2c, which is f77 only. >> >> Michael. >> > > Well, there is cross-gcc, i.e. you can compile for Windows on a Linux/UNIX > box. Though it doesn't guarantee MS compilers compatibility. > > And there is MinGW 'gcc'. > > Should 'octave' for Windows be necessarily compiled by MS compilers ? No. OTOH, do we want octave to be only compilable by gcc? Michael. From daniel at sachse-zhang.com Tue Nov 3 14:22:18 2009 From: daniel at sachse-zhang.com (Daniel Sachse) Date: Tue, 03 Nov 2009 21:22:18 +0100 Subject: imshow, image and imagesc fail on small images In-Reply-To: <19184.35435.297864.313832@segfault.lan> References: <26160128.post@talk.nabble.com> <19184.35435.297864.313832@segfault.lan> Message-ID: <4AF090FA.70201@sachse-zhang.com> I tried it on another pc, same configuration, same effect. Unfortunately, Octave Forge has not yet released 3.2.3 for Windows, so I cannot test that. Cheers, Daniel John W. Eaton wrote: > On 3-Nov-2009, Antares42 wrote: > > | using Octave 3.2.2 with Gnuplot 4.3.0 under Windows, I found the following > | confusing behaviour: > | > | A=[1 2 3 4; 5 6 7 8]; > | imshow(A,jet(9)); > | > | works while > | > | A=[1 2 3; 5 6 7]; > | imshow(A,jet(9)); > | > | does not. (It produces a white image only.) Similarly, > | > | colormap hot; > | A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6; 6 6 6 6 6]; > | imagesc(A); > | > | works while > | > | colormap hot; > | A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6]; > | imagesc(A); > | > | does not. And last but not least > | > | colormap(gray(2)); > | image(eye(5)+1); > | > | works, but > | > | colormap(gray(2)); > | image(eye(4)+1); > | > | does not. (Same of course for image -> imagesc.) > | > | A note: All axes seem to appear correctly. (Or in the case of imshow at > | least the coordinate system is scaled correctly. Axes can be summoned with > | "axis on".) > > I can't duplicate this problem with Octave 3.2.3 on a Debian system > with gnuplot4.2.6. > > jwe From chrysn at fsfe.org Tue Nov 3 14:44:45 2009 From: chrysn at fsfe.org (chrysn) Date: Tue, 3 Nov 2009 21:44:45 +0100 Subject: qr decomposition fails for certain matrices Message-ID: <20091103204445.GA30518@hephaistos.amsuess.com> (i hope this doesn't get filed twice; i reported it from within octave, but it seems to have missed the list) -------- Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu Description: ----------- * for the attached matrix "bad", the qr decomposition creates NaN and Inf Repeat-By: --------- * load "bad" * do `[Q,R] = qr(bad)` or `[Q,R,P] = qr(bad)`; you get several +/-Inf and NaN. (for comparison, matlab can decompose this; moreover, the qr decomposition should work with any given input) Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux hephaistos 2.6.30-2-amd64 #1 SMP Fri Sep 25 22:16:56 UTC 2009 x86_64 GNU/Linux configure opts: '--build=x86_64-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=x86_64-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' Fortran compiler: gfortran FFLAGS: -O2 -g FLIBS: -lgfortranbegin -lgfortran CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.4 (Debian 4.3.4-4) CFLAGS: -O2 -g CPICFLAG: -fPIC C++ compiler: g++, version 4.3.4 CXXFLAGS: -O2 -g CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 BLAS_LIBS: -llapackgf-3 -lblas-3gf FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = vim EXEC_PATH = /usr/lib/octave/3.2.3/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/api-v37/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/3.2.3/exec/x86_64-pc-linux-gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/games IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib PAGER = pager PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/chrysn/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave3.2.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 -------------- next part -------------- # Created by Octave 3.2.3, Wed Oct 28 11:36:58 2009 CET # name: bad # type: matrix # rows: 10 # columns: 10 10.08281071474692 -6.365001220213275e-16 -1.095862284704128e-15 -2.696039612100385e-16 2.028106670699041e-16 7.87609959122284e-16 -8.69535116950435e-16 -4.752957577688955e-16 -7.999882714801519e-16 -9.526555401654391e-16 3.072352834040245e-154 2.409834985187796 -7.080741419290825e-16 4.264640455734195e-16 -8.528245961335121e-16 1.662091446003039e-15 3.020979986170891e-16 -8.612567565067727e-16 -2.320203839266881e-16 4.274488504043562e-16 1.284045590470485e-180 -6.001692936490212e-28 1.884356937399034 0.007710938642175293 -4.104785221720314e-16 -3.534126315668841e-17 1.729655694077542e-16 -3.49090542331505e-16 2.860087248915117e-17 2.068312017813794e-16 1.990805540954218e-183 5.494494711313992e-30 0.007710938642175732 -1.831725592155371 8.958674039903884e-16 4.912516314330228e-16 1.729818694751086e-16 -3.080955978428914e-16 1.549335989744458e-16 2.953198444530853e-16 2.689116890988173e-201 1.558664161541373e-47 4.215846637899941e-21 -2.127226215234033e-18 1.554273726563368 -6.572292182197986e-10 1.720608741233552e-17 -3.922726689584524e-16 6.419004949219602e-17 2.442336539058333e-16 -7.597471931089994e-211 1.549041522751045e-57 -2.795771717229085e-31 4.89237461437074e-28 -6.572277398665318e-10 -1.421477099991831 -1.150360111462768e-16 2.244076894005266e-16 1.495432618687405e-16 3.055374795750419e-16 1.962665636287987e-269 -3.018824720713485e-116 4.919718380222504e-89 -2.868212539135241e-86 1.124954879426486e-68 3.46216949595653e-59 0.8243629511918087 5.891479416258602e-12 4.214620209217503e-17 6.119273197461773e-17 3.813852223721426e-281 1.000636734528609e-127 1.403004472579291e-100 -8.602656262752663e-98 1.599214745002984e-80 1.017409509385266e-70 5.890935017335692e-12 -0.7376758950027112 1.415418436186652e-16 -9.149250694666573e-17 0 5.649230126363334e-175 5.167601812435397e-149 -5.991195123604499e-146 -2.604808135773483e-128 1.057036480301348e-118 1.972820712705903e-59 -4.574201222769327e-48 0.4756823873383532 3.113929142453984e-17 0 6.208957057064851e-307 3.933340142416565e-281 -6.138020110399418e-278 -2.714866147239894e-260 1.129805731278581e-250 1.998330648384745e-191 -4.53409391582144e-180 5.171745669229912e-133 -0.1383051152355606 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091103/1acb3eb0/attachment.bin From jwe at octave.org Tue Nov 3 15:24:08 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 16:24:08 -0500 Subject: Add property FormatSpacing to root In-Reply-To: <4AEFFED5.2070207@acc.umu.se> References: <4AEFFED5.2070207@acc.umu.se> Message-ID: <19184.40824.430346.163832@segfault.lan> On 3-Nov-2009, David Grundberg wrote: | In Matlab's "display" function help text, there is an example how to | implement a user-defined display method. The root property FormatSpacing | is used in this example. Octave doesn't have such a property. | | I attached a changeset that adds a formatspacing root property. I applied it and also checked in the following changes that provide some additional root figure properties for compatibility: http://hg.savannah.gnu.org/hgweb/octave/rev/2364eebcd644 http://hg.savannah.gnu.org/hgweb/octave/rev/2941c1daf509 Thanks, jwe From jwe at octave.org Tue Nov 3 16:08:06 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 17:08:06 -0500 Subject: qr decomposition fails for certain matrices In-Reply-To: <20091103204445.GA30518@hephaistos.amsuess.com> References: <20091103204445.GA30518@hephaistos.amsuess.com> Message-ID: <19184.43462.342573.115713@segfault.lan> On 3-Nov-2009, chrysn wrote: | (i hope this doesn't get filed twice; i reported it from within octave, | but it seems to have missed the list) | | -------- | Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu | | Description: | ----------- | | * for the attached matrix "bad", the qr decomposition creates NaN and Inf | | Repeat-By: | --------- | | * load "bad" | * do `[Q,R] = qr(bad)` or `[Q,R,P] = qr(bad)`; you get several +/-Inf and | NaN. | | (for comparison, matlab can decompose this; moreover, the qr decomposition | should work with any given input) Octave just uses DGEQRF from LAPACK for computing the QR decomposition in this case. So unless we are calling that function incorrectly (possible, but it seems unlikely, since it works for many other cases...), I think the problem is with LAPACK. I'm attaching a simple program that demonstrates the problem with your data. It makes the same call to DGEQRF that Octave does. If I use the LAPACK 3.2.1 library that is installed on my Debian system, I see Inf and NaN values in the result. If I use the older reference LAPACK 3.1 sources that are distributed with Octave, I see the more reasonable result: required workspace = 320 we are using 560 info = 0 a = -0.10E+02 0.64E-15 0.11E-14 0.27E-15 -0.20E-15 -0.79E-15 0.87E-15 0.48E-15 0.80E-15 0.95E-15 0.15-154 -0.24E+01 0.71E-15 -0.43E-15 0.85E-15 -0.17E-14 -0.30E-15 0.86E-15 0.23E-15 -0.43E-15 0.64-181 -0.12E-27 -0.19E+01 -0.22E-03 0.41E-15 0.33E-16 -0.17E-15 0.35E-15 -0.29E-16 -0.21E-15 0.99-184 0.11E-29 0.20E-02 0.18E+01 -0.90E-15 -0.49E-15 -0.17E-15 0.31E-15 -0.15E-15 -0.29E-15 0.13-201 0.32E-47 0.11E-20 0.58E-18 -0.16E+01 0.56E-10 -0.17E-16 0.39E-15 -0.64E-16 -0.24E-15 -0.38-211 0.32E-57 -0.74E-31 -0.13E-27 -0.21E-09 0.14E+01 0.12E-15 -0.22E-15 -0.15E-15 -0.31E-15 0.97-270 -0.63-116 0.13E-88 0.78E-86 0.36E-68 -0.12E-58 -0.82E+00 -0.62E-12 -0.42E-16 -0.61E-16 0.19-281 0.21-127 0.37-100 0.23E-97 0.51E-80 -0.36E-70 0.36E-11 0.74E+00 -0.14E-15 0.91E-16 0.00E+00 0.12-174 0.14-148 0.16-145 -0.84-128 -0.37-118 0.12E-58 0.31E-47 -0.48E+00 -0.31E-16 0.00E+00 0.13-306 0.10-280 0.17-277 -0.87-260 -0.40-250 0.12-190 0.31-179 0.54-132 -0.14E+00 tau = 0.20E+01 0.20E+01 0.20E+01 0.20E+01 0.20E+01 0.20E+01 0.20E+01 0.20E+01 0.20E+01 0.00E+00 jwe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: foo.f Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091103/b6a391a7/attachment-0001.ksh From tmacchant at yahoo.co.jp Tue Nov 3 18:27:15 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Wed, 4 Nov 2009 09:27:15 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <19184.23758.696083.673263@segfault.lan> Message-ID: <20091104002719.45779.qmail@web3804.mail.bbt.yahoo.co.jp> Hello For octave 3.2.3 and gnuplot 4.5 CVS on mingw, I did not see what John has shown but saw that octave only represented the next prompt. Perhaps what I saw is the same as what Petr saw. Perhaps the response octave depends on gnuplot version. > | Isn't the stdout of gnuplot redirected to /dev/null? I do not know for octave 3.0.x. At least, octave 3.2.x or later uses bidirectional pipes to communicate with gnuplot. In the 'gnuplot_drawnow.m', (octave 3.0.x does not have it), 'dumb' terminal is not treated. Therefore it is quite natural octave 3.2 does not respond to 'dumb' terminal. If you would like you use dumb terminal octave 3.2 or later, you should modify gnuplot_drawnow.m. Regards Tatsuro --- "John W. Eaton" wrote: > On 3-Nov-2009, Petr Mikulik wrote: > > | > | + else > | > | + term = "unknown"; > | > | It may be convenient to use the "dumb" terminal instead. However, > | > | $ GNUTERM=dumb octave > | octave> plot(1:100); > | > | does not draw anything in Octave 3.2.x while it works correctly in 3.0.x. > > Here is what I see with 3.2.3: > > $ GNUTERM=dumb octave3.2 > GNU Octave, version 3.2.3 > Copyright (C) 2009 John W. Eaton and others. > This is free software; see the source code for copying conditions. > There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or > FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. > > Octave was configured for "x86_64-pc-linux-gnu". > > Additional information about Octave is available at http://www.octave.org. > > Please contribute if you find this software useful. > For more information, visit http://www.octave.org/help-wanted.html > > Report bugs to (but first, please read > http://www.octave.org/bugs.html to learn how to write a helpful report). > > For information about changes from previous versions, type `news'. > > octave3.2:1> line > Error: terminal "dumb" does not support continuous colors. > octave3.2:2> > > No plot appears. > > | Isn't the stdout of gnuplot redirected to /dev/null? > > I don't see any code in Octave for doing that. > > jwe > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Tue Nov 3 19:41:11 2009 From: bpabbott at mac.com (Ben Abbott) Date: Tue, 03 Nov 2009 20:41:11 -0500 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> Message-ID: On Nov 2, 2009, at 4:58 AM, Jaroslav Hajek wrote: > On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov > wrote: >> Hello, >> >> I encounter the following problem on Slackware Linux 13.0 with >> LAPACK 3.2.1 >> and Octave 3.2.3. When I run octave it uses almost the whole CPU >> time on the >> machine, without being able to finish. I've traced the problem to the >> following: >> >> # gdb /usr/bin/octave >> GNU gdb 6.8 >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "i486-slackware-linux"... >> (no debugging symbols found) >> (gdb) r >> Starting program: /usr/bin/octave >> (no debugging symbols found) >> [Thread debugging using libthread_db enabled] >> (no debugging symbols found) >> [New Thread 0xb599e8e0 (LWP 3266)] >> (no debugging symbols found) >> ^C >> Program received signal SIGINT, Interrupt. >> [Switching to Thread 0xb599e8e0 (LWP 3266)] >> 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 >> (gdb) bt >> #0 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 >> #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 >> #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 >> #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 >> #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so >> #5 0xb69f158d in oct_mach_info::init_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #6 0xb69f1682 in oct_mach_info::oct_mach_info () from >> /usr/lib/octave-3.2.3/liboctave.so >> #7 0xb69f16ee in oct_mach_info::instance_ok () from >> /usr/lib/octave-3.2.3/liboctave.so >> #8 0xb69f17b7 in oct_mach_info::native_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #9 0xb69de464 in octave_ieee_init () from >> /usr/lib/octave-3.2.3/liboctave.so >> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/ >> liboctinterp.so >> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/ >> liboctinterp.so >> #12 0x080486da in main () >> (gdb) c >> Continuing. >> ^C >> Program received signal SIGINT, Interrupt. >> 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 >> (gdb) bt >> #0 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 >> #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 >> #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 >> #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 >> #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so >> #5 0xb69f158d in oct_mach_info::init_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #6 0xb69f1682 in oct_mach_info::oct_mach_info () from >> /usr/lib/octave-3.2.3/liboctave.so >> #7 0xb69f16ee in oct_mach_info::instance_ok () from >> /usr/lib/octave-3.2.3/liboctave.so >> #8 0xb69f17b7 in oct_mach_info::native_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #9 0xb69de464 in octave_ieee_init () from >> /usr/lib/octave-3.2.3/liboctave.so >> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/ >> liboctinterp.so >> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/ >> liboctinterp.so >> #12 0x080486da in main () >> >> It seems, that Octave is stuck on an infinite loop in LAPACK, which >> in my >> case is compiled as a separate shared library by gcc 4.3.3 with flags >> "-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I >> have the >> same problem with flags "-fimplicit-none -O2 -march=i486 - >> mtune=i686 -fPIC" >> and also with "-O3" (I've though at one point it may be some >> optimization >> issue). Then, I noticed that octave runs normally if compiled without >> system's LAPACK (./configure --without-lapack). In this case LAPACK >> is >> compiled for libcruft with just "-O -mieee-fp" flags. >> >> Any suggestions? Is the problem in Octave or it's in LAPACK? How >> could I >> help for the resolving of this problem? >> > > the SLAMCH and DLAMCH routines are sensitive to compiler > optimizations. I use the settings (in make.inc from LAPACK tarball) > NOOPT = -mieee-fp -ffloat-store -fPIC > and it works well. I think that in future releases these routines will > be replaced by querying Fortran 90 internals. > > hth I just noticed this thread. I've burned a unexpected amount of time trying to compile a fortran program that requires lapack under Windows. Today I switched from lapack 3.2.1 to lapack 3.1.1 and my problems have disappeared. I have also traced the problem to dlamch ... thus, I'm responding because using lapack 3.1.1 may resolve this problem as well. Ben From lindnerben at gmx.net Wed Nov 4 01:30:34 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 04 Nov 2009 08:30:34 +0100 Subject: imshow, image and imagesc fail on small images In-Reply-To: <4AF090FA.70201@sachse-zhang.com> References: <26160128.post@talk.nabble.com> <19184.35435.297864.313832@segfault.lan> <4AF090FA.70201@sachse-zhang.com> Message-ID: <20091104073034.227470@gmx.net> > John W. Eaton wrote: > > On 3-Nov-2009, Antares42 wrote: > > > > | using Octave 3.2.2 with Gnuplot 4.3.0 under Windows, I found the > following > > | confusing behaviour: > > | > > | A=[1 2 3 4; 5 6 7 8]; > > | imshow(A,jet(9)); > > | > > | works while > > | > > | A=[1 2 3; 5 6 7]; > > | imshow(A,jet(9)); > > | > > | does not. (It produces a white image only.) Similarly, > > | > > | colormap hot; > > | A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6; 6 6 6 6 6]; > > | imagesc(A); > > | > > | works while > > | > > | colormap hot; > > | A=[1 2 3 4 6; 5 6 7 6 8; 5 5 5 5 6; 5 5 5 5 6]; > > | imagesc(A); > > | > > | does not. And last but not least > > | > > | colormap(gray(2)); > > | image(eye(5)+1); > > | > > | works, but > > | > > | colormap(gray(2)); > > | image(eye(4)+1); > > | > > | does not. (Same of course for image -> imagesc.) > > | > > | A note: All axes seem to appear correctly. (Or in the case of imshow > at > > | least the coordinate system is scaled correctly. Axes can be summoned > with > > | "axis on".) > > > > I can't duplicate this problem with Octave 3.2.3 on a Debian system > > with gnuplot4.2.6. > > > > jwe > > I tried it on another pc, same configuration, same effect. > > Unfortunately, Octave Forge has not yet released 3.2.3 for Windows, so I > cannot test that. Fortunately, it has (There seem to be problems with SSE3 atlas, so please choose the SSE2 libraries for now) But you'll find the same problem. I suspect it's a gnuplot problem with the windows terminal, because if you switch to wxt terminal - putenv("gnuterm","wxt") - the problem's gone. Debugging octave's commands to gnuplot I find that the commands to set the xrange and yrange are causing the problem. If you omit them (in a separate gnuplot session), then display is fine. You can get a transcript of the gnuplot commands from octave by drawnow("windows", "", 0, "debug.gp"); If you then remove the two commands to set xrange and yrange, then it works for me. A simple testcase that shows the effect is set term windows plot "-" matrix with image 1 2 3 1 e e versus set term windows set xrange [0:1]; set yrange [0:1]; plot "-" matrix with image 1 2 3 1 e e This should be reported to gnuplot I guess. benjamin benjamin -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser From highegg at gmail.com Wed Nov 4 03:28:44 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 4 Nov 2009 10:28:44 +0100 Subject: qr decomposition fails for certain matrices In-Reply-To: <19184.43462.342573.115713@segfault.lan> References: <20091103204445.GA30518@hephaistos.amsuess.com> <19184.43462.342573.115713@segfault.lan> Message-ID: <69d8d540911040128k3f243075g2f675489beec18ad@mail.gmail.com> On Tue, Nov 3, 2009 at 11:08 PM, John W. Eaton wrote: > On ?3-Nov-2009, chrysn wrote: > > | (i hope this doesn't get filed twice; i reported it from within octave, > | but it seems to have missed the list) > | > | -------- > | Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu > | > | Description: > | ----------- > | > | ? * for the attached matrix "bad", the qr decomposition creates NaN and Inf > | > | Repeat-By: > | --------- > | > | ? * load "bad" > | ? * do `[Q,R] = qr(bad)` or `[Q,R,P] = qr(bad)`; you get several +/-Inf and > | ? ? NaN. > | > | (for comparison, matlab can decompose this; moreover, the qr decomposition > | should work with any given input) > > Octave just uses DGEQRF from LAPACK for computing the QR decomposition > in this case. ?So unless we are calling that function incorrectly > (possible, but it seems unlikely, since it works for many other > cases...), I think the problem is with LAPACK. ?I'm attaching a simple > program that demonstrates the problem with your data. ?It makes the > same call to DGEQRF that Octave does. > > If I use the LAPACK 3.2.1 library that is installed on my Debian > system, I see Inf and NaN values in the result. > > If I use the older reference LAPACK 3.1 sources that are distributed > with Octave, I see the more reasonable result: > > ?required workspace = ? 320 we are using 560 > ? info = ? ? ? ? ? ?0 > ? a = > ? ? -0.10E+02 ? ?0.64E-15 ? ?0.11E-14 ? ?0.27E-15 ? -0.20E-15 ? -0.79E-15 ? ?0.87E-15 ? ?0.48E-15 ? ?0.80E-15 ? ?0.95E-15 > ? ? ?0.15-154 ? -0.24E+01 ? ?0.71E-15 ? -0.43E-15 ? ?0.85E-15 ? -0.17E-14 ? -0.30E-15 ? ?0.86E-15 ? ?0.23E-15 ? -0.43E-15 > ? ? ?0.64-181 ? -0.12E-27 ? -0.19E+01 ? -0.22E-03 ? ?0.41E-15 ? ?0.33E-16 ? -0.17E-15 ? ?0.35E-15 ? -0.29E-16 ? -0.21E-15 > ? ? ?0.99-184 ? ?0.11E-29 ? ?0.20E-02 ? ?0.18E+01 ? -0.90E-15 ? -0.49E-15 ? -0.17E-15 ? ?0.31E-15 ? -0.15E-15 ? -0.29E-15 > ? ? ?0.13-201 ? ?0.32E-47 ? ?0.11E-20 ? ?0.58E-18 ? -0.16E+01 ? ?0.56E-10 ? -0.17E-16 ? ?0.39E-15 ? -0.64E-16 ? -0.24E-15 > ? ? -0.38-211 ? ?0.32E-57 ? -0.74E-31 ? -0.13E-27 ? -0.21E-09 ? ?0.14E+01 ? ?0.12E-15 ? -0.22E-15 ? -0.15E-15 ? -0.31E-15 > ? ? ?0.97-270 ? -0.63-116 ? ?0.13E-88 ? ?0.78E-86 ? ?0.36E-68 ? -0.12E-58 ? -0.82E+00 ? -0.62E-12 ? -0.42E-16 ? -0.61E-16 > ? ? ?0.19-281 ? ?0.21-127 ? ?0.37-100 ? ?0.23E-97 ? ?0.51E-80 ? -0.36E-70 ? ?0.36E-11 ? ?0.74E+00 ? -0.14E-15 ? ?0.91E-16 > ? ? ?0.00E+00 ? ?0.12-174 ? ?0.14-148 ? ?0.16-145 ? -0.84-128 ? -0.37-118 ? ?0.12E-58 ? ?0.31E-47 ? -0.48E+00 ? -0.31E-16 > ? ? ?0.00E+00 ? ?0.13-306 ? ?0.10-280 ? ?0.17-277 ? -0.87-260 ? -0.40-250 ? ?0.12-190 ? ?0.31-179 ? ?0.54-132 ? -0.14E+00 > ? tau = > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.20E+01 > ? ? ?0.00E+00 > > > jwe > > > ? ? ?program foo > > ? ? ?double precision a(10,10) > ? ? ?double precision work(560) > ? ? ?double precision tau(10) > ? ? ?integer info > > ? ? ?a(1,1) = 10.08281071474692 > ? ? ?a(1,2) = -6.365001220213275D-16 > ? ? ?a(1,3) = -1.095862284704128D-15 > ? ? ?a(1,4) = -2.696039612100385D-16 > ? ? ?a(1,5) = 2.028106670699041D-16 > ? ? ?a(1,6) = 7.87609959122284D-16 > ? ? ?a(1,7) = -8.69535116950435D-16 > ? ? ?a(1,8) = -4.752957577688955D-16 > ? ? ?a(1,9) = -7.999882714801519D-16 > ? ? ?a(1,10) = -9.526555401654391D-16 > > ? ? ?a(2,1) = 3.072352834040245D-154 > ? ? ?a(2,2) = 2.409834985187796 > ? ? ?a(2,3) = -7.080741419290825D-16 > ? ? ?a(2,4) = 4.264640455734195D-16 > ? ? ?a(2,5) = -8.528245961335121D-16 > ? ? ?a(2,6) = 1.662091446003039D-15 > ? ? ?a(2,7) = 3.020979986170891D-16 > ? ? ?a(2,8) = -8.612567565067727D-16 > ? ? ?a(2,9) = -2.320203839266881D-16 > ? ? ?a(2,10) = 4.274488504043562D-16 > > ? ? ?a(3,1) = 1.284045590470485D-180 > ? ? ?a(3,2) = -6.001692936490212D-28 > ? ? ?a(3,3) = 1.884356937399034 > ? ? ?a(3,4) = 0.007710938642175293 > ? ? ?a(3,5) = -4.104785221720314D-16 > ? ? ?a(3,6) = -3.534126315668841D-17 > ? ? ?a(3,7) = 1.729655694077542D-16 > ? ? ?a(3,8) = -3.49090542331505D-16 > ? ? ?a(3,9) = 2.860087248915117D-17 > ? ? ?a(3,10) = 2.068312017813794D-16 > > ? ? ?a(4,1) = 1.990805540954218D-183 > ? ? ?a(4,2) = 5.494494711313992D-30 > ? ? ?a(4,3) = 0.007710938642175732 > ? ? ?a(4,4) = -1.831725592155371 > ? ? ?a(4,5) = 8.958674039903884D-16 > ? ? ?a(4,6) = 4.912516314330228D-16 > ? ? ?a(4,7) = 1.729818694751086D-16 > ? ? ?a(4,8) = -3.080955978428914D-16 > ? ? ?a(4,9) = 1.549335989744458D-16 > ? ? ?a(4,10) = 2.953198444530853D-16 > > ? ? ?a(5,1) = 2.689116890988173D-201 > ? ? ?a(5,2) = 1.558664161541373D-47 > ? ? ?a(5,3) = 4.215846637899941D-21 > ? ? ?a(5,4) = -2.127226215234033D-18 > ? ? ?a(5,5) = 1.554273726563368 > ? ? ?a(5,6) = -6.572292182197986D-10 > ? ? ?a(5,7) = 1.720608741233552D-17 > ? ? ?a(5,8) = -3.922726689584524D-16 > ? ? ?a(5,9) = 6.419004949219602D-17 > ? ? ?a(5,10) = 2.442336539058333D-16 > > ? ? ?a(6,1) = -7.597471931089994D-211 > ? ? ?a(6,2) = 1.549041522751045D-57 > ? ? ?a(6,3) = -2.795771717229085D-31 > ? ? ?a(6,4) = 4.89237461437074D-28 > ? ? ?a(6,5) = -6.572277398665318D-10 > ? ? ?a(6,6) = -1.421477099991831 > ? ? ?a(6,7) = -1.150360111462768D-16 > ? ? ?a(6,8) = 2.244076894005266D-16 > ? ? ?a(6,9) = 1.495432618687405D-16 > ? ? ?a(6,10) = 3.055374795750419D-16 > > ? ? ?a(7,1) = 1.962665636287987D-269 > ? ? ?a(7,2) = -3.018824720713485D-116 > ? ? ?a(7,3) = 4.919718380222504D-89 > ? ? ?a(7,4) = -2.868212539135241D-86 > ? ? ?a(7,5) = 1.124954879426486D-68 > ? ? ?a(7,6) = 3.46216949595653D-59 > ? ? ?a(7,7) = 0.8243629511918087 > ? ? ?a(7,8) = 5.891479416258602D-12 > ? ? ?a(7,9) = 4.214620209217503D-17 > ? ? ?a(7,10) = 6.119273197461773D-17 > > ? ? ?a(8,1) = 3.813852223721426D-281 > ? ? ?a(8,2) = 1.000636734528609D-127 > ? ? ?a(8,3) = 1.403004472579291D-100 > ? ? ?a(8,4) = -8.602656262752663D-98 > ? ? ?a(8,5) = 1.599214745002984D-80 > ? ? ?a(8,6) = 1.017409509385266D-70 > ? ? ?a(8,7) = 5.890935017335692D-12 > ? ? ?a(8,8) = -0.7376758950027112 > ? ? ?a(8,9) = 1.415418436186652D-16 > ? ? ?a(8,10) = -9.149250694666573D-17 > > ? ? ?a(9,1) = 0 > ? ? ?a(9,2) = 5.649230126363334D-175 > ? ? ?a(9,3) = 5.167601812435397D-149 > ? ? ?a(9,4) = -5.991195123604499D-146 > ? ? ?a(9,5) = -2.604808135773483D-128 > ? ? ?a(9,6) = 1.057036480301348D-118 > ? ? ?a(9,7) = 1.972820712705903D-59 > ? ? ?a(9,8) = -4.574201222769327D-48 > ? ? ?a(9,9) = 0.4756823873383532 > ? ? ?a(9,10) = 3.113929142453984D-17 > > ? ? ?a(10,1) = 0 > ? ? ?a(10,2) = 6.208957057064851D-307 > ? ? ?a(10,3) = 3.933340142416565D-281 > ? ? ?a(10,4) = -6.138020110399418D-278 > ? ? ?a(10,5) = -2.714866147239894D-260 > ? ? ?a(10,6) = 1.129805731278581D-250 > ? ? ?a(10,7) = 1.998330648384745D-191 > ? ? ?a(10,8) = -4.53409391582144D-180 > ? ? ?a(10,9) = 5.171745669229912D-133 > ? ? ?a(10,10) = -0.1383051152355606 > > * query workspace requiremnt. > ? ? ?call dgeqrf (10, 10, a, 10, tau, work, -1, info) > ? ? ?write (*,'(a,i5,a)') > ? ? $ ? ? 'required workspace = ', int (work(1)), ' we are using 560' > > * compute decomposition > ? ? ?call dgeqrf (10, 10, a, 10, tau, work, 560, info) > > ? ? ?print *, 'info = ', info > ? ? ?print *, 'a = ' > ? ? ?do i = 1, 10 > ? ? ? ?write(*,'(10e12.2)') (a(i,j), j = 1, 10) > ? ? ?enddo > ? ? ?print *, 'tau = ' > ? ? ?do i = 1, 10 > ? ? ? ?write(*,'(e12.2)') tau(i) > ? ? ?enddo > > ? ? ?end > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > I spent some time investigating this. Apparently the new xLARFP routines are responsible for these problems. These are described in the LAPACK working note 203: http://www.netlib.org/lapack/lawnspdf/lawn203.pdf Specifically, on page 4, the text says: "Both imag(alpha)/gamma and norm(x)/gamma are less than one, so abs(delta) <= abs(beta) and these computations introduce no new overfl ow possibilities into the existing routines." It seems to me that this is utterly wrong. Apparently delta = norm(x) * (norm(x) / beta) can't overflow, but it can easily underflow if norm(x) is a tiny number; hence subsequent division asks for problems. A possible remedy is to split into two scalings, one by norm(x) and one by norm(x)/beta - still, even norm(x)/beta alone can underflow. It seems to me that the goal of achieving beta >= 0 together with keeping the leading one in the reflection vector is too ambitious. Something like the following patch fixes the worst of the problem, but still doesn't solve everything. Just raise a(:,1) to second power in your test matrix and you're back in XXX. Hmmm... diff --git a/dlarfp.f b/dlarfp.f --- a/dlarfp.f +++ b/dlarfp.f @@ -134,8 +134,13 @@ BETA = -BETA TAU = -ALPHA / BETA ELSE - ALPHA = XNORM * (XNORM/ALPHA) - TAU = ALPHA / BETA + ALPHA = XNORM/ALPHA + TAU = XNORM * ALPHA + IF (TAU >= SAFMIN) THEN + ALPHA = TAU + ELSE + CALL DSCAL ( N-1, ONE / XNORM, X, INCX ) + END IF ALPHA = -ALPHA END IF CALL DSCAL( N-1, ONE / ALPHA, X, INCX ) diff --git a/slarfp.f b/slarfp.f --- a/slarfp.f +++ b/slarfp.f @@ -134,8 +134,13 @@ BETA = -BETA TAU = -ALPHA / BETA ELSE - ALPHA = XNORM * (XNORM/ALPHA) - TAU = ALPHA / BETA + ALPHA = XNORM/ALPHA + TAU = XNORM * ALPHA + IF (TAU >= SAFMIN) THEN + ALPHA = TAU + ELSE + CALL SSCAL ( N-1, ONE / XNORM, X, INCX ) + END IF ALPHA = -ALPHA END IF CALL SSCAL( N-1, ONE / ALPHA, X, INCX ) -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From sergstesh at yahoo.com Wed Nov 4 03:45:40 2009 From: sergstesh at yahoo.com (Sergei Steshenko) Date: Wed, 4 Nov 2009 01:45:40 -0800 (PST) Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> Message-ID: <390539.19709.qm@web112105.mail.gq1.yahoo.com> --- On Tue, 11/3/09, Michael Goffioul wrote: > From: Michael Goffioul > Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so > To: "Sergei Steshenko" > Cc: "Jaroslav Hajek" , "Georgi D. Sotirov" , bug-octave at octave.org > Date: Tuesday, November 3, 2009, 12:39 PM > On Tue, Nov 3, 2009 at 11:59 AM, > Sergei Steshenko > wrote: > > > > > > --- On Tue, 11/3/09, Michael Goffioul > wrote: > > > >> From: Michael Goffioul > >> Subject: Re: Octave loops infinitely in dlamc3_ > from /usr/lib/liblapack.so > >> To: "Sergei Steshenko" > >> Cc: "Jaroslav Hajek" , > "Georgi D. Sotirov" , > bug-octave at octave.org > >> Date: Tuesday, November 3, 2009, 3:45 AM > >> On Tue, Nov 3, 2009 at 10:51 AM, > >> Sergei Steshenko > >> wrote: > >> >> Too bad. I think I'll definitely be out > of the > >> game then. > >> >> > >> >> Michael. > >> >> > _______________________________________________ > >> > > >> > > >> > Isn't 'gfortran' coming with latest 'gcc' > good enough > >> ? My understanding is > >> > that 'gfortran' is f95, i.e. even later than > f90. > >> > >> As Jaroslav pointed out, gfortran is not > compatible with MS > >> compilers. > >> The only free solution is f2c, which is f77 only. > >> > >> Michael. > >> > > > > Well, there is cross-gcc, i.e. you can compile for > Windows on a Linux/UNIX > > box. Though it doesn't guarantee MS compilers > compatibility. > > > > And there is MinGW 'gcc'. > > > > Should 'octave' for Windows be necessarily compiled by > MS compilers ? > > No. OTOH, do we want octave to be only compilable by gcc? > > Michael. > I think you are hiding the real issue in your question. The real issue that for 'octave' to be compiled wherever, one needs decent C/C++ compiler + f95 (or later) compiler (because of the latest LAPACK). The truth is that 'gcc' suite contains both, so going with 'gcc' is the path of least resistance. Another possible positive outcome of going with 'gcc' on all OSes is that C/C++/Fortran quirks will be much more similar - this will make bug fixing easier. Regards, Sergei. From soren at hauberg.org Wed Nov 4 03:55:41 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Wed, 04 Nov 2009 10:55:41 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> References: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> <408192.85650.qm@web112102.mail.gq1.yahoo.com> <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> Message-ID: <1257328541.3990.11.camel@sh-t400> tir, 03 11 2009 kl. 20:39 +0000, skrev Michael Goffioul: > > Should 'octave' for Windows be necessarily compiled by MS compilers ? > > No. OTOH, do we want octave to be only compilable by gcc? There are many (some more silly than others) measures of code quality. One sign of good quality is that the code compiles with several different compilers. So, while I only use gcc, I do appreciate the fact that Octave also works with MSVC. S?ren From highegg at gmail.com Wed Nov 4 04:20:33 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 4 Nov 2009 11:20:33 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <1257328541.3990.11.camel@sh-t400> References: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> <408192.85650.qm@web112102.mail.gq1.yahoo.com> <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> <1257328541.3990.11.camel@sh-t400> Message-ID: <69d8d540911040220v5ea5e1cp5aac2aea003df272@mail.gmail.com> On Wed, Nov 4, 2009 at 10:55 AM, S?ren Hauberg wrote: > tir, 03 11 2009 kl. 20:39 +0000, skrev Michael Goffioul: >> > Should 'octave' for Windows be necessarily compiled by MS compilers ? >> >> No. OTOH, do we want octave to be only compilable by gcc? > > There are many (some more silly than others) measures of code quality. > One sign of good quality is that the code compiles with several > different compilers. So, while I only use gcc, I do appreciate the fact > that Octave also works with MSVC. > > S?ren Similarly, I would very much like Octave to stay compilable by the Intel C++ & Fortran compilers. Optional optimizations or tricks specific to gcc are OK, but making gcc a requirement would IMHO be a bad move. As Sergei noted, however, here the problem is not about Octave (or LAPACK) becoming gcc-only, but rather the lack of a free MSVC-compatible Fortran 90 compiler for the Windows platform. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From gdsotirov at dir.bg Wed Nov 4 01:52:29 2009 From: gdsotirov at dir.bg (Georgi D. Sotirov) Date: Wed, 04 Nov 2009 09:52:29 +0200 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> Message-ID: <4AF132BD.2030501@dir.bg> Jaroslav Hajek wrote: > On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov wrote: > >> Hello, >> >> I encounter the following problem on Slackware Linux 13.0 with LAPACK 3.2.1 >> and Octave 3.2.3. When I run octave it uses almost the whole CPU time on the >> machine, without being able to finish. I've traced the problem to the >> following: >> >> # gdb /usr/bin/octave >> GNU gdb 6.8 >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i486-slackware-linux"... >> (no debugging symbols found) >> (gdb) r >> Starting program: /usr/bin/octave >> (no debugging symbols found) >> [Thread debugging using libthread_db enabled] >> (no debugging symbols found) >> [New Thread 0xb599e8e0 (LWP 3266)] >> (no debugging symbols found) >> ^C >> Program received signal SIGINT, Interrupt. >> [Switching to Thread 0xb599e8e0 (LWP 3266)] >> 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 >> (gdb) bt >> #0 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 >> #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 >> #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 >> #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 >> #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so >> #5 0xb69f158d in oct_mach_info::init_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #6 0xb69f1682 in oct_mach_info::oct_mach_info () from >> /usr/lib/octave-3.2.3/liboctave.so >> #7 0xb69f16ee in oct_mach_info::instance_ok () from >> /usr/lib/octave-3.2.3/liboctave.so >> #8 0xb69f17b7 in oct_mach_info::native_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #9 0xb69de464 in octave_ieee_init () from >> /usr/lib/octave-3.2.3/liboctave.so >> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so >> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so >> #12 0x080486da in main () >> (gdb) c >> Continuing. >> ^C >> Program received signal SIGINT, Interrupt. >> 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 >> (gdb) bt >> #0 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 >> #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 >> #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 >> #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 >> #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so >> #5 0xb69f158d in oct_mach_info::init_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #6 0xb69f1682 in oct_mach_info::oct_mach_info () from >> /usr/lib/octave-3.2.3/liboctave.so >> #7 0xb69f16ee in oct_mach_info::instance_ok () from >> /usr/lib/octave-3.2.3/liboctave.so >> #8 0xb69f17b7 in oct_mach_info::native_float_format () from >> /usr/lib/octave-3.2.3/liboctave.so >> #9 0xb69de464 in octave_ieee_init () from >> /usr/lib/octave-3.2.3/liboctave.so >> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so >> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so >> #12 0x080486da in main () >> >> It seems, that Octave is stuck on an infinite loop in LAPACK, which in my >> case is compiled as a separate shared library by gcc 4.3.3 with flags >> "-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I have the >> same problem with flags "-fimplicit-none -O2 -march=i486 -mtune=i686 -fPIC" >> and also with "-O3" (I've though at one point it may be some optimization >> issue). Then, I noticed that octave runs normally if compiled without >> system's LAPACK (./configure --without-lapack). In this case LAPACK is >> compiled for libcruft with just "-O -mieee-fp" flags. >> >> Any suggestions? Is the problem in Octave or it's in LAPACK? How could I >> help for the resolving of this problem? >> >> > > the SLAMCH and DLAMCH routines are sensitive to compiler > optimizations. I use the settings (in make.inc from LAPACK tarball) > NOOPT = -mieee-fp -ffloat-store -fPIC > and it works well. I think that in future releases these routines will > be replaced by querying Fortran 90 internals. > > hth > > Hello, Thank you for this suggestion. These compilation flags ultimately solved the problem. Octave now works perfectly on Slackware 13.0 with system's LAPACK. Kind Regards, -- *Georgi D. Sotirov* Software Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091104/df2a533b/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091104/df2a533b/attachment.bin From hjunes at gmail.com Wed Nov 4 01:49:29 2009 From: hjunes at gmail.com (Heikki Johannes Junes) Date: Wed, 4 Nov 2009 09:49:29 +0200 Subject: PDF printing creates empty pages around the actual output In-Reply-To: <4A958A7B.3050408@gmx.net> References: <33cf4bba0908240307ka0cf8y541d9287028f9ba0@mail.gmail.com> <4A92EDE0.1010504@gmx.net> <4A958A7B.3050408@gmx.net> Message-ID: <33cf4bba0911032349q34bb992cs96c2ea3ada4d0117@mail.gmail.com> 2009/8/26 Benjamin Lindner > Benjamin Lindner wrote: > >> Heikki Johannes Junes wrote: >> >>> PDF printing creates empty pages around the actual output. >>> Steps to reproduce: >>> >>> plot(sin(0:0.1:10)); >>> print(gcf,'test.pdf','-dpdf'); >>> >>> The generated PDF output has >>> - empty page 1, >>> - plot in page 2, and >>> - empty page 3. >>> >>> The empty pages should not be there. >>> This is the only bug that prevents me shifting from 3.0.5 to 3.2.2. >>> >> >> This is a bug in gnuplot which is fixed in gnuplot's CVS but not yet in >> any released version. >> > > I stand corrected. There *is* a new CVS snapshot available which I did not > realize. It contains the fix for the cairopdf terminal removing the reported > bug. > > I updated to the new snapshot and it will be included in the next > octave/mingw32 release. > I have installed the new MinGW installation of Octave 3.2.3. It does not contain the above bug anymore. Accordingly, I can now switch from Octave 3.0.5 to Octave 3.2.3 :) Best wishes, Heikki -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091104/e1f10233/attachment-0001.html From gdsotirov at dir.bg Wed Nov 4 02:09:46 2009 From: gdsotirov at dir.bg (Georgi D. Sotirov) Date: Wed, 04 Nov 2009 10:09:46 +0200 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <1257184471.3934.1.camel@sh-t400> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> <19183.549.952812.823846@segfault.lan> <69d8d540911020911r6287f8b0r977776f582b5f41f@mail.gmail.com> <1257184471.3934.1.camel@sh-t400> Message-ID: <4AF136CA.9000005@dir.bg> S?ren Hauberg wrote: > man, 02 11 2009 kl. 18:11 +0100, skrev Jaroslav Hajek: > >> I think the BLAS and LAPACK are a little special in the sense that >> they're (AFAIK) the only strong requirement for Octave. If any other >> dependency is missing, Octave will build and work, though with some >> crippled functionality. >> OTOH, BLAS and LAPACK are now almost universally available, so maybe >> nobody actually needs this feature. In that case, I think it's fine to >> drop these sources. It will also plausibly reduce Octave's code size. >> > > One advantage of dropping BLAS and LAPACK from the sources is that the > user don't end up using these by accident instead of using the system > libraries. > > S?ren > > Hello, Wow, I didn't thought that my thread will trigger such discussion. Anyway, as software developer and Slackware package builder, I think the best is to use system libraries, even a bit harder in cases like this one. This gives even better flexibility to a redistributable packages as Octave. Best Regards, -- *Georgi D. Sotirov* Software Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091104/0df05299/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091104/0df05299/attachment-0001.bin From mikulik at physics.muni.cz Wed Nov 4 09:33:26 2009 From: mikulik at physics.muni.cz (Petr Mikulik) Date: Wed, 4 Nov 2009 16:33:26 +0100 (CET) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <20091104002719.45779.qmail@web3804.mail.bbt.yahoo.co.jp> References: <20091104002719.45779.qmail@web3804.mail.bbt.yahoo.co.jp> Message-ID: > > | Isn't the stdout of gnuplot redirected to /dev/null? > > I do not know for octave 3.0.x. At least, octave 3.2.x or later uses bidirectional pipes to > communicate with gnuplot. > > If you would like you use dumb terminal octave 3.2 or later, you should modify gnuplot_drawnow.m. Thanks for the hint. It was necesary to "set output '/dev/stderr'". Now the dumb plot works, see the enclosed patch. Does it work also on Windows? > Error: terminal "dumb" does not support continuous colors. It's just a warning, it has been removed recently. --- PM -------------- next part -------------- A non-text attachment was scrubbed... Name: dumb01.diff Type: text/x-diff Size: 2073 bytes Desc: Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091104/24605ebc/attachment.bin From jwe at octave.org Wed Nov 4 10:09:22 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 11:09:22 -0500 Subject: qr decomposition fails for certain matrices In-Reply-To: <69d8d540911040128k3f243075g2f675489beec18ad@mail.gmail.com> References: <20091103204445.GA30518@hephaistos.amsuess.com> <19184.43462.342573.115713@segfault.lan> <69d8d540911040128k3f243075g2f675489beec18ad@mail.gmail.com> Message-ID: <19185.42802.724752.516158@segfault.lan> On 4-Nov-2009, Jaroslav Hajek wrote: | I spent some time investigating this. Apparently the new xLARFP | routines are responsible for these problems. | These are described in the LAPACK working note 203: | http://www.netlib.org/lapack/lawnspdf/lawn203.pdf | | Specifically, on page 4, the text says: | | "Both imag(alpha)/gamma and norm(x)/gamma are less than one, so | abs(delta) <= abs(beta) and these computations introduce | no new overfl | ow possibilities into the existing routines." | | It seems to me that this is utterly wrong. Apparently delta = norm(x) | * (norm(x) / beta) can't overflow, but it can easily underflow if | norm(x) is a tiny number; hence subsequent division asks for problems. | A possible remedy is to split into two scalings, one by norm(x) and | one by norm(x)/beta - still, even norm(x)/beta alone can underflow. | | It seems to me that the goal of achieving beta >= 0 together with | keeping the leading one in the reflection vector is too ambitious. | | Something like the following patch fixes the worst of the problem, but | still doesn't solve everything. Just raise a(:,1) to second power in | your test matrix and you're back in XXX. Hmmm... Is this patch for the LAPACK 3.2.x sources? jwe From highegg at gmail.com Wed Nov 4 10:12:17 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 4 Nov 2009 17:12:17 +0100 Subject: qr decomposition fails for certain matrices In-Reply-To: <19185.42802.724752.516158@segfault.lan> References: <20091103204445.GA30518@hephaistos.amsuess.com> <19184.43462.342573.115713@segfault.lan> <69d8d540911040128k3f243075g2f675489beec18ad@mail.gmail.com> <19185.42802.724752.516158@segfault.lan> Message-ID: <69d8d540911040812x3efe79e0mf3d3593c5c2e04cc@mail.gmail.com> On Wed, Nov 4, 2009 at 5:09 PM, John W. Eaton wrote: > On ?4-Nov-2009, Jaroslav Hajek wrote: > > | I spent some time investigating this. Apparently the new xLARFP > | routines are responsible for these problems. > | These are described in the LAPACK working note 203: > | http://www.netlib.org/lapack/lawnspdf/lawn203.pdf > | > | Specifically, on page 4, the text says: > | > | "Both imag(alpha)/gamma and norm(x)/gamma are less than one, so > | abs(delta) <= abs(beta) and these computations introduce > | no new overfl > | ow possibilities into the existing routines." > | > | It seems to me that this is utterly wrong. Apparently delta = norm(x) > | * (norm(x) / beta) can't overflow, but it can easily underflow if > | norm(x) is a tiny number; hence subsequent division asks for problems. > | A possible remedy is to split into two scalings, one by norm(x) and > | one by norm(x)/beta - still, even norm(x)/beta alone can underflow. > | > | It seems to me that the goal of achieving beta >= 0 together with > | keeping the leading one in the reflection vector is too ambitious. > | > | Something like the following patch fixes the worst of the problem, but > | still doesn't solve everything. Just raise a(:,1) to second power in > | your test matrix and you're back in XXX. Hmmm... > > Is this patch for the LAPACK 3.2.x sources? > > Yes. But it's not correct, so don't use it. I'll post a correction later. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From jwe at octave.org Wed Nov 4 10:21:33 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 11:21:33 -0500 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <69d8d540911040220v5ea5e1cp5aac2aea003df272@mail.gmail.com> References: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> <408192.85650.qm@web112102.mail.gq1.yahoo.com> <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> <1257328541.3990.11.camel@sh-t400> <69d8d540911040220v5ea5e1cp5aac2aea003df272@mail.gmail.com> Message-ID: <19185.43533.887456.769578@segfault.lan> On 4-Nov-2009, Jaroslav Hajek wrote: | Similarly, I would very much like Octave to stay compilable by the | Intel C++ & Fortran compilers. Optional optimizations or tricks | specific to gcc are OK, but making gcc a requirement would IMHO be a | bad move. | | As Sergei noted, however, here the problem is not about Octave (or | LAPACK) becoming gcc-only, but rather the lack of a free | MSVC-compatible Fortran 90 compiler for the Windows platform. I do not intend to restrict Octave to a single compiler. But I would guess that there will eventually be some LAPACK features or bug fixes that will require LAPACK 3.2 or later, and that will mean you will have to somehow be able to build it if you want to take advantage of those features. I'm not sure how hard we should work to ensure that Octave can always be built with LAPACK 3.1, especially since there are free (as in speech) compilers that can build LAPACK 3.2. MSVC is not a free compiler, though some versions a distributed gratis. So I don't see why it is a problem that there is no free compiler that is compatible with MSVC. I mean, if you choose to use MSVC, then I think you should not be surprised that you have to use a non-free Fortran compiler with it. OTOH, is there any technical reason that gfortran can't be used with MSVC, or is it just that there are currently some problems that could be fixed? If it is the latter, then my recommendation would be to help find a way to fix the problems. jwe From michael.goffioul at gmail.com Wed Nov 4 10:48:04 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Wed, 4 Nov 2009 16:48:04 +0000 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <19185.43533.887456.769578@segfault.lan> References: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> <408192.85650.qm@web112102.mail.gq1.yahoo.com> <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> <1257328541.3990.11.camel@sh-t400> <69d8d540911040220v5ea5e1cp5aac2aea003df272@mail.gmail.com> <19185.43533.887456.769578@segfault.lan> Message-ID: <128f38bd0911040848k15ee4d24u1dabd1c9cd930bb8@mail.gmail.com> On Wed, Nov 4, 2009 at 4:21 PM, John W. Eaton wrote: > On ?4-Nov-2009, Jaroslav Hajek wrote: > > | Similarly, I would very much like Octave to stay compilable by the > | Intel C++ & Fortran compilers. Optional optimizations or tricks > | specific to gcc are OK, but making gcc a requirement would IMHO be a > | bad move. > | > | As Sergei noted, however, here the problem is not about Octave (or > | LAPACK) becoming gcc-only, but rather the lack of a free > | MSVC-compatible Fortran 90 compiler for the Windows platform. > > I do not intend to restrict Octave to a single compiler. ?But I would > guess that there will eventually be some LAPACK features or bug fixes > that will require LAPACK 3.2 or later, and that will mean you will > have to somehow be able to build it if you want to take advantage of > those features. ?I'm not sure how hard we should work to ensure that > Octave can always be built with LAPACK 3.1, especially since there are > free (as in speech) compilers that can build LAPACK 3.2. > > MSVC is not a free compiler, though some versions a distributed > gratis. ?So I don't see why it is a problem that there is no free > compiler that is compatible with MSVC. ?I mean, if you choose to use > MSVC, then I think you should not be surprised that you have to use a > non-free Fortran compiler with it. > > OTOH, is there any technical reason that gfortran can't be used with > MSVC, or is it just that there are currently some problems that could > be fixed? ?If it is the latter, then my recommendation would be to > help find a way to fix the problems. Trust me, I tried, but it simply does not work. If anyone is interested, he can give it a try. But to be honest, I don't want to invest any more time on Octave or trying to maintain the MSVC support. And it appears from the various reactions that nobody do want to make octave compilable with MSVC. My feeling is that the recent moves will make building octave natively under Windows utterly complex and that the only way to get octave under Windows will be with cygwin. Michael. From jwe at octave.org Wed Nov 4 11:08:21 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 12:08:21 -0500 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911040848k15ee4d24u1dabd1c9cd930bb8@mail.gmail.com> References: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> <408192.85650.qm@web112102.mail.gq1.yahoo.com> <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> <1257328541.3990.11.camel@sh-t400> <69d8d540911040220v5ea5e1cp5aac2aea003df272@mail.gmail.com> <19185.43533.887456.769578@segfault.lan> <128f38bd0911040848k15ee4d24u1dabd1c9cd930bb8@mail.gmail.com> Message-ID: <19185.46341.685324.23090@segfault.lan> On 4-Nov-2009, Michael Goffioul wrote: | Trust me, I tried, but it simply does not work. Did you ever report or discuss your problems with the gfortran maintainers? If so, is there an archive of the discussion somewhere that I could read so I could understand the issues? | If anyone is | interested, he can give it a try. But to be honest, I don't want to | invest any more time on Octave or trying to maintain the MSVC | support. And it appears from the various reactions that nobody do | want to make octave compilable with MSVC. I don't object to having Octave compilable with MSVC. But that is different from wanting to do the work to build binaries, or do the testing to ensure that things don't break. Making sure that Octave continues to build cleanly with MSVC is not a high priority for me, given that MSVC is not free software. So if there are no volunteers for that job, then yes, things will likely break. But if there are volunteers for that job, then I'm perfectly willing to work with them. | My feeling is that the recent moves will make building octave natively under | Windows utterly complex and that the only way to get octave under Windows | will be with cygwin. I don't think that's true. We are simmply talking about using a shell script to manage the complexity of building shared libraries. I don't see how that makes things "utterly complex". We already rely on many other shell scripts for other jobs when building Octave, and they did not seem to prevent building Octave for Windows in the past. jwe From marco_atzeri at yahoo.it Wed Nov 4 14:24:56 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Wed, 4 Nov 2009 20:24:56 +0000 (GMT) Subject: qr decomposition fails for certain matrices In-Reply-To: <69d8d540911040128k3f243075g2f675489beec18ad@mail.gmail.com> Message-ID: <886346.20733.qm@web25505.mail.ukl.yahoo.com> --- Mer 4/11/09, Jaroslav Hajek ha scritto: [cut] > I spent some time investigating this. Apparently the new > xLARFP > routines are responsible for these problems. > These are described in the LAPACK working note 203: > http://www.netlib.org/lapack/lawnspdf/lawn203.pdf > > Specifically, on page 4, the text says: > > "Both imag(alpha)/gamma and norm(x)/gamma are less than > one, so > abs(delta) <= abs(beta) and these computations > introduce > no new overfl > ow possibilities into the existing routines." > > It seems to me that this is utterly wrong. Apparently delta > = norm(x) > * (norm(x) / beta) can't overflow, but it can easily > underflow if > norm(x) is a tiny number; hence subsequent division asks > for problems. > A possible remedy is to split into two scalings, one by > norm(x) and > one by norm(x)/beta - still, even norm(x)/beta alone can > underflow. > > It seems to me that the goal of achieving beta >= 0 > together with > keeping the leading one in the reflection vector is too > ambitious. looks like (*) bug0037 :: xLARFP and scaling http://www.netlib.org/lapack/Errata/errata_3.2.1_20091001.html or not ? [cut] > > -- > RNDr. Jaroslav Hajek Regards Marco From tmacchant at yahoo.co.jp Thu Nov 5 02:10:20 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Thu, 5 Nov 2009 17:10:20 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: Message-ID: <20091105081023.24411.qmail@web3805.mail.bbt.yahoo.co.jp> Hello --- Petr Mikulik wrote: > Does it work also on Windows? Worked on only Cygwin. For octave mingw, it did not work simply because native windows no '/dev/stdrr' file device. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From mikulik at physics.muni.cz Thu Nov 5 06:10:00 2009 From: mikulik at physics.muni.cz (Petr Mikulik) Date: Thu, 5 Nov 2009 13:10:00 +0100 (CET) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <20091105081023.24411.qmail@web3805.mail.bbt.yahoo.co.jp> References: <20091105081023.24411.qmail@web3805.mail.bbt.yahoo.co.jp> Message-ID: > > Does it work also on Windows? > > Worked on only Cygwin. You mean gnuplot with x11 on cygwin? > For octave mingw, it did not work simply because native windows no > '/dev/stde rr' file device. Do you mean wgnuplot.exe or the new gnuplot.exe? Does Octave use communication via stdin also in Windows, e.g. "set print"? Should Octave do "unset print" before printing the dumb plot? In DOS times, it was possible to use device named "con:" for console output. Isn't there something similar for /dev/stderr? Is it Octave which eats the dumb output? Shouldn't it thus reprint the dumb output to screen instead of parsing this as gnuplot messages? --- PM From tmacchant at yahoo.co.jp Thu Nov 5 08:47:09 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Thu, 5 Nov 2009 23:47:09 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: Message-ID: <20091105144713.56139.qmail@web3813.mail.bbt.yahoo.co.jp> Hello --- Petr Mikulik wrote: > > > Does it work also on Windows? > > > > Worked on only Cygwin. > > You mean gnuplot with x11 on cygwin? Yes. However, why it would get successful result on Cygwin because Cygwin has '/dev/stderr'. > > For octave mingw, it did not work simply because native windows no > > '/dev/stde rr' file device. > > Do you mean wgnuplot.exe or the new gnuplot.exe? Of cource gnuplot.exe on cvs trees. Old type pgnuplot is no longer used from octave 2.9.1? or later. > Does Octave use communication via stdin also in Windows, e.g. "set print"? > Should Octave do "unset print" before printing the dumb plot? > > In DOS times, it was possible to use device named "con:" for console output. > Isn't there something similar for /dev/stderr? To my knowledge, it does not exist. But someone might know > Is it Octave which eats the dumb output? Shouldn't it thus reprint the dumb > output to screen instead of parsing this as gnuplot messages? Octave uses bidirectional pipes so that it may be possible to get information from gnuplot output. But I do not know how it will be realized. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From mikulik at physics.muni.cz Thu Nov 5 10:13:26 2009 From: mikulik at physics.muni.cz (Petr Mikulik) Date: Thu, 5 Nov 2009 17:13:26 +0100 (CET) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <20091105144713.56139.qmail@web3813.mail.bbt.yahoo.co.jp> References: <20091105144713.56139.qmail@web3813.mail.bbt.yahoo.co.jp> Message-ID: > > In DOS times, it was possible to use device named "con:" for console output. > > Isn't there something similar for /dev/stderr? > To my knowledge, it does not exist. But someone might know Hm, it seems that in Mingw's C, there is FILE *stderr, but you cannot do fopen("/dev/stderr") (unless run inside cygwin's bash?). > > Is it Octave which eats the dumb output? Shouldn't it thus reprint the dumb > > output to screen instead of parsing this as gnuplot messages? > Octave uses bidirectional pipes so that it may be possible to get > information from gnuplot output. Who knows how to do it? --- PM From Onu at UIUC.EDU Thu Nov 5 11:54:06 2009 From: Onu at UIUC.EDU (Kristjan Onu) Date: Thu, 5 Nov 2009 11:54:06 -0600 Subject: Plot window "dies" with fontsize 14 when using an axis label with a superscript construct Message-ID: <20091105175405.GA12246@Levy.AE.UIUC.EDU> Bug report for Octave 3.2.3 configured for i486-pc-linux-gnu Description: ----------- When I run the file attached, the plot window closes unexpectedly due to the command on line 11. I can avoid this problem by not setting the fontsize to 14 (13 & 15 are OK), or by avoiding the "^2" construct. For example replacing line 11 with ylabel("y"), I see no problem. Note that with the development sources (changeset 9779:2941c1daf509) I observe the same problem. I first reported this bug on the Debian bug tracking system (http://bugs.debian.org/554191), but since I've now reproduced the problem with the Octave development sources, I think it's appropriate to report it as an Octave bug. Repeat-By: --------- $ octave3.2 -f ... octave3.2:1> plot_bug Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux Levy 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 i686 GNU/Linux configure opts: '--build=i486-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=i486-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' Fortran compiler: gfortran FFLAGS: -O2 -g FLIBS: -lgfortranbegin -lgfortran CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.4 (Debian 4.3.4-5) CFLAGS: -O2 -g CPICFLAG: -fPIC C++ compiler: g++, version 4.3.4 CXXFLAGS: -O2 -g CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 BLAS_LIBS: -llapackgf-3 -lblas-3gf FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs -nw EXEC_PATH = /usr/lib/octave/3.2.3/site/exec/i486-pc-linux-gnu:/usr/lib/octave/api-v37/site/exec/i486-pc-linux-gnu:/usr/lib/octave/site/exec/i486-pc-linux-gnu:/usr/lib/octave/3.2.3/exec/i486-pc-linux-gnu:/usr/bin:/home/k/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib PAGER = pager PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/k/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave3.2.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 1 page_screen_output = 0 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 -------------- next part -------------- function plot_bug x = 0:10; y = x.^2; figure a1 = axes; set(a1,"fontsize",14) plot(x,y) xlabel("x") ylabel("x^2") endfunction From jwe at octave.org Thu Nov 5 12:46:02 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 5 Nov 2009 13:46:02 -0500 Subject: Plot window "dies" with fontsize 14 when using an axis label with a superscript construct In-Reply-To: <20091105175405.GA12246@Levy.AE.UIUC.EDU> References: <20091105175405.GA12246@Levy.AE.UIUC.EDU> Message-ID: <19187.7530.804429.967957@segfault.lan> On 5-Nov-2009, Kristjan Onu wrote: | Bug report for Octave 3.2.3 configured for i486-pc-linux-gnu | | Description: | ----------- | | When I run the file attached, the plot window closes unexpectedly due | to the command on line 11. I can avoid this problem by not setting the | fontsize to 14 (13 & 15 are OK), or by avoiding the "^2" construct. | For example replacing line 11 with ylabel("y"), I see no problem. | | Note that with the development sources (changeset 9779:2941c1daf509) I | observe the same problem. | | I first reported this bug on the Debian bug tracking system | (http://bugs.debian.org/554191), but since I've now reproduced the | problem with the Octave development sources, I think it's appropriate | to report it as an Octave bug. | | Repeat-By: | --------- | | $ octave3.2 -f | ... | octave3.2:1> plot_bug I can't duplicate this problem with 3.2.3 or the current sources, also on a Debian system. What version of gnuplot do you have? I have 4.2.6. If you'd like to debug further, I recommend trying the following: * run your plot function * execute the command drawnow ("x11", "/dev/null", 0, "debug.gp"); * quit Octave * start gnuplot and execute the following command load "debug.gp" Do you also see the same problem there? If so, then the problemm is likely a gnuplot bug. jwe From bpabbott at mac.com Thu Nov 5 12:57:22 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 05 Nov 2009 13:57:22 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <27890685913295548502052032932291492684-Webmail@me.com> References: <27890685913295548502052032932291492684-Webmail@me.com> Message-ID: <116882845175507996186716634374360538589-Webmail@me.com> On Thursday, November 05, 2009, at 11:13AM, "Petr Mikulik" wrote: >> > In DOS times, it was possible to use device named "con:" for console output. >> > Isn't there something similar for /dev/stderr? >> To my knowledge, it does not exist. But someone might know > >Hm, it seems that in Mingw's C, there is FILE *stderr, but you cannot do >fopen("/dev/stderr") (unless run inside cygwin's bash?). > >> > Is it Octave which eats the dumb output? Shouldn't it thus reprint the dumb >> > output to screen instead of parsing this as gnuplot messages? >> Octave uses bidirectional pipes so that it may be possible to get >> information from gnuplot output. > >Who knows how to do it? Take a look at __gnuplot_get_var__.m http://hg.savannah.gnu.org/hgweb/octave/file/2941c1daf509/scripts/plot/__gnuplot_get_var__.m Perhaps "replot" can be sent to gnuplot, the resulting output obtained using the same approach as in __gnuplot_get_var__? Ben From Onu at UIUC.EDU Thu Nov 5 13:52:39 2009 From: Onu at UIUC.EDU (Kristjan Onu) Date: Thu, 5 Nov 2009 13:52:39 -0600 Subject: Plot window "dies" with fontsize 14 when using an axis label with a superscript construct In-Reply-To: <19187.7530.804429.967957@segfault.lan> References: <20091105175405.GA12246@Levy.AE.UIUC.EDU> <19187.7530.804429.967957@segfault.lan> Message-ID: <20091105195239.GA30180@Levy.AE.UIUC.EDU> On Thu, Nov 05, 2009 at 01:46:02PM -0500, John W. Eaton wrote: > On 5-Nov-2009, Kristjan Onu wrote: > > | Bug report for Octave 3.2.3 configured for i486-pc-linux-gnu > | > | Description: > | ----------- > | > | When I run the file attached, the plot window closes unexpectedly due > | to the command on line 11. I can avoid this problem by not setting the > | fontsize to 14 (13 & 15 are OK), or by avoiding the "^2" construct. > | For example replacing line 11 with ylabel("y"), I see no problem. > | > | Note that with the development sources (changeset 9779:2941c1daf509) I > | observe the same problem. > | > | I first reported this bug on the Debian bug tracking system > | (http://bugs.debian.org/554191), but since I've now reproduced the > | problem with the Octave development sources, I think it's appropriate > | to report it as an Octave bug. > | > | Repeat-By: > | --------- > | > | $ octave3.2 -f > | ... > | octave3.2:1> plot_bug > > I can't duplicate this problem with 3.2.3 or the current sources, also > on a Debian system. > > What version of gnuplot do you have? I have 4.2.6. $ apt-cache policy gnuplot gnuplot: Installed: 4.2.6-1 Candidate: 4.2.6-1 Version table: *** 4.2.6-1 0 990 ftp://debian.cites.uiuc.edu testing/main Packages 500 ftp://debian.cites.uiuc.edu unstable/main Packages 100 /var/lib/dpkg/status > If you'd like to debug further, I recommend trying the following: > > * run your plot function > > * execute the command > > drawnow ("x11", "/dev/null", 0, "debug.gp"); > > * quit Octave > > * start gnuplot and execute the following command > > load "debug.gp" > > > Do you also see the same problem there? If so, then the problemm is > likely a gnuplot bug. Thanks very much for giving me that sequence of commands. I see the problem with gnuplot alone as well. On line 25 of debug.gp (attached), changing the fontsize from 14 to 13, the problem goes away. I have filed a bug with Debian bug tracking system for gnuplot: http://bugs.debian.org/554629 -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.gp Type: application/octet-stream Size: 3002 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091105/d9c15af8/attachment.obj From pr.nienhuis at hccnet.nl Thu Nov 5 16:22:37 2009 From: pr.nienhuis at hccnet.nl (Philip Nienhuis) Date: Thu, 05 Nov 2009 23:22:37 +0100 Subject: Unexpected results when adding & removing fields to empty structs Message-ID: <4AF3502D.4050400@hccnet.nl> Adding fields to empty structs doesn't seem to work: octave-3.2.3.exe: #1 > aa = struct("field1", {}) aa = { 0x0 struct array containing the fields: field1 } octave-3.2.3.exe: #2 > [aa.field2] = {} aa = { 0x0 struct array containing the fields: field1 } ===> No field2 to be seen in struct aa (This works OK on Matlab r2007a, if that's any reference :-) ) .....while..... octave-3.2.3.exe: #3 > cc = struct("field1", {}) cc = { 0x0 struct array containing the fields: field1 } octave-3.2.3.exe: #4 > [cc(1).field2]= {} cc = { field1 = [](0x0) field2 = {}(0x0) } but now the fields contain (empty) values. Note that field1 has been "extended" with [] rather than {}. I suppose this last example is intended behavior as adding elements to all fields in a struct (extending the "field size") always goes like (at least on my box) struct(size(struct, 2) + 1).a_field = {anything} where field1 was initially empty (zero size) but an (empty) element was added implicitly due to the operation of adding another field. But: octave-3.2.3.exe: #5 > [cc.field3]= {} cc = { field1 = [](0x0) field2 = {}(0x0) field3 = {}(0x0) } octave-3.2.3.exe: #7 > [cc(1).field4]= {} cc = { field1 = [](0x0) field2 = {}(0x0) field3 = {}(0x0) field4 = {}(0x0) } where the layout seems to be mixed up. Furthermore, continuing with cc: octave-3.2.3.exe: #8 > rmfield(cc, "field3") ans = { field1 = [](0x0) field2 = {}(0x0) field4 = {}(0x0) } octave-3.2.3.exe: #9 > rmfield(cc, "field2") ans = { field1 = [](0x0) field3 = {}(0x0) field4 = {}(0x0) } octave-3.2.3.exe: #10 > rmfield(cc, "field3") ans = { field1 = [](0x0) field2 = {}(0x0) field4 = {}(0x0) } where "field3" and "field2" magically but unintendedly reappear. On a related note (empty lines skipped for brevity): octave-3.2.3.exe: #93 > AA = struct() AA = { } octave-3.2.3.exe: #94 > size (AA) ans = 1 1 ## ?? octave-3.2.3.exe: #95 > isempty (AA) ans = 0 ## !! but in line with size(aa) === while ==== octave-3.2.3.exe: #96 > BB = struct("field1", {}) BB = { 0x0 struct array containing the fields: field1 } octave-3.2.3.exe: #97 > size (BB) ans = 0 0 ## !? octave-3.2.3.exe: #98 > isempty (BB) ans = 1 ## ?! again in line with size(bb) The results of size() and isempty() on AA and BB are IMO contrary to expectation. (But... fully Matlab r2007a-compatible!) Is this somehow logical (but beyond my sense for logic) or is it too far pursued Matlab compatibility? Thank you, Philip From thomas.weber.mail at gmail.com Thu Nov 5 23:32:53 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Fri, 6 Nov 2009 06:32:53 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <128f38bd0911040848k15ee4d24u1dabd1c9cd930bb8@mail.gmail.com> References: <128f38bd0911030345j1121f033vda78fc5aa6b0a96@mail.gmail.com> <408192.85650.qm@web112102.mail.gq1.yahoo.com> <128f38bd0911031239h7d14548btd9dd8f15cd60b03@mail.gmail.com> <1257328541.3990.11.camel@sh-t400> <69d8d540911040220v5ea5e1cp5aac2aea003df272@mail.gmail.com> <19185.43533.887456.769578@segfault.lan> <128f38bd0911040848k15ee4d24u1dabd1c9cd930bb8@mail.gmail.com> Message-ID: <20091106053253.GA5681@atlan> On Wed, Nov 04, 2009 at 04:48:04PM +0000, Michael Goffioul wrote: > On Wed, Nov 4, 2009 at 4:21 PM, John W. Eaton wrote: > > On ?4-Nov-2009, Jaroslav Hajek wrote: > > > > | Similarly, I would very much like Octave to stay compilable by the > > | Intel C++ & Fortran compilers. Optional optimizations or tricks > > | specific to gcc are OK, but making gcc a requirement would IMHO be a > > | bad move. > > | > > | As Sergei noted, however, here the problem is not about Octave (or > > | LAPACK) becoming gcc-only, but rather the lack of a free > > | MSVC-compatible Fortran 90 compiler for the Windows platform. > > > > I do not intend to restrict Octave to a single compiler. ?But I would > > guess that there will eventually be some LAPACK features or bug fixes > > that will require LAPACK 3.2 or later, and that will mean you will > > have to somehow be able to build it if you want to take advantage of > > those features. ?I'm not sure how hard we should work to ensure that > > Octave can always be built with LAPACK 3.1, especially since there are > > free (as in speech) compilers that can build LAPACK 3.2. > > > > MSVC is not a free compiler, though some versions a distributed > > gratis. ?So I don't see why it is a problem that there is no free > > compiler that is compatible with MSVC. ?I mean, if you choose to use > > MSVC, then I think you should not be surprised that you have to use a > > non-free Fortran compiler with it. > > > > OTOH, is there any technical reason that gfortran can't be used with > > MSVC, or is it just that there are currently some problems that could > > be fixed? ?If it is the latter, then my recommendation would be to > > help find a way to fix the problems. > > Trust me, I tried, but it simply does not work. If anyone is interested, he can > give it a try. But to be honest, I don't want to invest any more time on Octave > or trying to maintain the MSVC support. And it appears from the various > reactions that nobody do want to make octave compilable with MSVC. Why is Octave at fault when LAPACK's upstream changes its requirements? Thomas From mikulik at physics.muni.cz Fri Nov 6 03:11:04 2009 From: mikulik at physics.muni.cz (Petr Mikulik) Date: Fri, 6 Nov 2009 10:11:04 +0100 (CET) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <116882845175507996186716634374360538589-Webmail@me.com> References: <27890685913295548502052032932291492684-Webmail@me.com> <116882845175507996186716634374360538589-Webmail@me.com> Message-ID: > >Hm, it seems that in Mingw's C, there is FILE *stderr, but you cannot do > >fopen("/dev/stderr") (unless run inside cygwin's bash?). > > > >> > Is it Octave which eats the dumb output? > >> > output to screen instead of parsing this as gnuplot messages? > >> Octave uses bidirectional pipes so that it may be possible to get > >> information from gnuplot output. > > Take a look at __gnuplot_get_var__.m So it's popen2("gnuplot") which eats the stdout. The approach of __gnuplot_get_var__.m is too complicated and it uses mkfifo which may not work everywhere. Using temporary file is much more easy and transparent. Enclosed is a patch of gnuplot_drawnow.m for which GNUTERM=dumb octave should work everywhere. Please test it and commit if OK. --- Petr Mikulik -------------- next part -------------- A non-text attachment was scrubbed... Name: dumb02.diff Type: text/x-diff Size: 2950 bytes Desc: Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091106/36d6104e/attachment.bin From highegg at gmail.com Fri Nov 6 03:31:17 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 6 Nov 2009 10:31:17 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <4AF3502D.4050400@hccnet.nl> References: <4AF3502D.4050400@hccnet.nl> Message-ID: <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> On Thu, Nov 5, 2009 at 11:22 PM, Philip Nienhuis wrote: > > > > Adding fields to empty structs doesn't seem to work: > > octave-3.2.3.exe: #1 > aa = struct("field1", {}) > aa = > { > ? 0x0 struct array containing the fields: > > ? ? field1 > } > > octave-3.2.3.exe: #2 > [aa.field2] = {} > aa = > { > ? 0x0 struct array containing the fields: > > ? ? field1 > } > > ===> No field2 to be seen in struct aa > (This works OK on Matlab r2007a, if that's any reference :-) ) > [aa.field2] when aa is sempty resolves to an empty cs-list, so there's nothing to assign (excess rhs values are discarded). Apparently Matlab carries out the empty assignments for possible side effects, while Octave simply skips them. For compatibility, here's a patch: > .....while..... > > octave-3.2.3.exe: #3 > cc = struct("field1", {}) > cc = > { > ? 0x0 struct array containing the fields: > > ? ? field1 > } > > octave-3.2.3.exe: #4 > [cc(1).field2]= {} > cc = > { > ? field1 = [](0x0) > ? field2 = {}(0x0) > } > > but now the fields contain (empty) values. Note that field1 has been > "extended" with [] rather than {}. > I suppose this last example is intended behavior as adding elements to > all fields in a struct (extending the "field size") always goes like (at > least on my box) > ? ? ? ? ?struct(size(struct, 2) + 1).a_field = {anything} > where field1 was initially empty (zero size) but an (empty) element was > added implicitly due to the operation of adding another field. > Yep, that is correct. > But: > > octave-3.2.3.exe: #5 > [cc.field3]= {} > cc = > { > ? field1 = [](0x0) > ? field2 = {}(0x0) > field3 = {}(0x0) > } > > octave-3.2.3.exe: #7 > [cc(1).field4]= {} > cc = > { > ? field1 = [](0x0) > ? field2 = {}(0x0) > field3 = {}(0x0) > field4 = {}(0x0) > } > > where the layout seems to be mixed up. Another bug. See > Furthermore, continuing with cc: > > octave-3.2.3.exe: #8 > rmfield(cc, "field3") > ans = > { > ? field1 = [](0x0) > ? field2 = {}(0x0) > field4 = {}(0x0) > } > > octave-3.2.3.exe: #9 > rmfield(cc, "field2") > ans = > { > ? field1 = [](0x0) > ? field3 = {}(0x0) > field4 = {}(0x0) > } > > octave-3.2.3.exe: #10 > rmfield(cc, "field3") > ans = > { > ? field1 = [](0x0) > ? field2 = {}(0x0) > field4 = {}(0x0) > } > where "field3" and "field2" magically but unintendedly reappear. > This is a mix-up of the "your ignorance" case and Octave's sometimes too succint documentation. While the docstring for rmfield might give you the impression that rmfield(cc, "field3") removes the field3 from cc, but this is not true. Remember (and this is written in the manual) that Octave functions, be them built-in or user scripts, *never* alter their arguments. There is no passing by reference. When you pass a variable as a function argument, it behaves *as if* a copy was made for all the values (in reality it's a lazy copy). This very simple and natural scheme frees the Matlab language of the object ownership problems seen, for instance, in Python or C#, at the cost of sometimes sacrificing memory efficiency. rmfield does, in fact take a copy of the argument, remove the named field from that copy and return the result, so cc = rmfield (cc, "field3"); is what you want. In the docstrings this is often not emphasized because it's assumed to be a general principle. > > On a related note (empty lines skipped for brevity): > > octave-3.2.3.exe: #93 > AA = struct() > AA = > { > } > octave-3.2.3.exe: #94 > size (AA) > ans = > ? ?1 ? 1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ## ?? > octave-3.2.3.exe: #95 > isempty (AA) > ans = 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?## !! but in line with size(aa) > > ? ?=== while ==== > > octave-3.2.3.exe: #96 > BB = struct("field1", {}) > BB = > { > ? 0x0 struct array containing the fields: > ? ? field1 > } > octave-3.2.3.exe: #97 > size (BB) > ans = > ? ?0 ? 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ## !? > octave-3.2.3.exe: #98 > isempty (BB) > ans = ?1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ## ?! again in line with size(bb) > > The results of size() and isempty() on AA and BB are IMO contrary to > expectation. (But... fully Matlab r2007a-compatible!) > > Is this somehow logical (but beyond my sense for logic) or is it too far > pursued Matlab compatibility? > It's logical. isempty simply tests whether any dimension is zero; it doesn't test for the number of fields. Structs with no fields are not much useful anyway, so I'd expect them to be very rare. > > Thank you, > > Philip > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Fri Nov 6 03:34:17 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 6 Nov 2009 10:34:17 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> Message-ID: <69d8d540911060134w60982f73w97139a16c1b047fc@mail.gmail.com> On Fri, Nov 6, 2009 at 10:31 AM, Jaroslav Hajek wrote: > On Thu, Nov 5, 2009 at 11:22 PM, Philip Nienhuis wrote: >> > >> >> >> Adding fields to empty structs doesn't seem to work: >> >> octave-3.2.3.exe: #1 > aa = struct("field1", {}) >> aa = >> { >> ? 0x0 struct array containing the fields: >> >> ? ? field1 >> } >> >> octave-3.2.3.exe: #2 > [aa.field2] = {} >> aa = >> { >> ? 0x0 struct array containing the fields: >> >> ? ? field1 >> } >> >> ===> No field2 to be seen in struct aa >> (This works OK on Matlab r2007a, if that's any reference :-) ) >> > > [aa.field2] when aa is sempty resolves to an empty cs-list, so there's > nothing to assign (excess rhs values are discarded). Apparently Matlab > carries out the empty assignments for possible side effects, while > Octave simply skips them. For compatibility, here's a patch: > >> .....while..... >> >> octave-3.2.3.exe: #3 > cc = struct("field1", {}) >> cc = >> { >> ? 0x0 struct array containing the fields: >> >> ? ? field1 >> } >> >> octave-3.2.3.exe: #4 > [cc(1).field2]= {} >> cc = >> { >> ? field1 = [](0x0) >> ? field2 = {}(0x0) >> } >> >> but now the fields contain (empty) values. Note that field1 has been >> "extended" with [] rather than {}. >> I suppose this last example is intended behavior as adding elements to >> all fields in a struct (extending the "field size") always goes like (at >> least on my box) >> ? ? ? ? ?struct(size(struct, 2) + 1).a_field = {anything} >> where field1 was initially empty (zero size) but an (empty) element was >> added implicitly due to the operation of adding another field. >> > > Yep, that is correct. > >> But: >> >> octave-3.2.3.exe: #5 > [cc.field3]= {} >> cc = >> { >> ? field1 = [](0x0) >> ? field2 = {}(0x0) >> field3 = {}(0x0) >> } >> >> octave-3.2.3.exe: #7 > [cc(1).field4]= {} >> cc = >> { >> ? field1 = [](0x0) >> ? field2 = {}(0x0) >> field3 = {}(0x0) >> field4 = {}(0x0) >> } >> >> where the layout seems to be mixed up. > > Another bug. > See > > >> Furthermore, continuing with cc: >> >> octave-3.2.3.exe: #8 > rmfield(cc, "field3") >> ans = >> { >> ? field1 = [](0x0) >> ? field2 = {}(0x0) >> field4 = {}(0x0) >> } >> >> octave-3.2.3.exe: #9 > rmfield(cc, "field2") >> ans = >> { >> ? field1 = [](0x0) >> ? field3 = {}(0x0) >> field4 = {}(0x0) >> } >> >> octave-3.2.3.exe: #10 > rmfield(cc, "field3") >> ans = >> { >> ? field1 = [](0x0) >> ? field2 = {}(0x0) >> field4 = {}(0x0) >> } >> where "field3" and "field2" magically but unintendedly reappear. >> > > This is a mix-up of the "your ignorance" case and Octave's sometimes > too succint documentation. While the docstring for rmfield might give > you the impression that > rmfield(cc, "field3") > removes the field3 from cc, but this is not true. Remember (and this > is written in the manual) that Octave functions, be them built-in or > user scripts, *never* alter their arguments. There is no passing by > reference. When you pass a variable as a function argument, it behaves > *as if* a copy was made for all the values (in reality it's a lazy > copy). This very simple and natural scheme frees the Matlab language > of the object ownership problems seen, for instance, in Python or C#, > at the cost of sometimes sacrificing memory efficiency. > > rmfield does, in fact take a copy of the argument, remove the named > field from that copy and return the result, so > cc = rmfield (cc, "field3"); > is what you want. In the docstrings this is often not emphasized > because it's assumed to be a general principle. > >> >> On a related note (empty lines skipped for brevity): >> >> octave-3.2.3.exe: #93 > AA = struct() >> AA = >> { >> } >> octave-3.2.3.exe: #94 > size (AA) >> ans = >> ? ?1 ? 1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ## ?? >> octave-3.2.3.exe: #95 > isempty (AA) >> ans = 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?## !! but in line with size(aa) >> >> ? ?=== while ==== >> >> octave-3.2.3.exe: #96 > BB = struct("field1", {}) >> BB = >> { >> ? 0x0 struct array containing the fields: >> ? ? field1 >> } >> octave-3.2.3.exe: #97 > size (BB) >> ans = >> ? ?0 ? 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ## !? >> octave-3.2.3.exe: #98 > isempty (BB) >> ans = ?1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ## ?! again in line with size(bb) >> >> The results of size() and isempty() on AA and BB are IMO contrary to >> expectation. (But... fully Matlab r2007a-compatible!) >> >> Is this somehow logical (but beyond my sense for logic) or is it too far >> pursued Matlab compatibility? >> > > It's logical. isempty simply tests whether any dimension is zero; it > doesn't test for the number of fields. Structs with no fields are not > much useful anyway, so I'd expect them to be very rare. > >> >> Thank you, >> >> Philip >> _______________________________________________ >> Bug-octave mailing list >> Bug-octave at octave.org >> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave >> > > > > -- > RNDr. Jaroslav Hajek > computing expert & GNU Octave developer > Aeronautical Research and Test Institute (VZLU) > Prague, Czech Republic > url: www.highegg.matfyz.cz > Oops, I forgot to hyperlink the patches: http://hg.savannah.gnu.org/hgweb/octave/rev/eead00a7df05 http://hg.savannah.gnu.org/hgweb/octave/rev/ea88eece12f5 regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Fri Nov 6 06:23:48 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 6 Nov 2009 13:23:48 +0100 Subject: qr decomposition fails for certain matrices In-Reply-To: <886346.20733.qm@web25505.mail.ukl.yahoo.com> References: <69d8d540911040128k3f243075g2f675489beec18ad@mail.gmail.com> <886346.20733.qm@web25505.mail.ukl.yahoo.com> Message-ID: <69d8d540911060423r73b5145eiea8a16034f3b48e7@mail.gmail.com> On Wed, Nov 4, 2009 at 9:24 PM, Marco Atzeri wrote: > > > --- Mer 4/11/09, Jaroslav Hajek ha scritto: > > [cut] > >> I spent some time investigating this. Apparently the new >> xLARFP >> routines are responsible for these problems. >> These are described in the LAPACK working note 203: >> http://www.netlib.org/lapack/lawnspdf/lawn203.pdf >> >> Specifically, on page 4, the text says: >> >> "Both imag(alpha)/gamma and norm(x)/gamma are less than >> one, so >> abs(delta) <= abs(beta) and these computations >> introduce >> no new overfl >> ow possibilities into the existing routines." >> >> It seems to me that this is utterly wrong. Apparently delta >> = norm(x) >> * (norm(x) / beta) can't overflow, but it can easily >> underflow if >> norm(x) is a tiny number; hence subsequent division asks >> for problems. >> A possible remedy is to split into two scalings, one by >> norm(x) and >> one by norm(x)/beta - still, even norm(x)/beta alone can >> underflow. >> >> It seems to me that the goal of achieving beta >= 0 >> together with >> keeping the leading one in the reflection vector is too >> ambitious. > > looks like (*) bug0037 :: xLARFP and scaling > http://www.netlib.org/lapack/Errata/errata_3.2.1_20091001.html > or not ? > Probably yes. It's marked as fixed in 3.2.2, so no need for me to try (at least until I see their solution). For anyone interested, here's a patch that simply forwards xLARFP to the old xLARFG that can be used to patch 3.2.1. Of course this brings back the old behavior of qr not yielding nonnegative diagonals. diff --git a/clarfp.f b/clarfp.f --- a/clarfp.f +++ b/clarfp.f @@ -80,6 +80,8 @@ * .. * .. Executable Statements .. * + CALL CLARFG( N, ALPHA, X, INCX, TAU ) + IF( N.LE.0 ) THEN TAU = ZERO RETURN diff --git a/dlarfp.f b/dlarfp.f --- a/dlarfp.f +++ b/dlarfp.f @@ -79,6 +79,8 @@ * .. * .. Executable Statements .. * + CALL DLARFG( N, ALPHA, X, INCX, TAU ) + IF( N.LE.0 ) THEN TAU = ZERO RETURN diff --git a/slarfp.f b/slarfp.f --- a/slarfp.f +++ b/slarfp.f @@ -79,6 +79,8 @@ * .. * .. Executable Statements .. * + CALL SLARFG( N, ALPHA, X, INCX, TAU ) + IF( N.LE.0 ) THEN TAU = ZERO RETURN diff --git a/zlarfp.f b/zlarfp.f --- a/zlarfp.f +++ b/zlarfp.f @@ -80,6 +80,8 @@ * .. * .. Executable Statements .. * + CALL ZLARFG( N, ALPHA, X, INCX, TAU ) + IF( N.LE.0 ) THEN TAU = ZERO RETURN -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From marco_atzeri at yahoo.it Fri Nov 6 06:51:03 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Fri, 6 Nov 2009 12:51:03 +0000 (GMT) Subject: qr decomposition fails for certain matrices In-Reply-To: <69d8d540911060423r73b5145eiea8a16034f3b48e7@mail.gmail.com> Message-ID: <489798.14591.qm@web25508.mail.ukl.yahoo.com> --- Ven 6/11/09, Jaroslav Hajek ha scritto: > > > > looks like (*) bug0037 :: xLARFP and scaling > > http://www.netlib.org/lapack/Errata/errata_3.2.1_20091001.html > > or not ? > > > > Probably yes. It's marked as fixed in 3.2.2, so no need for > me to try > (at least until I see their solution). in reality it is reported as "Bug reports -- bug needs to be confirmed!" so no solution is yet available. So you are free to offer yours > > -- > RNDr. Jaroslav Hajek Marco From slask at paulsundvall.net Fri Nov 6 06:54:15 2009 From: slask at paulsundvall.net (Paul Sundvall) Date: Fri, 06 Nov 2009 13:54:15 +0100 Subject: misleading documentation for ferror Message-ID: <4AF41C77.4020306@paulsundvall.net> Hi! The help for the builtin ferror function claims "Return 1 if an error condition has been encountered for a given file and 0 otherwise" The implementation however seems to behave just like matlab does. Also, the second (optional) input parameter is not documented. I suggest the following help text. See it as a start of discussion: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% [errormessage] = ferror(fid) [errormessage,errorcode] = ferror(fid) ...= ferror(fid,command) Checks if the last operation on file given by file handle fid resulted in error. If there was no error, errormessage will be empty and errorcode set to 0. If there was an error, errormessage is set appropriately and errorcode is nonzero. ??what about command?? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Also, the output is not assigned on invalid input such as an invalid fid or bad argument count. Instead of users having to wrap their calls to ferror in try/catch, it would be better to set the output appropriately. I use debian 3.0.1 packaged by debian(lenny), but the report is valid for the octave repository as well (checked today). Thanks, Paul Sundvall From bpabbott at mac.com Fri Nov 6 15:22:34 2009 From: bpabbott at mac.com (Ben Abbott) Date: Fri, 6 Nov 2009 16:22:34 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: References: <27890685913295548502052032932291492684-Webmail@me.com> <116882845175507996186716634374360538589-Webmail@me.com> Message-ID: <32F1D138-DBC9-4C66-89E2-6F4CA006CF7B@mac.com> On Nov 6, 2009, at 4:11 AM, Petr Mikulik wrote: >>> Hm, it seems that in Mingw's C, there is FILE *stderr, but you >>> cannot do >>> fopen("/dev/stderr") (unless run inside cygwin's bash?). >>> >>>>> Is it Octave which eats the dumb output? >>>>> output to screen instead of parsing this as gnuplot messages? >>>> Octave uses bidirectional pipes so that it may be possible to get >>>> information from gnuplot output. >> >> Take a look at __gnuplot_get_var__.m > > So it's popen2("gnuplot") which eats the stdout. The approach of > __gnuplot_get_var__.m is too complicated and it uses mkfifo which > may not > work everywhere. Using temporary file is much more easy and > transparent. > > Enclosed is a patch of gnuplot_drawnow.m for which > GNUTERM=dumb octave > should work everywhere. Please test it and commit if OK. > > --- > Petr Mikulik I've converted Petr's diff to a mercurial changeset. I assume the "pause(0.1)" command is intended to give gnuplot time to produce the plot and write the file, and have modified the patch as indicated below. - pause(0.1); - f = fopen(dumb_tmp_file, 'r'); + fid = -1; + while (fid < 0) + pause(0.1); + fid = fopen(dumb_tmp_file, 'r'); + endwhile Is there a better way to ensure that the temp file is ready to be read? I also made some formatting changes for consistency with Octave's sources. Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 3610 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091106/67a56437/attachment.obj From lindnerben at gmx.net Fri Nov 6 15:50:31 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 22:50:31 +0100 Subject: imshow, image and imagesc fail on small images In-Reply-To: <20091104073034.227470@gmx.net> References: <26160128.post@talk.nabble.com> <19184.35435.297864.313832@segfault.lan> <4AF090FA.70201@sachse-zhang.com> <20091104073034.227470@gmx.net> Message-ID: <4AF49A27.2080807@gmx.net> > > This should be reported to gnuplot I guess. > I created a thread on gnuplot's mailing list reporting this issue. benjamin From tmacchant at yahoo.co.jp Fri Nov 6 19:11:26 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 7 Nov 2009 10:11:26 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <32F1D138-DBC9-4C66-89E2-6F4CA006CF7B@mac.com> Message-ID: <20091107011126.85743.qmail@web3813.mail.bbt.yahoo.co.jp> --- Ben Abbott wrote: > > Petr Mikulik > > I've converted Petr's diff to a mercurial changeset. Thank you for your kindness. To which branch ? 3.2.x or development branch or to both Anyway I will see the both code and try the patch. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Fri Nov 6 19:11:23 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 7 Nov 2009 10:11:23 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <32F1D138-DBC9-4C66-89E2-6F4CA006CF7B@mac.com> Message-ID: <20091107011123.52926.qmail@web3809.mail.bbt.yahoo.co.jp> --- Ben Abbott wrote: > > Petr Mikulik > > I've converted Petr's diff to a mercurial changeset. Thank you for your kindness. To which branch ? 3.2.x or development branch or to both Anyway I will see the both code and try the patch. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Fri Nov 6 23:29:05 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 07 Nov 2009 00:29:05 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <20091107011126.85743.qmail@web3813.mail.bbt.yahoo.co.jp> References: <20091107011126.85743.qmail@web3813.mail.bbt.yahoo.co.jp> Message-ID: <297C2DA5-4C4F-41E2-A770-4216935BD2D3@mac.com> On Nov 6, 2009, at 8:11 PM, Tatsuro MATSUOKA wrote: > --- Ben Abbott wrote: > >>> Petr Mikulik >> >> I've converted Petr's diff to a mercurial changeset. > > Thank you for your kindness. To which branch ? 3.2.x or development > branch or to both > > Anyway I will see the both code and try the patch. > > Regards > > Tatsuro The changeset should apply to the developers branch. It may also apply to 3.2.x, but I haven't tried. Ben From tmacchant at yahoo.co.jp Sat Nov 7 12:00:34 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 8 Nov 2009 03:00:34 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <297C2DA5-4C4F-41E2-A770-4216935BD2D3@mac.com> Message-ID: <20091107180034.56680.qmail@web3808.mail.bbt.yahoo.co.jp> Hello Ben --- Ben Abbott wrote: > The changeset should apply to the developers branch. > > It may also apply to 3.2.x, but I haven't tried. > > Ben ********* Thanks! I have built octave of both branch with your changeset.patch. However both branch, I have met the same error ********************* octave:1> putenv('GNUTERM','dumb') octave:2> plot(1:10) error: `size_str' undefined near line 310 column 20 error: evaluating argument list element number 1 error: called from: error: c:\usr\Tatsu\mingwhome\octaves\OctBuild\octave-develop\..\..\hg\octave-work\scripts\plot\gnuplot_drawnow.m at line 310, column 5 error: c:\usr\Tatsu\mingwhome\octaves\OctBuild\octave-develop\..\..\hg\octave-work\scripts\plot\gnuplot_drawnow.m at line 96, column 14 ********************* 308: if (! isempty (size_str) && new_stream) 309: ## size_str comes after other options to permit specification of 310: ## the canvas size for terminals cdr/corel. 311: term_str = sprintf ("%s %s", term_str, size_str); 312: endif Hmmm ??? Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From Gunnar.Raetsch at tuebingen.mpg.de Sat Nov 7 11:54:45 2009 From: Gunnar.Raetsch at tuebingen.mpg.de (=?ISO-8859-1?Q?Gunnar_R=E4tsch?=) Date: Sat, 7 Nov 2009 18:54:45 +0100 Subject: feval bug in 3.2.3 In-Reply-To: <8C82C2BC-26CD-4ADE-882F-662272C31ECA@tuebingen.mpg.de> References: <8C82C2BC-26CD-4ADE-882F-662272C31ECA@tuebingen.mpg.de> Message-ID: Hi again, I tried it now with other octave versions. It works with 3.0.4 and 3.0.5. It does not work with 3.2.0, 3.2.2 and 3.2.3. Hth, Gunnar On 07.11.2009, at 18:07, Gunnar Raetsch wrote: > Hi Octave team, > > I'm using octave 3.2.3 on amd64 (compiled from source) and have > problems with the feval function. > The code without feval works (1), while it does not work with eval > (2): > > 1. fprintf('calling exp_galaxy(PAR_config)\n') ; > exp_galaxy(PAR_config) ; > > 2. Exp='exp_galaxy' > fprintf('calling feval(''%s'', PAR_config)\n', Exp) ; > PAR_exp = feval(Exp, PAR_config) ; > > The function exp_galaxy is in the same source file as the code above > (a local function). > > feval works as expected in octave 3.0.4, but not in 3.2.3. > (I did not try versions between these versions as I could not get > them compiled.) > > Thanks a lot for your help! > > All the best, > > Gunnar > > > > From pr.nienhuis at hccnet.nl Fri Nov 6 14:56:13 2009 From: pr.nienhuis at hccnet.nl (Philip Nienhuis) Date: Fri, 06 Nov 2009 21:56:13 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> Message-ID: <4AF48D6D.2040607@hccnet.nl> Jaroslav Hajek wrote: > On Thu, Nov 5, 2009 at 11:22 PM, Philip Nienhuis wrote: >> > >> >> >> Adding fields to empty structs doesn't seem to work: >> >> octave-3.2.3.exe: #1 > aa = struct("field1", {}) >> aa = >> { >> 0x0 struct array containing the fields: >> >> field1 >> } >> >> octave-3.2.3.exe: #2 > [aa.field2] = {} >> aa = >> { >> 0x0 struct array containing the fields: >> >> field1 >> } >> >> ===> No field2 to be seen in struct aa : : > [aa.field2] when aa is sempty resolves to an empty cs-list, so there's > nothing to assign (excess rhs values are discarded). Apparently Matlab > carries out the empty assignments for possible side effects, while > Octave simply skips them. For compatibility, here's a patch: Thank you. : >> octave-3.2.3.exe: #9 > rmfield(cc, "field2") >> ans = >> { >> field1 = [](0x0) >> field3 = {}(0x0) >> field4 = {}(0x0) >> } >> >> octave-3.2.3.exe: #10 > rmfield(cc, "field3") >> ans = >> { >> field1 = [](0x0) >> field2 = {}(0x0) >> field4 = {}(0x0) >> } >> where "field3" and "field2" magically but unintendedly reappear. >> > > This is a mix-up of the "your ignorance" case and Octave's sometimes > too succint documentation. While the docstring for rmfield might give > you the impression that > rmfield(cc, "field3") > removes the field3 from cc, but this is not true. Remember (and this > is written in the manual) that Octave functions, be them built-in or > user scripts, *never* alter their arguments. There is no passing by > reference. When you pass a variable as a function argument, it behaves > *as if* a copy was made for all the values (in reality it's a lazy > copy). This very simple and natural scheme frees the Matlab language > of the object ownership problems seen, for instance, in Python or C#, > at the cost of sometimes sacrificing memory efficiency. > > rmfield does, in fact take a copy of the argument, remove the named > field from that copy and return the result, so > cc = rmfield (cc, "field3"); > is what you want. In the docstrings this is often not emphasized > because it's assumed to be a general principle. Yeah I should have realized this, sorry. I might have been distracted because removing fields from structures works through a function rmfield(), while adding fields only works through assignment [struct(:).newfield] = deal({cells}{:}) which does change the original. Part of my original bug report was motivated by all kind of corner cases with empty structs. To avoid having to repeatedly beware & take care of such cases I've created a script around this for my own use, because invoking something like: new_s = addfield (old_s, "nfield", [optional values]) is IMO a little more obvious than the assignment syntax above + variants for exceptions. BTW if anyone thinks such a script is useful for other octave users I'll happily contribute it (here or for octave-forge) > >> On a related note (empty lines skipped for brevity): >> >> octave-3.2.3.exe: #93 > AA = struct() >> AA = >> { >> } >> octave-3.2.3.exe: #96 > BB = struct("field1", {}) : >> BB = >> { >> 0x0 struct array containing the fields: >> field1 >> } : >> The results of size() and isempty() on AA and BB are IMO contrary to >> expectation. (But... fully Matlab r2007a-compatible!) >> >> Is this somehow logical (but beyond my sense for logic) or is it too far >> pursued Matlab compatibility? >> > > It's logical. isempty simply tests whether any dimension is zero; it > doesn't test for the number of fields. Structs with no fields are not > much useful anyway, so I'd expect them to be very rare. (How does size()work in such a case? that one seems to convey the wrong info to isempty) ) Well, it's logical in the sense of "how octave works internally". Still I think it's a bit inconsistent from a user's point of view. A struct with no fields has "no dimensions" to test at all so should be reported "empty" with size 0. IMO, of course :-) Indeed such structs may not be that useful per se, but I can think of automated scripts that could generate them and use them later on; I think from an efficiency perspective such scripts should be saved from having to test for too many corner cases, especially far-fetched ones. To that end, behavior of operations like size() and isempty() should be as consistent as reasonably possible. But assigning extra burden to very-often-used functions for the sake of some rarely encountered cases might not be very sensible either. And -again- Matlab (used preferrably at my employer's office) doesn't do any better in this case. Anyway, thank you for your answer & patches. As I'm not in core octave development I suppose I'll have to wait until a next stable binary :-( (but I'm glad some stuff is solved already). Philip From bpabbott at mac.com Sat Nov 7 13:22:39 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 07 Nov 2009 14:22:39 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <20091107180034.56680.qmail@web3808.mail.bbt.yahoo.co.jp> References: <20091107180034.56680.qmail@web3808.mail.bbt.yahoo.co.jp> Message-ID: <9E53EABC-C7DF-4F80-AA55-3C248D5A235F@mac.com> On Nov 7, 2009, at 1:00 PM, Tatsuro MATSUOKA wrote: > Hello Ben > > --- Ben Abbott wrote: > >> The changeset should apply to the developers branch. >> >> It may also apply to 3.2.x, but I haven't tried. >> >> Ben > ********* > Thanks! > > I have built octave of both branch with your changeset.patch. > > However both branch, I have met the same error > ********************* > octave:1> putenv('GNUTERM','dumb') > octave:2> plot(1:10) > error: `size_str' undefined near line 310 column 20 > error: evaluating argument list element number 1 > error: called from: > error: > c:\usr\Tatsu\mingwhome\octaves\OctBuild\octave-develop\..\..\hg > \octave-work\scripts\plot\gnuplot_drawnow.m > at line 310, column 5 > error: > c:\usr\Tatsu\mingwhome\octaves\OctBuild\octave-develop\..\..\hg > \octave-work\scripts\plot\gnuplot_drawnow.m > at line 96, column 14 > ********************* > 308: if (! isempty (size_str) && new_stream) > 309: ## size_str comes after other options to permit > specification of > 310: ## the canvas size for terminals cdr/corel. > 311: term_str = sprintf ("%s %s", term_str, size_str); > 312: endif > > Hmmm ??? > > Regards > > Tatsuro I'll look into the problem. What I get is below. octave:1> setenv ("GNUTERM", "dumb") octave:2> plot(1:10) Error: terminal "dumb" does not support continuous colors. ^L 10 ++-----------+------------+------------+------------ +-----------++ + + + + + --- + | - +- | | -- | | -- | 8 ++ - +- ++ | --- | | - +- | | ---- | 6 ++ - +- ++ | --- | | - +- | | -- | | -- | 4 ++ - +- ++ | --- | | - +- | | ---- | 2 ++ - +- ++ | -- | | -- | | + | + + + + + + 0 ++-----------+------------+------------+------------ +-----------++ 0 2 4 6 8 10 octave:3> Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091107/fb0dbf75/attachment.html From Gunnar.Raetsch at tuebingen.mpg.de Sat Nov 7 11:07:15 2009 From: Gunnar.Raetsch at tuebingen.mpg.de (Gunnar Raetsch) Date: Sat, 7 Nov 2009 18:07:15 +0100 Subject: feval bug in 3.2.3 Message-ID: <8C82C2BC-26CD-4ADE-882F-662272C31ECA@tuebingen.mpg.de> Hi Octave team, I'm using octave 3.2.3 on amd64 (compiled from source) and have problems with the feval function. The code without feval works (1), while it does not work with eval (2): 1. fprintf('calling exp_galaxy(PAR_config)\n') ; exp_galaxy(PAR_config) ; 2. Exp='exp_galaxy' fprintf('calling feval(''%s'', PAR_config)\n', Exp) ; PAR_exp = feval(Exp, PAR_config) ; The function exp_galaxy is in the same source file as the code above (a local function). feval works as expected in octave 3.0.4, but not in 3.2.3. (I did not try versions between these versions as I could not get them compiled.) Thanks a lot for your help! All the best, Gunnar From bpabbott at mac.com Sat Nov 7 14:04:01 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 07 Nov 2009 15:04:01 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <9E53EABC-C7DF-4F80-AA55-3C248D5A235F@mac.com> References: <20091107180034.56680.qmail@web3808.mail.bbt.yahoo.co.jp> <9E53EABC-C7DF-4F80-AA55-3C248D5A235F@mac.com> Message-ID: On Nov 7, 2009, at 2:22 PM, Ben Abbott wrote: > > On Nov 7, 2009, at 1:00 PM, Tatsuro MATSUOKA wrote: > >> Hello Ben >> >> --- Ben Abbott wrote: >> >>> The changeset should apply to the developers branch. >>> >>> It may also apply to 3.2.x, but I haven't tried. >>> >>> Ben >> ********* >> Thanks! >> >> I have built octave of both branch with your changeset.patch. >> >> However both branch, I have met the same error >> ********************* >> octave:1> putenv('GNUTERM','dumb') >> octave:2> plot(1:10) >> error: `size_str' undefined near line 310 column 20 >> error: evaluating argument list element number 1 >> error: called from: >> error: >> c:\usr\Tatsu\mingwhome\octaves\OctBuild\octave-develop\..\..\hg >> \octave-work\scripts\plot\gnuplot_drawnow.m >> at line 310, column 5 >> error: >> c:\usr\Tatsu\mingwhome\octaves\OctBuild\octave-develop\..\..\hg >> \octave-work\scripts\plot\gnuplot_drawnow.m >> at line 96, column 14 >> ********************* >> 308: if (! isempty (size_str) && new_stream) >> 309: ## size_str comes after other options to permit >> specification of >> 310: ## the canvas size for terminals cdr/corel. >> 311: term_str = sprintf ("%s %s", term_str, size_str); >> 312: endif >> >> Hmmm ??? >> >> Regards >> >> Tatsuro > > I'll look into the problem. What I get is below. > > octave:1> setenv ("GNUTERM", "dumb") > octave:2> plot(1:10) > Error: terminal "dumb" does not support continuous colors. > ^L > > > 10 ++-----------+------------+------------+------------ > +-----------++ > + + + + > + --- + > | > -+- | > | > -- | > | > -- | > 8 ++ - > +- ++ > | > --- | > | - > +- | > | > ---- | > 6 ++ - > +- ++ > | > --- | > | - > +- | > | > -- | > | > -- | > 4 ++ - > +- ++ > | > --- | > | - > +- | > | > ---- | > 2 ++ - > +- ++ > | > -- | > | > -- | > | > + | > + + + + > + + > 0 ++-----------+------------+------------+------------ > +-----------++ > 0 2 4 6 > 8 10 > > octave:3> > > Ben Ok, I see the problem. "size_str" should contain the width and height of the "dumb" terminal in characters. In my case, I see size_str = size 91 36 Which is the width and height of my terminal (i.e. xterm) in characters. For systems where the environment includes the variables "COLUMNS" and "LINES", those will be used to set the plot size. Otherwise I've added default values of 80x34 characters. Is there a better way? For the windows COMMAND window are there environment variables that represent the width and height? Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 3940 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091107/753da436/attachment-0001.obj -------------- next part -------------- From highegg at gmail.com Sat Nov 7 14:25:39 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Sat, 7 Nov 2009 21:25:39 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <4AF48D6D.2040607@hccnet.nl> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> <4AF48D6D.2040607@hccnet.nl> Message-ID: <69d8d540911071225k74342fc0jc815d4e5317c91a5@mail.gmail.com> On Fri, Nov 6, 2009 at 9:56 PM, Philip Nienhuis wrote: > Jaroslav Hajek wrote: >> On Thu, Nov 5, 2009 at 11:22 PM, Philip Nienhuis wrote: >>> >> >>> >>> >>> Adding fields to empty structs doesn't seem to work: >>> >>> octave-3.2.3.exe: #1 > aa = struct("field1", {}) > ?>> aa = > ?>> { > ?>> ? 0x0 struct array containing the fields: > ?>> > ?>> ? ? field1 > ?>> } > ?>> > ?>> octave-3.2.3.exe: #2 > [aa.field2] = {} > ?>> aa = > ?>> { > ?>> ? 0x0 struct array containing the fields: > ?>> > ?>> ? ? field1 > ?>> } > ?>> > ?>> ===> No field2 to be seen in struct aa > : > > : >> [aa.field2] when aa is sempty resolves to an empty cs-list, so there's >> nothing to assign (excess rhs values are discarded). Apparently Matlab >> carries out the empty assignments for possible side effects, while >> Octave simply skips them. For compatibility, here's a patch: > > Thank you. > > > : >>> octave-3.2.3.exe: #9 > rmfield(cc, "field2") >>> ans = >>> { >>> ? field1 = [](0x0) >>> ? field3 = {}(0x0) >>> field4 = {}(0x0) >>> } >>> >>> octave-3.2.3.exe: #10 > rmfield(cc, "field3") >>> ans = >>> { >>> ? field1 = [](0x0) >>> ? field2 = {}(0x0) >>> field4 = {}(0x0) >>> } >>> where "field3" and "field2" magically but unintendedly reappear. >>> >> >> This is a mix-up of the "your ignorance" case and Octave's sometimes >> too succint documentation. While the docstring for rmfield might give >> you the impression that >> rmfield(cc, "field3") >> removes the field3 from cc, but this is not true. Remember (and this >> is written in the manual) that Octave functions, be them built-in or >> user scripts, *never* alter their arguments. There is no passing by >> reference. When you pass a variable as a function argument, it behaves >> *as if* a copy was made for all the values (in reality it's a lazy >> copy). This very simple and natural scheme frees the Matlab language >> of the object ownership problems seen, for instance, in Python or C#, >> at the cost of sometimes sacrificing memory efficiency. >> >> rmfield does, in fact take a copy of the argument, remove the named >> field from that copy and return the result, so >> cc = rmfield (cc, "field3"); >> is what you want. In the docstrings this is often not emphasized >> because it's assumed to be a general principle. > > Yeah I should have realized this, sorry. > I might have been distracted because removing fields from structures > works through a function rmfield(), while adding fields only works > through assignment > ? ? ?[struct(:).newfield] = deal({cells}{:}) > which does change the original. > Part of my original bug report was motivated by all kind of corner cases > with empty structs. To avoid having to repeatedly beware & take care of > such cases I've created a script around this for my own use, because > invoking something like: > > ? ?new_s = addfield (old_s, "nfield", [optional values]) > > is IMO a little more obvious than the assignment syntax above + variants > for exceptions. > How would that differ from setfield? > BTW if anyone thinks such a script is useful for other octave users I'll > happily contribute it (here or for octave-forge) > >> >>> On a related note (empty lines skipped for brevity): >>> >>> octave-3.2.3.exe: #93 > AA = struct() >>> AA = >>> { >>> } >>> octave-3.2.3.exe: #96 > BB = struct("field1", {}) > : > >>> BB = >>> { >>> ? 0x0 struct array containing the fields: >>> ? ? field1 >>> } > : > >>> The results of size() and isempty() on AA and BB are IMO contrary to >>> expectation. (But... fully Matlab r2007a-compatible!) >>> >>> Is this somehow logical (but beyond my sense for logic) or is it too far >>> pursued Matlab compatibility? >>> >> >> It's logical. isempty simply tests whether any dimension is zero; it >> doesn't test for the number of fields. Structs with no fields are not >> much useful anyway, so I'd expect them to be very rare. > > (How does size()work in such a case? that one seems to convey the wrong > info to isempty) ) > Well, it's logical in the sense of "how octave works internally". Still > I think it's a bit inconsistent from a user's point of view. A struct > with no fields has "no dimensions" to test at all so should be reported > "empty" with size 0. IMO, of course :-) > No, that is not true. The number of fields is simply an independent property of the structure. You may also think of it as an extra dimension. You can have structs with no fields but arbitrary dimensions. Admittedly, what is really missing is a function to query the number of fields, say, nfields (s). Currently one needs length (fieldnames (s)). > Indeed such structs may not be that useful per se, but I can think of > automated scripts that could generate them and use them later on; I > think from an efficiency perspective such scripts should be saved from > having to test for too many corner cases, especially far-fetched ones. > To that end, behavior of operations like size() and isempty() should be > as consistent as reasonably possible. Agreed. I think right now, it's quite consistent. > But assigning extra burden to very-often-used functions for the sake of > some rarely encountered cases might not be very sensible either. > > And -again- Matlab (used preferrably at my employer's office) doesn't do > any better in this case. > > Anyway, thank you for your answer & patches. > As I'm not in core octave development I suppose I'll have to wait until > a next stable binary :-( (but I'm glad some stuff is solved already). > Surely you don't *have to* wait - you can download the sources right now and build Octave from them. http://hg.savannah.gnu.org/hgweb/octave Honestly, setting up the build with all dependency libs is a non-trivial task (at least if you want full functionality), but once done, you can get new patches included very easily. best regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From tmacchant at yahoo.co.jp Sat Nov 7 16:26:00 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 8 Nov 2009 07:26:00 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: Message-ID: <20091107222600.5739.qmail@web3812.mail.bbt.yahoo.co.jp> Hello --- Ben Abbott wrote: > Ok, I see the problem. > > "size_str" should contain the width and height of the "dumb" terminal > in characters. In my case, I see > > size_str = size 91 36 > > Which is the width and height of my terminal (i.e. xterm) in characters. > > For systems where the environment includes the variables "COLUMNS" and > "LINES", those will be used to set the plot size. Otherwise I've added > default values of 80x34 characters. > > Is there a better way? > > For the windows COMMAND window are there environment variables that > represent the width and height? Oh! COLUMNS and LINES are environmental variables! I have overlooked. if ~isempty (getenv ("COLUMNS")) && ~isempty (getenv ("LINES")) new_stream = 1; size_str = ["size ", getenv("COLUMNS"), " ", getenv("LINES")]; end OK! Worked if I set COLUMNS and LINES environmental variables, octave:1> putenv('COLUMNS','79') octave:2> putenv('LINES','24') octave:3> putenv('GNUTERM','dumb') octave:4> fplot ("[cos(x), sin(x)]", [0, 2*pi]) ^L 1 ++-------+-------+--------+-------+--------+-------+-------++ + +++ +++ +++ + [cos(x), sin(x)](:,1) +----+ + | ++++ ++ [cos(x), sin(x)](:,2) +----+ | | ++ ++ + | | ++ ++ ++ ++ | 0.5 ++ + ++ + ++ ++ | + ++ + ++ | | + ++ + ++ | |+ ++ ++ ++ | 0 ++ + ++ + ++ | + + + ++ | | ++ + + ++ | | ++ + + ++ | | ++ + ++ ++ | -0.5 ++ ++ + ++ + ++ | ++ ++ ++ ++ | | + ++ ++ | | ++ ++++ ++ | + + + +++ + +++ + +++ +++ + + -1 ++-------+-------+--------+-------+--------+-------+-------++ 0 1 2 3 4 5 6 7 I have not seen the new patch. I will report later. Anyway the changeset made by Ben and Petr works also on windows if size is set properly. BTW, according to help of gnuplot for windows ************************ where and set the size of the dumb terminals. Default is 79 by 24.The last newline is printed only if feedis enabled. Examples: set term dumb nofeed set term dumb 79 49 #VGA screen---why would anyone do that? ************************* Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sat Nov 7 18:10:35 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 8 Nov 2009 09:10:35 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <20091107222600.5739.qmail@web3812.mail.bbt.yahoo.co.jp> Message-ID: <20091108001035.17130.qmail@web3802.mail.bbt.yahoo.co.jp> Hello --- Tatsuro MATSUOKA wrote: > Hello > > --- Ben Abbott wrote: > > Which is the width and height of my terminal (i.e. xterm) in characters. > > > > For systems where the environment includes the variables "COLUMNS" and > > "LINES", those will be used to set the plot size. Otherwise I've added > > default values of 80x34 characters. New patch has been worked!! Thanks I think it is better to set default value of gnuplot, 79x24 as is written in gnuplot help. I consulted help on Cygwin, the default value is also 79x24. (I have mistaken to write it as 79x49.) This is a small point I suggest you. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Sat Nov 7 19:00:26 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 07 Nov 2009 20:00:26 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <20091108001035.17130.qmail@web3802.mail.bbt.yahoo.co.jp> References: <20091108001035.17130.qmail@web3802.mail.bbt.yahoo.co.jp> Message-ID: On Nov 7, 2009, at 7:10 PM, Tatsuro MATSUOKA wrote: > Hello > > --- Tatsuro MATSUOKA wrote: > >> Hello >> >> --- Ben Abbott wrote: >>> Which is the width and height of my terminal (i.e. xterm) in >>> characters. >>> >>> For systems where the environment includes the variables "COLUMNS" >>> and >>> "LINES", those will be used to set the plot size. Otherwise I've >>> added >>> default values of 80x34 characters. > > New patch has been worked!! > Thanks > > I think it is better to set default value of gnuplot, 79x24 as is > written in gnuplot help. > I consulted help on Cygwin, the default value is also 79x24. > (I have mistaken to write it as 79x49.) > > This is a small point I suggest you. > > Regards > > Tatsuro Ok. A modified changeset is attached. If there are no objections, I'll push it tomorrow. Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 3940 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091107/16c45270/attachment.obj -------------- next part -------------- From bpabbott at mac.com Sun Nov 8 16:28:45 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 08 Nov 2009 17:28:45 -0500 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: References: <20091108001035.17130.qmail@web3802.mail.bbt.yahoo.co.jp> Message-ID: <0DF760A1-76BC-4320-96E5-BB2B7A9E86AF@mac.com> On Nov 7, 2009, at 8:00 PM, Ben Abbott wrote: > On Nov 7, 2009, at 7:10 PM, Tatsuro MATSUOKA wrote: > >> Hello >> >> --- Tatsuro MATSUOKA wrote: >> >>> Hello >>> >>> --- Ben Abbott wrote: >>>> Which is the width and height of my terminal (i.e. xterm) in >>>> characters. >>>> >>>> For systems where the environment includes the variables >>>> "COLUMNS" and >>>> "LINES", those will be used to set the plot size. Otherwise I've >>>> added >>>> default values of 80x34 characters. >> >> New patch has been worked!! >> Thanks >> >> I think it is better to set default value of gnuplot, 79x24 as is >> written in gnuplot help. >> I consulted help on Cygwin, the default value is also 79x24. >> (I have mistaken to write it as 79x49.) >> >> This is a small point I suggest you. >> >> Regards >> >> Tatsuro > > Ok. A modified changeset is attached. If there are no objections, > I'll push it tomorrow. > > Ben I've pushed the attached changeset, attributed to Petr. There are some minor differences from the preceding ones. (1) The gnuplot_default_term() function has been modified to use "dumb" , instead of "unknown", as a last resort. (2) The gnuplot_set_term() function is used to produce the gnuplot "set output ..." command. (3) In the event that the COLUMNS and LINES environment variables are not set, the size of the plot is left up to gnuplot. Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 4067 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091108/84b1ff84/attachment.obj -------------- next part -------------- From tmacchant at yahoo.co.jp Sun Nov 8 17:07:52 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 9 Nov 2009 08:07:52 +0900 (JST) Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <0DF760A1-76BC-4320-96E5-BB2B7A9E86AF@mac.com> Message-ID: <20091108230753.37542.qmail@web3813.mail.bbt.yahoo.co.jp> Hello --- Ben Abbott wrote: I agree. > I've pushed the attached changeset, attributed to Petr. There are some > minor differences from the preceding ones. > > (1) The gnuplot_default_term() function has been modified to use > "dumb" , instead of "unknown", as a last resort. > > (2) The gnuplot_set_term() function is used to produce the gnuplot > "set output ..." command. > > (3) In the event that the COLUMNS and LINES environment variables are > not set, the size of the plot is left up to gnuplot. ********** + ## Use the gnuplot default. + size_str = ""; ********** Indeed! This is smart. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From C.Ellenberger at gmx.net Mon Nov 9 05:17:19 2009 From: C.Ellenberger at gmx.net (Christoph Ellenberger) Date: Mon, 09 Nov 2009 12:17:19 +0100 Subject: plotyy force dataaspectratio Message-ID: <20091109111719.157640@gmx.net> Hi, I am using the regular mingw snapshots for windows. Some of my scripts got broken when I updated from 3.2.0 to 3.2.2/3. It is about using two axis plots with plotyy. The problem is that after I change axis properties the plot of the second axis gets way too small (see fig). I traced it down to the update_position function in plotyy where the dataaspectratio property from the first axis is forced onto the second axis which does not make sense. Now I don't know what the intended behaviour of this function would have been or if the function is called somewhere with the wrong axes handles but as far as I understand it, it should be reverted to the 3.2.0 version as it only updates the positioning, which in my opinion does not change the aspectratio... 3.2.2/3 function update_position (h, d, ax2) persistent recursion = false; ## Don't allow recursion if (! recursion) unwind_protect recursion = true; position = get (h, "position"); view = get (h, "view"); dataaspectratio = get (h, "dataaspectratio"); oldposition = get (ax2, "position"); oldview = get (ax2, "view"); olddataaspectratio = get (ax2, "dataaspectratio"); if (! (isequal (position, oldposition) && isequal (view, oldview) && isequal (dataaspectratio, olddataaspectratio))) set (ax2, "position", position, "view", view, "dataaspectratio", dataaspectratio); endif unwind_protect_cleanup recursion = false; end_unwind_protect endif endfunction 3.2.0 and my suggestion function update_position (h, d, ax2) persistent recursion = false; ## Don't allow recursion if (! recursion) unwind_protect recursion = true; position = get (h, "position"); view = get (h, "view"); oldposition = get (ax2, "position"); oldview = get (ax2, "view"); if (! (isequal (position, oldposition) && isequal (view, oldview))) set (ax2, "position", position, "view", view); endif unwind_protect_cleanup recursion = false; end_unwind_protect endif endfunction thanks in advance christoph -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -------------- next part -------------- A non-text attachment was scrubbed... Name: plotyy.jpg Type: image/pjpeg Size: 29055 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091109/73782140/attachment-0001.bin From bpabbott at mac.com Mon Nov 9 06:46:21 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 09 Nov 2009 07:46:21 -0500 Subject: plotyy force dataaspectratio In-Reply-To: <20091109111719.157640@gmx.net> References: <20091109111719.157640@gmx.net> Message-ID: On Nov 9, 2009, at 6:17 AM, Christoph Ellenberger wrote: > Hi, > I am using the regular mingw snapshots for windows. Some of my > scripts got broken when I updated from 3.2.0 to 3.2.2/3. It is about > using two axis plots with plotyy. The problem is that after I change > axis properties the plot of the second axis gets way too small (see > fig). I traced it down to the update_position function in plotyy > where the dataaspectratio property from the first axis is forced > onto the second axis which does not make sense. Now I don't know > what the intended behaviour of this function would have been or if > the function is called somewhere with the wrong axes handles but as > far as I understand it, it should be reverted to the 3.2.0 version > as it only updates the positioning, which in my opinion does not > change the aspectratio... > > 3.2.2/3 > function update_position (h, d, ax2) > persistent recursion = false; > > ## Don't allow recursion > if (! recursion) > unwind_protect > recursion = true; > position = get (h, "position"); > view = get (h, "view"); > dataaspectratio = get (h, "dataaspectratio"); > oldposition = get (ax2, "position"); > oldview = get (ax2, "view"); > olddataaspectratio = get (ax2, "dataaspectratio"); > if (! (isequal (position, oldposition) > && isequal (view, oldview) > && isequal (dataaspectratio, olddataaspectratio))) > set (ax2, "position", position, > "view", view, > "dataaspectratio", dataaspectratio); > endif > unwind_protect_cleanup > recursion = false; > end_unwind_protect > endif > endfunction > > 3.2.0 and my suggestion > function update_position (h, d, ax2) > persistent recursion = false; > > ## Don't allow recursion > if (! recursion) > unwind_protect > recursion = true; > position = get (h, "position"); > view = get (h, "view"); > oldposition = get (ax2, "position"); > oldview = get (ax2, "view"); > if (! (isequal (position, oldposition) && isequal (view, > oldview))) > set (ax2, "position", position, "view", view); > endif > unwind_protect_cleanup > recursion = false; > end_unwind_protect > endif > endfunction > > thanks in advance > christoph Please verify that your proposed change works for the demos. You can do that by starting Octave and typing ... demo plotyy Also, it would be useful to add a new demo for your case. Can you give us a simple example where 3.2.3 produces the wrong result? Ben From C.Ellenberger at gmx.net Mon Nov 9 08:09:39 2009 From: C.Ellenberger at gmx.net (Christoph Ellenberger) Date: Mon, 09 Nov 2009 15:09:39 +0100 Subject: plotyy force dataaspectratio In-Reply-To: References: <20091109111719.157640@gmx.net> Message-ID: <20091109140939.198130@gmx.net> I tested the demos and they still work, though as I said the error might be at a different spot. Because the problem occurs when calling the axis command on the second axis itself (using the first works well), so it might be that the axis command is calling update_position with a wrong handle set, but I haven't actually found from where this function is called. I only saw that it is copying the dataaspectratio from axis1 to axis2 as it is called with h=handle axis1 and ax2=handle axis2 So here is my "simple example": x=1:8; y=7000:20:7140; y2=repmat(2,1,8); ax=plotyy(x,y,x,y2); lim=axis; lim(1:4)=[3 5 1 5]; axis(lim); My suggestion is just a workaround for the function as it is called right now, but wouldn't fix it if the idea of the reposition is to compare it with older axis properties, but to my idea of it it is not intended to copy the dataaspectratio if just the position of an axis is changed. kind regards christoph -------- Original-Nachricht -------- > Datum: Mon, 09 Nov 2009 07:46:21 -0500 > Von: Ben Abbott > An: Christoph Ellenberger > CC: bug-octave at octave.org > Betreff: Re: plotyy force dataaspectratio > > On Nov 9, 2009, at 6:17 AM, Christoph Ellenberger wrote: > > > Hi, > > I am using the regular mingw snapshots for windows. Some of my > > scripts got broken when I updated from 3.2.0 to 3.2.2/3. It is about > > using two axis plots with plotyy. The problem is that after I change > > axis properties the plot of the second axis gets way too small (see > > fig). I traced it down to the update_position function in plotyy > > where the dataaspectratio property from the first axis is forced > > onto the second axis which does not make sense. Now I don't know > > what the intended behaviour of this function would have been or if > > the function is called somewhere with the wrong axes handles but as > > far as I understand it, it should be reverted to the 3.2.0 version > > as it only updates the positioning, which in my opinion does not > > change the aspectratio... > > > > 3.2.2/3 > > function update_position (h, d, ax2) > > persistent recursion = false; > > > > ## Don't allow recursion > > if (! recursion) > > unwind_protect > > recursion = true; > > position = get (h, "position"); > > view = get (h, "view"); > > dataaspectratio = get (h, "dataaspectratio"); > > oldposition = get (ax2, "position"); > > oldview = get (ax2, "view"); > > olddataaspectratio = get (ax2, "dataaspectratio"); > > if (! (isequal (position, oldposition) > > && isequal (view, oldview) > > && isequal (dataaspectratio, olddataaspectratio))) > > set (ax2, "position", position, > > "view", view, > > "dataaspectratio", dataaspectratio); > > endif > > unwind_protect_cleanup > > recursion = false; > > end_unwind_protect > > endif > > endfunction > > > > 3.2.0 and my suggestion > > function update_position (h, d, ax2) > > persistent recursion = false; > > > > ## Don't allow recursion > > if (! recursion) > > unwind_protect > > recursion = true; > > position = get (h, "position"); > > view = get (h, "view"); > > oldposition = get (ax2, "position"); > > oldview = get (ax2, "view"); > > if (! (isequal (position, oldposition) && isequal (view, > > oldview))) > > set (ax2, "position", position, "view", view); > > endif > > unwind_protect_cleanup > > recursion = false; > > end_unwind_protect > > endif > > endfunction > > > > thanks in advance > > christoph > > Please verify that your proposed change works for the demos. You can > do that by starting Octave and typing ... > > demo plotyy > > Also, it would be useful to add a new demo for your case. Can you give > us a simple example where 3.2.3 produces the wrong result? > > Ben > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From bpabbott at mac.com Mon Nov 9 12:46:00 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 09 Nov 2009 13:46:00 -0500 Subject: plotyy force dataaspectratio In-Reply-To: <20091109140939.198130@gmx.net> References: <20091109111719.157640@gmx.net> <20091109140939.198130@gmx.net> Message-ID: <42125056345975885358814655966376748357-Webmail@me.com> On Monday, November 09, 2009, at 09:09AM, "Christoph Ellenberger" wrote: > >-------- Original-Nachricht -------- >> Datum: Mon, 09 Nov 2009 07:46:21 -0500 >> Von: Ben Abbott >> An: Christoph Ellenberger >> CC: bug-octave at octave.org >> Betreff: Re: plotyy force dataaspectratio > >> >> On Nov 9, 2009, at 6:17 AM, Christoph Ellenberger wrote: >> >> > Hi, >> > I am using the regular mingw snapshots for windows. Some of my >> > scripts got broken when I updated from 3.2.0 to 3.2.2/3. It is about >> > using two axis plots with plotyy. The problem is that after I change >> > axis properties the plot of the second axis gets way too small (see >> > fig). I traced it down to the update_position function in plotyy >> > where the dataaspectratio property from the first axis is forced >> > onto the second axis which does not make sense. Now I don't know >> > what the intended behaviour of this function would have been or if >> > the function is called somewhere with the wrong axes handles but as >> > far as I understand it, it should be reverted to the 3.2.0 version >> > as it only updates the positioning, which in my opinion does not >> > change the aspectratio... >> > >> > 3.2.2/3 >> > function update_position (h, d, ax2) >> > persistent recursion = false; >> > >> > ## Don't allow recursion >> > if (! recursion) >> > unwind_protect >> > recursion = true; >> > position = get (h, "position"); >> > view = get (h, "view"); >> > dataaspectratio = get (h, "dataaspectratio"); >> > oldposition = get (ax2, "position"); >> > oldview = get (ax2, "view"); >> > olddataaspectratio = get (ax2, "dataaspectratio"); >> > if (! (isequal (position, oldposition) >> > && isequal (view, oldview) >> > && isequal (dataaspectratio, olddataaspectratio))) >> > set (ax2, "position", position, >> > "view", view, >> > "dataaspectratio", dataaspectratio); >> > endif >> > unwind_protect_cleanup >> > recursion = false; >> > end_unwind_protect >> > endif >> > endfunction >> > >> > 3.2.0 and my suggestion >> > function update_position (h, d, ax2) >> > persistent recursion = false; >> > >> > ## Don't allow recursion >> > if (! recursion) >> > unwind_protect >> > recursion = true; >> > position = get (h, "position"); >> > view = get (h, "view"); >> > oldposition = get (ax2, "position"); >> > oldview = get (ax2, "view"); >> > if (! (isequal (position, oldposition) && isequal (view, >> > oldview))) >> > set (ax2, "position", position, "view", view); >> > endif >> > unwind_protect_cleanup >> > recursion = false; >> > end_unwind_protect >> > endif >> > endfunction >> > >> > thanks in advance >> > christoph >> >> Please verify that your proposed change works for the demos. You can >> do that by starting Octave and typing ... >> >> demo plotyy >> >> Also, it would be useful to add a new demo for your case. Can you give >> us a simple example where 3.2.3 produces the wrong result? >> >> Ben >> > >I tested the demos and they still work, though as I said the error might be at a different spot. Because the problem occurs when calling the axis command on the second axis itself (using the first works well), so it might be that the axis command is calling update_position with a wrong handle set, but I haven't actually found from where this function is called. I only saw that it is copying the dataaspectratio from axis1 to axis2 as it is called with h=handle axis1 and ax2=handle axis2 > >So here is my "simple example": > >x=1:8; >y=7000:20:7140; >y2=repmat(2,1,8); >ax=plotyy(x,y,x,y2); >lim=axis; >lim(1:4)=[3 5 1 5]; >axis(lim); > >My suggestion is just a workaround for the function as it is called right now, but wouldn't fix it if the idea of the reposition is to compare it with older axis properties, but to my idea of it it is not intended to copy the dataaspectratio if just the position of an axis is changed. > >kind regards >christoph I tried your example with current version for 3.2.x. The result looks correct to me. Meaning it is consistent with what Matlab produces. The current version for 3.2.x can be found at the like below. http://hg.tw-math.de/release-3-2-x/file/fee95bb4ee94/scripts/plot/plotyy.m Ben Ben From highegg at gmail.com Tue Nov 10 03:59:56 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 10 Nov 2009 10:59:56 +0100 Subject: method indexing bug In-Reply-To: <4AF0396F.2040009@acc.umu.se> References: <4AF0390C.5030600@acc.umu.se> <4AF0396F.2040009@acc.umu.se> Message-ID: <69d8d540911100159j3f39e7bfoa739fd1bf8f9c5e3@mail.gmail.com> On Tue, Nov 3, 2009 at 3:08 PM, David Grundberg wrote: > David Grundberg wrote: >> >> Hi bug-list, >> >> In an object's subasgn, I want to assign to a object field using >> >> ?object.field(1, :) = [1,2] >> >> syntax. This works in Matlab. However, in Octave, I get 'error: a cs-list >> cannot be further indexed'. >> >> I'm attaching a tarball with an example as minimal as I could make it. >> After extracting the tarball, I can run >> >> ?p=Mini; p.key = 1:2 >> >> on rev 9771:4634a0e9ea1b to recreate the error message. >> >> Regards, >> David >> > > Naturally, it helps if I actually attach the tarball. > > Please try this patch: http://hg.savannah.gnu.org/hgweb/octave/rev/384616240a8f thanks -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Tue Nov 10 04:25:44 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 10 Nov 2009 11:25:44 +0100 Subject: feval bug in 3.2.3 In-Reply-To: References: <8C82C2BC-26CD-4ADE-882F-662272C31ECA@tuebingen.mpg.de> Message-ID: <69d8d540911100225t4e4d03bex552975cc1d6c9ba2@mail.gmail.com> On Sat, Nov 7, 2009 at 6:54 PM, Gunnar R?tsch wrote: > Hi again, > > I tried it now with other octave versions. It works with 3.0.4 and > 3.0.5. > It does not work with 3.2.0, 3.2.2 and 3.2.3. > > Hth, Gunnar > > > On 07.11.2009, at 18:07, Gunnar Raetsch wrote: > >> Hi Octave team, >> >> I'm using octave 3.2.3 on amd64 (compiled from source) and have >> problems with the feval function. >> The code without feval works (1), while it does not work with eval >> (2): >> >> 1. fprintf('calling exp_galaxy(PAR_config)\n') ; >> exp_galaxy(PAR_config) ; >> >> 2. Exp='exp_galaxy' >> fprintf('calling feval(''%s'', PAR_config)\n', Exp) ; >> PAR_exp = feval(Exp, PAR_config) ; >> >> The function exp_galaxy is in the same source file as the code above >> (a local function). >> >> feval works as expected in octave 3.0.4, but not in 3.2.3. >> (I did not try versions between these versions as I could not get >> them compiled.) >> >> Thanks a lot for your help! >> >> All the best, >> >> Gunnar >> >> >> >> > Since you haven't given a working code, I can't be sure, but probably this is a duplicate of http://old.nabble.com/feval-call-to-a-subfunction-fails-when-it-is-in-a-subfunction-to25691978.html -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From individ at acc.umu.se Tue Nov 10 05:04:29 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 10 Nov 2009 12:04:29 +0100 Subject: method indexing bug In-Reply-To: <69d8d540911100159j3f39e7bfoa739fd1bf8f9c5e3@mail.gmail.com> References: <4AF0390C.5030600@acc.umu.se> <4AF0396F.2040009@acc.umu.se> <69d8d540911100159j3f39e7bfoa739fd1bf8f9c5e3@mail.gmail.com> Message-ID: <4AF948BD.2000104@acc.umu.se> Jaroslav Hajek wrote: > On Tue, Nov 3, 2009 at 3:08 PM, David Grundberg wrote: > >> David Grundberg wrote: >> >>> Hi bug-list, >>> >>> In an object's subasgn, I want to assign to a object field using >>> >>> object.field(1, :) = [1,2] >>> >>> syntax. This works in Matlab. However, in Octave, I get 'error: a cs-list >>> cannot be further indexed'. >>> >>> I'm attaching a tarball with an example as minimal as I could make it. >>> After extracting the tarball, I can run >>> >>> p=Mini; p.key = 1:2 >>> >>> on rev 9771:4634a0e9ea1b to recreate the error message. >>> >>> Regards, >>> David >>> >>> >> Naturally, it helps if I actually attach the tarball. >> >> >> > > Please try this patch: > http://hg.savannah.gnu.org/hgweb/octave/rev/384616240a8f > > thanks > > Jaroslav, thanks for fixing this. The indexing works now. David From highegg at gmail.com Tue Nov 10 05:31:06 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 10 Nov 2009 12:31:06 +0100 Subject: method indexing bug In-Reply-To: <4AF948BD.2000104@acc.umu.se> References: <4AF0390C.5030600@acc.umu.se> <4AF0396F.2040009@acc.umu.se> <69d8d540911100159j3f39e7bfoa739fd1bf8f9c5e3@mail.gmail.com> <4AF948BD.2000104@acc.umu.se> Message-ID: <69d8d540911100331r797eb692if7fe732b059d06ba@mail.gmail.com> On Tue, Nov 10, 2009 at 12:04 PM, David Grundberg wrote: > Jaroslav Hajek wrote: > >> On Tue, Nov 3, 2009 at 3:08 PM, David Grundberg >> wrote: >> >> >>> David Grundberg wrote: >>> >>> >>>> Hi bug-list, >>>> >>>> In an object's subasgn, I want to assign to a object field using >>>> >>>> object.field(1, :) = [1,2] >>>> >>>> syntax. This works in Matlab. However, in Octave, I get 'error: a >>>> cs-list >>>> cannot be further indexed'. >>>> >>>> I'm attaching a tarball with an example as minimal as I could make it. >>>> After extracting the tarball, I can run >>>> >>>> p=Mini; p.key = 1:2 >>>> >>>> on rev 9771:4634a0e9ea1b to recreate the error message. >>>> >>>> Regards, >>>> David >>>> >>>> >>>> >>> Naturally, it helps if I actually attach the tarball. >>> >>> >>> >>> >> >> Please try this patch: >> http://hg.savannah.gnu.org/hgweb/octave/rev/384616240a8f >> >> thanks >> >> >> > > > Jaroslav, > > thanks for fixing this. The indexing works now. > > David > Good. Please note that the OOP support is still partial; inheritance simply doesn't work together with multidimensional classes. To make it work like in Matlab a massive rewrite would probably be needed. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091110/56eb9578/attachment-0001.html From jwe at octave.org Tue Nov 10 06:10:34 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 07:10:34 -0500 Subject: method indexing bug In-Reply-To: <69d8d540911100331r797eb692if7fe732b059d06ba@mail.gmail.com> References: <4AF0390C.5030600@acc.umu.se> <4AF0396F.2040009@acc.umu.se> <69d8d540911100159j3f39e7bfoa739fd1bf8f9c5e3@mail.gmail.com> <4AF948BD.2000104@acc.umu.se> <69d8d540911100331r797eb692if7fe732b059d06ba@mail.gmail.com> Message-ID: <19193.22586.282282.171301@segfault.lan> On 10-Nov-2009, Jaroslav Hajek wrote: | Good. Please note that the OOP support is still partial; inheritance simply | doesn't work together with multidimensional classes. To make it work like in | Matlab a massive rewrite would probably be needed. By multidimensional classes, do you mean something like class (struct ("x", {1, 2; 3, 4}), "foo") ? Is this kind of thing used very often by real code? How is it useful? jwe From individ at acc.umu.se Tue Nov 10 06:23:51 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 10 Nov 2009 13:23:51 +0100 Subject: method indexing bug In-Reply-To: <69d8d540911100331r797eb692if7fe732b059d06ba@mail.gmail.com> References: <4AF0390C.5030600@acc.umu.se> <4AF0396F.2040009@acc.umu.se> <69d8d540911100159j3f39e7bfoa739fd1bf8f9c5e3@mail.gmail.com> <4AF948BD.2000104@acc.umu.se> <69d8d540911100331r797eb692if7fe732b059d06ba@mail.gmail.com> Message-ID: <4AF95B57.6030501@acc.umu.se> Jaroslav Hajek wrote: > > > On Tue, Nov 10, 2009 at 12:04 PM, David Grundberg > wrote: > > Jaroslav Hajek wrote: > > On Tue, Nov 3, 2009 at 3:08 PM, David Grundberg > > wrote: > > > David Grundberg wrote: > > > Hi bug-list, > > In an object's subasgn, I want to assign to a object > field using > > object.field(1, :) = [1,2] > > syntax. This works in Matlab. However, in Octave, I > get 'error: a cs-list > cannot be further indexed'. > > I'm attaching a tarball with an example as minimal as > I could make it. > After extracting the tarball, I can run > > p=Mini; p.key = 1:2 > > on rev 9771:4634a0e9ea1b to recreate the error message. > > Regards, > David > > > > Naturally, it helps if I actually attach the tarball. > > > > > > Please try this patch: > http://hg.savannah.gnu.org/hgweb/octave/rev/384616240a8f > > thanks > > > > > > Jaroslav, > > thanks for fixing this. The indexing works now. > > David > > > Good. Please note that the OOP support is still partial; inheritance > simply doesn't work together with multidimensional classes. To make it > work like in Matlab a massive rewrite would probably be needed. Ok, good to know about problems with multidimensional classes. Fortunate, I don't have any inheritance! One problem with making a Matlab-compatible oo system is that OOP is extremely scarcely documented. The docs are written by some technical writer that haven't bothered to test whether the statements made are correct. The new oo-system (with single classdef files) makes it even harder to know how the legacy system is supposed to work. Does anyone have a detailed idea of how legacy OOP works in Matlab? Otherwise implementing it correctly would be hard. David From highegg at gmail.com Tue Nov 10 06:24:24 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 10 Nov 2009 13:24:24 +0100 Subject: method indexing bug In-Reply-To: <19193.22586.282282.171301@segfault.lan> References: <4AF0390C.5030600@acc.umu.se> <4AF0396F.2040009@acc.umu.se> <69d8d540911100159j3f39e7bfoa739fd1bf8f9c5e3@mail.gmail.com> <4AF948BD.2000104@acc.umu.se> <69d8d540911100331r797eb692if7fe732b059d06ba@mail.gmail.com> <19193.22586.282282.171301@segfault.lan> Message-ID: <69d8d540911100424s4f065743l69407e7576f89320@mail.gmail.com> On Tue, Nov 10, 2009 at 1:10 PM, John W. Eaton wrote: > On 10-Nov-2009, Jaroslav Hajek wrote: > > | Good. Please note that the OOP support is still partial; inheritance > simply > | doesn't work together with multidimensional classes. To make it work like > in > | Matlab a massive rewrite would probably be needed. > > By multidimensional classes, do you mean something like > > class (struct ("x", {1, 2; 3, 4}), "foo") > > ? Yes. > Is this kind of thing used very often by real code? How is it > useful? > > jwe > > I dunno. I suppose scalar struct with multidimensional fields will be used in most cases - that gives you a far better flexibility (an example is the dict class from the "general" package). What Matlab does in the multi-dim inheritance case is also quite weird. When you create obj = class (struct ("x", {1, 2; 3, 4}), "foo", bar), I think bar may either be a scalar or 2x2. obj.bar then behaves like an ordinary field, i.e. gives a cs-list of 4 bar classes. Stuff like obj(I,J).bar also works. This would suggest that the constructor splits bar into 1x1 inherited sub objects (or replicates the 1x1 object given) and stores the field normally. But then, when foo object is passed to an inherited method, a 2x2 class is visible again to the method, as if the 1x1 objects were magically joined. I tested this quickly with a Matlab copy some time ago, so I may not be entirely correct here. In any case this behaviour is quite ill-suited for our current implementation - splitting a struct array into scalar structs is very wasteful, and this is needed for an ordinary field to be created. If we were to work this around, then foo.bar must not be an ordinary field, but resolved magically. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091110/b5db20df/attachment.html From individ at acc.umu.se Tue Nov 10 08:12:20 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 10 Nov 2009 15:12:20 +0100 Subject: sscanf always returns 0 Message-ID: <4AF974C4.8020302@acc.umu.se> Hi buglist, Running [scanned, count, errmsg, offset] = sscanf ("56 foobar", "%d") should give offset = 4 but instead I get offset = 0. I changed octave_istrstream to fix this, see attachment. Best regards, David -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sscanf-tell.changeset Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091110/0be58e82/attachment.ksh From WATKINS.ROBERT at comcast.net Tue Nov 10 15:23:39 2009 From: WATKINS.ROBERT at comcast.net (Robert Watkins) Date: Tue, 10 Nov 2009 13:23:39 -0800 Subject: svd() documentation suggestion Message-ID: <34148083-C11C-4A47-813C-232153AD430D@COMCAST.NET> Bug report for Octave 3.0.5 configured for i386-apple-darwin8.9.1 Description: ----------- In Matlab, [u,s,v] = svd(X) guarantees that the singular values are returned in descending order, and this fact is documented in the Matlab Users Guide. Octave appears to do the same, but the documentation makes no mention of it. Repeat-By: --------- See description of svd() in the Linear Algebra/Matrix Factorizations section of the the Octave Manual. Note absence of any description of the order of the singular values. Fix: --- Confirm that the order of singular values returned by svd() is indeed guaranteed to be descending. If so, update Octave manual; if not, consider it a Matlab compatibility bug. Configuration (please do not edit this section): ----------------------------------------------- uname output: Darwin snowbird.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 configure opts: 'CC=gcc -O3 -ftree-vectorize -fforce-addr - march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx' 'CPP=gcc -O3 -ftree-vectorize -fforce-addr -march=i686 -mfpmath=sse, 387 -mieee-fp -msse3 -msse2 -msse -mmmx -E' 'CXX=g++ -O3 -ftree- vectorize -fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 - msse2 -msse -mmmx' 'CFLAGS=' 'CPPFLAGS=' 'CXXFLAGS=' 'LDFLAGS=' '-- prefix=/tmp/dependencies-i386' '' 'F77=fort77 -O3 -ftree-vectorize - fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx' 'FLIBS=-lf2c' 'FFLAGS=' '--enable-shared' 'host_alias=i386- apple-darwin8.9.1' Fortran compiler: fort77 -O3 -ftree-vectorize -fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx FFLAGS: F2C: @F2C@ F2CFLAGS: @F2CFLAGS@ FLIBS: -lf2c CPPFLAGS: -I/tmp/dependencies-i386/include INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc -O3 -ftree-vectorize -fforce-addr -march=i686 - mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx, version 4.0.1 (Apple Computer, Inc. build 5370) CFLAGS: CPICFLAG: -fPIC C++ compiler: g++ -O3 -ftree-vectorize -fforce-addr -march=i686 - mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx, version 4.0.1 CXXFLAGS: CXXPICFLAG: -fPIC LD_CXX: g++ -O3 -ftree-vectorize -fforce-addr -march=i686 - mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx LDFLAGS: LIBFLAGS: -L. RLD_FLAG: BLAS_LIBS: -Wl,-framework -Wl,vecLib FFTW_LIBS: -lfftw3 LIBS: -lreadline -lncurses -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /usr/bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" - D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=unknown -DCXX_PREPENDS_UNDERSCORE=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __ -DHAVE_BLAS=1 -DHAVE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_CHOLMOD_H=1 - DHAVE_CHOLMOD=1 -DHAVE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 - DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 - DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 - DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 - DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 - DHAVE_SSTREAM=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 - DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 - DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 - DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 - DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 -DHAVE_DYLD_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_EXP2=1 -DHAVE_LOG2=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 - DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 - DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot" User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /Applications/Octave.app/Contents/Resources/libexec/ octave/3.0.5/site/exec/i386-apple-darwin8.9.1:/Applications/Octave.app/ Contents/Resources/libexec/octave/api-v32/site/exec/i386-apple- darwin8.9.1:/Applications/Octave.app/Contents/Resources/libexec/octave/ site/exec/i386-apple-darwin8.9.1:/Applications/Octave.app/Contents/ Resources/libexec/octave/3.0.5/exec/i386-apple-darwin8.9.1:/ Applications/Octave.app/Contents/Resources/bin:/Applications/ Octave.app/Contents/Resources/bin:/Applications/Gnuplot.app/Contents/ Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin IMAGE_PATH = .:/Applications/Octave.app/Contents/Resources/share/ octave/3.0.5/imagelib PAGER = less PS1 = octave> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 0 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot gnuplot_command_end = gnuplot_command_plot = pl gnuplot_command_replot = rep gnuplot_command_splot = sp gnuplot_command_title = t gnuplot_command_using = u gnuplot_command_with = w history_file = /Users/rwatkins/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /Applications/Octave.app/Contents/Resources/share/info/ octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 0 print_answer_id_name = 1 print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From jwe at octave.org Tue Nov 10 16:19:58 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 17:19:58 -0500 Subject: sscanf always returns 0 In-Reply-To: <4AF974C4.8020302@acc.umu.se> References: <4AF974C4.8020302@acc.umu.se> Message-ID: <19193.59150.9359.273016@segfault.lan> On 10-Nov-2009, David Grundberg wrote: | Running | | [scanned, count, errmsg, offset] = sscanf ("56 foobar", "%d") | | should give offset = 4 but instead I get offset = 0. | | I changed octave_istrstream to fix this, see attachment. I applied it. Thanks, jwe From jwe at octave.org Tue Nov 10 16:57:15 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 17:57:15 -0500 Subject: misleading documentation for ferror In-Reply-To: <4AF41C77.4020306@paulsundvall.net> References: <4AF41C77.4020306@paulsundvall.net> Message-ID: <19193.61387.792690.245459@segfault.lan> On 6-Nov-2009, Paul Sundvall wrote: | The help for the builtin ferror function claims | "Return 1 if an error condition has been encountered for a given | file and 0 otherwise" | The implementation however seems to behave just like matlab does. | Also, the second (optional) input parameter is not documented. | I suggest the following help text. See it as a start of discussion: | | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | [errormessage] = ferror(fid) | [errormessage,errorcode] = ferror(fid) | ...= ferror(fid,command) | | Checks if the last operation on file given by file handle fid resulted | in error. If there was no error, errormessage will be empty and | errorcode set to 0. If there was an error, errormessage is set | appropriately and errorcode is nonzero. | ??what about command?? | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | Also, the output is not assigned on invalid input such as an invalid fid | or bad argument count. Instead of users having to wrap their calls to | ferror in try/catch, it would be better to set the output appropriately. | | I use debian 3.0.1 packaged by debian(lenny), but the report is valid | for the octave repository as well (checked today). The doc string is now: -- Built-in Function: [ERR, MSG] = ferror (FID, "clear") Return 1 if an error condition has been encountered for the file ID FID and 0 otherwise. Note that it will only return 1 if an error has already been encountered, not if the next operation will result in an error condition. The second argument is optional. If it is supplied, also clear the error condition. Thanks, jwe From jwe at octave.org Tue Nov 10 22:17:01 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 23:17:01 -0500 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <1257184471.3934.1.camel@sh-t400> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> <19183.549.952812.823846@segfault.lan> <69d8d540911020911r6287f8b0r977776f582b5f41f@mail.gmail.com> <1257184471.3934.1.camel@sh-t400> Message-ID: <19194.15037.131248.885303@segfault.lan> On 2-Nov-2009, S?ren Hauberg wrote: | man, 02 11 2009 kl. 18:11 +0100, skrev Jaroslav Hajek: | > I think the BLAS and LAPACK are a little special in the sense that | > they're (AFAIK) the only strong requirement for Octave. If any other | > dependency is missing, Octave will build and work, though with some | > crippled functionality. | > OTOH, BLAS and LAPACK are now almost universally available, so maybe | > nobody actually needs this feature. In that case, I think it's fine to | > drop these sources. It will also plausibly reduce Octave's code size. | | One advantage of dropping BLAS and LAPACK from the sources is that the | user don't end up using these by accident instead of using the system | libraries. I committed the following changeset which removes the subset of the reference BLAS and LAPACK sources from the Octave source tree: http://hg.savannah.gnu.org/hgweb/octave/rev/cfd0aa788ae1 If somehow people think that any further discussion about this is needed, then please use the maintainers list. Thanks, jwe From alxgel at gmail.com Wed Nov 11 11:52:16 2009 From: alxgel at gmail.com (AlexG1) Date: Wed, 11 Nov 2009 09:52:16 -0800 (PST) Subject: 'pkg install ...' failure Octave 3.2/Vista SP2 In-Reply-To: <24223422.post@talk.nabble.com> References: <24223422.post@talk.nabble.com> Message-ID: <26305579.post@talk.nabble.com> bzink wrote: > > The following snippet may indicate a bug in Octave 3.2 on MS Vista > (Ultimate, SP2). Note: In spite of the message, the octave installation > directory (and sub-directories) is not write-protected. > >> pkg install -verbose -global java-1.2.6.tar.gz > error: Permission denied > terminate called after throwing an instance of > 'octave_execution_exception' > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > panic: Aborted -- stopping myself... > attempting to save variables to `octave-core'... > save to `octave-core' complete > error: Permission denied > terminate called after throwing an instance of > 'octave_execution_exception' > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > panic: Aborted -- stopping myself... > attempting to save variables to `octave-core'... > save to `octave-core' complete > error: Permission denied > terminate called after throwing an instance of > 'octave_execution_exception' > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > panic: Aborted -- stopping myself... > attempting to save variables to `octave-core'... > save to `octave-core' complete > error: memory exhausted or requested size too large for range of Octave's > index type -- trying to return to prompt > > Hi, Did you/anyone ever manager to solve that? Getting the same error on Vista SP1 -- View this message in context: http://old.nabble.com/%27pkg-install-...%27-failure-Octave-3.2-Vista-SP2-tp24223422p26305579.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From lindnerben at gmx.net Wed Nov 11 12:31:50 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 11 Nov 2009 19:31:50 +0100 Subject: 'pkg install ...' failure Octave 3.2/Vista SP2 In-Reply-To: <26305579.post@talk.nabble.com> References: <24223422.post@talk.nabble.com> <26305579.post@talk.nabble.com> Message-ID: <4AFB0316.9090406@gmx.net> > > Hi, > > Did you/anyone ever manager to solve that? Getting the same error on Vista > SP1 Since I cannot reproduce this error you need do more debugging yourself. For example you could use sysinternals filemonitor or processmonitor to check which file operation is failing with a access denied error. benjamin From alxgel at gmail.com Wed Nov 11 13:21:38 2009 From: alxgel at gmail.com (AlexG1) Date: Wed, 11 Nov 2009 11:21:38 -0800 (PST) Subject: 'pkg install ...' failure Octave 3.2/Vista SP2 In-Reply-To: <4AFB0316.9090406@gmx.net> References: <24223422.post@talk.nabble.com> <26305579.post@talk.nabble.com> <4AFB0316.9090406@gmx.net> Message-ID: <26306961.post@talk.nabble.com> For now I just executed Octave in "Run as administrator" mode and it worked (although most of the java commands still don't work for me, which is a problem I've seen on another thread). -- View this message in context: http://old.nabble.com/%27pkg-install-...%27-failure-Octave-3.2-Vista-SP2-tp24223422p26306961.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From pr.nienhuis at hccnet.nl Wed Nov 11 15:43:15 2009 From: pr.nienhuis at hccnet.nl (Philip Nienhuis) Date: Wed, 11 Nov 2009 22:43:15 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <69d8d540911071225k74342fc0jc815d4e5317c91a5@mail.gmail.com> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> <4AF48D6D.2040607@hccnet.nl> <69d8d540911071225k74342fc0jc815d4e5317c91a5@mail.gmail.com> Message-ID: <4AFB2FF3.6070206@hccnet.nl> (sorry for late response, my provider's email server was down for some days) Jaroslav Hajek wrote: > On Fri, Nov 6, 2009 at 9:56 PM, Philip Nienhuis wrote: >> Jaroslav Hajek wrote: >>> On Thu, Nov 5, 2009 at 11:22 PM, Philip Nienhuis wrote: >>>> >>> This is a mix-up of the "your ignorance" case and Octave's sometimes >>> too succint documentation. While the docstring for rmfield might give >>> you the impression that >>> rmfield(cc, "field3") >>> removes the field3 from cc, but this is not true. Remember (and this >>> is written in the manual) that Octave functions, be them built-in or >>> user scripts, *never* alter their arguments. There is no passing by >>> reference. When you pass a variable as a function argument, it behaves >>> *as if* a copy was made for all the values (in reality it's a lazy >>> copy). This very simple and natural scheme frees the Matlab language >>> of the object ownership problems seen, for instance, in Python or C#, >>> at the cost of sometimes sacrificing memory efficiency. >>> >>> rmfield does, in fact take a copy of the argument, remove the named >>> field from that copy and return the result, so >>> cc = rmfield (cc, "field3"); >>> is what you want. In the docstrings this is often not emphasized >>> because it's assumed to be a general principle. >> Yeah I should have realized this, sorry. >> I might have been distracted because removing fields from structures >> works through a function rmfield(), while adding fields only works >> through assignment >> [struct(:).newfield] = deal({cells}{:}) >> which does change the original. >> Part of my original bug report was motivated by all kind of corner cases >> with empty structs. To avoid having to repeatedly beware & take care of >> such cases I've created a script around this for my own use, because >> invoking something like: >> >> new_s = addfield (old_s, "nfield", [optional values]) >> >> is IMO a little more obvious than the assignment syntax above + variants >> for exceptions. >> > > How would that differ from setfield? * AFAICS & test, setfield() seems intended for assigning a value to individual field elements, but only one element at a time (= per call). Unless of course I again overlooked something. This becomes cumbersome if one wants to add a somewhat larger array to all field elements in a struct. * (A wrapper script around) [s.f] = deal({cell_values}) assigns values to all elements of a field in one swoop and can add fields too. But yes, some fine-grainedness might be lost. * And I think setfield's syntax isn't that obvious either; that is, the help text could be more helpful. A suggestion for an IMO more easily comprehensible example is attached - just fit it in between the function call description and the example. If you'd prefer I can send setfield.m with improved help section. (You're right about sometimes too succinct octave docs. Admittedly only after checking out Matlab's helpdesk it occurred to me how setfield works. Hopefully my little addition may help others to avoid such a surrender.) >>>> On a related note (empty lines skipped for brevity): >>>> >>>> octave-3.2.3.exe: #93 > AA = struct() >>>> AA = >>>> { >>>> } >>>> octave-3.2.3.exe: #96 > BB = struct("field1", {}) >> : >> >>>> BB = >>>> { >>>> 0x0 struct array containing the fields: >>>> field1 >>>> } >> : >> >>>> The results of size() and isempty() on AA and BB are IMO contrary to >>>> expectation. (But... fully Matlab r2007a-compatible!) >>>> >>>> Is this somehow logical (but beyond my sense for logic) or is it too far >>>> pursued Matlab compatibility? >>>> >>> It's logical. isempty simply tests whether any dimension is zero; it >>> doesn't test for the number of fields. Structs with no fields are not >>> much useful anyway, so I'd expect them to be very rare. >> (How does size()work in such a case? that one seems to convey the wrong >> info to isempty) ) ? >> Well, it's logical in the sense of "how octave works internally". Still >> I think it's a bit inconsistent from a user's point of view. A struct >> with no fields has "no dimensions" to test at all so should be reported >> "empty" with size 0. IMO, of course :-) >> > > No, that is not true. The number of fields is simply an independent > property of the structure. You may also think of it as an extra > dimension. You can have structs with no fields but arbitrary > dimensions. Admittedly, what is really missing is a function to query > the number of fields, say, nfields (s). Currently one needs length > (fieldnames (s)). I was thinking more of size(s) yielding misleading info about empty structs - perhaps because size(s) itself gets confused there. Again, matlab does the same so why worry... >> As I'm not in core octave development I suppose I'll have to wait until >> a next stable binary :-( (but I'm glad some stuff is solved already). >> > > Surely you don't *have to* wait - you can download the sources right > now and build Octave from them. > http://hg.savannah.gnu.org/hgweb/octave > > Honestly, setting up the build with all dependency libs is a > non-trivial task (at least if you want full functionality), but once > done, you can get new patches included very easily. Sure, I've done that for some time several years ago under linux and cygwin. However nowadays I'm mostly confined to Windows so I would need a MingW development setup first, and from what I've read so far that's still a bit too challenging for me. However my first priority is to get octave involved in procedures we'd otherwise do with Matlab. That replacement-attempt doesn't quite go without the odd fairly involved hitch. IOW it's non-trivial either :-) Thanks, Philip From jakub.kasse at tul.cz Wed Nov 11 16:07:15 2009 From: jakub.kasse at tul.cz (Jakub Kasse) Date: Wed, 11 Nov 2009 23:07:15 +0100 Subject: stairs(1:3) bug Message-ID: <9410328311.20091111230715@tul.cz> Bug report for Octave 3.2.3 configured for i686-pc-mingw32 Description: ----------- Try: stairs(1:3) And you get errors in plot.m in function __stairs__ on line 83: if (nargin == 1 || ischar (varargin{2})) And also some other error, probably as a consequence. Repeat-By: --------- As I wrote, try "stairs(1:3)" Fix: --- Instead of "nargin==1" replace by "nargin==2" on line 83. The source of the mistake is probably in the definition of function __stairs__: function [h, xs, ys] = __stairs__ (doplot, varargin) When it is called from line 70: [h, xxs, yys] = __stairs__ (true, varargin{:}); Then the "nargin" is always greater or equal 2 because of "doplot" and at least one parameter in "varargin". In case of "stairs(1:3)" the "nargin" on line 83 is 2, "varargin" is "1:3" and "varargin(2)" doesn't exist. I'm not on your mailing list. Please confirm this email. Bye, Jakub Configuration (please do not edit this section): ----------------------------------------------- uname output: Windows configure opts: Fortran compiler: mingw32-gfortran-4.4.0-dw2 FFLAGS: -O -mieee-fp FLIBS: -lgfortran CPPFLAGS: INCFLAGS: -I. -I/octmgw32/octave/octave-3.2.3 -I. -I./liboctave -I./src -I./libcruft/misc -I/octmgw32/octave/octave-3.2.3 -I/octmgw32/octave/octave-3.2.3/liboctave -I/octmgw32/octave/octave-3.2.3/src -I/octmgw32/octave/octave-3.2.3/libcruft/misc C compiler: mingw32-gcc-4.4.0-dw2, version4.4.0 (GCC) CFLAGS: -march=i686 -mtune=generic -O3 -Wall CPICFLAG: C++ compiler: mingw32-g++-4.4.0-dw2, version4.4.0 CXXFLAGS: -D_GLIBCXX_DLL -march=i686 -mtune=generic -O3 -Wall CXXPICFLAG: LD_CXX: mingw32-g++-4.4.0-dw2 LDFLAGS: -shared-libgcc -Wl,--allow-multiple-definition LIBFLAGS: -L. RLD_FLAG: BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -liberty -lhdf5 -lz -lm -lgdi32 -lws2_32 -luser32 -lkernel32 LEXLIB: LIBGLOB: -lglob SED: /usr/bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=';' -DSEPCHAR_STR=";" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -Duid_t=int -Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1 -DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_MKSTEMPS=1 -DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 -D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_COPYSIGN=1 -DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=1 -DHAVE__COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1 -DRETSIGTYPE_IS_VOID=1 User-preferences (please do not edit this section): EDITOR = C:\Octave\3.2.3_gcc4.4.0\tools\notepad++\notepad++.exe EXEC_PATH = C:\Octave\3.2.3_gcc4.4.0\MINGW32\bin;C:\Octave\3.2.3_gcc4.4.0\MSYS\bin;C:\Octave\3.2.3_gcc4.4.0\libexec\octave\3.2.3\site\exec\i686-pc-mingw32;C:\Octave\3.2.3_gcc4.4.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Octave\3.2.3_gcc4.4.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Octave\3.2.3_gcc4.4.0\libexec\octave\3.2.3\exec\i686-pc-mingw32;C:\Octave\3.2.3_gcc4.4.0\bin;C:\Program Files\PC Connectivity Solution\;C:\Program Files\Siemens\Common\bin;C:\Program Files\Siemens\STEP7\s7bin;C:\Program Files\RSA SecurID Token Common;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Siemens\DESIGO\Insight 3.0\Citect\Bin\;c:\Program Files\Microsoft SQL Server\80\Tools\Binn\;C:\LonWorks\bin;C:\Program Files\Common Files\Autodesk Shared\;C:\Program Files\OpenVPN\bin;C:\LONWORKS\BIN IMAGE_PATH = .;C:\Octave\3.2.3_gcc4.4.0\share\octave\3.2.3\imagelib PAGER = C:\Octave\3.2.3_gcc4.4.0\bin\less.exe PS1 = > PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = C:\Octave\3.2.3_gcc4.4.0\bin\gnuplot.exe # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = C:\Documents and Settings\xjxp.XJNB.000\.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = C:\Octave\3.2.3_gcc4.4.0\share\info\octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 0 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 1 From jwe at octave.org Wed Nov 11 16:52:53 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 17:52:53 -0500 Subject: stairs(1:3) bug In-Reply-To: <9410328311.20091111230715@tul.cz> References: <9410328311.20091111230715@tul.cz> Message-ID: <19195.16453.573287.17881@segfault.lan> On 11-Nov-2009, Jakub Kasse wrote: | Bug report for Octave 3.2.3 configured for i686-pc-mingw32 | | Description: | ----------- | | Try: | | stairs(1:3) | | And you get errors in plot.m in function __stairs__ on line 83: | | if (nargin == 1 || ischar (varargin{2})) | | And also some other error, probably as a consequence. | | | Repeat-By: | --------- | | As I wrote, try "stairs(1:3)" | | Fix: | --- | | Instead of "nargin==1" replace by "nargin==2" on line 83. The source | of the mistake is probably in the definition of function __stairs__: | | function [h, xs, ys] = __stairs__ (doplot, varargin) | | When it is called from line 70: | | [h, xxs, yys] = __stairs__ (true, varargin{:}); | | Then the "nargin" is always greater or equal 2 because of "doplot" and | at least one parameter in "varargin". In case of "stairs(1:3)" the | "nargin" on line 83 is 2, "varargin" is "1:3" and "varargin(2)" | doesn't exist. I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/965487e00282 Jaroslav, this could probably be applied to the 3.2.x branch. Thanks, jwe From mason_thomas at hotmail.com Wed Nov 11 17:09:00 2009 From: mason_thomas at hotmail.com (Mason Thomas) Date: Wed, 11 Nov 2009 15:09:00 -0800 Subject: typo in intwarning documentation Message-ID: Hi, the user manual for Octave has a tiny error:the description of "intwarning" (page 44-45 of the pdf manual) describes the "off" option as turning math warnings "on". This should be "off". -Mason _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091111/53cb6173/attachment-0001.html From jwe at octave.org Wed Nov 11 19:15:28 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 20:15:28 -0500 Subject: typo in intwarning documentation In-Reply-To: References: Message-ID: <19195.25008.965281.337564@segfault.lan> On 11-Nov-2009, Mason Thomas wrote: | Hi, | the user manual for Octave has a tiny error:the description of "intwarning" (page 44-45 of the pdf manual) describes the "off" option as turning math warnings "on". This should be "off". I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/7c211d0091d9 jwe From highegg at gmail.com Wed Nov 11 23:56:16 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 12 Nov 2009 06:56:16 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <4AFB2FF3.6070206@hccnet.nl> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> <4AF48D6D.2040607@hccnet.nl> <69d8d540911071225k74342fc0jc815d4e5317c91a5@mail.gmail.com> <4AFB2FF3.6070206@hccnet.nl> Message-ID: <69d8d540911112156x3052724exb4449b9dd808dce5@mail.gmail.com> On Wed, Nov 11, 2009 at 10:43 PM, Philip Nienhuis wrote: > (sorry for late response, my provider's email server was down for some > days) > > Jaroslav Hajek wrote: > > On Fri, Nov 6, 2009 at 9:56 PM, Philip Nienhuis > wrote: > >> Jaroslav Hajek wrote: > >>> On Thu, Nov 5, 2009 at 11:22 PM, Philip Nienhuis < > pr.nienhuis at hccnet.nl> wrote: > >>>> part) > : > > >>> This is a mix-up of the "your ignorance" case and Octave's sometimes > >>> too succint documentation. While the docstring for rmfield might give > >>> you the impression that > >>> rmfield(cc, "field3") > >>> removes the field3 from cc, but this is not true. Remember (and this > >>> is written in the manual) that Octave functions, be them built-in or > >>> user scripts, *never* alter their arguments. There is no passing by > >>> reference. When you pass a variable as a function argument, it behaves > >>> *as if* a copy was made for all the values (in reality it's a lazy > >>> copy). This very simple and natural scheme frees the Matlab language > >>> of the object ownership problems seen, for instance, in Python or C#, > >>> at the cost of sometimes sacrificing memory efficiency. > >>> > >>> rmfield does, in fact take a copy of the argument, remove the named > >>> field from that copy and return the result, so > >>> cc = rmfield (cc, "field3"); > >>> is what you want. In the docstrings this is often not emphasized > >>> because it's assumed to be a general principle. > >> Yeah I should have realized this, sorry. > >> I might have been distracted because removing fields from structures > >> works through a function rmfield(), while adding fields only works > >> through assignment > >> [struct(:).newfield] = deal({cells}{:}) > >> which does change the original. > >> Part of my original bug report was motivated by all kind of corner cases > >> with empty structs. To avoid having to repeatedly beware & take care of > >> such cases I've created a script around this for my own use, because > >> invoking something like: > >> > >> new_s = addfield (old_s, "nfield", [optional values]) > >> > >> is IMO a little more obvious than the assignment syntax above + variants > >> for exceptions. > >> > > > > How would that differ from setfield? > > * AFAICS & test, setfield() seems intended for assigning a value to > individual field elements, but only one element at a time (= per call). > Unless of course I again overlooked something. This becomes cumbersome > if one wants to add a somewhat larger array to all field elements in a > struct. > It seems you're right. Gosh, what a useless function. > > * (A wrapper script around) [s.f] = deal({cell_values}) assigns values > to all elements of a field in one swoop and can add fields too. But yes, > some fine-grainedness might be lost. > > Yes, that is the preferred way. You can even bypass deal and just do [s.f] = c{:} where c is a cell array. > * And I think setfield's syntax isn't that obvious either; that is, the > help text could be more helpful. > A suggestion for an IMO more easily comprehensible example is attached - > just fit it in between the function call description and the example. > If you'd prefer I can send setfield.m with improved help section. > > Sorry, no attachment arrived. > (You're right about sometimes too succinct octave docs. Admittedly only > after checking out Matlab's helpdesk it occurred to me how setfield > works. Hopefully my little addition may help others to avoid such a > surrender.) > > > >>>> On a related note (empty lines skipped for brevity): > >>>> > >>>> octave-3.2.3.exe: #93 > AA = struct() > >>>> AA = > >>>> { > >>>> } > >>>> octave-3.2.3.exe: #96 > BB = struct("field1", {}) > >> : > >> > >>>> BB = > >>>> { > >>>> 0x0 struct array containing the fields: > >>>> field1 > >>>> } > >> : > >> > >>>> The results of size() and isempty() on AA and BB are IMO contrary to > >>>> expectation. (But... fully Matlab r2007a-compatible!) > >>>> > >>>> Is this somehow logical (but beyond my sense for logic) or is it too > far > >>>> pursued Matlab compatibility? > >>>> > >>> It's logical. isempty simply tests whether any dimension is zero; it > >>> doesn't test for the number of fields. Structs with no fields are not > >>> much useful anyway, so I'd expect them to be very rare. > >> (How does size()work in such a case? that one seems to convey the wrong > >> info to isempty) ) > > ? > > >> Well, it's logical in the sense of "how octave works internally". Still > >> I think it's a bit inconsistent from a user's point of view. A struct > >> with no fields has "no dimensions" to test at all so should be reported > >> "empty" with size 0. IMO, of course :-) > >> > > > > No, that is not true. The number of fields is simply an independent > > property of the structure. You may also think of it as an extra > > dimension. You can have structs with no fields but arbitrary > > dimensions. Admittedly, what is really missing is a function to query > > the number of fields, say, nfields (s). Currently one needs length > > (fieldnames (s)). > > I was thinking more of size(s) yielding misleading info about empty > structs - perhaps because size(s) itself gets confused there. > I don't know what you mean. size is not confused in any way - it just returns the correct dimensions. End of story. Number of fields is not a dimension. FWIW, I added a nfields () function to Octave that can be used to get the number of fields. > Again, matlab does the same so why worry... > > > > >> As I'm not in core octave development I suppose I'll have to wait until > >> a next stable binary :-( (but I'm glad some stuff is solved already). > >> > > > > Surely you don't *have to* wait - you can download the sources right > > now and build Octave from them. > > http://hg.savannah.gnu.org/hgweb/octave > > > > Honestly, setting up the build with all dependency libs is a > > non-trivial task (at least if you want full functionality), but once > > done, you can get new patches included very easily. > > Sure, I've done that for some time several years ago under linux and > cygwin. > > However nowadays I'm mostly confined to Windows so I would need a > MingW development setup first, and from what I've read so far that's > still a bit too challenging for me. > > However my first priority is to get octave involved in procedures we'd > otherwise do with Matlab. That replacement-attempt doesn't quite go > without the odd fairly involved hitch. IOW it's non-trivial either :-) > > Thanks, > > Philip > Yes, the benefits must outweigh the costs for you. That's up to you to decide. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091112/b060f567/attachment.html From cunninghamstats at gmail.com Thu Nov 12 01:12:34 2009 From: cunninghamstats at gmail.com (Helen Cunningham) Date: Wed, 11 Nov 2009 23:12:34 -0800 Subject: gnuplot bug on Macintosh Message-ID: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> Hi, This is to report a bug. The octave version I am using is 3.2.3. I am on an intel MacBook Pro 2.5 GHz Intel Core Duo Memory 4 GB 667 MHz DDR2 SDRAM running OSX 10.5.6 I am trying to run the octave command imshow(uint8(round(newimage))) It fails with the following error verbiage: sh: gnuplot: command not found error: you must have gnuplot installed to display graphics; if you have gnuplot installed in a non-standard location, see the 'gnuplot_binary' function sh: gnuplot: command not found error: you must have gnuplot installed to display graphics; if you have gnuplot installed in a non-standard location, see the 'gnuplot_binary' function This is a bug because I just installed gnuplot 4.2.3 on the mac by dragging it into the Applications folder, where it now sits. I have restarted octave and restarted the Mac since dragging it into Applications folder. Still getting the error. Don't know what else to do at this point. Thanks, Helen -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091111/45d2482f/attachment.html From daniel.arteaga at barcelonamedia.org Thu Nov 12 06:18:25 2009 From: daniel.arteaga at barcelonamedia.org (Daniel Arteaga) Date: Thu, 12 Nov 2009 13:18:25 +0100 Subject: Something wrong with the logical indexing of structure arrays Message-ID: <4AFBFD11.60805@barcelonamedia.org> 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. Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux wl071598 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux configure opts: '--build=i486-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=i486-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' Fortran compiler: gfortran FFLAGS: -O2 -g FLIBS: -lgfortranbegin -lgfortran CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.4.1 (Ubuntu 4.4.1-4ubuntu1) CFLAGS: -O2 -g CPICFLAG: -fPIC C++ compiler: g++, version 4.4.1 CXXFLAGS: -O2 -g CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: -Wl,-Bsymbolic-functions LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.2 BLAS_LIBS: -llapackgf-3 -lblas-3gf FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lblas-3gf -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/lib/octave/3.2.2/site/exec/i486-pc-linux-gnu:/usr/lib/octave/api-v37/site/exec/i486-pc-linux-gnu:/usr/lib/octave/site/exec/i486-pc-linux-gnu:/usr/lib/octave/3.2.2/exec/i486-pc-linux-gnu:/usr/bin:/home/daniel.arteaga/local/bin:/home/daniel.arteaga/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games IMAGE_PATH = .:/usr/share/octave/3.2.2/imagelib PAGER = pager PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/daniel.arteaga/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave3.2.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From tanas at zon1.physd.amu.edu.pl Thu Nov 12 03:57:26 2009 From: tanas at zon1.physd.amu.edu.pl (Ryszard Tanas) Date: Thu, 12 Nov 2009 10:57:26 +0100 (CET) Subject: octave3.2.3 gives segmentation fault on eig(M) Message-ID: <20091112095726.D24E9C28248@zon1.physd.amu.edu.pl> To: bug at octave.org Cc: tanas Subject: octave3.2.3 gives segmentation fault on eig(M) Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu Description: ----------- I upgraded octave to version 3.2.3 (binary package on Debian) and I get segmentation fault for eig(M) for some matrices Here is the program with the matrix M which gives the error Here is the program with the matrix M which gives the error --------------------------------------------------------------------- % program bug.m clear; M =[ -1.0,0.0,-0.95+9.30*i,0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0,0.0,0.0; 0.0,-1.0,0.0,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0,0.0,0.0; -0.95+9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0; 0.0,-0.95-9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0; 0.0,0.0,0.0,0.0,-2.0,0.0,-0.95-9.30*i,-0.95+9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,-2.0,-0.95+9.30*i,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,-0.95-9.30*i,-0.95+9.30*i,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; 0.0,0.0,0.0,0.0,-0.95+9.30*i,-0.95-9.30*i,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95+9.30*i,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95-9.30*i,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95+9.30*i,0.0,-3.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95-9.30*i,0.0,-3.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-4.0]; eig(M) -------------------------------------------------------------------- --------------------------------------------------------------------- % program bug.m clear; M =[ -1.0,0.0,-0.95+9.30*i,0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0,0.0,0.0; 0.0,-1.0,0.0,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0,0.0,0.0; -0.95+9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0; 0.0,-0.95-9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0; 0.0,0.0,0.0,0.0,-2.0,0.0,-0.95-9.30*i,-0.95+9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,-2.0,-0.95+9.30*i,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,-0.95-9.30*i,-0.95+9.30*i,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; 0.0,0.0,0.0,0.0,-0.95+9.30*i,-0.95-9.30*i,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95+9.30*i,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95-9.30*i,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95+9.30*i,0.0,-3.0,0.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95-9.30*i,0.0,-3.0,0.0; 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-4.0]; eig(M) -------------------------------------------------------------------- * Please replace this item with a detailed description of the problem. Suggestions or general comments are also welcome. Repeat-By: --------- * Please replace this item with a description of the sequence of events that causes the problem to occur. 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 zon1 2.6.31.4 #1 SMP Mon Oct 19 12:35:43 CEST 2009 x86_64 GNU/Linux configure opts: '--build=x86_64-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=x86_64-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' Fortran compiler: gfortran FFLAGS: -O2 -g FLIBS: -lgfortranbegin -lgfortran CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.4 (Debian 4.3.4-4) CFLAGS: -O2 -g CPICFLAG: -fPIC C++ compiler: g++, version 4.3.4 CXXFLAGS: -O2 -g CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 BLAS_LIBS: -llapackgf-3 -lblas-3gf FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/lib/octave/3.2.3/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/api-v37/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/3.2.3/exec/x86_64-pc-linux-gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib PAGER = pager PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/tanas/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave3.2.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From tmacchant at yahoo.co.jp Thu Nov 12 09:30:20 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Fri, 13 Nov 2009 00:30:20 +0900 (JST) Subject: octave3.2.3 gives segmentation fault on eig(M) In-Reply-To: <20091112095726.D24E9C28248@zon1.physd.amu.edu.pl> Message-ID: <20091112153020.91226.qmail@web3808.mail.bbt.yahoo.co.jp> Hello I have tested octave-3.2.3/ming32 (maintainer: Bejamin) with atlas with sse2. octave:1> clear; octave:2> M =[ > > -1.0,0.0,-0.95+9.30*i,0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0,0.0,0.0; > 0.0,-1.0,0.0,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0,0.0,0.0; > -0.95+9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0; > 0.0,-0.95-9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0; > 0.0,0.0,0.0,0.0,-2.0,0.0,-0.95-9.30*i,-0.95+9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,-2.0,-0.95+9.30*i,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,-0.95-9.30*i,-0.95+9.30*i,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; > 0.0,0.0,0.0,0.0,-0.95+9.30*i,-0.95-9.30*i,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95+9.30*i,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95-9.30*i,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95+9.30*i,0.0,-3.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95-9.30*i,0.0,-3.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-4.0]; octave:3> eig(M) ans = -0.05000 - 9.30000i -1.95000 + 9.30000i -1.95000 - 9.30000i -0.05000 + 9.30000i -2.00000 + 18.60000i -2.00000 - 18.60000i -0.10000 - 0.00000i -3.90000 + 0.00000i -2.05000 - 9.30000i -3.95000 + 9.30000i -3.95000 - 9.30000i -2.05000 + 9.30000i -2.00000 + 0.00000i -2.00000 + 0.00000i -4.00000 + 0.00000i I think that it is not bug of octave itself. Perhaps it may be a problem of lapack and blas libraries. Please ask package manage maintainer at the Debian site or wait reply from those of maintainer of Debian package on this list. Regards Tatsuro --- Ryszard Tanas wrote: > To: bug at octave.org > Cc: tanas > Subject: octave3.2.3 gives segmentation fault on eig(M) > > Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu > > Description: > ----------- > I upgraded octave to version 3.2.3 (binary package on Debian) and I get segmentation fault > for eig(M) for some matrices > > Here is the program with the matrix M which gives the error > > > > Here is the program with the matrix M which gives the error > > --------------------------------------------------------------------- > % program bug.m > > clear; > M =[ > > -1.0,0.0,-0.95+9.30*i,0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0,0.0,0.0; > 0.0,-1.0,0.0,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0,0.0,0.0; > -0.95+9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0; > 0.0,-0.95-9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0; > 0.0,0.0,0.0,0.0,-2.0,0.0,-0.95-9.30*i,-0.95+9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,-2.0,-0.95+9.30*i,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,-0.95-9.30*i,-0.95+9.30*i,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; > 0.0,0.0,0.0,0.0,-0.95+9.30*i,-0.95-9.30*i,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95+9.30*i,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95-9.30*i,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95+9.30*i,0.0,-3.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95-9.30*i,0.0,-3.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-4.0]; > > eig(M) > > -------------------------------------------------------------------- > > --------------------------------------------------------------------- > % program bug.m > > clear; > M =[ > > -1.0,0.0,-0.95+9.30*i,0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0,0.0,0.0; > 0.0,-1.0,0.0,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0,0.0,0.0; > -0.95+9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89-18.61*i,0.0; > 0.0,-0.95-9.30*i,0.0,-1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.89+18.61*i,0.0,0.0; > 0.0,0.0,0.0,0.0,-2.0,0.0,-0.95-9.30*i,-0.95+9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,-2.0,-0.95+9.30*i,-0.95-9.30*i,0.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,-0.95-9.30*i,-0.95+9.30*i,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; > 0.0,0.0,0.0,0.0,-0.95+9.30*i,-0.95-9.30*i,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0,3.78; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-2.0,0.0,0.0,0.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95+9.30*i,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-3.0,0.0,-0.95-9.30*i,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95+9.30*i,0.0,-3.0,0.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-0.95-9.30*i,0.0,-3.0,0.0; > 0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-4.0]; > > eig(M) > > -------------------------------------------------------------------- > > > * Please replace this item with a detailed description of the > problem. Suggestions or general comments are also welcome. > > Repeat-By: > --------- > > * Please replace this item with a description of the sequence of > events that causes the problem to occur. > > 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 zon1 2.6.31.4 #1 SMP Mon Oct 19 12:35:43 CEST 2009 x86_64 GNU/Linux > configure opts: '--build=x86_64-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' > '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' > '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' > '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' > 'build_alias=x86_64-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' > 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' > Fortran compiler: gfortran > FFLAGS: -O2 -g > FLIBS: -lgfortranbegin -lgfortran > CPPFLAGS: > INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc > C compiler: gcc, version 4.3.4 (Debian 4.3.4-4) > CFLAGS: -O2 -g > CPICFLAG: -fPIC > C++ compiler: g++, version 4.3.4 > CXXFLAGS: -O2 -g > CXXPICFLAG: -fPIC > LD_CXX: g++ > LDFLAGS: > LIBFLAGS: -L. > RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 > BLAS_LIBS: -llapackgf-3 -lblas-3gf > FFTW_LIBS: -lfftw3 -lfftw3f > LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm > LEXLIB: > LIBGLOB: > SED: /bin/sed > DEFS: > > -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" > -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" > -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 > -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' > -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 > -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 > -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 > -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 > -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 > -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 > -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 > -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name > ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 > -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 > -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 > -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 > -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 > -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 > -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 > -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 > -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 > -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 > -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 > -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 > -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 > -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 > -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 > -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 > -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 > -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 > -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 > -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 > -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 > -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 > -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 > -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 > -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 > -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 > -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 > -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 > -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 > -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 > -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 > -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 > -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 > -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 > -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 > -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 > -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 > -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 > -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 > -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 > -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 > -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 > -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 > -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 > -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 > -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 > -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 > -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 > -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 > -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 > -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 > -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 > -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 > -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 > -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 > -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void > -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 > -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 > > User-preferences (please do not edit this section): > -------------------------------------------------- > > EDITOR = emacs > EXEC_PATH = > /usr/lib/octave/3.2.3/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/api-v37/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/3.2.3/exec/x86_64-pc-linux-gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games > IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib > PAGER = pager > PS1 = \s:\#> > PS2 = > > PS4 = + > beep_on_error = 0 > completion_append_char = > crash_dumps_octave_core = 1 > echo_executing_commands = 0 > fixed_point_format = 0 > gnuplot_binary = gnuplot > # gnuplot_command_end = > # gnuplot_command_plot = > # gnuplot_command_replot = > # gnuplot_command_splot = > # gnuplot_command_title = > # gnuplot_command_using = > # gnuplot_command_with = > history_file = /home/tanas/.octave_hist > history_size = 1024 > ignore_function_time_stamp = system > info_file = /usr/share/info/octave3.2.info > info_program = info > makeinfo_program = makeinfo > max_recursion_depth = 256 > output_max_field_width = 5 > output_precision = 5 > page_output_immediately = 0 > page_screen_output = 1 > # print_answer_id_name = > print_empty_dimensions = 1 > save_precision = 16 > saving_history = 1 > sighup_dumps_octave_core = 1 > sigterm_dumps_octave_core = 1 > silent_functions = 0 > split_long_rows = 1 > string_fill_char = > struct_levels_to_print = 2 > suppress_verbose_help_message = 0 > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From pr.nienhuis at hccnet.nl Thu Nov 12 15:37:41 2009 From: pr.nienhuis at hccnet.nl (Philip Nienhuis) Date: Thu, 12 Nov 2009 22:37:41 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <69d8d540911112156x3052724exb4449b9dd808dce5@mail.gmail.com> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> <4AF48D6D.2040607@hccnet.nl> <69d8d540911071225k74342fc0jc815d4e5317c91a5@mail.gmail.com> <4AFB2FF3.6070206@hccnet.nl> <69d8d540911112156x3052724exb4449b9dd808dce5@mail.gmail.com> Message-ID: <4AFC8025.9000901@hccnet.nl> Jaroslav Hajek wrote: > > > On Wed, Nov 11, 2009 at 10:43 PM, Philip Nienhuis > wrote: : : > >> invoking something like: > >> > >> new_s = addfield (old_s, "nfield", [optional values]) > >> > >> is IMO a little more obvious than the assignment syntax above + > variants > >> for exceptions. > >> > > > > How would that differ from setfield? > > * AFAICS & test, setfield() seems intended for assigning a value to > individual field elements, but only one element at a time (= per call). > Unless of course I again overlooked something. This becomes cumbersome > if one wants to add a somewhat larger array to all field elements in a > struct. > > It seems you're right. Gosh, what a useless function. If so, getfield() may also be superfluous. But I'll hold my breath, perhaps both ARE useful for corner cases. And, uhm, Matlab compatibility of course (is that a corner case?) > * (A wrapper script around) [s.f] = deal({cell_values}) assigns values > to all elements of a field in one swoop and can add fields too. But yes, > some fine-grainedness might be lost. > > > Yes, that is the preferred way. You can even bypass deal and just do > [s.f] = c{:} > where c is a cell array. ... but I found that doesn't always work. Apart from deal() I sometimes also needed (:) to the left of "=" like in [s(:).f] = deal(c{:}) To find out how to add fields to large structs & fill them simultaneously I experimented a lot; the above syntax is what always seemed to work OK - except for 1x1 and some empty structs. Which provoked my original posting. > * And I think setfield's syntax isn't that obvious either; that is, the > help text could be more helpful. > A suggestion for an IMO more easily comprehensible example is attached - > just fit it in between the function call description and the example. > If you'd prefer I can send setfield.m with improved help section. > > > Sorry, no attachment arrived. Yes. sorry for that. Another try then. I also attached some additional help text for rmfield() (that may also benefit from additional info). As rmfield is built-in, I cannot adapt it myself. Philip -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rmfield_texinfo.txt Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091112/6b792435/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setfield_texinfo.txt Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091112/6b792435/attachment-0001.txt From thomas.weber.mail at gmail.com Thu Nov 12 16:02:58 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Thu, 12 Nov 2009 23:02:58 +0100 Subject: octave3.2.3 gives segmentation fault on eig(M) In-Reply-To: <20091112095726.D24E9C28248@zon1.physd.amu.edu.pl> References: <20091112095726.D24E9C28248@zon1.physd.amu.edu.pl> Message-ID: <20091112220258.GA9661@atlan> On Thu, Nov 12, 2009 at 10:57:26AM +0100, Ryszard Tanas wrote: > To: bug at octave.org > Cc: tanas > Subject: octave3.2.3 gives segmentation fault on eig(M) > > Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu > > Description: > ----------- > I upgraded octave to version 3.2.3 (binary package on Debian) and I get segmentation fault > for eig(M) for some matrices Confirmed. I don't know the reason yet. Please file a bug in Debian using "reportbug". Thanks Thomas (Debian maintainer) From thomas.weber.mail at gmail.com Thu Nov 12 16:25:31 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Thu, 12 Nov 2009 23:25:31 +0100 Subject: octave3.2.3 gives segmentation fault on eig(M) In-Reply-To: <20091112220258.GA9661@atlan> References: <20091112095726.D24E9C28248@zon1.physd.amu.edu.pl> <20091112220258.GA9661@atlan> Message-ID: <20091112222531.GA21521@atlan> On Thu, Nov 12, 2009 at 11:02:58PM +0100, Thomas Weber wrote: > On Thu, Nov 12, 2009 at 10:57:26AM +0100, Ryszard Tanas wrote: > > To: bug at octave.org > > Cc: tanas > > Subject: octave3.2.3 gives segmentation fault on eig(M) > > > > Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu > > > > Description: > > ----------- > > I upgraded octave to version 3.2.3 (binary package on Debian) and I get segmentation fault > > for eig(M) for some matrices > > Confirmed. I don't know the reason yet. This seems to be related to Atlas. Please try removing it. > Please file a bug in Debian using "reportbug". That sentence still holds. Thomas From bungernut at gmail.com Thu Nov 12 16:02:24 2009 From: bungernut at gmail.com (bung) Date: Thu, 12 Nov 2009 14:02:24 -0800 (PST) Subject: plotyy force dataaspectratio In-Reply-To: <42125056345975885358814655966376748357-Webmail@me.com> References: <20091109111719.157640@gmx.net> <20091109140939.198130@gmx.net> <42125056345975885358814655966376748357-Webmail@me.com> Message-ID: <26327314.post@talk.nabble.com> I get the same result as the original poster, and definetly not an acceptable result using the 3.2.3 plotyy.m linked, I even checked with a deff with my installed version. The plot looks fine until you set limits on an axis. I have even managed to get the y-axis to shrink trying some things. Again I only see problems when I do something like set(ax(1),'ylim',[0,100]), see attached picture http://old.nabble.com/file/p26327314/plotyy_prob.jpg Ben Abbott wrote: > > On Monday, November 09, 2009, at 09:09AM, "Christoph Ellenberger" > wrote: >> >>-------- Original-Nachricht -------- >>> Datum: Mon, 09 Nov 2009 07:46:21 -0500 >>> Von: Ben Abbott >>> An: Christoph Ellenberger >>> CC: bug-octave at octave.org >>> Betreff: Re: plotyy force dataaspectratio >> >>> >>> On Nov 9, 2009, at 6:17 AM, Christoph Ellenberger wrote: >>> >>> > Hi, >>> > I am using the regular mingw snapshots for windows. Some of my >>> > scripts got broken when I updated from 3.2.0 to 3.2.2/3. It is about >>> > using two axis plots with plotyy. The problem is that after I change >>> > axis properties the plot of the second axis gets way too small (see >>> > fig). I traced it down to the update_position function in plotyy >>> > where the dataaspectratio property from the first axis is forced >>> > onto the second axis which does not make sense. Now I don't know >>> > what the intended behaviour of this function would have been or if >>> > the function is called somewhere with the wrong axes handles but as >>> > far as I understand it, it should be reverted to the 3.2.0 version >>> > as it only updates the positioning, which in my opinion does not >>> > change the aspectratio... >>> > >>> > 3.2.2/3 >>> > function update_position (h, d, ax2) >>> > persistent recursion = false; >>> > >>> > ## Don't allow recursion >>> > if (! recursion) >>> > unwind_protect >>> > recursion = true; >>> > position = get (h, "position"); >>> > view = get (h, "view"); >>> > dataaspectratio = get (h, "dataaspectratio"); >>> > oldposition = get (ax2, "position"); >>> > oldview = get (ax2, "view"); >>> > olddataaspectratio = get (ax2, "dataaspectratio"); >>> > if (! (isequal (position, oldposition) >>> > && isequal (view, oldview) >>> > && isequal (dataaspectratio, olddataaspectratio))) >>> > set (ax2, "position", position, >>> > "view", view, >>> > "dataaspectratio", dataaspectratio); >>> > endif >>> > unwind_protect_cleanup >>> > recursion = false; >>> > end_unwind_protect >>> > endif >>> > endfunction >>> > >>> > 3.2.0 and my suggestion >>> > function update_position (h, d, ax2) >>> > persistent recursion = false; >>> > >>> > ## Don't allow recursion >>> > if (! recursion) >>> > unwind_protect >>> > recursion = true; >>> > position = get (h, "position"); >>> > view = get (h, "view"); >>> > oldposition = get (ax2, "position"); >>> > oldview = get (ax2, "view"); >>> > if (! (isequal (position, oldposition) && isequal (view, >>> > oldview))) >>> > set (ax2, "position", position, "view", view); >>> > endif >>> > unwind_protect_cleanup >>> > recursion = false; >>> > end_unwind_protect >>> > endif >>> > endfunction >>> > >>> > thanks in advance >>> > christoph >>> >>> Please verify that your proposed change works for the demos. You can >>> do that by starting Octave and typing ... >>> >>> demo plotyy >>> >>> Also, it would be useful to add a new demo for your case. Can you give >>> us a simple example where 3.2.3 produces the wrong result? >>> >>> Ben >>> >> >>I tested the demos and they still work, though as I said the error might be at a different spot. Because the problem occurs when calling the axis command on the second axis itself (using the first works well), so it might be that the axis command is calling update_position with a wrong handle set, but I haven't actually found from where this function is called. I only saw that it is copying the dataaspectratio from axis1 to axis2 as it is called with h=handle axis1 and ax2=handle axis2 >> >>So here is my "simple example": >> >>x=1:8; >>y=7000:20:7140; >>y2=repmat(2,1,8); >>ax=plotyy(x,y,x,y2); >>lim=axis; >>lim(1:4)=[3 5 1 5]; >>axis(lim); >> >>My suggestion is just a workaround for the function as it is called right now, but wouldn't fix it if the idea of the reposition is to compare it with older axis properties, but to my idea of it it is not intended to copy the dataaspectratio if just the position of an axis is changed. >> >>kind regards >>christoph > > I tried your example with current version for 3.2.x. The result looks > correct to me. Meaning it is consistent with what Matlab produces. > > The current version for 3.2.x can be found at the like below. > > > http://hg.tw-math.de/release-3-2-x/file/fee95bb4ee94/scripts/plot/plotyy.m > > Ben > > > > > Ben > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > -- View this message in context: http://old.nabble.com/plotyy-force-dataaspectratio-tp26264727p26327314.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From pr.nienhuis at hccnet.nl Thu Nov 12 16:36:32 2009 From: pr.nienhuis at hccnet.nl (Philip Nienhuis) Date: Thu, 12 Nov 2009 23:36:32 +0100 Subject: ("paperorientation", "portrait") doesn't work onscreen but does when printed to hard copy Message-ID: <4AFC8DF0.2080901@hccnet.nl> (Windows XP SP3, octave 3.2.3 MingW binary from octave-forge) figure (1, "paperorientation", "portrait") has no effect on the size/orientation of gnuplot (& jhandles) window (the latter in an older octave 3.0.3 MSVC from octave-forge). Neither has set (gcf(), "paperorientation", "portrait") The plot windows keeps its landscape form, in spite of octave-3.2.3.exe: #34 > get(gcf(), "paperorientation") ans = portrait OK, manual resizing helps but when printing to file: print (1, "file.gif", "-dgif") the landscape orientation is back :-( Other formats I tried: type ---result--- - emf: landscape, wrong - png: landscape, wrong - svg: landscape, wrong - pdf: portrait, OK! (I have no ghostcript so couldn't try ps/eps) and printing from the gnuplot window (right click on icon in upper left, selecting "Options | Print...") has gnuplot stalled initially. Next, a "close" from octave makes gnuplot wake up, show a print conversation window (with proper portrait dimensions) and then a properly oriented plot comes out of my printer. Q: - Is this to be expected? (taking state of connection octave-gnuplot into account or whatever) - or have I missed something? How can I get plots in portrait orientation on my screen and in a file? Thanks, Philip From bpabbott at mac.com Thu Nov 12 19:19:33 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 12 Nov 2009 20:19:33 -0500 Subject: gnuplot bug on Macintosh In-Reply-To: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> References: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> Message-ID: <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> On Nov 12, 2009, at 2:12 AM, Helen Cunningham wrote: > Hi, > > This is to report a bug. The octave version I am using is 3.2.3. > I am on an intel MacBook Pro 2.5 GHz Intel Core Duo > Memory 4 GB 667 MHz DDR2 SDRAM > running OSX 10.5.6 > > I am trying to run the octave command > > imshow(uint8(round(newimage))) > > It fails with the following error verbiage: > > sh: gnuplot: command not found > error: you must have gnuplot installed to display graphics; if you have gnuplot installed in a non-standard location, see the 'gnuplot_binary' function > sh: gnuplot: command not found > error: you must have gnuplot installed to display graphics; if you have gnuplot installed in a non-standard location, see the 'gnuplot_binary' function > > This is a bug because I just installed gnuplot 4.2.3 on the mac by dragging it into the Applications folder, where it now sits. > I have restarted octave and restarted the Mac since dragging it into Applications folder. Still getting the error. > > Don't know what else to do at this point. > > Thanks, > Helen Hi Helen, I don't think it is a bug. The problem is that Octave does not know where your gnuplot is located. How did you install octave? Ben From cunninghamstats at gmail.com Thu Nov 12 22:52:10 2009 From: cunninghamstats at gmail.com (Helen Cunningham) Date: Thu, 12 Nov 2009 20:52:10 -0800 Subject: gnuplot bug on Macintosh In-Reply-To: <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> References: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> Message-ID: <10e22bac0911122052s14da6097n6e5ff915a2c29a09@mail.gmail.com> By dragging it onto the representation of the "Applications" folder in the .dmg window, according to the instructions in the window. On Thu, Nov 12, 2009 at 5:19 PM, Ben Abbott wrote: > > On Nov 12, 2009, at 2:12 AM, Helen Cunningham wrote: > > > Hi, > > > > This is to report a bug. The octave version I am using is 3.2.3. > > I am on an intel MacBook Pro 2.5 GHz Intel Core Duo > > Memory 4 GB 667 MHz DDR2 SDRAM > > running OSX 10.5.6 > > > > I am trying to run the octave command > > > > imshow(uint8(round(newimage))) > > > > It fails with the following error verbiage: > > > > sh: gnuplot: command not found > > error: you must have gnuplot installed to display graphics; if you have > gnuplot installed in a non-standard location, see the 'gnuplot_binary' > function > > sh: gnuplot: command not found > > error: you must have gnuplot installed to display graphics; if you have > gnuplot installed in a non-standard location, see the 'gnuplot_binary' > function > > > > This is a bug because I just installed gnuplot 4.2.3 on the mac by > dragging it into the Applications folder, where it now sits. > > I have restarted octave and restarted the Mac since dragging it into > Applications folder. Still getting the error. > > > > Don't know what else to do at this point. > > > > Thanks, > > Helen > > Hi Helen, > > I don't think it is a bug. The problem is that Octave does not know where > your gnuplot is located. > > How did you install octave? > > Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091112/585fd58f/attachment-0001.html From keay at ou.edu Fri Nov 13 00:09:01 2009 From: keay at ou.edu (Joel Keay) Date: Fri, 13 Nov 2009 00:09:01 -0600 Subject: Octave 3.2.3 - imagesc fails with uint16 matrices Message-ID: Bug report for Octave 3.2.3 configured for i386-apple-darwin10.0.0 Description: imagesc(eye(10,10,'uint16')) fails with the following errors: error: invalid value for array property "cdata" error: set: expecting argument 2 to be a property name error: set: expecting argument 4 to be a property name error: set: expecting argument 6 to be a property name error: called from: error: /opt/local/share/octave/3.2.3/m/image/__img__.m at line 57, column 7 error: /opt/local/share/octave/3.2.3/m/image/image.m at line 75, column 5 error: /opt/local/share/octave/3.2.3/m/image/imagesc.m at line 111, column 7 error: /opt/local/share/octave/3.2.3/m/image/imagesc.m at line 60, column 9 error: A(I): Index exceeds matrix dimension. error: called from: error: /opt/local/share/octave/3.2.3/m/plot/__go_draw_axes__.m at line 383, column 22 error: /opt/local/share/octave/3.2.3/m/plot/__go_draw_figure__.m at line 92, column 3 error: /opt/local/share/octave/3.2.3/m/plot/gnuplot_drawnow.m at line 91, column 5 This is similar to report - No bool matrices for imagesc in tip? by Thomas Weber-8 Oct 31, 2008; 10:46am imagesc also fails for images of class int16 and single which are other possible ML image formats. Repeat-By: --------- imagesc(eye(10,10,'uint16')) Fix: *** graphics.h.in.orig 2009-11-12 23:08:55.000000000 -0600 --- graphics.h.in 2009-11-12 23:10:57.000000000 -0600 *************** *** 3100,3105 **** --- 3100,3108 ---- cdata.add_constraint ("double"); cdata.add_constraint ("logical"); cdata.add_constraint ("uint8"); + cdata.add_constraint ("uint16"); + cdata.add_constraint ("int16"); + cdata.add_constraint ("single"); cdata.add_constraint (dim_vector (-1, -1)); cdata.add_constraint (dim_vector (-1, -1, 3)); } --- * 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: Darwin GrayGhost.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 i386 configure opts: '--prefix=/opt/local' '--enable-shared' '--enable-dl' '--with-hdf5' '--with-fftw' '--with-blas=-framework Accelerate' '--enable-static' '--enable-readline' '--with-zlib' '--with-glpk' '--with-curl' '--with-lapack' '--with-umfpack' '--with-colamd' '--with-ccolamd' '--with-cholmod' '--with-cxsparse' 'CC=/opt/local/bin/gcc-mp-4.4' 'CFLAGS=-O2 -m64' 'LDFLAGS=-L/opt/local/lib' 'CPPFLAGS=-I/opt/local/include' 'CXX=/opt/local/bin/g++-mp-4.4' 'CXXFLAGS=-O2 -m64' 'F77=/opt/local/bin/gfortran-mp-4.4' 'FFLAGS=-O2 -m64' Fortran compiler: /opt/local/bin/gfortran-mp-4.4 FFLAGS: -O2 -m64 -mieee-fp FLIBS: -L/opt/local/lib -L/opt/local/lib/gcc44/gcc/x86_64-apple-darwin10/4.4.2 -L/opt/local/lib/gcc44/gcc/x86_64-apple-darwin10/4.4.2/../../.. -lhdf5 -lz -lm -lgfortranbegin -lgfortran CPPFLAGS: -I/opt/local/include -I/opt/local/include INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: /opt/local/bin/gcc-mp-4.4, version 4.4.2 (GCC) CFLAGS: -O2 -m64 CPICFLAG: -fPIC C++ compiler: /opt/local/bin/g++-mp-4.4, version 4.4.2 CXXFLAGS: -O2 -m64 CXXPICFLAG: -fPIC LD_CXX: /opt/local/bin/g++-mp-4.4 LDFLAGS: -L/opt/local/lib LIBFLAGS: -L. RLD_FLAG: BLAS_LIBS: FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /opt/local/bin/gsed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_FRAMEWORK_OPENGL=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_UFSPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_UFSPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DHAVE_UFSPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_UFSPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_UFSPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_UFSPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_DYLD_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = gvim EXEC_PATH = /opt/local/libexec/octave/3.2.3/site/exec/i386-apple-darwin10.0.0:/opt/local/libexec/octave/api-v37/site/exec/i386-apple-darwin10.0.0:/opt/local/libexec/octave/site/exec/i386-apple-darwin10.0.0:/opt/local/libexec/octave/3.2.3/exec/i386-apple-darwin10.0.0:/opt/local/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/Users/keay/bin IMAGE_PATH = .:/opt/local/share/octave/3.2.3/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /Users/keay/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /opt/local/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 1 page_screen_output = 0 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From highegg at gmail.com Fri Nov 13 00:34:09 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 13 Nov 2009 07:34:09 +0100 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <4AFC8025.9000901@hccnet.nl> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> <4AF48D6D.2040607@hccnet.nl> <69d8d540911071225k74342fc0jc815d4e5317c91a5@mail.gmail.com> <4AFB2FF3.6070206@hccnet.nl> <69d8d540911112156x3052724exb4449b9dd808dce5@mail.gmail.com> <4AFC8025.9000901@hccnet.nl> Message-ID: <69d8d540911122234hc1cc46cj5726129b117e8ba5@mail.gmail.com> On Thu, Nov 12, 2009 at 10:37 PM, Philip Nienhuis wrote: > Jaroslav Hajek wrote: > >> >> >> On Wed, Nov 11, 2009 at 10:43 PM, Philip Nienhuis > pr.nienhuis at hccnet.nl>> wrote: >> > : > > > : > >> >> invoking something like: >> >> >> >> new_s = addfield (old_s, "nfield", [optional values]) >> >> >> >> is IMO a little more obvious than the assignment syntax above + >> variants >> >> for exceptions. >> >> >> > >> > How would that differ from setfield? >> >> * AFAICS & test, setfield() seems intended for assigning a value to >> individual field elements, but only one element at a time (= per call). >> Unless of course I again overlooked something. This becomes cumbersome >> if one wants to add a somewhat larger array to all field elements in a >> struct. >> >> It seems you're right. Gosh, what a useless function. >> > > If so, getfield() may also be superfluous. > But I'll hold my breath, perhaps both ARE useful for corner cases. > And, uhm, Matlab compatibility of course (is that a corner case?) > > > * (A wrapper script around) [s.f] = deal({cell_values}) assigns values >> to all elements of a field in one swoop and can add fields too. But >> yes, >> some fine-grainedness might be lost. >> >> >> Yes, that is the preferred way. You can even bypass deal and just do >> [s.f] = c{:} >> where c is a cell array. >> > > ... but I found that doesn't always work. Apart from deal() I sometimes > also needed (:) to the left of "=" like in [s(:).f] = deal(c{:}) > > Sorry, but such comments (that something sometimes doesn't work) are virtually useless. Show me where it doesn't work and I'll either try to fix that or explain why it is so. > To find out how to add fields to large structs & fill them simultaneously I > experimented a lot; the above syntax is what always seemed to work OK - > except for 1x1 and some empty structs. Which provoked my original posting. > > example? where it doesn't work? > > * And I think setfield's syntax isn't that obvious either; that is, the >> help text could be more helpful. >> A suggestion for an IMO more easily comprehensible example is attached >> - >> just fit it in between the function call description and the example. >> If you'd prefer I can send setfield.m with improved help section. >> >> >> Sorry, no attachment arrived. >> > > Yes. sorry for that. Another try then. > I also attached some additional help text for rmfield() (that may also > benefit from additional info). As rmfield is built-in, I cannot adapt it > myself. > > Philip > > > ## > ## Note: to remove fields in nested structs, specify the substruct at > ## both sides of the "=" sign, e.g.: > ## @example > ## a.b.c = rmfield (a.b.c, "oldfld"); > ## @end example > > ## @example > ## pp = struct ("f1", @{"a", 3@}); > ## pp = setfield (pp, @{1, 2@}, "f2", (8)); > ## pp.f2 > ## => ans = [](0x0) > ## ans = 8 > ## (which adds a field f2 to struct pp and assigns value 8 > ## to the second element of pp.f2. The other elements of > ## pp.f2 will be filled with empty values) > ## @end example > ## > ## Note: to add fields in nested structs, specify the substruct at > ## both sides of the "=" sign, e.g.: > ## @example > ## a.b.c = setfield (a.b.c, @{2, 3@}, "nwfld", []); > ## @end example > ## > ## A more complicated example: > thanks. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091113/98b5a4b8/attachment.html From Thomas.Treichl at gmx.net Fri Nov 13 01:24:24 2009 From: Thomas.Treichl at gmx.net (Thomas Treichl) Date: Fri, 13 Nov 2009 08:24:24 +0100 Subject: gnuplot bug on Macintosh In-Reply-To: <10e22bac0911122052s14da6097n6e5ff915a2c29a09@mail.gmail.com> References: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> <10e22bac0911122052s14da6097n6e5ff915a2c29a09@mail.gmail.com> Message-ID: <4AFD09A8.5030902@gmx.net> Helen Cunningham schrieb: > By dragging it onto the representation of the "Applications" folder in > the .dmg window, according to the instructions in the window. > > On Thu, Nov 12, 2009 at 5:19 PM, Ben Abbott > wrote: > > > On Nov 12, 2009, at 2:12 AM, Helen Cunningham wrote: > > > Hi, > > > > This is to report a bug. The octave version I am using is 3.2.3. > > I am on an intel MacBook Pro 2.5 GHz Intel Core Duo > > Memory 4 GB 667 MHz DDR2 SDRAM > > running OSX 10.5.6 > > > > I am trying to run the octave command > > > > imshow(uint8(round(newimage))) > > > > It fails with the following error verbiage: > > > > sh: gnuplot: command not found > > error: you must have gnuplot installed to display graphics; if > you have gnuplot installed in a non-standard location, see the > 'gnuplot_binary' function > > sh: gnuplot: command not found > > error: you must have gnuplot installed to display graphics; if > you have gnuplot installed in a non-standard location, see the > 'gnuplot_binary' function > > > > This is a bug because I just installed gnuplot 4.2.3 on the mac > by dragging it into the Applications folder, where it now sits. > > I have restarted octave and restarted the Mac since dragging it > into Applications folder. Still getting the error. > > > > Don't know what else to do at this point. > > > > Thanks, > > Helen > > Hi Helen, > > I don't think it is a bug. The problem is that Octave does not know > where your gnuplot is located. > > How did you install octave? > > Ben Hi, please start up Octave.app and then type (or copy and paste) these commands into the command line interface of Octave and then send back the answers of these commands please: gnuplot_binary system ('which gnuplot') system ('echo $PATH') system ('ls /Applications/{Gnuplot.app,Octave.app}/Contents/Resources') Thomas From tanas at zon1.physd.amu.edu.pl Fri Nov 13 01:24:11 2009 From: tanas at zon1.physd.amu.edu.pl (Ryszard Tanas) Date: Fri, 13 Nov 2009 08:24:11 +0100 Subject: octave3.2.3 gives segmentation fault on eig(M) In-Reply-To: <20091112222531.GA21521@atlan> References: <20091112095726.D24E9C28248@zon1.physd.amu.edu.pl> <20091112220258.GA9661@atlan> <20091112222531.GA21521@atlan> Message-ID: <200911130824.11550.tanas@zon1.physd.amu.edu.pl> Dnia czwartek, 12 listopada 2009 o 23:25:31 napisa?e?: > On Thu, Nov 12, 2009 at 11:02:58PM +0100, Thomas Weber wrote: > > On Thu, Nov 12, 2009 at 10:57:26AM +0100, Ryszard Tanas wrote: > > > To: bug at octave.org > > > Cc: tanas > > > Subject: octave3.2.3 gives segmentation fault on eig(M) > > > > > > Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu > > > > > > Description: > > > ----------- > > > I upgraded octave to version 3.2.3 (binary package on Debian) and I get > > > segmentation fault for eig(M) for some matrices > > > > Confirmed. I don't know the reason yet. > > This seems to be related to Atlas. Please try removing it. Yes, this was caused by Atlas. Afrer removing Atlas it works! Thanks! Ryszard -- Ryszard Tanas Nonlinear Optics Division Institute of Physics Phone: +48 61 829-5184 Adam Mickiewicz University Fax: +48 61 829-5155 Umultowska 85, 61-614 Poznan, Poland From cunninghamstats at gmail.com Fri Nov 13 09:57:30 2009 From: cunninghamstats at gmail.com (Helen Cunningham) Date: Fri, 13 Nov 2009 07:57:30 -0800 Subject: gnuplot bug on Macintosh In-Reply-To: <4AFD09A8.5030902@gmx.net> References: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> <10e22bac0911122052s14da6097n6e5ff915a2c29a09@mail.gmail.com> <4AFD09A8.5030902@gmx.net> Message-ID: <10e22bac0911130757n5f2d5ba3ud9314e21c413db77@mail.gmail.com> Here's the path: /Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/3.2.3/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/api-v37/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/3.2.3/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/bin:/Users/hcc/Desktop/Octave.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin ans = 0 And it seems I have no {Gnuplot.app,Octave.app}/Contents/Resources in /Applications: octave-3.2.3:4> system ('ls /Applications/{Gnuplot.app,Octave.app}/Contents/Resources') ls: /Applications/Gnuplot.app/Contents/Resources: No such file or directory ls: /Applications/Octave.app/Contents/Resources: No such file or directory ans = 1 On Thu, Nov 12, 2009 at 11:24 PM, Thomas Treichl wrote: > Helen Cunningham schrieb: > >> By dragging it onto the representation of the "Applications" folder in the >> .dmg window, according to the instructions in the window. >> On Thu, Nov 12, 2009 at 5:19 PM, Ben Abbott > bpabbott at mac.com>> wrote: >> >> >> On Nov 12, 2009, at 2:12 AM, Helen Cunningham wrote: >> >> > Hi, >> > >> > This is to report a bug. The octave version I am using is 3.2.3. >> > I am on an intel MacBook Pro 2.5 GHz Intel Core Duo >> > Memory 4 GB 667 MHz DDR2 SDRAM >> > running OSX 10.5.6 >> > >> > I am trying to run the octave command >> > >> > imshow(uint8(round(newimage))) >> > >> > It fails with the following error verbiage: >> > >> > sh: gnuplot: command not found >> > error: you must have gnuplot installed to display graphics; if >> you have gnuplot installed in a non-standard location, see the >> 'gnuplot_binary' function >> > sh: gnuplot: command not found >> > error: you must have gnuplot installed to display graphics; if >> you have gnuplot installed in a non-standard location, see the >> 'gnuplot_binary' function >> > >> > This is a bug because I just installed gnuplot 4.2.3 on the mac >> by dragging it into the Applications folder, where it now sits. >> > I have restarted octave and restarted the Mac since dragging it >> into Applications folder. Still getting the error. >> > >> > Don't know what else to do at this point. >> > >> > Thanks, >> > Helen >> >> Hi Helen, >> >> I don't think it is a bug. The problem is that Octave does not know >> where your gnuplot is located. >> >> How did you install octave? >> >> Ben >> > > Hi, > > please start up Octave.app and then type (or copy and paste) these commands > into the command line interface of Octave and then send back the answers of > these commands please: > > gnuplot_binary > system ('which gnuplot') > system ('echo $PATH') > system ('ls /Applications/{Gnuplot.app,Octave.app}/Contents/Resources') > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091113/99de0092/attachment.html From jwe at octave.org Fri Nov 13 10:48:22 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 13 Nov 2009 11:48:22 -0500 Subject: Unexpected results when adding & removing fields to empty structs In-Reply-To: <4AFC8025.9000901@hccnet.nl> References: <4AF3502D.4050400@hccnet.nl> <69d8d540911060131i50536d41xa199a90f55cab042@mail.gmail.com> <4AF48D6D.2040607@hccnet.nl> <69d8d540911071225k74342fc0jc815d4e5317c91a5@mail.gmail.com> <4AFB2FF3.6070206@hccnet.nl> <69d8d540911112156x3052724exb4449b9dd808dce5@mail.gmail.com> <4AFC8025.9000901@hccnet.nl> Message-ID: <19197.36310.24412.34871@segfault.lan> On 12-Nov-2009, Philip Nienhuis wrote: | Jaroslav Hajek wrote: | > | > On Wed, Nov 11, 2009 at 10:43 PM, Philip Nienhuis > wrote: | > | > * AFAICS & test, setfield() seems intended for assigning a value to | > individual field elements, but only one element at a time (= per call). | > Unless of course I again overlooked something. This becomes cumbersome | > if one wants to add a somewhat larger array to all field elements in a | > struct. | > | > It seems you're right. Gosh, what a useless function. | | If so, getfield() may also be superfluous. | But I'll hold my breath, perhaps both ARE useful for corner cases. | And, uhm, Matlab compatibility of course (is that a corner case?) Before dynamic field name indexing was implemented in Matlab, setfield and getfield were provided to allow structure fields to be accessed without using eval when the field name is stored in a variable. I don't think they are really needed now, but are provided to avoid breaking existing code that uses them. jwe From Thomas.Treichl at gmx.net Fri Nov 13 12:51:38 2009 From: Thomas.Treichl at gmx.net (Thomas Treichl) Date: Fri, 13 Nov 2009 19:51:38 +0100 Subject: gnuplot bug on Macintosh In-Reply-To: <10e22bac0911130757n5f2d5ba3ud9314e21c413db77@mail.gmail.com> References: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> <10e22bac0911122052s14da6097n6e5ff915a2c29a09@mail.gmail.com> <4AFD09A8.5030902@gmx.net> <10e22bac0911130757n5f2d5ba3ud9314e21c413db77@mail.gmail.com> Message-ID: <4AFDAABA.3000805@gmx.net> Helen Cunningham schrieb: > Here's the path: > > /Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/3.2.3/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/api-v37/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/3.2.3/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/bin:/Users/hcc/Desktop/Octave.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin > ans = 0 > > And it seems I have no {Gnuplot.app,Octave.app}/Contents/Resources in > /Applications: > > octave-3.2.3:4> system ('ls > /Applications/{Gnuplot.app,Octave.app}/Contents/Resources') > ls: /Applications/Gnuplot.app/Contents/Resources: No such file or directory > ls: /Applications/Octave.app/Contents/Resources: No such file or directory > ans = 1 From your path information I see that you have not installed Octave.app in your Applications folder but on your Desktop. From the same path information I also see that you don't have installed Gnuplot.app on your Desktop, otherwise there would be said something about Gnuplot.app (Octave.app sets up the path of Gnuplot.app automatically if it is installed correctly in the same directory). Now, if you want to keep Octave.app on your Desktop then also put Gnuplot.app on your Desktop, otherwise Octave.app does not find Gnuplot.app... Thomas From jwe at octave.org Fri Nov 13 13:59:57 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 13 Nov 2009 14:59:57 -0500 Subject: Octave 3.2.3 - imagesc fails with uint16 matrices In-Reply-To: References: Message-ID: <19197.47805.50060.783770@segfault.lan> On 13-Nov-2009, Joel Keay wrote: | Bug report for Octave 3.2.3 configured for i386-apple-darwin10.0.0 | | Description: | | imagesc(eye(10,10,'uint16')) fails with the following errors: | | error: invalid value for array property "cdata" | error: set: expecting argument 2 to be a property name | error: set: expecting argument 4 to be a property name | error: set: expecting argument 6 to be a property name | error: called from: | error: /opt/local/share/octave/3.2.3/m/image/__img__.m at line 57, column 7 | error: /opt/local/share/octave/3.2.3/m/image/image.m at line 75, column 5 | error: /opt/local/share/octave/3.2.3/m/image/imagesc.m at line 111, column 7 | error: /opt/local/share/octave/3.2.3/m/image/imagesc.m at line 60, column 9 | error: A(I): Index exceeds matrix dimension. | error: called from: | error: /opt/local/share/octave/3.2.3/m/plot/__go_draw_axes__.m at line 383, column 22 | error: /opt/local/share/octave/3.2.3/m/plot/__go_draw_figure__.m at line 92, column 3 | error: /opt/local/share/octave/3.2.3/m/plot/gnuplot_drawnow.m at line 91, column 5 | | This is similar to report - No bool matrices for imagesc in tip? by Thomas Weber-8 Oct 31, 2008; 10:46am | | imagesc also fails for images of class int16 and single which are other possible ML image formats. | | Repeat-By: | --------- | | imagesc(eye(10,10,'uint16')) | | Fix: | | *** graphics.h.in.orig 2009-11-12 23:08:55.000000000 -0600 | --- graphics.h.in 2009-11-12 23:10:57.000000000 -0600 | *************** | *** 3100,3105 **** | --- 3100,3108 ---- | cdata.add_constraint ("double"); | cdata.add_constraint ("logical"); | cdata.add_constraint ("uint8"); | + cdata.add_constraint ("uint16"); | + cdata.add_constraint ("int16"); | + cdata.add_constraint ("single"); | cdata.add_constraint (dim_vector (-1, -1)); | cdata.add_constraint (dim_vector (-1, -1, 3)); | } I made this change, credited to you. Thanks, jwe From Thomas.Treichl at gmx.net Fri Nov 13 15:01:55 2009 From: Thomas.Treichl at gmx.net (Thomas Treichl) Date: Fri, 13 Nov 2009 22:01:55 +0100 Subject: gnuplot bug on Macintosh In-Reply-To: <10e22bac0911131252x54545387s460fabfa1f3e2c4a@mail.gmail.com> References: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> <10e22bac0911122052s14da6097n6e5ff915a2c29a09@mail.gmail.com> <4AFD09A8.5030902@gmx.net> <10e22bac0911130757n5f2d5ba3ud9314e21c413db77@mail.gmail.com> <4AFDAABA.3000805@gmx.net> <10e22bac0911131252x54545387s460fabfa1f3e2c4a@mail.gmail.com> Message-ID: <4AFDC943.8080507@gmx.net> Helen Cunningham schrieb: > Thanks for that. I now have both gnuplot and octave in the > Applications folder. > And now the command: > > imshow(uint8(round(newimage))) > > fails silently. No complaint, but no image either. The matrix > "newimage" is full of numbers. > Thanks, > Helen Please check the Readme.html of the Gnuplot*.dmg where I wrote about the one or other problem that might appear. Best regards Thomas -- Do I have to install AquaTerm.app before I install Gnuplot.app? In 99% of all cases there is absolutely no need to install AquaTerm.app manually. Gnuplot.app comes with AquaTerm.framework that is started automatically if you launch Gnuplot.app with GNUTERM=aqua and this should normally be enough. If no AquaTerm window opens while plotting then normally the reason might be that the environment variable GNUTERM=aqua is not set or has been set incorrectly. On a very small number of Mac systems an AquaTerm window is not opened at all. Therefore AquaTerm.app has been included into Gnuplot.app and that can be started automatically if Gnuplot.app's startup script /Contents/Resources/bin/gnuplot is modified. Change the lines # DYLD_FRAMEWORK_PATH="${ROOT}/lib:${DYLD_FRAMEWORK_PATH}" \ # open "${ROOT}/lib/AquaTerm.app" into DYLD_FRAMEWORK_PATH="${ROOT}/lib:${DYLD_FRAMEWORK_PATH}" \ open "${ROOT}/lib/AquaTerm.app" which will open AquaTerm.app automatically if you launch Gnuplot.app. From cunninghamstats at gmail.com Fri Nov 13 14:52:00 2009 From: cunninghamstats at gmail.com (Helen Cunningham) Date: Fri, 13 Nov 2009 12:52:00 -0800 Subject: gnuplot bug on Macintosh In-Reply-To: <4AFDAABA.3000805@gmx.net> References: <10e22bac0911112312r7949115cu69e1c60367c2f309@mail.gmail.com> <73000C3A-DB48-4E76-8199-A57B0BC1A944@mac.com> <10e22bac0911122052s14da6097n6e5ff915a2c29a09@mail.gmail.com> <4AFD09A8.5030902@gmx.net> <10e22bac0911130757n5f2d5ba3ud9314e21c413db77@mail.gmail.com> <4AFDAABA.3000805@gmx.net> Message-ID: <10e22bac0911131252x54545387s460fabfa1f3e2c4a@mail.gmail.com> Thanks for that. I now have both gnuplot and octave in the Applications folder. And now the command: imshow(uint8(round(newimage))) fails silently. No complaint, but no image either. The matrix "newimage" is full of numbers. Thanks, Helen On Fri, Nov 13, 2009 at 10:51 AM, Thomas Treichl wrote: > Helen Cunningham schrieb: > > Here's the path: >> >> /Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/3.2.3/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/api-v37/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/site/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/libexec/octave/3.2.3/exec/i386-apple-darwin8.11.1:/Users/hcc/Desktop/Octave.app/Contents/Resources/bin:/Users/hcc/Desktop/Octave.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin >> ans = 0 >> >> And it seems I have no {Gnuplot.app,Octave.app}/Contents/Resources in >> /Applications: >> >> octave-3.2.3:4> system ('ls >> /Applications/{Gnuplot.app,Octave.app}/Contents/Resources') >> ls: /Applications/Gnuplot.app/Contents/Resources: No such file or >> directory >> ls: /Applications/Octave.app/Contents/Resources: No such file or directory >> ans = 1 >> > > From your path information I see that you have not installed Octave.app in > your Applications folder but on your Desktop. From the same path information > I also see that you don't have installed Gnuplot.app on your Desktop, > otherwise there would be said something about Gnuplot.app (Octave.app sets > up the path of Gnuplot.app automatically if it is installed correctly in the > same directory). > > Now, if you want to keep Octave.app on your Desktop then also put > Gnuplot.app on your Desktop, otherwise Octave.app does not find > Gnuplot.app... > > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091113/672abf21/attachment.html From allen at transpireinc.com Fri Nov 13 18:17:38 2009 From: allen at transpireinc.com (Allen Barnett) Date: Fri, 13 Nov 2009 19:17:38 -0500 Subject: Fwd: Scrambled expm output Message-ID: <1258157859.2499.27.camel@alpaca.lan> Bug report for Octave 3.2.3 configured for i386-redhat-linux-gnu Description: ----------- expm(A) produces a matrix in which the elements are scrambled compared to the Taylor series expansion. Repeat-By: --------- Here is an example. A is lower triangular, so expm(A) should be lower triangular as well: ---------------------------------------------------------------------------- A=[-0.1, 0, 0, 0, 0, 0, 0, 0, 0, 0; 0.1, -5.000004e-3, 0, 0, 0, 0, 0, 0, 0, 0; 0, 5e-3, -1e-4, 0, 0, 0, 0, 0, 0, 0; 0, 4e-9, 0, -7e-3, 0, 0, 0, 0, 0, 0; 0, 0, 1e-4, 7e-3, -6e-3, 0, 0, 0, 0, 0; 0, 0, 0, 0, 6e-3, -3e-2, 0, 0, 0, 0; 0, 0, 0, 0, 0, 3e-2, -6e-2, 0, 0, 0; 0, 0, 0, 0, 0, 0, 6e-2, -3e-3, 0, 0; 0, 0, 0, 0, 0, 0, 0, 3e-3, -7e-2, 0; 0, 0, 0, 0, 0, 0, 0, 0, 7e-2, -3e-6]; B = expm(A) #{ Short Taylor series expansion #} id = eye(rows(A)); C = id + ( id + ( id + ( id + id /4 * A ) / 3 * A ) / 2 * A ) * A ---------------------------------------------------------------------------- If I compare B and C, the entries have the correct values but a couple of rows/columns of B appear to be out of order. In particular, note column 8; it is not lower triangular. B = Columns 1 through 8: 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00024 0.00499 0.00000 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00695 0.00010 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 0.00002 0.00000 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.99700 0.05815 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.00000 0.94176 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00289 0.00009 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00000 Columns 9 and 10: 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.93239 0.00000 0.06761 1.00000 C = Columns 1 through 8: 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00024 0.00499 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00695 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00002 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.94176 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.05815 0.99700 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.00289 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 Columns 9 and 10: 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.93239 0.00000 0.06761 1.00000 Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux guanaco 2.6.30.9-96.fc11.i586 #1 SMP Tue Nov 3 23:33:04 EST 2009 i686 i686 i386 GNU/Linux configure opts: '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--enable-shared' '--disable-static' '--enable-64=no' 'F77=gfortran' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables' 'CPPFLAGS=-DH5_USE_16_API' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables' 'FFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -I/usr/lib/gfortran/modules' Fortran compiler: gfortran FFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -I/usr/lib/gfortran/modules -mieee-fp FLIBS: -L/usr/lib/gcc/i586-redhat-linux/4.4.1 -L/usr/lib/gcc/i586-redhat-linux/4.4.1/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: -DH5_USE_16_API INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) CFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables CPICFLAG: -fPIC C++ compiler: g++, version 4.4.1 CXXFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/libexec/octave/3.2.3/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/api-v37/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/3.2.3/exec/i386-redhat-linux-gnu:/usr/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/allen/bin:/home/allen/transpire/bin:/home/allen/bin IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/allen/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From tmacchant at yahoo.co.jp Fri Nov 13 19:03:48 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 14 Nov 2009 10:03:48 +0900 (JST) Subject: Fwd: Scrambled expm output In-Reply-To: <1258157859.2499.27.camel@alpaca.lan> Message-ID: <20091114010352.20676.qmail@web3805.mail.bbt.yahoo.co.jp> Hello I have examined the test: Octave-3.2.3/mingw32 octave:2> B = expm(A) B = 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00024 0.00499 0.00000 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00695 0.00010 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00002 0.00000 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.99700 0.05815 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.00000 0.94176 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00289 0.00009 0.93239 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00000 0.06761 1.00000 Howver, octave-3.0.3 / msvc octave:2> B = expm(A) B = 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00024 0.00499 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00695 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00002 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.94176 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.05815 0.99700 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.00289 0.93239 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.06761 1.00000 Result of octave-3.0.3 seems to be correct. Is this bug newly imported when the version of octave has been upgraded from 3.0 to 3.2? Regards Tatsuro --- Allen Barnett wrote: > Bug report for Octave 3.2.3 configured for i386-redhat-linux-gnu > > Description: > ----------- > > expm(A) produces a matrix in which the elements are scrambled compared > to the Taylor series expansion. > > Repeat-By: > --------- > > Here is an example. A is lower triangular, so expm(A) should be lower > triangular as well: > ---------------------------------------------------------------------------- > A=[-0.1, 0, 0, 0, 0, 0, 0, 0, 0, 0; > 0.1, -5.000004e-3, 0, 0, 0, 0, 0, 0, 0, 0; > 0, 5e-3, -1e-4, 0, 0, 0, 0, 0, 0, 0; > 0, 4e-9, 0, -7e-3, 0, 0, 0, 0, 0, 0; > 0, 0, 1e-4, 7e-3, -6e-3, 0, 0, 0, 0, 0; > 0, 0, 0, 0, 6e-3, -3e-2, 0, 0, 0, 0; > 0, 0, 0, 0, 0, 3e-2, -6e-2, 0, 0, 0; > 0, 0, 0, 0, 0, 0, 6e-2, -3e-3, 0, 0; > 0, 0, 0, 0, 0, 0, 0, 3e-3, -7e-2, 0; > 0, 0, 0, 0, 0, 0, 0, 0, 7e-2, -3e-6]; > > B = expm(A) > #{ Short Taylor series expansion #} > id = eye(rows(A)); > C = id + ( id + ( id + ( id + id /4 * A ) / 3 * A ) / 2 * A ) * A > ---------------------------------------------------------------------------- > > If I compare B and C, the entries have the correct values but a couple > of rows/columns of B appear to be out of order. In particular, note > column 8; it is not lower triangular. > > B = > > Columns 1 through 8: > > 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00024 0.00499 0.00000 0.99990 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00695 0.00010 0.99402 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00002 0.00000 0.00589 0.97045 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.99700 0.05815 > 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.00000 0.94176 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00289 0.00009 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00000 > > Columns 9 and 10: > > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.93239 0.00000 > 0.06761 1.00000 > > C = > > Columns 1 through 8: > > 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00024 0.00499 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00010 0.00695 0.99402 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00002 0.00589 0.97045 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.94176 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.05815 0.99700 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.00289 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 > > Columns 9 and 10: > > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.00000 0.00000 > 0.93239 0.00000 > 0.06761 1.00000 > > > Configuration (please do not edit this section): > ----------------------------------------------- > > uname output: Linux guanaco 2.6.30.9-96.fc11.i586 #1 SMP Tue Nov 3 23:33:04 EST 2009 i686 > i686 i386 GNU/Linux > configure opts: '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' > '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' > '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' > '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' > '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' > '--infodir=/usr/share/info' '--enable-shared' '--disable-static' '--enable-64=no' 'F77=gfortran' > 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' > 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic > -fasynchronous-unwind-tables' 'CPPFLAGS=-DH5_USE_16_API' 'CXXFLAGS=-O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 > -march=i586 -mtune=generic -fasynchronous-unwind-tables' 'FFLAG! > S=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > -I/usr/lib/gfortran/modules' > Fortran compiler: gfortran > FFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > -I/usr/lib/gfortran/modules -mieee-fp > FLIBS: -L/usr/lib/gcc/i586-redhat-linux/4.4.1 > -L/usr/lib/gcc/i586-redhat-linux/4.4.1/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm > CPPFLAGS: -DH5_USE_16_API > INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc > C compiler: gcc, version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) > CFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > CPICFLAG: -fPIC > C++ compiler: g++, version 4.4.1 > CXXFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > CXXPICFLAG: -fPIC > LD_CXX: g++ > LDFLAGS: > LIBFLAGS: -L. > RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 > BLAS_LIBS: -llapack -lblas > FFTW_LIBS: -lfftw3 -lfftw3f > LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm > LEXLIB: > LIBGLOB: > SED: /bin/sed > DEFS: > > -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" > -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 > -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 > -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 > -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 > -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 > -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 > -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 > -DHAVE_FFTW3=1 -DHAVE_GLPK_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 > -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 > -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 > -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL=1 > -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name > ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 > -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 > -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 > -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 > -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 > -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 > -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 > -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 > -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 > -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 > -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 > -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 > -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 > -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 > -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 > -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 > -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 > -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 > -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 > -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 > -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 > -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 > -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 > -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 > -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 > -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 > -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 > -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 > -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 > -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 > -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 > -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 > -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 > -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 > -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 > -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 > -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 > -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 > -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 > -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 > -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 > -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 > -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 > -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 > -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 > -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 > -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 > -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 > -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 > -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 > -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 > -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 > -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 > -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 > -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 > -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void > -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 > -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 > > User-preferences (please do not edit this section): > -------------------------------------------------- > > EDITOR = emacs > EXEC_PATH = > /usr/libexec/octave/3.2.3/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/api-v37/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/3.2.3/exec/i386-redhat-linux-gnu:/usr/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin :/usr/local/sbin:/usr/sbin:/sbin:/home/allen/bin:/home/allen/transpire/bin:/home/allen/bin > IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib > PAGER = less > PS1 = \s:\#> > PS2 = > > PS4 = + > beep_on_error = 0 > completion_append_char = > crash_dumps_octave_core = 1 > echo_executing_commands = 0 > fixed_point_format = 0 > gnuplot_binary = gnuplot > # gnuplot_command_end = > # gnuplot_command_plot = > # gnuplot_command_replot = > # gnuplot_command_splot = > # gnuplot_command_title = > # gnuplot_command_using = > # gnuplot_command_with = > history_file = /home/allen/.octave_hist > history_size = 1024 > ignore_function_time_stamp = system > info_file = /usr/share/info/octave.info > info_program = info > makeinfo_program = makeinfo > max_recursion_depth = 256 > output_max_field_width = 5 > output_precision = 5 > page_output_immediately = 0 > page_screen_output = 1 > # print_answer_id_name = > print_empty_dimensions = 1 > save_precision = 16 > saving_history = 1 > sighup_dumps_octave_core = 1 > sigterm_dumps_octave_core = 1 > silent_functions = 0 > split_long_rows = 1 > string_fill_char = > struct_levels_to_print = 2 > suppress_verbose_help_message = 0 > > > > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From allen at transpireinc.com Fri Nov 13 20:23:44 2009 From: allen at transpireinc.com (Allen Barnett) Date: Fri, 13 Nov 2009 21:23:44 -0500 Subject: Fwd: Scrambled expm output In-Reply-To: <20091114010352.20676.qmail@web3805.mail.bbt.yahoo.co.jp> References: <20091114010352.20676.qmail@web3805.mail.bbt.yahoo.co.jp> Message-ID: <1258165424.2499.32.camel@alpaca.lan> Hi Tatsuro: I don't know if this is specific to version 3.2. This is the first time I have ever used Octave. Your version 3.0.3 results look correct to me. Thanks, Allen On Sat, 2009-11-14 at 10:03 +0900, Tatsuro MATSUOKA wrote: > Hello > > I have examined the test: > > Octave-3.2.3/mingw32 > octave:2> B = expm(A) > B = > > 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00024 0.00499 0.00000 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00695 0.00010 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00002 0.00000 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.99700 0.05815 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.00000 0.94176 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00289 0.00009 0.93239 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00000 0.06761 1.00000 > > Howver, octave-3.0.3 / msvc > octave:2> B = expm(A) > B = > > 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00024 0.00499 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00010 0.00695 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00002 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.94176 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.05815 0.99700 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.00289 0.93239 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.06761 1.00000 > > Result of octave-3.0.3 seems to be correct. > > Is this bug newly imported when the version of octave has been upgraded from 3.0 to 3.2? > > Regards > > Tatsuro > > --- Allen Barnett wrote: > > > Bug report for Octave 3.2.3 configured for i386-redhat-linux-gnu > > > > Description: > > ----------- > > > > expm(A) produces a matrix in which the elements are scrambled compared > > to the Taylor series expansion. > > > > Repeat-By: > > --------- > > > > Here is an example. A is lower triangular, so expm(A) should be lower > > triangular as well: > > ---------------------------------------------------------------------------- > > A=[-0.1, 0, 0, 0, 0, 0, 0, 0, 0, 0; > > 0.1, -5.000004e-3, 0, 0, 0, 0, 0, 0, 0, 0; > > 0, 5e-3, -1e-4, 0, 0, 0, 0, 0, 0, 0; > > 0, 4e-9, 0, -7e-3, 0, 0, 0, 0, 0, 0; > > 0, 0, 1e-4, 7e-3, -6e-3, 0, 0, 0, 0, 0; > > 0, 0, 0, 0, 6e-3, -3e-2, 0, 0, 0, 0; > > 0, 0, 0, 0, 0, 3e-2, -6e-2, 0, 0, 0; > > 0, 0, 0, 0, 0, 0, 6e-2, -3e-3, 0, 0; > > 0, 0, 0, 0, 0, 0, 0, 3e-3, -7e-2, 0; > > 0, 0, 0, 0, 0, 0, 0, 0, 7e-2, -3e-6]; > > > > B = expm(A) > > #{ Short Taylor series expansion #} > > id = eye(rows(A)); > > C = id + ( id + ( id + ( id + id /4 * A ) / 3 * A ) / 2 * A ) * A > > ---------------------------------------------------------------------------- > > > > If I compare B and C, the entries have the correct values but a couple > > of rows/columns of B appear to be out of order. In particular, note > > column 8; it is not lower triangular. > > > > B = > > > > Columns 1 through 8: > > > > 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > > 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > > 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 > > 0.00024 0.00499 0.00000 0.99990 0.00000 0.00000 0.00000 0.00000 > > 0.00000 0.00000 0.00695 0.00010 0.99402 0.00000 0.00000 0.00000 > > 0.00000 0.00000 0.00002 0.00000 0.00589 0.97045 0.00000 0.00000 > > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.99700 0.05815 > > 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.00000 0.94176 > > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00289 0.00009 > > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00000 > > > > Columns 9 and 10: > > > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.93239 0.00000 > > 0.06761 1.00000 > > > > C = > > > > Columns 1 through 8: > > > > 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > > 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > > 0.00024 0.00499 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 > > 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 > > 0.00000 0.00000 0.00010 0.00695 0.99402 0.00000 0.00000 0.00000 > > 0.00000 0.00000 0.00000 0.00002 0.00589 0.97045 0.00000 0.00000 > > 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.94176 0.00000 > > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.05815 0.99700 > > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.00289 > > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 > > > > Columns 9 and 10: > > > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.00000 0.00000 > > 0.93239 0.00000 > > 0.06761 1.00000 > > > > > > Configuration (please do not edit this section): > > ----------------------------------------------- > > > > uname output: Linux guanaco 2.6.30.9-96.fc11.i586 #1 SMP Tue Nov 3 23:33:04 EST 2009 i686 > > i686 i386 GNU/Linux > > configure opts: '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' > > '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' > > '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' > > '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' > > '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' > > '--infodir=/usr/share/info' '--enable-shared' '--disable-static' '--enable-64=no' 'F77=gfortran' > > 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' > > 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic > > -fasynchronous-unwind-tables' 'CPPFLAGS=-DH5_USE_16_API' 'CXXFLAGS=-O2 -g -pipe -Wall > > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 > > -march=i586 -mtune=generic -fasynchronous-unwind-tables' 'FFLAG! > > S=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > > -I/usr/lib/gfortran/modules' > > Fortran compiler: gfortran > > FFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > > -I/usr/lib/gfortran/modules -mieee-fp > > FLIBS: -L/usr/lib/gcc/i586-redhat-linux/4.4.1 > > -L/usr/lib/gcc/i586-redhat-linux/4.4.1/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm > > CPPFLAGS: -DH5_USE_16_API > > INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc > > C compiler: gcc, version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) > > CFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > > CPICFLAG: -fPIC > > C++ compiler: g++, version 4.4.1 > > CXXFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables > > CXXPICFLAG: -fPIC > > LD_CXX: g++ > > LDFLAGS: > > LIBFLAGS: -L. > > RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 > > BLAS_LIBS: -llapack -lblas > > FFTW_LIBS: -lfftw3 -lfftw3f > > LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm > > LEXLIB: > > LIBGLOB: > > SED: /bin/sed > > DEFS: > > > > -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" > > -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 > > -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > > -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 > > -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 > > -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 > > -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 > > -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 > > -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 > > -DHAVE_FFTW3=1 -DHAVE_GLPK_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 > > -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 > > -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 > > -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL=1 > > -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name > > ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 > > -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 > > -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 > > -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 > > -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 > > -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 > > -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 > > -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 > > -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 > > -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 > > -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 > > -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 > > -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 > > -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 > > -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 > > -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 > > -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 > > -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 > > -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 > > -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 > > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 > > -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 > > -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 > > -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 > > -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 > > -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 > > -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 > > -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 > > -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 > > -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 > > -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 > > -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 > > -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 > > -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 > > -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 > > -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 > > -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 > > -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 > > -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 > > -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 > > -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 > > -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 > > -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 > > -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 > > -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 > > -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 > > -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 > > -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 > > -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 > > -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 > > -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 > > -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 > > -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 > > -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 > > -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 > > -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 > > -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 > > -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 > > -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void > > -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 > > -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 > > > > User-preferences (please do not edit this section): > > -------------------------------------------------- > > > > EDITOR = emacs > > EXEC_PATH = > > > /usr/libexec/octave/3.2.3/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/api-v37/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/site/exec/i386-redhat-linux-gnu:/usr/libexec/octave/3.2.3/exec/i386-redhat-linux-gnu:/usr/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin > :/usr/local/sbin:/usr/sbin:/sbin:/home/allen/bin:/home/allen/transpire/bin:/home/allen/bin > > IMAGE_PATH = .:/usr/share/octave/3.2.3/imagelib > > PAGER = less > > PS1 = \s:\#> > > PS2 = > > > PS4 = + > > beep_on_error = 0 > > completion_append_char = > > crash_dumps_octave_core = 1 > > echo_executing_commands = 0 > > fixed_point_format = 0 > > gnuplot_binary = gnuplot > > # gnuplot_command_end = > > # gnuplot_command_plot = > > # gnuplot_command_replot = > > # gnuplot_command_splot = > > # gnuplot_command_title = > > # gnuplot_command_using = > > # gnuplot_command_with = > > history_file = /home/allen/.octave_hist > > history_size = 1024 > > ignore_function_time_stamp = system > > info_file = /usr/share/info/octave.info > > info_program = info > > makeinfo_program = makeinfo > > max_recursion_depth = 256 > > output_max_field_width = 5 > > output_precision = 5 > > page_output_immediately = 0 > > page_screen_output = 1 > > # print_answer_id_name = > > print_empty_dimensions = 1 > > save_precision = 16 > > saving_history = 1 > > sighup_dumps_octave_core = 1 > > sigterm_dumps_octave_core = 1 > > silent_functions = 0 > > split_long_rows = 1 > > string_fill_char = > > struct_levels_to_print = 2 > > suppress_verbose_help_message = 0 > > > > > > > > > > _______________________________________________ > > Bug-octave mailing list > > Bug-octave at octave.org > > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > > > > -------------------------------------- > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > http://pr.mail.yahoo.co.jp/gyao/ > -- Allen Barnett Transpire, Inc E-Mail: allen at transpireinc.com Skype: allenbarnett Ph: 518-887-2930 From j.d.smith at lancs.ac.uk Fri Nov 13 20:04:53 2009 From: j.d.smith at lancs.ac.uk (Jonathan Smith) Date: Sat, 14 Nov 2009 02:04:53 +0000 Subject: csapi/csape bug with 4 element vector Message-ID: <1258164293.2490.389.camel@phaal> Bug report for Octave 3.2.0 configured for x86_64-pc-linux-gnu csapi(x,y) and csape(x,y,'not-a-knot') seems to fail with length(x)=length(y)=4 The error is shown below. octave:1> csapi([1 2 3 4 ],[2 3 4 5],[3 4]) error: number of rows must match (1 != 2) near line 200, column 42 error: evaluating argument list element number 1 error: evaluating argument list element number 1 error: called from: error: /home/me/octave/splines-1.0.7/csape.m at line 200, column 20 error: /home/me/octave/splines-1.0.7/csapi.m at line 29, column 7 Possible solutions: Apart from checking the algorithm, which I'm not able to do at the mo I can think of three workarounds: 1: use spline function instead? I have an install of matlab and that is present, while csapi is not. 2: Perhaps a warning for the user in this case 3: Use something other than not-a-knot boundary conditions on csapi for length 4 vector. A spline fit in general is probably not a great deal of use for such a short dataset, but if a method is being applied consistently, the code should properly reject unreasonable input. My installation is a relatively up to date Gentoo x86_64 system, some details below, but it is remote from me at the moment, won't send mail using bug_report directly (as it doesn't have a sendmail client), so this is the potted version uname output: Linux thali 2.6.30-gentoo-r5 #5 SMP Sat Oct 10 11:40:41 BST 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Proc$ configure opts: '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--inf$ Fortran compiler: x86_64-pc-linux-gnu-gfortran FFLAGS: -O FLIBS: -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64 -L/lib/$ CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: x86_64-pc-linux-gnu-gcc, version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) CFLAGS: -O2 -march=athlon64 -pipe CPICFLAG: -fPIC C++ compiler: x86_64-pc-linux-gnu-g++, version 4.3.4 CXXFLAGS: -O2 -march=athlon64 -pipe CXXPICFLAG: -fPIC LD_CXX: x86_64-pc-linux-gnu-g++ LDFLAGS: -Wl,-O1 LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib64/octave-3.2.0 BLAS_LIBS: -llapack -lblas -latlas -lpthread -lcblas -lblas -latlas -lpthread FFTW_LIBS: LIBS: -lreadline -lncurses -ldl -lblas -latlas -lpthread -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = /bin/nano EXEC_PATH = /usr/libexec/octave/3.2.0/site/exec/x86_64-pc-linux-gnu:/usr/libexec/octave/api-v37/site/exec/x86_64-pc-linux-g$ IMAGE_PATH = .:/usr/share/octave/3.2.0/imagelib PAGER = /usr/bin/less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 Jonathan Smith From highegg at gmail.com Sat Nov 14 00:06:04 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Sat, 14 Nov 2009 07:06:04 +0100 Subject: Scrambled expm output In-Reply-To: <1258157859.2499.27.camel@alpaca.lan> References: <1258157859.2499.27.camel@alpaca.lan> Message-ID: <69d8d540911132206i5b2e8cfpa51e956b962169f5@mail.gmail.com> On Sat, Nov 14, 2009 at 1:17 AM, Allen Barnett wrote: > Bug report for Octave 3.2.3 configured for i386-redhat-linux-gnu > > Description: > ----------- > > expm(A) produces a matrix in which the elements are scrambled compared > to the Taylor series expansion. > > Hi, please try this patch: http://hg.savannah.gnu.org/hgweb/octave/rev/84398271118c regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091114/cc7ed6cc/attachment.html From tmacchant at yahoo.co.jp Sat Nov 14 05:32:32 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 14 Nov 2009 20:32:32 +0900 (JST) Subject: Scrambled expm output In-Reply-To: <69d8d540911132206i5b2e8cfpa51e956b962169f5@mail.gmail.com> Message-ID: <20091114113232.72405.qmail@web3802.mail.bbt.yahoo.co.jp> Hello Jaroslav At least for me, your patch works!! octave-3.0.3 / msvc octave:2> B = expm(A) B = 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00024 0.00499 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00695 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00002 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.94176 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.05815 0.99700 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.00289 0.93239 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.06761 1.00000 octave-3.2.3 with Jaroslav's Patch octave:2> B = expm(A) B = 0.90484 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.09492 0.99501 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00024 0.00499 0.99990 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.99302 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.00695 0.99402 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00002 0.00589 0.97045 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.02868 0.94176 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00087 0.05815 0.99700 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00009 0.00289 0.93239 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00010 0.06761 1.00000 Regards Tatsuro --- Jaroslav Hajek wrote: > On Sat, Nov 14, 2009 at 1:17 AM, Allen Barnett wrote: > > > Bug report for Octave 3.2.3 configured for i386-redhat-linux-gnu > > > > Description: > > ----------- > > > > expm(A) produces a matrix in which the elements are scrambled compared > > to the Taylor series expansion. > > > > > Hi, > please try this patch: > http://hg.savannah.gnu.org/hgweb/octave/rev/84398271118c > > regards > > -- > 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 > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From allen at transpireinc.com Sat Nov 14 13:46:32 2009 From: allen at transpireinc.com (Allen Barnett) Date: Sat, 14 Nov 2009 14:46:32 -0500 Subject: Scrambled expm output In-Reply-To: <69d8d540911132206i5b2e8cfpa51e956b962169f5@mail.gmail.com> References: <1258157859.2499.27.camel@alpaca.lan> <69d8d540911132206i5b2e8cfpa51e956b962169f5@mail.gmail.com> Message-ID: <1258227992.2499.36.camel@alpaca.lan> On Sat, 2009-11-14 at 07:06 +0100, Jaroslav Hajek wrote: > On Sat, Nov 14, 2009 at 1:17 AM, Allen Barnett > wrote: > Bug report for Octave 3.2.3 configured for > i386-redhat-linux-gnu > > Description: > ----------- > > expm(A) produces a matrix in which the elements are scrambled > compared > to the Taylor series expansion. > please try this patch: > http://hg.savannah.gnu.org/hgweb/octave/rev/84398271118c Hi Jaroslav: That looks good. Thanks! I guess I don't really understand what the line of code you changed is doing. Could you explain the difference between: r = r(p,p) and r(p,p) = r Thanks, Allen -- Allen Barnett Transpire, Inc E-Mail: allen at transpireinc.com Skype: allenbarnett Ph: 518-887-2930 From stefan-husmann at t-online.de Sun Nov 15 12:00:01 2009 From: stefan-husmann at t-online.de (Stefan Husmann) Date: Sun, 15 Nov 2009 19:00:01 +0100 Subject: Build error in mercurial version of octave. Message-ID: <4B0041A1.9060808@t-online.de> Hello, I get the follwing error when I try to build the mercurial version of octave Making all in faq make[3]: Entering directory `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' make[3]: F?r das Ziel ?all? ist nichts zu tun. make[3]: Leaving directory `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' Making all in interpreter make[3]: Entering directory `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter' ../../run-octave -f -q -H -p . --eval "sparseimages ('gplot', 'txt');" error: speye: /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/src/DLD-FUNCTIONS/sparse.oct: undefined symbol: _ZNK18octave_base_sparseI19SparseComplexMatrixE3mapEN17octave_base_value14unary_mapper_tE error: called from: error: /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/scripts/sparse/speye.m at line 50, column 5 error: /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m at line 59, column 5 error: /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m at line 27, column 7 revision 9819, architecture: x86_64, Arch Linux Regards Stefan Husmann From lists at schamschula.com Sun Nov 15 20:47:56 2009 From: lists at schamschula.com (Marius Schamschula) Date: Sun, 15 Nov 2009 20:47:56 -0600 Subject: Building octave 3.2.3 under Mac OS X 10.6.x Message-ID: <0E4954E1-DAA5-4DC1-961A-604908CBE71D@schamschula.com> Hi all, I've been off the bug-octave list for a while (my ISP inbox filled up while I was overseas). I had been trying to build octave 3.2.3 under Mac OS 10.6.x (Snow Leopard) using g95. This always fails: g95 is looking for 32 bit libraries, and there are none...(unless I rebuild a significant portion of my development tree using -m32) Now I'm trying to build using gcc 4.4 and gfortran. However I find the following 'warning': 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 get $ file /System/Library/Frameworks/Accelerate.framework/Versions/A/ Frameworks/vecLib.framework/Versions/A/libBLAS.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libBLAS.dylib: Mach-O fat file with 3 architectures I tried to send -ff2c with the gfortran command: to no avail. What puzzles me, is that arpack and qrupdate are linked to the same library and the configure script accepts them as functional. I would be grateful for any pointers, since building ATLAS is a pain. I stopped building it several years ago. -- Marius Schamschula From highegg at gmail.com Mon Nov 16 00:16:16 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 16 Nov 2009 07:16:16 +0100 Subject: Build error in mercurial version of octave. In-Reply-To: <4B0041A1.9060808@t-online.de> References: <4B0041A1.9060808@t-online.de> Message-ID: <69d8d540911152216p3311ba2axe131149eae4db4ea@mail.gmail.com> On Sun, Nov 15, 2009 at 7:00 PM, Stefan Husmann wrote: > Hello, > > I get the follwing error when I try to build the mercurial version of > octave > > Making all in faq > make[3]: Entering directory > `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' > make[3]: F?r das Ziel ?all? ist nichts zu tun. > make[3]: Leaving directory > `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' > Making all in interpreter > make[3]: Entering directory > `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter' > ../../run-octave -f -q -H -p . --eval "sparseimages ('gplot', 'txt');" > error: speye: > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/src/DLD-FUNCTIONS/sparse.oct: > undefined symbol: > _ZNK18octave_base_sparseI19SparseComplexMatrixE3mapEN17octave_base_value14unary_mapper_tE > error: called from: > error: > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/scripts/sparse/speye.m > at line 50, column 5 > error: > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m > at line 59, column 5 > error: > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m > at line 27, column 7 > > revision 9819, architecture: x86_64, Arch Linux > > Regards Stefan Husmann > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > Looks like a missing dependency problem. Did you build from scratch or just pull & rebuild? Try touch src/ov-{re,cx,bool}-sparse.cc and remake... -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091116/b56eedbd/attachment.html From marco.caliari at univr.it Mon Nov 16 03:49:12 2009 From: marco.caliari at univr.it (Marco Caliari) Date: Mon, 16 Nov 2009 10:49:12 +0100 (CET) Subject: Bug in balance (Was: Scrambled expm output) Message-ID: Dear Jaroslav, I've seen the problem with expm. It is not fixed yet, but I think the real problem is in balance. If you look at a = [0.26039 0 0 0;... 0.62561 0.48689 0.02351 0.24097;... 0.78732 0 0.19496 0;... 0.90438 0 0.45281 0.35363]; [dd,aa] = balance(a); [d, p, aa] = balance (a); norm(dd - eye(4)(p,:) * diag (d)) a = [0.13291 0 0 0.72285 0.29434 0.87083 0.29494;... 0.65094 0.67851 0.99559 0.68490 0.68669 0.85321 0.74209;... 0.95246 0 0.99473 0.55131 0.81216 0.71037 0.89993;... 0.47241 0 0 0.14610 0.65764 0.88557 0.17632;... 0 0 0 0 0.31210 0 0;... 0 0 0 0 0.35266 0.91154 0;... 0 0 0 0 0.58253 0.49922 0.52790]; [dd,aa] = balance(a); [d, p, aa] = balance (a); norm(dd - eye(7)(p,:) * diag (d)) you see that in the first case `dd' is not `eye(n)(p,:) * diag(d)', as stated in the doc of balance. In fact, it is `eye(n)(p,:) \ diag(d)'. But in the second case... the other way round (I'm using 3.2.3). Best regards, Marco From stefan-husmann at t-online.de Mon Nov 16 03:21:41 2009 From: stefan-husmann at t-online.de (Stefan Husmann) Date: Mon, 16 Nov 2009 10:21:41 +0100 Subject: Build error in mercurial version of octave. In-Reply-To: <69d8d540911152216p3311ba2axe131149eae4db4ea@mail.gmail.com> References: <4B0041A1.9060808@t-online.de> <69d8d540911152216p3311ba2axe131149eae4db4ea@mail.gmail.com> Message-ID: <4B0119A5.7020406@t-online.de> Jaroslav Hajek schrieb: > On Sun, Nov 15, 2009 at 7:00 PM, Stefan Husmann > wrote: > >> Hello, >> >> I get the follwing error when I try to build the mercurial version of >> octave >> >> Making all in faq >> make[3]: Entering directory >> `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' >> make[3]: F?r das Ziel ?all? ist nichts zu tun. >> make[3]: Leaving directory >> `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' >> Making all in interpreter >> make[3]: Entering directory >> `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter' >> ../../run-octave -f -q -H -p . --eval "sparseimages ('gplot', 'txt');" >> error: speye: >> /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/src/DLD-FUNCTIONS/sparse.oct: >> undefined symbol: >> _ZNK18octave_base_sparseI19SparseComplexMatrixE3mapEN17octave_base_value14unary_mapper_tE >> error: called from: >> error: >> /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/scripts/sparse/speye.m >> at line 50, column 5 >> error: >> /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m >> at line 59, column 5 >> error: >> /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m >> at line 27, column 7 >> >> revision 9819, architecture: x86_64, Arch Linux >> >> Regards Stefan Husmann >> _______________________________________________ >> Bug-octave mailing list >> Bug-octave at octave.org >> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave >> > > Looks like a missing dependency problem. Did you build from scratch or just > pull & rebuild? > Try > touch src/ov-{re,cx,bool}-sparse.cc > and remake... > This happens in both cases (rebuilding and building from scratch) and touching the suggested files does not change anything. Regards Stefan From highegg at gmail.com Mon Nov 16 20:21:35 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 17 Nov 2009 03:21:35 +0100 Subject: Build error in mercurial version of octave. In-Reply-To: <4B0119A5.7020406@t-online.de> References: <4B0041A1.9060808@t-online.de> <69d8d540911152216p3311ba2axe131149eae4db4ea@mail.gmail.com> <4B0119A5.7020406@t-online.de> Message-ID: <69d8d540911161821l6214d954td0c5035aedbc2ab9@mail.gmail.com> On Mon, Nov 16, 2009 at 10:21 AM, Stefan Husmann wrote: > Jaroslav Hajek schrieb: > > On Sun, Nov 15, 2009 at 7:00 PM, Stefan Husmann > > wrote: > > > >> Hello, > >> > >> I get the follwing error when I try to build the mercurial version of > >> octave > >> > >> Making all in faq > >> make[3]: Entering directory > >> > `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' > >> make[3]: F?r das Ziel ?all? ist nichts zu tun. > >> make[3]: Leaving directory > >> > `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/faq' > >> Making all in interpreter > >> make[3]: Entering directory > >> > `/home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter' > >> ../../run-octave -f -q -H -p . --eval "sparseimages ('gplot', 'txt');" > >> error: speye: > >> > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/src/DLD-FUNCTIONS/sparse.oct: > >> undefined symbol: > >> > _ZNK18octave_base_sparseI19SparseComplexMatrixE3mapEN17octave_base_value14unary_mapper_tE > >> error: called from: > >> error: > >> > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/scripts/sparse/speye.m > >> at line 50, column 5 > >> error: > >> > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m > >> at line 59, column 5 > >> error: > >> > /home/haawda/paketierung/maintained_by_me/octave-hg/src/octave-build/doc/interpreter/sparseimages.m > >> at line 27, column 7 > >> > >> revision 9819, architecture: x86_64, Arch Linux > >> > >> Regards Stefan Husmann > >> _______________________________________________ > >> Bug-octave mailing list > >> Bug-octave at octave.org > >> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > >> > > > > Looks like a missing dependency problem. Did you build from scratch or > just > > pull & rebuild? > > Try > > touch src/ov-{re,cx,bool}-sparse.cc > > and remake... > > > > This happens in both cases (rebuilding and building from scratch) and > touching the suggested > files does not change anything. > > It looks like the DLD file can't find the symbol. Please verify by ldd src/DLD-FUNCTIONS/sparse.oct that the correct dynamic library is referenced. Also, try nm src/DLD-FUNCTIONS/sparse.oct | grep "octave_base_sparse.*SparseComplexMatrix.*map" nm src/.libs/liboctinterp.so | grep "octave_base_sparse.*SparseComplexMatrix.*map" to verify that the missing symbol is really defined in the library. You should get something like U _ZNK18octave_base_sparseI19SparseComplexMatrixE3mapEN17octave_base_value14unary_mapper_tE 000000000072c810 W _ZNK18octave_base_sparseI19SparseComplexMatrixE3mapEN17octave_base_value14unary_mapper_tE regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091117/aedbc7e1/attachment.html From highegg at gmail.com Mon Nov 16 21:16:38 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 17 Nov 2009 04:16:38 +0100 Subject: Bug in balance (Was: Scrambled expm output) In-Reply-To: References: Message-ID: <69d8d540911161916j49438cc4u3a1f6a8918dd663e@mail.gmail.com> On Mon, Nov 16, 2009 at 10:49 AM, Marco Caliari wrote: > Dear Jaroslav, > > I've seen the problem with expm. It is not fixed yet, but I think the real > problem is in balance. If you look at > > a = [0.26039 0 0 0;... > 0.62561 0.48689 0.02351 0.24097;... > 0.78732 0 0.19496 0;... > 0.90438 0 0.45281 0.35363]; > [dd,aa] = balance(a); > [d, p, aa] = balance (a); > norm(dd - eye(4)(p,:) * diag (d)) > a = [0.13291 0 0 0.72285 0.29434 0.87083 0.29494;... > 0.65094 0.67851 0.99559 0.68490 0.68669 0.85321 0.74209;... > 0.95246 0 0.99473 0.55131 0.81216 0.71037 0.89993;... > 0.47241 0 0 0.14610 0.65764 0.88557 0.17632;... > 0 0 0 0 0.31210 0 0;... > 0 0 0 0 0.35266 0.91154 0;... > 0 0 0 0 0.58253 0.49922 0.52790]; > [dd,aa] = balance(a); > [d, p, aa] = balance (a); > norm(dd - eye(7)(p,:) * diag (d)) > > you see that in the first case `dd' is not `eye(n)(p,:) * diag(d)', as > stated in the doc of balance. In fact, it is `eye(n)(p,:) \ diag(d)'. But in > the second case... the other way round (I'm using 3.2.3). > > Best regards, > > Marco > Hi Marco, given that the scaling is like aa = dd \ a * dd, it should of course be dd = eye (n)(:,p) * diag (d); a patch is online: http://hg.savannah.gnu.org/hgweb/octave/rev/84199c9fc69c a regression test for balance would also be nice. thanks -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091117/c56fc4ee/attachment.html From hallc at lu.unisi.ch Tue Nov 17 07:39:22 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Tue, 17 Nov 2009 14:39:22 +0100 Subject: eigs crash on a particular spare matrix Message-ID: <1258465162.4564.39.camel@boulder> Ciao all- I've been happily using eigs for a couple months now and have never run into any problems. However I have recently run into a particular matrix that *sometimes* crashes octave *only* when both the eigenvalues and eigenvectors are requested. I.e. [V,S] = eigs(P); I have no idea where to start trying to find a minimal matrix that causes the error, so I've just posted the single (and only) matrix I've found that triggers the bug: http://www.inf.usi.ch/phd/hall/core-matrix.oct Just run eigs, with two output arguments, several times and you should experience the crash. I've confirmed the same behavior on two different machines, one an Intel 32-bit and the other a 64-bit Opteron, both running 3.2.3. Both builds of Octave are my own, so I also installed the latest Ubuntu package (3.2.2) and confirmed it has the same problem and that the valgrind trace looks very similar. I've posted a valgrind session with the same matrix. It can be found here: http://www.inf.usi.ch/phd/hall/octave-valgrind-bad-matrix-eigs.txt (ignore the libreadline off-by one read errors on startup - it appears readline needs some love) The session is from the 32-bit machine, but the errors are the same on the 64-bit box: A bunch of invalid writes from dlacpy_ in /usr/lib/liblapack.so.3gf.o, followed by invalid reads. Apparently the memory malloc uses eventually gets stomped on, as free or malloc eventually causes the program to crash in the end. The exactly free or malloc is non-deterministic. I am not using the known to be bad ubuntu version of atlas, and only have the non-optimized version installed - indeed, atlas isn't even installed on the x64 box and it has the same problem. When results are computed without a crash they are correct (taking matlab as correct). Cheers, Cyrus From marco_atzeri at yahoo.it Tue Nov 17 11:20:19 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Tue, 17 Nov 2009 17:20:19 +0000 (GMT) Subject: R: eigs crash on a particular spare matrix In-Reply-To: <1258465162.4564.39.camel@boulder> Message-ID: <629388.82991.qm@web25506.mail.ukl.yahoo.com> --- Mar 17/11/09, Cyrus Hall ha scritto: > Ciao all- > > I've been happily using eigs for a couple months now and > have never run > into any problems.? However I have recently run into a > particular matrix > that *sometimes* crashes octave *only* when both the > eigenvalues and > eigenvectors are requested.? I.e. > > [V,S] = eigs(P); > > I have no idea where to start trying to find a minimal > matrix that > causes the error, so I've just posted the single (and only) > matrix I've > found that triggers the bug: > > http://www.inf.usi.ch/phd/hall/core-matrix.oct > > Just run eigs, with two output arguments, several times and > you should > experience the crash.? I've confirmed the same > behavior on two different > machines, one an Intel 32-bit and the other a 64-bit > Opteron, both > running 3.2.3.? Both builds of Octave are my own, so I > also installed > the latest Ubuntu package (3.2.2) and confirmed it has the > same problem > and that the valgrind trace looks very similar. > > I've posted a valgrind session with the same matrix.? > It can be found > here: > > http://www.inf.usi.ch/phd/hall/octave-valgrind-bad-matrix-eigs.txt > > (ignore the libreadline off-by one read errors on startup - > it appears > readline needs some love) > > The session is from the 32-bit machine, but the errors are > the same on > the 64-bit box: A bunch of invalid writes from dlacpy_ > in /usr/lib/liblapack.so.3gf.o, followed by invalid > reads.? Apparently > the memory malloc uses eventually gets stomped on, as free > or malloc > eventually causes the program to crash in the end.? > The exactly free or > malloc is non-deterministic.? > > I am not using the known to be bad ubuntu version of atlas, > and only > have the non-optimized version installed - indeed, atlas > isn't even > installed on the x64 box and it has the same problem. > > When results are computed without a crash they are correct > (taking > matlab as correct). > > Cheers, > Cyrus > confirmed on octave 3.2.3 running on cygwin-1.7 it crashs after 4/5 repetition with both lapack 3.2.1 or atlas 3.9.16 libraries. Regards Marco From highegg at gmail.com Wed Nov 18 06:54:03 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 18 Nov 2009 13:54:03 +0100 Subject: eigs crash on a particular spare matrix In-Reply-To: <629388.82991.qm@web25506.mail.ukl.yahoo.com> References: <1258465162.4564.39.camel@boulder> <629388.82991.qm@web25506.mail.ukl.yahoo.com> Message-ID: <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> On Tue, Nov 17, 2009 at 6:20 PM, Marco Atzeri wrote: > --- Mar 17/11/09, Cyrus Hall ha scritto: > > > Ciao all- > > > > I've been happily using eigs for a couple months now and > > have never run > > into any problems. However I have recently run into a > > particular matrix > > that *sometimes* crashes octave *only* when both the > > eigenvalues and > > eigenvectors are requested. I.e. > > > > [V,S] = eigs(P); > > > > I have no idea where to start trying to find a minimal > > matrix that > > causes the error, so I've just posted the single (and only) > > matrix I've > > found that triggers the bug: > > > > http://www.inf.usi.ch/phd/hall/core-matrix.oct > > > > Just run eigs, with two output arguments, several times and > > you should > > experience the crash. I've confirmed the same > > behavior on two different > > machines, one an Intel 32-bit and the other a 64-bit > > Opteron, both > > running 3.2.3. Both builds of Octave are my own, so I > > also installed > > the latest Ubuntu package (3.2.2) and confirmed it has the > > same problem > > and that the valgrind trace looks very similar. > > > > I've posted a valgrind session with the same matrix. > > It can be found > > here: > > > > http://www.inf.usi.ch/phd/hall/octave-valgrind-bad-matrix-eigs.txt > > > > (ignore the libreadline off-by one read errors on startup - > > it appears > > readline needs some love) > > > > The session is from the 32-bit machine, but the errors are > > the same on > > the 64-bit box: A bunch of invalid writes from dlacpy_ > > in /usr/lib/liblapack.so.3gf.o, followed by invalid > > reads. Apparently > > the memory malloc uses eventually gets stomped on, as free > > or malloc > > eventually causes the program to crash in the end. > > The exactly free or > > malloc is non-deterministic. > > > > I am not using the known to be bad ubuntu version of atlas, > > and only > > have the non-optimized version installed - indeed, atlas > > isn't even > > installed on the x64 box and it has the same problem. > > > > When results are computed without a crash they are correct > > (taking > > matlab as correct). > > > > Cheers, > > Cyrus > > > > confirmed on octave 3.2.3 running on cygwin-1.7 > it crashs after 4/5 repetition with both lapack 3.2.1 or atlas > 3.9.16 libraries. > > Regards > Marco > > 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 -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091118/bc44a88e/attachment.html From hallc at lu.unisi.ch Wed Nov 18 07:38:27 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Wed, 18 Nov 2009 14:38:27 +0100 Subject: eigs crash on a particular spare matrix In-Reply-To: <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> References: <1258465162.4564.39.camel@boulder> <629388.82991.qm@web25506.mail.ukl.yahoo.com> <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> Message-ID: <1258551507.8612.47.camel@boulder> I fear you're quite likely right. I am just going to script around the problem, since restart my process if it crashes is cheaper than spending a week or two learning Fortran, ARPACK, and hunting this down. Do you think it would be useful for me to e-mail the ARPACK people with the same information? Also, does Matlab use ARPACK? I can't get it to crash on the same matrix. Cheers, Cyrus On Wed, 2009-11-18 at 13:54 +0100, 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. From individ at acc.umu.se Wed Nov 18 09:00:54 2009 From: individ at acc.umu.se (David Grundberg) Date: Wed, 18 Nov 2009 16:00:54 +0100 Subject: list_in_columns: Don't SIGFPE when given empty first argument Message-ID: <4B040C26.2030901@acc.umu.se> Hi, on current tip, running list_in_columns ({}); causes Octave to emit SIGFPE. I think it should return a string with an empty listing, and I made changes to this end. list_in_columns always ends its output with a newline, so I made sure it does this even on empty input. Regards, David -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: list_in_columns.changeset Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091118/24067912/attachment.ksh From Christoph.Mayer at dlr.de Wed Nov 18 07:11:34 2009 From: Christoph.Mayer at dlr.de (Christoph.Mayer at dlr.de) Date: Wed, 18 Nov 2009 14:11:34 +0100 Subject: possible bug Message-ID: <50B83E83C453D441BB265127DF5B561D5BFF04@exbe6.intra.dlr.de> Dear list, I have found an unusual behaviour of octave. I would assume that in the following script c and d should be equal? But they are not. I am using Octave 3.0.3. Any help is much appreciated. Best regards Christoph # -*- octave -*- function octave_bug a=100*[1 2; 3 4; 5 6] counter=1; for i=a' [counter i'] c{counter}=i'; d{counter}=1*i'; counter++; endfor c d endfunction Deutsches Zentrum f?r Luft- und Raumfahrt e.V. in der Helmholtz-Gemeinschaft Institut f?r Kommunikation und Navigation Dr. Christoph Mayer Kalkhorstweg 53 17235 Neustrelitz Telefon: ++49 3981 480 145 Telefax: ++49 3981 480 123 Internet: http://www.DLR.de/kn From jwe at octave.org Wed Nov 18 11:54:28 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 18 Nov 2009 12:54:28 -0500 Subject: possible bug In-Reply-To: <50B83E83C453D441BB265127DF5B561D5BFF04@exbe6.intra.dlr.de> References: <50B83E83C453D441BB265127DF5B561D5BFF04@exbe6.intra.dlr.de> Message-ID: <19204.13524.335517.811354@segfault.lan> On 18-Nov-2009, Christoph.Mayer at dlr.de wrote: | Dear list, | | I have found an unusual behaviour of octave. I would assume that in the following script c and d should be equal? But they are not. I am using Octave 3.0.3. | | Any help is much appreciated. | | Best regards | Christoph | | # -*- octave -*- | | function octave_bug | a=100*[1 2; 3 4; 5 6] | counter=1; | for i=a' | [counter i'] | c{counter}=i'; | d{counter}=1*i'; | counter++; | endfor | c | d | endfunction This problem is fixed in the current stable release, 3.2.3. I recommend that you upgrade to the newer version. jwe From highegg at gmail.com Wed Nov 18 14:40:12 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 18 Nov 2009 21:40:12 +0100 Subject: list_in_columns: Don't SIGFPE when given empty first argument In-Reply-To: <4B040C26.2030901@acc.umu.se> References: <4B040C26.2030901@acc.umu.se> Message-ID: <69d8d540911181240y5f19f39dtf4e56f867f2ed535@mail.gmail.com> On Wed, Nov 18, 2009 at 4:00 PM, David Grundberg wrote: > Hi, > > on current tip, running > > list_in_columns ({}); > > causes Octave to emit SIGFPE. > > I think it should return a string with an empty listing, and I made changes > to this end. list_in_columns always ends its output with a newline, so I > made sure it does this even on empty input. > > Regards, > David > I checked this patch in. thanks -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091118/e7c2511a/attachment.html From lists at schamschula.com Wed Nov 18 20:40:01 2009 From: lists at schamschula.com (Marius Schamschula) Date: Wed, 18 Nov 2009 20:40:01 -0600 Subject: BLAS under Mac OS X 10.6.x In-Reply-To: <0E4954E1-DAA5-4DC1-961A-604908CBE71D@schamschula.com> References: <0E4954E1-DAA5-4DC1-961A-604908CBE71D@schamschula.com> Message-ID: <1517BD14-ADE2-4E3E-95A1-84BCB311A680@schamschula.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091118/9e882f05/attachment.html From matthias at brennwald.org Thu Nov 19 01:17:43 2009 From: matthias at brennwald.org (Matthias Brennwald) Date: Thu, 19 Nov 2009 08:17:43 +0100 Subject: Octave crashing In-Reply-To: <19204.61267.902966.32946@segfault.lan> References: <19204.18249.576566.588595@segfault.lan> <420590EA-EC05-4696-9148-84E4C464DA0A@brennwald.org> <19204.61267.902966.32946@segfault.lan> Message-ID: On Nov 19, 2009, at 8:10 AM, John W. Eaton wrote: > On 19-Nov-2009, Matthias Brennwald wrote: > > | As a matter of fact, it does not happen anymore... I have no idea > why > | the problem is gone now. As far as I can tell I did not change > | anything. I tried running from different directories, but could not > | reproduce the error. > | > | > Is there a PKG_ADD or .octaverc file in the directory where you > are > | > starting Octave? If so, what is in those files? > | > | Yes, I do have an .octaverc file in my home directory. Here it is: > | > | --------------------- > | %%%% warning on Octave:matlab-incompatible % warn if using code that > | %%%% won't work with Matlab (it won't catch everything, though). > | addpath ('~/Matlab/') > | addpath ('~/Matlab/mcompartments/code') > | addpath ('~/Matlab/mcompartments/examples/example1') > | addpath ('~/Matlab/mcompartments/examples/example2') > | addpath ('~/Matlab/mcompartments/examples/example3') > | addpath ('~/Matlab/mataa/mataa_tools/') > | addpath ('~/Matlab/mataa/mataa_scripts/') > | addpath ('~/Matlab/matchromat/') > | addpath ('~/Matlab/matchromat/machines/') > | addpath ('~/Matlab/matchromat/machines/ANTRAWA/') > | addpath ('~/Matlab/cal_bottles/') > | addpath ('~/Matlab/matGSOD/'); > | addpath ('~/Matlab/m_map/'); > | addpath ('~/Matlab/m_map/private/'); > | --------------------- > > Your problem has the same symptoms as > > https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-August/009350.html > > Did you have a pkg command somewhere in a startup file when Octave > crashed? Not that I'd know of any. Where (except in my .octaverc file) could these be? > In any case, I can't duplicate the problem linked above. > > | > Also, it's best to report bugs to the bug at octave.org list. > | > | Yes, sure, but I am not sure it this really is a bug in Octave (it > | might just as well be me or some other software package on the > machine). > > The bug reporting guide says > > If you are not sure whether you have found a bug, here are some > guidelines: > > * If Octave gets a fatal signal, for any input whatever, that is > a bug. Reliable interpreters never crash. Aha, ok. I posted this message to the bug list. Matthias ---- Matthias Brennwald, K?ferholzstrasse 173, CH-8046 Z?rich, +41 44 364 17 03 From marco.caliari at univr.it Thu Nov 19 03:13:38 2009 From: marco.caliari at univr.it (Marco Caliari) Date: Thu, 19 Nov 2009 10:13:38 +0100 (CET) Subject: R: eigs crash on a particular sparse matrix Message-ID: > Ciao all- > > I've been happily using eigs for a couple months now and > have never run > into any problems. However I have recently run into a > particular matrix > that *sometimes* crashes octave *only* when both the > eigenvalues and > eigenvectors are requested. I.e. > > [V,S] = eigs(P); > > I have no idea where to start trying to find a minimal > matrix that > causes the error, so I've just posted the single (and only) > matrix I've > found that triggers the bug: > > http://www.inf.usi.ch/phd/hall/core-matrix.oct > > Just run eigs, with two output arguments, several times and > you should > experience the crash. I've confirmed the same > behavior on two different > machines, one an Intel 32-bit and the other a 64-bit > Opteron, both > running 3.2.3. Both builds of Octave are my own, so I > also installed > the latest Ubuntu package (3.2.2) and confirmed it has the > same problem > and that the valgrind trace looks very similar. > > I've posted a valgrind session with the same matrix. > It can be found > here: > > http://www.inf.usi.ch/phd/hall/octave-valgrind-bad-matrix-eigs.txt > > (ignore the libreadline off-by one read errors on startup - > it appears > readline needs some love) > > The session is from the 32-bit machine, but the errors are > the same on > the 64-bit box: A bunch of invalid writes from dlacpy_ > in /usr/lib/liblapack.so.3gf.o, followed by invalid > reads. Apparently > the memory malloc uses eventually gets stomped on, as free > or malloc > eventually causes the program to crash in the end. > The exactly free or > malloc is non-deterministic. > > I am not using the known to be bad ubuntu version of atlas, > and only > have the non-optimized version installed - indeed, atlas > isn't even > installed on the x64 box and it has the same problem. > > When results are computed without a crash they are correct > (taking > matlab as correct). > > Cheers, > Cyrus The same here, with Octave 3.2.3, lapack 3.1.1, atlas 3.8.3. As a trivial workaround, I found that > P(1,1)=P(1,1)+i*eps; does not crash anymore. Cheers, Marco From highegg at gmail.com Thu Nov 19 04:52:10 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 19 Nov 2009 11:52:10 +0100 Subject: BLAS under Mac OS X 10.6.x In-Reply-To: <1517BD14-ADE2-4E3E-95A1-84BCB311A680@schamschula.com> References: <0E4954E1-DAA5-4DC1-961A-604908CBE71D@schamschula.com> <1517BD14-ADE2-4E3E-95A1-84BCB311A680@schamschula.com> Message-ID: <69d8d540911190252k29f61a7cpa3c456e136c5e5d8@mail.gmail.com> On Thu, Nov 19, 2009 at 3:40 AM, Marius Schamschula 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091119/18d39efb/attachment.html From lists at schamschula.com Thu Nov 19 05:52:21 2009 From: lists at schamschula.com (Marius Schamschula) Date: Thu, 19 Nov 2009 05:52:21 -0600 Subject: BLAS under Mac OS X 10.6.x In-Reply-To: <69d8d540911190252k29f61a7cpa3c456e136c5e5d8@mail.gmail.com> References: <0E4954E1-DAA5-4DC1-961A-604908CBE71D@schamschula.com> <1517BD14-ADE2-4E3E-95A1-84BCB311A680@schamschula.com> <69d8d540911190252k29f61a7cpa3c456e136c5e5d8@mail.gmail.com> Message-ID: Jaroslav, The source is octave 3.2.3. Here is the config.log file: ? On Nov 19, 2009, at 4:52 AM, Jaroslav Hajek wrote: > > > On Thu, Nov 19, 2009 at 3:40 AM, Marius Schamschula > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091119/581e1f21/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/applefile Size: 73 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091119/581e1f21/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/x-gzip Size: 14233 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091119/581e1f21/attachment-0003.bin -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091119/581e1f21/attachment-0003.html From highegg at gmail.com Thu Nov 19 06:24:59 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 19 Nov 2009 13:24:59 +0100 Subject: BLAS under Mac OS X 10.6.x In-Reply-To: References: <0E4954E1-DAA5-4DC1-961A-604908CBE71D@schamschula.com> <1517BD14-ADE2-4E3E-95A1-84BCB311A680@schamschula.com> <69d8d540911190252k29f61a7cpa3c456e136c5e5d8@mail.gmail.com> Message-ID: <69d8d540911190424n7c49f812r7d7f982cef3367be@mail.gmail.com> On Thu, Nov 19, 2009 at 12:52 PM, Marius Schamschula 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091119/851911c5/attachment.html From dbateman at dbateman.org Thu Nov 19 13:32:07 2009 From: dbateman at dbateman.org (David Bateman) Date: Thu, 19 Nov 2009 20:32:07 +0100 Subject: eigs crash on a particular spare matrix In-Reply-To: <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> References: <1258465162.4564.39.camel@boulder> <629388.82991.qm@web25506.mail.ukl.yahoo.com> <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> Message-ID: <4B059D37.3000005@dbateman.org> 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) -------------- next part -------------- An embedded message was scrubbed... From: David Bateman Subject: Problem with ARPACK for unsymmetric matrices where the Ritz values need reordering Date: Fri, 03 Nov 2006 12:34:17 +0100 Size: 64808 Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091119/8f6fee41/attachment-0001.eml From peter at sonderport.dk Wed Nov 18 17:35:10 2009 From: peter at sonderport.dk (Peter L. =?ISO-8859-1?Q?S=F8ndergaard?=) Date: Thu, 19 Nov 2009 00:35:10 +0100 Subject: nargchk always fails Message-ID: <1258587310.2794.59.camel@katholt> 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. From jwe at octave.org Thu Nov 19 16:04:05 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 19 Nov 2009 17:04:05 -0500 Subject: nargchk always fails In-Reply-To: <1258587310.2794.59.camel@katholt> References: <1258587310.2794.59.camel@katholt> Message-ID: <19205.49365.262466.582390@segfault.lan> 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 From highegg at gmail.com Fri Nov 20 03:06:20 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 10:06:20 +0100 Subject: Something wrong with the logical indexing of structure arrays In-Reply-To: <4AFBFD11.60805@barcelonamedia.org> References: <4AFBFD11.60805@barcelonamedia.org> Message-ID: <69d8d540911200106k48a26705if918fe8274852a0b@mail.gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/12dcbe3b/attachment.html From highegg at gmail.com Fri Nov 20 03:17:10 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 10:17:10 +0100 Subject: octave-3.2.3: krylov.m: missing function "swap" In-Reply-To: <8F05F4F1-5685-48B6-90B3-E4B51180E5B9@swissonline.ch> References: <8F05F4F1-5685-48B6-90B3-E4B51180E5B9@swissonline.ch> Message-ID: <69d8d540911200117u21593efcm76e0276fd6a043ac@mail.gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/5ac95e71/attachment.html From highegg at gmail.com Fri Nov 20 03:43:35 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 10:43:35 +0100 Subject: Legend label order In-Reply-To: References: Message-ID: <69d8d540911200143w35efbcc7t79df83cd25d2949a@mail.gmail.com> On Fri, Oct 9, 2009 at 2:56 PM, Marco Caliari 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/8ac83dc9/attachment.html From highegg at gmail.com Fri Nov 20 03:44:32 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 10:44:32 +0100 Subject: wavread function bug In-Reply-To: <19168.46962.94257.96289@segfault.lan> References: <4AE03461.5070504@10g.pl> <19168.46962.94257.96289@segfault.lan> Message-ID: <69d8d540911200144y3760094y803a704073bb2c5a@mail.gmail.com> 2009/10/22 John W. Eaton > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/4292336f/attachment.html From highegg at gmail.com Fri Nov 20 03:48:44 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 10:48:44 +0100 Subject: Gnuplot terminal detection on linux without X11 patch In-Reply-To: <19183.38733.184096.833426@segfault.lan> References: <4AEB45DC.7060608@stefant.org> <19183.38733.184096.833426@segfault.lan> Message-ID: <69d8d540911200148m7bc5a80agd9064dd254582bd@mail.gmail.com> On Tue, Nov 3, 2009 at 3:37 AM, John W. Eaton wrote: > On 30-Oct-2009, Stefan Hepp wrote: > > | Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu > | > | Description: > | ----------- > | > | If 'plot' is used on a linux server without X (p.e. using ssh), > | octave sets terminal 'aqua' to gnuplot, which is not available > | (in octave 3.0), and not all diehard console users know/care about > | setting GNUTERM (like me :) ). > | > | Similary, in Octave 3.2 in gnuplot_drawnow.m the Gnuplot terminal > | should only be set to X11 if DISPLAY is set (else, set to 'unknown' > | again or something). > | > | It would be nice to have an option/command/.. to prevent plot,etc.. > | from displaying the plot, but only store it to a file using 'print'. > | (I don't know if there is already such an option, but I could not find > one). > | > | Repeat-By: > | --------- > | > | Run Octave 3.0/3.2 on a linux terminal, unset DISPLAY and GNUTERM > | environment variables, execute the following code: > | > | plot( [1 2 3 2 3] ); > | print('test.eps','-deps'); > | > | > | Fix: > | --- > | > | Here is a patch for drawnow.m for octave 3.0 which checks for OS X > | first, which works for me: > | > | diff -ru m.orig/plot/drawnow.m m/plot/drawnow.m > | --- m.orig/plot/drawnow.m 2009-10-30 20:00:21.000000000 +0100 > | +++ m/plot/drawnow.m 2009-10-30 19:59:45.000000000 +0100 > | @@ -160,13 +160,10 @@ > | term = "x11"; > | elseif (! isunix ()) > | term = "windows"; > | - else > | - ## This should really be checking for os x before setting > | - ## the terminal type to aqua, but nobody will notice because > | - ## every other unix will be using x11 and windows will be > | - ## using windows. Those diehards still running octave from > | - ## a linux console know how to set the GNUTERM variable. > | + elseif ( ismac () ) > | term = "aqua"; > | + else > | + term = "unknown"; > | endif > | endif > | > | @@ -195,10 +192,9 @@ > | > | elseif (enhanced) > | fprintf (plot_stream, "set terminal %s %s\n", term, enh_str); > | + elseif ( isempty (getenv ("GNUTERM")) ) > | + fprintf (plot_stream, "set terminal %s\n", term); > | endif > | - ## gnuplot will pick up the GNUTERM environment variable itself > | - ## so no need to set the terminal type if not also setting the > | - ## figure title or enhanced mode. > | > | endif > | > | > | For Octave 3.2 the following patch could work, but I have *not* tested > it: > | > | diff -ru scripts.orig/plot/gnuplot_drawnow.m > scripts/plot/gnuplot_drawnow.m > | --- scripts.orig/plot/gnuplot_drawnow.m 2009-10-30 20:41:19.000000000 > +0100 > | +++ scripts/plot/gnuplot_drawnow.m 2009-10-30 20:20:52.000000000 > +0100 > | @@ -326,8 +326,10 @@ > | term = "aqua"; > | elseif (! isunix ()) > | term = "windows"; > | - else > | + elseif (! isempty( getenv ("DISPLAY")) ) > | term = "x11"; > | + else > | + term = "unknown"; > | endif > | endif > | endfunction > > 3.0.x is no longer maintained. I checked in your patch for 3.2 to the > main development branch: > > http://hg.savannah.gnu.org/hgweb/octave/rev/4634a0e9ea1b > > Jaroslav, I don't think this is a regression or a particularly serious > bug, but it should be safe to apply the patch to the 3.2.x release > branch. > > jwe > transplanted. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/1ee7ee5b/attachment-0001.html From highegg at gmail.com Fri Nov 20 03:49:36 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 10:49:36 +0100 Subject: stairs(1:3) bug In-Reply-To: <19195.16453.573287.17881@segfault.lan> References: <9410328311.20091111230715@tul.cz> <19195.16453.573287.17881@segfault.lan> Message-ID: <69d8d540911200149k3aa71616q665cb22760f9d288@mail.gmail.com> On Wed, Nov 11, 2009 at 11:52 PM, John W. Eaton wrote: > On 11-Nov-2009, Jakub Kasse wrote: > > | Bug report for Octave 3.2.3 configured for i686-pc-mingw32 > | > | Description: > | ----------- > | > | Try: > | > | stairs(1:3) > | > | And you get errors in plot.m in function __stairs__ on line 83: > | > | if (nargin == 1 || ischar (varargin{2})) > | > | And also some other error, probably as a consequence. > | > | > | Repeat-By: > | --------- > | > | As I wrote, try "stairs(1:3)" > | > | Fix: > | --- > | > | Instead of "nargin==1" replace by "nargin==2" on line 83. The source > | of the mistake is probably in the definition of function __stairs__: > | > | function [h, xs, ys] = __stairs__ (doplot, varargin) > | > | When it is called from line 70: > | > | [h, xxs, yys] = __stairs__ (true, varargin{:}); > | > | Then the "nargin" is always greater or equal 2 because of "doplot" and > | at least one parameter in "varargin". In case of "stairs(1:3)" the > | "nargin" on line 83 is 2, "varargin" is "1:3" and "varargin(2)" > | doesn't exist. > > I checked in the following change. > > http://hg.savannah.gnu.org/hgweb/octave/rev/965487e00282 > > Jaroslav, this could probably be applied to the 3.2.x branch. > > Thanks, > > Done. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/4157490b/attachment.html From highegg at gmail.com Fri Nov 20 03:52:26 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 10:52:26 +0100 Subject: Scrambled expm output In-Reply-To: <1258227992.2499.36.camel@alpaca.lan> References: <1258157859.2499.27.camel@alpaca.lan> <69d8d540911132206i5b2e8cfpa51e956b962169f5@mail.gmail.com> <1258227992.2499.36.camel@alpaca.lan> Message-ID: <69d8d540911200152x21ce84e7u6c35804a5a058398@mail.gmail.com> On Sat, Nov 14, 2009 at 8:46 PM, Allen Barnett wrote: > On Sat, 2009-11-14 at 07:06 +0100, Jaroslav Hajek wrote: > > > On Sat, Nov 14, 2009 at 1:17 AM, Allen Barnett > > wrote: > > Bug report for Octave 3.2.3 configured for > > i386-redhat-linux-gnu > > > > Description: > > ----------- > > > > expm(A) produces a matrix in which the elements are scrambled > > compared > > to the Taylor series expansion. > > > please try this patch: > > http://hg.savannah.gnu.org/hgweb/octave/rev/84398271118c > > Hi Jaroslav: That looks good. Thanks! > > I guess I don't really understand what the line of code you changed is > doing. Could you explain the difference between: > r = r(p,p) > and > r(p,p) = r > > Thanks, > Allen > The second one permutes backwards, i.e. applies inverse permutation. it's nicer if you convert permutation vectors to matrices: p = eye(n) (:,p); then r = r(p,p) ---> r = p' * r * p r(p,p) = r ---> r = p * r * p' -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/c749706a/attachment.html From hallc at lu.unisi.ch Fri Nov 20 05:04:22 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Fri, 20 Nov 2009 12:04:22 +0100 Subject: eigs crash on a particular spare matrix In-Reply-To: <4B059D37.3000005@dbateman.org> References: <1258465162.4564.39.camel@boulder> <629388.82991.qm@web25506.mail.ukl.yahoo.com> <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> <4B059D37.3000005@dbateman.org> Message-ID: <1258715062.7662.7.camel@boulder> Dave - I don't think you attached the right patch file, as it appears to be a patch for __imagemagick__.cc. I tried to retrieve the patch file linked from the original message at https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20061104/d7d2f5a1/attachment-0001.ksh ...but the server is timing out. Any chance the correct patch is lying around your hard-drive somewhere? Cheers, Cyrus On Thu, 2009-11-19 at 20:32 +0100, David Bateman wrote: > 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. > > > email message attachment > > -------- Forwarded Message -------- > > From: David Bateman > > To: arpack at caam.rice.edu > > Subject: Problem with ARPACK for unsymmetric matrices where the Ritz > > values need reordering > > Date: Fri, 3 Nov 2006 12:34:17 +0100 > > > > 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 > > From alois.schloegl at tugraz.at Fri Nov 20 09:22:30 2009 From: alois.schloegl at tugraz.at (=?ISO-8859-1?Q?Alois_Schl=F6gl?=) Date: Fri, 20 Nov 2009 16:22:30 +0100 Subject: fix pkg.m if package name contains upper-case characters Message-ID: <4B06B436.7060208@tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If the package name contains upper-case characters, the package cannot be installed with pkg. It fails with this error message: octave:1> pkg install NaN package name 'nan' doesn't correspond to its filename 'NaN' error: called from `pkg>install' in file /usr/local/share/octave/3.2.0/m/pkg/pkg.m near line 630, column 4 error: called from: error: /usr/local/share/octave/3.2.0/m/pkg/pkg.m at line 658, column 5 error: /usr/local/share/octave/3.2.0/m/pkg/pkg.m at line 287, column 7 Here are two possible solutions: (1) diff -r edf065b51fa9 scripts/pkg/pkg.m - --- a/scripts/pkg/pkg.m Fri Nov 20 10:35:49 2009 +0100 +++ b/scripts/pkg/pkg.m Fri Nov 20 16:10:05 2009 +0100 @@ -1661,7 +1661,6 @@ else desc.depends = ""; endif - - desc.name = tolower (desc.name); endfunction ## Make sure the version string v is a valid x.y.z version string (2) diff -r edf065b51fa9 scripts/pkg/pkg.m - --- a/scripts/pkg/pkg.m Fri Nov 20 10:35:49 2009 +0100 +++ b/scripts/pkg/pkg.m Fri Nov 20 16:15:11 2009 +0100 @@ -626,7 +626,7 @@ ## Verify that package name corresponds with filename. [dummy, nm] = fileparts (tgz); if ((length (nm) >= length (desc.name)) - - && ! strcmp (desc.name, nm(1:length(desc.name)))) + && ! strcmp (desc.name, tolower(nm(1:length(desc.name))))) error ("package name '%s' doesn't correspond to its filename '%s'", desc.name, nm); endif Cheers, Alois -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksGtDMACgkQzSlbmAlvEIgKEQCfU8gDgfk1bHr9pQtvtanPD+Dr rJEAn30xw+SwcU8X+w+sE00tnDEwo1FT =wRLi -----END PGP SIGNATURE----- From alois.schloegl at tugraz.at Fri Nov 20 10:50:50 2009 From: alois.schloegl at tugraz.at (=?ISO-8859-1?Q?Alois_Schl=F6gl?=) Date: Fri, 20 Nov 2009 17:50:50 +0100 Subject: fix pkg.m if package name contains upper-case characters [followup] Message-ID: <4B06C8EA.8000005@tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If the package name contains upper-case characters, the package cannot be installed with pkg. It fails with this error message: octave:1> pkg install NaN package name 'nan' doesn't correspond to its filename 'NaN' error: called from `pkg>install' in file /usr/local/share/octave/3.2.0/m/pkg/pkg.m near line 630, column 4 error: called from: error: /usr/local/share/octave/3.2.0/m/pkg/pkg.m at line 658, column 5 error: /usr/local/share/octave/3.2.0/m/pkg/pkg.m at line 287, column 7 The earlier patch did not address all issues. In order to keep the case-sensitivity of the package name, the attached patch should be applied to pkg.m Cheers, Alois -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksGyOcACgkQzSlbmAlvEIjAnQCgpuONRFf0/J2IzaBkC4xkM+dN SxQAn1r091vLk24NHI3Y2ex28zyqzH1p =XsEb -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_pkg_case_sensitive_package_name.diff Type: text/x-patch Size: 2017 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/7e920ce9/attachment.bin From dbateman at dbateman.org Fri Nov 20 14:37:23 2009 From: dbateman at dbateman.org (David Bateman) Date: Fri, 20 Nov 2009 21:37:23 +0100 Subject: eigs crash on a particular spare matrix In-Reply-To: <1258715062.7662.7.camel@boulder> References: <1258465162.4564.39.camel@boulder> <629388.82991.qm@web25506.mail.ukl.yahoo.com> <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> <4B059D37.3000005@dbateman.org> <1258715062.7662.7.camel@boulder> Message-ID: <4B06FE03.9010603@dbateman.org> Cyrus Hall wrote: > Dave - > > I don't think you attached the right patch file, as it appears to be a > patch for __imagemagick__.cc. I tried to retrieve the patch file linked > from the original message at > > https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20061104/d7d2f5a1/attachment-0001.ksh > > ...but the server is timing out. Any chance the correct patch is lying > around your hard-drive somewhere? > > Cheers, > Cyrus > > Strange... Here is the patch to ARPACK that I used in 2006 to address this issue 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) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.arpack Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091120/3786209f/attachment.ksh From thomas.weber.mail at gmail.com Fri Nov 20 15:53:23 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Fri, 20 Nov 2009 22:53:23 +0100 Subject: eigs crash on a particular spare matrix In-Reply-To: <4B059D37.3000005@dbateman.org> References: <1258465162.4564.39.camel@boulder> <629388.82991.qm@web25506.mail.ukl.yahoo.com> <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> <4B059D37.3000005@dbateman.org> Message-ID: <20091120215323.GA8678@atlan> On Thu, Nov 19, 2009 at 08:32:07PM +0100, David Bateman wrote: > 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 I can try to get it into Debian's ARPACK, but a self-contained test would be helpful (yes, I've read the part about that in http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2006-November/001251.html ) Otherwise, a .m file triggering the bug might suffice. Thomas From pbellec at bic.mni.mcgill.ca Sat Nov 21 09:21:37 2009 From: pbellec at bic.mni.mcgill.ca (pbellec) Date: Sat, 21 Nov 2009 07:21:37 -0800 (PST) Subject: saving an empty structure Message-ID: <26457496.post@talk.nabble.com> -------- Bug report for Octave 3.0.4 configured for i686-pc-linux-gnu Description: ----------- Saving an empty structure to a mat file and then loading it will result in a non-empty structure with no fields, which is different of the original variable (in particular it is non-empty). I generated the bug report in octave 3.0.4, but I was able to reproduce it in octave 3.2.3 as well. Repeat-By: --------- First, let's create an empty structure octave:1> a = struct([]) a = { 0x0 struct array containing the fields: } octave:2> whos a *** local user variables: Prot Name Size Bytes Class ==== ==== ==== ===== ===== rwd a 0x0 0 struct Total is 0 elements using 0 bytes octave:3> isempty(a) ans = 1 Now, let's save the structure and load the saved version octave:4> save test a octave:5> load test The structure now has one element, with no field : octave:6> a a = { } octave:7> whos a *** local user variables: Prot Name Size Bytes Class ==== ==== ==== ===== ===== rwd a 1x1 0 struct Total is 1 element using 0 bytes The difference with the original "a" is that it is not considered empty anymore : octave:8> isempty(a) ans = 0 Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux sorbier 2.6.24-25-generic #1 SMP Tue Oct 20 07:31:10 UTC 2009 i686 GNU/Linux configure opts: Fortran compiler: g77 FFLAGS: -O -mieee-fp F2C: @F2C@ F2CFLAGS: @F2CFLAGS@ FLIBS: -L/usr/lib/gcc/i486-linux-gnu/3.4.6 -L/usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib -L/usr/lib/gcc/i486-linux-gnu/3.4.6/../../.. -L/lib/../lib -L/usr/lib/../lib -lhdf5 -lz -lfrtbegin -lg2c -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) CFLAGS: -g -O2 CPICFLAG: -fPIC C++ compiler: g++, version 4.2.4 CXXFLAGS: -g -O2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/local/lib/octave-3.0.4 BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=gnu_v3 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __ -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_EXP2=1 -DHAVE_LOG2=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot" User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/local/libexec/octave/3.0.4/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/api-v32/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/3.0.4/exec/i686-pc-linux-gnu:/usr/local/bin:/home/pbellec/quarantines/Feb-14-2008/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/X11/bin:/usr/bin/:/usr/local/bic/bin:/usr/local/bin IMAGE_PATH = .:/usr/local/share/octave/3.0.4/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot gnuplot_command_end = gnuplot_command_plot = pl gnuplot_command_replot = rep gnuplot_command_splot = sp gnuplot_command_title = t gnuplot_command_using = u gnuplot_command_with = w history_file = /home/pbellec/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/local/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 print_answer_id_name = 1 print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 -- View this message in context: http://old.nabble.com/saving-an-empty-structure-tp26457496p26457496.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From dbateman at dbateman.org Sun Nov 22 15:31:02 2009 From: dbateman at dbateman.org (David Bateman) Date: Sun, 22 Nov 2009 22:31:02 +0100 Subject: eigs crash on a particular spare matrix In-Reply-To: <20091120215323.GA8678@atlan> References: <1258465162.4564.39.camel@boulder> <629388.82991.qm@web25506.mail.ukl.yahoo.com> <69d8d540911180454l5ecd32ccv710b714ce1246ac2@mail.gmail.com> <4B059D37.3000005@dbateman.org> <20091120215323.GA8678@atlan> Message-ID: <4B09AD96.9040506@dbateman.org> Thomas Weber wrote: > I can try to get it into Debian's ARPACK, but a self-contained test > would be helpful (yes, I've read the part about that in > http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2006-November/001251.html > ) > > Otherwise, a .m file triggering the bug might suffice. > > The attached m-file called like "segtest(100)" should trigger the bug. I've tried to make an f77 file that triggers it, but trying 10000 different seed values to dlarnv for the random starting vector could generate a segfault. I have no idea why I can't get this to segfault in the same manner. In any case I believe my explanation of the issue 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. from 2006. It might be better to just throw away the value of NCONV returned from xTRSEN rather than accept it only if it is smaller than the original (as the patch I sent does), though I'm not confident that is the right thing to do as perhaps xNEUPD should be allowed to flags some of the converged ritz vectors from xNAUPD as unacceptable. However, NCONV should never grow in the xNEUPD functions as it is the job of the xNAUPD function to converge the ritz vectors Cheers David -- 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: segtest.m Type: text/x-objcsrc Size: 556 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091122/dd2bc86a/attachment.bin From syrnick at gmail.com Sun Nov 22 18:00:18 2009 From: syrnick at gmail.com (Alexander Sorokin) Date: Sun, 22 Nov 2009 19:00:18 -0500 Subject: Ginput doesn't work in 3.2.3 Message-ID: When I try to use ginput after showing an image, it returns an error: clf imshow(rand(100)) [x,y,k]=ginput(1) line 2: warning: Mousing not active multiplot> pause mouse any; ^ line 2: expecting string I'm using Octave 3.2.3 on 64-bit Ubuntu 9.04. Alex From tmacchant at yahoo.co.jp Sun Nov 22 20:08:43 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 11:08:43 +0900 (JST) Subject: Ginput doesn't work in 3.2.3 In-Reply-To: Message-ID: <20091123020844.67113.qmail@web3805.mail.bbt.yahoo.co.jp> Hello Alexander Please give the version number of gnuplot as a reference. Hello list members ******* > clf > imshow(rand(100)) > [x,y,k]=ginput(1) On octave / mingw32 (Benjamin), Errors happened for Alexander does not appear for me. However, commands the above did not work. There was no response by mouse click. I noticed that x, y coordinate does not change by moving mouse pointer. Perhaps multiplot is set in the gnuplot by imshow. ************ BTW, octave-3.2.3 on cygwin with gnuplot 4.2.4) octave:1> plot (1:10) octave:2> [x,y]=ginput(1) x = 1.7202 y = 4.3302 octave:3> imshow(rand(100)) octave:4> [x,y]=ginput(1) line 0: warning: Mousing not active multiplot> pause mouse any; ^ line 0: expecting string x = 0 y = 0 However, octave-3.2.3 on cygwin with gnuplot 4.5 (cvs) The error is the same as that in octave / mingw32, in which gnuplot 4.3 (cvs). Perhaps multiplot is set in the gnuplot by imshow. Behaviors seem to depend on version of gnuplot. Regards Tatsuro ******* On Regards Tatsuro --- Alexander Sorokin wrote: > When I try to use ginput after showing an image, it returns an error: > > clf > imshow(rand(100)) > [x,y,k]=ginput(1) > > > line 2: warning: Mousing not active > > multiplot> pause mouse any; > ^ > line 2: expecting string > > > I'm using Octave 3.2.3 on 64-bit Ubuntu 9.04. > > Alex > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From syrnick at gmail.com Sun Nov 22 20:37:27 2009 From: syrnick at gmail.com (Alexander Sorokin) Date: Sun, 22 Nov 2009 21:37:27 -0500 Subject: Ginput doesn't work in 3.2.3 In-Reply-To: <20091123020844.67113.qmail@web3805.mail.bbt.yahoo.co.jp> References: <20091123020844.67113.qmail@web3805.mail.bbt.yahoo.co.jp> Message-ID: Hi All, I was initially on gnuplot 4.2.4, but I updated to 4.5. Indeed, I found multiplot seems to be the cause of trouble. After I put: fputs (ostream, "unset multiplot;\n\n"); fputs (ostream, "set mouse;\n\npause mouse;\n\n"); in /usr/local/share/octave/3.2.3/m/plot/__gnuplot_ginput__.m It started to work for me. Note, that I have no idea about gnuplot, so my fixes are probably not the right way to do it. Alex. 2009/11/22 Tatsuro MATSUOKA : > Hello Alexander > > Please give the version number of gnuplot as a reference. > > Hello list members > ******* >> clf >> imshow(rand(100)) >> [x,y,k]=ginput(1) > > On octave / mingw32 (Benjamin), > Errors happened for Alexander ?does not appear for me. > However, commands the above did not work. There was no response by mouse click. > I noticed that x, y coordinate does not change by moving mouse pointer. > > Perhaps multiplot is set in the gnuplot by imshow. > > ************ > BTW, octave-3.2.3 on cygwin with gnuplot 4.2.4) > > octave:1> plot (1:10) > octave:2> [x,y]=ginput(1) > x = ?1.7202 > y = ?4.3302 > > octave:3> imshow(rand(100)) > octave:4> [x,y]=ginput(1) > ? ? ? ? ? line 0: warning: Mousing not active > > multiplot> pause mouse any; > ? ? ? ? ? ? ? ? ? ? ? ^ > ? ? ? ? ? line 0: expecting string > > x = 0 > y = 0 > > However, octave-3.2.3 on cygwin with gnuplot 4.5 (cvs) > The error is the same as that in octave / mingw32, in which gnuplot 4.3 (cvs). > Perhaps multiplot is set in the gnuplot by imshow. > > Behaviors seem to depend on version of gnuplot. > > Regards > > Tatsuro > ******* > On > > Regards > > Tatsuro > > --- Alexander Sorokin wrote: > >> When I try to use ginput after showing an image, it returns an error: >> >> clf >> imshow(rand(100)) >> [x,y,k]=ginput(1) >> >> >> ? ? ? ? ? ?line 2: warning: Mousing not active >> >> multiplot> pause mouse any; >> ? ? ? ? ? ? ? ? ? ? ? ?^ >> ? ? ? ? ? ?line 2: expecting string >> >> >> I'm using Octave 3.2.3 on 64-bit Ubuntu 9.04. >> >> Alex >> _______________________________________________ >> Bug-octave mailing list >> Bug-octave at octave.org >> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave >> > > > -------------------------------------- > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > http://pr.mail.yahoo.co.jp/gyao/ > From WGHM.Janssen at science.ru.nl Mon Nov 23 06:26:03 2009 From: WGHM.Janssen at science.ru.nl (Wim Janssen) Date: Mon, 23 Nov 2009 13:26:03 +0100 Subject: Octave on Scientific Linux Message-ID: <4B0A7F5B.8000108@science.ru.nl> Dear Octave-Folks, This afternoon I tried to make "octave-3.2.3" available on the SL5.4-platform. As you know Scientific Linux is very close to the RedHat-distribution. # uname -a results in: Linux sundoor 2.6.18-164.6.1.el5 \ #1 SMP Tue Nov 3 23:11:58 EST 2009 i686 i686 i386 GNU/Linux The 'configure' went without errors. And the 'make' ran for a very long time with some warnings and finally stopped with: ../src/liboctinterp.so: undefined reference to `std::basic_istream References: <20091123020844.67113.qmail@web3805.mail.bbt.yahoo.co.jp> Message-ID: <90454F99-4226-40F5-ABF1-2CD9B8BA291A@mac.com> On Nov 22, 2009, at 9:08 PM, Tatsuro MATSUOKA wrote: > Hello Alexander > > Please give the version number of gnuplot as a reference. > > Hello list members > ******* >> clf >> imshow(rand(100)) >> [x,y,k]=ginput(1) > > On octave / mingw32 (Benjamin), > Errors happened for Alexander does not appear for me. > However, commands the above did not work. There was no response by mouse click. > I noticed that x, y coordinate does not change by moving mouse pointer. > > Perhaps multiplot is set in the gnuplot by imshow. > > ************ > BTW, octave-3.2.3 on cygwin with gnuplot 4.2.4) > > octave:1> plot (1:10) > octave:2> [x,y]=ginput(1) > x = 1.7202 > y = 4.3302 > > octave:3> imshow(rand(100)) > octave:4> [x,y]=ginput(1) > line 0: warning: Mousing not active > > multiplot> pause mouse any; > ^ > line 0: expecting string > > x = 0 > y = 0 > > However, octave-3.2.3 on cygwin with gnuplot 4.5 (cvs) > The error is the same as that in octave / mingw32, in which gnuplot 4.3 (cvs). > Perhaps multiplot is set in the gnuplot by imshow. > > Behaviors seem to depend on version of gnuplot. > > Regards > > Tatsuro > ******* > On > > Regards > > Tatsuro > > --- Alexander Sorokin wrote: > >> When I try to use ginput after showing an image, it returns an error: >> >> clf >> imshow(rand(100)) >> [x,y,k]=ginput(1) >> >> >> line 2: warning: Mousing not active >> >> multiplot> pause mouse any; >> ^ >> line 2: expecting string >> >> >> I'm using Octave 3.2.3 on 64-bit Ubuntu 9.04. >> >> Alex ginput works for me running Octave-3.2.3/x with gnuplot 4.2.3 Later today I'll try a more recent gnuplot. Ben From bpabbott at mac.com Mon Nov 23 07:56:10 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 23 Nov 2009 08:56:10 -0500 Subject: Ginput doesn't work in 3.2.3 In-Reply-To: <62797265452150907666093751629030271252-Webmail@me.com> References: <62797265452150907666093751629030271252-Webmail@me.com> Message-ID: <167265331931694214073480136693955299604-Webmail@me.com> On Monday, November 23, 2009, at 08:07AM, "Ben Abbott" wrote: > >On Nov 22, 2009, at 9:08 PM, Tatsuro MATSUOKA wrote: > >> Hello Alexander >> >> Please give the version number of gnuplot as a reference. >> >> Hello list members >> ******* >>> clf >>> imshow(rand(100)) >>> [x,y,k]=ginput(1) >> >> On octave / mingw32 (Benjamin), >> Errors happened for Alexander does not appear for me. >> However, commands the above did not work. There was no response by mouse click. >> I noticed that x, y coordinate does not change by moving mouse pointer. >> >> Perhaps multiplot is set in the gnuplot by imshow. >> >> ************ >> BTW, octave-3.2.3 on cygwin with gnuplot 4.2.4) >> >> octave:1> plot (1:10) >> octave:2> [x,y]=ginput(1) >> x = 1.7202 >> y = 4.3302 >> >> octave:3> imshow(rand(100)) >> octave:4> [x,y]=ginput(1) >> line 0: warning: Mousing not active >> >> multiplot> pause mouse any; >> ^ >> line 0: expecting string >> >> x = 0 >> y = 0 >> >> However, octave-3.2.3 on cygwin with gnuplot 4.5 (cvs) >> The error is the same as that in octave / mingw32, in which gnuplot 4.3 (cvs). >> Perhaps multiplot is set in the gnuplot by imshow. >> >> Behaviors seem to depend on version of gnuplot. >> >> Regards >> >> Tatsuro >> ******* >> On >> >> Regards >> >> Tatsuro >> >> --- Alexander Sorokin wrote: >> >>> When I try to use ginput after showing an image, it returns an error: >>> >>> clf >>> imshow(rand(100)) >>> [x,y,k]=ginput(1) >>> >>> >>> line 2: warning: Mousing not active >>> >>> multiplot> pause mouse any; >>> ^ >>> line 2: expecting string >>> >>> >>> I'm using Octave 3.2.3 on 64-bit Ubuntu 9.04. >>> >>> Alex > > >ginput works for me running Octave-3.2.3/x with gnuplot 4.2.3 > >Later today I'll try a more recent gnuplot. > >Ben Opps ... I just noticed this problem is unique to images. The problem exists for me as well. Ben From stefan at pofahl.de Mon Nov 23 04:50:27 2009 From: stefan at pofahl.de (stefan.pofahl) Date: Mon, 23 Nov 2009 11:50:27 +0100 Subject: axis command is corrupt Message-ID: <4B0A68F3.50607@pofahl.de> Bug report for Octave 3.2.2 configured for i686-pc-mingw32 Description: ----------- I can't set axis-range with axis command. Repeat-By: --------- function my_xlim_test_b() x = [1,2,3,4,5]'; y = x; plot(x,y); axis = ([1, 3]); replot; endfunction does not work :-( Fix: --- Use "set()"-command: > set(gca(), "xlim", [1, 3]); Kind regards, Stefan Pofahl *** Configuration (please do not edit this section): ----------------------------------------------- uname output: Windows configure opts: Fortran compiler: mingw32-gfortran-4.3.0-dw2 FFLAGS: -O -mieee-fp FLIBS: -lgfortran CPPFLAGS: -march=i686 -mtune=generic -O2 INCFLAGS: -I. -I/octmgw32/octave/octave-3.2.2 -I. -I./liboctave -I./src -I./libcruft/misc -I/octmgw32/octave/octave-3.2.2 -I/octmgw32/octave/octave-3.2.2/liboctave -I/octmgw32/octave/octave-3.2.2/src -I/octmgw32/octave/octave-3.2.2/libcruft/misc C compiler: mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2 for MinGW) CFLAGS: -Wall CPICFLAG: C++ compiler: mingw32-g++-4.3.0-dw2, version4.3.0-dw2 CXXFLAGS: -D_DLL -Wall CXXPICFLAG: LD_CXX: mingw32-g++-4.3.0-dw2 LDFLAGS: -shared-libgcc -Wl,--exclude-libs=-lstdc++_s -Wl,--allow-multiple-definition LIBFLAGS: -L. RLD_FLAG: BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -liberty -lblas -lhdf5 -lz -lm -lgdi32 -lws2_32 -luser32 -lkernel32 LEXLIB: LIBGLOB: -lglob SED: /usr/bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=';' -DSEPCHAR_STR=";" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -Duid_t=int -Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1 -DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_MKSTEMPS=1 -DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 -D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_COPYSIGN=1 -DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=1 -DHAVE__COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1 -DRETSIGTYPE_IS_VOID=1 User-preferences (please do not edit this section): EDITOR = C:\Programme\pspad\PSPad.exe EXEC_PATH = C:\Programme\Octave\3.2.2_gcc-4.3.0\MINGW32\bin;C:\Programme\Octave\3.2.2_gcc-4.3.0\MSYS\bin;C:\Programme\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\site\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.2_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.2_gcc-4.3.0\bin;C:\Programme\MiKTeX 2.7\miktex\bin;C:\Programme\Microsoft Visual Studio\Common\Tools;C:\Programme\Microsoft Visual Studio\Common\Msdev98\BIN;C:\Programme\Microsoft Visual Studio\DF98\BIN;C:\Programme\Microsoft Visual Studio\VC98\BIN;C:\PROGRA~1\GEMEIN~1\ASPENT~1;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\Gemeinsame Dateien\AspenTech Shared\;C:\Programme\Rainbow Technologies\SentinelLM 7.2.0.1 Server\English\;C:\Programme\gnuplot\bin\;C:\VXIpnp\WinNT\Bin;C:\Programme\XEmacs\XEmacs-21.4.21\i586-pc-win32;C:\Programme\Ghostgum\gs\gs8.63\bin IMAGE_PATH = .;C:\Programme\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\imagelib PAGER = C:\Programme\Octave\3.2.2_gcc-4.3.0\bin\less.exe PS1 = \s:\#:\w > PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = C:\Programme\Octave\3.2.2_gcc-4.3.0\bin\gnuplot.exe # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = C:\Dokumente und Einstellungen\spofahl\.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = C:\Programme\Octave\3.2.2_gcc-4.3.0\share\info\octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From bpabbott at mac.com Mon Nov 23 09:08:01 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 23 Nov 2009 10:08:01 -0500 Subject: Ginput doesn't work in 3.2.3 In-Reply-To: References: <20091123020844.67113.qmail@web3805.mail.bbt.yahoo.co.jp> Message-ID: On Nov 23, 2009, at 10:06 AM, Ben Abbott wrote: > On Nov 22, 2009, at 9:37 PM, Alexander Sorokin wrote: >> >> 2009/11/22 Tatsuro MATSUOKA : >>> Hello Alexander >>> >>> Please give the version number of gnuplot as a reference. >>> >>> Hello list members >>> ******* >>>> clf >>>> imshow(rand(100)) >>>> [x,y,k]=ginput(1) >>> >>> On octave / mingw32 (Benjamin), >>> Errors happened for Alexander does not appear for me. >>> However, commands the above did not work. There was no response by mouse click. >>> I noticed that x, y coordinate does not change by moving mouse pointer. >>> >>> Perhaps multiplot is set in the gnuplot by imshow. >>> >>> ************ >>> BTW, octave-3.2.3 on cygwin with gnuplot 4.2.4) >>> >>> octave:1> plot (1:10) >>> octave:2> [x,y]=ginput(1) >>> x = 1.7202 >>> y = 4.3302 >>> >>> octave:3> imshow(rand(100)) >>> octave:4> [x,y]=ginput(1) >>> line 0: warning: Mousing not active >>> >>> multiplot> pause mouse any; >>> ^ >>> line 0: expecting string >>> >>> x = 0 >>> y = 0 >>> >>> However, octave-3.2.3 on cygwin with gnuplot 4.5 (cvs) >>> The error is the same as that in octave / mingw32, in which gnuplot 4.3 (cvs). >>> Perhaps multiplot is set in the gnuplot by imshow. >>> >>> Behaviors seem to depend on version of gnuplot. >>> >>> Regards >>> >>> Tatsuro >>> ******* >>> On >>> >>> Regards >>> >>> Tatsuro >>> >>> --- Alexander Sorokin wrote: >>> >>>> When I try to use ginput after showing an image, it returns an error: >>>> >>>> clf >>>> imshow(rand(100)) >>>> [x,y,k]=ginput(1) >>>> >>>> >>>> line 2: warning: Mousing not active >>>> >>>> multiplot> pause mouse any; >>>> ^ >>>> line 2: expecting string >>>> >>>> >>>> I'm using Octave 3.2.3 on 64-bit Ubuntu 9.04. >>>> >>>> Alex >>>> >>> >> >> Hi All, >> >> I was initially on gnuplot 4.2.4, but I updated to 4.5. Indeed, I >> found multiplot seems to be the cause of trouble. After I put: >> >> fputs (ostream, "unset multiplot;\n\n"); >> fputs (ostream, "set mouse;\n\npause mouse;\n\n"); >> >> in /usr/local/share/octave/3.2.3/m/plot/__gnuplot_ginput__.m >> >> It started to work for me. Note, that I have no idea about gnuplot, so >> my fixes are probably not the right way to do it. >> >> Alex. > > It looks to me like we'll either have to ... > > (1) Add a "set multiplot" in __go_draw_figure__ after drawing all axes, or .... > > (2) Add a "set multiplot" to __gnuplot_ginput__. > > I'd favor (2), as it is less likely we'd suffer another regression. > > Does the attached work ok, now with the changeset attached! Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 1636 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091123/4448ab94/attachment.obj From bpabbott at mac.com Mon Nov 23 09:06:01 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 23 Nov 2009 10:06:01 -0500 Subject: Ginput doesn't work in 3.2.3 In-Reply-To: References: <20091123020844.67113.qmail@web3805.mail.bbt.yahoo.co.jp> Message-ID: On Nov 22, 2009, at 9:37 PM, Alexander Sorokin wrote: > > 2009/11/22 Tatsuro MATSUOKA : >> Hello Alexander >> >> Please give the version number of gnuplot as a reference. >> >> Hello list members >> ******* >>> clf >>> imshow(rand(100)) >>> [x,y,k]=ginput(1) >> >> On octave / mingw32 (Benjamin), >> Errors happened for Alexander does not appear for me. >> However, commands the above did not work. There was no response by mouse click. >> I noticed that x, y coordinate does not change by moving mouse pointer. >> >> Perhaps multiplot is set in the gnuplot by imshow. >> >> ************ >> BTW, octave-3.2.3 on cygwin with gnuplot 4.2.4) >> >> octave:1> plot (1:10) >> octave:2> [x,y]=ginput(1) >> x = 1.7202 >> y = 4.3302 >> >> octave:3> imshow(rand(100)) >> octave:4> [x,y]=ginput(1) >> line 0: warning: Mousing not active >> >> multiplot> pause mouse any; >> ^ >> line 0: expecting string >> >> x = 0 >> y = 0 >> >> However, octave-3.2.3 on cygwin with gnuplot 4.5 (cvs) >> The error is the same as that in octave / mingw32, in which gnuplot 4.3 (cvs). >> Perhaps multiplot is set in the gnuplot by imshow. >> >> Behaviors seem to depend on version of gnuplot. >> >> Regards >> >> Tatsuro >> ******* >> On >> >> Regards >> >> Tatsuro >> >> --- Alexander Sorokin wrote: >> >>> When I try to use ginput after showing an image, it returns an error: >>> >>> clf >>> imshow(rand(100)) >>> [x,y,k]=ginput(1) >>> >>> >>> line 2: warning: Mousing not active >>> >>> multiplot> pause mouse any; >>> ^ >>> line 2: expecting string >>> >>> >>> I'm using Octave 3.2.3 on 64-bit Ubuntu 9.04. >>> >>> Alex >>> >> > > Hi All, > > I was initially on gnuplot 4.2.4, but I updated to 4.5. Indeed, I > found multiplot seems to be the cause of trouble. After I put: > > fputs (ostream, "unset multiplot;\n\n"); > fputs (ostream, "set mouse;\n\npause mouse;\n\n"); > > in /usr/local/share/octave/3.2.3/m/plot/__gnuplot_ginput__.m > > It started to work for me. Note, that I have no idea about gnuplot, so > my fixes are probably not the right way to do it. > > Alex. It looks to me like we'll either have to ... (1) Add a "set multiplot" in __go_draw_figure__ after drawing all axes, or .... (2) Add a "set multiplot" to __gnuplot_ginput__. I'd favor (2), as it is less likely we'd suffer another regression. Does the attached work From bpabbott at mac.com Mon Nov 23 09:40:32 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 23 Nov 2009 10:40:32 -0500 Subject: axis command is corrupt In-Reply-To: <4B0A68F3.50607@pofahl.de> References: <4B0A68F3.50607@pofahl.de> Message-ID: <6CA3CBC6-F512-4F5B-B5D7-B2251E4E7D3C@mac.com> On Nov 23, 2009, at 5:50 AM, "stefan.pofahl" wrote: > Bug report for Octave 3.2.2 configured for i686-pc-mingw32 > > Description: > ----------- > > I can't set axis-range with axis command. > > Repeat-By: > --------- > > function my_xlim_test_b() > x = [1,2,3,4,5]'; > y = x; > plot(x,y); > axis = ([1, 3]); > replot; > endfunction > > does not work :-( > > Fix: > --- > > Use "set()"-command: >> set(gca(), "xlim", [1, 3]); > > Kind regards, > > Stefan Pofahl > You're not using the axis function properly. Please look at help axis If you only want to change the x-axis see help xlim Ben From thomas.weber.mail at gmail.com Mon Nov 23 12:10:24 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Mon, 23 Nov 2009 19:10:24 +0100 Subject: Octave on Scientific Linux In-Reply-To: <4B0A7F5B.8000108@science.ru.nl> References: <4B0A7F5B.8000108@science.ru.nl> Message-ID: <20091123181024.GA13266@atlan> On Mon, Nov 23, 2009 at 01:26:03PM +0100, Wim Janssen wrote: > Dear Octave-Folks, > > This afternoon I tried to make "octave-3.2.3" available on the > SL5.4-platform. > As you know Scientific Linux is very close to the RedHat-distribution. > # uname -a results in: > Linux sundoor 2.6.18-164.6.1.el5 \ > #1 SMP Tue Nov 3 23:11:58 EST 2009 i686 i686 i386 GNU/Linux > The 'configure' went without errors. > And the 'make' ran for a very long time with some warnings and finally > stopped with: > ../src/liboctinterp.so: undefined reference to `std::basic_istream std::ch../src/liboctinterp.so: undefined reference to > `__cxa_get_exception_ptr' Please check whether you are linking to the right version of libstdc++ for your compiler: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20170 Thomas From highegg at gmail.com Mon Nov 23 14:19:56 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 23 Nov 2009 21:19:56 +0100 Subject: Octave on Scientific Linux In-Reply-To: <20091123181024.GA13266@atlan> References: <4B0A7F5B.8000108@science.ru.nl> <20091123181024.GA13266@atlan> Message-ID: <69d8d540911231219r319f7b39ycefb62937b23eb90@mail.gmail.com> On Mon, Nov 23, 2009 at 7:10 PM, Thomas Weber wrote: > On Mon, Nov 23, 2009 at 01:26:03PM +0100, Wim Janssen wrote: > > Dear Octave-Folks, > > > > This afternoon I tried to make "octave-3.2.3" available on the > > SL5.4-platform. > > As you know Scientific Linux is very close to the RedHat-distribution. > > # uname -a results in: > > Linux sundoor 2.6.18-164.6.1.el5 \ > > #1 SMP Tue Nov 3 23:11:58 EST 2009 i686 i686 i386 GNU/Linux > > The 'configure' went without errors. > > And the 'make' ran for a very long time with some warnings and finally > > stopped with: > > ../src/liboctinterp.so: undefined reference to `std::basic_istream > std::ch../src/liboctinterp.so: undefined reference to > > `__cxa_get_exception_ptr' > > Please check whether you are linking to the right version of libstdc++ > for your compiler: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20170 > > Thomas > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > I think something very similar was reported before. The problem is mixing gcc 4.x (g++) with gcc 3.x (g77). This confuses g++ to link in wrong runtime libraries. If you can't use gfortran, try specifying the correct path to C++ runtime libraries using -L. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091123/5cdfc1eb/attachment.html From highegg at gmail.com Tue Nov 24 00:55:37 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 24 Nov 2009 07:55:37 +0100 Subject: saving an empty structure In-Reply-To: <26457496.post@talk.nabble.com> References: <26457496.post@talk.nabble.com> Message-ID: <69d8d540911232255r7e67f98did3f8ec4846e1b6b2@mail.gmail.com> On Sat, Nov 21, 2009 at 4:21 PM, pbellec wrote: > > -------- > Bug report for Octave 3.0.4 configured for i686-pc-linux-gnu > > Description: > ----------- > > Saving an empty structure to a mat file and then loading it will result in > a > non-empty structure with no fields, which is different of the original > variable (in particular it is non-empty). I generated the bug report in > octave 3.0.4, but I was able to reproduce it in octave 3.2.3 as well. > > Repeat-By: > --------- > > First, let's create an empty structure > > octave:1> a = struct([]) > a = > { > 0x0 struct array containing the fields: > > } > octave:2> whos a > > *** local user variables: > > Prot Name Size Bytes Class > ==== ==== ==== ===== ===== > rwd a 0x0 0 struct > > Total is 0 elements using 0 bytes > octave:3> isempty(a) > ans = 1 > > Now, let's save the structure and load the saved version > octave:4> save test a > octave:5> load test > > The structure now has one element, with no field : > octave:6> a > a = > { > } > > octave:7> whos a > > *** local user variables: > > Prot Name Size Bytes Class > ==== ==== ==== ===== ===== > rwd a 1x1 0 struct > > Total is 1 element using 0 bytes > > The difference with the original "a" is that it is not considered empty > anymore : > octave:8> isempty(a) > ans = 0 > Thanks. I've fixed this in the development sources: http://hg.savannah.gnu.org/hgweb/octave/rev/1fac51c5f83f http://hg.savannah.gnu.org/hgweb/octave/rev/43a7adf62534 John, can you take a look? The approach is to first save the dimensions of a struct, then number of fields and fields follow. When loading, care is taken to preserve backward compatibility. In ascii, this is done by multiple keyword lookup (extract_keyword). In binary, the ndims is stored as a negative number, whereas len is positive. For ascii format, this approach is even forward-compatible, meaning that older versions of Octave will be still able to read the new files. For binary, however, it is not. Worse yet, trying it will cause Octave to abort (negative nfields used to cause panic_impossible which I think was unnecessary, so I removed it). Is this OK? Should any of these go to 3.2.4? -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091124/aff00aaa/attachment.html