From dbateman at dbateman.org  Tue Sep  1 01:17:50 2009
From: dbateman at dbateman.org (David Bateman)
Date: Tue, 01 Sep 2009 08:17:50 +0200
Subject: eigs interface inconsistent with documentation?
In-Reply-To: <4A9C472A.9070403@dbateman.org>
References: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>
	<4A9C472A.9070403@dbateman.org>
Message-ID: <4A9CBC8E.6060800@dbateman.org>

David Bateman wrote:
> Carlo de Falco wrote:
>> --------
>> Bug report for Octave 3.2.2 configured for i386-apple-darwin8.11.1
>>
>> Description:
>> -----------
>>
>> Using 'eigs' to solve a generalized eigenvalue problem does not seem  
>> to work
>> as advertized in the help text when the first argument is a function  
>> handle:
>>
>> -- Loadable Function: D = eigs (AF, N, B)
>> -- Loadable Function: D = eigs (AF, N, B, K)
>> -- Loadable Function: D = eigs (AF, N, B, K, SIGMA)
>> -- Loadable Function: D = eigs (AF, N, B, K, SIGMA, OPTS)
>>
>> Repeat-By:
>> ---------
>>
>>  >> A = eye (10);
>>  >> AF = @(x) (A*x);
>>  >> D = eigs (AF, 10, A)
>> warning: implicit conversion from diagonal matrix to real scalar
>> D =  1
>>  >> D = eigs (AF, 10, A, 6)
>> D = eigs (AF, 10, A, 6)
>> warning: implicit conversion from diagonal matrix to real scalar
>> D =  7
>>  >> D = eigs (AF, 10, A, 6, 'lm')
>> warning: implicit conversion from diagonal matrix to real scalar
>> error: eigs: options argument must be a structure
>>  >> D = eigs (AF, 10, A, 6, 'lm', struct ('issym', true))
>> warning: implicit conversion from diagonal matrix to real scalar
>> error: eigs: options argument must be a structure
>>
>>
>> Fix:
>> ---
>>
>> I beleive there should be some sort of problem in the way eigs 
>> checks  for input arg type but I haven't found it yet...
>>
>>   
> Waiting for a full rebuild to complete, so I can't test, but I think 
> the attached patch against the savannah tip probably fixes the issue.
>
> D.
>
>
Yes that was the issue. The attached patch, which I've pushed to 
savannah, fixes the issue and adds a test.

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
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/497e0218/attachment-0001.ksh 

From highegg at gmail.com  Tue Sep  1 01:45:18 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 1 Sep 2009 08:45:18 +0200
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <573143.39036.qm@web25503.mail.ukl.yahoo.com>
References: <114022.98737.qm@web25504.mail.ukl.yahoo.com>
	<573143.39036.qm@web25503.mail.ukl.yahoo.com>
Message-ID: <69d8d540908312345j5277d3acre1735637194d1e67@mail.gmail.com>

On Mon, Aug 31, 2009 at 9:25 PM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
> --- Lun 31/8/09, Marco Atzeri <marco_atzeri at yahoo.it> ha scritto:
>
>> Da: Marco Atzeri <marco_atzeri at yahoo.it>
>> Oggetto: R: quadgk test fault or comparing complex
>> A: "John W. Eaton" <jwe at octave.org>
>> Cc: bug-octave at octave.org
>> Data: Luned? 31 agosto 2009, 19:52
>> --- Lun 31/8/09, John W. Eaton <jwe at octave.org>
>> ha scritto:
>>
>> > Da: John W. Eaton <jwe at octave.org>
>> > Oggetto: quadgk test fault or comparing complex
>> > A: "Marco Atzeri" <marco_atzeri at yahoo.it>
>> > Cc: bug-octave at octave..org
>> > Data: Luned? 31 agosto 2009, 18:14
>> > On 31-Aug-2009, Marco Atzeri wrote:
>> >
>> > | on latest hg source , built on cygwin-1.7 and
>> gcc-4.3..2
>> > | one of the test on quadgk is failing
>> > |
>> > | quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i,
>> -1,-i,
>> > -1+i ])
>> > | error: max_recursion_limit exceeded
>> > | error: called from:
>> > |
>> >
>> error:???/pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m
>> > at line 124, column 15
>> > |
>> > | No problem on octave 3.2.2
>> > | octave:2> quadgk (@(z) log(z), 1+1i,
>> > 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
>> > | ans = 3.5607e-12 - 3.1416e+00i
>> > |
>> > | So it seems related on comparing 2 complex numbers
>> > |
>> > | octave:1> 1+1i < 1+1i
>> > | ans =? 1
>> > | octave:2> 1+1i > 1+1i
>> > | ans = 0
>> >
>> > I can't reproduce this problem with the latest
>> > sources.? I see:
>> >
>> > ? octave:1> 1+1i < 1+1i
>> > ? ans = 0
>> > ? octave:2> 1+1i > 1+1i
>> > ? ans = 0
>> > ? octave:3> quadgk (@(z) log(z), 1+1i,
>> > 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
>> > ? ans = 3.5607e-12 - 3.1416e+00i
>> >
>> > The latest changeset applied for my build is:
>> >
>> > ? changeset:???9587:5ab448e3febe
>> > ? tag:? ? ? ???tip
>> > ? user:? ? ? ? Jaroslav Hajek
>> > <highegg at gmail.com>
>> > ? date:? ? ? ? Sun Aug 30 10:32:10
>> > 2009 +0200
>> > ? summary:? ???remove unused
>> > macros from ops.h
>> >
>> > Are you sure you are current?
>> >
>> > jwe
>>
>>
>> ?hg tip
>> changeset:???9584:0fcbfddaa87f
>> tag:? ? ? ???tip
>> user:? ? ? ? John W. Eaton <jwe at octave.org>
>> date:? ? ? ? Fri Aug 28 05:30:29 2009
>> -0400
>> summary:? ???allow abbreviated graphics
>> property names to match, with optional warning
>>
>> I will rebuild as eventually the last cleaning from
>> Jaroslav
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/319e2ab9b8ae
>>
>> solved the issue.
>>
>> Marco
>>
>
> unfortunately the problem is still here
>
> hg tip
> changeset: ? 9589:8e42bb4ad34d
> tag: ? ? ? ? tip
> user: ? ? ? ?Jaroslav Hajek <highegg at gmail.com>
> date: ? ? ? ?Sun Aug 30 21:56:18 2009 +0200
> summary: ? ? update NEWS
>
>
> octave:2> 1+1i < 1+1i
> ans = ?1
> octave:3> 1+1i > 1+1i
> ans = 0
> octave:4> 1-1i > 1-1i
> ans = ?1
> octave:5> 1-1i < 1-1i
> ans = 0
>
>

Oops. There was a stupid bug impacting the non-strict equality operators:
http://hg.savannah.gnu.org/hgweb/octave/rev/01004c3cde2c

I'm afraid it doesn't explain your problem, though. If you're the only
one to see it, I think there's no other option than to debug and see
what's going on (but I'd suggest a fresh pull+rebuild first just in
case). Incidentally, do you correctly get the matlab-incompatible
warning?

octave:1> warning("on","Octave:matlab-incompatible")
octave:2> 1+1i < 1+1i
warning: potential Matlab compatibility problem: comparing complex numbers
ans = 0
octave:3> 1+1i > 1+1i
warning: potential Matlab compatibility problem: comparing complex numbers
ans = 0

hth

-- 
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 Sep  1 02:27:20 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 1 Sep 2009 09:27:20 +0200
Subject: bug in std.m
In-Reply-To: <19067.8472.459093.991495@segfault.lan>
References: <20090805100310.137970@gmx.net>
	<19067.8472.459093.991495@segfault.lan>
Message-ID: <69d8d540909010027u623acd08qc4971b2306d8e2ce@mail.gmail.com>

On Thu, Aug 6, 2009 at 8:29 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?5-Aug-2009, Christoph Ellenberger wrote:
>
> | I don't know if this was already reported or fixed, but I didn't found anything in the bug archive.
> |
> | I am using the MinGW version 3.2.0 for windows from sourceforge and there I encountered the following.
> |
> | error: `sz' undefined near line 79 column 21
> | error: evaluating argument list element number 1
> | error: evaluating argument list element number 1
> | error: called from:
> | error: ? C:\Programme\Octave\3.2.0_gcc-4.3.0\share\octave\3.2.0\m\statistics\base\std.m at line 79, column 12
> |
> | instead of:
> |
> | ? if (n == 1)
> | ? ? retval = zeros (sz);
> | ? elseif (numel (a) > 0)
> | ? ? retval = sqrt (sumsq (center (a, dim), dim) / (n + opt - 1));
> | ? else
> | ? ? error ("std: x must not be empty");
> | ? endif
> |
> | I guess it should be something like
> |
> | ? if (n == 1)
> | ? ? retval = zeros (size(a));
> | ? elseif (numel (a) > 0)
> | ? ? retval = sqrt (sumsq (center (a, dim), dim) / (n + opt - 1));
> | ? else
> | ? ? error ("std: x must not be empty");
> | ? endif
> |
> | but I am not sure what the intended behaviour should be according to matlab compatibility...
>
> I checked in the following change.
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/bb37822e9b82
>
> Thanks,
>
> jwe

applied 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


From highegg at gmail.com  Tue Sep  1 02:32:06 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 1 Sep 2009 09:32:06 +0200
Subject: datestr.m strangeness
In-Reply-To: <19093.44383.566576.988102@segfault.lan>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
	<69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
	<6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>
	<69d8d540908260345u1df93fe0of39fc1137bd2422d@mail.gmail.com>
	<6b48db1f0908261027v7bb448b4u864d296a752c1190@mail.gmail.com>
	<19093.30081.486771.612893@segfault.lan>
	<6b48db1f0908261432y4d0b9a11gfbe7b93ea294a718@mail.gmail.com>
	<19093.44383.566576.988102@segfault.lan>
Message-ID: <69d8d540909010032q1e20d3fcme1e64518a9ff44a@mail.gmail.com>

On Wed, Aug 26, 2009 at 11:47 PM, John W. Eaton<jwe at octave.org> wrote:
> On 26-Aug-2009, E. Joshua Rigler wrote:
>
> | On Wed, Aug 26, 2009 at 11:48 AM, John W. Eaton<jwe at octave.org> wrote:
> | > On 26-Aug-2009, E. Joshua Rigler wrote:
> | >
> | > | Ah, I understand why mktime is not broken now. ?Thanks for the clarification.
> | > |
> | > | But, datestr.m is still broken (or at least incompatible with m**lab),
> | > | because it does not set tm.isdst before passing tm to mktime. ?ISO C
> | > | states that setting tm.isdst=-1will force mktime to determine whether
> | > | the time in question falls during daylight savings or not. ?I made
> | > | this change to my local copy of datestr.m, and everything now works as
> | > | expected (i.e., datestr(datenum(2009,8,26,12,0,0)) actually returns
> | > | the desired date string).
> | >
> | > How about submitting a changeset, or at least a context diff?
> | >
> | > jwe
> | >
> |
> | I'm not sure what a changeset is, but please find the attached context diff.
>
> I checked in this change, attributed to you:
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/19124db6fc1c
>
> Jaroslav, this could probably go in the 3.2.x branch.
>
> Thanks,
>
> jwe
>

applied, along with your later fix for the missing semicolon.


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


From carlo.defalco at gmail.com  Tue Sep  1 03:08:17 2009
From: carlo.defalco at gmail.com (Carlo de Falco)
Date: Tue, 1 Sep 2009 10:08:17 +0200
Subject: eigs interface inconsistent with documentation?
In-Reply-To: <4A9CBC8E.6060800@dbateman.org>
References: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>
	<4A9C472A.9070403@dbateman.org> <4A9CBC8E.6060800@dbateman.org>
Message-ID: <2A0B6317-D7E6-4BF7-B06A-28AE873A230A@gmail.com>


On 1 Sep 2009, at 08:17, David Bateman wrote:

> Yes that was the issue. The attached patch, which I've pushed to  
> savannah, fixes the issue and adds a test.
>
> D.

Thanks!
Jaroslav, do you think this could be transplanted to the 3.2.x branch  
and go into the upcoming release?
c.


> -- 
> 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)
>
> # HG changeset patch
> # User David Bateman <dbateman at free.fr>
> # Date 1251785759 -7200
> # Node ID cf8403208c43d357e2da1b92d08dd3102db8f0b4
> # Parent  5828d64ca0041ec561dfd6f27deb0548ef70d4d3
> Fix nesting error in options parsing of eigs
>
> diff --git a/src/ChangeLog b/src/ChangeLog
> --- a/src/ChangeLog
> +++ b/src/ChangeLog
> @@ -1,3 +1,9 @@
> +2008-09-01  David Bateman  <dbateman at free.fr>
> +
> +	* DLD-FUNCTIONS/eig.cc (Feigs): Correct nesting error in option
> +	parsing that prevented the use of a function for generalized
> +	eigenvalue problems.
> +
> 2009-08-30  Jaroslav Hajek  <highegg at gmail.com>
>
> 	* ops.h (DEFCMPLXCMPOP_OP, DEFNDCMPLXCMPOP_FN): New macros.
> diff --git a/src/DLD-FUNCTIONS/eigs.cc b/src/DLD-FUNCTIONS/eigs.cc
> --- a/src/DLD-FUNCTIONS/eigs.cc
> +++ b/src/DLD-FUNCTIONS/eigs.cc
> @@ -425,25 +425,27 @@
> 	    }
> 	}
>
> -      // Note hold off reading B till later to avoid issues of double
> -      // copies of the matrix if B is full/real while A is complex..
> -      if (!error_state && nargin > 1 && !(args(1).is_real_scalar ()))
> +    }
> +
> +  // Note hold off reading B till later to avoid issues of double
> +  // copies of the matrix if B is full/real while A is complex..
> +  if (!error_state && nargin > 1 + arg_offset &&
> +      !(args(1 + arg_offset).is_real_scalar ()))
> +    {
> +      if (args(1+arg_offset).is_complex_type ())
> 	{
> -	  if (args(1).is_complex_type ())
> -	    {
> -	      b_arg = 1+arg_offset;
> -	      have_b = true;
> -	      bmat = 'G';
> -	      b_is_complex = true;
> -	      arg_offset++;
> -	    }
> -	  else
> -	    {
> -	      b_arg = 1+arg_offset;
> -	      have_b = true;
> -	      bmat = 'G';
> -	      arg_offset++;
> -	    }
> +	  b_arg = 1+arg_offset;
> +	  have_b = true;
> +	  bmat = 'G';
> +	  b_is_complex = true;
> +	  arg_offset++;
> +	}
> +      else
> +	{
> +	  b_arg = 1+arg_offset;
> +	  have_b = true;
> +	  bmat = 'G';
> +	  arg_offset++;
> 	}
>     }
>
> @@ -834,6 +836,11 @@
> %! d1 = eigs (fn, n, k, 4.1, opts);
> %! assert (d1, eigs(A,k,4.1), 1e-11);
> %!testif HAVE_ARPACK
> +%! AA = speye (10);
> +%! fn = @(x) A * x;
> +%! opts.issym = 1; opts.isreal = 1;
> +%! assert (eigs (fn, 10, AA, 3, 'lm', opts), [1; 1; 1]);
> +%!testif HAVE_ARPACK
> %! [v1,d1] = eigs(A, k, 'lm');
> %! d1 = diag(d1);
> %! for i=1:k


From marco_atzeri at yahoo.it  Tue Sep  1 06:30:57 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Tue, 1 Sep 2009 11:30:57 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <69d8d540908312345j5277d3acre1735637194d1e67@mail.gmail.com>
Message-ID: <596430.15230.qm@web25505.mail.ukl.yahoo.com>

--- Mar 1/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:

> I'm afraid it doesn't explain your problem, though. If
> you're the only
> one to see it, I think there's no other option than to
> debug and see
> what's going on (but I'd suggest a fresh pull+rebuild first
> just in
> case). Incidentally, do you correctly get the
> matlab-incompatible
> warning?
> 
> octave:1> warning("on","Octave:matlab-incompatible")
> octave:2> 1+1i < 1+1i
> warning: potential Matlab compatibility problem: comparing
> complex numbers
> ans = 0
> octave:3> 1+1i > 1+1i
> warning: potential Matlab compatibility problem: comparing
> complex numbers
> ans = 0
> 
> hth
> 
> -- 
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)

Hi Jaroslav,
rebuilt from scratch, 

$hg tip 
changeset:   9594:01004c3cde2c
tag:         tip
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Tue Sep 01 08:42:08 2009 +0200
summary:     fix non-strict complex comparisons

No difference

octave:5> warning("on","Octave:matlab-incompatible")
octave:6> 1+i < 1+i
warning: potential Matlab compatibility problem: comparing complex numbers
ans =  1
octave:7> 1+i > 1+i
warning: potential Matlab compatibility problem: comparing complex numbers
ans = 0
octave:8> 1-i < 1-i
warning: potential Matlab compatibility problem: comparing complex numbers
ans = 0
octave:9> 1-i > 1-i
warning: potential Matlab compatibility problem: comparing complex numbers
ans =  1

I suspect another cygwin/newlib difference vs libc implementation.

Regards
Marco



      



From highegg at gmail.com  Tue Sep  1 06:45:34 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 1 Sep 2009 13:45:34 +0200
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <596430.15230.qm@web25505.mail.ukl.yahoo.com>
References: <69d8d540908312345j5277d3acre1735637194d1e67@mail.gmail.com>
	<596430.15230.qm@web25505.mail.ukl.yahoo.com>
Message-ID: <69d8d540909010445s7873783ftedcabc74732a5829@mail.gmail.com>

On Tue, Sep 1, 2009 at 1:30 PM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
> --- Mar 1/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:
>
>> I'm afraid it doesn't explain your problem, though. If
>> you're the only
>> one to see it, I think there's no other option than to
>> debug and see
>> what's going on (but I'd suggest a fresh pull+rebuild first
>> just in
>> case). Incidentally, do you correctly get the
>> matlab-incompatible
>> warning?
>>
>> octave:1> warning("on","Octave:matlab-incompatible")
>> octave:2> 1+1i < 1+1i
>> warning: potential Matlab compatibility problem: comparing
>> complex numbers
>> ans = 0
>> octave:3> 1+1i > 1+1i
>> warning: potential Matlab compatibility problem: comparing
>> complex numbers
>> ans = 0
>>
>> hth
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>
> Hi Jaroslav,
> rebuilt from scratch,
>
> $hg tip
> changeset: ? 9594:01004c3cde2c
> tag: ? ? ? ? tip
> user: ? ? ? ?Jaroslav Hajek <highegg at gmail.com>
> date: ? ? ? ?Tue Sep 01 08:42:08 2009 +0200
> summary: ? ? fix non-strict complex comparisons
>
> No difference
>
> octave:5> warning("on","Octave:matlab-incompatible")
> octave:6> 1+i < 1+i
> warning: potential Matlab compatibility problem: comparing complex numbers
> ans = ?1
> octave:7> 1+i > 1+i
> warning: potential Matlab compatibility problem: comparing complex numbers
> ans = 0
> octave:8> 1-i < 1-i
> warning: potential Matlab compatibility problem: comparing complex numbers
> ans = 0
> octave:9> 1-i > 1-i
> warning: potential Matlab compatibility problem: comparing complex numbers
> ans = ?1
>

OK, so you do seem to have the latest tip.

> I suspect another cygwin/newlib difference vs libc implementation.
>

Even in an arbitrarily screwed-up implementation, std::abs and
std::arg should give identical results for identical arguments, so I
still don't see where that behavior can come from. Let's try a simple
test: compile & run the following in octave/liboctave directory using
the same CXXFLAGS as used by your configuration:

#include <iostream>
#include "oct-cmplx.h"

int main ()
{
  Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
  std::cout << (z1 < z2) << '\n';
}

You should get 0. Is that OK?
If yes, then please recompile with the following patchlet:

diff --git a/liboctave/oct-cmplx.h b/liboctave/oct-cmplx.h
--- a/liboctave/oct-cmplx.h
+++ b/liboctave/oct-cmplx.h
@@ -25,6 +25,7 @@
 #define octave_oct_cmplx_h 1

 #include <complex>
+#include <iostream>

 typedef std::complex<double> Complex;
 typedef std::complex<float> FloatComplex;
@@ -41,6 +42,8 @@
 inline bool operator OP (const std::complex<T>& a, const std::complex<T>& b) \
 { \
   T ax = std::abs (a), bx = std::abs (b); \
+  std::cerr << ax << ' ' << bx << ' ' << (ax OPS bx) << '\n'; \
+  std::cerr << std::arg(a) << ' ' << std::arg(b) << ' ' <<
(std::arg(a) OP std::arg(b)) << '\n'; \
   return ax OPS bx || (ax == bx && std::arg (a) OP std::arg (b)); \
 } \
 template <class T> \

and test the inequality again, and report the results.

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  Tue Sep  1 07:28:03 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Tue, 1 Sep 2009 12:28:03 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <69d8d540909010445s7873783ftedcabc74732a5829@mail.gmail.com>
Message-ID: <691451.42109.qm@web25501.mail.ukl.yahoo.com>

--- Mar 1/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:

> Da: Jaroslav Hajek <highegg at gmail.com>
> Oggetto: Re: R: quadgk test fault or comparing complex
> A: "Marco Atzeri" <marco_atzeri at yahoo.it>
> Cc: "John W. Eaton" <jwe at octave.org>, bug-octave at octave.org
> Data: Marted? 1 settembre 2009, 13:45
> On Tue, Sep 1, 2009 at 1:30 PM, Marco
> Atzeri<marco_atzeri at yahoo.it>
> wrote:
> > --- Mar 1/9/09, Jaroslav Hajek <highegg at gmail.com>
> ha scritto:
> >
> >> I'm afraid it doesn't explain your problem,
> though. If
> >> you're the only
> >> one to see it, I think there's no other option
> than to
> >> debug and see
> >> what's going on (but I'd suggest a fresh
> pull+rebuild first
> >> just in
> >> case). Incidentally, do you correctly get the
> >> matlab-incompatible
> >> warning?
> >>
> >> octave:1>
> warning("on","Octave:matlab-incompatible")
> >> octave:2> 1+1i < 1+1i
> >> warning: potential Matlab compatibility problem:
> comparing
> >> complex numbers
> >> ans = 0
> >> octave:3> 1+1i > 1+1i
> >> warning: potential Matlab compatibility problem:
> comparing
> >> complex numbers
> >> ans = 0
> >>
> >> hth
> >>
> >> --
> >> RNDr. Jaroslav Hajek
> >> computing expert & GNU Octave developer
> >> Aeronautical Research and Test Institute (VZLU)
> >
> > Hi Jaroslav,
> > rebuilt from scratch,
> >
> > $hg tip
> > changeset: ? 9594:01004c3cde2c
> > tag: ? ? ? ? tip
> > user: ? ? ? ?Jaroslav Hajek <highegg at gmail.com>
> > date: ? ? ? ?Tue Sep 01 08:42:08 2009 +0200
> > summary: ? ? fix non-strict complex comparisons
> >
> > No difference
> >
> > octave:5>
> warning("on","Octave:matlab-incompatible")
> > octave:6> 1+i < 1+i
> > warning: potential Matlab compatibility problem:
> comparing complex numbers
> > ans = ?1
> > octave:7> 1+i > 1+i
> > warning: potential Matlab compatibility problem:
> comparing complex numbers
> > ans = 0
> > octave:8> 1-i < 1-i
> > warning: potential Matlab compatibility problem:
> comparing complex numbers
> > ans = 0
> > octave:9> 1-i > 1-i
> > warning: potential Matlab compatibility problem:
> comparing complex numbers
> > ans = ?1
> >
> 
> OK, so you do seem to have the latest tip.
> 
> > I suspect another cygwin/newlib difference vs libc
> implementation.
> >
> 
> Even in an arbitrarily screwed-up implementation, std::abs
> and
> std::arg should give identical results for identical
> arguments, so I

it seems that something here is wrong....

> still don't see where that behavior can come from. Let's
> try a simple
> test: compile & run the following in octave/liboctave
> directory using
> the same CXXFLAGS as used by your configuration:
> 
> #include <iostream>
> #include "oct-cmplx.h"
> 
> int main ()
> {
> ? Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
> ? std::cout << (z1 < z2) << '\n';
> }
> 
> You should get 0. Is that OK?

I changed in

#include <iostream>
#include "oct-cmplx.h"

int main ()
{
  Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
  std::cout << (z1 < z2) << '\n';
  std::cout << (abs(z1)) << '\n';
  std::cout << (abs(z2)) << '\n';
  std::cout << (abs(z1)<abs(z2)) << '\n';
  std::cout << (arg(z1)) << '\n';
  std::cout << (arg(z2)) << '\n';
  std::cout << (arg(z1)<arg(z2)) << '\n';
}

and unfortunately the output is
1
1.41421
1.41421
0
0.785398
0.785398
1

I will investigate on cygwin list for this puzzling outcome

> 
> hth
> 

Thanks 
Marco


      



From highegg at gmail.com  Tue Sep  1 07:38:52 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 1 Sep 2009 14:38:52 +0200
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <691451.42109.qm@web25501.mail.ukl.yahoo.com>
References: <69d8d540909010445s7873783ftedcabc74732a5829@mail.gmail.com>
	<691451.42109.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <69d8d540909010538w715b2499qe90bda62c6eae505@mail.gmail.com>

On Tue, Sep 1, 2009 at 2:28 PM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
> --- Mar 1/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:
>
>> Da: Jaroslav Hajek <highegg at gmail.com>
>> Oggetto: Re: R: quadgk test fault or comparing complex
>> A: "Marco Atzeri" <marco_atzeri at yahoo.it>
>> Cc: "John W. Eaton" <jwe at octave.org>, bug-octave at octave.org
>> Data: Marted? 1 settembre 2009, 13:45
>> On Tue, Sep 1, 2009 at 1:30 PM, Marco
>> Atzeri<marco_atzeri at yahoo.it>
>> wrote:
>> > --- Mar 1/9/09, Jaroslav Hajek <highegg at gmail.com>
>> ha scritto:
>> >
>> >> I'm afraid it doesn't explain your problem,
>> though. If
>> >> you're the only
>> >> one to see it, I think there's no other option
>> than to
>> >> debug and see
>> >> what's going on (but I'd suggest a fresh
>> pull+rebuild first
>> >> just in
>> >> case). Incidentally, do you correctly get the
>> >> matlab-incompatible
>> >> warning?
>> >>
>> >> octave:1>
>> warning("on","Octave:matlab-incompatible")
>> >> octave:2> 1+1i < 1+1i
>> >> warning: potential Matlab compatibility problem:
>> comparing
>> >> complex numbers
>> >> ans = 0
>> >> octave:3> 1+1i > 1+1i
>> >> warning: potential Matlab compatibility problem:
>> comparing
>> >> complex numbers
>> >> ans = 0
>> >>
>> >> hth
>> >>
>> >> --
>> >> RNDr. Jaroslav Hajek
>> >> computing expert & GNU Octave developer
>> >> Aeronautical Research and Test Institute (VZLU)
>> >
>> > Hi Jaroslav,
>> > rebuilt from scratch,
>> >
>> > $hg tip
>> > changeset: ? 9594:01004c3cde2c
>> > tag: ? ? ? ? tip
>> > user: ? ? ? ?Jaroslav Hajek <highegg at gmail.com>
>> > date: ? ? ? ?Tue Sep 01 08:42:08 2009 +0200
>> > summary: ? ? fix non-strict complex comparisons
>> >
>> > No difference
>> >
>> > octave:5>
>> warning("on","Octave:matlab-incompatible")
>> > octave:6> 1+i < 1+i
>> > warning: potential Matlab compatibility problem:
>> comparing complex numbers
>> > ans = ?1
>> > octave:7> 1+i > 1+i
>> > warning: potential Matlab compatibility problem:
>> comparing complex numbers
>> > ans = 0
>> > octave:8> 1-i < 1-i
>> > warning: potential Matlab compatibility problem:
>> comparing complex numbers
>> > ans = 0
>> > octave:9> 1-i > 1-i
>> > warning: potential Matlab compatibility problem:
>> comparing complex numbers
>> > ans = ?1
>> >
>>
>> OK, so you do seem to have the latest tip.
>>
>> > I suspect another cygwin/newlib difference vs libc
>> implementation.
>> >
>>
>> Even in an arbitrarily screwed-up implementation, std::abs
>> and
>> std::arg should give identical results for identical
>> arguments, so I
>
> it seems that something here is wrong....
>

Apparently, judging by the results you gave below. But of course the
above premise is fundamental; so I suspect a serious compiler bug. Did
you also try at -O0? Please let me know if you discover more.

>> still don't see where that behavior can come from. Let's
>> try a simple
>> test: compile & run the following in octave/liboctave
>> directory using
>> the same CXXFLAGS as used by your configuration:
>>
>> #include <iostream>
>> #include "oct-cmplx.h"
>>
>> int main ()
>> {
>> ? Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
>> ? std::cout << (z1 < z2) << '\n';
>> }
>>
>> You should get 0. Is that OK?
>
> I changed in
>
> #include <iostream>
> #include "oct-cmplx.h"
>
> int main ()
> {
> ?Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
> ?std::cout << (z1 < z2) << '\n';
> ?std::cout << (abs(z1)) << '\n';
> ?std::cout << (abs(z2)) << '\n';
> ?std::cout << (abs(z1)<abs(z2)) << '\n';
> ?std::cout << (arg(z1)) << '\n';
> ?std::cout << (arg(z2)) << '\n';
> ?std::cout << (arg(z1)<arg(z2)) << '\n';
> }
>
> and unfortunately the output is
> 1
> 1.41421
> 1.41421
> 0
> 0.785398
> 0.785398
> 1
>
> I will investigate on cygwin list for this puzzling outcome
>
>>
>> hth
>>
>
> Thanks
> Marco
>
>

regards

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


From carlo.defalco at gmail.com  Tue Sep  1 08:20:20 2009
From: carlo.defalco at gmail.com (Carlo de Falco)
Date: Tue, 1 Sep 2009 15:20:20 +0200
Subject: eigs interface inconsistent with documentation?
In-Reply-To: <2A0B6317-D7E6-4BF7-B06A-28AE873A230A@gmail.com>
References: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>
	<4A9C472A.9070403@dbateman.org> <4A9CBC8E.6060800@dbateman.org>
	<2A0B6317-D7E6-4BF7-B06A-28AE873A230A@gmail.com>
Message-ID: <9561574C-8B25-4825-B660-513DE39E3FA7@gmail.com>


On 1 Sep 2009, at 10:08, Carlo de Falco wrote:

>
> On 1 Sep 2009, at 08:17, David Bateman wrote:
>
>> Yes that was the issue. The attached patch, which I've pushed to  
>> savannah, fixes the issue and adds a test.
>>
>> D.
>
> Thanks!
> Jaroslav, do you think this could be transplanted to the 3.2.x  
> branch and go into the upcoming release?
> c.

FYI, this patch applied cleanly to "eigs.cc" from version 3.2.2 and  
the resulting eigs.oct passes all tests (including the new one), thanks!
BTW, I think you had a typo in the patch below in the part regarding  
the test, I believe you probably meant:

fn = @(x) AA * x;

instead of

fn = @(x) A * x;

is this right?
c.

>> -- 
>> 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)
>>
>> # HG changeset patch
>> # User David Bateman <dbateman at free.fr>
>> # Date 1251785759 -7200
>> # Node ID cf8403208c43d357e2da1b92d08dd3102db8f0b4
>> # Parent  5828d64ca0041ec561dfd6f27deb0548ef70d4d3
>> Fix nesting error in options parsing of eigs
>>
>> diff --git a/src/ChangeLog b/src/ChangeLog
>> --- a/src/ChangeLog
>> +++ b/src/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2008-09-01  David Bateman  <dbateman at free.fr>
>> +
>> +	* DLD-FUNCTIONS/eig.cc (Feigs): Correct nesting error in option
>> +	parsing that prevented the use of a function for generalized
>> +	eigenvalue problems.
>> +
>> 2009-08-30  Jaroslav Hajek  <highegg at gmail.com>
>>
>> 	* ops.h (DEFCMPLXCMPOP_OP, DEFNDCMPLXCMPOP_FN): New macros.
>> diff --git a/src/DLD-FUNCTIONS/eigs.cc b/src/DLD-FUNCTIONS/eigs.cc
>> --- a/src/DLD-FUNCTIONS/eigs.cc
>> +++ b/src/DLD-FUNCTIONS/eigs.cc
>> @@ -425,25 +425,27 @@
>> 	    }
>> 	}
>>
>> -      // Note hold off reading B till later to avoid issues of  
>> double
>> -      // copies of the matrix if B is full/real while A is complex..
>> -      if (!error_state && nargin > 1 && !(args(1).is_real_scalar  
>> ()))
>> +    }
>> +
>> +  // Note hold off reading B till later to avoid issues of double
>> +  // copies of the matrix if B is full/real while A is complex..
>> +  if (!error_state && nargin > 1 + arg_offset &&
>> +      !(args(1 + arg_offset).is_real_scalar ()))
>> +    {
>> +      if (args(1+arg_offset).is_complex_type ())
>> 	{
>> -	  if (args(1).is_complex_type ())
>> -	    {
>> -	      b_arg = 1+arg_offset;
>> -	      have_b = true;
>> -	      bmat = 'G';
>> -	      b_is_complex = true;
>> -	      arg_offset++;
>> -	    }
>> -	  else
>> -	    {
>> -	      b_arg = 1+arg_offset;
>> -	      have_b = true;
>> -	      bmat = 'G';
>> -	      arg_offset++;
>> -	    }
>> +	  b_arg = 1+arg_offset;
>> +	  have_b = true;
>> +	  bmat = 'G';
>> +	  b_is_complex = true;
>> +	  arg_offset++;
>> +	}
>> +      else
>> +	{
>> +	  b_arg = 1+arg_offset;
>> +	  have_b = true;
>> +	  bmat = 'G';
>> +	  arg_offset++;
>> 	}
>>    }
>>
>> @@ -834,6 +836,11 @@
>> %! d1 = eigs (fn, n, k, 4.1, opts);
>> %! assert (d1, eigs(A,k,4.1), 1e-11);
>> %!testif HAVE_ARPACK
>> +%! AA = speye (10);
>> +%! fn = @(x) A * x;
>> +%! opts.issym = 1; opts.isreal = 1;
>> +%! assert (eigs (fn, 10, AA, 3, 'lm', opts), [1; 1; 1]);
>> +%!testif HAVE_ARPACK
>> %! [v1,d1] = eigs(A, k, 'lm');
>> %! d1 = diag(d1);
>> %! for i=1:k
>


From Alexander.Klein at math.uni-giessen.de  Tue Sep  1 03:35:34 2009
From: Alexander.Klein at math.uni-giessen.de (Alexander Klein)
Date: Tue, 01 Sep 2009 10:35:34 +0200
Subject: make check crashes in data.cc on OSX 10.5.8 PPC
Message-ID: <4A9CDCD6.6010100@math.uni-giessen.de>

Hi,

while building octave 3.2.2 I experienced a crash during make check.

I've attached anything I thought could be useful for locating the bug:

1. Terminal output as found in fntests.log
2. Callback and linking info in octave_2009-09-01.....crash
3. octave-core (gdb claims that it's not a valid core file, but maybe it 
can help anyway).

The problem seems limited to PPC, as I had no problems building on Intel.

If I can do anything further, please let me know!

Kind regards,

	Alex

-- 
Alexander Klein, Dipl.-Math.                    Fon: 0641/99-32194
Lehrstuhl f?r Numerische Mathematik             Fax: 0641/99-32199
Heinrich-Buff-Ring 44
35392 Giessen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fntests.log
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/ee6d46ec/attachment-0001.ksh 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave_2009-09-01-090932_alexander-kleins-emac.crash
Type: text/x-apport
Size: 33763 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/ee6d46ec/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave-core
Type: application/octet-stream
Size: 28448 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/ee6d46ec/attachment-0001.obj 

From dbateman at dbateman.org  Tue Sep  1 14:04:39 2009
From: dbateman at dbateman.org (David Bateman)
Date: Tue, 01 Sep 2009 21:04:39 +0200
Subject: eigs interface inconsistent with documentation?
In-Reply-To: <9561574C-8B25-4825-B660-513DE39E3FA7@gmail.com>
References: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>
	<4A9C472A.9070403@dbateman.org> <4A9CBC8E.6060800@dbateman.org>
	<2A0B6317-D7E6-4BF7-B06A-28AE873A230A@gmail.com>
	<9561574C-8B25-4825-B660-513DE39E3FA7@gmail.com>
Message-ID: <4A9D7047.2010105@dbateman.org>

Carlo de Falco wrote:
>
> FYI, this patch applied cleanly to "eigs.cc" from version 3.2.2 and 
> the resulting eigs.oct passes all tests (including the new one), thanks!
> BTW, I think you had a typo in the patch below in the part regarding 
> the test, I believe you probably meant:
>
> fn = @(x) AA * x;
>
> instead of
>
> fn = @(x) A * x;
>
> is this right?
> c.
Yes that is a mistake. Trivial changeset pushed to savannah.

D.


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


From jwe at octave.org  Tue Sep  1 15:37:26 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 1 Sep 2009 16:37:26 -0400
Subject: A backend("fltk") problem
In-Reply-To: <4A9749CF.6030708@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
Message-ID: <19101.34310.961893.954083@segfault.lan>

On 27-Aug-2009, Michael D Godfrey wrote:

| When experimenting with the current fltk I have found that
| it often seg faults at the same place.  In some complicated
| plots the fault occurs without use of "title" commands.  However,
| these cases would require a lot of code and setup.
| The plot has been drawn by the time the seg fault occurs in
| all cases.
| 
| This happened using yesterday's hg repository.
| 
| I noticed that the same seg fault occurs in this simple
| example:
| ============================================
| [godfrey-pbdsl3.stanford.edu:godfrey] gdb octave
| GNU gdb (GDB) Fedora (6.8.50.20090302-37.fc11)
| Copyright (C) 2009 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later 
| <http://gnu.org/licenses/gpl.html>
| 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 "x86_64-redhat-linux-gnu".
| For bug reporting instructions, please see:
| <http://www.gnu.org/software/gdb/bugs/>...
| (gdb) run
| Starting program: /usr/local/bin/octave
| [Thread debugging using libthread_db enabled]
| GNU Octave, version 3.1.55
| 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-unknown-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 <bug at octave.org> (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'.
| 
| octave:1> backend("fltk");
| octave:2> plot([1:20])
| octave:3> title("123");
| octave:4> error: could not match any font: *-normal-normal-12
| error: ft_manager: unable to load font:
| error: ft_render: unable to load appropriate font
| error: could not match any font: *-normal-normal-12
| error: ft_manager: unable to load font:
| error: ft_render: unable to load appropriate font
| error: ft_render: font not initialized
| 
| Program received signal SIGSEGV, Segmentation fault.
| 0x00007ffff7329273 in octave_value::~octave_value (this=<value optimized 
| out>, __in_chrg=<value optimized out>)
|      at ov.h:297

Do you have fontconfig installed on your system, and did Octave's
configure script detect it?

I think the problem would be solved by a patch something like this:

diff --git a/src/txt-eng-ft.cc b/src/txt-eng-ft.cc
--- a/src/txt-eng-ft.cc
+++ b/src/txt-eng-ft.cc
@@ -163,7 +163,7 @@
 #ifdef __WIN32__
 	  file = "C:/WINDOWS/Fonts/verdana.ttf";
 #else
-	  // FIXME: find a "standard" font for UNIX platforms
+	  file = "/usr/share/fonts/truetype/freefont/FreeSans.ttf";
 #endif
 	}
 
but we should probably just use the same default font on all systems,
and distribute it with Octave.  The location of the default font
should be configurable at run time, so that Octave can find it when it
is installed, or when it is running in the build directory via the
run-octave script.

Comments?

jwe

From rdgrdgrdg at verizon.net  Tue Sep  1 15:11:51 2009
From: rdgrdgrdg at verizon.net (Richard Greenblatt)
Date: Tue, 01 Sep 2009 16:11:51 -0400
Subject: Subject: mex broken on OS-X Snow Leopard. Current .dmg probably loses
	on all Mac Intel.
Message-ID: <AEC1D2B3-D7B3-444E-A52D-1A1425353FEB@verizon.net>


Bug report for Octave 3.2.2 configured for i386-apple-darwin8.11.1

Description:  mex broken
-----------

octave-3.2.2:21> mex 'segmentImgOpt.cpp'
ld: warning: in /Applications/Octave.app/Contents/Resources/bin/ 
octave-3.2.2, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
octave-3.2.2/liboctinterp.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
octave-3.2.2/liboctave.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
octave-3.2.2/libcruft.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
libfftw3.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
libfftw3f.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
libreadline.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
libhdf5.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
libz.dylib, file is not of required architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/gcc- 
lib/i386-apple-darwin8.11.1/4.0.3/libf95.a, file is not of required  
architecture
ld: warning: in /Applications/Octave.app/Contents/Resources/lib/gcc- 
lib/i386-apple-darwin8.11.1/4.0.3/libgcc.a, file is not of required  
architecture
Undefined symbols:
   "_mxArrayToString", referenced from:
       _mexFunction in segmentImgOpt.o
   "_mxGetDimensions", referenced from:
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
   "_mxIsChar", referenced from:
       _mexFunction in segmentImgOpt.o
   "_mxIsComplex", referenced from:
       _mexFunction in segmentImgOpt.o
   "_mexErrMsgTxt", referenced from:
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
   "_mxCreateDoubleMatrix", referenced from:
       _mexFunction in segmentImgOpt.o
   "_mxGetPr", referenced from:
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
       _mexFunction in segmentImgOpt.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
octave-3.2.2:22>

    mex associated files evidently not compiled correctly for Snow  
Leopard

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

    just try to use mex

Fix:
---

    needs to be recompiled specific to target machine.
    versions for PPC and Intel may need to be forked for .dmg file  
purposes
        unless octave can deal with fat binaries, etc.



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

uname output:     Darwin 31-35-120.wireless.csail.mit.edu 10.0.0  
Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009;  
root:xnu-1456.1.25~1/RELEASE_I386 i386 i386
configure opts:   'CC=gcc -arch i386' 'CPP=gcc -arch i386 -E' 'CXX=g++  
-arch i386' 'F77=i386-apple-darwin8.11.1-g95' 'CFLAGS=-O3 -fforce-addr  
-march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx - 
isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include'  
'CPPFLAGS=-O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp - 
msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/ 
tmp/deps-i386/include' 'CXXFLAGS=-O3 -fforce-addr -march=i686 - 
mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx -isysroot / 
Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include' 'FFLAGS=-O3 - 
fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse  
-mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/ 
include' 'FLIBS=' 'LDFLAGS=-L/tmp/deps-i386/lib -Wl,- 
headerpad_max_install_names   -Wl,-syslibroot -Wl,/Developer/SDKs/ 
MacOSX10.4u.sdk' '--prefix=/tmp/deps-i386' '--host=i386-apple- 
darwin8.11.1' '--without-x' '--enable-shared' '--disable-static'  
'host_alias=i386-apple-darwin8.11.1'
Fortran compiler: i386-apple-darwin8.11.1-g95
FFLAGS:           -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- 
fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk  
-I/tmp/deps-i386/include -mieee-fp
FLIBS:            -L/tmp/deps-i386/lib -L/private/tmp/deps-i386/bin/../ 
lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3/ -L/private/tmp/deps-i386/ 
bin/../lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3 -L/usr/lib/gcc// -L/ 
private/tmp/deps-i386/bin/../lib/gcc-lib/i386-apple- 
darwin8.11.1/4.0.3/// -L/usr/lib// -lhdf5 -lz -lf95 -lm -lSystemStubs - 
lmx
CPPFLAGS:         -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- 
fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk  
-I/tmp/deps-i386/include -I/tmp/deps-i386/include
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc -arch i386, version 4.0.1 (Apple Computer, Inc.  
build 5370)
CFLAGS:           -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- 
fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk  
-I/tmp/deps-i386/include
CPICFLAG:         -fPIC
C++ compiler:     g++ -arch i386, version 4.0.1
CXXFLAGS:         -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- 
fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk  
-I/tmp/deps-i386/include
CXXPICFLAG:       -fPIC
LD_CXX:           g++ -arch i386
LDFLAGS:          -L/tmp/deps-i386/lib -Wl,- 
headerpad_max_install_names   -Wl,-syslibroot -Wl,/Developer/SDKs/ 
MacOSX10.4u.sdk
LIBFLAGS:         -L.
RLD_FLAG:
BLAS_LIBS:        -Wl,-framework -Wl,vecLib
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -Wl,-framework -Wl,vecLib - 
lhdf5 -lz -lm
LEXLIB:
LIBGLOB:
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_FRAMEWORK_CARBON=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_GLUTESSCALLBACK_THREEDOTS=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_AMD_H=1 -DHAVE_AMD=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_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=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_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 - 
DOCTAVE_HAVE_BROKEN_STRPTIME=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 = emacs
   EXEC_PATH = /Applications/Octave.app/Contents/Resources/libexec/ 
octave/3.2.2/site/exec/i386-apple-darwin8.11.1:/Applications/ 
Octave.app/Contents/Resources/libexec/octave/api-v37/site/exec/i386- 
apple-darwin8.11.1:/Applications/Octave.app/Contents/Resources/libexec/ 
octave/site/exec/i386-apple-darwin8.11.1:/Applications/Octave.app/ 
Contents/Resources/libexec/octave/3.2.2/exec/i386-apple-darwin8.11.1:/ 
Applications/Octave.app/Contents/Resources/bin:/Applications/ 
Octave.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ 
local/bin:/usr/X11/bin:/usr/local/bin/:/opt/local/bin:/Users/rg/bin:/ 
opt/gtk/bin:/usr/local/cuda/bin
   IMAGE_PATH = .:/Applications/Octave.app/Contents/Resources/share/ 
octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
   history_file = /Users/rg/.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 = 1
# print_answer_id_name = <no value or error in displaying it>
   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 Sep  1 15:50:34 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 1 Sep 2009 16:50:34 -0400
Subject: wavread(..., 'size') bug in 3.2.0
In-Reply-To: <615AE594-8CF3-4E04-BB5B-DB9F7966C771@illusonic.com>
References: <F610C3E8-DFFD-43DC-81DF-346E9A6B3948@illusonic.com>
	<615AE594-8CF3-4E04-BB5B-DB9F7966C771@illusonic.com>
Message-ID: <19101.35098.821388.512590@segfault.lan>

On 29-Aug-2009, Christophe Tournery wrote:

| Hi Octave developers,
| 
| Attached is a hg patch for wavread in order to restore the  
| functionality wavread("filename.wav", "size").
| This applies to Octave 3.2.2.
| See previous bug description below.

I made this change.

Thanks,

jwe

From jwe at octave.org  Tue Sep  1 15:58:52 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 1 Sep 2009 16:58:52 -0400
Subject: make check crashes in data.cc on OSX 10.5.8 PPC
In-Reply-To: <4A9CDCD6.6010100@math.uni-giessen.de>
References: <4A9CDCD6.6010100@math.uni-giessen.de>
Message-ID: <19101.35596.456023.939880@segfault.lan>

On  1-Sep-2009, Alexander Klein wrote:

| while building octave 3.2.2 I experienced a crash during make check.
| 
| I've attached anything I thought could be useful for locating the bug:
| 
| 1. Terminal output as found in fntests.log
| 2. Callback and linking info in octave_2009-09-01.....crash
| 3. octave-core (gdb claims that it's not a valid core file, but maybe it 
| can help anyway).

The octave-core file contains the Octave workspace at the time of the
crash.  It's not for debugging, but to help you avoid losing work if
Octave crashes.

| The problem seems limited to PPC, as I had no problems building on Intel.
| 
| If I can do anything further, please let me know!

I can't duplicate this problem on my system (not OS X, or PPC).
Perhaps someone else who has access to a system like yours can?
Otherwise, I think you will need to do some debugging to find the
cause of the crash and fix it.

I would start by isolating the test that causes the crash, then
run Octave under gdb and find precisely where it crashes.

| 0   libstdc++.6.dylib             	0x91925094 std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_float<double>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, char, double) const + 552
| 1   libstdc++.6.dylib             	0x91925124 std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, double) const + 36
| 2   libstdc++.6.dylib             	0x9192ef74 std::basic_ostream<char, std::char_traits<char> >::operator<<(double) + 200
| 3   liboctinterp.dylib            	0x014d7948 operator<<(std::basic_ostream<char, std::char_traits<char> >&, pr_formatted_float const&) + 136
| 4   liboctinterp.dylib            	0x014e39e8 pr_any_float(float_format const*, std::basic_ostream<char, std::char_traits<char> >&, double, int) + 1560
| 5   liboctinterp.dylib            	0x014e7454 pr_complex(std::basic_ostream<char, std::char_traits<char> >&, std::complex<double> const&, int, int, double) + 372
| 6   liboctinterp.dylib            	0x014e98f8 octave_print_internal(std::basic_ostream<char, std::char_traits<char> >&, std::complex<double> const&, bool) + 616
| 7   liboctinterp.dylib            	0x015dc5b8 octave_base_scalar<std::complex<double> >::print(std::basic_ostream<char, std::char_traits<char> >&, bool) const + 40 (ov-base-scalar.cc:121)
| 8   liboctinterp.dylib            	0x014e9af4 Fdisp(octave_value_list const&, int) + 404


>From this, it looks like it is crashing inside disp while printing a
complex value.  But that seems suspicious.  If you start Octave and do
something like

  disp (1+i)

does it crash?

jwe


From marco_atzeri at yahoo.it  Tue Sep  1 16:26:10 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Tue, 1 Sep 2009 21:26:10 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <69d8d540909010538w715b2499qe90bda62c6eae505@mail.gmail.com>
Message-ID: <647710.15208.qm@web25505.mail.ukl.yahoo.com>

--- Mar 1/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:
[cut]
> >>
> >> OK, so you do seem to have the latest tip.
> >>
> >> > I suspect another cygwin/newlib difference vs
> libc
> >> implementation.
> >> >
> >>
> >> Even in an arbitrarily screwed-up implementation,
> std::abs
> >> and
> >> std::arg should give identical results for
> identical
> >> arguments, so I
> >
> > it seems that something here is wrong....
> >
> 
> Apparently, judging by the results you gave below. But of
> course the
> above premise is fundamental; so I suspect a serious
> compiler bug. Did
> you also try at -O0? Please let me know if you discover
> more.
> 
> >> still don't see where that behavior can come from.
> Let's
> >> try a simple
> >> test: compile & run the following in
> octave/liboctave
> >> directory using
> >> the same CXXFLAGS as used by your configuration:
> >>
> >> #include <iostream>
> >> #include "oct-cmplx.h"
> >>
> >> int main ()
> >> {
> >> ? Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
> >> ? std::cout << (z1 < z2) << '\n';
> >> }
> >>
> >> You should get 0. Is that OK?
> >
> > I changed in
> >
> > #include <iostream>
> > #include "oct-cmplx.h"
> >
> > int main ()
> > {
> > ?Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
> > ?std::cout << (z1 < z2) << '\n';
> > ?std::cout << (abs(z1)) << '\n';
> > ?std::cout << (abs(z2)) << '\n';
> > ?std::cout << (abs(z1)<abs(z2)) <<
> '\n';
> > ?std::cout << (arg(z1)) << '\n';
> > ?std::cout << (arg(z2)) << '\n';
> > ?std::cout << (arg(z1)<arg(z2)) <<
> '\n';
> > }
> >
> > and unfortunately the output is
> > 1
> > 1.41421
> > 1.41421
> > 0
> > 0.785398
> > 0.785398
> > 1
> >
> > I will investigate on cygwin list for this puzzling
> outcome

Hi Jaroslav,
it seems a variant of 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2

with any -O flag

 (arg(z1)-arg(z2)) = -3.06287e-17

but adding -ffloat-store flag

 (arg(z1)-arg(z2)) = 0


octave:1> 1+i < 1+i
ans = 0
octave:2> 1+i > 1+i
ans = 0

> regards
> 
> -- 
> RNDr. Jaroslav Hajek

Thanks
Marco



      



From godfrey at isl.stanford.edu  Tue Sep  1 20:58:44 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Tue, 01 Sep 2009 18:58:44 -0700
Subject: Interpreter tex is broken
Message-ID: <4A9DD154.1020706@isl.stanford.edu>

While testing the backend("fltk") plotting mode I noticed that
setting the property "interpreter", "tex" no longer works as
it used to.  These tests were done using a test version of the
current 3.1.55.

I then tried the same tests using 3.1.55 without backend("fltk").
This produced the same results as with backend("fltk").

Then I tried 3.0.5 (the current Fedora release).  It behaved the
same way.

Attached are a test script and a PS output of the plot it
draws when working correctly,  It worked with the current
development system on 9 April 2008.

Since this error is unchanged whether "fltk" is used or not,
the error appears to be outside the gnuplot or OpenGL specific code.

Finally, I think that there are font handling problems that affect
Fedora Linux systems specifically.  So, it would be helpful if
someone ran the attached script on other distributions and compared
the results with the PS file.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/38300a56/attachment-0001.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_tex.m
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/38300a56/attachment-0001.ksh 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_tex.ps
Type: application/postscript
Size: 41489 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/38300a56/attachment-0001.ps 

From dasergatskov at gmail.com  Tue Sep  1 21:18:13 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 1 Sep 2009 21:18:13 -0500
Subject: Interpreter tex is broken
In-Reply-To: <4A9DD154.1020706@isl.stanford.edu>
References: <4A9DD154.1020706@isl.stanford.edu>
Message-ID: <892b16670909011918j652c9077xf1f339f459ba0ab8@mail.gmail.com>

On Tue, Sep 1, 2009 at 8:58 PM, Michael D
Godfrey<godfrey at isl.stanford.edu> wrote:

> Finally, I think that there are font handling problems that affect
> Fedora Linux systems specifically.? So, it would be helpful if
> someone ran the attached script on other distributions and compared
> the results with the PS file.

Perhaps I do not understand what is the problem, but it appears
to be working fine on octave-3.2.2 on x86_64 fedora 11
(rpm recompiled from rawhide/development tree)

>
> Michael
>
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 12441 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/85f3a3b2/attachment.png 

From godfrey at isl.stanford.edu  Tue Sep  1 22:43:09 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Tue, 01 Sep 2009 20:43:09 -0700
Subject: Interpreter tex is broken
In-Reply-To: <892b16670909011918j652c9077xf1f339f459ba0ab8@mail.gmail.com>
References: <4A9DD154.1020706@isl.stanford.edu>
	<892b16670909011918j652c9077xf1f339f459ba0ab8@mail.gmail.com>
Message-ID: <4A9DE9CD.7090005@isl.stanford.edu>

On 09/01/2009 07:18 PM, Dmitri A. Sergatskov wrote:
> Perhaps I do not understand what is the problem, but it appears
> to be working fine on octave-3.2.2 on x86_64 fedora 11
> (rpm recompiled from rawhide/development tree)
>
>    
And, I just figured out why it works for you:
You likely have the following fonts installed:

> yum install xorg-x11-fonts-100dpi.noarch xorg-x11-fonts-75dpi.noarch

I just installed these 2 fonts and now usage without backend("fltk");
is OK.  Somewhere, it should be recorded that these fonts are required.
And, whoever builds the rpm for Fedora should include them in the
dependencies.

Now, the not so good news:  with backend("fltk") selected,   The text is
not converted.  And, while preparing to show the result I discovered
that with backend("fltk") set,  print("backend.ps")  does not produce any
output.  So, I cannot show the result.   But, running the attached script
will do it, I think.  Again, your system may be smarter than mine.

So, please change the report about when backend("fltk") is not set to only
a documentation and dependency problem.

The fltk problems are not unexpected since this is not yet a supported
feature.  I should add that it does a lot of things very nicely, and now 
that
displaying text  mainly works, it is getting close to real use.

Michael



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/0ea95296/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: man_test.m
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/0ea95296/attachment.ksh 

From dasergatskov at gmail.com  Tue Sep  1 23:08:08 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 1 Sep 2009 23:08:08 -0500
Subject: Interpreter tex is broken
In-Reply-To: <4A9DE9CD.7090005@isl.stanford.edu>
References: <4A9DD154.1020706@isl.stanford.edu>
	<892b16670909011918j652c9077xf1f339f459ba0ab8@mail.gmail.com>
	<4A9DE9CD.7090005@isl.stanford.edu>
Message-ID: <892b16670909012108n1c25f505g954427eb1f6c64a7@mail.gmail.com>

On Tue, Sep 1, 2009 at 10:43 PM, Michael D
Godfrey<godfrey at isl.stanford.edu> wrote:
> On 09/01/2009 07:18 PM, Dmitri A. Sergatskov wrote:
>
> Perhaps I do not understand what is the problem, but it appears
> to be working fine on octave-3.2.2 on x86_64 fedora 11
> (rpm recompiled from rawhide/development tree)
>
>
>
> And, I just figured out why it works for you:
> You likely have the following fonts installed:
>
> yum install xorg-x11-fonts-100dpi.noarch xorg-x11-fonts-75dpi.noarch
>

Yes. And I think this is also issue with the change that set default font
to "" (i.e. empty). And with X11 gnuplot terminal (I guess it picks up first
available font and that happens not having symbols available).
If you used wxt termina (e.g. by starting octave as
GNUTERM=wxt octave
) it would still display the required symbols (see attached).

As for making fonts a dependence of octave rpm -- this is
up to the packager how she would like to handle the situation.
In my opinion the solution would be to set the default font to the one
that present in the system already.

I do not know anything about fltk. In fact running
octave:1> backend ("fltk")
octave:2> man_test

resulted in

octave:3> error: octave_base_value::convert_to_str_internal (): wrong
type argument `struct'
warning: opengl_renderer: cannot render object of type `text'
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault


> Michael
>

Sincerely,

Dmitri.
--

From jwe at octave.org  Tue Sep  1 23:14:14 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 00:14:14 -0400
Subject: Interpreter tex is broken
In-Reply-To: <892b16670909012108n1c25f505g954427eb1f6c64a7@mail.gmail.com>
References: <4A9DD154.1020706@isl.stanford.edu>
	<892b16670909011918j652c9077xf1f339f459ba0ab8@mail.gmail.com>
	<4A9DE9CD.7090005@isl.stanford.edu>
	<892b16670909012108n1c25f505g954427eb1f6c64a7@mail.gmail.com>
Message-ID: <19101.61718.666414.924675@segfault.lan>

On  1-Sep-2009, Dmitri A. Sergatskov wrote:

| I do not know anything about fltk. In fact running
| octave:1> backend ("fltk")
| octave:2> man_test
| 
| resulted in
| 
| octave:3> error: octave_base_value::convert_to_str_internal (): wrong
| type argument `struct'
| warning: opengl_renderer: cannot render object of type `text'
| panic: Segmentation fault -- stopping myself...
| attempting to save variables to `octave-core'...
| save to `octave-core' complete
| Segmentation fault

What version did you try this with?  The text support for the fltk
backend was added after 3.2.0, and as a new feature, isn't something
that will appear in any 3.2.x release.

jwe


From dasergatskov at gmail.com  Tue Sep  1 23:15:52 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 1 Sep 2009 23:15:52 -0500
Subject: Interpreter tex is broken
In-Reply-To: <19101.61718.666414.924675@segfault.lan>
References: <4A9DD154.1020706@isl.stanford.edu>
	<892b16670909011918j652c9077xf1f339f459ba0ab8@mail.gmail.com>
	<4A9DE9CD.7090005@isl.stanford.edu>
	<892b16670909012108n1c25f505g954427eb1f6c64a7@mail.gmail.com>
	<19101.61718.666414.924675@segfault.lan>
Message-ID: <892b16670909012115i10196677v89e39b84ce4a863e@mail.gmail.com>

On Tue, Sep 1, 2009 at 11:14 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?1-Sep-2009, Dmitri A. Sergatskov wrote:
>
> | I do not know anything about fltk. In fact running
> | octave:1> backend ("fltk")
> | octave:2> man_test
> |
> | resulted in
> |
> | octave:3> error: octave_base_value::convert_to_str_internal (): wrong
> | type argument `struct'
> | warning: opengl_renderer: cannot render object of type `text'
> | panic: Segmentation fault -- stopping myself...
> | attempting to save variables to `octave-core'...
> | save to `octave-core' complete
> | Segmentation fault
>
> What version did you try this with? ?The text support for the fltk
> backend was added after 3.2.0, and as a new feature, isn't something
> that will appear in any 3.2.x release.

OK.
I tried with 3.2.2 and 3.2.3rc2.

>
> jwe
>
>

Dmitri.
--


From rob at utk.edu  Tue Sep  1 23:16:38 2009
From: rob at utk.edu (Rob Mahurin)
Date: Wed, 2 Sep 2009 00:16:38 -0400
Subject: make check crashes in data.cc on OSX 10.5.8 PPC
In-Reply-To: <19101.35596.456023.939880@segfault.lan>
References: <4A9CDCD6.6010100@math.uni-giessen.de>
	<19101.35596.456023.939880@segfault.lan>
Message-ID: <FE343FB6-DE17-4D06-A76D-A1EA1A01F8A1@utk.edu>

On Sep 1, 2009, at 4:58 PM, John W. Eaton wrote:
> | while building octave 3.2.2 I experienced a crash during make check.
> |
> | The problem seems limited to PPC, as I had no problems building  
> on Intel.
> |
> | If I can do anything further, please let me know!
>
> I can't duplicate this problem on my system (not OS X, or PPC).
> Perhaps someone else who has access to a system like yours can?
> Otherwise, I think you will need to do some debugging to find the
> cause of the crash and fix it.

I also see this on PPC Mac (running 10.4.11).  I posted a gcc  
backtrace at

http://www.nabble.com/Re%3A-3.2.3-RC1-p25124047.html

Rob

-- 
Rob Mahurin
University of Manitoba, Dept. of Physics & Astronomy
at:	Oak Ridge National Laboratory	865 207 2594
	Oak Ridge, Tennessee		rob at utk.edu


From dasergatskov at gmail.com  Tue Sep  1 23:17:17 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 1 Sep 2009 23:17:17 -0500
Subject: Interpreter tex is broken
In-Reply-To: <892b16670909012108n1c25f505g954427eb1f6c64a7@mail.gmail.com>
References: <4A9DD154.1020706@isl.stanford.edu>
	<892b16670909011918j652c9077xf1f339f459ba0ab8@mail.gmail.com>
	<4A9DE9CD.7090005@isl.stanford.edu>
	<892b16670909012108n1c25f505g954427eb1f6c64a7@mail.gmail.com>
Message-ID: <892b16670909012117s547948f7p46eb87b262f6e8be@mail.gmail.com>

On Tue, Sep 1, 2009 at 11:08 PM, Dmitri A.
Sergatskov<dasergatskov at gmail.com> wrote>
> GNUTERM=wxt octave
> ) it would still display the required symbols (see attached).

Now it is really attached.

Dmitri.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-wxt.png
Type: image/png
Size: 51631 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090901/92591790/attachment-0001.png 

From marco_atzeri at yahoo.it  Wed Sep  2 04:49:04 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Wed, 2 Sep 2009 09:49:04 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <647710.15208.qm@web25505.mail.ukl.yahoo.com>
Message-ID: <586357.33142.qm@web25506.mail.ukl.yahoo.com>

--- Mar 1/9/09, Marco Atzeri <marco_atzeri at yahoo.it> ha scritto:

> 
> Hi Jaroslav,
> it seems a variant of 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2
> 
> with any -O flag
> 
>  (arg(z1)-arg(z2)) = -3.06287e-17
> 
> but adding -ffloat-store flag
> 
>  (arg(z1)-arg(z2)) = 0
> 
> 
> octave:1> 1+i < 1+i
> ans = 0
> octave:2> 1+i > 1+i
> ans = 0
> 
> > regards
> > 
> > -- 
> > RNDr.. Jaroslav Hajek
> 
> Thanks
> Marco

Jaroslav,

is it possible, eventually only for cygwin,
to implement this workaround , storing the arg(z1) in 
a temporary variable ? 

#include <iostream>
#include "oct-cmplx.h"

int main ()
{
  Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
  long double zt;
  std::cout << (arg(z1)) << '\n';
  std::cout << (arg(z2)) << '\n';
  std::cout << (arg(z1)<arg(z2)) << '\n';
  std::cout << (arg(z1)-arg(z2)) << '\n';
  zt = arg(z1);
  std::cout << (zt<arg(z2)) << '\n';
  std::cout << (zt-arg(z2)) << '\n';
}


0.785398
0.785398
1
-3.06287e-17
0
0

I am reluctant to use -ffloat-store as the solution for the cygwin release

Regards
Marco






      



From highegg at gmail.com  Wed Sep  2 04:52:24 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 2 Sep 2009 11:52:24 +0200
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <586357.33142.qm@web25506.mail.ukl.yahoo.com>
References: <647710.15208.qm@web25505.mail.ukl.yahoo.com>
	<586357.33142.qm@web25506.mail.ukl.yahoo.com>
Message-ID: <69d8d540909020252p2cd3d573ga722d6a2068f4f0b@mail.gmail.com>

On Wed, Sep 2, 2009 at 11:49 AM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
> --- Mar 1/9/09, Marco Atzeri <marco_atzeri at yahoo.it> ha scritto:
>
>>
>> Hi Jaroslav,
>> it seems a variant of
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2
>>
>> with any -O flag
>>
>> ?(arg(z1)-arg(z2)) = -3.06287e-17
>>
>> but adding -ffloat-store flag
>>
>> ?(arg(z1)-arg(z2)) = 0
>>
>>
>> octave:1> 1+i < 1+i
>> ans = 0
>> octave:2> 1+i > 1+i
>> ans = 0
>>
>> > regards
>> >
>> > --
>> > RNDr.. Jaroslav Hajek
>>
>> Thanks
>> Marco
>
> Jaroslav,
>
> is it possible, eventually only for cygwin,
> to implement this workaround , storing the arg(z1) in
> a temporary variable ?
>

I will eventually do that unless I can come up with something better.

> #include <iostream>
> #include "oct-cmplx.h"
>
> int main ()
> {
> ?Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
> ?long double zt;
> ?std::cout << (arg(z1)) << '\n';
> ?std::cout << (arg(z2)) << '\n';
> ?std::cout << (arg(z1)<arg(z2)) << '\n';
> ?std::cout << (arg(z1)-arg(z2)) << '\n';
> ?zt = arg(z1);
> ?std::cout << (zt<arg(z2)) << '\n';
> ?std::cout << (zt-arg(z2)) << '\n';
> }
>
>
> 0.785398
> 0.785398
> 1
> -3.06287e-17
> 0
> 0
>
> I am reluctant to use -ffloat-store as the solution for the cygwin release
>

Yes, that would not be a good idea.

-- 
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 Sep  2 05:28:42 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 06:28:42 -0400
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <69d8d540909020252p2cd3d573ga722d6a2068f4f0b@mail.gmail.com>
References: <647710.15208.qm@web25505.mail.ukl.yahoo.com>
	<586357.33142.qm@web25506.mail.ukl.yahoo.com>
	<69d8d540909020252p2cd3d573ga722d6a2068f4f0b@mail.gmail.com>
Message-ID: <19102.18650.827177.592367@segfault.lan>

On  2-Sep-2009, Jaroslav Hajek wrote:

| On Wed, Sep 2, 2009 at 11:49 AM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
| >
| > is it possible, eventually only for cygwin,
| > to implement this workaround , storing the arg(z1) in
| > a temporary variable ?
| >
| 
| I will eventually do that unless I can come up with something better.
| 
| > #include <iostream>
| > #include "oct-cmplx.h"
| >
| > int main ()
| > {
| > ?Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
| > ?long double zt;
| > ?std::cout << (arg(z1)) << '\n';
| > ?std::cout << (arg(z2)) << '\n';
| > ?std::cout << (arg(z1)<arg(z2)) << '\n';
| > ?std::cout << (arg(z1)-arg(z2)) << '\n';
| > ?zt = arg(z1);
| > ?std::cout << (zt<arg(z2)) << '\n';
| > ?std::cout << (zt-arg(z2)) << '\n';
| > }

Why long double?  I expect that is not the best thing to do for
portability.  What about using volatile for storing the values to be
compared?  That should be the equivalent of using -ffloat-store for
specific variables.  BTW, reading the GCC bug report that was
mentined earlier, it seems that -ffloat-store may not be consistently
implemented in GCC, so you might see problems even if you use
-ffloat-store.

jwe


From marco_atzeri at yahoo.it  Wed Sep  2 06:28:43 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Wed, 2 Sep 2009 11:28:43 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <19102.18650.827177.592367@segfault.lan>
Message-ID: <542632.93794.qm@web25507.mail.ukl.yahoo.com>

--- Mer 2/9/09, John W. Eaton <jwe at octave.org> ha scritto:

> Da: John W. Eaton <jwe at octave.org>
> Oggetto: Re: R: quadgk test fault or comparing complex
> A: "Jaroslav Hajek" <highegg at gmail.com>
> Cc: "Marco Atzeri" <marco_atzeri at yahoo.it>, bug-octave at octave.org
> Data: Mercoled? 2 settembre 2009, 12:28
> On? 2-Sep-2009, Jaroslav Hajek
> wrote:
> 
> | On Wed, Sep 2, 2009 at 11:49 AM, Marco Atzeri<marco_atzeri at yahoo.it>
> wrote:
> | >
> | > is it possible, eventually only for cygwin,
> | > to implement this workaround , storing the arg(z1)
> in
> | > a temporary variable ?
> | >
> | 
> | I will eventually do that unless I can come up with
> something better.
> | 
> | > #include <iostream>
> | > #include "oct-cmplx.h"
> | >
> | > int main ()
> | > {
> | > ?Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
> | > ?long double zt;
> | > ?std::cout << (arg(z1)) << '\n';
> | > ?std::cout << (arg(z2)) << '\n';
> | > ?std::cout << (arg(z1)<arg(z2)) <<
> '\n';
> | > ?std::cout << (arg(z1)-arg(z2)) <<
> '\n';
> | > ?zt = arg(z1);
> | > ?std::cout << (zt<arg(z2)) << '\n';
> | > ?std::cout << (zt-arg(z2)) << '\n';
> | > }
> 
> Why long double?? I expect that is not the best thing
> to do for
> portability.? What about using volatile for storing
> the values to be
> compared?? That should be the equivalent of using
> -ffloat-store for
> specific variables.? BTW, reading the GCC bug report
> that was
> mentined earlier, it seems that -ffloat-store may not be
> consistently
> implemented in GCC, so you might see problems even if you
> use
> -ffloat-store.
> 
> jwe
> 

Hi John,
just because it works on my test.
Making further experiment, I found that  

double works if 2 variables are used

**** ************************
#include <iostream>
#include "oct-cmplx.h"

int main ()
{
  Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
  double zt1, zt2;
  std::cout << (arg(z1)) << '\n';
  std::cout << (arg(z2)) << '\n';
  std::cout << (arg(z1)<arg(z2)) << '\n';
  std::cout << (arg(z1)-arg(z2)) << '\n';
  zt1 = arg(z1);
  zt2 = arg(z2);
  std::cout << (zt1<zt2) << '\n';
  std::cout << (zt1-zt2) << '\n';
}
***************************

0.785398
0.785398
1
-3.06287e-17
0
0

using only one variable is not enough. 

Volatile has no influence in the outcome.

*****************************************
#include <iostream>
#include "oct-cmplx.h"

int main ()
{
  Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
  volatile double zt;
  std::cout << (arg(z1)) << '\n';
  std::cout << (arg(z2)) << '\n';
  std::cout << (arg(z1)<arg(z2)) << '\n';
  std::cout << (arg(z1)-arg(z2)) << '\n';
  zt = arg(z1);
  std::cout << (zt<arg(z2)) << '\n';
  std::cout << (zt-arg(z2)) << '\n';
}
***********************************

0.785398
0.785398
1
-3.06287e-17
1
-3.06287e-17


I agree that -ffloat-store is a workaround only for this
issue, so it is not my preferred solution and I looking
for alternatives.


Marco 



      



From jwe at octave.org  Wed Sep  2 06:34:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 07:34:32 -0400
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <542632.93794.qm@web25507.mail.ukl.yahoo.com>
References: <19102.18650.827177.592367@segfault.lan>
	<542632.93794.qm@web25507.mail.ukl.yahoo.com>
Message-ID: <19102.22600.163757.131920@segfault.lan>

On  2-Sep-2009, Marco Atzeri wrote:

| double works if 2 variables are used
| 
| **** ************************
| #include <iostream>
| #include "oct-cmplx.h"
| 
| int main ()
| {
|   Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
|   double zt1, zt2;
|   std::cout << (arg(z1)) << '\n';
|   std::cout << (arg(z2)) << '\n';
|   std::cout << (arg(z1)<arg(z2)) << '\n';
|   std::cout << (arg(z1)-arg(z2)) << '\n';
|   zt1 = arg(z1);
|   zt2 = arg(z2);
|   std::cout << (zt1<zt2) << '\n';
|   std::cout << (zt1-zt2) << '\n';
| }
| ***************************
| 
| 0.785398
| 0.785398
| 1
| -3.06287e-17
| 0
| 0

I suspect that the result might change depending on the level of
optimization.  What compiler options are you using?

| using only one variable is not enough. 
| 
| Volatile has no influence in the outcome.

I was assuming that you would declare "volatile double" temporary
variables for both intermediate results (so as above, but "volatile
double" for both zt1 and zt2.  Then the compiler should not be allowed
to leave either of those values in extended precision registers,
regardless of the level of optimization.

jwe

From highegg at gmail.com  Wed Sep  2 07:28:43 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 2 Sep 2009 14:28:43 +0200
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <19102.22600.163757.131920@segfault.lan>
References: <19102.18650.827177.592367@segfault.lan>
	<542632.93794.qm@web25507.mail.ukl.yahoo.com>
	<19102.22600.163757.131920@segfault.lan>
Message-ID: <69d8d540909020528l1c925c27r1d7bb78c09ad64c5@mail.gmail.com>

On Wed, Sep 2, 2009 at 1:34 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?2-Sep-2009, Marco Atzeri wrote:
>
> | double works if 2 variables are used
> |
> | **** ************************
> | #include <iostream>
> | #include "oct-cmplx.h"
> |
> | int main ()
> | {
> | ? Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
> | ? double zt1, zt2;
> | ? std::cout << (arg(z1)) << '\n';
> | ? std::cout << (arg(z2)) << '\n';
> | ? std::cout << (arg(z1)<arg(z2)) << '\n';
> | ? std::cout << (arg(z1)-arg(z2)) << '\n';
> | ? zt1 = arg(z1);
> | ? zt2 = arg(z2);
> | ? std::cout << (zt1<zt2) << '\n';
> | ? std::cout << (zt1-zt2) << '\n';
> | }
> | ***************************
> |
> | 0.785398
> | 0.785398
> | 1
> | -3.06287e-17
> | 0
> | 0
>
> I suspect that the result might change depending on the level of
> optimization. ?What compiler options are you using?
>
> | using only one variable is not enough.
> |
> | Volatile has no influence in the outcome.
>
> I was assuming that you would declare "volatile double" temporary
> variables for both intermediate results (so as above, but "volatile
> double" for both zt1 and zt2. ?Then the compiler should not be allowed
> to leave either of those values in extended precision registers,
> regardless of the level of optimization.
>
> jwe
>

I committed this change:
http://hg.savannah.gnu.org/hgweb/octave/rev/8bea4e89326f

FLOAT_TRUNCATE is defined in config.h, either empty or equal to
"volatile". This can be specified using the --enable-float-truncate
option. By default, it is disabled - it's unneeded for machines using
SSE math (essentially all 64-bit machines), and a lot of the 32-bit
ones if compiling with -msse or similar.

It would be nice to have a test attempting to set it automatically if
it detects compilation for the x87, but I'm not sure how such a test
should work. One relatively ugly option is to let gcc emit assembler
(via -S) for some simple code and check for the x87 instructions in
it.

Maybe some of the other occurences of "volatile" inside liboctave can
also be replaced by FLOAT_TRUNCATE.

regards

-- 
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  Wed Sep  2 10:52:18 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Wed, 2 Sep 2009 15:52:18 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <69d8d540909020528l1c925c27r1d7bb78c09ad64c5@mail.gmail.com>
Message-ID: <240130.28478.qm@web25507.mail.ukl.yahoo.com>

--- Mer 2/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:

> Da: Jaroslav Hajek <highegg at gmail.com>
> Oggetto: Re: R: quadgk test fault or comparing complex
> A: "John W. Eaton" <jwe at octave.org>
> Cc: "Marco Atzeri" <marco_atzeri at yahoo.it>, bug-octave at octave.org
> Data: Mercoled? 2 settembre 2009, 14:28
> On Wed, Sep 2, 2009 at 1:34 PM, John
> W. Eaton<jwe at octave.org>
> wrote:
> > On ?2-Sep-2009, Marco Atzeri wrote:
> >
> > | double works if 2 variables are used
> > |
> > | **** ************************
> > | #include <iostream>
> > | #include "oct-cmplx.h"
> > |
> > | int main ()
> > | {
> > | ? Complex z1 (1.0, 1..0), z2 (1.0, 1.0);
> > | ? double zt1, zt2;
> > | ? std::cout << (arg(z1)) << '\n';
> > | ? std::cout << (arg(z2)) << '\n';
> > | ? std::cout << (arg(z1)<arg(z2)) <<
> '\n';
> > | ? std::cout << (arg(z1)-arg(z2)) <<
> '\n';
> > | ? zt1 = arg(z1);
> > | ? zt2 = arg(z2);
> > | ? std::cout << (zt1<zt2) << '\n';
> > | ? std::cout << (zt1-zt2) << '\n';
> > | }
> > | ***************************
> > |
> > | 0.785398
> > | 0.785398
> > | 1
> > | -3.06287e-17
> > | 0
> > | 0
> >
> > I suspect that the result might change depending on
> the level of
> > optimization. ?What compiler options are you using?
> >
> > | using only one variable is not enough.
> > |
> > | Volatile has no influence in the outcome.
> >
> > I was assuming that you would declare "volatile
> double" temporary
> > variables for both intermediate results (so as above,
> but "volatile
> > double" for both zt1 and zt2. ?Then the compiler
> should not be allowed
> > to leave either of those values in extended precision
> registers,
> > regardless of the level of optimization.
> >
> > jwe
> >
> 
> I committed this change:
> http://hg.savannah.gnu.org/hgweb/octave/rev/8bea4e89326f
> 
> FLOAT_TRUNCATE is defined in config.h, either empty or
> equal to
> "volatile". This can be specified using the
> --enable-float-truncate
> option. By default, it is disabled - it's unneeded for
> machines using
> SSE math (essentially all 64-bit machines), and a lot of
> the 32-bit
> ones if compiling with -msse or similar.
> 
> It would be nice to have a test attempting to set it
> automatically if
> it detects compilation for the x87, but I'm not sure how
> such a test
> should work.. One relatively ugly option is to let gcc emit
> assembler
> (via -S) for some simple code and check for the x87
> instructions in
> it.
> 
> Maybe some of the other occurences of "volatile" inside
> liboctave can
> also be replaced by FLOAT_TRUNCATE.

grep TRUNCA config.h 
#define FLOAT_TRUNCATE volatile

but it seems not effective

octave:1> 1+i < 1+1
ans =  1
octave:2> 1+i >  1+1

> 
> regards
> 
> -- 
> RNDr. Jaroslav Hajek

regards
Marco



      



From Thomas.Treichl at gmx.net  Wed Sep  2 13:22:25 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Wed, 02 Sep 2009 20:22:25 +0200
Subject: make check crashes in data.cc on OSX 10.5.8 PPC
In-Reply-To: <FE343FB6-DE17-4D06-A76D-A1EA1A01F8A1@utk.edu>
References: <4A9CDCD6.6010100@math.uni-giessen.de>	<19101.35596.456023.939880@segfault.lan>
	<FE343FB6-DE17-4D06-A76D-A1EA1A01F8A1@utk.edu>
Message-ID: <4A9EB7E1.4010000@gmx.net>

Rob Mahurin schrieb:
> On Sep 1, 2009, at 4:58 PM, John W. Eaton wrote:
>> | while building octave 3.2.2 I experienced a crash during make check.
>> |
>> | The problem seems limited to PPC, as I had no problems building  
>> on Intel.
>> |
>> | If I can do anything further, please let me know!
>>
>> I can't duplicate this problem on my system (not OS X, or PPC).
>> Perhaps someone else who has access to a system like yours can?
>> Otherwise, I think you will need to do some debugging to find the
>> cause of the crash and fix it.
> 
> I also see this on PPC Mac (running 10.4.11).  I posted a gcc  
> backtrace at
> 
> http://www.nabble.com/Re%3A-3.2.3-RC1-p25124047.html
> 
> Rob

I thinkt his has never been solved:

http://www-old.cae.wisc.edu/pipermail/bug-octave/2008-August/006603.html

   Thomas

From Thomas.Treichl at gmx.net  Wed Sep  2 13:52:14 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Wed, 02 Sep 2009 20:52:14 +0200
Subject: Subject: mex broken on OS-X Snow Leopard. Current .dmg probably
	loses	on all Mac Intel.
In-Reply-To: <AEC1D2B3-D7B3-444E-A52D-1A1425353FEB@verizon.net>
References: <AEC1D2B3-D7B3-444E-A52D-1A1425353FEB@verizon.net>
Message-ID: <4A9EBEDE.3030402@gmx.net>

Hi Richard,

these are bad news - but thanks for the report.

Richard Greenblatt schrieb:
> Bug report for Octave 3.2.2 configured for i386-apple-darwin8.11.1
> 
> Description:  mex broken
> -----------
> 
> octave-3.2.2:21> mex 'segmentImgOpt.cpp'
> ld: warning: in /Applications/Octave.app/Contents/Resources/bin/ 
> octave-3.2.2, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> octave-3.2.2/liboctinterp.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> octave-3.2.2/liboctave.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> octave-3.2.2/libcruft.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> libfftw3.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> libfftw3f.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> libreadline.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> libhdf5.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/ 
> libz.dylib, file is not of required architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/gcc- 
> lib/i386-apple-darwin8.11.1/4.0.3/libf95.a, file is not of required  
> architecture
> ld: warning: in /Applications/Octave.app/Contents/Resources/lib/gcc- 
> lib/i386-apple-darwin8.11.1/4.0.3/libgcc.a, file is not of required  
> architecture

Ok, I would say that all these warnings can be neglected on a 10.6 system 
because you are already running Octave.app, for me this means that 10.6 can 
still handle i686 32bit binaries (even if 64bit binaries would be preferred).

> Undefined symbols:
>    "_mxArrayToString", referenced from:
>        _mexFunction in segmentImgOpt.o
>    "_mxGetDimensions", referenced from:
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
>    "_mxIsChar", referenced from:
>        _mexFunction in segmentImgOpt.o
>    "_mxIsComplex", referenced from:
>        _mexFunction in segmentImgOpt.o
>    "_mexErrMsgTxt", referenced from:
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
>    "_mxCreateDoubleMatrix", referenced from:
>        _mexFunction in segmentImgOpt.o
>    "_mxGetPr", referenced from:
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
>        _mexFunction in segmentImgOpt.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> octave-3.2.2:22>

I can't see these problems on my 10.4 system and that's the big problem at all 
(this means that I cannot help fixing this): I have not made my decision in 
either invest money in a Mac OS X 10.6 system in the near future or to change my 
working machine into another platform at all. I even don't know how long I will 
prepare Octave.app binaries in the future for 10.4 and 10.5 - but what I can say 
is that if there are Octave.app versions beyond 3.2.x then I think they are not 
made from me anymore.

As you say, it seems that it is necessary to recompile all the binaries, make 
tests and so on, now we need to find someone who makes this job.

Best regards

   Thomas

>     mex associated files evidently not compiled correctly for Snow  
> Leopard
> 
> Repeat-By:
> ---------
> 
>     just try to use mex
> 
> Fix:
> ---
> 
>     needs to be recompiled specific to target machine.
>     versions for PPC and Intel may need to be forked for .dmg file  
> purposes
>         unless octave can deal with fat binaries, etc.


From kelk1 at hotmail.com  Wed Sep  2 14:52:33 2009
From: kelk1 at hotmail.com (Eric)
Date: Wed, 2 Sep 2009 19:52:33 +0000 (UTC)
Subject: auto sets axis scale too large
References: <loom.20090824T223645-136@post.gmane.org>
	<19093.59128.237407.234177@segfault.lan>
Message-ID: <loom.20090902T215007-854@post.gmane.org>

John W. Eaton <jwe <at> octave.org> writes:
> 
> On 24-Aug-2009, Eric wrote:
> 
> | octave:1> a=0.001 : .001 : 0.017
> | octave:2> plot(a)
> | 
> | - On FC7, octave-2.9.9-2.fc7, gnuplot-4.0.0-19.fc7, the x axis is nicely set
> | from 0 to 18 and the y axis from 0 to 0.018.
> | 
> | - On FC11, octave-3.0.5-1.fc11.x86_64, gnuplot-4.2.4-6.fc11.x86_64, it seems
> | that axis("auto") is forced to axis("tight").
> | 
> | - On Mandriva cooker, octave-3.2.2-1mdv2010.0, gnuplot-4.2.5-1mdv2010.0, 
> | the x axis is set from 0 to 20 and the y axis from 0 to 0.05. This is far
> | too large.
> 
> On my system with Octave 3.2.2 I see the y limit going from 0 to 0.02,
> which doesn't seem too bad to me.
> 

Thank you for answering.

That is weird that we get different results with the same octave version, don't
you think?

> | This is quite an annoying regression.
> 
> Saying that things are "quite annoying" is not a great way to motivate
> people to help you out.
> 

Well I did not say it was very annoying, but the important word is regression, 
which everyone would like to avoid.

> | I tried to find similar reports but could not find any. 
> | 
> | Is there a way to control how tight auto-scale is?
> 
> Octave 2.9.9 left the axis scaling to gnuplot.  With the new graphics
> system, Octave computes the extents of the axes, and sets them
> explicitly.  If you want to improve how that works, then I think the
> functions to look at are
> 
>   axes::properties::get_axis_limits (double xmin, double xmax,
>   axes::properties::calc_ticks_and_lims (array_property& lims,
> 
> in src/graphics.cc.
> 
If I set ticint = 10 in axes::properties::calc_tick_sep (src/graphics.cc), I 
seem to have much nicer scales.

This parameter definitely controls the tightness of the graphs. Maybe it could 
be passed as parameter instead of being hard coded like that (with no 
documentation)?

--
Eric



From jwe at octave.org  Wed Sep  2 15:25:37 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 16:25:37 -0400
Subject: auto sets axis scale too large
In-Reply-To: <loom.20090902T215007-854@post.gmane.org>
References: <loom.20090824T223645-136@post.gmane.org>
	<19093.59128.237407.234177@segfault.lan>
	<loom.20090902T215007-854@post.gmane.org>
Message-ID: <19102.54465.753873.943023@segfault.lan>

On  2-Sep-2009, Eric wrote:

| If I set ticint = 10 in axes::properties::calc_tick_sep (src/graphics.cc), I 
| seem to have much nicer scales.
| 
| This parameter definitely controls the tightness of the graphs. Maybe it could 
| be passed as parameter instead of being hard coded like that (with no 
| documentation)?

I think this function was written quickly to get something working,
not as a complete and final solution to the problem of tick mark
placement.  So if there is a better way, please propose a patch.

jwe

From highegg at gmail.com  Wed Sep  2 23:36:52 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 3 Sep 2009 06:36:52 +0200
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <240130.28478.qm@web25507.mail.ukl.yahoo.com>
References: <69d8d540909020528l1c925c27r1d7bb78c09ad64c5@mail.gmail.com>
	<240130.28478.qm@web25507.mail.ukl.yahoo.com>
Message-ID: <69d8d540909022136k7825548wf56ba8dbfe836dd0@mail.gmail.com>

On Wed, Sep 2, 2009 at 5:52 PM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
> --- Mer 2/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:
>
>> Da: Jaroslav Hajek <highegg at gmail.com>
>> Oggetto: Re: R: quadgk test fault or comparing complex
>> A: "John W. Eaton" <jwe at octave.org>
>> Cc: "Marco Atzeri" <marco_atzeri at yahoo.it>, bug-octave at octave.org
>> Data: Mercoled? 2 settembre 2009, 14:28
>> On Wed, Sep 2, 2009 at 1:34 PM, John
>> W. Eaton<jwe at octave.org>
>> wrote:
>> > On ?2-Sep-2009, Marco Atzeri wrote:
>> >
>> > | double works if 2 variables are used
>> > |
>> > | **** ************************
>> > | #include <iostream>
>> > | #include "oct-cmplx.h"
>> > |
>> > | int main ()
>> > | {
>> > | ? Complex z1 (1.0, 1..0), z2 (1.0, 1.0);
>> > | ? double zt1, zt2;
>> > | ? std::cout << (arg(z1)) << '\n';
>> > | ? std::cout << (arg(z2)) << '\n';
>> > | ? std::cout << (arg(z1)<arg(z2)) <<
>> '\n';
>> > | ? std::cout << (arg(z1)-arg(z2)) <<
>> '\n';
>> > | ? zt1 = arg(z1);
>> > | ? zt2 = arg(z2);
>> > | ? std::cout << (zt1<zt2) << '\n';
>> > | ? std::cout << (zt1-zt2) << '\n';
>> > | }
>> > | ***************************
>> > |
>> > | 0.785398
>> > | 0.785398
>> > | 1
>> > | -3.06287e-17
>> > | 0
>> > | 0
>> >
>> > I suspect that the result might change depending on
>> the level of
>> > optimization. ?What compiler options are you using?
>> >
>> > | using only one variable is not enough.
>> > |
>> > | Volatile has no influence in the outcome.
>> >
>> > I was assuming that you would declare "volatile
>> double" temporary
>> > variables for both intermediate results (so as above,
>> but "volatile
>> > double" for both zt1 and zt2. ?Then the compiler
>> should not be allowed
>> > to leave either of those values in extended precision
>> registers,
>> > regardless of the level of optimization.
>> >
>> > jwe
>> >
>>
>> I committed this change:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/8bea4e89326f
>>
>> FLOAT_TRUNCATE is defined in config.h, either empty or
>> equal to
>> "volatile". This can be specified using the
>> --enable-float-truncate
>> option. By default, it is disabled - it's unneeded for
>> machines using
>> SSE math (essentially all 64-bit machines), and a lot of
>> the 32-bit
>> ones if compiling with -msse or similar.
>>
>> It would be nice to have a test attempting to set it
>> automatically if
>> it detects compilation for the x87, but I'm not sure how
>> such a test
>> should work.. One relatively ugly option is to let gcc emit
>> assembler
>> (via -S) for some simple code and check for the x87
>> instructions in
>> it.
>>
>> Maybe some of the other occurences of "volatile" inside
>> liboctave can
>> also be replaced by FLOAT_TRUNCATE.
>
> grep TRUNCA config.h
> #define FLOAT_TRUNCATE volatile
>
> but it seems not effective
>
> octave:1> 1+i < 1+1
> ans = ?1
> octave:2> 1+i > ?1+1
>

Ugh. I thought volatile would always work... could you again try the
test program with #include "oct-cmplx.h"?
You'd either need to include config.h as well or define FLOAT_TRUNCATE
to volatile.
If volatile is really not enough, we'll need something more complicated.


-- 
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  Thu Sep  3 01:53:29 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Thu, 3 Sep 2009 06:53:29 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <69d8d540909022136k7825548wf56ba8dbfe836dd0@mail.gmail.com>
Message-ID: <259808.81796.qm@web25505.mail.ukl.yahoo.com>

--- Gio 3/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:

> 
> Ugh. I thought volatile would always work... could you
> again try the
> test program with #include "oct-cmplx.h"?
> You'd either need to include config.h as well or define
> FLOAT_TRUNCATE
> to volatile.
> If volatile is really not enough, we'll need something more
> complicated.
> 

> -- 
> RNDr. Jaroslav Hajek

Jaroslav,
the potential issue is caused as we are comparing

abs(a) with arb(b)
arg(a) with arg(b) 

and in cygwin we have that one value is truncated 
and the other no, for whatever reason.

Is it simpler to add that if
a=b the comparison for a<b (and a> b) is false ? 

for
std::cout << ((z1!=z2)&&(arg(z1)<arg(z2))) << '\n';

the outcome is 0



Marco


 



      



From highegg at gmail.com  Thu Sep  3 02:03:17 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 3 Sep 2009 09:03:17 +0200
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <259808.81796.qm@web25505.mail.ukl.yahoo.com>
References: <69d8d540909022136k7825548wf56ba8dbfe836dd0@mail.gmail.com>
	<259808.81796.qm@web25505.mail.ukl.yahoo.com>
Message-ID: <69d8d540909030003t454175d5m2bd9d4377ed6cb2a@mail.gmail.com>

On Thu, Sep 3, 2009 at 8:53 AM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
> --- Gio 3/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:
>
>>
>> Ugh. I thought volatile would always work... could you
>> again try the
>> test program with #include "oct-cmplx.h"?
>> You'd either need to include config.h as well or define
>> FLOAT_TRUNCATE
>> to volatile.
>> If volatile is really not enough, we'll need something more
>> complicated.
>>
>
>> --
>> RNDr. Jaroslav Hajek
>
> Jaroslav,
> the potential issue is caused as we are comparing
>
> abs(a) with arb(b)
> arg(a) with arg(b)
>
> and in cygwin we have that one value is truncated
> and the other no, for whatever reason.
>

I would rather discover the "whatever reason" than add random tweaks
until the issue (possibly temporarily) vanishes. IMHO, using a
volatile temporary should force truncation, because the compiler is
forced to store the value on the stack and rereading it afterwards.
I'd be very surprised if it didn't work so in cygwin. I have even
inspected the assembler generated on my machine (when
FLOAT_TRUNCATE=volatile) and it does so, even though it's not actually
needed.
Could you try this test?

test.cc:
#include <iostream>
#define FLOAT_TRUNCATE volatile
#include "oct-cmplx.h"

bool do_compare (const Complex& z1, const Complex& z2)
{
  return z1 < z2;
}

int main ()
{
 Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
 std::cout << do_compare (z1, z2) << '\n';
}

if this doesn't work (should give zero), the please also generate the
assembler (via g++ -O2 -S test.cc) and show it to me.

regards

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

From Alexander.Klein at math.uni-giessen.de  Thu Sep  3 02:46:37 2009
From: Alexander.Klein at math.uni-giessen.de (Alexander Klein)
Date: Thu, 3 Sep 2009 09:46:37 +0200
Subject: make check crashes in data.cc on OSX 10.5.8 PPC
In-Reply-To: <4A9EB7E1.4010000@gmx.net>
References: <4A9CDCD6.6010100@math.uni-giessen.de>	<19101.35596.456023.939880@segfault.lan>
	<FE343FB6-DE17-4D06-A76D-A1EA1A01F8A1@utk.edu>
	<4A9EB7E1.4010000@gmx.net>
Message-ID: <CE398C4D-C35D-49C0-B28C-DFFA381CA045@math.uni-giessen.de>

Hi,

I've tracked down the bug to some routine for console output, and it  
goes back to at least 3.0.3, only that the tests didn't happen to  
trigger it then.

It seems that any complex number with a real part of infinite  
magnitude (Inf+3i, -Inf+1i) crashes octave right after the '+' is  
displayed on screen.

Haven't had the time to do any more debugging yet.

Kind regards,

	Alex

-- 
Alexander Klein, Dipl.-Math.
Lehrstuhl f?r Numerische Mathematik
Heinrich-Buff-Ring 44
35392 Giessen



From andrew.borg.cardona at live.com  Wed Sep  2 02:31:26 2009
From: andrew.borg.cardona at live.com (Andrew Borg Cardona)
Date: Wed, 2 Sep 2009 09:31:26 +0200
Subject: Dbstatus misses breakpoints inside for loops
Message-ID: <2728d750909020031x662ad606i352db6e3bfc7d9ef@mail.gmail.com>

Bug report attached
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090902/603618d7/attachment.html 
-------------- next part --------------
Bug report for Octave 3.2.0 configured for i686-pc-mingw32

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

  * Dbstatus does not recognize breakpoints that are found inside for loops (and possibly
    other similar statements such as while). 

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

  * Create the following function:

    function testFunction
        for i=1:10
        i
        end
    endfunction

    Add a breakpoint on the 'i' (line 3)
    Execute the command dbstatus("testFunction")
    The breakpoint on line 3 will not be returned


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/octaveforge_mingw32/octave/octave-3.2.0 -I. -I./liboctave -I./src -I./libcruft/misc -I/octaveforge_mingw32/octave/octave-3.2.0 -I/octaveforge_mingw32/octave/octave-3.2.0/liboctave -I/octaveforge_mingw32/octave/octave-3.2.0/src -I/octaveforge_mingw32/octave/octave-3.2.0/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_STRFTIME=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.0_gcc-4.3.0\tools\notepad++\notepad++.exe
  EXEC_PATH = C:\Octave\3.2.0_gcc-4.3.0\MINGW32\bin;C:\Octave\3.2.0_gcc-4.3.0\MSYS\bin;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\3.2.0\site\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\3.2.0\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\HPQ\IAM\bin;C:\Program Files\QuickTime\QTSystem\;C:\MATLAB7\bin\win32;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static
  IMAGE_PATH = .;C:\Octave\3.2.0_gcc-4.3.0\share\octave\3.2.0\imagelib
  PAGER = C:\Octave\3.2.0_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:\Octave\3.2.0_gcc-4.3.0\bin\gnuplot.exe
# gnuplot_command_end = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = C:\Documents and Settings\andrew\.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = C:\Octave\3.2.0_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 = <no value or error in displaying it>
  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  Fri Sep  4 11:05:41 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 12:05:41 -0400
Subject: make check crashes in data.cc on OSX 10.5.8 PPC
In-Reply-To: <CE398C4D-C35D-49C0-B28C-DFFA381CA045@math.uni-giessen.de>
References: <4A9CDCD6.6010100@math.uni-giessen.de>
	<19101.35596.456023.939880@segfault.lan>
	<FE343FB6-DE17-4D06-A76D-A1EA1A01F8A1@utk.edu>
	<4A9EB7E1.4010000@gmx.net>
	<CE398C4D-C35D-49C0-B28C-DFFA381CA045@math.uni-giessen.de>
Message-ID: <19105.15061.392913.212547@segfault.lan>

On  3-Sep-2009, Alexander Klein wrote:

| I've tracked down the bug to some routine for console output, and it  
| goes back to at least 3.0.3, only that the tests didn't happen to  
| trigger it then.
| 
| It seems that any complex number with a real part of infinite  
| magnitude (Inf+3i, -Inf+1i) crashes octave right after the '+' is  
| displayed on screen.
| 
| Haven't had the time to do any more debugging yet.

Could you please try the latest Octave sources from the Mercurial
archive and see if this is still a problem?

Thanks,

jwe

From jwe at octave.org  Fri Sep  4 11:08:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 12:08:32 -0400
Subject: Dbstatus misses breakpoints inside for loops
In-Reply-To: <2728d750909020031x662ad606i352db6e3bfc7d9ef@mail.gmail.com>
References: <2728d750909020031x662ad606i352db6e3bfc7d9ef@mail.gmail.com>
Message-ID: <19105.15232.334195.136172@segfault.lan>

On  2-Sep-2009, Andrew Borg Cardona wrote:

| Bug report attached
| 
| ----------------------------------------------------------------------
| Bug report for Octave 3.2.0 configured for i686-pc-mingw32
| 
| Description:
| -----------
| 
|   * Dbstatus does not recognize breakpoints that are found inside for loops (and possibly
|     other similar statements such as while). 
| 
| Repeat-By:
| ---------
| 
|   * Create the following function:
| 
|     function testFunction
|         for i=1:10
|         i
|         end
|     endfunction
| 
|     Add a breakpoint on the 'i' (line 3)
|     Execute the command dbstatus("testFunction")
|     The breakpoint on line 3 will not be returned

This problem seems to be fixed in the current sources, and also
works for me with Octave 3.2.2.

jwe

From orion at cora.nwra.com  Fri Sep  4 11:19:43 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 04 Sep 2009 10:19:43 -0600
Subject: [OctDev] test_sparse.m fails on ppc64 build
In-Reply-To: <1252029711.16399.7.camel@sh-t400>
References: <loom.20090903T222522-569@post.gmane.org>
	<1252029711.16399.7.camel@sh-t400>
Message-ID: <4AA13E1F.2020209@cora.nwra.com>

On 09/03/2009 08:01 PM, S?ren Hauberg wrote:
> tor, 03 09 2009 kl. 20:27 +0000, skrev Orion Poplawski:
>> Running make check on octave 3.2.2 build in Fedora Rawhide fails in
>> test_sparse.m on ppc64.
>>
>> Fixed test scripts:
>>    test_args.m ............................................ PASS   26/26
>> .....
>>    test_sparse.m ..........................................panic: Segmentation
>> fault -- stopping myself...
>> make[2]: *** [check] Segmentation fault
>>
>>
>> Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=521142
>> Build log: http://koji.fedoraproject.org/koji/getfile?taskID=1653016&name=build.log
>>
>> Any ideas?  Any kind of test verbosity that can be turned on to help debug?
>
> You should report this to the Octave bug list (bug at octave.org). To get
> more details about the issue look in the 'test/fntests.log' file.

Sorry, should have checked the gmane groups closer.

Not much in fntests.log, ends with:

>>>>> processing test_sparse

gdb shows:

#0  0x00000400037fe490 in 
._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE15_M_insert_floatIdEES4_S4_RSt8ios_baseccT_ 
()
    from /usr/lib64/libstdc++.so.6
#1  0x00000400037fe78c in 
._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES4_RSt8ios_basecd 
() from /usr/lib64/libstdc++.so.6
#2  0x0000040003811f20 in ._ZNSo9_M_insertIdEERSoT_ ()
    from /usr/lib64/libstdc++.so.6
#3  0x000004000070d100 in operator<< (__f=<value optimized out>,
     this=<value optimized out>)
     at 
/usr/lib/gcc/ppc64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/ostream:210
#4  operator<< (__f=<value optimized out>, this=<value optimized out>)
     at pr-output.cc:228
#5  0x00000400007108bc in pr_any_float (fmt=0x400011e4838, os=..., d=0,
     fw=<value optimized out>) at pr-output.cc:1395
#6  0x0000040000711ff0 in pr_imag_float (fw=<value optimized out>,
     d=<value optimized out>, os=<value optimized out>) at pr-output.cc:1413
#7  pr_complex (fw=<value optimized out>, d=<value optimized out>,
     os=<value optimized out>) at pr-output.cc:1443
#8  0x00000400007137c8 in octave_print_internal (os=..., c=...) at 
pr-output.cc:1959
#9  0x00000400009bb364 in 
octave_base_sparse<SparseComplexMatrix>::print_raw (
     this=0x1012d1b8, os=..., pr_as_read_syntax=false) at 
ov-base-sparse.cc:314
#10 0x00000400009b711c in octave_base_sparse<SparseComplexMatrix>::print (
     this=<value optimized out>, os=<value optimized out>,
     pr_as_read_syntax=<value optimized out>) at ov-base-sparse.cc:257
#11 0x000004000070f19c in print (pr_as_read_syntax=<value optimized out>,
     os=<value optimized out>, this=<value optimized out>) at ov.h:950
#12 Fdisp (pr_as_read_syntax=<value optimized out>, os=<value optimized 
out>,
     this=<value optimized out>) at pr-output.cc:3298
#13 0x00000400008c9ff0 in octave_builtin::do_multi_index_op 
(this=0x101b3078,
     nargout=1, args=...) at ov-builtin.cc:107
#14 0x00000400008c981c in octave_builtin::subsref (this=0x101b3078, 
type=...,
     idx=..., nargout=1) at ov-builtin.cc:55
#15 0x00000400008cad24 in octave_builtin::subsref (this=<value optimized 
out>,
     type=<value optimized out>, idx=<value optimized out>) at 
ov-builtin.h:56
#16 0x0000040000866180 in octave_value::subsref (this=<value optimized out>,
     type=<value optimized out>, idx=<value optimized out>,
     nargout=<value optimized out>) at ov.cc:1059
#17 0x00000400009f19f0 in tree_index_expression::rvalue (
     this=<value optimized out>, nargout=1) at pt-idx.cc:387
#18 0x00000400009ed17c in tree_index_expression::rvalue1 (
     this=<value optimized out>, nargout=<value optimized out>) at 
pt-idx.cc:398
#19 0x00000400009ca92c in tree_simple_assignment::rvalue1 (this=0x10a2a9d0)
     at pt-assign.cc:201
#20 0x00000400009df218 in tree_evaluator::visit_statement (
     this=<value optimized out>, stmt=<value optimized out>) at 
pt-eval.cc:695
#21 0x0000040000a0dbc8 in tree_statement::accept (this=<value optimized 
out>,
     tw=<value optimized out>) at pt-stmt.cc:152
(gdb) up 4
#4  operator<< (__f=<value optimized out>, this=<value optimized out>)
     at pr-output.cc:228
228       os << pff.val;
Current language:  auto
The current source language is "auto; currently c++".
(gdb) list
223
224       std::ios::fmtflags oflags =
225         os.flags (static_cast<std::ios::fmtflags>
226                   (pff.f.fmt | pff.f.up | pff.f.sp));
227
228       os << pff.val;
229
230       os.flags (oflags);
231
232       return os;
(gdb) print pff.val
Cannot access memory at address 0x8
(gdb) up
#5  0x00000400007108bc in pr_any_float (fmt=0x400011e4838, os=..., d=0,
     fw=<value optimized out>) at pr-output.cc:1395
1395            os << pr_formatted_float (*fmt, d);
(gdb) print d
$3 = 0
(gdb) print fmt
$4 = (const float_format *) 0x400011e4838
(gdb) print *fmt
$5 = {fw = 2147483647, prec = -2147483648, fmt = 0, up = 0, sp = 0}


So here is looks like fmt has an address, but is un-initialized (fmt.fmt 
is null)


#9  0x00000400009bb364 in 
octave_base_sparse<SparseComplexMatrix>::print_raw (
     this=0x1012d1b8, os=..., pr_as_read_syntax=false) at 
ov-base-sparse.cc:314
314                   octave_print_internal (os, matrix.data(i), 
pr_as_read_syntax);
(gdb) print matrix.data(i)
$8 = (std::complex<double> &) @0x10c54e30: {_M_value = 1 + -1 * I}

Hope that helps.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

From orion at cora.nwra.com  Fri Sep  4 13:36:55 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 04 Sep 2009 12:36:55 -0600
Subject: [OctDev] test_sparse.m fails on ppc64 build
In-Reply-To: <4AA13E1F.2020209@cora.nwra.com>
References: <loom.20090903T222522-569@post.gmane.org>	<1252029711.16399.7.camel@sh-t400>
	<4AA13E1F.2020209@cora.nwra.com>
Message-ID: <4AA15E47.3000508@cora.nwra.com>

On 09/04/2009 10:19 AM, Orion Poplawski wrote:
> On 09/03/2009 08:01 PM, S?ren Hauberg wrote:
>> tor, 03 09 2009 kl. 20:27 +0000, skrev Orion Poplawski:
>>> Running make check on octave 3.2.2 build in Fedora Rawhide fails in
>>> test_sparse.m on ppc64.
>>>
>>> Fixed test scripts:
>>>     test_args.m ............................................ PASS   26/26
>>> .....
>>>     test_sparse.m ..........................................panic: Segmentation
>>> fault -- stopping myself...
>>> make[2]: *** [check] Segmentation fault

Okay, the problem seems to be in set_complex_format() in pr-output.cc:

   else if (inf_or_nan || int_only)
     {
       int digits = x_max > x_min ? x_max : x_min;
       i_fw = digits <= 0 ? 1 : digits;
       r_fw = i_fw + 1;
       if (inf_or_nan && i_fw < 3)
         {
           i_fw = 3;
           r_fw = 4;
         }
       rd = r_fw;
     }

This is getting called with (x_max=2147483647, x_min=0, r_x=2147483647,
     inf_or_nan=true, int_only=1, r_fw=@0xfffffff56ec, 
i_fw=@0xfffffff56e8) which yields digits = 2147483647, which is later 
used as the width (os.setw(fmt.f.fw)).  This borks the C++ library. 
Surely this isn't what you want to set digits to.

Similar code is present in other set_ functions in pr-output.cc.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

From dasergatskov at gmail.com  Fri Sep  4 14:52:53 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Fri, 4 Sep 2009 14:52:53 -0500
Subject: [OctDev] test_sparse.m fails on ppc64 build
In-Reply-To: <4AA15E47.3000508@cora.nwra.com>
References: <loom.20090903T222522-569@post.gmane.org>
	<1252029711.16399.7.camel@sh-t400> <4AA13E1F.2020209@cora.nwra.com>
	<4AA15E47.3000508@cora.nwra.com>
Message-ID: <892b16670909041252u4fedc2daqe6259ebe3956602d@mail.gmail.com>

Orion,

Do you have shell account on ppc64 computer?
If so can you compile the attached test program and report the results?

gfortran dlamchtst.f -L/usr/lib/atlas -llapack -lm -o dlamchtst

(dlamchtst.f is from lapack distribution. You can vary -L switch to link
to either atlas or lapack).

Sincerely,

Dmitri.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlamchtst.f
Type: application/octet-stream
Size: 1522 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090904/d0995cf5/attachment.obj 

From orion at cora.nwra.com  Fri Sep  4 15:04:40 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 04 Sep 2009 14:04:40 -0600
Subject: [OctDev] test_sparse.m fails on ppc64 build
In-Reply-To: <892b16670909041252u4fedc2daqe6259ebe3956602d@mail.gmail.com>
References: <loom.20090903T222522-569@post.gmane.org>	
	<1252029711.16399.7.camel@sh-t400>
	<4AA13E1F.2020209@cora.nwra.com>	 <4AA15E47.3000508@cora.nwra.com>
	<892b16670909041252u4fedc2daqe6259ebe3956602d@mail.gmail.com>
Message-ID: <4AA172D8.8050600@cora.nwra.com>

On 09/04/2009 01:52 PM, Dmitri A. Sergatskov wrote:
> Orion,
>
> Do you have shell account on ppc64 computer?
> If so can you compile the attached test program and report the results?
>
> gfortran dlamchtst.f -L/usr/lib/atlas -llapack -lm -o dlamchtst
>
> (dlamchtst.f is from lapack distribution. You can vary -L switch to link
> to either atlas or lapack).
>
> Sincerely,
>
> Dmitri.
> --

Without atlas:

$ ./dlamchtst
   Epsilon                      =   1.11022302462515654E-016
   Safe minimum                 =   2.22507385850720138E-308
   Base                         =    2.0000000000000000
   Precision                    =   2.22044604925031308E-016
   Number of digits in mantissa =    53.000000000000000
   Rounding mode                =    1.0000000000000000
   Minimum exponent             =   -1021.0000000000000
   Underflow threshold          =   2.22507385850720138E-308
   Largest exponent             =    1024.0000000000000
   Overflow threshold           =   1.79769313486231571E+308
   Reciprocal of safe minimum   =   4.49423283715578977E+307

With atlas:

$ ./dlamchtst
   Epsilon                      =   1.11022302462515654E-016
   Safe minimum                 =   2.22507385850720138E-308
   Base                         =    2.0000000000000000
   Precision                    =   2.22044604925031308E-016
   Number of digits in mantissa =    53.000000000000000
   Rounding mode                =    1.0000000000000000
   Minimum exponent             =   -1021.0000000000000
   Underflow threshold          =   2.22507385850720138E-308
   Largest exponent             =    1024.0000000000000
   Overflow threshold           =   1.79769313486231571E+308
   Reciprocal of safe minimum   =   4.49423283715578977E+307


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

From dasergatskov at gmail.com  Fri Sep  4 15:14:23 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Fri, 4 Sep 2009 15:14:23 -0500
Subject: [OctDev] test_sparse.m fails on ppc64 build
In-Reply-To: <4AA172D8.8050600@cora.nwra.com>
References: <loom.20090903T222522-569@post.gmane.org>
	<1252029711.16399.7.camel@sh-t400> <4AA13E1F.2020209@cora.nwra.com>
	<4AA15E47.3000508@cora.nwra.com>
	<892b16670909041252u4fedc2daqe6259ebe3956602d@mail.gmail.com>
	<4AA172D8.8050600@cora.nwra.com>
Message-ID: <892b16670909041314n2f098906m8aa06c8ab95956a9@mail.gmail.com>

On Fri, Sep 4, 2009 at 3:04 PM, Orion Poplawski<orion at cora.nwra.com> wrote:
> On 09/04/2009 01:52 PM, Dmitri A. Sergatskov wrote:
>>
>> Orion,
>>
>> Do you have shell account on ppc64 computer?
>> If so can you compile the attached test program and report the results?
>>
>> gfortran dlamchtst.f -L/usr/lib/atlas -llapack -lm -o dlamchtst
>>
>> (dlamchtst.f is from lapack distribution. You can vary -L switch to link
>> to either atlas or lapack).
>>
>> Sincerely,
>>
>> Dmitri.
>> --
>
> Without atlas:
>
> $ ./dlamchtst
> ?Epsilon ? ? ? ? ? ? ? ? ? ? ?= ? 1.11022302462515654E-016
> ?Safe minimum ? ? ? ? ? ? ? ? = ? 2.22507385850720138E-308
> ?Base ? ? ? ? ? ? ? ? ? ? ? ? = ? ?2.0000000000000000
> ?Precision ? ? ? ? ? ? ? ? ? ?= ? 2.22044604925031308E-016
> ?Number of digits in mantissa = ? ?53.000000000000000
> ?Rounding mode ? ? ? ? ? ? ? ?= ? ?1.0000000000000000
> ?Minimum exponent ? ? ? ? ? ? = ? -1021.0000000000000
> ?Underflow threshold ? ? ? ? ?= ? 2.22507385850720138E-308
> ?Largest exponent ? ? ? ? ? ? = ? ?1024.0000000000000
> ?Overflow threshold ? ? ? ? ? = ? 1.79769313486231571E+308
> ?Reciprocal of safe minimum ? = ? 4.49423283715578977E+307
>
> With atlas:
>
> $ ./dlamchtst
> ?Epsilon ? ? ? ? ? ? ? ? ? ? ?= ? 1.11022302462515654E-016
> ?Safe minimum ? ? ? ? ? ? ? ? = ? 2.22507385850720138E-308
> ?Base ? ? ? ? ? ? ? ? ? ? ? ? = ? ?2.0000000000000000
> ?Precision ? ? ? ? ? ? ? ? ? ?= ? 2.22044604925031308E-016
> ?Number of digits in mantissa = ? ?53.000000000000000
> ?Rounding mode ? ? ? ? ? ? ? ?= ? ?1.0000000000000000
> ?Minimum exponent ? ? ? ? ? ? = ? -1021.0000000000000
> ?Underflow threshold ? ? ? ? ?= ? 2.22507385850720138E-308
> ?Largest exponent ? ? ? ? ? ? = ? ?1024.0000000000000
> ?Overflow threshold ? ? ? ? ? = ? 1.79769313486231571E+308
> ?Reciprocal of safe minimum ? = ? 4.49423283715578977E+307
>
>
> --
> Orion Poplawski
> Technical Manager ? ? ? ? ? ? ? ? ? ? 303-415-9701 x222
> NWRA/CoRA Division ? ? ? ? ? ? ? ? ? ?FAX: 303-415-9702
> 3380 Mitchell Lane ? ? ? ? ? ? ? ? ?orion at cora.nwra.com
> Boulder, CO 80301 ? ? ? ? ? ? ?http://www.cora.nwra.com
>

Thanks. This looks good. FWIW I recompiled lapack (with Os replaced
with O0), atlas and
octave srs.rpms from rawhide on F11/PPC and octave passed all checks.

Sincerely,

Dmitri.
--


From orion at cora.nwra.com  Fri Sep  4 09:47:23 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 04 Sep 2009 08:47:23 -0600
Subject: [OctDev] test_sparse.m fails on ppc64 build
In-Reply-To: <1252029711.16399.7.camel@sh-t400>
References: <loom.20090903T222522-569@post.gmane.org>
	<1252029711.16399.7.camel@sh-t400>
Message-ID: <4AA1287B.3040508@cora.nwra.com>

On 09/03/2009 08:01 PM, S?ren Hauberg wrote:
> tor, 03 09 2009 kl. 20:27 +0000, skrev Orion Poplawski:
>> Running make check on octave 3.2.2 build in Fedora Rawhide fails in
>> test_sparse.m on ppc64.
>>
>> Fixed test scripts:
>>    test_args.m ............................................ PASS   26/26
>> .....
>>    test_sparse.m ..........................................panic: Segmentation
>> fault -- stopping myself...
>> make[2]: *** [check] Segmentation fault
>>
>>
>> Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=521142
>> Build log: http://koji.fedoraproject.org/koji/getfile?taskID=1653016&name=build.log
>>
>> Any ideas?  Any kind of test verbosity that can be turned on to help debug?
>
> You should report this to the Octave bug list (bug at octave.org). To get
> more details about the issue look in the 'test/fntests.log' file.

Sorry, should have checked the gmane groups closer.

Not much in fntests.log, ends with:

 >>>>> processing test_sparse

gdb shows:

#0  0x00000400037fe490 in 
._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE15_M_insert_floatIdEES4_S4_RSt8ios_baseccT_ 
()
    from /usr/lib64/libstdc++.so.6
#1  0x00000400037fe78c in 
._ZNKSt17__gnu_cxx_ldbl1287num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES4_RSt8ios_basecd 
() from /usr/lib64/libstdc++.so.6
#2  0x0000040003811f20 in ._ZNSo9_M_insertIdEERSoT_ ()
    from /usr/lib64/libstdc++.so.6
#3  0x000004000070d100 in operator<< (__f=<value optimized out>,
     this=<value optimized out>)
     at 
/usr/lib/gcc/ppc64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/ostream:210
#4  operator<< (__f=<value optimized out>, this=<value optimized out>)
     at pr-output.cc:228
#5  0x00000400007108bc in pr_any_float (fmt=0x400011e4838, os=..., d=0,
     fw=<value optimized out>) at pr-output.cc:1395
#6  0x0000040000711ff0 in pr_imag_float (fw=<value optimized out>,
     d=<value optimized out>, os=<value optimized out>) at pr-output.cc:1413
#7  pr_complex (fw=<value optimized out>, d=<value optimized out>,
     os=<value optimized out>) at pr-output.cc:1443
#8  0x00000400007137c8 in octave_print_internal (os=..., c=...) at 
pr-output.cc:1959
#9  0x00000400009bb364 in 
octave_base_sparse<SparseComplexMatrix>::print_raw (
     this=0x1012d1b8, os=..., pr_as_read_syntax=false) at 
ov-base-sparse.cc:314
#10 0x00000400009b711c in octave_base_sparse<SparseComplexMatrix>::print (
     this=<value optimized out>, os=<value optimized out>,
     pr_as_read_syntax=<value optimized out>) at ov-base-sparse.cc:257
#11 0x000004000070f19c in print (pr_as_read_syntax=<value optimized out>,
     os=<value optimized out>, this=<value optimized out>) at ov.h:950
#12 Fdisp (pr_as_read_syntax=<value optimized out>, os=<value optimized 
out>,
     this=<value optimized out>) at pr-output.cc:3298
#13 0x00000400008c9ff0 in octave_builtin::do_multi_index_op 
(this=0x101b3078,
     nargout=1, args=...) at ov-builtin.cc:107
#14 0x00000400008c981c in octave_builtin::subsref (this=0x101b3078, 
type=...,
     idx=..., nargout=1) at ov-builtin.cc:55
#15 0x00000400008cad24 in octave_builtin::subsref (this=<value optimized 
out>,
     type=<value optimized out>, idx=<value optimized out>) at 
ov-builtin.h:56
#16 0x0000040000866180 in octave_value::subsref (this=<value optimized out>,
     type=<value optimized out>, idx=<value optimized out>,
     nargout=<value optimized out>) at ov.cc:1059
#17 0x00000400009f19f0 in tree_index_expression::rvalue (
     this=<value optimized out>, nargout=1) at pt-idx.cc:387
#18 0x00000400009ed17c in tree_index_expression::rvalue1 (
     this=<value optimized out>, nargout=<value optimized out>) at 
pt-idx.cc:398
#19 0x00000400009ca92c in tree_simple_assignment::rvalue1 (this=0x10a2a9d0)
     at pt-assign.cc:201
#20 0x00000400009df218 in tree_evaluator::visit_statement (
     this=<value optimized out>, stmt=<value optimized out>) at 
pt-eval.cc:695
#21 0x0000040000a0dbc8 in tree_statement::accept (this=<value optimized 
out>,
     tw=<value optimized out>) at pt-stmt.cc:152
(gdb) up 4
#4  operator<< (__f=<value optimized out>, this=<value optimized out>)
     at pr-output.cc:228
228       os << pff.val;
Current language:  auto
The current source language is "auto; currently c++".
(gdb) list
223
224       std::ios::fmtflags oflags =
225         os.flags (static_cast<std::ios::fmtflags>
226                   (pff.f.fmt | pff.f.up | pff.f.sp));
227
228       os << pff.val;
229
230       os.flags (oflags);
231
232       return os;
(gdb) print pff.val
Cannot access memory at address 0x8
(gdb) up
#5  0x00000400007108bc in pr_any_float (fmt=0x400011e4838, os=..., d=0,
     fw=<value optimized out>) at pr-output.cc:1395
1395            os << pr_formatted_float (*fmt, d);
(gdb) print d
$3 = 0
(gdb) print fmt
$4 = (const float_format *) 0x400011e4838
(gdb) print *fmt
$5 = {fw = 2147483647, prec = -2147483648, fmt = 0, up = 0, sp = 0}

#9  0x00000400009bb364 in 
octave_base_sparse<SparseComplexMatrix>::print_raw (
     this=0x1012d1b8, os=..., pr_as_read_syntax=false) at 
ov-base-sparse.cc:314
314                   octave_print_internal (os, matrix.data(i), 
pr_as_read_syntax);
(gdb) print matrix.data(i)
$8 = (std::complex<double> &) @0x10c54e30: {_M_value = 1 + -1 * I}

Hope that helps.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

From rdgrdgrdg at verizon.net  Sat Sep  5 00:35:01 2009
From: rdgrdgrdg at verizon.net (Richard Greenblatt)
Date: Sat, 05 Sep 2009 01:35:01 -0400
Subject: Subject:after first plot followed by hold,
	additional plot (s) are ignored
Message-ID: <1252128901.24530.6.camel@lnx1>

Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu

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

 first plot works as expected, but after hold additional plots are
ignored.

Repeat-By:
here is code fragment.  (this was matlab code)

---------
% This defines 20 discrete wavelengths
wavelength = 380:20:760; %(nm)

% Define the vectors of cone responsiveness
% Cone sensitivies for wavelengths in the visible range.  This data is 
%  based on a graph on page 93 in Wandell's "Foundations of Vision" 
L_cone_log = [-.9 -1.1 -1 -.8 -.7 -.6 -.5 -.4 -.3 -.25 -.3  -.4 -.8 -1.2
-1.6 -1.9 -2.4 -2.8 -3.6 -4];

M_cone_log = [-.8 -.85 -.85 -.6 -.5 -.4 -.3 -.2 -.1 -.15 -.3  -.7 -1.2
-1.7 -2.2 -2.9 -3.5 -4.2 -4.8 -5.5];

S_cone_log = [-.4 -.3 -.2 -.1 -.3 -.6 -1.2 -1.8 -2.5 -3.2  -4.1 -5 -6
-7 -8 -9 -10 -10.5 -11 -11.5];

% Raise everything to the 10 power to get the actual responsitivies.  
% These vectors contain the coefficients l_i, m_i, and s_i described in
the 
% problem statement from shortest to longest wavelength. 
L_coefficients = 10.^(L_cone_log);
M_coefficients = 10.^(M_cone_log);
S_coefficients = 10.^(S_cone_log);

% Plot the cone responsiveness. 
figure(1);
plot(wavelength,L_cone_log,'-*');
hold;
plot(wavelength,M_cone_log,'--x');
plot(wavelength,S_cone_log,'-o')
xlabel('Light Wavelength (nm)');
ylabel('Log Relative Sensitivity');
legend('L cones', 'M cones', 'S cones');
title('Approximate Human Cone Sensitivities');
grid;


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 lnx1 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18
19:25:34 UTC 2009 x86_64 GNU/Linux
configure opts:   
Fortran compiler: f77
FFLAGS:           -O
FLIBS:            /usr/lib/libg2c.so.0 
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) 
CFLAGS:           -g -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.3.3
CXXFLAGS:         -g -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:          
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.2
BLAS_LIBS:        -llapack -lcblas -lf77blas -latlas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lcblas -lf77blas -latlas
-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_FFTW3=1
  -DHAVE_GLPK_H=1 -DHAVE_GLPK=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_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/local/libexec/octave/3.2.2/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/api-v37/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/3.2.2/exec/x86_64-unknown-linux-gnu:/usr/local/bin:/home/rg/ros/ros/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/cuda/bin
  IMAGE_PATH = .:/usr/local/share/octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/rg/.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 = <no value or error in displaying it>
  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 dasergatskov at gmail.com  Sat Sep  5 09:14:19 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sat, 5 Sep 2009 09:14:19 -0500
Subject: Subject:after first plot followed by hold, additional plot (s) 
	are ignored
In-Reply-To: <1252128901.24530.6.camel@lnx1>
References: <1252128901.24530.6.camel@lnx1>
Message-ID: <892b16670909050714r1bad12e2u74dacabf96cdd468@mail.gmail.com>

On Sat, Sep 5, 2009 at 12:35 AM, Richard
Greenblatt<rdgrdgrdg at verizon.net> wrote:
> Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu
>
> Description:
> -----------
>
> ?first plot works as expected, but after hold additional plots are
> ignored.
>

It does appear to be a bug, but replacing "hold;"
with "hold on" makes the code work as expected.

Dmitri.
--


From dasergatskov at gmail.com  Sat Sep  5 11:11:09 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sat, 5 Sep 2009 11:11:09 -0500
Subject: Subject:after first plot followed by hold, additional plot (s) 
	are ignored
In-Reply-To: <892b16670909050714r1bad12e2u74dacabf96cdd468@mail.gmail.com>
References: <1252128901.24530.6.camel@lnx1>
	<892b16670909050714r1bad12e2u74dacabf96cdd468@mail.gmail.com>
Message-ID: <892b16670909050911q243d1a1agba04e15c56f3aa1f@mail.gmail.com>

A short demonstration of the bug is the following:

octave:1> ishold
ans = 0
octave:2> hold
octave:3> ishold
ans = 0
octave:4> hold
octave:5> ishold
ans =  1

(This is with both 3.2.2 and 3.2.3rc2)


Dmitri.
--

From jwe at octave.org  Sat Sep  5 15:53:11 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 5 Sep 2009 16:53:11 -0400
Subject: Subject:after first plot followed by hold,
	additional plot (s) are ignored
In-Reply-To: <1252128901.24530.6.camel@lnx1>
References: <1252128901.24530.6.camel@lnx1>
Message-ID: <19106.53175.152457.317688@segfault.lan>

On  5-Sep-2009, Richard Greenblatt wrote:

| Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu
| 
| Description:
| -----------
| 
|  first plot works as expected, but after hold additional plots are
| ignored.
| 
| Repeat-By:
| here is code fragment.  (this was matlab code)
| 
| ---------
| % This defines 20 discrete wavelengths
| wavelength = 380:20:760; %(nm)
| 
| % Define the vectors of cone responsiveness
| % Cone sensitivies for wavelengths in the visible range.  This data is 
| %  based on a graph on page 93 in Wandell's "Foundations of Vision" 
| L_cone_log = [-.9 -1.1 -1 -.8 -.7 -.6 -.5 -.4 -.3 -.25 -.3  -.4 -.8 -1.2
| -1.6 -1.9 -2.4 -2.8 -3.6 -4];
| 
| M_cone_log = [-.8 -.85 -.85 -.6 -.5 -.4 -.3 -.2 -.1 -.15 -.3  -.7 -1.2
| -1.7 -2.2 -2.9 -3.5 -4.2 -4.8 -5.5];
| 
| S_cone_log = [-.4 -.3 -.2 -.1 -.3 -.6 -1.2 -1.8 -2.5 -3.2  -4.1 -5 -6
| -7 -8 -9 -10 -10.5 -11 -11.5];
| 
| % Raise everything to the 10 power to get the actual responsitivies.  
| % These vectors contain the coefficients l_i, m_i, and s_i described in
| the 
| % problem statement from shortest to longest wavelength. 
| L_coefficients = 10.^(L_cone_log);
| M_coefficients = 10.^(M_cone_log);
| S_coefficients = 10.^(S_cone_log);
| 
| % Plot the cone responsiveness. 
| figure(1);
| plot(wavelength,L_cone_log,'-*');
| hold;
| plot(wavelength,M_cone_log,'--x');
| plot(wavelength,S_cone_log,'-o')
| xlabel('Light Wavelength (nm)');
| ylabel('Log Relative Sensitivity');
| legend('L cones', 'M cones', 'S cones');
| title('Approximate Human Cone Sensitivities');
| grid;

I checked in the following change.

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

Jaroslav, unless someone notices a problem, this change could probably
be applied to the 3.2.x release branch.

Thanks,

jwe

From marco_atzeri at yahoo.it  Sat Sep  5 17:20:58 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Sat, 5 Sep 2009 22:20:58 +0000 (GMT)
Subject: comparing complex with real
Message-ID: <639307.47658.qm@web25504.mail.ukl.yahoo.com>

on latest hg source the comparison between a complex and real
seems limited to the real part instead of comparing
abs and arg

octave:27> 1+1i>1
ans = 0
octave:29> 1+i<1.1
ans =  1

comparing complex with complex looks fine

octave:28> 1+1i>i
ans =  1
octave:30> 1+i<1+i
ans = 0
octave:31> 1+i<2i 
ans =  1
octave:32> 1+i<1.4i
ans = 0

built on cygwin-1.7 with gcc-4.3.2

Regards
Marco


      


From bpabbott at mac.com  Sat Sep  5 17:41:32 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sat, 05 Sep 2009 18:41:32 -0400
Subject: comparing complex with real
In-Reply-To: <639307.47658.qm@web25504.mail.ukl.yahoo.com>
References: <639307.47658.qm@web25504.mail.ukl.yahoo.com>
Message-ID: <C8758ECB-7809-4C02-912A-1ACBE2F124AB@mac.com>


On Sep 5, 2009, at 6:20 PM, Marco Atzeri wrote:

> on latest hg source the comparison between a complex and real
> seems limited to the real part instead of comparing
> abs and arg
>
> octave:27> 1+1i>1
> ans = 0
> octave:29> 1+i<1.1
> ans =  1
>
> comparing complex with complex looks fine
>
> octave:28> 1+1i>i
> ans =  1
> octave:30> 1+i<1+i
> ans = 0
> octave:31> 1+i<2i
> ans =  1
> octave:32> 1+i<1.4i
> ans = 0
>
> built on cygwin-1.7 with gcc-4.3.2
>

Is this another case of  WWMWT?

For matlab ...

 >> 1+1i>1
ans =     0
 >> 1+i<1.1
ans =     1
 >> 1+1i>i
ans =     1
 >> 1+i<1+i
ans =     0
 >> 1+i<2i
ans =     0
 >> 1+i<1.4i
ans =     0

Ben


From highegg at gmail.com  Sun Sep  6 00:44:53 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 6 Sep 2009 07:44:53 +0200
Subject: comparing complex with real
In-Reply-To: <639307.47658.qm@web25504.mail.ukl.yahoo.com>
References: <639307.47658.qm@web25504.mail.ukl.yahoo.com>
Message-ID: <69d8d540909052244h34ad0a37ib92ca271bb7a7238@mail.gmail.com>

On Sun, Sep 6, 2009 at 12:20 AM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
> on latest hg source the comparison between a complex and real
> seems limited to the real part instead of comparing
> abs and arg
>
> octave:27> 1+1i>1
> ans = 0
> octave:29> 1+i<1.1
> ans = ?1
>
> comparing complex with complex looks fine
>
> octave:28> 1+1i>i
> ans = ?1
> octave:30> 1+i<1+i
> ans = 0
> octave:31> 1+i<2i
> ans = ?1
> octave:32> 1+i<1.4i
> ans = 0
>
> built on cygwin-1.7 with gcc-4.3.2
>
> Regards
> Marco
>

oops. Please see
http://hg.savannah.gnu.org/hgweb/octave/rev/3ee9029931b3

-- 
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  Sun Sep  6 00:57:19 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 6 Sep 2009 07:57:19 +0200
Subject: comparing complex with real
In-Reply-To: <C8758ECB-7809-4C02-912A-1ACBE2F124AB@mac.com>
References: <639307.47658.qm@web25504.mail.ukl.yahoo.com>
	<C8758ECB-7809-4C02-912A-1ACBE2F124AB@mac.com>
Message-ID: <69d8d540909052257k23725b1aw6bc58f1aabdd60d2@mail.gmail.com>

On Sun, Sep 6, 2009 at 12:41 AM, Ben Abbott<bpabbott at mac.com> wrote:
>
> On Sep 5, 2009, at 6:20 PM, Marco Atzeri wrote:
>
>> on latest hg source the comparison between a complex and real
>> seems limited to the real part instead of comparing
>> abs and arg
>>
>> octave:27> 1+1i>1
>> ans = 0
>> octave:29> 1+i<1.1
>> ans = ?1
>>
>> comparing complex with complex looks fine
>>
>> octave:28> 1+1i>i
>> ans = ?1
>> octave:30> 1+i<1+i
>> ans = 0
>> octave:31> 1+i<2i
>> ans = ?1
>> octave:32> 1+i<1.4i
>> ans = 0
>>
>> built on cygwin-1.7 with gcc-4.3.2
>>
>
> Is this another case of ?WWMWT?
>

In fact this is a case of WWMTLDSR (Whatever Was Mathworks Thinking,
Let's Do Something Reasonable).
See http://www.nabble.com/complex-comparison-ops-vs.-Matlab-td25169741.html


-- 
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  Sun Sep  6 04:57:43 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Sun, 6 Sep 2009 09:57:43 +0000 (GMT)
Subject: comparing complex with real
In-Reply-To: <69d8d540909052244h34ad0a37ib92ca271bb7a7238@mail.gmail.com>
Message-ID: <945274.65362.qm@web25501.mail.ukl.yahoo.com>

--- Dom 6/9/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:

> Da: Jaroslav Hajek <highegg at gmail.com>
> Oggetto: Re: comparing complex with real
> A: "Marco Atzeri" <marco_atzeri at yahoo.it>
> Cc: bug at octave.org
> Data: Domenica 6 settembre 2009, 07:44
> On Sun, Sep 6, 2009 at 12:20 AM,
> Marco Atzeri<marco_atzeri at yahoo.it>
> wrote:
> > on latest hg source the comparison between a complex
> and real
> > seems limited to the real part instead of comparing
> > abs and arg
> >
> > octave:27> 1+1i>1
> > ans = 0
> > octave:29> 1+i<1.1
> > ans = ?1
> >
> > comparing complex with complex looks fine
> >
> > octave:28> 1+1i>i
> > ans = ?1
> > octave:30> 1+i<1+i
> > ans = 0
> > octave:31> 1+i<2i
> > ans = ?1
> > octave:32> 1+i<1.4i
> > ans = 0
> >
> > built on cygwin-1.7 with gcc-4.3.2
> >
> > Regards
> > Marco
> >
> 
> oops. Please see
> http://hg.savannah.gnu.org/hgweb/octave/rev/3ee9029931b3
> 
> -- 
> RNDr. Jaroslav Hajek

octave:1> 1+1 > 1
ans =  1
octave:2> 1+i <1.1
ans = 0
octave:3> 1+i <1.5
ans =  1

fine

Marco




      


From h_ayguen at web.de  Sun Sep  6 09:44:00 2009
From: h_ayguen at web.de (h_ayguen)
Date: Sun, 6 Sep 2009 07:44:00 -0700 (PDT)
Subject: wavwrite() and wavread() on stereo signals incosistent
Message-ID: <25318432.post@talk.nabble.com>



writing a complex (stereo) signal and reading it again,
results in negated right (2nd) channel:

% generate complex sine
N = 1024;
F = zeros( 1, N );
F(2) = 1;
s = ifft( F );
s = s / max( [ real(s) imag(s) ] );
% write as stereo file
t = [ real(s') , imag(s') ];
wavwrite( t, 'test.wav' );
% read stereo file
u = wavread( 'test.wav' );
v = u( : , 1 ) + i * u( : , 2 );
%
% result: imag(s) == - imag(v)

-- 
View this message in context: http://www.nabble.com/wavwrite%28%29-and-wavread%28%29-on-stereo-signals-incosistent-tp25318432p25318432.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From jwe at octave.org  Sun Sep  6 10:20:55 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 6 Sep 2009 11:20:55 -0400
Subject: wavwrite() and wavread() on stereo signals incosistent
In-Reply-To: <25318432.post@talk.nabble.com>
References: <25318432.post@talk.nabble.com>
Message-ID: <19107.54103.225427.977196@segfault.lan>

On  6-Sep-2009, h_ayguen wrote:

| % generate complex sine
| N = 1024;
| F = zeros( 1, N );
| F(2) = 1;
| s = ifft( F );
| s = s / max( [ real(s) imag(s) ] );
| % write as stereo file
| t = [ real(s') , imag(s') ];

This line is your problem.  Note the difference between s' and s.'.

jwe

From h_ayguen at web.de  Sun Sep  6 10:40:02 2009
From: h_ayguen at web.de (h_ayguen)
Date: Sun, 6 Sep 2009 08:40:02 -0700 (PDT)
Subject: wavwrite() and wavread() on stereo signals incosistent
In-Reply-To: <19107.54103.225427.977196@segfault.lan>
References: <25318432.post@talk.nabble.com>
	<19107.54103.225427.977196@segfault.lan>
Message-ID: <25318884.post@talk.nabble.com>



changing that line to
t = [ real(s)' , imag(s)' ];
solves the problem - of course.

-- 
View this message in context: http://www.nabble.com/wavwrite%28%29-and-wavread%28%29-on-stereo-signals-incosistent-tp25318432p25318884.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From jstottsj at gmail.com  Sun Sep  6 16:05:54 2009
From: jstottsj at gmail.com (Jonathan Stott)
Date: Sun, 6 Sep 2009 14:05:54 -0700
Subject: "make check" fails for eigs()
Message-ID: <F9095223-2900-4710-99EC-EDCF75BA4A8B@gmail.com>

Bug report for Octave 3.2.2 configured for i386-apple-darwin9.8.0

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

Running "make check" fails for eig.cc

 From fntests.log:

 >>>>> processing /Users/jstott/Public/download/science/octave-3.2.2/ 
src/DLD-FUNCTIONS/eigs.cc
   ***** testif HAVE_ARPACK
  d1 = eigs (A, k);
  assert (d1, d0(end:-1:(end-k+1)), 1e-11);
!!!!! test failed
eigs: error -9999 in dsaupd

On the colsole, what's printed is
  src/DLD-FUNCTIONS/eigs.cc ..............................A(I): Index  
exceeds matrix dimension.

dsaupd() is a routine inside libarpack and error -9999 is returned  
when it "Could not build an Lanczos factorization."  The example code  
that comes with arpack builds just fine (including the bits that call  
dsaupd()), so it's not an obvious library problem.

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

Rebuild from octave sources and run "make check".

I'm using the compiler from <http://hpc.sourceforge.net>, not the  
supplied
Apple gcc because hpc's is a) newer, and b) include gfortran.

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

uname output:     Darwin jstott.local 9.8.0 Darwin Kernel Version  
9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386  
i386
configure opts:   '--with-blas=-lrefblas' '--with-lapack=-lreflapack'  
'--x-includes=/usr/X11/include' '--x-libraries=/usr/X11/lib' 'CC=/usr/ 
local/bin/gcc' 'CFLAGS=-Wall -O2 -msse3 -mfpmath=sse -I/usr/local/ 
include -I/usr/local/include/hdf5-1.8' 'LDFLAGS=-L/usr/local/lib'  
'LIBS=-lmetis -lstdc++' 'CPPFLAGS=-I/usr/local/include -I/usr/local/ 
include/hdf5-1.8' 'CPP=/usr/local/bin/cpp' 'CXX=/usr/local/bin/gcc'  
'CXXFLAGS=-Wall -O2 -msse3 -mfpmath=sse -I/usr/local/include'  
'F77=gfortran' 'FFLAGS=-Wall -O2 -msse3 -mfpmath=sse -I/usr/local/ 
include'
Fortran compiler: gfortran
FFLAGS:           -Wall -O2 -msse3 -mfpmath=sse -I/usr/local/include - 
mieee-fp
FLIBS:            -L/usr/local/lib -L/usr/local/lib/gcc/i386-apple- 
darwin9.7.0/4.4.1 -L/usr/local/lib/gcc/i386-apple- 
darwin9.7.0/4.4.1/../../.. -lhdf5 -lz -lm -lmetis -lstdc++ - 
lgfortranbegin -lgfortran
CPPFLAGS:         -I/usr/local/include -I/usr/local/include/hdf5-1.8 - 
I/usr/local/include
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       /usr/local/bin/gcc, version 4.4.1 20090623  
(prerelease) (GCC)
CFLAGS:           -Wall -O2 -msse3 -mfpmath=sse -I/usr/local/include - 
I/usr/local/include/hdf5-1.8
CPICFLAG:         -fPIC
C++ compiler:     /usr/local/bin/g++, version 4.4.1
CXXFLAGS:         -Wall -O2 -msse3 -mfpmath=sse -I/usr/local/include
CXXPICFLAG:       -fPIC
LD_CXX:           /usr/local/bin/g++
LDFLAGS:          -L/usr/local/lib
LIBFLAGS:         -L.
RLD_FLAG:
BLAS_LIBS:        -lreflapack -lrefblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -lrefblas -lhdf5 -lz -lm - 
lmetis -lstdc++
LEXLIB:
LIBGLOB:
SED:              /usr/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_FRAMEWORK_CARBON=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_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=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_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


From dasergatskov at gmail.com  Sun Sep  6 16:33:23 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sun, 6 Sep 2009 16:33:23 -0500
Subject: "make check" fails for eigs()
In-Reply-To: <F9095223-2900-4710-99EC-EDCF75BA4A8B@gmail.com>
References: <F9095223-2900-4710-99EC-EDCF75BA4A8B@gmail.com>
Message-ID: <892b16670909061433w214c8ad2v1966de2951b458c8@mail.gmail.com>

On Sun, Sep 6, 2009 at 4:05 PM, Jonathan Stott<jstottsj at gmail.com> wrote:
> Bug report for Octave 3.2.2 configured for i386-apple-darwin9.8.0
>
> Description:
> -----------
>
> Running "make check" fails for eig.cc
>

Could you compile and run the attached test program and report
the results back?

gfortran dlamchtst.f -lreflapack -lm -o dlamchtst
./dlamchtst

Sincerely,

Dmitri.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlamchtst.f
Type: application/octet-stream
Size: 1522 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090906/d417950c/attachment.obj 

From highegg at gmail.com  Mon Sep  7 01:02:40 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 7 Sep 2009 08:02:40 +0200
Subject: eigs interface inconsistent with documentation?
In-Reply-To: <2A0B6317-D7E6-4BF7-B06A-28AE873A230A@gmail.com>
References: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>
	<4A9C472A.9070403@dbateman.org> <4A9CBC8E.6060800@dbateman.org>
	<2A0B6317-D7E6-4BF7-B06A-28AE873A230A@gmail.com>
Message-ID: <69d8d540909062302w361b46den94f18d2ecab347b6@mail.gmail.com>

On Tue, Sep 1, 2009 at 10:08 AM, Carlo de Falco<carlo.defalco at gmail.com> wrote:
>
> On 1 Sep 2009, at 08:17, David Bateman wrote:
>
>> Yes that was the issue. The attached patch, which I've pushed to
>> savannah, fixes the issue and adds a test.
>>
>> D.
>
> Thanks!
> Jaroslav, do you think this could be transplanted to the 3.2.x branch
> and go into the upcoming release?
> c.

Transplanted.

-- 
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 Sep  7 01:03:13 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 7 Sep 2009 08:03:13 +0200
Subject: Subject:after first plot followed by hold, additional plot (s) 
	are ignored
In-Reply-To: <19106.53175.152457.317688@segfault.lan>
References: <1252128901.24530.6.camel@lnx1>
	<19106.53175.152457.317688@segfault.lan>
Message-ID: <69d8d540909062303s5accb306o4d3859c801118bca@mail.gmail.com>

On Sat, Sep 5, 2009 at 10:53 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?5-Sep-2009, Richard Greenblatt wrote:
>
> | Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu
> |
> | Description:
> | -----------
> |
> | ?first plot works as expected, but after hold additional plots are
> | ignored.
> |
> | Repeat-By:
> | here is code fragment. ?(this was matlab code)
> |
> | ---------
> | % This defines 20 discrete wavelengths
> | wavelength = 380:20:760; %(nm)
> |
> | % Define the vectors of cone responsiveness
> | % Cone sensitivies for wavelengths in the visible range. ?This data is
> | % ?based on a graph on page 93 in Wandell's "Foundations of Vision"
> | L_cone_log = [-.9 -1.1 -1 -.8 -.7 -.6 -.5 -.4 -.3 -.25 -.3 ?-.4 -.8 -1.2
> | -1.6 -1.9 -2.4 -2.8 -3.6 -4];
> |
> | M_cone_log = [-.8 -.85 -.85 -.6 -.5 -.4 -.3 -.2 -.1 -.15 -.3 ?-.7 -1.2
> | -1.7 -2.2 -2.9 -3.5 -4.2 -4.8 -5.5];
> |
> | S_cone_log = [-.4 -.3 -.2 -.1 -.3 -.6 -1.2 -1.8 -2.5 -3.2 ?-4.1 -5 -6
> | -7 -8 -9 -10 -10.5 -11 -11.5];
> |
> | % Raise everything to the 10 power to get the actual responsitivies.
> | % These vectors contain the coefficients l_i, m_i, and s_i described in
> | the
> | % problem statement from shortest to longest wavelength.
> | L_coefficients = 10.^(L_cone_log);
> | M_coefficients = 10.^(M_cone_log);
> | S_coefficients = 10.^(S_cone_log);
> |
> | % Plot the cone responsiveness.
> | figure(1);
> | plot(wavelength,L_cone_log,'-*');
> | hold;
> | plot(wavelength,M_cone_log,'--x');
> | plot(wavelength,S_cone_log,'-o')
> | xlabel('Light Wavelength (nm)');
> | ylabel('Log Relative Sensitivity');
> | legend('L cones', 'M cones', 'S cones');
> | title('Approximate Human Cone Sensitivities');
> | grid;
>
> I checked in the following change.
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/e381f80a5f7a
>
> Jaroslav, unless someone notices a problem, this change could probably
> be applied to the 3.2.x release branch.
>
Done.



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


From lukasz.sowinski at post.pl  Mon Sep  7 07:05:26 2009
From: lukasz.sowinski at post.pl (=?utf-8?q?=C5=81ukasz_Sowi=C5=84ski?=)
Date: Mon, 7 Sep 2009 21:05:26 +0900
Subject: a minor typo in the io/dlmwrite.m script
Message-ID: <200909072105.26248.lukasz.sowinski@post.pl>

Bug report for Octave 3.2.0 configured for i686-pc-linux-gnu
(applies also to the 3.2.2 version)

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

  * In the 'io/dlmwrite.m' the 'print_usage' invocation is misspelled as 
'ptint_usage'. 

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

  * F.i. invoke 'dlmwrite' (without any parameters) from the octave command 
line. 

Seriousness:
-----------

  * Almost none.

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

uname output:     Linux gentoo 2.6.30-gentoo-r4 #1 SMP PREEMPT Thu Jul 30 
17:03:11 JST 2009 i686 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel 
GNU/Linux
configure opts:   '--prefix=/usr' '--build=i686-pc-linux-gnu' '--host=i686-pc-
linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--
datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--
localstatedir=/var/state/octave' '--enable-shared' '--without-arpack' '--with-
blas=-lblas  ' '--with-lapack=-llapack -lblas  ' '--without-hdf5' '--without-
curl' '--with-zlib' '--without-fftw' '--without-umfpack' '--without-colamd' 
'--without-ccolamd' '--without-cholmod' '--without-cxsparse' '--enable-
readline' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 
'CFLAGS=-O2 -march=prescott -pipe -fomit-frame-pointer' 'LDFLAGS=-Wl,-O1' 
'CXXFLAGS=-O2 -march=prescott -pipe -fomit-frame-pointer'
Fortran compiler: i686-pc-linux-gnu-gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/X11R6/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.3.2 -
L/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib -
L/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../.. -lz -lgfortranbegin -lgfortran 
-lm -lfreetype -lGL -lGLU
CPPFLAGS:         -I/usr/include/freetype2
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       i686-pc-linux-gnu-gcc, version 4.3.2 (Gentoo 4.3.2-r3 p1.6, 
pie-10.1.5) 
CFLAGS:           -O2 -march=prescott -pipe -fomit-frame-pointer
CPICFLAG:         -fPIC
C++ compiler:     i686-pc-linux-gnu-g++, version 4.3.2
CXXFLAGS:         -O2 -march=prescott -pipe -fomit-frame-pointer -
I/usr/include/freetype2
CXXPICFLAG:       -fPIC
LD_CXX:           i686-pc-linux-gnu-g++
LDFLAGS:          -Wl,-O1
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.2.0
BLAS_LIBS:        -llapack -lblas   -lblas  
FFTW_LIBS:        
LIBS:             -lreadline  -lncurses -ldl -lblas   -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_QHULL=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_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=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 = /bin/nano
  EXEC_PATH = /usr/libexec/octave/3.2.0/site/exec/i686-pc-linux-
gnu:/usr/libexec/octave/api-v37/site/exec/i686-pc-linux-
gnu:/usr/libexec/octave/site/exec/i686-pc-linux-
gnu:/usr/libexec/octave/3.2.0/exec/i686-pc-linux-
gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-
bin/4.3.2:/usr/qt/3/bin:/usr/games/bin
  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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/lukasz/.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 = <no value or error in displaying it>
  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 dasergatskov at gmail.com  Mon Sep  7 09:12:44 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Mon, 7 Sep 2009 09:12:44 -0500
Subject: Fwd: "make check" fails for eigs()
In-Reply-To: <892b16670909070712l26ac0ce2p887393e673fb6e@mail.gmail.com>
References: <F9095223-2900-4710-99EC-EDCF75BA4A8B@gmail.com>
	<892b16670909061433w214c8ad2v1966de2951b458c8@mail.gmail.com>
	<B2302D27-1481-4583-948A-832201DBE15F@gmail.com>
	<892b16670909070712l26ac0ce2p887393e673fb6e@mail.gmail.com>
Message-ID: <892b16670909070712t2a1de26hbdbcabc647d18cfe@mail.gmail.com>

Forgot to Cc to the list


---------- Forwarded message ----------
From: Dmitri A. Sergatskov <dasergatskov at gmail.com>
Date: Mon, Sep 7, 2009 at 9:12 AM
Subject: Re: "make check" fails for eigs()
To: Jonathan Stott <jstottsj at gmail.com>


On Mon, Sep 7, 2009 at 12:39 AM, Jonathan Stott<jstottsj at gmail.com> wrote:
> Hi Dmitri,
>
> Sure thing, here you go:
>
> jstott at jstott:~> gfortran dlamchtst.f -lreflapack -lm -o dlamchtst
> jstott at jstott:~> ./dlamchtst
> ?Epsilon ? ? ? ? ? ? ? ? ? ? ?= ? 1.11022302462515654E-016
> ?Safe minimum ? ? ? ? ? ? ? ? = ? 2.22507385850720138E-308
> ?Base ? ? ? ? ? ? ? ? ? ? ? ? = ? ?2.0000000000000000
> ?Precision ? ? ? ? ? ? ? ? ? ?= ? 2.22044604925031308E-016
> ?Number of digits in mantissa = ? ?53.000000000000000
> ?Rounding mode ? ? ? ? ? ? ? ?= ? ?1.0000000000000000
> ?Minimum exponent ? ? ? ? ? ? = ? -1021.0000000000000
> ?Underflow threshold ? ? ? ? ?= ? 2.22507385850720138E-308
> ?Largest exponent ? ? ? ? ? ? = ? ?1024.0000000000000
> ?Overflow threshold ? ? ? ? ? = ? 1.79769313486231571E+308
> ?Reciprocal of safe minimum ? = ? 4.49423283715578977E+307
> jstott at jstott:~>
>
> Also, for reference, the reflapack library I'm using is just the standard
> Netlib reference version (same for librefblas.a).
>

The numbers look good. Do you have everything (suitesparse in particular)
compiled against this library or you might have atlas or some other
optimized lapack mixed in? (ldd /path/to/your/compiled/octave ?will
tell you for sure)

> -JS
>

Sincerely,

Dmiri.
--


From dasergatskov at gmail.com  Mon Sep  7 11:51:13 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Mon, 7 Sep 2009 11:51:13 -0500
Subject: "make check" fails for eigs()
In-Reply-To: <F925EB38-ADD1-4365-806F-6A9FA700D8B3@gmail.com>
References: <F9095223-2900-4710-99EC-EDCF75BA4A8B@gmail.com>
	<892b16670909061433w214c8ad2v1966de2951b458c8@mail.gmail.com>
	<B2302D27-1481-4583-948A-832201DBE15F@gmail.com>
	<892b16670909070712l26ac0ce2p887393e673fb6e@mail.gmail.com>
	<F925EB38-ADD1-4365-806F-6A9FA700D8B3@gmail.com>
Message-ID: <892b16670909070951k4d98d600i7674f9c76c2d58bc@mail.gmail.com>

On Mon, Sep 7, 2009 at 11:27 AM, Jonathan Stott<jstottsj at gmail.com> wrote:
> This is the only lapack I'm using (I rebuilt suitesparse just last night to
> make sure that wasn't the problem).
>
> OSX doesn't have ldd, but nm will work too:

I forgot about that -- use "otool -L" instead.

> jstott at jstott:~> nm /usr/local/atlas32/lib/libatlas.a | head
>
> /usr/local/atlas32/lib/libatlas.a(ATL_flushcache.o):
> ? ? ? ? U _ATL_dzero
> 00000000 T _ATL_flushcache
> ? ? ? ? U _ATL_xerbla
> 0000020c b _N.4677
> ? ? ? ? U _free
> ? ? ? ? U _malloc
> 00000210 b _vp.4676
>
>
> jstott at jstott:~> nm /usr/local/bin/octave-3.2.2 | grep _ATL_
> jstott at jstott:~>

This way you only check that atlas is not linked in statically.
It can be linked in dynamically, that is what ldd or otool can check.
E.g. in my case (on x86_64 linux):

nm octave | grep _ATL_
(returns nothing
yet:
ldd ./octave | grep lapack
	liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x0000003461e00000)


Again, I do not know if you have a dynamic atlas library, and if so
if it does provide a complete optimised lapack replacement; so
I am just shooting in the dark.
The issue here is that octave, starting with version 3.2.x,
uses dlamch routine from lapack to obtain floating-point math
parameters of the system. Previously, it used its own heuristics.
It turned up that dlamch was/is often miscompiled on i386
architecture due to some compiler optimization and mixing
sse and i387 fp registers.
I want to verify that this is not the case here.

>
> -JS
>

Sincerely,

Dmitri.
--


From dasergatskov at gmail.com  Mon Sep  7 16:35:47 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Mon, 7 Sep 2009 16:35:47 -0500
Subject: "make check" fails for eigs()
In-Reply-To: <F8C05AAE-8F35-4DC6-84F2-2E2D06FFBDA6@gmail.com>
References: <F9095223-2900-4710-99EC-EDCF75BA4A8B@gmail.com>
	<892b16670909061433w214c8ad2v1966de2951b458c8@mail.gmail.com>
	<B2302D27-1481-4583-948A-832201DBE15F@gmail.com>
	<892b16670909070712l26ac0ce2p887393e673fb6e@mail.gmail.com>
	<F925EB38-ADD1-4365-806F-6A9FA700D8B3@gmail.com>
	<892b16670909070951k4d98d600i7674f9c76c2d58bc@mail.gmail.com>
	<F8C05AAE-8F35-4DC6-84F2-2E2D06FFBDA6@gmail.com>
Message-ID: <892b16670909071435x2b41c5bap4034c2d222a7e242@mail.gmail.com>

On Mon, Sep 7, 2009 at 4:08 PM, Jonathan Stott<jstottsj at gmail.com> wrote:
> Hi,
>
> OK, otool -L instead:
>
> jstott at jstott:~> otool -L /usr/local/bin/octave-3.2.2
> /usr/local/bin/octave-3.2.2:
> ? ? ? ?/usr/local/lib/octave-3.2.2/liboctinterp.dylib (compatibility version
> 0.0.0, current version 0.0.0)
> ? ? ? ?/usr/local/lib/octave-3.2.2/liboctave.dylib (compatibility version
> 0.0.0, current version 0.0.0)
> ? ? ? ?/usr/local/lib/octave-3.2.2/libcruft.dylib (compatibility version
> 0.0.0, current version 0.0.0)
> ? ? ? ?/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> (compatibility version 1.0.0, current version 1.0.0)
> ? ? ? ?/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> (compatibility version 2.0.0, current version 136.0.0)
> ? ? ? ?/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
> version 5.4.0)
> ? ? ? ?/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.1.4)
> ? ? ? ?/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
> 1.2.3)
> ? ? ? ?/usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
> version 9.0.0)
> ? ? ? ?/usr/local/lib/libftgl.2.dylib (compatibility version 4.0.0, current
> version 4.3.0)
> ? ? ? ?/usr/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,
> current version 10.12.0)
> ? ? ? ?/usr/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0,
> current version 5.2.0)
> ? ? ? ?/usr/local/lib/libstdc++.6.dylib (compatibility version 7.0.0,
> current version 7.12.0)
> ? ? ? ?/usr/local/lib/libgfortran.3.dylib (compatibility version 4.0.0,
> current version 4.0.0)
> ? ? ? ?/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> jstott at jstott:~>
>
> Still no surprises. ?In any case, I built atlas as a static library, same as
> all the Fortran libraries I'm liking octave against (suitesparse, blas,
> lapack, etc).
>
> -JS
>

OK. At this moment I have no idea. You may try the 3.2.3rc3 -- it has some
changes in eigs code. I also crossposted it to octave-help list, may be some
people who has more experience with Mac OSX builds can help.

Sincerely,

Dmitri.
--


From jrollins at finestructure.net  Tue Sep  8 15:43:21 2009
From: jrollins at finestructure.net (Jameson Rollins)
Date: Tue, 08 Sep 2009 13:43:21 -0700
Subject: nargchk return improper message field on success
Message-ID: <E1Ml7X7-0005Ss-Q6@servo.finestructure.net>

To: bug at octave.org
Cc: jrollins at finestructure.net
Subject: nargchk return improper message field on success

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

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

The nargchk function in this new version of octave returns an emptry
string for the msg.message output strucutre upon success.  This breaks
compatibility with Matlab, and breaks previously working calls, such
as:

error(nargchk(1,3,narargin))

The proper return should be an empty array ("[]") in msg.messages upon
success.

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

Any successful can to nargchk, ie: nargchk(1,3,2)

Fix:
---

Here is a very simple patch that solves the problem:

servo:~ 0$ diff -u /usr/share/octave/3.2.0/m/general/nargchk.m{.bak,}
--- /usr/share/octave/3.2.0/m/general/nargchk.m.bak	2009-09-08 09:41:46.000000000 -0700
+++ /usr/share/octave/3.2.0/m/general/nargchk.m		2009-09-08 09:43:55.000000000 -0700
@@ -44,7 +44,7 @@
     error ("nargchk: mina, maxa, and narg must be scalars");
   endif
 
-  msg = struct ("message", "", "identifier", "");
+  msg = struct ("message", [], "identifier", "");
   if (narg < mina)
     msg.message = "not enough input arguments";
     msg.identifier = "Octave:nargchk:not-enough-inputs";
servo:~ 1$


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

uname output:     Linux servo 2.6.30-1-686 #1 SMP Sat Aug 15 19:11:58 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:            -L/usr/lib/gcc/i486-linux-gnu/4.3.4 -L/usr/lib/gcc/i486-linux-gnu/4.3.4/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.4/../../.. -L/usr/lib/i486-linux-gnu -lhdf5 -lz -lgfortranbegin -lgfortran -lm
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.4 (Debian 4.3.4-1) 
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.0
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 -nw
  EXEC_PATH = /usr/lib/octave/3.2.0/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.0/exec/i486-pc-linux-gnu:/usr/bin:/home/jrollins/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/local/sbin:/usr/sbin:/sbin
  IMAGE_PATH = .:/usr/share/octave/3.2.0/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/jrollins/.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 = <no value or error in displaying it>
  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 markusle at gentoo.org  Tue Sep  8 22:06:24 2009
From: markusle at gentoo.org (Markus Dittrich)
Date: Wed, 9 Sep 2009 03:06:24 +0000
Subject: typo in scripts/io/dlmwrite.m
Message-ID: <20090909030624.GA32133@woodpecker.gentoo.org>

Bug report for Octave 3.2.0 configured for x86_64-pc-linux-gnu

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

  * There is a typo in the function scripts/io/dlmwrite.m,
    "ptint_usage ()" instead of "print_usage ()"
   

Fix: (proposed patch)
---

diff -Naur octave-3.2.0/scripts/io/dlmwrite.m octave-3.2.0.new/scripts/io/dlmwrite.m
--- octave-3.2.0/scripts/io/dlmwrite.m  2009-05-25 02:04:59.000000000 -0400
+++ octave-3.2.0.new/scripts/io/dlmwrite.m      2009-09-08 22:08:40.000000000 -0400
@@ -85,7 +85,7 @@
 function dlmwrite (file, a, varargin)

   if (nargin < 2 || ! ischar (file))
-    ptint_usage ();
+    print_usage ();
   endif

   ## set defaults


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

uname output:     Linux dreamm2 2.6.30-gentoo-r5 #1 SMP PREEMPT Sun Aug 16 14:20:39 EDT 2009 x86_64 Dual Core AMD Opteron(tm) Processor 280 AuthenticAMD GNU/Linux
configure opts:   '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--localstatedir=/var/state/octave' '--enable-shared' '--without-arpack' '--with-blas=-L/usr/lib64/blas/threaded-atlas -lblas -latlas -lpthread  ' '--with-lapack=-L/usr/lib64/lapack/atlas -L/usr/lib64/blas/threaded-atlas -llapack -lcblas -lblas -latlas -lpthread  ' '--without-hdf5' '--with-curl' '--with-zlib' '--with-fftw' '--with-umfpack' '--with-colamd' '--with-ccolamd' '--with-cholmod' '--with-cxsparse' '--enable-readline' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=opteron -O2 -fomit-frame-pointer -pipe' 'LDFLAGS=-Wl,-O1,--hash-style=gnu,--sort-common -Wl,-z,now -Wl,-z,relro -Wl,--enable-new-dtags -Wl,--as-needed' 'CXXFLAGS=-march=opteron -O2 -fomit-frame-pointer -pipe' 'FFLAGS=-march=opteron -O2 -fomit-frame-pointer -pipe'
Fortran compiler: x86_64-pc-linux-gnu-gfortran
FFLAGS:           -march=opteron -O2 -fomit-frame-pointer -pipe
FLIBS:            -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/../../.. -lz -lgfortranbegin -lgfortran -lm
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       x86_64-pc-linux-gnu-gcc, version 4.4.1 (Gentoo 4.4.1 p1.0) 
CFLAGS:           -march=opteron -O2 -fomit-frame-pointer -pipe
CPICFLAG:         -fPIC
C++ compiler:     x86_64-pc-linux-gnu-g++, version 4.4.1
CXXFLAGS:         -march=opteron -O2 -fomit-frame-pointer -pipe
CXXPICFLAG:       -fPIC
LD_CXX:           x86_64-pc-linux-gnu-g++
LDFLAGS:          -Wl,-O1,--hash-style=gnu,--sort-common -Wl,-z,now -Wl,-z,relro -Wl,--enable-new-dtags -Wl,--as-needed
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib64/octave-3.2.0
BLAS_LIBS:        -L/usr/lib64/lapack/atlas -L/usr/lib64/blas/threaded-atlas -llapack -lcblas -lblas -latlas -lpthread   -L/usr/lib64/blas/threaded-atlas -lblas -latlas -lpthread  
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -L/usr/lib64/blas/threaded-atlas -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_QHULL=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_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=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_AMD_H=1 -DHAVE_AMD=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=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

-- 
Markus Dittrich (markusle)
Gentoo Linux Developer
Scientific applications
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090909/10a8a632/attachment.bin 

From jwe at octave.org  Tue Sep  8 22:38:00 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 8 Sep 2009 23:38:00 -0400
Subject: typo in scripts/io/dlmwrite.m
In-Reply-To: <20090909030624.GA32133@woodpecker.gentoo.org>
References: <20090909030624.GA32133@woodpecker.gentoo.org>
Message-ID: <19111.8984.742399.655789@segfault.lan>

On  9-Sep-2009, Markus Dittrich wrote:

|   * There is a typo in the function scripts/io/dlmwrite.m,
|     "ptint_usage ()" instead of "print_usage ()"

I fixed this in the main development sources.  Jaroslav, this could be
fixed in the 3.2.x branch too.

Thanks,

jwe

From family.hope at ukonline.co.uk  Wed Sep  9 11:48:45 2009
From: family.hope at ukonline.co.uk (Rowena and John)
Date: Wed, 9 Sep 2009 17:48:45 +0100
Subject: help for dare has first plus that should (?) be minus in Riccati equn
Message-ID: <533C97298DD0443EBC5C76A957A384D9@ASPIRE>


Bug report for Octave 3.0.3 configured for i686-pc-msdosmsvc

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

help for dare has first plus that should (?) be minus in Riccati equn 

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

help dare

Fix:
---

 Just turn first + to a - in equn given in help file

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

uname output:     Windows
configure opts:   
Fortran compiler: fc-msvc
FFLAGS:           -O2
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -lhdf5 -lzlib -lf2c -lkernel32
CPPFLAGS:         -I.  -Ic:/Software/VCLibs/include
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       cc-msvc, version
CFLAGS:           -O2 -MD
CPICFLAG:         
C++ compiler:     cc-msvc, version
CXXFLAGS:         -O2 -EHs -MD
CXXPICFLAG:       
LD_CXX:           cc-msvc
LDFLAGS:          
LIBFLAGS:         -L.
RLD_FLAG:         
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3
LIBS:             -lreadline  -lncurses -lhdf5 -lzlib  -lws2_32 -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_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=unknown -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -D_HDF5USEDLL_=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_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 -Dmode_t=int -Dpid_t=int -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_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DHAVE_PLACEMENT_DELETE=1 -DSTDC_HEADERS=1 -DHAVE_ASSERT_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_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE__KBHIT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_STAT=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1 -DHAVE__SNPRINTF=1 -DHAVE__UTIME32=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 -D_USE_MATH_DEFINES=1 -DHAVE_LOADLIBRARY_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=1 -DHAVE__COPYSIGN=1 -DHAVE_DECL_SIGNBIT=0 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 -DCLOSEDIR_VOID=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1 -DRETSIGTYPE_IS_VOID=1 -DGNUPLOT_BINARY="pgnuplot"


User-preferences (please do not edit this section):

  EDITOR = C:\Program Files\Octave\tools\wscite\SciTE.exe
  EXEC_PATH = C:\Program Files\Octave\msys\bin;C:\Program Files\Octave\libexec\octave\3.0.3\site\exec\i686-pc-msdosmsvc;C:\Program Files\Octave\libexec\octave\api-v32\site\exec\i686-pc-msdosmsvc;C:\Program Files\Octave\libexec\octave\site\exec\i686-pc-msdosmsvc;C:\Program Files\Octave\libexec\octave\3.0.3\exec\i686-pc-msdosmsvc;C:\Program Files\Octave\bin;C:\Program Files\Octave;C:\Program Files\Silverfrost\FTN95;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\QuickTime\QTSystem\
  IMAGE_PATH = .;C:\Program Files\Octave\share\octave\3.0.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 = pgnuplot
  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 = C:\Documents and Settings\John Hope\.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = C:\Program Files\Octave\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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090909/01fba389/attachment.html 

From efrios at yahoo.com  Wed Sep  9 17:51:25 2009
From: efrios at yahoo.com (Hielos)
Date: Wed, 9 Sep 2009 15:51:25 -0700 (PDT)
Subject: java and jhandles... revisited
Message-ID: <25374487.post@talk.nabble.com>


Hello everyone. I just started using Octave. I want to do a simple GUI for
FEM modelling (I will do it for a class, and afterwards, I dream of
uploading my results to the community). I have used Matlab extensively
before, but now I want to do things the right way: open-source.
Well, the issue is that I have tried to install jhandles for some days now
without any positive results. First of all, I think that the java package
from octave-forge (java-1.2.6.tar.gz) is failing to install. I run

octave:4> pkg install /home/edgar/Programas/Temp/java-1.2.6.tar.gz
octave:5>

Although it seems to install properly (there are no warnings nor anything),
I can't run java commands:

octave:5> l = java_new('java.util.LinkedList')
error: `java_new' undefined near line 5 column 5

So what I thought was that I could probably install it from the terminal.
Therefore, I unpacked the tar.gz file to a folder, and did the following:

----------Block start---------------
~/java-1.2.6$ sudo ./configure
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for mkoctfile... mkoctfile
retrieving compile and link flags from mkoctfile
checking for F77_FUNC... yes
checking for octave... octave
checking for OCTAVE_VERSION in Octave... 3.2.2
checking for octave_config_info('canonical_host_type') in Octave...
x86_64-unknown-linux-gnu
checking for octave_config_info('SHLEXT') in Octave... so
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for strip... strip
checking for java... java
checking for javac... javac
checking for jar... jar
checking for Java version... 1.6.0_0
configure: creating ./config.status
config.status: creating Makeconf
 
  "$prefix" is /home/edgar/octave/java-1.2.6
  "$exec_prefix" is ${prefix}

octave commands will install into the following directories:
   m-files:   /usr/local/share/octave/3.2.2/site/m/octave-forge
   oct-files:
/usr/local/libexec/octave/3.2.2/site/oct/x86_64-unknown-linux-gnu/octave-forge
   binaries: 
/usr/local/libexec/octave/3.2.2/site/exec/x86_64-unknown-linux-gnu
alternatives:
   m-files:   /usr/local/share/octave/3.2.2/site/octave-forge-alternatives/m
   oct-files:
/usr/local/libexec/octave/3.2.2/site/octave-forge-alternatives/oct/x86_64-unknown-linux-gnu

shell commands will install into the following directories:
   binaries:  ${exec_prefix}/bin
   man pages: ${datarootdir}/man
   libraries: ${exec_prefix}/lib
   headers:   ${prefix}/include

octave-forge is configured with
   octave:      octave (version 3.2.2)
   mkoctfile:	mkoctfile for Octave 2
   java:        Java Development Kit not found
----------Block end---------------

As you can see, it fails to find JDK. I can assure that I have installed JDK
(open-jdk and sun-jdk):

$ ls /usr/lib/jvm/
default-java  java-6-openjdk  java-6-sun  java-6-sun-1.6.0.16

One would say: well everything that he has to do is modify ~/.bashrc . I
have done tried it with several flavors, but the most recent is:

$ sudo nano ~/.bashrc
(added in to the file): export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/

I picked this version because of this:

$ locate libjvm.so
/usr/lib/gcj-4.3-90/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/cacao/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server/libjvm.so

So, I come to you dear people trying to get an answer to my pledge. Please,
do help me! Many thanks (my configuration is UBUNTU 9.04, 64 bits, Dell
Optiplex 755)
-- 
View this message in context: http://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25374487.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From g.pannocchia at ing.unipi.it  Thu Sep 10 00:35:56 2009
From: g.pannocchia at ing.unipi.it (Gabriele Pannocchia)
Date: Thu, 10 Sep 2009 07:35:56 +0200
Subject: help for dare has first plus that should (?) be minus in Riccati
	equn
In-Reply-To: <533C97298DD0443EBC5C76A957A384D9@ASPIRE>
References: <533C97298DD0443EBC5C76A957A384D9@ASPIRE>
Message-ID: <1E78F8D8-6AA3-4DE0-8DAC-965310DF9008@ing.unipi.it>

Yes, you are absolutely right.  Appended is a trivial patch.

--- /opt/local/share/octave/packages/control-1.0.11/dare.m	2009-08-31  
15:07:30.000000000 +0200
+++ dare.m	2009-09-10 07:30:05.000000000 +0200
@@ -24,13 +24,13 @@
  ## @iftex
  ## @tex
  ## $$
-## A^TXA - X + A^TXB  (R + B^TXB)^{-1} B^TXA + Q = 0
+## A^TXA - X - A^TXB  (R + B^TXB)^{-1} B^TXA + Q = 0
  ## $$
  ## @end tex
  ## @end iftex
  ## @ifinfo
  ## @example
-## a' x a - x + a' x b (r + b' x b)^(-1) b' x a + q = 0
+## a' x a - x - a' x b (r + b' x b)^(-1) b' x a + q = 0
  ## @end example
  ## @end ifinfo
  ## @noindent

Thanks,
	Gabriele

>
> Bug report for Octave 3.0.3 configured for i686-pc-msdosmsvc
>
> Description:
> -----------
> help for dare has first plus that should (?) be minus in Riccati equn
>
> Repeat-By:
> ---------
>
> help dare
>
> Fix:
> ---
>
>  Just turn first + to a - in equn given in help file
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090910/a3ea5772/attachment.html 

From michael.goffioul at gmail.com  Thu Sep 10 01:32:23 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Thu, 10 Sep 2009 07:32:23 +0100
Subject: java and jhandles... revisited
In-Reply-To: <25374487.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com>
Message-ID: <128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>

On Wed, Sep 9, 2009 at 11:51 PM, Hielos <efrios at yahoo.com> wrote:
> As you can see, it fails to find JDK. I can assure that I have installed JDK
> (open-jdk and sun-jdk):
>
> $ ls /usr/lib/jvm/
> default-java ?java-6-openjdk ?java-6-sun ?java-6-sun-1.6.0.16
>
> One would say: well everything that he has to do is modify ~/.bashrc . I
> have done tried it with several flavors, but the most recent is:
>
> $ sudo nano ~/.bashrc
> (added in to the file): export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
>
> I picked this version because of this:
>
> $ locate libjvm.so
> /usr/lib/gcj-4.3-90/libjvm.so
> /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/cacao/libjvm.so
> /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server/libjvm.so

Can you try to following?

In a shell:
test -d $JAVA_HOME/jre/lib/amd64 && echo "got it!"

In octave:
getenv("JAVA_HOME")

Michael.


From orion at cora.nwra.com  Thu Sep 10 09:28:38 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 10 Sep 2009 08:28:38 -0600
Subject: test_sparse.m fails on ppc64 build
In-Reply-To: <4AA15E47.3000508@cora.nwra.com>
References: <loom.20090903T222522-569@post.gmane.org>	<1252029711.16399.7.camel@sh-t400>	<4AA13E1F.2020209@cora.nwra.com>
	<4AA15E47.3000508@cora.nwra.com>
Message-ID: <4AA90D16.8060706@cora.nwra.com>

On 09/04/2009 12:36 PM, Orion Poplawski wrote:
> On 09/04/2009 10:19 AM, Orion Poplawski wrote:
>> On 09/03/2009 08:01 PM, S?ren Hauberg wrote:
>>> tor, 03 09 2009 kl. 20:27 +0000, skrev Orion Poplawski:
>>>> Running make check on octave 3.2.2 build in Fedora Rawhide fails in
>>>> test_sparse.m on ppc64.
>>>>
>>>> Fixed test scripts:
>>>>      test_args.m ............................................ PASS   26/26
>>>> .....
>>>>      test_sparse.m ..........................................panic: Segmentation
>>>> fault -- stopping myself...
>>>> make[2]: *** [check] Segmentation fault
>
> Okay, the problem seems to be in set_complex_format() in pr-output.cc:
>
>     else if (inf_or_nan || int_only)
>       {
>         int digits = x_max>  x_min ? x_max : x_min;
>         i_fw = digits<= 0 ? 1 : digits;
>         r_fw = i_fw + 1;
>         if (inf_or_nan&&  i_fw<  3)
>           {
>             i_fw = 3;
>             r_fw = 4;
>           }
>         rd = r_fw;
>       }
>
> This is getting called with (x_max=2147483647, x_min=0, r_x=2147483647,
>       inf_or_nan=true, int_only=1, r_fw=@0xfffffff56ec,
> i_fw=@0xfffffff56e8) which yields digits = 2147483647, which is later
> used as the width (os.setw(fmt.f.fw)).  This borks the C++ library.
> Surely this isn't what you want to set digits to.
>
> Similar code is present in other set_ functions in pr-output.cc.

Any thoughts on this?

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

From guenther.palfinger at gmx.net  Thu Sep 10 10:59:57 2009
From: guenther.palfinger at gmx.net (Guenther Palfinger)
Date: Thu, 10 Sep 2009 17:59:57 +0200
Subject: Documentation of norm
Message-ID: <200909101759.57514.guenther.palfinger@gmx.net>

> help norm gives
...
    P = `2'
          Largest singular value of A.
...

The documentation of norm is wrong. For P=2 (default) you get the 
Euclids norm, as to be expected.

octave version: 3.0.1 on ubuntu 9.04

Regards

G?nther




From dfslezak at gmail.com  Thu Sep 10 15:20:30 2009
From: dfslezak at gmail.com (=?ISO-8859-1?Q?Diego_Fern=E1ndez_Slezak?=)
Date: Thu, 10 Sep 2009 16:20:30 -0400
Subject: Compiling error - Bug at configure.in
Message-ID: <cfd0f9eb0909101320v7d000b9j68c87b6d13c1472e@mail.gmail.com>

Hello,

Today I sent an email to the help list asking for help configuring
octave without X11.
Finally I have solved the problem.

I found that the configure (line 7446) has a bug.
That line tests the variable $have_x
This line corresponds to the line 258 of the file configure.in

In the macro AC_PATH_X, the variable $have_x is always defined
(yes/no/disabled), so the test always is true, and HAVE_X_WINDOWS is
always defined.

The solution is to test whether $no_x is defined, or check if $have_x
equals "yes".

Bye.
Diego

From carlo.defalco at gmail.com  Fri Sep 11 03:30:41 2009
From: carlo.defalco at gmail.com (Carlo de Falco)
Date: Fri, 11 Sep 2009 10:30:41 +0200
Subject: Documentation of norm
In-Reply-To: <mailman.37.1252602207.17963.bug-octave@octave.org>
References: <mailman.37.1252602207.17963.bug-octave@octave.org>
Message-ID: <00E82626-8CB5-470E-A2BB-A211619EB8BF@gmail.com>


On 10 Sep 2009, at 19:03, bug-octave-request at octave.org wrote:

>>
>> help norm gives
> ...
>   P = `2'
>         Largest singular value of A.
> ...
>
> The documentation of norm is wrong. For P=2 (default) you get the
> Euclids norm, as to be expected.
>
> octave version: 3.0.1 on ubuntu 9.04
>
> Regards
>
> G?nther
>

The matrix norm induced by the Euclid vector norm is the largest  
singular value, see, e.g., Trefethen and Bau, Numerical Linear  
Algebra, Chap. I

For matrices with only one row or one column (i.e. a vector)   
computing the norm as

sqrt (sum (v.^2))

or as

max (svd (v))

gives the same result:

 >> a = rand (5, 1)
a =

   0.67232
   0.67919
   0.16876
   0.73998
   0.54648

 >> svd(a')
ans =  1.3372
 >> norm (a')
ans =  1.3372
 >> max( svd(a))
ans =  1.3372
 >> norm(a)
ans =  1.3372

c.


From highegg at gmail.com  Fri Sep 11 03:34:48 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 11 Sep 2009 10:34:48 +0200
Subject: Documentation of norm
In-Reply-To: <200909101759.57514.guenther.palfinger@gmx.net>
References: <200909101759.57514.guenther.palfinger@gmx.net>
Message-ID: <69d8d540909110134p272268adm336cc102818df0bb@mail.gmail.com>

On Thu, Sep 10, 2009 at 5:59 PM, Guenther Palfinger
<guenther.palfinger at gmx.net> wrote:
>> help norm gives
> ...
> ? ?P = `2'
> ? ? ? ? ?Largest singular value of A.
> ...
>
> The documentation of norm is wrong. For P=2 (default) you get the
> Euclids norm, as to be expected.
>
> octave version: 3.0.1 on ubuntu 9.04
>
> Regards
>
> G?nther
>

This is a definition for the general matrix case. It should be
consistent with the vector case, as it should be for any other 1<= p
<= Inf. The vector definitions are given below, at least in 3.2.x.

hth

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


From dasergatskov at gmail.com  Fri Sep 11 09:03:02 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Fri, 11 Sep 2009 09:03:02 -0500
Subject: test_sparse.m fails on ppc64 build
In-Reply-To: <4AA90D16.8060706@cora.nwra.com>
References: <loom.20090903T222522-569@post.gmane.org>
	<1252029711.16399.7.camel@sh-t400> <4AA13E1F.2020209@cora.nwra.com>
	<4AA15E47.3000508@cora.nwra.com> <4AA90D16.8060706@cora.nwra.com>
Message-ID: <892b16670909110703g51a9164albace15fc5672e245@mail.gmail.com>

On Thu, Sep 10, 2009 at 9:28 AM, Orion Poplawski <orion at cora.nwra.com> wrote:

>> This is getting called with (x_max=2147483647, x_min=0, r_x=2147483647,
>> ? ? ? inf_or_nan=true, int_only=1, r_fw=@0xfffffff56ec,
>> i_fw=@0xfffffff56e8) which yields digits = 2147483647, which is later
>> used as the width (os.setw(fmt.f.fw)). ?This borks the C++ library.
>> Surely this isn't what you want to set digits to.
>>
>> Similar code is present in other set_ functions in pr-output.cc.
>
> Any thoughts on this?
>

Did you try compiling it on F11? The fact that it fails only on one platform
is very suspicious. I just noticed the thread on fedora-devel mainling list:

https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00323.html

("GCC update breaks PPC?")

With a further reference to

http://article.gmane.org/gmane.linux.redhat.fedora.devel/120454
("GCC var-tracking-assignments: testing and bug reports appreciated")

Perhaps this is relevant.

> --
> Orion Poplawski

Sincerely,

Dmitri.
--


From orion at cora.nwra.com  Fri Sep 11 10:55:39 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 11 Sep 2009 09:55:39 -0600
Subject: test_sparse.m fails on ppc64 build
In-Reply-To: <892b16670909110703g51a9164albace15fc5672e245@mail.gmail.com>
References: <loom.20090903T222522-569@post.gmane.org>	
	<1252029711.16399.7.camel@sh-t400>
	<4AA13E1F.2020209@cora.nwra.com>	 <4AA15E47.3000508@cora.nwra.com>
	<4AA90D16.8060706@cora.nwra.com>
	<892b16670909110703g51a9164albace15fc5672e245@mail.gmail.com>
Message-ID: <4AAA72FB.5060600@cora.nwra.com>

On 09/11/2009 08:03 AM, Dmitri A. Sergatskov wrote:
> On Thu, Sep 10, 2009 at 9:28 AM, Orion Poplawski<orion at cora.nwra.com>  wrote:
>
>>> This is getting called with (x_max=2147483647, x_min=0, r_x=2147483647,
>>>        inf_or_nan=true, int_only=1, r_fw=@0xfffffff56ec,
>>> i_fw=@0xfffffff56e8) which yields digits = 2147483647, which is later
>>> used as the width (os.setw(fmt.f.fw)).  This borks the C++ library.
>>> Surely this isn't what you want to set digits to.
>>>
>>> Similar code is present in other set_ functions in pr-output.cc.
>>
>> Any thoughts on this?
>>
>
> Did you try compiling it on F11? The fact that it fails only on one platform
> is very suspicious. I just noticed the thread on fedora-devel mainling list:

I've seen plenty of cases where coding problems where only exposed on 
the PPC platform.  In any case:

- My failed build was before the GCC change went into effect.
- Fails in the same place on F11. 
http://koji.fedoraproject.org/koji/watchlogs?taskID=1671216
- I believe my analysis above of the problem is correct.  Has anyone 
looked it?



-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

From efrios at yahoo.com  Fri Sep 11 10:02:51 2009
From: efrios at yahoo.com (Hielos)
Date: Fri, 11 Sep 2009 08:02:51 -0700 (PDT)
Subject: java and jhandles... revisited
In-Reply-To: <128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
Message-ID: <25402674.post@talk.nabble.com>


Michael, this is the result (positive):

$ test -d $JAVA_HOME/jre/lib/amd64 && echo "got it"
got it

I also ran the octave command:

octave:1> getenv("JAVA_HOME")
ans = /usr/lib/jvm/java-6-openjdk/


Michael Goffioul-2 wrote:
> 
> Can you try to following?
> 
> In a shell:
> test -d $JAVA_HOME/jre/lib/amd64 && echo "got it!"
> 
> In octave:
> getenv("JAVA_HOME")
> 
> Michael.
> 
> _______________________________________________
> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25402674.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From michael.goffioul at gmail.com  Fri Sep 11 11:47:18 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Fri, 11 Sep 2009 17:47:18 +0100
Subject: java and jhandles... revisited
In-Reply-To: <25402674.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
Message-ID: <128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>

It seems your environment is correct. I'm a little bit puzzled, as it *should*
work. In this case, I think the best would be to unpack the package source,
go into src/ subdir, run ./configure manually and check config.log for anything
relevant (or try to see why the configure script fails to detect your JDK).

Michael.


On Fri, Sep 11, 2009 at 4:02 PM, Hielos <efrios at yahoo.com> wrote:
>
> Michael, this is the result (positive):
>
> $ test -d $JAVA_HOME/jre/lib/amd64 && echo "got it"
> got it
>
> I also ran the octave command:
>
> octave:1> getenv("JAVA_HOME")
> ans = /usr/lib/jvm/java-6-openjdk/
>
>
> Michael Goffioul-2 wrote:
>>
>> Can you try to following?
>>
>> In a shell:
>> test -d $JAVA_HOME/jre/lib/amd64 && echo "got it!"
>>
>> In octave:
>> getenv("JAVA_HOME")
>>
>> Michael.
>>
>> _______________________________________________
>> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25402674.html
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>

From efrios at yahoo.com  Fri Sep 11 13:51:05 2009
From: efrios at yahoo.com (Hielos)
Date: Fri, 11 Sep 2009 11:51:05 -0700 (PDT)
Subject: java and jhandles... revisited
In-Reply-To: <128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
Message-ID: <25406474.post@talk.nabble.com>


Well, I am sending you the config.log which I obtained after unpacking the
java-1.2.6.tar.gz file into a folder I called "java-1.2.6" (as you may know
there is a 'configure' file in the root folder and another one within 'src'
the root folder):

java-1.2.6/src$  sudo ./configure
// MANY LINES OF RESULT //
http://www.nabble.com/file/p25406474/config.output config.output 

java-1.2.6/src$ gedit config.log
// SEE ATTACHED FILE // http://www.nabble.com/file/p25406474/config.log
config.log 

However, I don't know what to do next (I am not very Linux-skilled). As you
can see, I also attached the './configure' prompt output just in case that
it helps...


Michael Goffioul-2 wrote:
> 
> It seems your environment is correct. I'm a little bit puzzled, as it
> *should*
> work. In this case, I think the best would be to unpack the package
> source,
> go into src/ subdir, run ./configure manually and check config.log for
> anything
> relevant (or try to see why the configure script fails to detect your
> JDK).
> 
> Michael.
> _______________________________________________
> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25406474.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From soren at hauberg.org  Fri Sep 11 14:58:58 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Fri, 11 Sep 2009 21:58:58 +0200
Subject: java and jhandles... revisited
In-Reply-To: <25406474.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
Message-ID: <1252699138.4423.4.camel@sh-t400>

fre, 11 09 2009 kl. 11:51 -0700, skrev Hielos:
> Well, I am sending you the config.log which I obtained after unpacking the
> java-1.2.6.tar.gz file into a folder I called "java-1.2.6" (as you may know
> there is a 'configure' file in the root folder and another one within 'src'
> the root folder):

The following patch fixes things for me on Ubuntu. I can't compile the
package, but that seems to be an issue with my setup.

S?ren

--- configure.base	2009-06-07 12:44:44.000000000 +0200
+++ /home/sh/Skrivebord/java-1.2.6/src/configure.base	2009-09-11
21:48:18.000000000 +0200
@@ -343,6 +343,9 @@
             # you need to explicitely set the include path
             JAVA_INCS="-I${JAVA_HOME}/include"
             HAVE_JAVA=yes
+          # This is the Debian default path
+          elif test -d "/usr/lib/jvm/default-java"; then
+            JAVA_HOME=/usr/lib/jvm/default-java
           else
             JAVA_HOME=/usr/lib/jvm
           fi



From michael.goffioul at gmail.com  Fri Sep 11 15:13:56 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Fri, 11 Sep 2009 21:13:56 +0100
Subject: java and jhandles... revisited
In-Reply-To: <25406474.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
Message-ID: <128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>

Looking at your config.log (near the end), you'll see that the JAVA_HOME
variable is wrong (/usr/lib/jvm). This may indicate that the configure script
does not have it correctly defined: it looks like the configure script detects
it as empty and use the default value.

This might be due to the "sudo" call. I'm not sure this inherit the environment
variables from the parent shell.

Michael.


On Fri, Sep 11, 2009 at 7:51 PM, Hielos <efrios at yahoo.com> wrote:
>
> Well, I am sending you the config.log which I obtained after unpacking the
> java-1.2.6.tar.gz file into a folder I called "java-1.2.6" (as you may know
> there is a 'configure' file in the root folder and another one within 'src'
> the root folder):
>
> java-1.2.6/src$ ?sudo ./configure
> // MANY LINES OF RESULT //
> http://www.nabble.com/file/p25406474/config.output config.output
>
> java-1.2.6/src$ gedit config.log
> // SEE ATTACHED FILE // http://www.nabble.com/file/p25406474/config.log
> config.log
>
> However, I don't know what to do next (I am not very Linux-skilled). As you
> can see, I also attached the './configure' prompt output just in case that
> it helps...
>
>
> Michael Goffioul-2 wrote:
>>
>> It seems your environment is correct. I'm a little bit puzzled, as it
>> *should*
>> work. In this case, I think the best would be to unpack the package
>> source,
>> go into src/ subdir, run ./configure manually and check config.log for
>> anything
>> relevant (or try to see why the configure script fails to detect your
>> JDK).
>>
>> Michael.
>> _______________________________________________
>> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25406474.html
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>


From rabuter at eso.org  Sat Sep 12 05:59:26 2009
From: rabuter at eso.org (Roberto Abuter)
Date: Sat, 12 Sep 2009 12:59:26 +0200
Subject: interp1 -  bug 
Message-ID: <4AAB7F0E.2060902@eso.org>

Hi :

    I am using the most basic form of interp1 in both matlab and octave.
    To my surprise interp1 in octave (3.0.2)  is producing some very 
strange results on my data.

    I have a set of two vectors X, Y where X has a sawtooth shape (4 
repetitions) and Y has 4 repetitions of an increasing/decreasing 
amplitude sine wave.
    to start very simple I just check the interp1 engine by making :
   
    XI = X;
    YI = interp1(X,Y,XI)


    to my surprise, the result YI  comes out not identical to Y .  
   
    well, if I try to interp1 with XI as my target grid ( a regular one 
) I get absolutely wierd results.

hope someone can give me a hint.

many thanks in advance,

Roberto Abuter
VLTI project-
E.S.O ( Europeam Southern Observatory)

   


From rabuter at eso.org  Sat Sep 12 06:07:18 2009
From: rabuter at eso.org (Roberto Abuter)
Date: Sat, 12 Sep 2009 13:07:18 +0200
Subject: interp1 -  bug 
Message-ID: <4AAB80E6.7040106@eso.org>

Hi :

   I am using the most basic form of interp1 in both matlab and octave.
   To my surprise interp1 in octave (3.0.2)  is producing some very 
strange results on my data.

   I have a set of two vectors X, Y where X has a sawtooth shape (4 
repetitions) and Y has 4 repetitions of an increasing/decreasing 
amplitude sine wave.
   to start very simple I just check the interp1 engine by making :
  
   XI = X;
   YI = interp1(X,Y,XI)


   to my surprise, the result YI  comes out not identical to Y .  
  
   well, if I try to interp1 with XI as my target grid ( a regular one 
) I get absolutely wierd results.

hope someone can give me a hint.

many thanks in advance,

Roberto Abuter
VLTI project-
E.S.O ( Europeam Southern Observatory)

  



From william.zink at juno.com  Sat Sep 12 15:45:33 2009
From: william.zink at juno.com (bzink)
Date: Sat, 12 Sep 2009 13:45:33 -0700 (PDT)
Subject: Installation of package java 1.2.6 fails with latest Windows binary
Message-ID: <25418093.post@talk.nabble.com>


The link below is a 'diary' log of my latest unsuccessful attempt to install
the 'java' package.  I reported a similar problem with the 3.2.0 sourceforge
binary.  Does anyone have an idea what the problem might be?  Thanks.

http://www.nabble.com/file/p25418093/java_pkg_install_failure.txt
java_pkg_install_failure.txt 

BZ
-- 
View this message in context: http://www.nabble.com/Installation-of-package-java-1.2.6-fails-with-latest-Windows-binary-tp25418093p25418093.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From tmacchant at yahoo.co.jp  Sat Sep 12 17:10:20 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Sun, 13 Sep 2009 07:10:20 +0900 (JST)
Subject: Installation of package java 1.2.6 fails with latest Windows
	binary
In-Reply-To: <25418093.post@talk.nabble.com>
Message-ID: <20090912221020.11602.qmail@web3804.mail.bbt.yahoo.co.jp>

Hello

--- bzink wrote:

> 
> The link below is a 'diary' log of my latest unsuccessful attempt to install
> the 'java' package.  I reported a similar problem with the 3.2.0 sourceforge
> binary.  Does anyone have an idea what the problem might be?  Thanks.
> 
> http://www.nabble.com/file/p25418093/java_pkg_install_failure.txt
> java_pkg_install_failure.txt 
Please see the Michael's suggestion for jhandle.

http://www.nabble.com/Octave-3.2.0-mingw-jhandles-td24024734.html

BTW.

This topic completely is in the category of octave-forge package.
The more appropriate place for this issue is octave-dev at lists.sourceforge.net (ML for octave-forge).
Thus my reply is also cc. to  octave-dev at lists.sourceforge.net.

Please use octave-dev at lists.sourceforge.net from the next time if you ask about that can be downloaded
from octave-forge sourceforge.net.

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From ferni.martin at gmail.com  Sun Sep 13 10:19:08 2009
From: ferni.martin at gmail.com (Fernando Martin)
Date: Sun, 13 Sep 2009 17:19:08 +0200
Subject: figure windows cannot be closed from the Octave command line
Message-ID: <85B83DEC-8911-4D55-B8DA-A6210EBE3400@gmail.com>

Hello,

I have just installed Octave 3.2.2 from octave-3.2.2-i386.dmg (i386- 
apple-darwin8.11.1) in a clean installation of Mac OS X Snow Leopard.  
I have just drag octave.app and gnuplot.app to the Application folder.

The problem is that I cannot close the plot windows using the command  
"close all". For example, if I type:

plot([1:10]);
close all;

The aquaterm window remains there and I cannot close it from the  
Octave command line.

Also, figures cannot be open neither using the command "figure".

Best regards.

From bpabbott at mac.com  Sun Sep 13 10:53:13 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sun, 13 Sep 2009 11:53:13 -0400
Subject: figure windows cannot be closed from the Octave command line
In-Reply-To: <85B83DEC-8911-4D55-B8DA-A6210EBE3400@gmail.com>
References: <85B83DEC-8911-4D55-B8DA-A6210EBE3400@gmail.com>
Message-ID: <2663D3F1-A097-4D4D-A56B-70F45E394929@mac.com>


On Sep 13, 2009, at 11:19 AM, Fernando Martin wrote:

> Hello,
>
> I have just installed Octave 3.2.2 from octave-3.2.2-i386.dmg (i386-
> apple-darwin8.11.1) in a clean installation of Mac OS X Snow Leopard.
> I have just drag octave.app and gnuplot.app to the Application folder.
>
> The problem is that I cannot close the plot windows using the command
> "close all". For example, if I type:
>
> plot([1:10]);
> close all;
>
> The aquaterm window remains there and I cannot close it from the
> Octave command line.
>
> Also, figures cannot be open neither using the command "figure".
>
> Best regards.

This is a gnuplot/aquaterm limitation.

If you switch to x11 you'll be able to close the windows.

You can do that by (1) starting x11 and (2) typing 'setenv ("GNUTERM",  
"x11")' at octave's prompt.

Ben



From efrios at yahoo.com  Sun Sep 13 20:48:28 2009
From: efrios at yahoo.com (Hielos)
Date: Sun, 13 Sep 2009 18:48:28 -0700 (PDT)
Subject: java and jhandles... revisited
In-Reply-To: <128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
Message-ID: <25429191.post@talk.nabble.com>


Michael, I did the following:

   $ sudo su
   $ gedit /root/.bashrc

Then I modified the '.bashrc' file to include the lines:

   export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
   export JAVA_ARCH=amd64

After that:

   $ cd /java-1.2.6/src
   $ ./configure

And I got the same JDK issue as before. I also checked the 'config.log'
file, and it shows 

   ...
   JAVA_HOME='/usr/lib/jvm/java-6-openjdk'
   ...
http://www.nabble.com/file/p25429191/config.log config.log 

It is a shame, but I cannot spend more time trying to figure this out.
Thanks a lot for you help. I hope that someone can fix it eventually.
Godspeed.



Michael Goffioul-2 wrote:
> 
> Looking at your config.log (near the end), you'll see that the JAVA_HOME
> variable is wrong (/usr/lib/jvm). This may indicate that the configure
> script
> does not have it correctly defined: it looks like the configure script
> detects
> it as empty and use the default value.
> 
> This might be due to the "sudo" call. I'm not sure this inherit the
> environment
> variables from the parent shell.
> 
> Michael.
> 
> _______________________________________________
> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25429191.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From efrios at yahoo.com  Sun Sep 13 20:57:16 2009
From: efrios at yahoo.com (Hielos)
Date: Sun, 13 Sep 2009 18:57:16 -0700 (PDT)
Subject: java and jhandles... revisited
In-Reply-To: <1252699138.4423.4.camel@sh-t400>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com> <1252699138.4423.4.camel@sh-t400>
Message-ID: <25429259.post@talk.nabble.com>


Sorry, mate, I did as you proposed, but it did not work for me :) . I will
have to live without octave (or octave-java at least). Thanks for your help
;)


S?ren Hauberg wrote:
> 
> fre, 11 09 2009 kl. 11:51 -0700, skrev Hielos:
>> Well, I am sending you the config.log which I obtained after unpacking
>> the
>> java-1.2.6.tar.gz file into a folder I called "java-1.2.6" (as you may
>> know
>> there is a 'configure' file in the root folder and another one within
>> 'src'
>> the root folder):
> 
> The following patch fixes things for me on Ubuntu. I can't compile the
> package, but that seems to be an issue with my setup.
> 
> S?ren
> 
> --- configure.base	2009-06-07 12:44:44.000000000 +0200
> +++ /home/sh/Skrivebord/java-1.2.6/src/configure.base	2009-09-11
> 21:48:18.000000000 +0200
> @@ -343,6 +343,9 @@
>              # you need to explicitely set the include path
>              JAVA_INCS="-I${JAVA_HOME}/include"
>              HAVE_JAVA=yes
> +          # This is the Debian default path
> +          elif test -d "/usr/lib/jvm/default-java"; then
> +            JAVA_HOME=/usr/lib/jvm/default-java
>            else
>              JAVA_HOME=/usr/lib/jvm
>            fi
> 
> 
> _______________________________________________
> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25429259.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.



From ferni.martin at gmail.com  Sun Sep 13 14:14:02 2009
From: ferni.martin at gmail.com (ferni.martin at gmail.com)
Date: Sun, 13 Sep 2009 19:14:02 +0000
Subject: figure windows cannot be closed from the Octave command line
In-Reply-To: <2663D3F1-A097-4D4D-A56B-70F45E394929@mac.com>
Message-ID: <000e0cdfda1e2488ce04737a5a89@google.com>

Thanks.

Fernando

On Sep 13, 2009 5:53pm, Ben Abbott <bpabbott at mac.com> wrote:


> On Sep 13, 2009, at 11:19 AM, Fernando Martin wrote:




> Hello,



> I have just installed Octave 3.2.2 from octave-3.2.2-i386.dmg (i386-

> apple-darwin8.11.1) in a clean installation of Mac OS X Snow Leopard.

> I have just drag octave.app and gnuplot.app to the Application folder.



> The problem is that I cannot close the plot windows using the command

> "close all". For example, if I type:



> plot([1:10]);

> close all;



> The aquaterm window remains there and I cannot close it from the

> Octave command line.



> Also, figures cannot be open neither using the command "figure".



> Best regards.




> This is a gnuplot/aquaterm limitation.



> If you switch to x11 you'll be able to close the windows.



> You can do that by (1) starting x11 and (2) typing 'setenv  
> ("GNUTERM", "x11")' at octave's prompt.



> Ben






-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090913/a91eae7d/attachment.html 

From michael.goffioul at gmail.com  Mon Sep 14 01:24:26 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Mon, 14 Sep 2009 07:24:26 +0100
Subject: java and jhandles... revisited
In-Reply-To: <25429191.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
	<25429191.post@talk.nabble.com>
Message-ID: <128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>

You shouldn't define JAVA_ARCH yourself. The configure script won't
work correctly if you do (Ijust realized that).

Michael.


On Mon, Sep 14, 2009 at 2:48 AM, Hielos <efrios at yahoo.com> wrote:
>
> Michael, I did the following:
>
> ? $ sudo su
> ? $ gedit /root/.bashrc
>
> Then I modified the '.bashrc' file to include the lines:
>
> ? export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
> ? export JAVA_ARCH=amd64
>
> After that:
>
> ? $ cd /java-1.2.6/src
> ? $ ./configure
>
> And I got the same JDK issue as before. I also checked the 'config.log'
> file, and it shows
>
> ? ...
> ? JAVA_HOME='/usr/lib/jvm/java-6-openjdk'
> ? ...
> http://www.nabble.com/file/p25429191/config.log config.log
>
> It is a shame, but I cannot spend more time trying to figure this out.
> Thanks a lot for you help. I hope that someone can fix it eventually.
> Godspeed.
>
>
>
> Michael Goffioul-2 wrote:
>>
>> Looking at your config.log (near the end), you'll see that the JAVA_HOME
>> variable is wrong (/usr/lib/jvm). This may indicate that the configure
>> script
>> does not have it correctly defined: it looks like the configure script
>> detects
>> it as empty and use the default value.
>>
>> This might be due to the "sudo" call. I'm not sure this inherit the
>> environment
>> variables from the parent shell.
>>
>> Michael.
>>
>> _______________________________________________
>> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25429191.html
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>


From efrios at yahoo.com  Mon Sep 14 15:50:34 2009
From: efrios at yahoo.com (Hielos)
Date: Mon, 14 Sep 2009 13:50:34 -0700 (PDT)
Subject: java and jhandles... revisited
In-Reply-To: <128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
	<25429191.post@talk.nabble.com>
	<128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>
Message-ID: <25443402.post@talk.nabble.com>


Now the './configure' command works, but 'make' gives an error 1:
$ sudo su
$ cd java-1.2.6/src
$ ./configure
...
octave-forge is configured with
   octave:      octave (version 3.2.2)
   mkoctfile:	mkoctfile for Octave 2
   java:        yes
...
http://www.nabble.com/file/p25443402/config.log config.log 

$ make
http://www.nabble.com/file/p25443402/make.output make.output 

---Some useful translations---
conversi?n obsoleta de una constante de cadena a ?char*? = obsolete string
conversion to 'char*'
no tiene un miembro llamado = doesn't have a member called
no es un miembro de = is not a member of
http://www.nabble.com/file/p25443402/make.trans make.trans 
---End of translations---


Michael Goffioul-2 wrote:
> 
> You shouldn't define JAVA_ARCH yourself. The configure script won't
> work correctly if you do (Ijust realized that).
> 
> Michael.
> _______________________________________________
> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25443402.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.



From michael.goffioul at gmail.com  Mon Sep 14 16:01:10 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Mon, 14 Sep 2009 22:01:10 +0100
Subject: java and jhandles... revisited
In-Reply-To: <25443402.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
	<25429191.post@talk.nabble.com>
	<128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>
	<25443402.post@talk.nabble.com>
Message-ID: <128f38bd0909141401i32656342h4e5a1da3ce72628e@mail.gmail.com>

This is already fixed in SVN, see
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/java/src/__java__.cc?r1=5371&r2=6098
In summary:
- add "include <iostream>"
- replace capacity() with length()
- replace qsort() with sort()

Michael.


On Mon, Sep 14, 2009 at 9:50 PM, Hielos <efrios at yahoo.com> wrote:
>
> Now the './configure' command works, but 'make' gives an error 1:
> $ sudo su
> $ cd java-1.2.6/src
> $ ./configure
> ...
> octave-forge is configured with
> ? octave: ? ? ?octave (version 3.2.2)
> ? mkoctfile: ? mkoctfile for Octave 2
> ? java: ? ? ? ?yes
> ...
> http://www.nabble.com/file/p25443402/config.log config.log
>
> $ make
> http://www.nabble.com/file/p25443402/make.output make.output
>
> ---Some useful translations---
> conversi?n obsoleta de una constante de cadena a ?char*? = obsolete string
> conversion to 'char*'
> no tiene un miembro llamado = doesn't have a member called
> no es un miembro de = is not a member of
> http://www.nabble.com/file/p25443402/make.trans make.trans
> ---End of translations---
>
>
> Michael Goffioul-2 wrote:
>>
>> You shouldn't define JAVA_ARCH yourself. The configure script won't
>> work correctly if you do (Ijust realized that).
>>
>> Michael.
>> _______________________________________________
>> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25443402.html
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>


From efrios at yahoo.com  Mon Sep 14 18:03:09 2009
From: efrios at yahoo.com (Hielos)
Date: Mon, 14 Sep 2009 16:03:09 -0700 (PDT)
Subject: java and jhandles... revisited
In-Reply-To: <128f38bd0909141401i32656342h4e5a1da3ce72628e@mail.gmail.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
	<25429191.post@talk.nabble.com>
	<128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>
	<25443402.post@talk.nabble.com>
	<128f38bd0909141401i32656342h4e5a1da3ce72628e@mail.gmail.com>
Message-ID: <25445171.post@talk.nabble.com>


Fantastic! I have octave-java installed.

  octave:1> help java_new

works. But

  octave:1> l = java_new('java.util.LinkedList')
  error: /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/client/libjvm.so: cannot
open shared object file: No such file or directory

So what I did was:
  $ mkdir /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/client/
  $ ln -s /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/amd64/server/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/client/libjvm.so

and now
  octave:1> l = java_new('java.util.LinkedList')
  l =

  <Java object: java.util.LinkedList>
:jumping:

Therefore, I am trying to install jhandles:
  $ ./configure
  ...
  octave-forge is configured with
     octave:      octave (version 3.2.2)
     mkoctfile:	mkoctfile for Octave 2
     java:        Can not find jogl.jar
     octave.jar:	/usr/local/share/octave/packages/java-1.2.6/octave.jar
     jogl.jar:    jogl.jar
  ...
http://www.nabble.com/file/p25445171/config.log config.log 

It seems rather familiar, but I don't know how to solve it. Please, help!



Michael Goffioul-2 wrote:
> 
> This is already fixed in SVN, see
> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/java/src/__java__.cc?r1=5371&r2=6098
> In summary:
> - add "include <iostream>"
> - replace capacity() with length()
> - replace qsort() with sort()
> 
> Michael.
> ______________________________________________
> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25445171.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From michael.goffioul at gmail.com  Tue Sep 15 02:55:34 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Tue, 15 Sep 2009 08:55:34 +0100
Subject: java and jhandles... revisited
In-Reply-To: <25445171.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com> <25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
	<25429191.post@talk.nabble.com>
	<128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>
	<25443402.post@talk.nabble.com>
	<128f38bd0909141401i32656342h4e5a1da3ce72628e@mail.gmail.com>
	<25445171.post@talk.nabble.com>
Message-ID: <128f38bd0909150055h65f2270dt1127a39325c7f213@mail.gmail.com>

On Tue, Sep 15, 2009 at 12:03 AM, Hielos <efrios at yahoo.com> wrote:
>
> Fantastic! I have octave-java installed.
>
> ?octave:1> help java_new
>
> works. But
>
> ?octave:1> l = java_new('java.util.LinkedList')
> ?error: /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/client/libjvm.so: cannot
> open shared object file: No such file or directory
>
> So what I did was:
> ?$ mkdir /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/client/
> ?$ ln -s /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/amd64/server/libjvm.so
> /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/client/libjvm.so
>
> and now
> ?octave:1> l = java_new('java.util.LinkedList')
> ?l =
>
> ?<Java object: java.util.LinkedList>
> :jumping:
>
> Therefore, I am trying to install jhandles:
> ?$ ./configure
> ?...
> ?octave-forge is configured with
> ? ? octave: ? ? ?octave (version 3.2.2)
> ? ? mkoctfile: mkoctfile for Octave 2
> ? ? java: ? ? ? ?Can not find jogl.jar
> ? ? octave.jar: ? ? ? ?/usr/local/share/octave/packages/java-1.2.6/octave.jar
> ? ? jogl.jar: ? ?jogl.jar
> ?...
> http://www.nabble.com/file/p25445171/config.log config.log
>
> It seems rather familiar, but I don't know how to solve it. Please, help!

Currently, the configure script expects to find JOGL jar files somewhere in
your PATH. So make sure this is the case.

Moreover, you'll also need to
add the path where JOGL shared libs (.so) are located to your
LD_LIBRARY_PATH variable. Although you probably don't need it for
configure/make stages.

Michael.


From thorsten.meyier at gmx.de  Tue Sep 15 07:51:55 2009
From: thorsten.meyier at gmx.de (Thorsten Meyer)
Date: Tue, 15 Sep 2009 14:51:55 +0200
Subject: bug in oct-cmplx.h?
Message-ID: <h8o2lb$pns$1@ger.gmane.org>

A have just tried to compile the present tip (85dd3a2c9355) and get the error
below. Apparently, FLOAT_TRUNCATE is not declared there. However, I do find a
definition of FLOAT_TRUNCATE as part of UGLY_DEFS in Makeconf (is says
-DFLOAT_TRUNCATE= ). So, why isn't this definition propagated down?

Can someone help with this?

Thanks

Thorsten

...
ccache g++ -c    -I. -I.. -I../liboctave -I../src -I../libcruft/misc
-DHAVE_CONFIG_H -mieee-fp -I/usr/include/freetype2   -Wall -W -Wshadow
-Wold-style-cast -Wformat -O2 -pthread oct-locbuf.cc -o oct-locbuf.o
In file included from oct-locbuf.h:28,
                 from oct-locbuf.cc:29:
oct-cmplx.h: In function ?bool operator>(const std::complex<_Tp>&, const
std::complex<_Tp>&)?:
oct-cmplx.h:78: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:78: error: expected `;' before ?const?
oct-cmplx.h:78: error: ?ax? was not declared in this scope
oct-cmplx.h:78: error: ?bx? was not declared in this scope
oct-cmplx.h:78: error: expected `;' before ?const?
oct-cmplx.h:78: error: ?ay? was not declared in this scope
oct-cmplx.h:78: error: ?by? was not declared in this scope
oct-cmplx.h: In function ?bool operator>(const std::complex<_Tp>&, T)?:
oct-cmplx.h:78: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:78: error: expected `;' before ?const?
oct-cmplx.h:78: error: ?ax? was not declared in this scope
oct-cmplx.h:78: error: expected `;' before ?const?
oct-cmplx.h:78: error: ?ay? was not declared in this scope
oct-cmplx.h: In function ?bool operator>(T, const std::complex<_Tp>&)?:
oct-cmplx.h:78: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:78: error: expected `;' before ?const?
oct-cmplx.h:78: error: ?bx? was not declared in this scope
oct-cmplx.h:78: error: expected `;' before ?const?
oct-cmplx.h:78: error: ?by? was not declared in this scope
oct-cmplx.h: In function ?bool operator<(const std::complex<_Tp>&, const
std::complex<_Tp>&)?:
oct-cmplx.h:79: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:79: error: expected `;' before ?const?
oct-cmplx.h:79: error: ?ax? was not declared in this scope
oct-cmplx.h:79: error: ?bx? was not declared in this scope
oct-cmplx.h:79: error: expected `;' before ?const?
oct-cmplx.h:79: error: ?ay? was not declared in this scope
oct-cmplx.h:79: error: ?by? was not declared in this scope
oct-cmplx.h: In function ?bool operator<(const std::complex<_Tp>&, T)?:
oct-cmplx.h:79: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:79: error: expected `;' before ?const?
oct-cmplx.h:79: error: ?ax? was not declared in this scope
oct-cmplx.h:79: error: expected `;' before ?const?
oct-cmplx.h:79: error: ?ay? was not declared in this scope
oct-cmplx.h: In function ?bool operator<(T, const std::complex<_Tp>&)?:
oct-cmplx.h:79: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:79: error: expected `;' before ?const?
oct-cmplx.h:79: error: ?bx? was not declared in this scope
oct-cmplx.h:79: error: expected `;' before ?const?
oct-cmplx.h:79: error: ?by? was not declared in this scope
oct-cmplx.h: In function ?bool operator<=(const std::complex<_Tp>&, const
std::complex<_Tp>&)?:
oct-cmplx.h:80: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:80: error: expected `;' before ?const?
oct-cmplx.h:80: error: ?ax? was not declared in this scope
oct-cmplx.h:80: error: ?bx? was not declared in this scope
oct-cmplx.h:80: error: expected `;' before ?const?
oct-cmplx.h:80: error: ?ay? was not declared in this scope
oct-cmplx.h:80: error: ?by? was not declared in this scope
oct-cmplx.h: In function ?bool operator<=(const std::complex<_Tp>&, T)?:
oct-cmplx.h:80: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:80: error: expected `;' before ?const?
oct-cmplx.h:80: error: ?ax? was not declared in this scope
oct-cmplx.h:80: error: expected `;' before ?const?
oct-cmplx.h:80: error: ?ay? was not declared in this scope
oct-cmplx.h: In function ?bool operator<=(T, const std::complex<_Tp>&)?:
oct-cmplx.h:80: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:80: error: expected `;' before ?const?
oct-cmplx.h:80: error: ?bx? was not declared in this scope
oct-cmplx.h:80: error: expected `;' before ?const?
oct-cmplx.h:80: error: ?by? was not declared in this scope
oct-cmplx.h: In function ?bool operator>=(const std::complex<_Tp>&, const
std::complex<_Tp>&)?:
oct-cmplx.h:81: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:81: error: expected `;' before ?const?
oct-cmplx.h:81: error: ?ax? was not declared in this scope
oct-cmplx.h:81: error: ?bx? was not declared in this scope
oct-cmplx.h:81: error: expected `;' before ?const?
oct-cmplx.h:81: error: ?ay? was not declared in this scope
oct-cmplx.h:81: error: ?by? was not declared in this scope
oct-cmplx.h: In function ?bool operator>=(const std::complex<_Tp>&, T)?:
oct-cmplx.h:81: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:81: error: expected `;' before ?const?
oct-cmplx.h:81: error: ?ax? was not declared in this scope
oct-cmplx.h:81: error: expected `;' before ?const?
oct-cmplx.h:81: error: ?ay? was not declared in this scope
oct-cmplx.h: In function ?bool operator>=(T, const std::complex<_Tp>&)?:
oct-cmplx.h:81: error: ?FLOAT_TRUNCATE? was not declared in this scope
oct-cmplx.h:81: error: expected `;' before ?const?
oct-cmplx.h:81: error: ?bx? was not declared in this scope
oct-cmplx.h:81: error: expected `;' before ?const?
oct-cmplx.h:81: error: ?by? was not declared in this scope
make[2]: *** [oct-locbuf.o] Error 1
make[2]: Leaving directory `/home/thorsten/hg/octave/liboctave'
make[1]: *** [liboctave] Error 2
make[1]: Leaving directory `/home/thorsten/hg/octave'
make: *** [all] Error 2


==========================
==========================
configuration:


From highegg at gmail.com  Tue Sep 15 07:56:35 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 15 Sep 2009 14:56:35 +0200
Subject: bug in oct-cmplx.h?
In-Reply-To: <h8o2lb$pns$1@ger.gmane.org>
References: <h8o2lb$pns$1@ger.gmane.org>
Message-ID: <69d8d540909150556s6a8b88a4g9d676b65407f829b@mail.gmail.com>

On Tue, Sep 15, 2009 at 2:51 PM, Thorsten Meyer <thorsten.meyier at gmx.de> wrote:
> A have just tried to compile the present tip (85dd3a2c9355) and get the error
> below. Apparently, FLOAT_TRUNCATE is not declared there. However, I do find a
> definition of FLOAT_TRUNCATE as part of UGLY_DEFS in Makeconf (is says
> -DFLOAT_TRUNCATE= ). So, why isn't this definition propagated down?
>
> Can someone help with this?
>
> Thanks
>
> Thorsten

UGLY_DEFS are not used if HAVE_CONFIG_H is in effect. Verify that
FLOAT_TRUNCATE is set in your config.h file. If not, I suggest rerun
autogen.sh and reconfigure. If the problem persists, it will need more
investigation.

hth

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

From Andreas.Stahel at bfh.ch  Thu Sep 17 05:07:07 2009
From: Andreas.Stahel at bfh.ch (Andreas Stahel)
Date: Thu, 17 Sep 2009 12:07:07 +0200
Subject: failing fsolve with derivative
Message-ID: <4AB20A4B.3000909@bfh.ch>

Bug report for Octave 3.2.2 configured for i686-pc-linux-gnu

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

  * On my system (Ubuntu 8.04 with Octave 3.2.2 (locally compiled)
    I can not convince the command fsolve to use the derivative

Repeat-By:
---------
  * I reduced the code to  
    fsolve({@sin, at cos},3,opt)
    leading to
   error: A(I): Index exceeds matrix dimension.
Fix:
---

  * If I would only know?

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

uname output:     Linux hilbert 2.6.24-24-generic #1 SMP Sat Aug 22 
01:06:14 UTC 2009 i686 GNU/Linux
configure opts:   '--with-fastblas' '--with-arpack' 'LDFLAGS=-lpthread'
Fortran compiler: g77
FFLAGS:           -O -mieee-fp
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 -lpthread -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:          -lpthread
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.2
BLAS_LIBS:        -lcblas -lf77blas -latlas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lcblas -lf77blas -latlas 
-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_REGEXEC=1
  -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_FFTW3=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_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_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

User-preferences (please do not edit this section):
--------------------------------------------------

  EDITOR = emacs
  EXEC_PATH = 
/usr/local/libexec/octave/3.2.2/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/api-v37/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/3.2.2/exec/i686-pc-linux-gnu:/usr/local/bin:/home/sha1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
  IMAGE_PATH = .:/usr/local/share/octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/sha1/.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 = 0
# print_answer_id_name = <no value or error in displaying it>
  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


-- 
Andreas Stahel       E-Mail: Andreas.Stahel@[ANTI-SPAM]bfh.ch
Mathematics, BFH-TI  Phone: ++41 +32 32 16 258
Quellgasse 21        Fax:   ++41 +32 321 500
CH-2501 Biel         WWW:   https://prof.ti.bfh.ch/sha1/
Switzerland


From Pascal.Dupuis at worldonline.be  Tue Sep 15 10:46:36 2009
From: Pascal.Dupuis at worldonline.be (Dupuis)
Date: Tue, 15 Sep 2009 08:46:36 -0700 (PDT)
Subject: sqp: failing when providing objective function's hessian
Message-ID: <25456476.post@talk.nabble.com>


Hello,

while trying to understand why I couldn't get solutions satisfying the
equality constraint with sqp, I noticed the following, as examplified in the
enclosed file (octave3.0.1 on Ubuntu, can't change the version). The program
draws an ellipse, as defined by a center, a quadratic form and some level.
The initial code computes points in the reduced referential, then apply a
rotation and a translation into ordinary coordinates.

The next step is to find a point on the ellipse where the coordinates
product is maximum. To use sqp, the opposite of the coordinate product is
taken as the objective function. The constraint is expressed in terms of the
ellipse definition. I compared three methods:
1) use sqp with objective value and gradient, as well as equality value,
gradient and hessian
2) use sqp with objective value, gradient and hessian, as well as equality
value, gradient and hessian
3) express the augmented problem using Lagrange multiplier, iterativelly
cancel out the gradient with a Newton method

The conclusion: method 1 and 3 give the same result, while method 2 give a
lower power, but the solution doesn't validate the equality constraint. In
particular, I noticed that the lambda as returned by method 1 has only  one
non-zero component, while the lambda of method 2 (with hessian) contains two
non-zero components. Any hint ?

Regards

Pascal
http://www.nabble.com/file/p25456476/sqp_demo.m sqp_demo.m 
-- 
View this message in context: http://www.nabble.com/sqp%3A-failing-when-providing-objective-function%27s-hessian-tp25456476p25456476.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From soren at hauberg.org  Thu Sep 17 08:28:20 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Thu, 17 Sep 2009 15:28:20 +0200
Subject: Animations with fltk backend
Message-ID: <1253194100.4394.8.camel@sh-t400>

Hi All,

I'd like to do animate some data, that I've got using the fltk backend
(the gnuplot backend is too slow for this). I can't make it work though.
The following code illustrates the problem

        backend ("fltk")
        x = linspace (0, 10, 100);
        for k = 1:100
          plot (x, k * sin (x));
          pause (1)
        endfor

When I run this, no plot appears on screen until the loop ends, so I
don't get any animations. This works with the gnuplot backend.

S?ren


From michael.goffioul at gmail.com  Thu Sep 17 09:34:31 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Thu, 17 Sep 2009 15:34:31 +0100
Subject: Animations with fltk backend
In-Reply-To: <1253194100.4394.8.camel@sh-t400>
References: <1253194100.4394.8.camel@sh-t400>
Message-ID: <128f38bd0909170734u513a87c7web7b4323c74a6ff4@mail.gmail.com>

I think this is due to the synchronous implementation of
the FLTK backend. Basically, the FLTK GUI loop runs
synchronously with octave and only when octave is idle
(there's an input event hook registered by the FLTK backend).

So as long as readline is not in idle mode, no event
processing will be done by FLTK. I think you can get what
you want by calling "drawnow" explicitly after the plot
command.

Michael.


On Thu, Sep 17, 2009 at 2:28 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> Hi All,
>
> I'd like to do animate some data, that I've got using the fltk backend
> (the gnuplot backend is too slow for this). I can't make it work though.
> The following code illustrates the problem
>
> ? ? ? ?backend ("fltk")
> ? ? ? ?x = linspace (0, 10, 100);
> ? ? ? ?for k = 1:100
> ? ? ? ? ?plot (x, k * sin (x));
> ? ? ? ? ?pause (1)
> ? ? ? ?endfor
>
> When I run this, no plot appears on screen until the loop ends, so I
> don't get any animations. This works with the gnuplot backend.
>
> S?ren
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>


From soren at hauberg.org  Thu Sep 17 09:47:11 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Thu, 17 Sep 2009 16:47:11 +0200
Subject: Animations with fltk backend
In-Reply-To: <128f38bd0909170734u513a87c7web7b4323c74a6ff4@mail.gmail.com>
References: <1253194100.4394.8.camel@sh-t400>
	<128f38bd0909170734u513a87c7web7b4323c74a6ff4@mail.gmail.com>
Message-ID: <1253198831.4410.1.camel@sh-t400>

tor, 17 09 2009 kl. 15:34 +0100, skrev Michael Goffioul:
> So as long as readline is not in idle mode, no event
> processing will be done by FLTK. I think you can get what
> you want by calling "drawnow" explicitly after the plot
> command.

I also tried this, and it didn't make a difference. From what I
remember, 'pause' should also call 'drawnow' (if not it's a bug), so it
really shouldn't be necessary.

S?ren


From highegg at gmail.com  Thu Sep 17 10:30:09 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 17 Sep 2009 17:30:09 +0200
Subject: failing fsolve with derivative
In-Reply-To: <4AB20A4B.3000909@bfh.ch>
References: <4AB20A4B.3000909@bfh.ch>
Message-ID: <69d8d540909170830y4a63c3d5leb1025d4196c5eb7@mail.gmail.com>

On Thu, Sep 17, 2009 at 12:07 PM, Andreas Stahel <Andreas.Stahel at bfh.ch> wrote:
> Bug report for Octave 3.2.2 configured for i686-pc-linux-gnu
>
> Description:
> -----------
>
> ?* On my system (Ubuntu 8.04 with Octave 3.2.2 (locally compiled)
> ? ?I can not convince the command fsolve to use the derivative
>
> Repeat-By:
> ---------
> ?* I reduced the code to
> ? ?fsolve({@sin, at cos},3,opt)
> ? ?leading to
> ? error: A(I): Index exceeds matrix dimension.
> Fix:
> ---
>
> ?* If I would only know?
>

"help" is your friend. Derivative is specified as second output
argument of the function.

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


From godfrey at isl.stanford.edu  Thu Sep 17 23:36:16 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 17 Sep 2009 21:36:16 -0700
Subject: plotting: window close does not close figure in gnuplot mode
Message-ID: <4AB30E40.4080800@isl.stanford.edu>

Using current development system,
And fedora Linux FC11:

octave:1> backend("fltk");
octave:2> figure(6)
octave:3> isfigure(6)
ans =  1
octave:4> ishandle(6)
ans =  1
 >>>> closed window on screen:
octave:5> ishandle(6)
ans = 0
octave:6> isfigure(6)
ans = 0
octave:7> backend("gnuplot");
octave:8> figure(7)
octave:9> isfigure(7)
ans =  1
 >>>> closed window on screen
octave:10> isfigure(7)
ans =  1
octave:11>
octave:11> close(7)
octave:12> isfigure(7)
ans = 0
octave:13>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090917/e73893b0/attachment.html 

From soren at hauberg.org  Fri Sep 18 01:47:53 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Fri, 18 Sep 2009 08:47:53 +0200
Subject: plotting: window close does not close figure in gnuplot mode
In-Reply-To: <4AB30E40.4080800@isl.stanford.edu>
References: <4AB30E40.4080800@isl.stanford.edu>
Message-ID: <1253256473.4410.10.camel@sh-t400>

tor, 17 09 2009 kl. 21:36 -0700, skrev Michael D Godfrey:
> Using current development system,
> And fedora Linux FC11:
> 
> octave:1> backend("fltk");
> octave:2> figure(6)
> octave:3> isfigure(6)
> ans =  1
> octave:4> ishandle(6)
> ans =  1
> >>>> closed window on screen:
> octave:5> ishandle(6)
> ans = 0
> octave:6> isfigure(6)
> ans = 0
> octave:7> backend("gnuplot");
> octave:8> figure(7)
> octave:9> isfigure(7)
> ans =  1
> >>>> closed window on screen
> octave:10> isfigure(7)
> ans =  1
> octave:11> 
> octave:11> close(7)
> octave:12> isfigure(7)
> ans = 0
> octave:13> 

The gnuplot backend doesn't know when you close windows on screen. The
problem is basically that we don't get a signal from gnuplot when it
exits. Consider this a limitation of the approach used in the gnuplot
backend; one that would be very hard to fix.

S?ren


From marco_atzeri at yahoo.it  Fri Sep 18 04:00:32 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Fri, 18 Sep 2009 09:00:32 +0000 (GMT)
Subject: missing oct-dlldefs.h
Message-ID: <557662.473.qm@web25504.mail.ukl.yahoo.com>

Hi John,

the last changeset 
http://hg.savannah.gnu.org/hgweb/octave/rev/11844593875a

seems incomplete as there are still reference to oct-dlldefs.h


g++-4 -c -I. -I../../octave/src -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/src/mex.cc -o mex.o
In file included from ../../octave/src/mex.cc:41:
../../octave/src/mexproto.h:58:25: error: oct-dlldefs.h: No such file or directory
../../octave/src/mex.cc: In constructor 'mxArray_number::mxArray_number(mwSize, const char**)':
../../octave/src/mex.cc:1165: warning: comparison between signed and unsigned integer expressions
make[2]: *** [mex.o] Error 1
make[2]: Leaving directory `/pub/hg/octave_build/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/pub/hg/octave_build'
make: *** [all] Error 2

Regards
Marco



      


From jwe at octave.org  Fri Sep 18 04:55:37 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 18 Sep 2009 05:55:37 -0400
Subject: missing oct-dlldefs.h
In-Reply-To: <557662.473.qm@web25504.mail.ukl.yahoo.com>
References: <557662.473.qm@web25504.mail.ukl.yahoo.com>
Message-ID: <19123.22809.649406.144561@segfault.lan>

On 18-Sep-2009, Marco Atzeri wrote:

| the last changeset 
| http://hg.savannah.gnu.org/hgweb/octave/rev/11844593875a
| 
| seems incomplete as there are still reference to oct-dlldefs.h

The following two patches should fix this:

  http://hg.savannah.gnu.org/hgweb/octave/rev/6e2a3968ea6f
  http://hg.savannah.gnu.org/hgweb/octave/rev/7234534f47ba

Removing the #include is enough for building Octave.

The second patch is necessary for building MEX files.

jwe

From jwe at octave.org  Fri Sep 18 05:10:33 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 18 Sep 2009 06:10:33 -0400
Subject: plotting: window close does not close figure in gnuplot mode
In-Reply-To: <1253256473.4410.10.camel@sh-t400>
References: <4AB30E40.4080800@isl.stanford.edu>
	<1253256473.4410.10.camel@sh-t400>
Message-ID: <19123.23705.593091.745638@segfault.lan>

On 18-Sep-2009, S?ren Hauberg wrote:

| tor, 17 09 2009 kl. 21:36 -0700, skrev Michael D Godfrey:
| > Using current development system,
| > And fedora Linux FC11:
| > 
| > octave:1> backend("fltk");
| > octave:2> figure(6)
| > octave:3> isfigure(6)
| > ans =  1
| > octave:4> ishandle(6)
| > ans =  1
| > >>>> closed window on screen:
| > octave:5> ishandle(6)
| > ans = 0
| > octave:6> isfigure(6)
| > ans = 0
| > octave:7> backend("gnuplot");
| > octave:8> figure(7)
| > octave:9> isfigure(7)
| > ans =  1
| > >>>> closed window on screen
| > octave:10> isfigure(7)
| > ans =  1
| > octave:11> 
| > octave:11> close(7)
| > octave:12> isfigure(7)
| > ans = 0
| > octave:13> 
| 
| The gnuplot backend doesn't know when you close windows on screen. The
| problem is basically that we don't get a signal from gnuplot when it
| exits. Consider this a limitation of the approach used in the gnuplot
| backend; one that would be very hard to fix.

Finding out when the gnuplot process has exited would be possible, but
somewhat messy.  Back in the olden times, when gnuplot was even more
closely integrated with Octave than it is now, there was a mechanism
in place for doing this, and restarting gnuplot if the connection
appeared to be dead.  I suppose we could try to make Octave watch the
gnuplot process to see if it exits, but it would probably be messy
and I'm not sure it is worth the effort.  For starters, does SIGCHLD
work the same on Windows as it does on Unixy systems?

But even if we made a complicated change like that, it would still not
fix the problem you noticed because closing the X11 window doesn't
cause gnuplot to exit.  It just closes the plot window.  The pipe to
the gnuplot process is still open, and gnuplot is still ready to
accept commands, and Octave is not notified that the window has been
closed.  I don't know whether gnuplot even has a way to provide that
information.

jwe


From jwe at octave.org  Fri Sep 18 05:48:02 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 18 Sep 2009 06:48:02 -0400
Subject: Animations with fltk backend
In-Reply-To: <1253198831.4410.1.camel@sh-t400>
References: <1253194100.4394.8.camel@sh-t400>
	<128f38bd0909170734u513a87c7web7b4323c74a6ff4@mail.gmail.com>
	<1253198831.4410.1.camel@sh-t400>
Message-ID: <19123.25954.943135.902224@segfault.lan>

On 17-Sep-2009, S?ren Hauberg wrote:

| tor, 17 09 2009 kl. 15:34 +0100, skrev Michael Goffioul:
| > So as long as readline is not in idle mode, no event
| > processing will be done by FLTK. I think you can get what
| > you want by calling "drawnow" explicitly after the plot
| > command.
| 
| I also tried this, and it didn't make a difference. From what I
| remember, 'pause' should also call 'drawnow' (if not it's a bug), so it
| really shouldn't be necessary.

I checked in the following change.  Now "demo comet" should work.

For a rough comparison of the maximum update speeds for the gnuplot
backend vs. the fltk/opengl backend, try the following:

  t = 0:.1:2*pi;
  x = cos(2*t).*(cos(t).^2);
  y = sin(2*t).*(sin(t).^2); 

  tic ();
  backend ("fltk");
  figure (1);
  comet(x, y, eps);
  toc ();

  tic ();
  backend ("gnuplot");
  figure (2);
  comet(x, y, eps);
  toc ();

On my system, it takes about 8 seconds for the fltk/opengl backend and
18 seconds for gnuplot.

jwe


From jwe at octave.org  Fri Sep 18 05:49:53 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 18 Sep 2009 06:49:53 -0400
Subject: Animations with fltk backend
In-Reply-To: <19123.25954.943135.902224@segfault.lan>
References: <1253194100.4394.8.camel@sh-t400>
	<128f38bd0909170734u513a87c7web7b4323c74a6ff4@mail.gmail.com>
	<1253198831.4410.1.camel@sh-t400>
	<19123.25954.943135.902224@segfault.lan>
Message-ID: <19123.26065.859581.278200@segfault.lan>

On 18-Sep-2009, John W. Eaton wrote:

| On 17-Sep-2009, S?ren Hauberg wrote:
| 
| | tor, 17 09 2009 kl. 15:34 +0100, skrev Michael Goffioul:
| | > So as long as readline is not in idle mode, no event
| | > processing will be done by FLTK. I think you can get what
| | > you want by calling "drawnow" explicitly after the plot
| | > command.
| | 
| | I also tried this, and it didn't make a difference. From what I
| | remember, 'pause' should also call 'drawnow' (if not it's a bug), so it
| | really shouldn't be necessary.
| 
| I checked in the following change.  Now "demo comet" should work.

Oops, the changeset is here:

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

jwe


From pierre.st-laurent at globetrotter.net  Fri Sep 18 07:59:09 2009
From: pierre.st-laurent at globetrotter.net (Pierre Saint-Laurent)
Date: Fri, 18 Sep 2009 08:59:09 -0400
Subject: Suggestion for addition to FAQ
Message-ID: <1253278749.3524.21.camel@c75.globetrotter.net>


Hi,

I would like to suggest an addition to the Octave FAQ
 ( http://www.gnu.org/software/octave/FAQ.html )

More precisely I would put it in section 9 "How do I...?", something
like :

|---------------------------------------------------------------|
9.2 How do I produce figures without a X-window?

In Octave2.9.9 and more recent, you can produce figures without a
working X-window (e.g. from a ssh connection) by using :

figure(1,"visible","off")
... plot commands ...
print("yourfile.eps","-deps");
|---------------------------------------------------------------|

I've been looking for this for months, and I found the answer (from jwe
on Sep.14 2007) deeply hidden in the archive of the Help-Octave mailing
list. I think it would be cool to have this trick in the Octave FAQ.
>From reading the archive this is really a frequently asked question, and
the old way of doing things (involving __gnuplot_set__ output
"yourfile.eps") does not work with >=2.9.9.

Note that the Octave3.0 manual does not explicitely cover this issue
either. It mentions the "visible" toggle, but I found nowhere that
Octave could produce figures without a X-window. So it seems like a good
idea to mention this very useful (to me at least) feature in the FAQ.

Best regards,

Pierre



From godfrey at isl.stanford.edu  Fri Sep 18 08:56:38 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Fri, 18 Sep 2009 06:56:38 -0700
Subject: plotting: window close does not close figure in gnuplot mode
In-Reply-To: <19123.23705.593091.745638@segfault.lan>
References: <4AB30E40.4080800@isl.stanford.edu>	<1253256473.4410.10.camel@sh-t400>
	<19123.23705.593091.745638@segfault.lan>
Message-ID: <4AB39196.6040503@isl.stanford.edu>

On 09/18/2009 03:10 AM, John W. Eaton wrote:
> But even if we made a complicated change like that, it would still not
> fix the problem you noticed because closing the X11 window doesn't
> cause gnuplot to exit.  It just closes the plot window.  The pipe to
> the gnuplot process is still open, and gnuplot is still ready to
> accept commands, and Octave is not notified that the window has been
> closed.  I don't know whether gnuplot even has a way to provide that
> information.
>
> jwe
>    
It seems best to just document this "feature." I will include it in the 
plotting
documentation that I am working on.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090918/9c4af95a/attachment-0001.html 

From david0815 at gmx.de  Fri Sep 18 09:31:57 2009
From: david0815 at gmx.de (bat_boy)
Date: Fri, 18 Sep 2009 07:31:57 -0700 (PDT)
Subject: Issues on 'errorbar' again, how do I fix it?
Message-ID: <25509743.post@talk.nabble.com>


Hi folks!

I had a look for reports about the function "errorbar". There seems to be
quite a great need for a more advanced version of it, e.g. change in
linestyle (currently there is none linestyle at all, right?), color (which
seems to be altered by the system for each plot), etc

In my version 3.0.0 just the following yields any output at all:
errorbar(x_data1,y_data1,y_data1_err,"~");

If I want a solid line connecting all datapoints I have to do this:
errorbar(x_data1,y_data1,y_data1_err,"~");
h=get(gca,'children');
set (h, "color", "blue"); 
hold on;
plot(x_data1,y_data1,"*-b");

The problem here is, that the errorbars themselves dont change their color,
e.g. I get a pretty mix of all colors in one line.
Do anyone know how to change this?
I tried to follow the trail of the data plotted by errorbar. I ended up in
"__errplot__.m"
Unfortunately I am not sure where the actual lines (the bars the errorbars
consist of) are plotted. Is  this done using the "set (h, "xdata",
(1:len)');" commands? Could I change the color of the errorbars here by
doing something like set(h,"color","yellow"); ?

I tried this in _errplot__.m  (see below) without success: The lines still
appear in the color chosen, the errorbars dont.
So how do I start? I would really like to help as developer, but yet I dont
understand this very basic funtions.

Cheers, David




__errplot__.m:

function h = __errplot__ (fstr, p, a1, a2, a3, a4, a5, a6)

  if (nargin < 4 || nargin > 8) # at least two data arguments needed
    print_usage ();
  endif

  [fmt, key] = __pltopt__ ("__errplot__", fstr);

  [len, nplots] = size (a1);

  for i = 1:nplots
    ## Set the plot type based on linestyle.
    if (fmt.linestyle == "~")
      ifmt = "yerr";
    elseif (fmt.linestyle == ">")
      ifmt = "xerr";
    elseif (fmt.linestyle == "~>")
      ifmt = "xyerr";
    elseif (fmt.linestyle == "#")
      ifmt = "box";
    elseif (fmt.linestyle == "#~")
      ifmt = "boxy";
    elseif (fmt.linestyle == "#~>")
      ifmt = "boxxy";
    else
      print_usage ();
    endif

    h = __line__ (p);

    switch (nargin - 2)
      case 2
	set (h, "xdata", (1:len)');
set (h, "color", "yellow");

	set (h, "ydata", a1(:,i));
set (h, "color", "yellow");

	set (h, "ldata", a2(:,i));
set (h, "color", "yellow");

	set (h, "udata", a2(:,i));
set (h, "color", "yellow");

      case 3
	set (h, "xdata", a1(:,i));
set (h, "color", "yellow");
	set (h, "ydata", a2(:,i));
set (h, "color", "yellow");
	set (h, "ldata", a3(:,i));
set (h, "color", "yellow");
	set (h, "udata", a3(:,i));
set (h, "color", "yellow");
      case 4
	set (h, "xdata", a1(:,i));
set (h, "color", "yellow");
	set (h, "ydata", a2(:,i));
set (h, "color", "yellow");

	if (index (ifmt, "boxxy") || index (ifmt, "xyerr"))
	  set (h, "xldata", a3(:,i));
set (h, "color", "yellow");
	  set (h, "xudata", a3(:,i));
set (h, "color", "yellow");
	  set (h, "ldata", a4(:,i));
set (h, "color", "yellow");
	  set (h, "udata", a4(:,i));
set (h, "color", "yellow");
	elseif (index (ifmt, "xerr"))
	  set (h, "xldata", a3(:,i));
set (h, "color", "yellow");
	  set (h, "xudata", a4(:,i));
set (h, "color", "yellow");
	else
	  set (h, "ldata", a3(:,i));
set (h, "color", "yellow");
set (h, "color", "yellow"); 
	  set (h, "udata", a4(:,i));
set (h, "color", "yellow"); 
	endif
      case 5
	error ("error plot requires 2, 3, 4 or 6 columns");
      case 6
	set (h, "xdata", a1(:,i));
set (h, "color", "yellow");
	set (h, "ydata", a2(:,i));
set (h, "color", "yellow");
	set (h, "xldata", a3(:,i));
set (h, "color", "yellow");
	set (h, "xudata", a4(:,i));
set (h, "color", "yellow");
	set (h, "ldata", a5(:,i));
set (h, "color", "yellow");
	set (h, "udata", a6(:,i));
set (h, "color", "yellow");

    endswitch
  endfor

endfunction

-- 
View this message in context: http://www.nabble.com/Issues-on-%27errorbar%27-again%2C-how-do-I-fix-it--tp25509743p25509743.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From Thomas.Treichl at gmx.net  Fri Sep 18 14:44:44 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 18 Sep 2009 21:44:44 +0200
Subject: Minor problems with developer sources...
Message-ID: <4AB3E32C.1020902@gmx.net>

Hi,

I have minor problems compiling the current sources on Mac OS X 10.4

   g++ -c -arch i386 -O2 -fforce-addr -mfpmath=sse,387 -march=prescott -ggdb
   -isysroot /Developer/SDKs/MacOSX10.4u.sdk
   -I/Applications/Octave.app/Contents/Resources/include
   -I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick
   -I/tmp/deps-i386/include   -fPIC -I. -I.. -I../liboctave -I../src
   -I../libcruft/misc  -DHAVE_CONFIG_H -mieee-fp
   -I/tmp/deps-i386/include/freetype2 -I/tmp/deps-i386/include
   -I/tmp/deps-i386/include   -Wall -W -Wshadow -Wold-style-cast -Wformat -arch
   i386 -O2 -fforce-addr -mfpmath=sse,387 -march=prescott -ggdb -isysroot
   /Developer/SDKs/MacOSX10.4u.sdk
   -I/Applications/Octave.app/Contents/Resources/include
   -I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick
   -D_THREAD_SAFE  mach-info.cc -o pic/mach-info.o
   mach-info.cc:31:23: error: oct-types.h: No such file or directory
   make[2]: *** [pic/mach-info.o] Error 1
   make[1]: *** [liboctave] Error 2
   make: *** [all] Error 2

I removed the line "include <oct-types.h>" from mach-info.cc because I don't 
know better. Is this the way to do it?

Best regards

   Thomas

PS. objections to these?

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-September/013211.html

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-September/013212.html

From jwe at octave.org  Fri Sep 18 17:58:05 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 18 Sep 2009 18:58:05 -0400
Subject: Minor problems with developer sources...
In-Reply-To: <4AB3E32C.1020902@gmx.net>
References: <4AB3E32C.1020902@gmx.net>
Message-ID: <19124.4221.699184.270614@segfault.lan>

On 18-Sep-2009, Thomas Treichl wrote:

| I have minor problems compiling the current sources on Mac OS X 10.4
| 
|    g++ -c -arch i386 -O2 -fforce-addr -mfpmath=sse,387 -march=prescott -ggdb
|    -isysroot /Developer/SDKs/MacOSX10.4u.sdk
|    -I/Applications/Octave.app/Contents/Resources/include
|    -I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick
|    -I/tmp/deps-i386/include   -fPIC -I. -I.. -I../liboctave -I../src
|    -I../libcruft/misc  -DHAVE_CONFIG_H -mieee-fp
|    -I/tmp/deps-i386/include/freetype2 -I/tmp/deps-i386/include
|    -I/tmp/deps-i386/include   -Wall -W -Wshadow -Wold-style-cast -Wformat -arch
|    i386 -O2 -fforce-addr -mfpmath=sse,387 -march=prescott -ggdb -isysroot
|    /Developer/SDKs/MacOSX10.4u.sdk
|    -I/Applications/Octave.app/Contents/Resources/include
|    -I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick
|    -D_THREAD_SAFE  mach-info.cc -o pic/mach-info.o
|    mach-info.cc:31:23: error: oct-types.h: No such file or directory
|    make[2]: *** [pic/mach-info.o] Error 1
|    make[1]: *** [liboctave] Error 2
|    make: *** [all] Error 2
| 
| I removed the line "include <oct-types.h>" from mach-info.cc because I don't 
| know better. Is this the way to do it?

I made this change.

Thanks,

jwe

From marventur at uol.com.br  Fri Sep 18 22:04:19 2009
From: marventur at uol.com.br (Marcelo)
Date: Sat, 19 Sep 2009 00:04:19 -0300
Subject: Bug - function roots numerical problem
Message-ID: <1253329459.18667.4.camel@TEPLOTAXL>

Please see attached file.
-------------- next part --------------
To: bug at octave.org
Cc: Marcelo
Subject: roots function
--------
Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu

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

  * The roots function have numerical problems.

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

  * For example: Find the root of (x+1)^n = binomial expansion.
    The answer should be x = -1 with multiplicity n.
    e.g., c = [1 4 6 4 1]; roots(c) should result -1. -1. -1. -1.
    The octave doesn't give the exact answer. It returns:
    -1.00006 + 0.00006i   -1.00006 - 0.00006i
    -0.99994 + 0.00006i   -0.99994 - 0.00006i
    The SciLab and Matlab do the job perfectly.

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 TEPLOTAXL 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux
configure opts:   '--host=i486-linux-gnu' '--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' 'host_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
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) 
CFLAGS:           -O2 -g
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.3.3
CXXFLAGS:         -O2 -g
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:          
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.0.1
BLAS_LIBS:        -llapackgf-3 -lblas-3gf
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
  -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 -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_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/lib/octave/3.0.1/site/exec/i486-pc-linux-gnu:/usr/lib/octave/api-v32/site/exec/i486-pc-linux-gnu:/usr/lib/octave/site/exec/i486-pc-linux-gnu:/usr/lib/octave/3.0.1/exec/i486-pc-linux-gnu:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  IMAGE_PATH = .:/usr/share/octave/3.0.1/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 = pl
  gnuplot_command_replot = rep
  gnuplot_command_splot = sp
  gnuplot_command_title = t
  gnuplot_command_using = u
  gnuplot_command_with = w
  history_file = /home/vesper/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /usr/share/info/octave3.0.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

From efrios at yahoo.com  Sat Sep 19 21:57:24 2009
From: efrios at yahoo.com (Hielos)
Date: Sat, 19 Sep 2009 19:57:24 -0700 (PDT)
Subject: java and jhandles... revisited
In-Reply-To: <128f38bd0909150055h65f2270dt1127a39325c7f213@mail.gmail.com>
References: <25374487.post@talk.nabble.com>
	<128f38bd0909092332m45c368c8i8d2fb3c958b5efb0@mail.gmail.com>
	<25402674.post@talk.nabble.com>
	<128f38bd0909110947u68ad297o2077c87152c5768@mail.gmail.com>
	<25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
	<25429191.post@talk.nabble.com>
	<128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>
	<25443402.post@talk.nabble.com>
	<128f38bd0909141401i32656342h4e5a1da3ce72628e@mail.gmail.com>
	<25445171.post@talk.nabble.com>
	<128f38bd0909150055h65f2270dt1127a39325c7f213@mail.gmail.com>
Message-ID: <25527375.post@talk.nabble.com>


Since I don't know where the JOGL shared libraries are, I looked it up on the
ubuntu package list
(http://packages.ubuntu.com/search?suite=default&section=all&arch=any&searchon=names&keywords=jogl)
and found this: http://packages.ubuntu.com/jaunty/amd64/libjogl-jni/filelist
.
So I went back to the terminal:
   $ locate libjogl.so
   /usr/lib/jni/libjogl.so

Then, I modified my '.bashrc':
  export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
  export PATH=$PATH:$JAVA_HOME
  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni/

After that, I tried to run (in octave):
   octave:1> pkg install /home/edgar/Programas/Temp/jhandles-0.3.5.tar.gz
   error: A(I) = X: X must have the same size as I
   error: called from:
   error:   /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 2007, column
21
   error:   /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 301, column 7
   make: *** [all] Error 255
   'make' returned the following error: make: se ingresa al directorio
`/tmp/oct-POCkd9/jhandles-0.3.5/src'
   Java support not compiled
   make: se sale del directorio `/tmp/oct-POCkd9/jhandles-0.3.5/src'
   error: called from `pkg>configure_make' in file
/usr/local/share/octave/3.2.2/m/pkg/pkg.m near line 1253, column 2
   error: called from:
   error:   /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 714, column 5
   error:   /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 287, column 7

I don't think that's very useful to anyone, so I went back to the terminal:
   $ cd jhandles-0.3.5/src
   jhandles-0.3.5/src $  ./configure
   ...
   checking for java package in Octave... error: A(I) = X: X must have the
same size as I
   ...
   octave-forge is configured with
   octave:      octave (version 3.2.2)
   mkoctfile:	mkoctfile for Octave 2
   java:        Could not find octave.jar
   octave.jar:	
   jogl.jar:
   ...
    http://www.nabble.com/file/p25527375/config.log config.log 

I tried the same thing as root (modified .bashrc and ran ./configure) with
not a positive result, although a bit different:
http://www.nabble.com/file/p25527375/config.root config.root 

Are the new environment variables ok? What else could be the problem?


Michael Goffioul-2 wrote:
> 
> 
> Currently, the configure script expects to find JOGL jar files somewhere
> in
> your PATH. So make sure this is the case.
> 
> Moreover, you'll also need to
> add the path where JOGL shared libs (.so) are located to your
> LD_LIBRARY_PATH variable. Although you probably don't need it for
> configure/make stages.
> 
> Michael.
> 
> _______________________________________________
> 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://www.nabble.com/java-and-jhandles...-revisited-tp25374487p25527375.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From jswhite97 at gmail.com  Sun Sep 20 12:08:56 2009
From: jswhite97 at gmail.com (Joshua White)
Date: Sun, 20 Sep 2009 13:08:56 -0400
Subject: 'union' returns incorrect output for simple case
Message-ID: <5263cc0f0909201008r5db8cabep40aaa4208d1a0a17@mail.gmail.com>

--------
Bug report for Octave 3.2.2 configured for i686-pc-linux-gnu

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

[C,IA,IB] = union(A,B) is supposed to return IA and IB such that A==C(IA)
and B==C(IB).
It does not -- IA and IB are incorrect.  (See example below.)

Repeat-By:
---------
octave:264> A = [1 3 5]
A =
   1   3   5
octave:265> B = [1 4 5]
B =
   1   4   5
octave:266> [C, IA, IB] = union(A,B)
C =
   1   3   4   5
IA =  2
IB =
   1   2   3
octave:267> C(IA)
ans =  3
octave:268> C(IB)
ans =
   1   3   4
octave:269> version
ans = 3.2.2

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 xxxxx 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18
18:40:08 UTC 2009 i686 GNU/Linux
configure opts:   '--with-blas=-L/opt/intel/mkl/10.2.1.017/lib/32/ -lmkl
-lpthread' '--with-lapack=-mkl_lapack' 'F77=gfortran'
Fortran compiler: gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/4.3.3
-L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lhdf5 -lz
-lgfortranbegin -lgfortran -lm
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
CFLAGS:           -g -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.3.3
CXXFLAGS:         -g -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.2
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lblas -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_H=1
  -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_GL_GL_H=1
  -DHAVE_GL_GLU_H=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_BLAS=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/local/libexec/octave/3.2.2/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/api-v37/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/3.2.2/exec/i686-pc-linux-gnu:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  IMAGE_PATH = .:/usr/local/share/octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/jswhite/.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 = <no value or error in displaying it>
  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 --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090920/e5e806d5/attachment.html 

From michael.goffioul at gmail.com  Sun Sep 20 15:06:36 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sun, 20 Sep 2009 21:06:36 +0100
Subject: java and jhandles... revisited
In-Reply-To: <25527375.post@talk.nabble.com>
References: <25374487.post@talk.nabble.com> <25406474.post@talk.nabble.com>
	<128f38bd0909111313i212fe91bg4a938ac00ed23e6a@mail.gmail.com>
	<25429191.post@talk.nabble.com>
	<128f38bd0909132324p6ea95287n8c0cce395af255c9@mail.gmail.com>
	<25443402.post@talk.nabble.com>
	<128f38bd0909141401i32656342h4e5a1da3ce72628e@mail.gmail.com>
	<25445171.post@talk.nabble.com>
	<128f38bd0909150055h65f2270dt1127a39325c7f213@mail.gmail.com>
	<25527375.post@talk.nabble.com>
Message-ID: <128f38bd0909201306k65cc2d1br8fb2ef1d26b1e243@mail.gmail.com>

On Sun, Sep 20, 2009 at 3:57 AM, Hielos <efrios at yahoo.com> wrote:
>
> Since I don't know where the JOGL shared libraries are, I looked it up on the
> ubuntu package list
> (http://packages.ubuntu.com/search?suite=default&section=all&arch=any&searchon=names&keywords=jogl)
> and found this: http://packages.ubuntu.com/jaunty/amd64/libjogl-jni/filelist
> .
> So I went back to the terminal:
> ? $ locate libjogl.so
> ? /usr/lib/jni/libjogl.so
>
> Then, I modified my '.bashrc':
> ?export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
> ?export PATH=$PATH:$JAVA_HOME
> ?export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni/
>
> After that, I tried to run (in octave):
> ? octave:1> pkg install /home/edgar/Programas/Temp/jhandles-0.3.5.tar.gz
> ? error: A(I) = X: X must have the same size as I
> ? error: called from:
> ? error: ? /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 2007, column
> 21
> ? error: ? /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 301, column 7
> ? make: *** [all] Error 255
> ? 'make' returned the following error: make: se ingresa al directorio
> `/tmp/oct-POCkd9/jhandles-0.3.5/src'
> ? Java support not compiled
> ? make: se sale del directorio `/tmp/oct-POCkd9/jhandles-0.3.5/src'
> ? error: called from `pkg>configure_make' in file
> /usr/local/share/octave/3.2.2/m/pkg/pkg.m near line 1253, column 2
> ? error: called from:
> ? error: ? /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 714, column 5
> ? error: ? /usr/local/share/octave/3.2.2/m/pkg/pkg.m at line 287, column 7
>
> I don't think that's very useful to anyone, so I went back to the terminal:
> ? $ cd jhandles-0.3.5/src
> ? jhandles-0.3.5/src $ ?./configure
> ? ...
> ? checking for java package in Octave... error: A(I) = X: X must have the
> same size as I
> ? ...
> ? octave-forge is configured with
> ? octave: ? ? ?octave (version 3.2.2)
> ? mkoctfile: ? mkoctfile for Octave 2
> ? java: ? ? ? ?Could not find octave.jar
> ? octave.jar:
> ? jogl.jar:
> ? ...

That's strange as the octave.jar detection used to work for
you before. What you actually need as setup is the following:

export PATH=$PATH:/usr/share/java
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk

You shouldn't need to set LD_LIBRARY_PATH for building
the package. You only need it at runtime. Note also that
instead of adding /usr/share/java to your PATH, you can
also try to simply copy gluegen-rt.jar and jogl.jar to
/usr/bin.

Michael.


From godfrey at isl.stanford.edu  Sun Sep 20 16:17:39 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 20 Sep 2009 14:17:39 -0700
Subject: whos command does not show graphics handles
Message-ID: <4AB69BF3.8020505@isl.stanford.edu>

Using current development system:

octave:2> fh1 = @sin;
octave:3> gh1 = figure(1);
octave:4> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        ans         1x1                          8  double
        fh1         1x1                          0  function_handle
        gh1         1x1                          8  double

Total is 3 elements using 16 bytes

As far as I know, all graphics handles just show double as
their class.  I looked at the code in variables.cc, but it was not
obvious (to me)  how to implement showing the correct
handle classes for graphics handles.

If this can be fixed soon, I will include the result in the
plotting documentation that I am working on.

Michael


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090920/8fe586fe/attachment.html 

From jswhite97 at gmail.com  Sun Sep 20 13:00:24 2009
From: jswhite97 at gmail.com (Joshua White)
Date: Sun, 20 Sep 2009 14:00:24 -0400
Subject: 'setxor' produces incorrect output
Message-ID: <5263cc0f0909201100h4e89e9edv2aaf91da9574b081@mail.gmail.com>

--------
Bug report for Octave 3.2.2 configured for i686-pc-linux-gnu

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

[C,IA,IJ] = setxor(A,B) should return IA and IB such that A==C(IA) and
B==C(IB).
It does not -- see example below.

Repeat-By:
---------
octave:307> A = [1 3 5]
A =
   1   3   5
octave:308> B = [1 4 5]
B =
   1   4   5
octave:309> [C,IA,IB] = setxor(A,B)
C =
   3   4
IA =  2
IB =  2
octave:310> C(IA)
ans =  4
octave:311> C(IB)
ans =  4

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 xxxxx 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18
18:40:08 UTC 2009 i686 GNU/Linux
configure opts:   '--with-blas=-L/opt/intel/mkl/10.2.1.017/lib/32/ -lmkl
-lpthread' '--with-lapack=-mkl_lapack' 'F77=gfortran'
Fortran compiler: gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/4.3.3
-L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lhdf5 -lz
-lgfortranbegin -lgfortran -lm
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
CFLAGS:           -g -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.3.3
CXXFLAGS:         -g -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.2
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lblas -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_H=1
  -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_GL_GL_H=1
  -DHAVE_GL_GLU_H=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_BLAS=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/local/libexec/octave/3.2.2/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/api-v37/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/3.2.2/exec/i686-pc-linux-gnu:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  IMAGE_PATH = .:/usr/local/share/octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/jswhite/.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 = <no value or error in displaying it>
  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 --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090920/9f5960c4/attachment-0001.html 

From jswhite97 at gmail.com  Sun Sep 20 14:26:17 2009
From: jswhite97 at gmail.com (Joshua White)
Date: Sun, 20 Sep 2009 15:26:17 -0400
Subject: Fwd: 'union' returns incorrect output for simple case
In-Reply-To: <5263cc0f0909201008r5db8cabep40aaa4208d1a0a17@mail.gmail.com>
References: <5263cc0f0909201008r5db8cabep40aaa4208d1a0a17@mail.gmail.com>
Message-ID: <5263cc0f0909201226j319e23cy582a0cc0b0c2abe9@mail.gmail.com>

I think the following is a fix for union.m.  Change lines 82-84 from

    [y, i] = unique (y, varargin{:});
    ia = i(i <= na);
    ib = i(i > na) - na;

to

     [y, i, j] = unique (y, varargin{:});
     ia = j(1:na);
     ib = j(na+1:end);

I wonder if this fixes the setxor problem too.



---------- Forwarded message ----------

Date: Sun, Sep 20, 2009 at 1:08 PM
Subject: 'union' returns incorrect output for simple case
To: bug at octave.org


--------
Bug report for Octave 3.2.2 configured for i686-pc-linux-gnu

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

[C,IA,IB] = union(A,B) is supposed to return IA and IB such that A==C(IA)
and B==C(IB).
It does not -- IA and IB are incorrect.  (See example below.)

Repeat-By:
---------
octave:264> A = [1 3 5]
A =
   1   3   5
octave:265> B = [1 4 5]
B =
   1   4   5
octave:266> [C, IA, IB] = union(A,B)
C =
   1   3   4   5
IA =  2
IB =
   1   2   3
octave:267> C(IA)
ans =  3
octave:268> C(IB)
ans =
   1   3   4
octave:269> version
ans = 3.2.2

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 xxxxx 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18
18:40:08 UTC 2009 i686 GNU/Linux
configure opts:   '--with-blas=-L/opt/intel/mkl/10.2.1.017/lib/32/ -lmkl
-lpthread' '--with-lapack=-mkl_lapack' 'F77=gfortran'
Fortran compiler: gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/4.3.3
-L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lhdf5 -lz
-lgfortranbegin -lgfortran -lm
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
CFLAGS:           -g -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.3.3
CXXFLAGS:         -g -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.2
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lblas -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_H=1
  -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_GL_GL_H=1
  -DHAVE_GL_GLU_H=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_BLAS=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/local/libexec/octave/3.2.2/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/api-v37/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/3.2.2/exec/i686-pc-linux-gnu:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  IMAGE_PATH = .:/usr/local/share/octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/jswhite/.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 = <no value or error in displaying it>
  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 --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090920/2e0f9bd5/attachment-0001.html 

From highegg at gmail.com  Mon Sep 21 01:30:13 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 21 Sep 2009 08:30:13 +0200
Subject: 'union' returns incorrect output for simple case
In-Reply-To: <5263cc0f0909201226j319e23cy582a0cc0b0c2abe9@mail.gmail.com>
References: <5263cc0f0909201008r5db8cabep40aaa4208d1a0a17@mail.gmail.com>
	<5263cc0f0909201226j319e23cy582a0cc0b0c2abe9@mail.gmail.com>
Message-ID: <69d8d540909202330q53a34c83mdc9af05e46a1744@mail.gmail.com>

On Sun, Sep 20, 2009 at 9:26 PM, Joshua White <jswhite97 at gmail.com> wrote:
>
> I think the following is a fix for union.m.? Change lines 82-84 from
>
> ??? [y, i] = unique (y, varargin{:});
> ??? ia = i(i <= na);
> ??? ib = i(i > na) - na;
>
> to
>
> ???? [y, i, j] = unique (y, varargin{:});
> ???? ia = j(1:na);
> ???? ib = j(na+1:end);
>
> I wonder if this fixes the setxor problem too.
>

Sorry, no, this is the wrong way to go. setxor and union are intended
to be Matlab-compatible, and actually their behavior is correct, just
their documentation is incorrect. In both cases, ia and ib are
supposed to be such that a(ia) and b(ib) are disjoint and their union
is c. I've pushed a correction.

thanks for the report

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


From carlo.defalco at gmail.com  Mon Sep 21 02:49:22 2009
From: carlo.defalco at gmail.com (Carlo de Falco)
Date: Mon, 21 Sep 2009 09:49:22 +0200
Subject: hos command does not show graphics handles
In-Reply-To: <mailman.2077.1253508855.21430.bug-octave@octave.org>
References: <mailman.2077.1253508855.21430.bug-octave@octave.org>
Message-ID: <E80BA7AD-B117-4315-B581-46BC40FBB477@gmail.com>


On 21 Sep 2009, at 06:54, bug-octave-request at octave.org wrote:

> Message: 1
> Date: Sun, 20 Sep 2009 14:17:39 -0700
> From: Michael D Godfrey <godfrey at isl.stanford.edu>
> Subject: whos command does not show graphics handles
> To: bug at octave.org
> Message-ID: <4AB69BF3.8020505 at isl.stanford.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Using current development system:
>
> octave:2> fh1 = @sin;
> octave:3> gh1 = figure(1);
> octave:4> whos
> Variables in the current scope:
>
>   Attr Name        Size                     Bytes  Class
>   ==== ====        ====                     =====  =====
>        ans         1x1                          8  double
>        fh1         1x1                          0  function_handle
>        gh1         1x1                          8  double
>
> Total is 3 elements using 16 bytes
>
> As far as I know, all graphics handles just show double as
> their class.  I looked at the code in variables.cc, but it was not
> obvious (to me)  how to implement showing the correct
> handle classes for graphics handles.
>
> If this can be fixed soon, I will include the result in the
> plotting documentation that I am working on.
>
> Michael


I believe this behaviour is needed for compatibility,
matlab does exactly the same (except for the size of fh1...):
--------------------------------------------------------
 >> fh1 = @sin;
 >> gh1 = figure(1);
 >> whos
   Name      Size            Bytes  Class              Attributes

   fh1       1x1                16  function_handle
   gh1       1x1                 8  double

 >> version
ans =
7.7.0.471 (R2008b)
 >>
--------------------------------------------------------
So I see no need to fix anything here...
c.



From Pascal.Dupuis at worldonline.be  Mon Sep 21 07:23:31 2009
From: Pascal.Dupuis at worldonline.be (Dupuis)
Date: Mon, 21 Sep 2009 05:23:31 -0700 (PDT)
Subject: Bug - function roots numerical problem
In-Reply-To: <1253329459.18667.4.camel@TEPLOTAXL>
References: <1253329459.18667.4.camel@TEPLOTAXL>
Message-ID: <25530310.post@talk.nabble.com>




Marcelo-60 wrote:
> 
> Please see attached file.
> 
> To: bug at octave.org
> Cc: Marcelo
> Subject: roots function
> --------
> Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu
> 
> Description:
> -----------
> 
>   * The roots function have numerical problems.
> 
> Repeat-By:
> ---------
> 
>   * For example: Find the root of (x+1)^n = binomial expansion.
>     The answer should be x = -1 with multiplicity n.
>     e.g., c = [1 4 6 4 1]; roots(c) should result -1. -1. -1. -1.
>     The octave doesn't give the exact answer. It returns:
>     -1.00006 + 0.00006i   -1.00006 - 0.00006i
>     -0.99994 + 0.00006i   -0.99994 - 0.00006i
>     The SciLab and Matlab do the job perfectly.
> 
> 

It's not a bug, it's a feature. Roots extracting is performed through matrix
computation, and in the case of a root with a multiplicity greater than 1,
the matrix becomes singular. The fix is to implement an algorithm which
computes the GCD between the polynomial and its first derivative: multiple
roots are common factor of both. The division of the original polynomial by
this GCD is a polynom where each root is of multiplicity 1, and this doesn't
suffer for numerical inaccuracies.

I suggest you to have a look at Z. Zeng's homepage,
http://www.neiu.edu/~zzeng/, then have a look at 'multroot', which
implements this solution. It's Matlab code, easy to translate to Octave, but
the license is very restricitive. See if you can cope with it.

Regards

Pascal
-- 
View this message in context: http://www.nabble.com/Bug---function-roots-numerical-problem-tp25521954p25530310.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From highegg at gmail.com  Mon Sep 21 12:41:17 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 21 Sep 2009 19:41:17 +0200
Subject: Bug - function roots numerical problem
In-Reply-To: <1253329459.18667.4.camel@TEPLOTAXL>
References: <1253329459.18667.4.camel@TEPLOTAXL>
Message-ID: <69d8d540909211041x52bf5b1eh1d860ecd6b18763f@mail.gmail.com>

On Sat, Sep 19, 2009 at 5:04 AM, Marcelo <marventur at uol.com.br> wrote:
> Please see attached file.
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>
>

The algorithm used by roots is fairly simplistic - it simply computes
the eigenvalues of the companion matrix. That is good enough for most
purposes, but is not suited for multiple roots. Contributing a better
algorithm (probably hybrid) would be welcome.

-- 
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  Mon Sep 21 12:59:58 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 21 Sep 2009 13:59:58 -0400
Subject: Bug - function roots numerical problem
In-Reply-To: <69d8d540909211041x52bf5b1eh1d860ecd6b18763f@mail.gmail.com>
References: <1253329459.18667.4.camel@TEPLOTAXL>
	<69d8d540909211041x52bf5b1eh1d860ecd6b18763f@mail.gmail.com>
Message-ID: <19127.48926.968305.624831@segfault.lan>

On 21-Sep-2009, Jaroslav Hajek wrote:

| On Sat, Sep 19, 2009 at 5:04 AM, Marcelo <marventur at uol.com.br> wrote:
| > Please see attached file.
| >
| > _______________________________________________
| > Bug-octave mailing list
| > Bug-octave at octave.org
| > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
| >
| >
| 
| The algorithm used by roots is fairly simplistic - it simply computes
| the eigenvalues of the companion matrix. That is good enough for most
| purposes, but is not suited for multiple roots. Contributing a better
| algorithm (probably hybrid) would be welcome.

If you do contribute an improved function, please remember that it
must not be derived from proprietary software.  For example, if
there happens to be a roots.m file in Matlab that you know about, you
must not use that as a basis for a function that will become a part of
Octave.

jwe

From jwe at octave.org  Mon Sep 21 13:08:53 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 21 Sep 2009 14:08:53 -0400
Subject: Bug - function roots numerical problem
In-Reply-To: <19127.48926.968305.624831@segfault.lan>
References: <1253329459.18667.4.camel@TEPLOTAXL>
	<69d8d540909211041x52bf5b1eh1d860ecd6b18763f@mail.gmail.com>
	<19127.48926.968305.624831@segfault.lan>
Message-ID: <19127.49461.439176.72753@segfault.lan>

On 21-Sep-2009, John W. Eaton wrote:

| If you do contribute an improved function, please remember that it
| must not be derived from proprietary software.  For example, if
| there happens to be a roots.m file in Matlab that you know about, you
| must not use that as a basis for a function that will become a part of
| Octave.

I should have also mentioned that some care is also needed even when
borrowing code from other free software.  For example, I recall that
someone once translated code from an RLaB function so that it would
run in Octave.  The resulting function was distributed as part of a
collection of Octave functions (this was long before Octave had the
concept of packages).  All of this should have been OK as RLaB was
distributed under the terms of the GPL as was the Octave package.
Unfortunatley, the author of the function later found that the code in
RLaB had simply been translated from Matlab to RLaB syntax by copying
it from the corresponding Matlab function.  In the end, the code had
to be removed from the collection of Octave functions.  It's important
that we avoid such problems in the future.

jwe

From godfrey at isl.stanford.edu  Mon Sep 21 13:15:47 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Mon, 21 Sep 2009 11:15:47 -0700
Subject: hos command does not show graphics handles
In-Reply-To: <E80BA7AD-B117-4315-B581-46BC40FBB477@gmail.com>
References: <mailman.2077.1253508855.21430.bug-octave@octave.org>
	<E80BA7AD-B117-4315-B581-46BC40FBB477@gmail.com>
Message-ID: <4AB7C2D3.8060909@isl.stanford.edu>

On 09/21/2009 12:49 AM, Carlo de Falco wrote:
> So I see no need to fix anything here... 

Using the Matlab compatibility argument in this case
does not seem to me appropriate.  It is hard, but not
impossible, to imagine a case where a difference in the
whos display would cause a serious incompatibility.
I know of no Matlab code whose correct function depends
on the content of the whos output.

Consistently applying your argument to all of Octave
would be a lot of work.  Who plans to do this?

So, I would still like to see a change to the whos output,
and an additional function which returns the graphics handle
type.  The result would be to make Octave easier to use.
There does not appear to be a Matlab function to do this, so
another incompatibility in the cause of ease of use.

Other Matlab compatibility issues should be considered:

1. Implement the use of property "renderer" to determine
     fltk (OpenGL) or gnuplot.
     This point causes me to realize that I do not know how to
     find out which backend a handle is set to.  Since backend
     is not used by Matlab, maybe it would be good to switch to
     using renderer and renderermode.  It appears that backend()
     may need to be retained to do the global selection.  It does not
     appear that Matlab provides this.
2. Implement hgsave/hgload
3. Implement the command opengl (maybe just 'info' initially).


From michael.goffioul at gmail.com  Mon Sep 21 14:53:51 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Mon, 21 Sep 2009 20:53:51 +0100
Subject: hos command does not show graphics handles
In-Reply-To: <4AB7C2D3.8060909@isl.stanford.edu>
References: <mailman.2077.1253508855.21430.bug-octave@octave.org>
	<E80BA7AD-B117-4315-B581-46BC40FBB477@gmail.com>
	<4AB7C2D3.8060909@isl.stanford.edu>
Message-ID: <128f38bd0909211253q5c26f828l37dc89fa8315b5a2@mail.gmail.com>

On Mon, Sep 21, 2009 at 7:15 PM, Michael D. Godfrey
<godfrey at isl.stanford.edu> wrote:
> 1. Implement the use of property "renderer" to determine
> ? ? fltk (OpenGL) or gnuplot.

Just for the sake of clarity: do not confuse "backend" and "renderer",
there's no 1-to-1 match. The backend provides the windowing
capabilities, while the renderer is just responsible for rendering
plot data. Although this is not the case at the moment, you
can have theoretically several renderer supported by a single
backend (e.g. OpenGL, cairo...).

Michael.


From godfrey at isl.stanford.edu  Mon Sep 21 15:00:16 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Mon, 21 Sep 2009 13:00:16 -0700
Subject: hos command does not show graphics handles
In-Reply-To: <128f38bd0909211253q5c26f828l37dc89fa8315b5a2@mail.gmail.com>
References: <mailman.2077.1253508855.21430.bug-octave@octave.org>	
	<E80BA7AD-B117-4315-B581-46BC40FBB477@gmail.com>	
	<4AB7C2D3.8060909@isl.stanford.edu>
	<128f38bd0909211253q5c26f828l37dc89fa8315b5a2@mail.gmail.com>
Message-ID: <4AB7DB50.4050803@isl.stanford.edu>

On 09/21/2009 12:53 PM, Michael Goffioul wrote:
> Although this is not the case at the moment, you
> can have theoretically several renderer supported by a single
> backend (e.g. OpenGL, cairo...).
>    
Oh. OK.  So, where should the "backend" be kept in the
figure properties structure?  And, where is it now?
And, where is the "global" setting kept?  "available_backends"
just tells what is available  (initialized, really).

If you know these things without looking it up, that would
help. If not, I can look it up.

Michael



From shaiay at gmail.com  Mon Sep 21 14:59:25 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 21 Sep 2009 22:59:25 +0300
Subject: hos command does not show graphics handles
In-Reply-To: <128f38bd0909211253q5c26f828l37dc89fa8315b5a2@mail.gmail.com>
References: <mailman.2077.1253508855.21430.bug-octave@octave.org>
	<E80BA7AD-B117-4315-B581-46BC40FBB477@gmail.com>
	<4AB7C2D3.8060909@isl.stanford.edu>
	<128f38bd0909211253q5c26f828l37dc89fa8315b5a2@mail.gmail.com>
Message-ID: <420fb9e60909211259ra942807j261d1bee0d76ac8@mail.gmail.com>

On Mon, Sep 21, 2009 at 10:53 PM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> On Mon, Sep 21, 2009 at 7:15 PM, Michael D. Godfrey
> <godfrey at isl.stanford.edu> wrote:
>> 1. Implement the use of property "renderer" to determine
>> ? ? fltk (OpenGL) or gnuplot.
>
> Just for the sake of clarity: do not confuse "backend" and "renderer",
> there's no 1-to-1 match. The backend provides the windowing
> capabilities, while the renderer is just responsible for rendering
> plot data. Although this is not the case at the moment, you
> can have theoretically several renderer supported by a single
> backend (e.g. OpenGL, cairo...).
and also several backends supporting the same renderer -- i.e.
fltk_backend, and a yet to be written postscript backend using the
opengl-render

Shai


From shaiay at gmail.com  Mon Sep 21 15:07:56 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 21 Sep 2009 23:07:56 +0300
Subject: hos command does not show graphics handles
In-Reply-To: <4AB7DB50.4050803@isl.stanford.edu>
References: <mailman.2077.1253508855.21430.bug-octave@octave.org>
	<E80BA7AD-B117-4315-B581-46BC40FBB477@gmail.com>
	<4AB7C2D3.8060909@isl.stanford.edu>
	<128f38bd0909211253q5c26f828l37dc89fa8315b5a2@mail.gmail.com>
	<4AB7DB50.4050803@isl.stanford.edu>
Message-ID: <420fb9e60909211307x3215a5c2h630994f97208077c@mail.gmail.com>

On Mon, Sep 21, 2009 at 11:00 PM, Michael D. Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/21/2009 12:53 PM, Michael Goffioul wrote:
>>
>> Although this is not the case at the moment, you
>> can have theoretically several renderer supported by a single
>> backend (e.g. OpenGL, cairo...).
>>
>
> Oh. OK. ?So, where should the "backend" be kept in the
> figure properties structure? ?And, where is it now?
> And, where is the "global" setting kept? ?"available_backends"
> just tells what is available ?(initialized, really).

the backend for each figure is in the figure's __backend__ property
the 'global' setting is the default value for this property

Shai


From kristian.dimitrievski at chalmers.se  Tue Sep 22 10:18:43 2009
From: kristian.dimitrievski at chalmers.se (Kristian)
Date: Tue, 22 Sep 2009 17:18:43 +0200
Subject: Plot Bug: 'markerfacecolor' does not work
Message-ID: <4AB8EAD3.9070805@chalmers.se>

Hi,
I'm new to Octave, but I want to use it instead of Matlab in my 
scientific work (I'm a PhD). I have encountered a bug:

'markerfacecolor' does not work e.g. in the following plot-command:

plot(x, y, 'bo', 'markerfacecolor', 'r');

The data points are still blue, but should be red.

Sincerely,
/Kristian



From dbateman at dbateman.org  Tue Sep 22 14:26:47 2009
From: dbateman at dbateman.org (David Bateman)
Date: Tue, 22 Sep 2009 21:26:47 +0200
Subject: Plot Bug: 'markerfacecolor' does not work
In-Reply-To: <4AB8EAD3.9070805@chalmers.se>
References: <4AB8EAD3.9070805@chalmers.se>
Message-ID: <4AB924F7.8060104@dbateman.org>

Kristian wrote:
> Hi,
> I'm new to Octave, but I want to use it instead of Matlab in my 
> scientific work (I'm a PhD). I have encountered a bug:
>
> 'markerfacecolor' does not work e.g. in the following plot-command:
>
> plot(x, y, 'bo', 'markerfacecolor', 'r');
>
> The data points are still blue, but should be red.
>
> Sincerely,
> /Kristian
>   

At the moment the gnuplot backend uses a single plot command for each 
line to gnuplot.. Gnuplot doesn't specify the line and point colour 
separately so as you found the markerfacecolor property is not 
respected.. We could quite easily modify the gnuplot backend code to use 
two separate gnuplot lines for each line to get the desired effect... 
Not sure I have the time to do it personally though

D.


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


From dbateman at dbateman.org  Tue Sep 22 14:52:01 2009
From: dbateman at dbateman.org (David Bateman)
Date: Tue, 22 Sep 2009 21:52:01 +0200
Subject: Plot Bug: 'markerfacecolor' does not work
In-Reply-To: <4AB924F7.8060104@dbateman.org>
References: <4AB8EAD3.9070805@chalmers.se> <4AB924F7.8060104@dbateman.org>
Message-ID: <4AB92AE1.7030806@dbateman.org>

David Bateman wrote:
> Kristian wrote:
>   
>> Hi,
>> I'm new to Octave, but I want to use it instead of Matlab in my 
>> scientific work (I'm a PhD). I have encountered a bug:
>>
>> 'markerfacecolor' does not work e.g. in the following plot-command:
>>
>> plot(x, y, 'bo', 'markerfacecolor', 'r');
>>
>> The data points are still blue, but should be red.
>>
>> Sincerely,
>> /Kristian
>>   
>>     
>
> At the moment the gnuplot backend uses a single plot command for each 
> line to gnuplot.. Gnuplot doesn't specify the line and point colour 
> separately so as you found the markerfacecolor property is not 
> respected.. We could quite easily modify the gnuplot backend code to use 
> two separate gnuplot lines for each line to get the desired effect... 
> Not sure I have the time to do it personally though
>
> D.
>
>
>   
I have no desire (or time) to fully test the attached patch, but 
something like this should give the behavior you want.. Does someone 
want to test this patch further and maybe commit  it?

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
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090922/226f74d7/attachment.ksh 

From mikulik at physics.muni.cz  Wed Sep 23 03:47:40 2009
From: mikulik at physics.muni.cz (Petr Mikulik)
Date: Wed, 23 Sep 2009 10:47:40 +0200 (CEST)
Subject: Plot Bug: 'markerfacecolor' does not work
In-Reply-To: <4AB92AE1.7030806@dbateman.org>
References: <4AB8EAD3.9070805@chalmers.se> <4AB924F7.8060104@dbateman.org>
	<4AB92AE1.7030806@dbateman.org>
Message-ID: <Pine.LNX.4.64.0909231039560.11325@monoceros.physics.muni.cz>

> > > 'markerfacecolor' does not work e.g. in the following plot-command:
> > > plot(x, y, 'bo', 'markerfacecolor', 'r');
> > > The data points are still blue, but should be red.
> >
> > At the moment the gnuplot backend uses a single plot command for each line
> > to gnuplot.. Gnuplot doesn't specify the line and point colour separately so
> > as you found the markerfacecolor property is not respected.. We could quite
> > easily modify the gnuplot backend code to use two separate gnuplot lines for
> > each line to get the desired effect...
> >   
> I have no desire (or time) to fully test the attached patch, but something
> like this should give the behavior you want.. Does someone want to test this
> patch further and maybe commit  it?

This patch changes colour of symbols to red instead of just "filling" it 
with red.

Two plot commands are really necessary: if "markerfacecolor" is set and 
gnuplot point type is n=4,6,8,10,12 (diamonds, circles, triangles, ...), 
then:
	plot _data_ with point pt n+1 lc rgb _markerfacecolor_, \
	     _data_ with point pt n   lc rgb _point_color_

---
PM

From M.tHart at witteveenbos.nl  Wed Sep 23 03:43:55 2009
From: M.tHart at witteveenbos.nl (Maarten Hart 't)
Date: Wed, 23 Sep 2009 10:43:55 +0200
Subject: Color set for mesh function
Message-ID: <4AB9FBEB.9DC0.0058.0@witteveenbos.nl>

Dear sir/madam,
 
The mesh function at my computer did not have the ability to set colors of the mesh using the "edgecolor" statement. For example (i used a surface with X Y Z values): 
 
mesh(X,Y,Z, 'EdgeColor', 'black') 
 
showed a flat-mode colored mesh, while it should be black. I have changed the function in such a way that it uses the "surf" function. It is better now, since it has the ability of changing the color of the mesh. It still is not perfect though: in some cases the bottom side of the mesh has a different color than the top side. The top always has the right color; I do not know why the bottom has not. 
 
Maarten 't Hart

------------------------------------------------------------------------------------------
DISCLAIMER:
This e-mail is strictly confidential and is intended solely for the
addressee. It is prohibited for unauthorized persons to utilize the
information contained within this e-mail. If you receive this e-mail
and you are not the addressee, then please delete it from your system
and notify the person who sent it to you.

Our company accepts no liability for the content of this email, or for the consequences of
any actions taken on the basis of the information provided, unless that information is
subsequently confirmed in writing.

Witteveen+Bos Raadgevende ingenieurs B.V., Deventer
www.witteveenbos.nl or www.witteveenbos.com
Kamer van Koophandel 38020751
------------------------------------------------------------------------------------------
Before printing, think about the environment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090923/ed20d72a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesh.m
Type: application/octet-stream
Size: 1648 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090923/ed20d72a/attachment.obj 

From davidhsmith255 at gmail.com  Thu Sep 24 09:01:28 2009
From: davidhsmith255 at gmail.com (David Smith)
Date: Thu, 24 Sep 2009 07:01:28 -0700
Subject: griddata() throws an error for only one point outside convex hull (it
	should return NaN).
Message-ID: <205b66140909240701l45c0960fl174a351f81f8f0ca@mail.gmail.com>

Bug report for Octave 3.2.2 configured for i686-pc-mingw32

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

  * griddata() produces error message if asked to interpolate a single
    point and that point is outside the convex hull.

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

  * Please replace this item with a description of the sequence of
    events that causes the problem to occur.
  -----------------------
  * Call griddata thus:

       zi = griddata(X, Y, Z, xi, yi)

    zi will be a vector of interpolated results with NaN's reported
    where points fall outside the convex hull.  However, if xi and
    yi are a single point AND the point falls outside the convex hull
    I get the following error message and the program halts:

      error: product: nonconformant arguments (op1 is 0x1, op2 is 0x0)
      error: called from:
      error:
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\geometry\griddata.m at line
111, column 11


  * griddata() seems to work fine as long as I pass it two or more
    points to interpolate, even though these may be outside the convex
hull.

Fix:
---

  * A possible fix: Check for empty value for vector valid somewhere
    before line 111 and return all NaN's if this is the case.  The following
    construct seems to work for me.

        nr_t = rows(tri_list);
        if (nr_t)
           .....
        end

    See my patch in the attachment.

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:\Octave\3.2.2_gcc-4.3.0\tools\notepad++\notepad++.exe
  EXEC_PATH =
C:\Octave\3.2.2_gcc-4.3.0\MINGW32\bin;C:\Octave\3.2.2_gcc-4.3.0\MSYS\bin;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\site\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\bin;c:\program
files\graphicsmagick-1.3.5-q8;C:\Program Files\MiKTeX
2.7\miktex\bin;C:\Program Files\Measurement
Computing\DAQ\;C:\Python25;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program
Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\Common
Files\Roxio Shared\DLLShared\;C:\Program Files\Common Files\Roxio
Shared\9.0\DLLShared\;C:\Program Files\Common Files\Lenovo;C:\Program
Files\ThinkPad\ConnectUtilities;C:\Program Files\Lenovo\Client Security
Solution;C:\strawberry\c\bin;C:\strawberry\perl\bin;C:\Program Files\IVI
Foundation\VISA\WinNT\Bin\;C:\PROGRA~1\IVIFOU~1\VISA\WinNT\Bin;C:\Program
Files\IVI Foundation\VISA\WinNT\Bin;C:\Program Files\IVI
Foundation\IVI\bin;C:\Program Files\TortoiseSVN\bin;C:\Program
Files\MATLAB\R2008b\bin;C:\Program Files\MATLAB\R2008b\bin\win32;C:\Program
Files\QuickTime\QTSystem\;C:\Program Files\TortoiseHg;C:\Program
Files\pstoedit
  IMAGE_PATH = .;C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\imagelib
  PAGER = C:\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:\Octave\3.2.2_gcc-4.3.0\bin\gnuplot.exe
# gnuplot_command_end = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = C:\Users\davids\.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = C:\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 = 0
# print_answer_id_name = <no value or error in displaying it>
  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 --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090924/642ca000/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: griddata_dhs.patch
Type: application/octet-stream
Size: 2408 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090924/642ca000/attachment.obj 

From Martin.Hepperle at dlr.de  Thu Sep 24 03:23:51 2009
From: Martin.Hepperle at dlr.de (Martin.Hepperle at dlr.de)
Date: Thu, 24 Sep 2009 10:23:51 +0200
Subject: Java Interface in Windows Version of Octave 3.2.2
Message-ID: <DDCDEAD81C743C46AB065D08BA7A746F66D1BE@exbe4.intra.dlr.de>

Hello,

I tried to install the Extra Java package into Octave 3.2.2
for Windows (as distributed with the MinGW compiler):

pkg install java-1.2.6.tar.gz

Now I have two problems:

1) the java include files cannot be found. 
  It is not clear how to tell the MinGW compiler which include
  path it should use. 
   I tried to add the path to the Java include directory using 
   Octaves getenv() setenv() function, but obviously this 
   environment is not forwarded to the compiler.
   I used the usual environment variable INCLUDE, but this 
   also did not work.
   Finally I ended up copying all java include files from the 
   JDK to the MinGW include directory under Octave.  
   This works but is not the preferred solution.

2) Now that the include files are found, I receiuve a lot of 
   compiler error messages and the code won't compile.
   Before I start digging deeper, I would like to know whether
   anybody has successfully installed the java package under 
   the Windows build of Octave 3.2.2 and how he did this.


Thank You,

Martin


From tmacchant at yahoo.co.jp  Thu Sep 24 20:56:18 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Fri, 25 Sep 2009 10:56:18 +0900 (JST)
Subject: Java Interface in Windows Version of Octave 3.2.2
In-Reply-To: <DDCDEAD81C743C46AB065D08BA7A746F66D1BE@exbe4.intra.dlr.de>
Message-ID: <20090925015618.82165.qmail@web3805.mail.bbt.yahoo.co.jp>

Hello

Did you follow the below thread ?
http://www.nabble.com/Errors-installing-java-1.2.6-package-in-octave-MingW-3.2.x-td25563841.html

BTW the topic on octave-forge package is recommended to discuss at the octave-forge ML but not octave
ML. 

Iforward this messsage to the octave-forge ML (octave-dev at lists.sourceforge.net).

>From the next time, I ask you to post the topic to the octave-dev at lists.sourceforge.net if the  topic
concerns to the octave-forge packages.


You can subscribe to octave-forge ML from the below

https://lists.sourceforge.net/lists/listinfo/octave-dev

Regards

Tatsuro


--- Martin.Hepperl wrote:

> Hello,
> 
> I tried to install the Extra Java package into Octave 3.2.2
> for Windows (as distributed with the MinGW compiler):
> 
> pkg install java-1.2.6.tar.gz
> 
> Now I have two problems:
> 
> 1) the java include files cannot be found. 
>   It is not clear how to tell the MinGW compiler which include
>   path it should use. 
>    I tried to add the path to the Java include directory using 
>    Octaves getenv() setenv() function, but obviously this 
>    environment is not forwarded to the compiler.
>    I used the usual environment variable INCLUDE, but this 
>    also did not work.
>    Finally I ended up copying all java include files from the 
>    JDK to the MinGW include directory under Octave.  
>    This works but is not the preferred solution.
> 
> 2) Now that the include files are found, I receiuve a lot of 
>    compiler error messages and the code won't compile.
>    Before I start digging deeper, I would like to know whether
>    anybody has successfully installed the java package under 
>    the Windows build of Octave 3.2.2 and how he did this.
> 
> 
> Thank You,
> 
> Martin
> 
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From roderick.koehle at web.de  Thu Sep 24 14:53:25 2009
From: roderick.koehle at web.de (=?ISO-8859-15?Q?Roderick_K=F6hle?=)
Date: Thu, 24 Sep 2009 21:53:25 +0200
Subject: octave 3.2.2: str2double fails.
Message-ID: <4ABBCE35.1000709@web.de>

To: bug at octave.org
Cc: roderick
Subject: str2double fails.
--------
Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu

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

   str2double results in error due to a change of function max()

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

  str2double('1')

  error: two-arg max expecting args of same size
  error: called from:
  error:   /home/roderick/local/share/octave/3.2.2/m/general/repmat.m at
line 58, column 9
  error:  
/home/roderick/local/share/octave/3.2.2/m/strings/str2double.m at line
238, column 7

  In earlier versions of octave max([1 2 3], 0)
  was a valid statement. As with octave 3.2.2 this seems to result in an
error.



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

uname output:     Linux linux 2.6.27.29-0.1-default #1 SMP 2009-08-15
17:53:59 +0200 x86_64 x86_64 x86_64 GNU/Linux
configure opts:   '--prefix=/home/roderick/local'
'LDFLAGS=-L/home/roderick/local/lib'
'CPPFLAGS=-I/home/roderick/local/include'
Fortran compiler: gfortran
FFLAGS:           -O
FLIBS:            -L/home/roderick/local/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.3
-L/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.3/../../.. -lhdf5 -lz
-lgfortranbegin -lgfortran -lm
CPPFLAGS:         -I/home/roderick/local/include
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.2 [gcc-4_3-branch revision 141291]
(SUSE Linux)
CFLAGS:           -g -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.3.2
CXXFLAGS:         -g -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:          -L/home/roderick/local/lib
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/home/roderick/local/lib/octave-3.2.2
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lblas -lhdf5 -lz -lm
LEXLIB:           
LIBGLOB:          
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_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_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 =
/home/roderick/local/libexec/octave/3.2.2/site/exec/x86_64-unknown-linux-gnu:/home/roderick/local/libexec/octave/api-v37/site/exec/x86_64-unknown-linux-gnu:/home/roderick/local/libexec/octave/site/exec/x86_64-unknown-linux-gnu:/home/roderick/local/libexec/octave/3.2.2/exec/x86_64-unknown-linux-gnu:/home/roderick/local/bin:/home/roderick/local/bin:/home/roderick/local/bin:/home/roderick/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin:.:/opt/kde3/bin
  IMAGE_PATH = .:/home/roderick/local/share/octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/roderick/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /home/roderick/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 = <no value or error in displaying it>
  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 peter at sonderport.dk  Fri Sep 25 04:04:15 2009
From: peter at sonderport.dk (Peter L. =?ISO-8859-1?Q?S=F8ndergaard?=)
Date: Fri, 25 Sep 2009 11:04:15 +0200
Subject: problem with path.
Message-ID: <1253869455.21323.19.camel@localhost.localdomain>

I am using Octave 3.0.5, bundled with Fedora core 11.

The following code fails:

p=path;
path(p);

producing the output:

ann =

{
  ANN_BD_CENTROID
  ANN_BD_NONE
  ANN_BD_SIMPLE
  ANN_BD_SUGGEST
  ANN_HI

.....

  new_ANNorthRect (global method)
  new_ANNsampStat (global method)
}

The function that I have made that uses the two lines (with code
inbetween to modify the path temporarily) will sometimes lock octave
completely, so that I have to abort by pressing Ctrl-C several times.

The same code work in Matlab.

Cheers,

Peter.

 


From jed at 59A2.org  Fri Sep 25 05:42:54 2009
From: jed at 59A2.org (Jed Brown)
Date: Fri, 25 Sep 2009 12:42:54 +0200
Subject: spurious warning: matrix singular to machine precision, rcond = 0
Message-ID: <4ABC9EAE.80001@59A2.org>

Bug report for Octave 3.2.0 configured for x86_64-unknown-linux-gnu

Description:
-----------
Applies to very simple matrices

octave:41> inv([1 2;0 1])
warning: inverse: matrix singular to machine precision, rcond = 0
ans =      
           
           1          -2
           0           1

octave:47> inv(full(eye(2)))
warning: inverse: matrix singular to machine precision, rcond = 0
ans =

           1          -0
           0           1

octave:50> inv(1)
warning: inverse: matrix singular to machine precision, rcond = 0
ans =          1



Works fine for some matrices

octave:48> inv(hilb(4))
ans =

          16        -120         240        -140
        -120        1200       -2700        1680
         240       -2700        6480       -4200
        -140        1680       -4200        2800

Correctly gives warning when it should.

octave:54> inv(hilb(12))
warning: inverse: matrix singular to machine precision, rcond = 2.63209e-17
[snipped]

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

Lots of examples above, but this must not be effecting everyone.



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

uname output:     Linux brakk 2.6.30-ARCH #1 SMP PREEMPT Wed Sep 9 14:16:44 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux
configure opts:   '--prefix=/usr' 'CC=mpicc' 'CXX=mpicxx' 'F77=mpif77' 'LIBS=-lmetis' '--libexecdir=/usr/lib' '--with-lapack=/usr/lib' '--enable-64' '--enable-shared' '--disable-static' 'CFLAGS=-march=native -msse4.1 -O2 -pipe' 'CPPFLAGS=-DH5_USE_16_API' 'CXXFLAGS=-march=native -msse4.1 -O2 -pipe'
Fortran compiler: mpif77
FFLAGS:           -O
FLIBS:            -L/usr/X11R6/lib -L/home/jed/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.0 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/home/jed/usr/lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm -lmetis -lfreetype -lGL -lGLU -lmpi_f77 -lmpi -lopen-rte -lopen-pal -ldl -lnsl -lutil -lpthread
CPPFLAGS:         -DH5_USE_16_API  -I/usr/include/freetype2
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       mpicc, version 4.4.0 20090630 (prerelease) (GCC) 
CFLAGS:           -march=native -msse4.1 -O2 -pipe
CPICFLAG:         -fPIC
C++ compiler:     mpicxx, version 4.4.0
CXXFLAGS:         -march=native -msse4.1 -O2 -pipe -I/usr/include/freetype2
CXXPICFLAG:       -fPIC
LD_CXX:           mpicxx
LDFLAGS:          
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.2.0
BLAS_LIBS:        -llapack -lcblas -lf77blas -latlas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lcblas -lf77blas -latlas -lhdf5 -lz -lm -lmetis -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
  -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=":" -DSIZEOF_VOID_P=8 -DSIZEOF_INT=4 -DSIZEOF_LONG=8
  -DIDX_TYPE_LONG=1 -DUSE_64_BIT_IDX_T=1 -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_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1
  -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _
  -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_AMD_H=1 -DHAVE_AMD=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_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 = emacsclient -t
  EXEC_PATH = /usr/lib/octave/3.2.0/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.0/exec/x86_64-unknown-linux-gnu:/usr/bin:/opt/wine/bin:/opt/opencascade/bin:/bin:/sbin:/usr/bin:/usr/sbin:/home/jed/bin:/usr/share/java/apache-ant/bin:/opt/mpich2/bin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core:/opt/qt/bin:/home/jed/usr/paraview/bin:/home/sun/bin:/home/jed/build/visit-build/visit1.11.1/src/bin/:/home/jed/usr/gamit-10.34/gamit/bin:/home/jed/usr/gamit-10.34/kf/bin
  IMAGE_PATH = .:/usr/share/octave/3.2.0/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/jed/.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 = <no value or error in displaying it>
  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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090925/dd57a9e1/attachment-0001.bin 

From tmacchant at yahoo.co.jp  Fri Sep 25 05:49:53 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Fri, 25 Sep 2009 19:49:53 +0900 (JST)
Subject: Fwd: RE: Java Interface in Windows Version of Octave 3.2.2
Message-ID: <20090925104953.71109.qmail@web3815.mail.bbt.yahoo.co.jp>

--- Martin.Hepperle at dlr.de wrote:

> Subject:RE: Java Interface in Windows Version of Octave 3.2.2
> Date:Fri, 25 Sep 2009 10:16:38 +0200
> From:<Martin.Hepperle at dlr.de>
> To:<tmacchant at yahoo.co.jp>
> 
> Tatsuro,
> 
> thank you for your firendly guidance into the correct direction.
> I found the thread and will follow the advice given there.
> 
> Have a nice weekend,
> Martin
> 
> -----Original Message-----
> From: Tatsuro MATSUOKA [mailto:tmacchant at yahoo.co.jp] 
> Sent: Friday, September 25, 2009 3:56 AM
> To: Hepperle, Martin; bug-octave at octave.org
> Cc: octave-dev at lists.sourceforge.net
> Subject: Re: Java Interface in Windows Version of Octave 3.2.2
> 
> Hello
> 
> Did you follow the below thread ?
> http://www.nabble.com/Errors-installing-java-1.2.6-package-in-octave-Min
> gW-3.2.x-td25563841.html
> 
> BTW the topic on octave-forge package is recommended to discuss at the
> octave-forge ML but not octave ML. 
> 
> Iforward this messsage to the octave-forge ML
> (octave-dev at lists.sourceforge.net).
> 
> From the next time, I ask you to post the topic to the
> octave-dev at lists.sourceforge.net if the  topic concerns to the
> octave-forge packages.
> 
> 
> You can subscribe to octave-forge ML from the below
> 
> https://lists.sourceforge.net/lists/listinfo/octave-dev
> 
> Regards
> 
> Tatsuro
> 
> 
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From highegg at gmail.com  Fri Sep 25 06:50:34 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 25 Sep 2009 13:50:34 +0200
Subject: spurious warning: matrix singular to machine precision, rcond = 0
In-Reply-To: <4ABC9EAE.80001@59A2.org>
References: <4ABC9EAE.80001@59A2.org>
Message-ID: <69d8d540909250450x33a2bfc6ndaf423f1e06469e@mail.gmail.com>

On Fri, Sep 25, 2009 at 12:42 PM, Jed Brown <jed at 59a2.org> wrote:
> Bug report for Octave 3.2.0 configured for x86_64-unknown-linux-gnu
>
> Description:
> -----------
> Applies to very simple matrices
>
> octave:41> inv([1 2;0 1])
> warning: inverse: matrix singular to machine precision, rcond = 0
> ans =
>
> ? ? ? ? ? 1 ? ? ? ? ?-2
> ? ? ? ? ? 0 ? ? ? ? ? 1
>
> octave:47> inv(full(eye(2)))
> warning: inverse: matrix singular to machine precision, rcond = 0
> ans =
>
> ? ? ? ? ? 1 ? ? ? ? ?-0
> ? ? ? ? ? 0 ? ? ? ? ? 1
>
> octave:50> inv(1)
> warning: inverse: matrix singular to machine precision, rcond = 0
> ans = ? ? ? ? ?1
>
>
>
> Works fine for some matrices
>
> octave:48> inv(hilb(4))
> ans =
>
> ? ? ? ? ?16 ? ? ? ?-120 ? ? ? ? 240 ? ? ? ?-140
> ? ? ? ?-120 ? ? ? ?1200 ? ? ? -2700 ? ? ? ?1680
> ? ? ? ? 240 ? ? ? -2700 ? ? ? ?6480 ? ? ? -4200
> ? ? ? ?-140 ? ? ? ?1680 ? ? ? -4200 ? ? ? ?2800
>
> Correctly gives warning when it should.
>
> octave:54> inv(hilb(12))
> warning: inverse: matrix singular to machine precision, rcond = 2.63209e-17
> [snipped]
>
> Repeat-By:
> ---------
>
> Lots of examples above, but this must not be effecting everyone.
>

I can't reproduce this bug, neither with development tip nor 3.2.x
tree. I suspect the problem lies with compiler configuration.
Why do you use the mpi-enabled compilers?
Also, you should be aware that --enable-64 is experimental. To
successfully use that, your BLAS and LAPACK *must* be compiled with
64-bit INTEGERs (a lot of ops will work if they're not, but some will
crash silently). Are you sure of that? If you really mean to use the
64-bit indexing (required for matrices with more than 2e9 elements), I
suggest you try the development sources, which includes some
improvements and checks whether everything is all right.

hth

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


From jed at 59A2.org  Fri Sep 25 07:04:19 2009
From: jed at 59A2.org (Jed Brown)
Date: Fri, 25 Sep 2009 14:04:19 +0200
Subject: spurious warning: matrix singular to machine precision, rcond = 0
In-Reply-To: <69d8d540909250450x33a2bfc6ndaf423f1e06469e@mail.gmail.com>
References: <4ABC9EAE.80001@59A2.org>
	<69d8d540909250450x33a2bfc6ndaf423f1e06469e@mail.gmail.com>
Message-ID: <4ABCB1C3.1070103@59A2.org>

Jaroslav Hajek wrote:

> I can't reproduce this bug, neither with development tip nor 3.2.x
> tree. I suspect the problem lies with compiler configuration.
> Why do you use the mpi-enabled compilers?

My HDF5 is built with parallel support, hence must be linked to MPI.

> Also, you should be aware that --enable-64 is experimental. To
> successfully use that, your BLAS and LAPACK *must* be compiled with
> 64-bit INTEGERs (a lot of ops will work if they're not, but some will
> crash silently). Are you sure of that? If you really mean to use the
> 64-bit indexing (required for matrices with more than 2e9 elements), I
> suggest you try the development sources, which includes some
> improvements and checks whether everything is all right.

I wasn't aware of this, I had just perturbed this

  http://aur.archlinux.org/packages.php?ID=20021
  http://aur.archlinux.org/packages/octave-suitesparse/octave-suitesparse/PKGBUILD

My BLAS/Lapack (ATLAS) is not specially compiled for 64-bit ints, maybe
this is the problem (though I'm surprised that almost everything isn't
broken if this is the case).


Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090925/f67d557e/attachment.bin 

From highegg at gmail.com  Fri Sep 25 07:24:32 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 25 Sep 2009 14:24:32 +0200
Subject: spurious warning: matrix singular to machine precision, rcond = 0
In-Reply-To: <4ABCB1C3.1070103@59A2.org>
References: <4ABC9EAE.80001@59A2.org>
	<69d8d540909250450x33a2bfc6ndaf423f1e06469e@mail.gmail.com>
	<4ABCB1C3.1070103@59A2.org>
Message-ID: <69d8d540909250524x71beabdao7d238de9f24f9cea@mail.gmail.com>

On Fri, Sep 25, 2009 at 2:04 PM, Jed Brown <jed at 59a2.org> wrote:
> Jaroslav Hajek wrote:
>
>> I can't reproduce this bug, neither with development tip nor 3.2.x
>> tree. I suspect the problem lies with compiler configuration.
>> Why do you use the mpi-enabled compilers?
>
> My HDF5 is built with parallel support, hence must be linked to MPI.
>

Does it suffice to add -lmpi (and possibly -lmpi_f77) to LIBS?
If that is a shared library, it should probably have the MPI runtime
as a dependency.

>> Also, you should be aware that --enable-64 is experimental. To
>> successfully use that, your BLAS and LAPACK *must* be compiled with
>> 64-bit INTEGERs (a lot of ops will work if they're not, but some will
>> crash silently). Are you sure of that? If you really mean to use the
>> 64-bit indexing (required for matrices with more than 2e9 elements), I
>> suggest you try the development sources, which includes some
>> improvements and checks whether everything is all right.
>
> I wasn't aware of this, I had just perturbed this
>
> ?http://aur.archlinux.org/packages.php?ID=20021
> ?http://aur.archlinux.org/packages/octave-suitesparse/octave-suitesparse/PKGBUILD
>
> My BLAS/Lapack (ATLAS) is not specially compiled for 64-bit ints, maybe
> this is the problem (though I'm surprised that almost everything isn't
> broken if this is the case).
>

Because Fortran gets the integers via pointers, a lot of BLAS/LAPACK
subroutines will work unless you actually use the high dimensions -
the upper null words are simply ignored. Only those that use INTEGER
arrays will fail (anything that requires pivoting, i.e. LU, QRP
factorizations, SVD etc).
For the development (3.3.50+) version, there are some configure checks
for this common misconfiguration.

-- 
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 Sep 25 08:31:49 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 25 Sep 2009 15:31:49 +0200
Subject: spurious warning: matrix singular to machine precision, rcond = 0
In-Reply-To: <4ABCC18E.7000800@59A2.org>
References: <4ABC9EAE.80001@59A2.org>
	<69d8d540909250450x33a2bfc6ndaf423f1e06469e@mail.gmail.com>
	<4ABCB1C3.1070103@59A2.org>
	<69d8d540909250524x71beabdao7d238de9f24f9cea@mail.gmail.com>
	<4ABCC18E.7000800@59A2.org>
Message-ID: <69d8d540909250631w26baf400p2a97cac13970161e@mail.gmail.com>

On Fri, Sep 25, 2009 at 3:11 PM, Jed Brown <jed at 59a2.org> wrote:
> Jaroslav Hajek wrote:
>> On Fri, Sep 25, 2009 at 2:04 PM, Jed Brown <jed at 59a2.org> wrote:
>>> Jaroslav Hajek wrote:
>>>
>>>> I can't reproduce this bug, neither with development tip nor 3.2.x
>>>> tree. I suspect the problem lies with compiler configuration.
>>>> Why do you use the mpi-enabled compilers?
>>> My HDF5 is built with parallel support, hence must be linked to MPI.
>>>
>>
>> Does it suffice to add -lmpi (and possibly -lmpi_f77) to LIBS?
>
> It's a little messier than that (though the above often works as long as
> the MPI did their shared libs correctly and hasn't changed names)
>
> $ mpicc -show
> gcc -pthread -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl
>
> This is different for each MPI implementation, the wrappers are very
> lightweight. ?It's unfortunate that the MPI standard does not specifying
> how linking is to be done. ?Fortunately other libraries don't consider
> themselves to be so special as to use wrappers. ?Rather than fight it, I
> end up building most things with the wrappers.
>
>> If that is a shared library, it should probably have the MPI runtime
>> as a dependency.
>
> Indeed, ldd tells me that libhdf5.so links to the MPI shared libs, but I
> still recall getting link errors. ?It may have been a packaging issue
> that is now resolved.
>

I'd suggest getting a non-MPI version, then. Octave won't be able to
use the MPI support anyway.

>>> My BLAS/Lapack (ATLAS) is not specially compiled for 64-bit ints, maybe
>>> this is the problem (though I'm surprised that almost everything isn't
>>> broken if this is the case).
>>>
>>
>> Because Fortran gets the integers via pointers, a lot of BLAS/LAPACK
>> subroutines will work unless you actually use the high dimensions -
>> the upper null words are simply ignored. Only those that use INTEGER
>> arrays will fail (anything that requires pivoting, i.e. LU, QRP
>> factorizations, SVD etc).
>
> Of course, thanks. ?It's still very strange that I could get that
> warning and still get a correct inverse.
>

Probably the calls to DGETRF and DGETRI were OK, just DGECON failed.
It is a little mystery to me as to why it actually failed, but it's
the most likely explanation.

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


From jed at 59A2.org  Fri Sep 25 08:11:42 2009
From: jed at 59A2.org (Jed Brown)
Date: Fri, 25 Sep 2009 15:11:42 +0200
Subject: spurious warning: matrix singular to machine precision, rcond = 0
In-Reply-To: <69d8d540909250524x71beabdao7d238de9f24f9cea@mail.gmail.com>
References: <4ABC9EAE.80001@59A2.org>	
	<69d8d540909250450x33a2bfc6ndaf423f1e06469e@mail.gmail.com>	
	<4ABCB1C3.1070103@59A2.org>
	<69d8d540909250524x71beabdao7d238de9f24f9cea@mail.gmail.com>
Message-ID: <4ABCC18E.7000800@59A2.org>

Jaroslav Hajek wrote:
> On Fri, Sep 25, 2009 at 2:04 PM, Jed Brown <jed at 59a2.org> wrote:
>> Jaroslav Hajek wrote:
>>
>>> I can't reproduce this bug, neither with development tip nor 3.2.x
>>> tree. I suspect the problem lies with compiler configuration.
>>> Why do you use the mpi-enabled compilers?
>> My HDF5 is built with parallel support, hence must be linked to MPI.
>>
> 
> Does it suffice to add -lmpi (and possibly -lmpi_f77) to LIBS?

It's a little messier than that (though the above often works as long as
the MPI did their shared libs correctly and hasn't changed names)

$ mpicc -show
gcc -pthread -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl

This is different for each MPI implementation, the wrappers are very
lightweight.  It's unfortunate that the MPI standard does not specifying
how linking is to be done.  Fortunately other libraries don't consider
themselves to be so special as to use wrappers.  Rather than fight it, I
end up building most things with the wrappers.

> If that is a shared library, it should probably have the MPI runtime
> as a dependency.

Indeed, ldd tells me that libhdf5.so links to the MPI shared libs, but I
still recall getting link errors.  It may have been a packaging issue
that is now resolved.

>> My BLAS/Lapack (ATLAS) is not specially compiled for 64-bit ints, maybe
>> this is the problem (though I'm surprised that almost everything isn't
>> broken if this is the case).
>>
> 
> Because Fortran gets the integers via pointers, a lot of BLAS/LAPACK
> subroutines will work unless you actually use the high dimensions -
> the upper null words are simply ignored. Only those that use INTEGER
> arrays will fail (anything that requires pivoting, i.e. LU, QRP
> factorizations, SVD etc).

Of course, thanks.  It's still very strange that I could get that
warning and still get a correct inverse.

I rebuilt without --enable-64 and the spurious warning went away.

Thanks,

Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090925/31c1d409/attachment.bin 

From efrios at yahoo.com  Sat Sep 26 16:00:40 2009
From: efrios at yahoo.com (Hielos)
Date: Sat, 26 Sep 2009 14:00:40 -0700 (PDT)
Subject: ./float/misc/cl_F_digits.cc
Message-ID: <25628827.post@talk.nabble.com>


Hello, this is the bug:

octave:3> a=sym("a")
a =

a
octave:4> a=to_char(sym("a"))
error: Internal error: statement in file ./float/misc/cl_F_digits.cc, line
29 has been reached!!
Please send the authors of the program a description how you produced this
error!
-- 
View this message in context: http://www.nabble.com/.-float-misc-cl_F_digits.cc-tp25628827p25628827.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From efrios at yahoo.com  Sat Sep 26 16:11:02 2009
From: efrios at yahoo.com (Hielos)
Date: Sat, 26 Sep 2009 14:11:02 -0700 (PDT)
Subject: ./float/misc/cl_F_digits.cc
Message-ID: <25628827.post@talk.nabble.com>


Hello, this is the bug:

octave:3> a=sym("a")
a =

a
octave:4> a=to_char(sym("a"))
error: Internal error: statement in file ./float/misc/cl_F_digits.cc, line
29 has been reached!!
Please send the authors of the program a description how you produced this
error!

If you ask me, the reason for this would be that I had not typed 'symbols'
-- 
View this message in context: http://www.nabble.com/.-float-misc-cl_F_digits.cc-tp25628827p25628827.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From momarzo at tin.it  Sat Sep 26 15:55:54 2009
From: momarzo at tin.it (Moreno Mazolla)
Date: Sat, 26 Sep 2009 22:55:54 +0200
Subject: sub2ind fails with single-dimensional input
Message-ID: <4ABE7FDA.4090300@tin.it>

Bug report for Octave 3.3.50+ configured for x86_64-unknown-linux-gnu

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

I'm trying the mercurial version of octave:

changeset:   9665:1dba57e9d08d
tag:         tip
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sat Sep 26 10:41:07 2009 +0200
summary:     use blas_trans_type for xgemm

the sub2ind() function behaves differently than the one from octave 
3.0.0 which comes with ubuntu 8.04/amd64.

* On octave 3.0.0 the sub2ind( [6], 5 ) call works as expected:

octave:3> version
ans = 3.0.0
octave:4> sub2ind( [6], 5 )
ans =  5

* On the mercurial version, the same call fails:

octave:1> version
ans = 3.3.50+
octave:2> sub2ind( [6], 5 )
error: Invalid call to sub2ind.  Correct usage is:

  -- Function File: IND = sub2ind (DIMS, I, J)
  -- Function File: IND = sub2ind (DIMS, S1, S2, ..., SN)

Note that the mercurial version works if the first parameter has more 
than one element, as follows:

octave:2> sub2ind( [5 6], 3, 2 )
ans =  8

Note that this behaviour is somewhat consistent with the documentation, 
wihch suggests that at least three input parameters must be passed to 
the sub2ind function. However, I suggest that both the documentation and 
the implementation of the sub2ind() function be adapted to the simple 
case when the "dims" vector has just one element.

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

Issue the command:

sub2ind( [6], 5 )

with the mercurial version of octave.

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

uname output:      Linux univac 2.6.24-24-generic #1 SMP Sat Aug 22 
00:30:49 UTC 2009 x86_64 GNU/Linux
configure opts:    '--prefix=/home/moreno'
SED:               /bin/sed
Fortran compiler:  g77
FFLAGS:            -O
FLIBS:             -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6 
-L/usr/lib/gcc/x86_64-linux-gnu/3.4.6/../../../../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/3.4.6/../../.. -L/lib/../lib 
-L/usr/lib/../lib -lfrtbegin -lg2c -lm
CPPFLAGS:          -I/usr/include/freetype2
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 -I/usr/include/freetype2
CXXPICFLAG:        -fPIC
LD_CXX:            g++
LDFLAGS:
LIBFLAGS:          -L.
RLD_FLAG:          -Wl,-rpath -Wl,/home/moreno/lib/octave-3.3.50+
LEXLIB:
LIBGLOB:
LIBS:              -lm  -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU
AMD_CPPFLAGS:
AMD_LDFLAGS:
AMD_LIBS:          -lamd
ARPACK_LIBS:       -larpack
BLAS_LIBS:         -llapack -lblas
CAMD_CPPFLAGS:
CAMD_LDFLAGS:
CAMD_LIBS:         -lcamd
CARBON_LIBS:
CCOLAMD_CPPFLAGS:
CCOLAMD_LDFLAGS:
CCOLAMD_LIBS:      -lccolamd
CHOLMOD_CPPFLAGS:
CHOLMOD_LDFLAGS:
CHOLMOD_LIBS:      -lcholmod
COLAMD_CPPFLAGS:
COLAMD_LDFLAGS:
COLAMD_LIBS:       -lcolamd
CURL_CPPFLAGS:
CURL_LDFLAGS:
CURL_LIBS:         -lcurl
CXSPARSE_CPPFLAGS:
CXSPARSE_LDFLAGS:
CXSPARSE_LIBS:     -lcxsparse
DL_LIBS:           -ldl
FFTW3_CPPFLAGS:
FFTW3_LDFLAGS:
FFTW3_LIBS:        -lfftw3
FFTW3F_CPPFLAGS:
FFTW3F_LDFLAGS:
FFTW3F_LIBS:       -lfftw3f
GRAPHICS_LIBS:     -lfltk_gl -lfltk
GLPK_CPPFLAGS:
GLPK_LDFLAGS:
GLPK_LIBS:         -lglpk
HDF5_CPPFLAGS:
HDF5_LDFLAGS:
HDF5_LIBS:
OPENGL_LIBS:       -lfontconfig   -L/usr/X11R6/lib -lGL -lGLU
PTHREAD_CFLAGS:    -pthread
PTHREAD_LIBS:
QHULL_CPPFLAGS:
QHULL_LDFLAGS:
QHULL_LIBS:        -lqhull
QRUPDATE_LIBS:
READLINE_LIBS:     -lreadline
REGEX_LIBS:        -L/usr/lib -lpcre
TERM_LIBS:         -lncurses
UMFPACK_LIBS:      -lumfpack
X11_INCFLAGS:
X11_LIBS:          -lX11
Z_CPPFLAGS:
Z_LDFLAGS:
Z_LIBS:            -lz
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=":" -DOCTAVE_IDX_TYPE=int -D__NO_MATH_INLINES=1
   -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1
   -DHAVE_PTHREAD=1 -DHAVE_X_WINDOWS=1 -DFLOAT_TRUNCATE= -DHAVE_LIBM=1
   -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __
   -DHAVE_IEEE754_DATA_FORMAT=1 -DHAVE_QHULL_QHULL_A_H=1 -DHAVE_QHULL=1
   -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1
   -DHAVE_ZLIB_H=1 -DHAVE_Z=1 -DHAVE_FFTW3_H=1 -DHAVE_FFTW3=1
   -DHAVE_FFTW3_H=1 -DHAVE_FFTW3F=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_FREETYPE=1 -DHAVE_FONTCONFIG=1
   -DHAVE_FLTK=1 -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1
   -DHAVE_SUITESPARSE_CAMD_H=1 -DHAVE_CAMD=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_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1
   -DUMFPACK_SEPARATE_SPLIT=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_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


Regards,

Moreno.

--
Moreno Marzolla
http://www.dsi.unive.it/~marzolla

From soren at hauberg.org  Sun Sep 27 02:02:56 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 27 Sep 2009 09:02:56 +0200
Subject: ./float/misc/cl_F_digits.cc
In-Reply-To: <25628827.post@talk.nabble.com>
References: <25628827.post@talk.nabble.com>
Message-ID: <1254034976.4424.5.camel@sh-t400>

Hi,

l?r, 26 09 2009 kl. 14:11 -0700, skrev Hielos:
> octave:3> a=sym("a")
> a =
> 
> a
> octave:4> a=to_char(sym("a"))
> error: Internal error: statement in file ./float/misc/cl_F_digits.cc, line
> 29 has been reached!!
> Please send the authors of the program a description how you produced this
> error!

This is a bug in the 'symbolic' package, which uses Ginac for most of
its computations. Looking at the source code it seems that the error
message comes from Ginac and not Octave.

> If you ask me, the reason for this would be that I had not typed 'symbols'

I am not familiar with the 'symbolic' package, but it seems that calling
'symbols' initialises the 'symbolic' package. I guess this should be
done automatically when the package is loaded.

Can somebody remind me: what is the proper way of calling a function
when a package is loaded? Should I just put

  symbols ();

at the end of the 'PKG_ADD' file?

S?ren


From highegg at gmail.com  Sun Sep 27 04:06:51 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 27 Sep 2009 11:06:51 +0200
Subject: sub2ind fails with single-dimensional input
In-Reply-To: <4ABE7FDA.4090300@tin.it>
References: <4ABE7FDA.4090300@tin.it>
Message-ID: <69d8d540909270206k42c8836ao347ba4a336011151@mail.gmail.com>

On Sat, Sep 26, 2009 at 10:55 PM, Moreno Mazolla <momarzo at tin.it> wrote:
> Bug report for Octave 3.3.50+ configured for x86_64-unknown-linux-gnu
>
> Description:
> -----------
>
> I'm trying the mercurial version of octave:
>
> changeset: ? 9665:1dba57e9d08d
> tag: ? ? ? ? tip
> user: ? ? ? ?Jaroslav Hajek <highegg at gmail.com>
> date: ? ? ? ?Sat Sep 26 10:41:07 2009 +0200
> summary: ? ? use blas_trans_type for xgemm
>
> the sub2ind() function behaves differently than the one from octave
> 3.0.0 which comes with ubuntu 8.04/amd64.
>
> * On octave 3.0.0 the sub2ind( [6], 5 ) call works as expected:
>
> octave:3> version
> ans = 3.0.0
> octave:4> sub2ind( [6], 5 )
> ans = ?5
>
> * On the mercurial version, the same call fails:
>
> octave:1> version
> ans = 3.3.50+
> octave:2> sub2ind( [6], 5 )
> error: Invalid call to sub2ind. ?Correct usage is:
>
> ?-- Function File: IND = sub2ind (DIMS, I, J)
> ?-- Function File: IND = sub2ind (DIMS, S1, S2, ..., SN)
>
> Note that the mercurial version works if the first parameter has more
> than one element, as follows:
>
> octave:2> sub2ind( [5 6], 3, 2 )
> ans = ?8
>
> Note that this behaviour is somewhat consistent with the documentation,
> wihch suggests that at least three input parameters must be passed to
> the sub2ind function. However, I suggest that both the documentation and
> the implementation of the sub2ind() function be adapted to the simple
> case when the "dims" vector has just one element.
>
> Repeat-By:
> ---------
>
> Issue the command:
>
> sub2ind( [6], 5 )
>
> with the mercurial version of octave.
>

On the contrary, [6] is not a valid dimension vector - arrays have
always at least 2 dimensions; besides, sub2ind ([n], x) does not
really do anything useful.
But I suppose that if Matlab allows this (which it seems so), Octave
should as well, if it doesn't hurt.

-- 
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  Sun Sep 27 04:28:22 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 27 Sep 2009 11:28:22 +0200
Subject: sub2ind fails with single-dimensional input
In-Reply-To: <69d8d540909270206k42c8836ao347ba4a336011151@mail.gmail.com>
References: <4ABE7FDA.4090300@tin.it>
	<69d8d540909270206k42c8836ao347ba4a336011151@mail.gmail.com>
Message-ID: <69d8d540909270228t39488142rafe39f361e820b73@mail.gmail.com>

On Sun, Sep 27, 2009 at 11:06 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Sat, Sep 26, 2009 at 10:55 PM, Moreno Mazolla <momarzo at tin.it> wrote:
>> Bug report for Octave 3.3.50+ configured for x86_64-unknown-linux-gnu
>>
>> Description:
>> -----------
>>
>> I'm trying the mercurial version of octave:
>>
>> changeset: ? 9665:1dba57e9d08d
>> tag: ? ? ? ? tip
>> user: ? ? ? ?Jaroslav Hajek <highegg at gmail.com>
>> date: ? ? ? ?Sat Sep 26 10:41:07 2009 +0200
>> summary: ? ? use blas_trans_type for xgemm
>>
>> the sub2ind() function behaves differently than the one from octave
>> 3.0.0 which comes with ubuntu 8.04/amd64.
>>
>> * On octave 3.0.0 the sub2ind( [6], 5 ) call works as expected:
>>
>> octave:3> version
>> ans = 3.0.0
>> octave:4> sub2ind( [6], 5 )
>> ans = ?5
>>
>> * On the mercurial version, the same call fails:
>>
>> octave:1> version
>> ans = 3.3.50+
>> octave:2> sub2ind( [6], 5 )
>> error: Invalid call to sub2ind. ?Correct usage is:
>>
>> ?-- Function File: IND = sub2ind (DIMS, I, J)
>> ?-- Function File: IND = sub2ind (DIMS, S1, S2, ..., SN)
>>
>> Note that the mercurial version works if the first parameter has more
>> than one element, as follows:
>>
>> octave:2> sub2ind( [5 6], 3, 2 )
>> ans = ?8
>>
>> Note that this behaviour is somewhat consistent with the documentation,
>> wihch suggests that at least three input parameters must be passed to
>> the sub2ind function. However, I suggest that both the documentation and
>> the implementation of the sub2ind() function be adapted to the simple
>> case when the "dims" vector has just one element.
>>
>> Repeat-By:
>> ---------
>>
>> Issue the command:
>>
>> sub2ind( [6], 5 )
>>
>> with the mercurial version of octave.
>>
>
> On the contrary, [6] is not a valid dimension vector - arrays have
> always at least 2 dimensions; besides, sub2ind ([n], x) does not
> really do anything useful.
> But I suppose that if Matlab allows this (which it seems so), Octave
> should as well, if it doesn't hurt.
>


Fix is upstream:
http://hg.savannah.gnu.org/hgweb/octave/rev/a531dec450c4

thanks

-- 
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  Sun Sep 27 10:34:22 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 27 Sep 2009 17:34:22 +0200
Subject: Cannot rotate 3D plots by setting 'cameraposition'
Message-ID: <1254065662.4424.76.camel@sh-t400>

Hi All

In a quite recent checkout, I seem to have some difficulties using the
'cameraposition' axes property on 3D plots.

The following code

  ## Construct rotation matrix
  t = 0.05;
  R = [cos(t), -sin(t), 0; sin(t), cos(t), 0; 0, 0, 1];
  
  ## Show figure
  sombrero ();
  
  ## Rotate
  for k = 1:100
    cp = get (gca, "cameraposition") * R;
    set (gca, "cameraposition", cp);
    drawnow ();
  endfor

doesn't really seem to do anything (on both graphics backends). It
should make an animation of a rotating sombrero.

S?ren


From M.Rupniewski at ise.pw.edu.pl  Sun Sep 27 12:03:19 2009
From: M.Rupniewski at ise.pw.edu.pl (Marek Rupniewski)
Date: Sun, 27 Sep 2009 19:03:19 +0200
Subject: loading strings from hdf5 files
Message-ID: <20090927170319.GA18838@lis>

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

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

  I load an hdf5 file with a Dataset of type (given by h5ls -v ...) '256-byte null-padded
  ASCII string' (same happens for null-terminated ASCII strings) I get an
  octave string variable of length 256 (as expected) that coincides with the
  string in the hdf5 file up to (but excluding) the first occurrence of the null
  in the hdf5 string Dataset. The rest of the octave string is as random as can
  an uninitialized piece of memory be. In particular, sometimes the octave
  string is correctly null-padded.

Repeat-By:
---------
    load string.h5;        % string.h5 consists of one dataset that is of name
                           %'strexamp' and of the value 'an example' followed
                           % by 245 nulls. Below I copy the output of h5ls command
%h5ls -dv string.h5 
%Opened "string.h5" with sec2 driver.
%strexamp                   Dataset {1/1}
%    Location:  1:800
%    Links:     1
%    Storage:   256 logical bytes, 256 allocated bytes, 100.00% utilization
%    Type:      256-byte null-padded ASCII string
%    Data:
%        (0) "an example" '\000' repeats 245 times

% now the value of strexamp is e.g.

int8(strexamp(1:15))    %just to show the problem
ans =

    97   110    32   101   120    97   109   112   108   101    58     9   -12
    42    58

% as I wrote above the values str(11:end) are "random" and you may need to load
% the file a few times in order to get some non-null values.


Fix:
---

  I think you should, either null-pad the loaded variable, or load (copy) the
  whole variable (from the hdf5 file) with all trailing nulls, or create the
  octave variable just enough big to keep the string up to the first occurrence
  of padding (or terminating) null.


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

uname output:     Linux lis 2.6.30-1-686 #1 SMP Sat Aug 15 19:11:58 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-2) 
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.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:/usr/local/bin:/usr/bin:/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/mrupniew/.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 = <no value or error in displaying it>
  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 hallc at lu.unisi.ch  Mon Sep 28 03:47:29 2009
From: hallc at lu.unisi.ch (Cyrus Hall)
Date: Mon, 28 Sep 2009 10:47:29 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
Message-ID: <1254127649.10433.2.camel@boulder>

Ciao all-

I have tried to build both Octave 3.2.2 and 3.2.3 from source on Ubuntu
9.04, as the 3.0 does not contain functionality I desire (mainly, good
support for sparse matrices).  Unfortunately, both builds fail the same
number of tests when make check is run:

...
src/DLD-FUNCTIONS/eig.cc ............................... PASS   15/20
FAIL 5
src/DLD-FUNCTIONS/eigs.cc .............................. PASS   99/149
FAIL 50
...

In my search of the list I did not find similar reports.  A few of the
failures appear trivial, and possibly not important.  For example:

 A = [1, 2; -1, 1]; B = [3, 3; 1, 2];
 [v, d] = eig (A, B);
 assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
 assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
!!!!! test failed
assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
   1.5000 + 0.0000i
   1.5000 + 0.0000i
but got
   1.5000 - 0.0000i
   1.5000 - 0.0000i
maximum absolute error 2.93328e-08 exceeds tolerance 1.49012e-08  *****
test

However, the majority appear a little bit more serious:

 A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
 [v, d] = eig (A, B);
 assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
 assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
!!!!! test failed
assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
    505.39 -  185.76i
  -1489.28 + 1353.70i
but got
   1.11867 - 0.17754i
   0.11721 + 2.41487i
maximum absolute error 2011.04 exceeds tolerance 1.49012e-08  ***** test

In the case of the eigs failures, all the messages are of the form

  eigs: error -9999 in xxxxxx

where xxxxxx is something is either znaupd or dsaupd.  This feels like a
linking issue, or maybe a version issue, yet 99 of the tests pass.

The build of both versions fairly normal.  I'm using the ubuntu provided
versions of all dependencies, and did not provide qrupdate.  Indeed, I
don't know how slow the old QR routines are, but that section of make
test script does not seem to ever finish.  The log of the tests that do
finish is posted at

  http://www.inf.unisi.ch/phd/hall/octave-3.2.3-make-test.log

The 3.2.2 log is at

  http://www.inf.unisi.ch/phd/hall/octave-3.2.2-make-test.log

There are only slight difference, which diff shows handily.  That 3.2.2
build *was* built with qrupdate.

Both builds and test runs were performed on a Intel Core Duo.  Configure
was called with:

LDFLAGS="-lmetis" ./configure --prefix=/home/hallcp/sw --enable-shared 

as metis was not correctly linking when make tried to create the final
octave binary.

I am more than willing to provide more details as I would love to have a
eigs (and eig) that pass all tests.

Cheers,
Cyrus Hall
University of Lugano



From hallc at lu.unisi.ch  Mon Sep 28 04:05:13 2009
From: hallc at lu.unisi.ch (Cyrus Hall)
Date: Mon, 28 Sep 2009 11:05:13 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <1254127649.10433.2.camel@boulder>
References: <1254127649.10433.2.camel@boulder>
Message-ID: <1254128713.10433.8.camel@boulder>

I had not noticed until just now that some of the tests do not fail with
the same incorrect values each time they are run:

octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
octave:2>  [v, d] = eig (A, B);
octave:3>  assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
  -5.1989 + 1.5530i
  -3.7537 + 1.7986i
but got
  -2.3455 - 3.3422i
  -2.4744 - 1.3489i
maximum absolute error 5.66616 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5
octave:3>  assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
   1.8875 - 1.1145i
  -1.9578 + 0.7916i
but got
  -0.5970 + 2.1114i
   1.1474 - 3.3054i
maximum absolute error 5.14083 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5

But then if I restart Octave 3.2.3 and try again...

octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
octave:2>  [v, d] = eig (A, B);
octave:3>  assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
  -5.2519 + 1.6063i
  -3.8228 + 1.8480i
but got
  -2.3842 - 3.3836i
  -2.5070 - 1.3848i
maximum absolute error 5.75526 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5
octave:3>  assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
   1.9083 - 1.1113i
  -1.9813 + 0.7892i
but got
  -0.6050 + 2.1255i
   1.1543 - 3.3355i
maximum absolute error 5.18123 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5

I assume this could be due to some sort of random initialization in
ARPACK, but it would seem that any difference in the final result should
be smaller than sqrt(eps).

Cheers,
Cyrus


From aleksandr_sinicyn at fastmail.net  Mon Sep 28 01:56:14 2009
From: aleksandr_sinicyn at fastmail.net (Aleksandr)
Date: Sun, 27 Sep 2009 23:56:14 -0700 (PDT)
Subject: contourf and axis
In-Reply-To: <alpine.DEB.1.00.0906181333340.23379@profs.sci.univr.it>
References: <alpine.DEB.1.00.0906181333340.23379@profs.sci.univr.it>
Message-ID: <25641389.post@talk.nabble.com>




Marco Caliari-4 wrote:
> 
> Dear maintainers,
> 
> when I execute
> 
> contourf(peaks),axis([10,20,10,20])
> 
> I get the strange picture you can see here: 
> http://157.27.10.252/~caliari/contourfaxis.png
> both with 3.2.0 and 3.0.5 (gnuplot 4.2.5).
> 
> Best regards,
> 
> Marco
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 
> 

The same thing sometimes happens to "fill", for example:

fill ([0 2 0], [-2 5 5], "b"), axis ([0 5 0 7])

produces rather strange picture.

But when axes do not intersect the polygon that is to be filled then
everything works fine:

fill ([0 2 0], [-2 5 5], "b"), axis ([0 5 -2 7])

-- 
View this message in context: http://www.nabble.com/contourf-and-axis-tp24091249p25641389.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From jwe at octave.org  Mon Sep 28 15:05:34 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 28 Sep 2009 16:05:34 -0400
Subject: Cannot rotate 3D plots by setting 'cameraposition'
In-Reply-To: <1254065662.4424.76.camel@sh-t400>
References: <1254065662.4424.76.camel@sh-t400>
Message-ID: <19137.5902.22393.883521@segfault.lan>

On 27-Sep-2009, S?ren Hauberg wrote:

| Hi All
| 
| In a quite recent checkout, I seem to have some difficulties using the
| 'cameraposition' axes property on 3D plots.
| 
| The following code
| 
|   ## Construct rotation matrix
|   t = 0.05;
|   R = [cos(t), -sin(t), 0; sin(t), cos(t), 0; 0, 0, 1];
|   
|   ## Show figure
|   sombrero ();
|   
|   ## Rotate
|   for k = 1:100
|     cp = get (gca, "cameraposition") * R;
|     set (gca, "cameraposition", cp);
|     drawnow ();
|   endfor
| 
| doesn't really seem to do anything (on both graphics backends). It
| should make an animation of a rotating sombrero.

I guess this is just a missing feature.  It is possible to rotate a
figure using the view property:

  ## Show figure
  sombrero ();
  axis equal
  grid off
  
  ## Rotate
  for k = 1:1000
    v = get (gca, "view") + 1;
    set (gca, "view", v);
    drawnow ();
  endfor

However, I see that the view property is marked as obsolete in the
Matlab docs now.  So I suppose some translation from the camera <->
view properties is needed.

If view changes, which camera properties should change, and how?

If the camera properties change, should the view property be modified?

jwe


From soren at hauberg.org  Mon Sep 28 15:32:16 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Mon, 28 Sep 2009 22:32:16 +0200
Subject: Cannot rotate 3D plots by setting 'cameraposition'
In-Reply-To: <19137.5902.22393.883521@segfault.lan>
References: <1254065662.4424.76.camel@sh-t400>
	<19137.5902.22393.883521@segfault.lan>
Message-ID: <1254169936.4632.26.camel@sh-t400>

man, 28 09 2009 kl. 16:05 -0400, skrev John W. Eaton:
> I guess this is just a missing feature.  It is possible to rotate a
> figure using the view property:

I must admit that I find the 'view' property very hard to use, which is
why I wanted some more low-level control.

> However, I see that the view property is marked as obsolete in the
> Matlab docs now.  So I suppose some translation from the camera <->
> view properties is needed.
> 
> If view changes, which camera properties should change, and how?

I ran the following program in Matlab

        plot3 (1, 1, 1, '*')
        before = get (gca ());
        [a, e] = view ();
        view (a+1, e+1);
        after = get (gca ());
        for k = 1:length (f)
          if (~isequal (before.(f {k}), after.(f {k})))
            disp (f {k});
          end
        end

to see which properties change when you call 'view'. I got the following
output:

        CameraPosition
        CameraViewAngle
        CurrentPoint
        View

That last one is obvious. For the first three I got:

        before.CameraPosition = 
           -8.1314  -10.9003    9.6603
        
        after.CameraPosition = 
           -7.8311  -10.9345    9.9207
        
        before.CameraViewAngle =
           10.3396
        
        after.CameraViewAngle =
           10.4082
        
        before.CurrentPoint =
          -10.2273  -10.5483    7.9341
           -1.0958    1.3520   -0.7262
        
        after.CurrentPoint =
           -9.9510  -10.6515    8.2008
           -1.1199    1.2830   -0.7199

I must admit that these numbers doesn't make all that much sense to me,
but perhaps they give insights to somebody else.

S?ren


From jwe at octave.org  Mon Sep 28 15:42:54 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 28 Sep 2009 16:42:54 -0400
Subject: Plot Bug: 'markerfacecolor' does not work
In-Reply-To: <Pine.LNX.4.64.0909231039560.11325@monoceros.physics.muni.cz>
References: <4AB8EAD3.9070805@chalmers.se> <4AB924F7.8060104@dbateman.org>
	<4AB92AE1.7030806@dbateman.org>
	<Pine.LNX.4.64.0909231039560.11325@monoceros.physics.muni.cz>
Message-ID: <19137.8142.214670.828607@segfault.lan>

On 23-Sep-2009, Petr Mikulik wrote:

| > > > 'markerfacecolor' does not work e.g. in the following plot-command:
| > > > plot(x, y, 'bo', 'markerfacecolor', 'r');
| > > > The data points are still blue, but should be red.
| > >
| > > At the moment the gnuplot backend uses a single plot command for each line
| > > to gnuplot.. Gnuplot doesn't specify the line and point colour separately so
| > > as you found the markerfacecolor property is not respected.. We could quite
| > > easily modify the gnuplot backend code to use two separate gnuplot lines for
| > > each line to get the desired effect...
| > >   
| > I have no desire (or time) to fully test the attached patch, but something
| > like this should give the behavior you want.. Does someone want to test this
| > patch further and maybe commit  it?
| 
| This patch changes colour of symbols to red instead of just "filling" it 
| with red.
| 
| Two plot commands are really necessary: if "markerfacecolor" is set and 
| gnuplot point type is n=4,6,8,10,12 (diamonds, circles, triangles, ...), 
| then:
| 	plot _data_ with point pt n+1 lc rgb _markerfacecolor_, \
| 	     _data_ with point pt n   lc rgb _point_color_

I have no plans to do any more work on the gnuplot backend myself, but
would consider a patch that uses this method.

Thanks,

jwe

From jwe at octave.org  Mon Sep 28 15:37:04 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 28 Sep 2009 16:37:04 -0400
Subject: problem with path.
In-Reply-To: <1253869455.21323.19.camel@localhost.localdomain>
References: <1253869455.21323.19.camel@localhost.localdomain>
Message-ID: <19137.7792.387896.223352@segfault.lan>

On 25-Sep-2009, "Peter L." S?ndergaard wrote:

| I am using Octave 3.0.5, bundled with Fedora core 11.
| 
| The following code fails:
| 
| p=path;
| path(p);

I don't see a problem with this on my system.  For me, with either
3.0.5 or 3.2.0

  p = path;
  path (p);
  p2 = path;
  assert (p, p2)

succeeds.

| producing the output:
| 
| ann =
| 
| {
|   ANN_BD_CENTROID
|   ANN_BD_NONE
|   ANN_BD_SIMPLE
|   ANN_BD_SUGGEST
|   ANN_HI
| 
| .....
| 
|   new_ANNorthRect (global method)
|   new_ANNsampStat (global method)
| }
| 
| The function that I have made that uses the two lines (with code
| inbetween to modify the path temporarily) will sometimes lock octave
| completely, so that I have to abort by pressing Ctrl-C several times.
| 
| The same code work in Matlab.

I don't see how Octave's path function can print a structure
named ANN.  So, I suspect you have another function named path
somewhere in your path that is doing this.  What does

  which path

tell you?

jwe


From jwe at octave.org  Mon Sep 28 15:33:16 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 28 Sep 2009 16:33:16 -0400
Subject: loading strings from hdf5 files
In-Reply-To: <20090927170319.GA18838@lis>
References: <20090927170319.GA18838@lis>
Message-ID: <19137.7564.452148.273335@segfault.lan>

On 27-Sep-2009, Marek Rupniewski wrote:

| Bug report for Octave 3.2.2 configured for i486-pc-linux-gnu
| 
| Description:
| -----------
| 
|   I load an hdf5 file with a Dataset of type (given by h5ls -v ...) '256-byte null-padded
|   ASCII string' (same happens for null-terminated ASCII strings) I get an
|   octave string variable of length 256 (as expected) that coincides with the
|   string in the hdf5 file up to (but excluding) the first occurrence of the null
|   in the hdf5 string Dataset. The rest of the octave string is as random as can
|   an uninitialized piece of memory be. In particular, sometimes the octave
|   string is correctly null-padded.
| 
| Repeat-By:
| ---------
|     load string.h5;        % string.h5 consists of one dataset that is of name
|                            %'strexamp' and of the value 'an example' followed
|                            % by 245 nulls. Below I copy the output of h5ls command
| %h5ls -dv string.h5 
| %Opened "string.h5" with sec2 driver.
| %strexamp                   Dataset {1/1}
| %    Location:  1:800
| %    Links:     1
| %    Storage:   256 logical bytes, 256 allocated bytes, 100.00% utilization
| %    Type:      256-byte null-padded ASCII string
| %    Data:
| %        (0) "an example" '\000' repeats 245 times
| 
| % now the value of strexamp is e.g.
| 
| int8(strexamp(1:15))    %just to show the problem
| ans =
| 
|     97   110    32   101   120    97   109   112   108   101    58     9   -12
|     42    58
| 
| % as I wrote above the values str(11:end) are "random" and you may need to load
| % the file a few times in order to get some non-null values.

Please send an example file that fails, or explain how one can be created.

jwe

From dbateman at dbateman.org  Mon Sep 28 17:09:41 2009
From: dbateman at dbateman.org (David Bateman)
Date: Tue, 29 Sep 2009 00:09:41 +0200
Subject: contourf and axis
In-Reply-To: <25641389.post@talk.nabble.com>
References: <alpine.DEB.1.00.0906181333340.23379@profs.sci.univr.it>
	<25641389.post@talk.nabble.com>
Message-ID: <4AC13425.9020803@dbateman.org>

Aleksandr wrote:
>
> Marco Caliari-4 wrote:
>   
>> Dear maintainers,
>>
>> when I execute
>>
>> contourf(peaks),axis([10,20,10,20])
>>
>> I get the strange picture you can see here: 
>> http://157.27.10.252/~caliari/contourfaxis.png
>> both with 3.2.0 and 3.0.5 (gnuplot 4.2.5).
>>
>> Best regards,
>>
>> Marco
>> _______________________________________________
>> Bug-octave mailing list
>> Bug-octave at octave.org
>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>
>>
>>     
>
> The same thing sometimes happens to "fill", for example:
>
> fill ([0 2 0], [-2 5 5], "b"), axis ([0 5 0 7])
>
> produces rather strange picture.
>
> But when axes do not intersect the polygon that is to be filled then
> everything works fine:
>
> fill ([0 2 0], [-2 5 5], "b"), axis ([0 5 -2 7])
>
>   
What is sent to gnuplot doesn't really change with or without the axis 
command.. I imagine the rendering difference from gnuplot is due to the 
"set clip two" command sent by Octave to gnuplot, that allows lines with 
one point outside of the axis to be plotted correctly. However, from my 
point of view this seems to be a gnuplot bug

D.


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


From highegg at gmail.com  Tue Sep 29 00:18:19 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 07:18:19 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <1254128713.10433.8.camel@boulder>
References: <1254127649.10433.2.camel@boulder>
	<1254128713.10433.8.camel@boulder>
Message-ID: <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>

On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
> I had not noticed until just now that some of the tests do not fail with
> the same incorrect values each time they are run:
>
> octave:1> ?A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
> octave:2> ?[v, d] = eig (A, B);
> octave:3> ?assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
> error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
> ?-5.1989 + 1.5530i
> ?-3.7537 + 1.7986i
> but got
> ?-2.3455 - 3.3422i
> ?-2.4744 - 1.3489i
> maximum absolute error 5.66616 exceeds tolerance 1.49012e-08
> error: called from:
> error: ? /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
> octave:3> ?assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
> error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
> ? 1.8875 - 1.1145i
> ?-1.9578 + 0.7916i
> but got
> ?-0.5970 + 2.1114i
> ? 1.1474 - 3.3054i
> maximum absolute error 5.14083 exceeds tolerance 1.49012e-08
> error: called from:
> error: ? /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
>
> But then if I restart Octave 3.2.3 and try again...
>
> octave:1> ?A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
> octave:2> ?[v, d] = eig (A, B);
> octave:3> ?assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
> error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
> ?-5.2519 + 1.6063i
> ?-3.8228 + 1.8480i
> but got
> ?-2.3842 - 3.3836i
> ?-2.5070 - 1.3848i
> maximum absolute error 5.75526 exceeds tolerance 1.49012e-08
> error: called from:
> error: ? /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
> octave:3> ?assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
> error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
> ? 1.9083 - 1.1113i
> ?-1.9813 + 0.7892i
> but got
> ?-0.6050 + 2.1255i
> ? 1.1543 - 3.3355i
> maximum absolute error 5.18123 exceeds tolerance 1.49012e-08
> error: called from:
> error: ? /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
>
> I assume this could be due to some sort of random initialization in
> ARPACK, but it would seem that any difference in the final result should
> be smaller than sqrt(eps).
>
> Cheers,
> Cyrus
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>

This looks like the known problem of mislinked LAPACK vs. ARPACK. If
you build without ARPACK (configure --without-arpack),
do you still see the problem in eig?
The solution was to rebuild ARPACK against LAPACK 3 no matter what the
ARPACK manual says.

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


From M.Rupniewski at ise.pw.edu.pl  Tue Sep 29 03:17:52 2009
From: M.Rupniewski at ise.pw.edu.pl (Marek Rupniewski)
Date: Tue, 29 Sep 2009 10:17:52 +0200
Subject: loading strings from hdf5 files
In-Reply-To: <19137.7564.452148.273335@segfault.lan>
References: <20090927170319.GA18838@lis>
	<19137.7564.452148.273335@segfault.lan>
Message-ID: <20090929081752.GA12675@lis>

Here, I attach two hdf5 files: string.h5 that I was writing about and
null_term.h5 that consists of a null-terminated string. The former is created
with HDFView, a (Java) Tool from hdfgroup.org. The latter is extracted from an
hdf5 file created under Matlab (I don't know how to create a null-terminated
string under HDFView). The problem I described concerns both the files.

The files can be also downloaded from:
http://staff.elka.pw.edu.pl/~mrupniew/string.h5
http://staff.elka.pw.edu.pl/~mrupniew/null_term.h5

Marek Rupniewski


On Mon, 28 Sep 2009, John W. Eaton wrote:

> On 27-Sep-2009, Marek Rupniewski wrote:
> 
> | Bug report for Octave 3.2.2 configured for i486-pc-linux-gnu
> | 
> | Description:
> | -----------
> | 
> |   I load an hdf5 file with a Dataset of type (given by h5ls -v ...) '256-byte null-padded
> |   ASCII string' (same happens for null-terminated ASCII strings) I get an
> |   octave string variable of length 256 (as expected) that coincides with the
> |   string in the hdf5 file up to (but excluding) the first occurrence of the null
> |   in the hdf5 string Dataset. The rest of the octave string is as random as can
> |   an uninitialized piece of memory be. In particular, sometimes the octave
> |   string is correctly null-padded.
> | 
> | Repeat-By:
> | ---------
> |     load string.h5;        % string.h5 consists of one dataset that is of name
> |                            %'strexamp' and of the value 'an example' followed
> |                            % by 245 nulls. Below I copy the output of h5ls command
> | %h5ls -dv string.h5 
> | %Opened "string.h5" with sec2 driver.
> | %strexamp                   Dataset {1/1}
> | %    Location:  1:800
> | %    Links:     1
> | %    Storage:   256 logical bytes, 256 allocated bytes, 100.00% utilization
> | %    Type:      256-byte null-padded ASCII string
> | %    Data:
> | %        (0) "an example" '\000' repeats 245 times
> | 
> | % now the value of strexamp is e.g.
> | 
> | int8(strexamp(1:15))    %just to show the problem
> | ans =
> | 
> |     97   110    32   101   120    97   109   112   108   101    58     9   -12
> |     42    58
> | 
> | % as I wrote above the values str(11:end) are "random" and you may need to load
> | % the file a few times in order to get some non-null values.
> 
> Please send an example file that fails, or explain how one can be created.
> 
> jwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: string.h5
Type: application/octet-stream
Size: 3104 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090929/5c0a555a/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: null_term.h5
Type: application/octet-stream
Size: 2913 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090929/5c0a555a/attachment-0003.obj 

From michael.goffioul at gmail.com  Tue Sep 29 03:40:19 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Tue, 29 Sep 2009 09:40:19 +0100
Subject: Cannot rotate 3D plots by setting 'cameraposition'
In-Reply-To: <1254169936.4632.26.camel@sh-t400>
References: <1254065662.4424.76.camel@sh-t400>
	<19137.5902.22393.883521@segfault.lan>
	<1254169936.4632.26.camel@sh-t400>
Message-ID: <128f38bd0909290140u3f0e57d9i9722527683a335ba@mail.gmail.com>

When I developed JHandles, I spent loads of time reverse engineering
the way Matlab setup 3D transform automatically. I could get a quite
good picture of it and it's basically implemented in
axes::properties::update_camera().
It's not 100% compatible with Matlab, but it's quite compatible.

I think the fact that changing cameraposition property didn't work
for you is because there's no "updater" defined for that property
in axes::properties. For instance, see what's done for the view
property.

FYI, the transformation that is automatically computed is:
- scales axes to the unit box
- position camera according to view or cameraxxxx properties
- when using view, the camera is looking at the center of the
  axes box and placed at a distance sqrt(75) from it in normalized
  units (sqrt(75) == diagonal of a box with side equal to 5)
- scale X/Y to fit the figure window

Michael.


On Mon, Sep 28, 2009 at 9:32 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> man, 28 09 2009 kl. 16:05 -0400, skrev John W. Eaton:
>> I guess this is just a missing feature. ?It is possible to rotate a
>> figure using the view property:
>
> I must admit that I find the 'view' property very hard to use, which is
> why I wanted some more low-level control.
>
>> However, I see that the view property is marked as obsolete in the
>> Matlab docs now. ?So I suppose some translation from the camera <->
>> view properties is needed.
>>
>> If view changes, which camera properties should change, and how?
>
> I ran the following program in Matlab
>
> ? ? ? ?plot3 (1, 1, 1, '*')
> ? ? ? ?before = get (gca ());
> ? ? ? ?[a, e] = view ();
> ? ? ? ?view (a+1, e+1);
> ? ? ? ?after = get (gca ());
> ? ? ? ?for k = 1:length (f)
> ? ? ? ? ?if (~isequal (before.(f {k}), after.(f {k})))
> ? ? ? ? ? ?disp (f {k});
> ? ? ? ? ?end
> ? ? ? ?end
>
> to see which properties change when you call 'view'. I got the following
> output:
>
> ? ? ? ?CameraPosition
> ? ? ? ?CameraViewAngle
> ? ? ? ?CurrentPoint
> ? ? ? ?View
>
> That last one is obvious. For the first three I got:
>
> ? ? ? ?before.CameraPosition =
> ? ? ? ? ? -8.1314 ?-10.9003 ? ?9.6603
>
> ? ? ? ?after.CameraPosition =
> ? ? ? ? ? -7.8311 ?-10.9345 ? ?9.9207
>
> ? ? ? ?before.CameraViewAngle =
> ? ? ? ? ? 10.3396
>
> ? ? ? ?after.CameraViewAngle =
> ? ? ? ? ? 10.4082
>
> ? ? ? ?before.CurrentPoint =
> ? ? ? ? ?-10.2273 ?-10.5483 ? ?7.9341
> ? ? ? ? ? -1.0958 ? ?1.3520 ? -0.7262
>
> ? ? ? ?after.CurrentPoint =
> ? ? ? ? ? -9.9510 ?-10.6515 ? ?8.2008
> ? ? ? ? ? -1.1199 ? ?1.2830 ? -0.7199
>
> I must admit that these numbers doesn't make all that much sense to me,
> but perhaps they give insights to somebody else.
>
> S?ren
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>


From marco.caliari at univr.it  Tue Sep 29 05:37:03 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Tue, 29 Sep 2009 12:37:03 +0200 (CEST)
Subject: Error with scripts containing only comments
Message-ID: <alpine.DEB.1.00.0909291231210.8182@profs.sci.univr.it>

Dear maintainers,

I noticed that if you run a script, say comment.m, containing only 
comments, such as

% bla bla bla

you get

error: `comment' undefined near line 1 column 1

with Octave 3.2.2, 3.2.3, whereas you get the correct behavior (i.e., 
nothing) with Octave 3.0.5.

Best regards,

Marco

From hallc at lu.unisi.ch  Tue Sep 29 06:17:07 2009
From: hallc at lu.unisi.ch (Cyrus Hall)
Date: Tue, 29 Sep 2009 13:17:07 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>
References: <1254127649.10433.2.camel@boulder>
	<1254128713.10433.8.camel@boulder>
	<69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>
Message-ID: <1254223027.5541.15.camel@boulder>

On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
> > I had not noticed until just now that some of the tests do not fail with
> > the same incorrect values each time they are run.
> 
> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
> you build without ARPACK (configure --without-arpack),
> do you still see the problem in eig?
> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
> ARPACK manual says.

I built without arpack and the problem remains.  The same tests fail,
and the values continue to change each time eig is called.

Any other ideas?

Cheers,
Cyrus


From highegg at gmail.com  Tue Sep 29 06:21:28 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 13:21:28 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <1254223027.5541.15.camel@boulder>
References: <1254127649.10433.2.camel@boulder>
	<1254128713.10433.8.camel@boulder>
	<69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>
	<1254223027.5541.15.camel@boulder>
Message-ID: <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com>

On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
> On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
>> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
>> > I had not noticed until just now that some of the tests do not fail with
>> > the same incorrect values each time they are run.
>>
>> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
>> you build without ARPACK (configure --without-arpack),
>> do you still see the problem in eig?
>> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
>> ARPACK manual says.
>
> I built without arpack and the problem remains. ?The same tests fail,
> and the values continue to change each time eig is called.
>
> Any other ideas?
>
> Cheers,
> Cyrus
>

Can you send your config.log from the latter build?

-- 
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 Sep 29 06:23:17 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 13:23:17 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com>
References: <1254127649.10433.2.camel@boulder>
	<1254128713.10433.8.camel@boulder>
	<69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>
	<1254223027.5541.15.camel@boulder>
	<69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com>
Message-ID: <69d8d540909290423g78c1fd75i6de3b98151d32e46@mail.gmail.com>

On Tue, Sep 29, 2009 at 1:21 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
>> On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
>>> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
>>> > I had not noticed until just now that some of the tests do not fail with
>>> > the same incorrect values each time they are run.
>>>
>>> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
>>> you build without ARPACK (configure --without-arpack),
>>> do you still see the problem in eig?
>>> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
>>> ARPACK manual says.
>>
>> I built without arpack and the problem remains. ?The same tests fail,
>> and the values continue to change each time eig is called.
>>
>> Any other ideas?
>>
>> Cheers,
>> Cyrus
>>
>
> Can you send your config.log from the latter build?
>

Btw., these files are usually huge, so either use a pastebin service
(pastebin.cz, pastebin.ca, pastebin.com...) or compress it.


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


From hallc at lu.unisi.ch  Tue Sep 29 06:43:24 2009
From: hallc at lu.unisi.ch (Cyrus Hall)
Date: Tue, 29 Sep 2009 13:43:24 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com>
References: <1254127649.10433.2.camel@boulder>
	<1254128713.10433.8.camel@boulder>
	<69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>
	<1254223027.5541.15.camel@boulder>
	<69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com>
Message-ID: <1254224604.5541.19.camel@boulder>

On Tue, 2009-09-29 at 13:21 +0200, Jaroslav Hajek wrote:
> On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
> > On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
> >> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
> >> > I had not noticed until just now that some of the tests do not fail with
> >> > the same incorrect values each time they are run.
> >>
> >> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
> >> you build without ARPACK (configure --without-arpack),
> >> do you still see the problem in eig?
> >> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
> >> ARPACK manual says.
> >
> > I built without arpack and the problem remains.  The same tests fail,
> > and the values continue to change each time eig is called.
> >
> > Any other ideas?
> >
> > Cheers,
> > Cyrus
> >
> 
> Can you send your config.log from the latter build?

Sure. I've posted it at:

http://www.inf.unisi.ch/phd/hall/octave-3.2.3-noarpack-config.log

Cheers,
Cyrus


From mikulik at physics.muni.cz  Tue Sep 29 06:46:07 2009
From: mikulik at physics.muni.cz (Petr Mikulik)
Date: Tue, 29 Sep 2009 13:46:07 +0200 (CEST)
Subject: contourf and axis
In-Reply-To: <4AC13425.9020803@dbateman.org>
References: <alpine.DEB.1.00.0906181333340.23379@profs.sci.univr.it>
	<25641389.post@talk.nabble.com> <4AC13425.9020803@dbateman.org>
Message-ID: <Pine.LNX.4.64.0909291342310.21440@monoceros.physics.muni.cz>

> >> contourf(peaks),axis([10,20,10,20])
> >>
> >> I get the strange picture you can see here: 
> >> http://157.27.10.252/~caliari/contourfaxis.png
> >> both with 3.2.0 and 3.0.5 (gnuplot 4.2.5).
> >
> > The same thing sometimes happens to "fill", for example:
> > fill ([0 2 0], [-2 5 5], "b"), axis ([0 5 0 7])
> > produces rather strange picture.
> >
> > But when axes do not intersect the polygon that is to be filled then
> > everything works fine:
> > fill ([0 2 0], [-2 5 5], "b"), axis ([0 5 -2 7])
> >
> >   
> What is sent to gnuplot doesn't really change with or without the axis 
> command.. I imagine the rendering difference from gnuplot is due to the 
> "set clip two" command sent by Octave to gnuplot, that allows lines with 
> one point outside of the axis to be plotted correctly. However, from my 
> point of view this seems to be a gnuplot bug.

Yes, it's a gnuplot bug: intersection of polygons with axes is not 
implemented at all. The "fill" command of Octave uses
"plot ... with filledcurves"; according to "help filledcurve" of gnuplot:

   Zooming a filled curve drawn from a datafile may produce empty or 
   incorrect areas because gnuplot is clipping points and lines, and not 
   areas.

Contribution to gnuplot which will add this type of clipping will be very 
welcome.

---
PM

From highegg at gmail.com  Tue Sep 29 06:53:31 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 13:53:31 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <1254224604.5541.19.camel@boulder>
References: <1254127649.10433.2.camel@boulder>
	<1254128713.10433.8.camel@boulder>
	<69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>
	<1254223027.5541.15.camel@boulder>
	<69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com>
	<1254224604.5541.19.camel@boulder>
Message-ID: <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com>

On Tue, Sep 29, 2009 at 1:43 PM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
> On Tue, 2009-09-29 at 13:21 +0200, Jaroslav Hajek wrote:
>> On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
>> > On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
>> >> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc at lu.unisi.ch> wrote:
>> >> > I had not noticed until just now that some of the tests do not fail with
>> >> > the same incorrect values each time they are run.
>> >>
>> >> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
>> >> you build without ARPACK (configure --without-arpack),
>> >> do you still see the problem in eig?
>> >> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
>> >> ARPACK manual says.
>> >
>> > I built without arpack and the problem remains. ?The same tests fail,
>> > and the values continue to change each time eig is called.
>> >
>> > Any other ideas?
>> >
>> > Cheers,
>> > Cyrus
>> >
>>
>> Can you send your config.log from the latter build?
>
> Sure. I've posted it at:
>
> http://www.inf.unisi.ch/phd/hall/octave-3.2.3-noarpack-config.log
>
> Cheers,
> Cyrus


I see nothing suspicious. If you have valgrind installed, please try

octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
octave:2>  [v, d] = eig (A, B);

with ./run-octave -valgrind

and post all messages that appear *after* the initial prompt. This can
discover whether you're having an invalid memory access.

hth

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


From hallc at lu.unisi.ch  Tue Sep 29 07:37:46 2009
From: hallc at lu.unisi.ch (Cyrus Hall)
Date: Tue, 29 Sep 2009 14:37:46 +0200
Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check
In-Reply-To: <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com>
References: <1254127649.10433.2.camel@boulder>
	<1254128713.10433.8.camel@boulder>
	<69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com>
	<1254223027.5541.15.camel@boulder>
	<69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com>
	<1254224604.5541.19.camel@boulder>
	<69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com>
Message-ID: <1254227866.5541.26.camel@boulder>

On Tue, 2009-09-29 at 13:53 +0200, Jaroslav Hajek wrote:
> I see nothing suspicious. If you have valgrind installed, please try
> 
> octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
> octave:2>  [v, d] = eig (A, B);
> 
> with ./run-octave -valgrind
> 
> and post all messages that appear *after* the initial prompt. This can
> discover whether you're having an invalid memory access.
> 
> hth

Wow, the number of jumps that depend on uninitialized values in LAPACK
is concerning.  The output was so large that I've uploaded it:

http://www.inf.unisi.ch/phd/hall/octave-3.2.3-valgrind

Note that the input is not listed in the dump as it was piped to octave
via redirection.  The script consists of your two suggested lines:

A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
[v, d] = eig (A, B);

All of the output after the octave prints the header comes after the
second line in the script is executed.

Cheers,
Cyrus


From kai.habel at gmx.de  Wed Sep 30 13:15:11 2009
From: kai.habel at gmx.de (Kai Habel)
Date: Wed, 30 Sep 2009 20:15:11 +0200
Subject: error() incompatibility
Message-ID: <4AC3A02F.3030102@gmx.de>

Hello,

while playing with the optilux package (http://optilux.sourceforge.net/) 
I noticed the following incompatibility.

When the error() function is called with an empty string octave exits 
and prints the error message "error:", while matlab consideres this as a 
special case and continues to run without raising an error.

The actual code, which uses this special case is:

error(nargchk(3,5,nargin));

I am using 3.2.2 on Windows at the moment and cannot check if this also 
applies to to 3.3.50+

Kai




From g.l.ingram at durham.ac.uk  Wed Sep 30 08:02:29 2009
From: g.l.ingram at durham.ac.uk (Grant Ingram)
Date: Wed, 30 Sep 2009 14:02:29 +0100
Subject: griddata fails with same size interpolation vectors
Message-ID: <4AC356E5.1040405@durham.ac.uk>

Dear Octave,

This didn't appear to get through the "bug-report" function.  I can also 
report the same error message with octave-3.2.3 now that I have managed 
to compile and run it.

Bug report for Octave 3.0.5 configured for x86_64-redhat-linux-gnu

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

The griddata function: griddata(x,y,z,xi,yi,method) won't work if xi and
yi are vectors of the same size.

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

This sequence of commands will fail:

rand("state",1);
x=2*rand(100,1)-1;
y=2*rand(size(x))-1;
z=sin(2*(x.^2+y.^2));
xi = linspace(-1,1,10);
yi = linspace(-1,1,10);
zi = griddata(x,y,z,xi,yi,"linear");
mesh(xi,yi,zi);
print("griddata_check.eps","-depsc2");

Producing the following output:
error: product: nonconformant arguments (op1 is 7x1, op2 is 1x7)
error: evaluating binary operator `.*' near line 111, column 25
error: evaluating binary operator `+' near line 111, column 37
error: evaluating binary operator `+' near line 111, column 57
error: evaluating prefix operator `-' near line 111, column 17
error: evaluating binary operator `./' near line 111, column 63
error: evaluating assignment expression near line 111, column 15
error: evaluating if command near line 70, column 3
error: called from `griddata' in file
`/usr/share/octave/3.0.5/m/geometry/griddata.m'
error: evaluating assignment expression near line 10, column 4
error: near line 10 of file `griddata_check.m'

Whereas changing the fifth line in the above script to xi =
linspace(-1,1,9) will produce an output without error.

In /usr/share/octave/3.0.5/m/geometry/griddata.m if
the vectors are not of the same length meshgrid is called, but if they
aren't they are left as is.  I'm now somewhat out of my depth... but a
quick review of the changes to griddata.m in the repository doesn't
suggest that this will work in a newer version.  I am compiling
octave-3.2.3 and will report if this fixes the problem in any case.







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

uname output:     Linux engpc321.eng.ad.dur.ac.uk 
2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27 21:39:52 EDT 2009 x86_64 
x86_64 x86_64 GNU/Linux
configure opts:   '--build=x86_64-redhat-linux-gnu' 
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-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/lib64' 
'--libexecdir=/usr/libexec' '--localstatedir=/var' 
'--sharedstatedir=/var/lib' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--enable-shared' '--disable-static' 
'--enable-64=no' '--with-f77=gfortran' 
'build_alias=x86_64-redhat-linux-gnu' 
'host_alias=x86_64-redhat-linux-gnu' 
'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic' 
'CPPFLAGS=-DH5_USE_16_API' 'CXXFLAGS=-O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic' 'FFLAGS=-O2 -g -pipe 
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/lib64/gfortran/modules'
Fortran compiler: gfortran
FFLAGS:           -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 
-mtune=generic -I/usr/lib64/gfortran/modules
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -L/usr/lib/gcc/x86_64-redhat-linux/4.4.0 
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../lib64 
-L/lib/../lib64 -L/usr/lib/../lib64 
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../.. -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.0 20090409 (Red Hat 4.4.0-0.32) (GCC)
CFLAGS:           -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.4.0
CXXFLAGS:         -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib64/octave-3.0.5
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=unknown -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_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_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=8 -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 = nano
   EXEC_PATH = 
/usr/libexec/octave/3.0.5/site/exec/x86_64-redhat-linux-gnu:/usr/libexec/octave/api-v32/site/exec/x86_64-redhat-linux-gnu:/usr/libexec/octave/site/exec/x86_64-redhat-linux-gnu:/usr/libexec/octave/3.0.5/exec/x86_64-redhat-linux-gnu:/usr/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/des0gli/bin
   IMAGE_PATH = .:/usr/share/octave/3.0.5/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/des0gli/.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 = 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

-- 
Grant Ingram
School of Engineering and Computing Sciences
Durham University
g.l.ingram at durham.ac.uk +44 (0)191 3342428

From m-wright at eskimo.com  Wed Sep 30 15:00:01 2009
From: m-wright at eskimo.com (Maynard Wright)
Date: Wed, 30 Sep 2009 13:00:01 -0700
Subject: inverted order of evaluation for multiple exponentiations
Message-ID: <200909301300.02357.m-wright@eskimo.com>

To: bug at octave.org
Cc: mwright
Subject: inverted order of evaluation for multiple exponentiations
--------
Bug report for Octave 3.0.0 configured for i686-pc-linux-gnu

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

  Although the manual (Section 8.8) specifies that multiple
  exponentiation operators are to be evaluated right-to-left,
  Octave 3.0.0 evalutates them left-to-right. This is also true
  of Octave 2.1.72. This applies to both "^" and "**" operators.

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

  3^3^3 returns the same value as does (3^3)^3. To conform with the
  manual, 3^3^3 should return the same value as does 3^(3^3).  The
  right-to-left associativity specified in the manual is the same
  as the behavior exhibited by Fortran (66 through 2008) and Python.
  I believe that it is also the behavior specified by ISO for 
  associativity of mathematical operators. 

Fix:
---

  I believe it would be best to change Octave to conform with the
  manual with respect to the exponentiation operator.  From my
  viewpoint, changing the manual to match Octave's behavior would
  be equally acceptable, but would not cause Octave to conform to
  what I think the ISO standard requires.
  

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

uname output:     Linux localhost.localdomain 2.4.18-14 #1 Wed Sep 4 13:35:50 
EDT 2002 i686 i686 i386 GNU/Linux
configure opts:   
Fortran compiler: g77
FFLAGS:           -O -mieee-fp
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -L/usr/lib/gcc-lib/i386-redhat-linux/3.2 -L/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../.. -lfrtbegin -lg2c -lm
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
CFLAGS:           -g -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 3.2
CXXFLAGS:         -g -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:          
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/local/lib/octave-3.0.0
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        
LIBS:             -lreadline  -lncurses -ldl -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_BROKEN_REINTERPRET_CAST=1
  -DCXX_ABI=gnu_v3 -DHAVE_LIBM=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1
  -DHAVE_REGEXEC=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=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_VARARGS_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.0/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.0/exec/i686-pc-linux-gnu:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/home/mwright/bin:/home/mwright/octave:/usr/local/bin
  IMAGE_PATH = .:/usr/local/share/octave/3.0.0/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/mwright/.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

From jwe at octave.org  Wed Sep 30 15:19:11 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 30 Sep 2009 16:19:11 -0400
Subject: error() incompatibility
In-Reply-To: <4AC3A02F.3030102@gmx.de>
References: <4AC3A02F.3030102@gmx.de>
Message-ID: <19139.48447.692264.681099@segfault.lan>

On 30-Sep-2009, Kai Habel wrote:

| while playing with the optilux package (http://optilux.sourceforge.net/) 
| I noticed the following incompatibility.
| 
| When the error() function is called with an empty string octave exits 
| and prints the error message "error:", while matlab consideres this as a 
| special case and continues to run without raising an error.
| 
| The actual code, which uses this special case is:
| 
| error(nargchk(3,5,nargin));
| 
| I am using 3.2.2 on Windows at the moment and cannot check if this also 
| applies to to 3.3.50+

I checked in the following change.

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

Since this incompatibity is not a regression and my proposed fix may
have some unintended consequences, I'd recommend not applying this to
the 3.2.x branch until it is better tested.

jwe