From highegg at gmail.com  Tue Sep  1 03:16:04 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 1 Sep 2009 10:16:04 +0200
Subject: 3.2.3 RC2
Message-ID: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>

hi all,

the 3.2.3 RC2 tarballs are available:
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

changes since RC1:

changeset:   9412:8e69b1d41c03
tag:         3-2-3-rc1
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Mon Aug 24 10:06:52 2009 +0200
summary:     fix typo in acx_blas_f77_func.m4

changeset:   9413:ec70e577f419
user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
date:        Thu Aug 13 20:20:32 2009 +0200
summary:     skip double declaration of tztime

changeset:   9414:edb25fa5e7d5
user:        John W. Eaton <jwe at octave.org>
date:        Tue Aug 25 10:26:01 2009 +0200
summary:     imread.m: undo unintended change

changeset:   9415:f0538a1bb518
user:        John W. Eaton <jwe at octave.org>
date:        Tue Aug 25 10:26:01 2009 +0200
summary:     __magick_read__.cc: undo unintended change

changeset:   9416:7ed8182b783d
user:        John W. Eaton <jwe at octave.org>
date:        Wed Aug 26 08:17:08 2009 +0200
summary:     try to avoid gnuplot zombies

changeset:   9417:b6ba353db762
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Wed Aug 26 08:17:08 2009 +0200
summary:     fix order of args in fmod

changeset:   9418:68f62a3337f5
user:        Rob Mahurin <rob at utk.edu>
date:        Wed Aug 26 08:17:08 2009 +0200
summary:     syscalls.cc: Recommend waitpid() in popen2() documentation.

changeset:   9419:7b5edf098210
user:        Olaf Till <olaf.till at uni-jena.de>
date:        Tue Sep 01 09:25:53 2009 +0200
summary:     fix griddata

changeset:   9420:abe96098735c
user:        John W. Eaton <jwe at octave.org>
date:        Tue Sep 01 09:26:33 2009 +0200
summary:     std.m: correctly work along singleton dimension

changeset:   9421:24266b7cd4ea
user:        E. Joshua Rigler <relgire at gmail.com>
date:        Tue Sep 01 09:31:39 2009 +0200
summary:     datestr: set tm.isdst to -1 before calling mktime

changeset:   9422:0ac625218cbc
user:        John W. Eaton <jwe at octave.org>
date:        Tue Sep 01 09:31:39 2009 +0200
summary:     datestr: add missing semicolon

changeset:   9423:8fd98b0a62a0
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Tue Sep 01 09:32:38 2009 +0200
summary:     fix int2str

changeset:   9424:4395054a49ba
tag:         qparent
tag:         3-2-3-rc2
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Tue Sep 01 09:35:17 2009 +0200
summary:     fix current class method determination


regards

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

From tmacchant at yahoo.co.jp  Tue Sep  1 05:47:05 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 1 Sep 2009 19:47:05 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
Message-ID: <20090901104705.23108.qmail@web3811.mail.bbt.yahoo.co.jp>

Today I have noticed that mouse zoom in 2D plot cannot possible for 3.2.3RC1 built by GCC-4.4.0-MinGW
(Offcial). I have already deleted 3.2.2 built myself so that  I rebuilt it.  I have just confirmed
that the mouse zoom works well on 3.2.2 not only Benjamin's binaries (octave-3.2.2/mingw32) but also
mine.    

--- Jaroslav Hajek <highegg at gmail.com> wrote:

> 
> changeset:   9416:7ed8182b783d
> user:        John W. Eaton <jwe at octave.org>
> date:        Wed Aug 26 08:17:08 2009 +0200
> summary:     try to avoid gnuplot zombies

Is the changeset above for the mouse zooming issue that I have met ?

Anyway I will try the source of 3.2.3 RC-2 and report the results here.

Regards

Tatsuro 

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

From jwe at octave.org  Tue Sep  1 13:41:42 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 1 Sep 2009 14:41:42 -0400
Subject: Building octave with large matrices support
In-Reply-To: <19099.17618.522287.15860@segfault.lan>
References: <def1d5650908241312l1a54f811vce91ced6b33afae8@mail.gmail.com>
	<69d8d540908250020w58eb4fdci54a81a5bf25f4662@mail.gmail.com>
	<19093.39315.466708.135278@segfault.lan>
	<69d8d540908270400jfb1d72ble72aaafc4f8a2c68@mail.gmail.com>
	<19094.63881.529202.480384@segfault.lan>
	<69d8d540908272318k288eb06fgc343d06a5979d3e@mail.gmail.com>
	<19099.17618.522287.15860@segfault.lan>
Message-ID: <19101.27366.172821.712255@segfault.lan>

As a start for checking consistency of integer sizes at compile time,
I checked in the following change:

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

If configuring with the --enable-64 option fails to detect the proper
size integer and we are using gfortran, then -fdefault-integer-8 is
added to FFLAGS if it is not already there.  Checks for other
compilers could be added, but I don't know what the compiler names or
options should be.

jwe

From lindnerben at gmx.net  Tue Sep  1 15:39:13 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 01 Sep 2009 22:39:13 +0200
Subject: 3.2.3 RC2
In-Reply-To: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
Message-ID: <4A9D8671.7050007@gmx.net>

Jaroslav Hajek wrote:
> hi all,
> 
> the 3.2.3 RC2 tarballs are available:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

Builds fine using mingw32 TDM-gcc-4.3.0-3.
Make check shows the already known failures.

However, as Tatsuro already pointed out, gnuplot does no longer allow 
interaction with either keyboard (e.g. grid on/of) or mouse (e.g. 
zooming). I tested this with the 2009-july-08 development binaries and a 
local build from the CVS snapshot of the same date.

This is quite a serious regression as it renders the gnuplot backend 
practically useless.

Going back to rev 9415, i.e.
changeset:   9415:f0538a1bb518
tag:         qparent
user:        John W. Eaton <jwe at octave.org>
date:        Tue Aug 25 10:26:01 2009 +0200
summary:     __magick_read__.cc: undo unintended change

does not solve the problem.

Going back to rev 9413 neither.
I begin to wonder if it worked with the rc1. Unfortunately I haven't 
checked then.

This will require more debugging.

Tatsuro do you have any news?

benjamin



From dasergatskov at gmail.com  Tue Sep  1 16:35:56 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 1 Sep 2009 16:35:56 -0500
Subject: 3.2.3 RC2
In-Reply-To: <4A9D8671.7050007@gmx.net>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
	<4A9D8671.7050007@gmx.net>
Message-ID: <892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>

On Tue, Sep 1, 2009 at 3:39 PM, Benjamin Lindner<lindnerben at gmx.net> wrote:
> Jaroslav Hajek wrote:
>>
>> hi all,
>>
>> the 3.2.3 RC2 tarballs are available:
>> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
>
> Builds fine using mingw32 TDM-gcc-4.3.0-3.
> Make check shows the already known failures.
>
> However, as Tatsuro already pointed out, gnuplot does no longer allow
> interaction with either keyboard (e.g. grid on/of) or mouse (e.g. zooming).
> I tested this with the 2009-july-08 development binaries and a local build
> from the CVS snapshot of the same date.
>
> This is quite a serious regression as it renders the gnuplot backend
> practically useless.
>
> Going back to rev 9415, i.e.
> changeset: ? 9415:f0538a1bb518
> tag: ? ? ? ? qparent
> user: ? ? ? ?John W. Eaton <jwe at octave.org>
> date: ? ? ? ?Tue Aug 25 10:26:01 2009 +0200
> summary: ? ? __magick_read__.cc: undo unintended change
>
> does not solve the problem.
>
> Going back to rev 9413 neither.
> I begin to wonder if it worked with the rc1. Unfortunately I haven't checked
> then.
>
> This will require more debugging.
>
> Tatsuro do you have any news?
>
> benjamin
>
>
>

Mouse works for me with on linux x86_64 and i686 with fairly recent
gnuplot cvs though.
On i686 after fixing lapack/atlas issues I am still getting 1 failure
on make check:

 ***** testif HAVE_ARPACK
 [u2,s2,v2,flag] = svds(a,k,0);
 s2 = diag(s2);
 assert(flag,!1);
 assert(s(k:-1:1), s2, 1e-10);
!!!!! test failed
assert (s (k:-1:1),s2,1e-10) expected
   38.060
   38.060
   38.034
   38.034
   38.015
   38.015
   38.004
but got
   38.060
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004

========

So I suspect that there are some problem with lapack left.
(Or may be with arpack.)

I am tempted to recompile everything with either "-ffloat-store" or
"-msse -mfmath=sse2" ...

Any hints would be appreciated.

Sincerely,

Dmitri.
--


From jwe at octave.org  Tue Sep  1 16:42:34 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 1 Sep 2009 17:42:34 -0400
Subject: 3.2.3 RC2
In-Reply-To: <4A9D8671.7050007@gmx.net>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
	<4A9D8671.7050007@gmx.net>
Message-ID: <19101.38218.61959.506578@segfault.lan>

On  1-Sep-2009, Benjamin Lindner wrote:

| Jaroslav Hajek wrote:
| > hi all,
| > 
| > the 3.2.3 RC2 tarballs are available:
| > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
| 
| Builds fine using mingw32 TDM-gcc-4.3.0-3.
| Make check shows the already known failures.
| 
| However, as Tatsuro already pointed out, gnuplot does no longer allow 
| interaction with either keyboard (e.g. grid on/of) or mouse (e.g. 
| zooming). I tested this with the 2009-july-08 development binaries and a 
| local build from the CVS snapshot of the same date.

Zooming doesn't work for me on a Debian system with 3.2.0, 3.2.2, or
3.2.3-RC2.  But toggling the grid does work with all three versions.
I don't know whether zooming with the mouse is suppsoed to work with
the version of gnuplot I have (4.2.5).  It does work for me when I
start gnuplot outside of Octave and plot a funtion.  I'm not sure
whether 4.2.5 can zoom when data comes from a pipe, as Octave is
sending it now.

jwe

From jwe at octave.org  Tue Sep  1 16:45:13 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 1 Sep 2009 17:45:13 -0400
Subject: 3.2.3 RC2
In-Reply-To: <892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
	<4A9D8671.7050007@gmx.net>
	<892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>
Message-ID: <19101.38377.700677.805514@segfault.lan>

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

| I am tempted to recompile everything with either "-ffloat-store"

I would not recommend complining everything with -ffloat-store, as that
would have some negative performance implications.

jwe

From marco_atzeri at yahoo.it  Tue Sep  1 17:14:11 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Tue, 1 Sep 2009 22:14:11 +0000 (GMT)
Subject: 3.2.3 RC2
In-Reply-To: <892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>
Message-ID: <480941.19682.qm@web25502.mail.ukl.yahoo.com>

-- Mar 1/9/09, Dmitri A. Sergatskov <dasergatskov at gmail.com> ha scritto:


> On i686 after fixing lapack/atlas issues I am still getting
> 1 failure
> on make check:
> 
>  ***** testif HAVE_ARPACK
>  [u2,s2,v2,flag] = svds(a,k,0);
>  s2 = diag(s2);
>  assert(flag,!1);
>  assert(s(k:-1:1), s2, 1e-10);
> !!!!! test failed
> assert (s (k:-1:1),s2,1e-10) expected
> ???38.060
> ???38.060
> ???38.034
> ???38.034
> ???38.015
> ???38.015
> ???38.004
> but got
> ???38.060
> ???38.034
> ???38.034
> ???38.015
> ???38.015
> ???38.004
> ???38.004
> 
> ========
> 
> So I suspect that there are some problem with lapack left.
> (Or may be with arpack.)

on 3..2.3-RC1 cygwin I had

  ***** testif HAVE_ARPACK
 [u2,s2,v2,flag] = svds(a,k,0);
 s2 = diag(s2);
 assert(flag,!1);
 assert(s(k:-1:1), s2, 1e-10); 
!!!!! test failed
assert (s (k:-1:1),s2,1e-10) expected
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004
but got
   38.060
   38.034
   38.034
   38.015
   38.015
   38..004
   38.004
Dimensions don't match>>>>> 

Is eventually the expected value wrong ?

> 
> I am tempted to recompile everything with either
> "-ffloat-store" or
> "-msse -mfmath=sse2" ...
> 
> Any hints would be appreciated.
> 
> Sincerely,
> 
> Dmitri.
> --
> 

Marco


      



From dasergatskov at gmail.com  Tue Sep  1 17:21:22 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 1 Sep 2009 17:21:22 -0500
Subject: 3.2.3 RC2
In-Reply-To: <480941.19682.qm@web25502.mail.ukl.yahoo.com>
References: <892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>
	<480941.19682.qm@web25502.mail.ukl.yahoo.com>
Message-ID: <892b16670909011521t132a5f30yab9d47ed354471b6@mail.gmail.com>

On Tue, Sep 1, 2009 at 5:14 PM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:

> on 3..2.3-RC1 cygwin I had
>
> ?***** testif HAVE_ARPACK
> ?[u2,s2,v2,flag] = svds(a,k,0);
> ?s2 = diag(s2);
> ?assert(flag,!1);
> ?assert(s(k:-1:1), s2, 1e-10);
> !!!!! test failed
> assert (s (k:-1:1),s2,1e-10) expected
> ? 38.034
> ? 38.034
> ? 38.015
> ? 38.015
> ? 38.004
> ? 38.004
> but got
> ? 38.060
> ? 38.034
> ? 38.034
> ? 38.015
> ? 38.015
> ? 38..004
> ? 38.004
> Dimensions don't match>>>>>
>
> Is eventually the expected value wrong ?
>

> Marco
>

It works fine on x86_64, so I tend to blame the problems like this on
wonders of i387 floating point math...
I am surprised that your expected values not the same as mine...

Dmitri.
--


From dasergatskov at gmail.com  Tue Sep  1 17:47:08 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 1 Sep 2009 17:47:08 -0500
Subject: 3.2.3 RC2
In-Reply-To: <19101.38377.700677.805514@segfault.lan>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
	<4A9D8671.7050007@gmx.net>
	<892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>
	<19101.38377.700677.805514@segfault.lan>
Message-ID: <892b16670909011547u6a5c0136w88d94361792e255b@mail.gmail.com>

On Tue, Sep 1, 2009 at 4:45 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?1-Sep-2009, Dmitri A. Sergatskov wrote:
>
> | I am tempted to recompile everything with either "-ffloat-store"
>
> I would not recommend complining everything with -ffloat-store, as that
> would have some negative performance implications.
>
> jwe
>

After recompiling octave 3.2.3rc2 source with -mfpmath=sse -msse2
(on Pentium M computer) "make check" runs without any failures.
(PASS 5762, FAIL 0).

FWIW...

Dmitri.
--


From tmacchant at yahoo.co.jp  Tue Sep  1 17:49:40 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 2 Sep 2009 07:49:40 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <4A9D8671.7050007@gmx.net>
Message-ID: <20090901224940.57144.qmail@web3805.mail.bbt.yahoo.co.jp>

Hello

Yesterday I have reported the problem 3.2.3RC1 soon after 3.2.3 RC2 was released.
However it is time I have to come home so that I have kept my computer on for building new binaries  
from the source 3.2.3RC2.  Now I have just come here and check results.  However, the mouse zoom 
problem still occur.

Unfortunately I will be occupied by important matter of the university, my work for this issue will be
delayed.

BTW make check results were the same as those on 3.2.3RC1. 

Regards

Tatsuro  


--- Benjamin Lindner wrote:

> Jaroslav Hajek wrote:
> > hi all,
> > 
> > the 3.2.3 RC2 tarballs are available:
> > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> Builds fine using mingw32 TDM-gcc-4.3.0-3.
> Make check shows the already known failures.
> 
> However, as Tatsuro already pointed out, gnuplot does no longer allow 
> interaction with either keyboard (e.g. grid on/of) or mouse (e.g. 
> zooming). I tested this with the 2009-july-08 development binaries and a 
> local build from the CVS snapshot of the same date.
> 
> This is quite a serious regression as it renders the gnuplot backend 
> practically useless.
> 
> Going back to rev 9415, i.e.
> changeset:   9415:f0538a1bb518
> tag:         qparent
> user:        John W. Eaton <jwe at octave.org>
> date:        Tue Aug 25 10:26:01 2009 +0200
> summary:     __magick_read__.cc: undo unintended change
> 
> does not solve the problem.
> 
> Going back to rev 9413 neither.
> I begin to wonder if it worked with the rc1. Unfortunately I haven't 
> checked then.
> 
> This will require more debugging.
> 
> Tatsuro do you have any news?
> 
> benjamin
> 
> 
> 


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

From tmacchant at yahoo.co.jp  Tue Sep  1 17:58:36 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 2 Sep 2009 07:58:36 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <480941.19682.qm@web25502.mail.ukl.yahoo.com>
Message-ID: <20090901225837.7899.qmail@web3803.mail.bbt.yahoo.co.jp>

Hello

I have encountered the same error.
It depended on the Atlas Libraries.

The Atlas 3.8.3 libraries at home (cerelon-M) works correct, however the atlas 3.8.3 libraries on the
computer (HT-pentium) gave the same error as the below.  Fortunately the atlas 3.8.2 libraries for
Ht-pentium are remained.  I had tried them, the error disappeared.

I do not know why the results depend on the Atlas libraries  at present.

Regards

Tatsuro    

--- Marco Atzeri <marco_atzeri at yahoo.it> wrote:

> -- Mar 1/9/09, Dmitri A. Sergatskov <dasergatskov at gmail.com> ha scritto:
> 
> 
> > On i686 after fixing lapack/atlas issues I am still getting
> > 1 failure
> > on make check:
> > 
> >  ***** testif HAVE_ARPACK
> >  [u2,s2,v2,flag] = svds(a,k,0);
> >  s2 = diag(s2);
> >  assert(flag,!1);
> >  assert(s(k:-1:1), s2, 1e-10);
> > !!!!! test failed
> > assert (s (k:-1:1),s2,1e-10) expected
> > 38.060
> > 38.060
> > 38.034
> > 38.034
> > 38.015
> > 38.015
> > 38.004
> > but got
> > 38.060
> > 38.034
> > 38.034
> > 38.015
> > 38.015
> > 38.004
> > 38.004
> > 
> > ========
> > 
> > So I suspect that there are some problem with lapack left.
> > (Or may be with arpack.)
> 
> on 3..2.3-RC1 cygwin I had
> 
>   ***** testif HAVE_ARPACK
>  [u2,s2,v2,flag] = svds(a,k,0);
>  s2 = diag(s2);
>  assert(flag,!1);
>  assert(s(k:-1:1), s2, 1e-10); 
> !!!!! test failed
> assert (s (k:-1:1),s2,1e-10) expected
>    38.034
>    38.034
>    38.015
>    38.015
>    38.004
>    38.004
> but got
>    38.060
>    38.034
>    38.034
>    38.015
>    38.015
>    38..004
>    38.004
> Dimensions don't match>>>>> 
> 
> Is eventually the expected value wrong ?
> 
> > 
> > I am tempted to recompile everything with either
> > "-ffloat-store" or
> > "-msse -mfmath=sse2" ...
> > 
> > Any hints would be appreciated.
> > 
> > Sincerely,
> > 
> > Dmitri.
> > --
> > 
> 
> Marco
> 
> 
>       
> 
> 
> 


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

From tmacchant at yahoo.co.jp  Tue Sep  1 18:14:41 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 2 Sep 2009 08:14:41 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <20090901225837.7899.qmail@web3803.mail.bbt.yahoo.co.jp>
Message-ID: <20090901231441.76206.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello

I remember that I have already reported the matter.
See
http://www.nabble.com/make-check-results-of-sparse\svds.m-and-ATLAS-tc24751523.html#a24751523 

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> I have encountered the same error.
> It depended on the Atlas Libraries.
> 
> The Atlas 3.8.3 libraries at home (cerelon-M) works correct, however the atlas 3.8.3 libraries
> on the
> computer (HT-pentium) gave the same error as the below.  Fortunately the atlas 3.8.2 libraries
> for
> Ht-pentium are remained.  I had tried them, the error disappeared.
> 
> I do not know why the results depend on the Atlas libraries  at present.
> 
> Regards
> 
> Tatsuro    
> 
> --- Marco Atzeri <marco_atzeri at yahoo.it> wrote:
> 
> > -- Mar 1/9/09, Dmitri A. Sergatskov <dasergatskov at gmail.com> ha scritto:
> > 
> > 
> > > On i686 after fixing lapack/atlas issues I am still getting
> > > 1 failure
> > > on make check:
> > > 
> > >  ***** testif HAVE_ARPACK
> > >  [u2,s2,v2,flag] = svds(a,k,0);
> > >  s2 = diag(s2);
> > >  assert(flag,!1);
> > >  assert(s(k:-1:1), s2, 1e-10);
> > > !!!!! test failed
> > > assert (s (k:-1:1),s2,1e-10) expected
> > > 38.060
> > > 38.060
> > > 38.034
> > > 38.034
> > > 38.015
> > > 38.015
> > > 38.004
> > > but got
> > > 38.060
> > > 38.034
> > > 38.034
> > > 38.015
> > > 38.015
> > > 38.004
> > > 38.004
> > > 
> > > ========
> > > 
> > > So I suspect that there are some problem with lapack left.
> > > (Or may be with arpack.)
> > 
> > on 3..2.3-RC1 cygwin I had
> > 
> >   ***** testif HAVE_ARPACK
> >  [u2,s2,v2,flag] = svds(a,k,0);
> >  s2 = diag(s2);
> >  assert(flag,!1);
> >  assert(s(k:-1:1), s2, 1e-10); 
> > !!!!! test failed
> > assert (s (k:-1:1),s2,1e-10) expected
> >    38.034
> >    38.034
> >    38.015
> >    38.015
> >    38.004
> >    38.004
> > but got
> >    38.060
> >    38.034
> >    38.034
> >    38.015
> >    38.015
> >    38..004
> >    38.004
> > Dimensions don't match>>>>> 
> > 
> > Is eventually the expected value wrong ?
> > 
> > > 
> > > I am tempted to recompile everything with either
> > > "-ffloat-store" or
> > > "-msse -mfmath=sse2" ...
> > > 
> > > Any hints would be appreciated.
> > > 
> > > Sincerely,
> > > 
> > > Dmitri.
> > > --
> > > 
> > 
> > Marco
> > 
> > 
> >       
> > 
> > 
> > 
> 
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 


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

From highegg at gmail.com  Wed Sep  2 01:50:11 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 2 Sep 2009 08:50:11 +0200
Subject: Building octave with large matrices support
In-Reply-To: <19101.27366.172821.712255@segfault.lan>
References: <def1d5650908241312l1a54f811vce91ced6b33afae8@mail.gmail.com>
	<69d8d540908250020w58eb4fdci54a81a5bf25f4662@mail.gmail.com>
	<19093.39315.466708.135278@segfault.lan>
	<69d8d540908270400jfb1d72ble72aaafc4f8a2c68@mail.gmail.com>
	<19094.63881.529202.480384@segfault.lan>
	<69d8d540908272318k288eb06fgc343d06a5979d3e@mail.gmail.com>
	<19099.17618.522287.15860@segfault.lan>
	<19101.27366.172821.712255@segfault.lan>
Message-ID: <69d8d540909012350h1a313814p53a0f282da6076b0@mail.gmail.com>

On Tue, Sep 1, 2009 at 8:41 PM, John W. Eaton<jwe at octave.org> wrote:
> As a start for checking consistency of integer sizes at compile time,
> I checked in the following change:
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/f26229391ea1
>
> If configuring with the --enable-64 option fails to detect the proper
> size integer and we are using gfortran, then -fdefault-integer-8 is
> added to FFLAGS if it is not already there. ?Checks for other
> compilers could be added, but I don't know what the compiler names or
> options should be.
>
> jwe
>

I've also added into acx_blas_f77_func.m4 a (tricky) check for
matching integer sizes between Fortran and BLAS:
http://hg.savannah.gnu.org/hgweb/octave/rev/de6f547574be

So now it works like a charm:
If I turn on --enable-64, OCTAVE_CHECK_FORTRAN_INTEGER_SIZE adds
-fdefault-integer-8 to FFLAGS, and subsequently ACX_BLAS_WITH_F77_FUNC
rejects the discovered BLAS library as incompatible. Octave will
build, but only with reference BLAS.

regards

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


From tmacchant at yahoo.co.jp  Wed Sep  2 03:23:15 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 2 Sep 2009 17:23:15 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <20090901224940.57144.qmail@web3805.mail.bbt.yahoo.co.jp>
Message-ID: <20090902082315.76867.qmail@web3813.mail.bbt.yahoo.co.jp>

Hello 



changeset:   9395:54a3fa5d4376
user:        Ben Abbott <bpabbott at mac.com>
date:        Thu Aug 06 07:30:34 2009 +0200
summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.
http://hg.tw-math.de/release-3-2-x/rev/54a3fa5d4376


The above changeset seems to be the origin by which mouse  zooming in 2D  cannot be used.

I have tested binaries built  by MinGW-4.4.0 (Official Version) and the gnuplot 4.3 cvs for windows
(the recent source) is used. The terminal is windows terminal.

The changeset modifies __go_draw_figure__.m and gnuplot_drawnow.m.
The change in gnuplot_drawnow.m cause the mouse zoom trouble.
The replacement of  gnuplot_drawnow.m in 3.2.3 RC1 or RC2 by that in 3.2.2 make mouse zooming coming
back.

I have not yet see this changeset in detail at present.

Anyway the chanageset should be re-modified to enable us to use mouse zooming in windows terminal on
gnuplot backend.

Regards

Tatsuro  

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> Yesterday I have reported the problem 3.2.3RC1 soon after 3.2.3 RC2 was released.
> However it is time I have to come home so that I have kept my computer on for building new
> binaries  
> from the source 3.2.3RC2.  Now I have just come here and check results.  However, the mouse zoom
> 
> problem still occur.
> 
> Unfortunately I will be occupied by important matter of the university, my work for this issue
> will be
> delayed.
> 
> BTW make check results were the same as those on 3.2.3RC1. 
> 
> Regards
> 
> Tatsuro  
> 
> 
> --- Benjamin Lindner wrote:
> 
> > Jaroslav Hajek wrote:
> > > hi all,
> > > 
> > > the 3.2.3 RC2 tarballs are available:
> > > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> > 
> > Builds fine using mingw32 TDM-gcc-4.3.0-3.
> > Make check shows the already known failures.
> > 
> > However, as Tatsuro already pointed out, gnuplot does no longer allow 
> > interaction with either keyboard (e.g. grid on/of) or mouse (e.g. 
> > zooming). I tested this with the 2009-july-08 development binaries and a 
> > local build from the CVS snapshot of the same date.
> > 
> > This is quite a serious regression as it renders the gnuplot backend 
> > practically useless.
> > 
> > Going back to rev 9415, i.e.
> > changeset:   9415:f0538a1bb518
> > tag:         qparent
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Tue Aug 25 10:26:01 2009 +0200
> > summary:     __magick_read__.cc: undo unintended change
> > 
> > does not solve the problem.
> > 
> > Going back to rev 9413 neither.
> > I begin to wonder if it worked with the rc1. Unfortunately I haven't 
> > checked then.
> > 
> > This will require more debugging.
> > 
> > Tatsuro do you have any news?
> > 
> > benjamin
> > 
> > 
> > 
> 
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 


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

From jwe at octave.org  Wed Sep  2 06:01:07 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 07:01:07 -0400
Subject: Building octave with large matrices support
In-Reply-To: <69d8d540909012350h1a313814p53a0f282da6076b0@mail.gmail.com>
References: <def1d5650908241312l1a54f811vce91ced6b33afae8@mail.gmail.com>
	<69d8d540908250020w58eb4fdci54a81a5bf25f4662@mail.gmail.com>
	<19093.39315.466708.135278@segfault.lan>
	<69d8d540908270400jfb1d72ble72aaafc4f8a2c68@mail.gmail.com>
	<19094.63881.529202.480384@segfault.lan>
	<69d8d540908272318k288eb06fgc343d06a5979d3e@mail.gmail.com>
	<19099.17618.522287.15860@segfault.lan>
	<19101.27366.172821.712255@segfault.lan>
	<69d8d540909012350h1a313814p53a0f282da6076b0@mail.gmail.com>
Message-ID: <19102.20595.634560.748139@segfault.lan>

On  2-Sep-2009, Jaroslav Hajek wrote:

| I've also added into acx_blas_f77_func.m4 a (tricky) check for
| matching integer sizes between Fortran and BLAS:
| http://hg.savannah.gnu.org/hgweb/octave/rev/de6f547574be

Thanks.  Is this test independent of the endianness of the system?

jwe

From highegg at gmail.com  Wed Sep  2 06:09:47 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 2 Sep 2009 13:09:47 +0200
Subject: Building octave with large matrices support
In-Reply-To: <19102.20595.634560.748139@segfault.lan>
References: <def1d5650908241312l1a54f811vce91ced6b33afae8@mail.gmail.com>
	<69d8d540908250020w58eb4fdci54a81a5bf25f4662@mail.gmail.com>
	<19093.39315.466708.135278@segfault.lan>
	<69d8d540908270400jfb1d72ble72aaafc4f8a2c68@mail.gmail.com>
	<19094.63881.529202.480384@segfault.lan>
	<69d8d540908272318k288eb06fgc343d06a5979d3e@mail.gmail.com>
	<19099.17618.522287.15860@segfault.lan>
	<19101.27366.172821.712255@segfault.lan>
	<69d8d540909012350h1a313814p53a0f282da6076b0@mail.gmail.com>
	<19102.20595.634560.748139@segfault.lan>
Message-ID: <69d8d540909020409y5d9a9bb3r80b93ca141020c57@mail.gmail.com>

On Wed, Sep 2, 2009 at 1:01 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?2-Sep-2009, Jaroslav Hajek wrote:
>
> | I've also added into acx_blas_f77_func.m4 a (tricky) check for
> | matching integer sizes between Fortran and BLAS:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/de6f547574be
>
> Thanks. ?Is this test independent of the endianness of the system?
>

Partially. The second part (checking against 32-bit Fortran calling
64-bit BLAS) is - that's why there are 3 numbers. The first part
assumes little endian; however, I think the case of 64-bit Fortran
calling 32-bit BLAS on big endian architecture actually has no chance
of getting that far; it's bound to faile the earlier tests. So, in
general, the test as whole should be endian-proof, though of course
that needs to be tested in order to be sure.

-- 
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 06:20:41 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 07:20:41 -0400
Subject: Building octave with large matrices support
In-Reply-To: <69d8d540909020409y5d9a9bb3r80b93ca141020c57@mail.gmail.com>
References: <def1d5650908241312l1a54f811vce91ced6b33afae8@mail.gmail.com>
	<69d8d540908250020w58eb4fdci54a81a5bf25f4662@mail.gmail.com>
	<19093.39315.466708.135278@segfault.lan>
	<69d8d540908270400jfb1d72ble72aaafc4f8a2c68@mail.gmail.com>
	<19094.63881.529202.480384@segfault.lan>
	<69d8d540908272318k288eb06fgc343d06a5979d3e@mail.gmail.com>
	<19099.17618.522287.15860@segfault.lan>
	<19101.27366.172821.712255@segfault.lan>
	<69d8d540909012350h1a313814p53a0f282da6076b0@mail.gmail.com>
	<19102.20595.634560.748139@segfault.lan>
	<69d8d540909020409y5d9a9bb3r80b93ca141020c57@mail.gmail.com>
Message-ID: <19102.21769.140906.58853@segfault.lan>

On  2-Sep-2009, Jaroslav Hajek wrote:

| The first part
| assumes little endian; however, I think the case of 64-bit Fortran
| calling 32-bit BLAS on big endian architecture actually has no chance
| of getting that far; it's bound to faile the earlier tests.

Which earlier test would fail?

But anyway, it also occurred to me that there may not be any 64-bit
systems that are big endian (at least now) so maybe it will never
matter?  OTOH, if the test can be made to always work for big or
little endian systems, we might as well do that.

jwe


From lindnerben at gmx.net  Wed Sep  2 07:09:24 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Wed, 02 Sep 2009 14:09:24 +0200
Subject: 3.2.3 RC2
In-Reply-To: <20090902082315.76867.qmail@web3813.mail.bbt.yahoo.co.jp>
References: <20090902082315.76867.qmail@web3813.mail.bbt.yahoo.co.jp>
Message-ID: <20090902120924.308010@gmx.net>


> 
> changeset:   9395:54a3fa5d4376
> user:        Ben Abbott <bpabbott at mac.com>
> date:        Thu Aug 06 07:30:34 2009 +0200
> summary:     Avoid the flickering x11 window seen with rapid gnuplot
> updates.
> http://hg.tw-math.de/release-3-2-x/rev/54a3fa5d4376
> 
> 
> The above changeset seems to be the origin by which mouse  zooming in 2D 
> cannot be used.
> 
> I have tested binaries built  by MinGW-4.4.0 (Official Version) and the
> gnuplot 4.3 cvs for windows
> (the recent source) is used. The terminal is windows terminal.
> 

I can confirm that this changeset breaks interactive usability.

BTW I realized that it is no longer possible to debug what is going on between octave and gnuplot by simply doing 
gnuplot_binary("tee log.txt | gnuplot")
since octave now seems to rely on 2way communication to gnuplot ?

Is there a different way of peeking into what is sent to gnuplot - other than to compile a version of gnuplot with an intrinsic "tee"-like feature, prefreably a way even windows understands?

Back to the gnuplot issue, I believe I can guess what went wrong with this changeset:

Prior to this changeset __go_draw_figure__.m issued a 
"set multiplot", then drew the axes and then issued a
"unset multiplot". Fine.

With this changeset gnuplot_drawnow.m issues a "set multiplot" in gnuplot_set_term prior to calling __go_draw_figure__.m, 
\begin{emph}
but it never issues the corresponding "unset multiplot"!
\end{emph}
leaving gnuplot in a multiplot state in which interative mouse and keyboard are disabled  - I tested this for the windows and wxt terminal.

Now I lost track a bit of all the plotting backend specific code changes, so I am not sure where this is best fixed. Could one of the plotting gurus take a look at it?

> 
> Anyway the chanageset should be re-modified to enable us to use mouse
> zooming in windows terminal on
> gnuplot backend.

I agree, this should be fixed, otherwise the gnuplot backend is pretty much useless on windows.

benjamin


-- 
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

From dbateman at free.fr  Wed Sep  2 07:50:22 2009
From: dbateman at free.fr (dbateman)
Date: Wed, 2 Sep 2009 05:50:22 -0700 (PDT)
Subject: 3.2.3 RC2
In-Reply-To: <20090902120924.308010@gmx.net>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
	<4A9D8671.7050007@gmx.net>
	<20090901224940.57144.qmail@web3805.mail.bbt.yahoo.co.jp>
	<20090902082315.76867.qmail@web3813.mail.bbt.yahoo.co.jp>
	<20090902120924.308010@gmx.net>
Message-ID: <25256862.post@talk.nabble.com>




Benjamin Lindner wrote:
> 
> 
> BTW I realized that it is no longer possible to debug what is going on
> between octave and gnuplot by simply doing 
> gnuplot_binary("tee log.txt | gnuplot")
> since octave now seems to rely on 2way communication to gnuplot ?
> 
> Is there a different way of peeking into what is sent to gnuplot - other
> than to compile a version of gnuplot with an intrinsic "tee"-like feature,
> prefreably a way even windows understands?
> 

drawnow ("x11", "/dev/null", false, "/tmp/log.txt")

It is even documented.

D.

-- 
View this message in context: http://www.nabble.com/3.2.3-RC2-tp25236191p25256862.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


From lindnerben at gmx.net  Wed Sep  2 08:37:00 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Wed, 02 Sep 2009 15:37:00 +0200
Subject: 3.2.3 RC2
In-Reply-To: <25256862.post@talk.nabble.com>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
	<4A9D8671.7050007@gmx.net>
	<20090901224940.57144.qmail@web3805.mail.bbt.yahoo.co.jp>
	<20090902082315.76867.qmail@web3813.mail.bbt.yahoo.co.jp>
	<20090902120924.308010@gmx.net> <25256862.post@talk.nabble.com>
Message-ID: <20090902133700.148190@gmx.net>

> 
> 
> 
> Benjamin Lindner wrote:
> > 
> > 
> > BTW I realized that it is no longer possible to debug what is going on
> > between octave and gnuplot by simply doing 
> > gnuplot_binary("tee log.txt | gnuplot")
> > since octave now seems to rely on 2way communication to gnuplot ?
> > 
> > Is there a different way of peeking into what is sent to gnuplot - other
> > than to compile a version of gnuplot with an intrinsic "tee"-like
> feature,
> > prefreably a way even windows understands?
> > 
> 
> drawnow ("x11", "/dev/null", false, "/tmp/log.txt")

thanks !
 
> It is even documented.

the documentation says:

 -- Built-in Function:  drawnow ()
 -- Built-in Function:  drawnow ("expose")
 -- Built-in Function:  drawnow (TERM, FILE, MONO, DEBUG_FILE)
     Update figure windows and their children.  The event queue is
     flushed and any callbacks generated are executed.  With the
     optional argument `"expose"', only graphic objects are updated and
     no other events or callbacks are processed.  The third calling
     form of `drawnow' is for debugging and is undocumented.

so actually it's "undocumented" ;-)
anyway, thanks for hinting.

using drawnow("windows", "foo.txt", 9, "debug.txt")
I see that indeed gnuplot is left in multiplot state, which explains why interaction is not possible.

benjamin
-- 
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

From jwe at octave.org  Wed Sep  2 13:29:44 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 14:29:44 -0400
Subject: 3.2.3 RC2
In-Reply-To: <892b16670909011521t132a5f30yab9d47ed354471b6@mail.gmail.com>
References: <892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>
	<480941.19682.qm@web25502.mail.ukl.yahoo.com>
	<892b16670909011521t132a5f30yab9d47ed354471b6@mail.gmail.com>
Message-ID: <19102.47512.91816.791481@segfault.lan>

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

| On Tue, Sep 1, 2009 at 5:14 PM, Marco Atzeri<marco_atzeri at yahoo.it> wrote:
| 
| > on 3..2.3-RC1 cygwin I had
| >
| > ?***** testif HAVE_ARPACK
| > ?[u2,s2,v2,flag] = svds(a,k,0);
| > ?s2 = diag(s2);
| > ?assert(flag,!1);
| > ?assert(s(k:-1:1), s2, 1e-10);
| > !!!!! test failed
| > assert (s (k:-1:1),s2,1e-10) expected
| > ? 38.034
| > ? 38.034
| > ? 38.015
| > ? 38.015
| > ? 38.004
| > ? 38.004
| > but got
| > ? 38.060
| > ? 38.034
| > ? 38.034
| > ? 38.015
| > ? 38.015
| > ? 38..004
| > ? 38.004
| > Dimensions don't match>>>>>
| >
| > Is eventually the expected value wrong ?
| >
| 
| > Marco
| >
| 
| It works fine on x86_64, so I tend to blame the problems like this on
| wonders of i387 floating point math...
| I am surprised that your expected values not the same as mine...

I also see this failure, but it doesn't happen on every run.  I'm
running Octave on an amd64 system.

The test is:

  n = 100;
  k = 7;
  a = sparse([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],[ones(1,n-2),0.4*n*ones(1,n),ones(1,n-2)]);
  [u,s,v] = svd(full(a));
  s = diag(s);
  [dum, idx] = sort(abs(s));
  s = s(idx);
  u = u(:,idx);
  v = v(:,idx);
  [u2,s2,v2,flag] = svds(a,k,0);
  s2 = diag(s2);
  assert(flag,!1);
  assert(s(k:-1:1), s2, 1e-10); 

If you run this repeatedly, do you see some successes and some
failures?  If it does fail, do you see that the first assert sometimes
fails, and other times it is the second?

I have not tried to debug the problem yet.

David, I'm copying you because you wrote svds and might be able to see
the problem and perhaps a fix more quickly than I could.

Thanks,

jwe


From dasergatskov at gmail.com  Wed Sep  2 13:39:49 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Wed, 2 Sep 2009 13:39:49 -0500
Subject: 3.2.3 RC2
In-Reply-To: <19102.47512.91816.791481@segfault.lan>
References: <892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>
	<480941.19682.qm@web25502.mail.ukl.yahoo.com>
	<892b16670909011521t132a5f30yab9d47ed354471b6@mail.gmail.com>
	<19102.47512.91816.791481@segfault.lan>
Message-ID: <892b16670909021139r58c9c849ke484166dba6817d9@mail.gmail.com>

On Wed, Sep 2, 2009 at 1:29 PM, John W. Eaton<jwe at octave.org> wrote:

> The test is:
>
> ?n = 100;
> ?k = 7;
> ?a = sparse([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],[ones(1,n-2),0.4*n*ones(1,n),ones(1,n-2)]);
> ?[u,s,v] = svd(full(a));
> ?s = diag(s);
> ?[dum, idx] = sort(abs(s));
> ?s = s(idx);
> ?u = u(:,idx);
> ?v = v(:,idx);
> ?[u2,s2,v2,flag] = svds(a,k,0);
> ?s2 = diag(s2);
> ?assert(flag,!1);
> ?assert(s(k:-1:1), s2, 1e-10);
>
> If you run this repeatedly, do you see some successes and some
> failures? ?If it does fail, do you see that the first assert sometimes
> fails, and other times it is the second?

It is alway seems to be in the second, but I get different warnings from
time to time.  Most often it is:

warning: returning fewer singular values than requested
warning: try increasing the value of sigma
error: assert (s (k:-1:1),s2,1e-10) expected
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004
but got
   38.060
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004
Dimensions don't match


but sometimes it is just:

error: assert (s (k:-1:1),s2,1e-10) expected
   38.060
   38.060
   38.034
   38.034
   38.015
   38.015
   38.004
but got
   38.060
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004
maximum absolute error 0.0263523 exceeds tolerance 1e-10


>
> I have not tried to debug the problem yet.
>
> David, I'm copying you because you wrote svds and might be able to see
> the problem and perhaps a fix more quickly than I could.
>
> Thanks,
>
> jwe
>

Dmitri.
--


From jwe at octave.org  Wed Sep  2 14:05:46 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 15:05:46 -0400
Subject: development snapshot
In-Reply-To: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
Message-ID: <19102.49674.637449.216165@segfault.lan>

On 29-Jul-2009, Jaroslav Hajek wrote:

| what about making a development snapshot soon, perhaps now?
| Further, src/version.h still shows version 3.1.55 and api-v37. Is it
| OK if I change it to 3.3.1 and api-v38?

Sorry for not responding to this message earlier.  Is now a good time
to make a new snapshot?  If there are no objections, I will try to
start making more regular snapshots again.  Should we start with
3.3.1?  3.3.50?  Should we start planning for a new release?  If so,
what features are most important?

jwe


From Thomas.Treichl at gmx.net  Wed Sep  2 14:08:25 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Wed, 02 Sep 2009 21:08:25 +0200
Subject: Changeset Mac: We have the strip tool
Message-ID: <4A9EC2A9.9050902@gmx.net>

Hi,

the attached changeset enables strip for Mac (I use this change for a while so I 
would say it is tested very well) and also fixes a typo (regarding strip) for 
Windows.

Best regards

   Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: strip.diff
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090902/e59636ea/attachment.ksh 

From Thomas.Treichl at gmx.net  Wed Sep  2 14:25:08 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Wed, 02 Sep 2009 21:25:08 +0200
Subject: Changeset Mac: Use dlopen instead of dyld per default
Message-ID: <4A9EC694.6020708@gmx.net>

Hi,

I'm compiling the Octave sources against Mac's dlopen libraries instead of Mac's 
dyld. For this I have created a option I'd like to see directly in the Octave 
sources. If given the flag

   ./configure --with-mach-dyld

then Octave should be compiled the "old way". Not given this flag checks for dlopen.

This change should be tested on more than just my machine - so please don't make 
bigger changes, eg. don't remove any of the dyld codes right now, as long as we 
don't have the feedback that things still work on other machines and dlopen 
works on all Macs as expected. The big changes (my suggestion) should be made 
before any of the next stable releases.

Best regards

   Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dlopen.diff
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090902/51c6829c/attachment.ksh 

From jwe at octave.org  Wed Sep  2 16:22:09 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 2 Sep 2009 17:22:09 -0400
Subject: A backend("fltk") problem
In-Reply-To: <4A9D9C7B.9050101@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
Message-ID: <19102.57857.878905.590704@segfault.lan>

Off list, I sent Michael a patch to try to avoid the crash he was
seeing.

Back on the mailing list:

On  1-Sep-2009, Michael D. Godfrey wrote:

| I said:
| 
| > For now, I will just try commenting the ::error 
| 
| I said I would try this with almost zero expectation that it
| would work, but it does !!
| 
| So far, I only wrote a title at the top of a plot, but it
| looks right and in a sans serif font that looks about right.

What versions of freetype and fontconfig do you have installed?  I
seem to have freetype 2.3.9 and fontconfig 2.6.0.

When I try something like

  set (0, 'defaultaxesfontname', 'foobarfont')
  set (0, 'defaulttextfontname', 'foobarfont')
  text (0.5, 0.5, 'foobar')

I don't see a crash.  It still works for me and uses some default
font (even without the change I sent to you).  Stepping through
ft_manager::do_get_font, I see that the font name is "foobarfont", but
even so, FcFontMatch returns a valid font object.  That's apparently
not happening for you, so maybe there is a difference in the versions
of freetype and/or fontconfig that we have installed, and my version
is returning some default font when there is no match on the font
pattern?  I see there is a call to

This all works for me even if I remove what I think are the
corresponding font packages that you mentioned.  On my system:

  xfonts-base xfonts-100dpi xfonts-75dpi

So now I'm a bit confused about exactly what dependency we should be
adding.

jwe

From godfrey at isl.stanford.edu  Wed Sep  2 17:49:29 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Wed, 02 Sep 2009 15:49:29 -0700
Subject: A backend("fltk") problem
In-Reply-To: <19102.57857.878905.590704@segfault.lan>
References: <4A9749CF.6030708@isl.stanford.edu>	<19101.34310.961893.954083@segfault.lan>	<4A9D906A.8030606@isl.stanford.edu>	<19101.37238.710823.546142@segfault.lan>	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
Message-ID: <4A9EF679.8050205@isl.stanford.edu>

On 09/02/2009 02:22 PM, John W. Eaton wrote:
> Off list, I sent Michael a patch to try to avoid the crash he was
> seeing.
>
> Back on the mailing list:
>
> On  1-Sep-2009, Michael D. Godfrey wrote:
>
> | I said:
> |
> |>  For now, I will just try commenting the ::error
> |
> | I said I would try this with almost zero expectation that it
> | would work, but it does !!
> |
> | So far, I only wrote a title at the top of a plot, but it
> | looks right and in a sans serif font that looks about right.
>
> What versions of freetype and fontconfig do you have installed?  I
> seem to have freetype 2.3.9 and fontconfig 2.6.0.
>    
[vzero:plot] rpm -q fontconfig
fontconfig-2.7.1-1.fc11.x86_64
fontconfig-2.7.1-1.fc11.i586
[vzero:plot] rpm -q freetype
freetype-2.3.9-5.fc11.x86_64
freetype-2.3.9-5.fc11.i586

> When I try something like
>
>    set (0, 'defaultaxesfontname', 'foobarfont')
>    set (0, 'defaulttextfontname', 'foobarfont')
>    text (0.5, 0.5, 'foobar')
>
> I don't see a crash.  It still works for me and uses some default
> font (even without the change I sent to you).  Stepping through
> ft_manager::do_get_font, I see that the font name is "foobarfont", but
> even so, FcFontMatch returns a valid font object.  That's apparently
> not happening for you, so maybe there is a difference in the versions
> of freetype and/or fontconfig that we have installed, and my version
> is returning some default font when there is no match on the font
> pattern?  I see there is a call to
>
> This all works for me even if I remove what I think are the
> corresponding font packages that you mentioned.  On my system:
>
>    xfonts-base xfonts-100dpi xfonts-75dpi
>
> So now I'm a bit confused about exactly what dependency we should be
> adding.
>    
I am not clear about this either.  Right now I do not have
a copy of the current system without the patch that removes the
error::  lines.
> jwe
>    
In any case, the fonts that I mentioned,
xorg-x11-fonts-75dpi-7.2-8.fc11.noarch
xorg-x11-fonts-100dpi-7.2-8.fc11.noarc
only fixed the "interpreter", "tex" problem
in the unpatched system.

To add a brief summary of what I know about fltk/OpenGL:

1. With the unofficial patches, all plotting that I have
     tried seems to work well.  This is mainly plots that
     gnuplot could not handle at all.

2. The things that do not work are print, and the
     "interpreter", "tex" mode.  The main reason print
     fails to do anything is that the drawnow call seems
     to do nothing.  It is clear that ghostscript is not being
     set up correctly. I made a few changes in print.m to
     get that far.  "interpreter", "tex"  is just ignored.

There may be more significant problems, but I think
that with the 2 above items resolved it would at least
be at a point where it could be made available as
a "beta" test.

I will try to do some more on this soon.  But, a reaction
from the real experts would be helpful.  I have only
just started on this.

Michael


From shaiay at gmail.com  Wed Sep  2 22:46:40 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 3 Sep 2009 06:46:40 +0300
Subject: A backend("fltk") problem
In-Reply-To: <4A9EF679.8050205@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
	<4A9EF679.8050205@isl.stanford.edu>
Message-ID: <420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>

On Thu, Sep 3, 2009 at 1:49 AM, Michael D.
Godfrey<godfrey at isl.stanford.edu> wrote:
> On 09/02/2009 02:22 PM, John W. Eaton wrote:
>>
>> Off list, I sent Michael a patch to try to avoid the crash he was
>> seeing.
>>
>> Back on the mailing list:
>>
>> On ?1-Sep-2009, Michael D. Godfrey wrote:
>>
>> | I said:
>> |
>> |> ?For now, I will just try commenting the ::error
>> |
>> | I said I would try this with almost zero expectation that it
>> | would work, but it does !!
>> |
>> | So far, I only wrote a title at the top of a plot, but it
>> | looks right and in a sans serif font that looks about right.
>>
>> What versions of freetype and fontconfig do you have installed? ?I
>> seem to have freetype 2.3.9 and fontconfig 2.6.0.
>>
>
> [vzero:plot] rpm -q fontconfig
> fontconfig-2.7.1-1.fc11.x86_64
> fontconfig-2.7.1-1.fc11.i586
> [vzero:plot] rpm -q freetype
> freetype-2.3.9-5.fc11.x86_64
> freetype-2.3.9-5.fc11.i586
>
>> When I try something like
>>
>> ? set (0, 'defaultaxesfontname', 'foobarfont')
>> ? set (0, 'defaulttextfontname', 'foobarfont')
>> ? text (0.5, 0.5, 'foobar')
>>
>> I don't see a crash. ?It still works for me and uses some default
>> font (even without the change I sent to you). ?Stepping through
>> ft_manager::do_get_font, I see that the font name is "foobarfont", but
>> even so, FcFontMatch returns a valid font object. ?That's apparently
>> not happening for you, so maybe there is a difference in the versions
>> of freetype and/or fontconfig that we have installed, and my version
>> is returning some default font when there is no match on the font
>> pattern? ?I see there is a call to
>>
>> This all works for me even if I remove what I think are the
>> corresponding font packages that you mentioned. ?On my system:
>>
>> ? xfonts-base xfonts-100dpi xfonts-75dpi
>>
>> So now I'm a bit confused about exactly what dependency we should be
>> adding.
>>
>
> I am not clear about this either. ?Right now I do not have
> a copy of the current system without the patch that removes the
> error:: ?lines.
>>
>> jwe
>>

I could not understand what the original problem was here.

> In any case, the fonts that I mentioned,
> xorg-x11-fonts-75dpi-7.2-8.fc11.noarch
> xorg-x11-fonts-100dpi-7.2-8.fc11.noarc
> only fixed the "interpreter", "tex" problem
> in the unpatched system.
>
> To add a brief summary of what I know about fltk/OpenGL:
>
> 1. With the unofficial patches, all plotting that I have
> ? ?tried seems to work well. ?This is mainly plots that
> ? ?gnuplot could not handle at all.
>
> 2. The things that do not work are print, and the
> ? ?"interpreter", "tex" mode. ?The main reason print
> ? ?fails to do anything is that the drawnow call seems
> ? ?to do nothing. ?It is clear that ghostscript is not being
> ? ?set up correctly. I made a few changes in print.m to
> ? ?get that far. ?"interpreter", "tex" ?is just ignored.

The status of the fltk/OpenGL backend as far as I know is consistent
with your observation: printing is not yet implemented - it is (was?)
planned to be done using the gl2ps library (actually consisting of one
c-file and one h-file). the tex interpreter is also unimplemented but
as I understand Michael Goffioul laid down the groundwork for using
LaTeX in the current text handling routines in that they use cached
bitmaps, which are now generated by freetype, but could be generated
by LaTeX.
I don't think I'll be able to work on these for at least the coming
month or so, but I will be available for email questions.

Shai

> There may be more significant problems, but I think
> that with the 2 above items resolved it would at least
> be at a point where it could be made available as
> a "beta" test.

IMHO lack of printing is the #1 issue. tex is more on the nice to have list

Shai


From jwe at octave.org  Wed Sep  2 23:04:44 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 3 Sep 2009 00:04:44 -0400
Subject: A backend("fltk") problem
In-Reply-To: <420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
Message-ID: <19103.16476.593329.960556@segfault.lan>

On  3-Sep-2009, Shai Ayal wrote:

| On Thu, Sep 3, 2009 at 1:49 AM, Michael D.
| Godfrey<godfrey at isl.stanford.edu> wrote:
| > On 09/02/2009 02:22 PM, John W. Eaton wrote:
| >>
| >> Off list, I sent Michael a patch to try to avoid the crash he was
| >> seeing.
| >>
| >> Back on the mailing list:
| >>
| >> On ?1-Sep-2009, Michael D. Godfrey wrote:
| >>
| >> | I said:
| >> |
| >> |> ?For now, I will just try commenting the ::error
| >> |
| >> | I said I would try this with almost zero expectation that it
| >> | would work, but it does !!
| >> |
| >> | So far, I only wrote a title at the top of a plot, but it
| >> | looks right and in a sans serif font that looks about right.
| >>
| >> What versions of freetype and fontconfig do you have installed? ?I
| >> seem to have freetype 2.3.9 and fontconfig 2.6.0.
| >>
| >
| > [vzero:plot] rpm -q fontconfig
| > fontconfig-2.7.1-1.fc11.x86_64
| > fontconfig-2.7.1-1.fc11.i586
| > [vzero:plot] rpm -q freetype
| > freetype-2.3.9-5.fc11.x86_64
| > freetype-2.3.9-5.fc11.i586
| >
| >> When I try something like
| >>
| >> ? set (0, 'defaultaxesfontname', 'foobarfont')
| >> ? set (0, 'defaulttextfontname', 'foobarfont')
| >> ? text (0.5, 0.5, 'foobar')
| >>
| >> I don't see a crash. ?It still works for me and uses some default
| >> font (even without the change I sent to you). ?Stepping through
| >> ft_manager::do_get_font, I see that the font name is "foobarfont", but
| >> even so, FcFontMatch returns a valid font object. ?That's apparently
| >> not happening for you, so maybe there is a difference in the versions
| >> of freetype and/or fontconfig that we have installed, and my version
| >> is returning some default font when there is no match on the font
| >> pattern? ?I see there is a call to
| >>
| >> This all works for me even if I remove what I think are the
| >> corresponding font packages that you mentioned. ?On my system:
| >>
| >> ? xfonts-base xfonts-100dpi xfonts-75dpi
| >>
| >> So now I'm a bit confused about exactly what dependency we should be
| >> adding.
| >>
| >
| > I am not clear about this either. ?Right now I do not have
| > a copy of the current system without the patch that removes the
| > error:: ?lines.
| >>
| >> jwe
| >>
| 
| I could not understand what the original problem was here.

Sorry, the problem was the crash reported here:

  https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-August/009333.html

I was able to reproduce this only by stepping through the
ft_manager::do_get_font function and setting match to 0 after this
statement:

  match = FcFontMatch (0, pat, &res);
	      
Then the crash actually occurs later.  I never found exactly why, but
I think the best solution is to ensure that do_get_font always returns
a valid font, even if it is just some fallback font that we either
distribute with Octave or expect to be present based on package
dependencies.

| IMHO lack of printing is the #1 issue. tex is more on the nice to have list

I agree, but at least partial TeX parsing is already handled by the
gnuplot backend in an interpreted function, so I think that should not
be too hard to translate to C++.  Another place to look for TeX
support is the code in matplotlib, which I think has several levels of
TeX support from simple parsing of basic things like \theta to passing
the string to TeX and getting some graphics object back that is then
inserted in the plot.

jwe


From godfrey at isl.stanford.edu  Wed Sep  2 23:06:01 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 02 Sep 2009 21:06:01 -0700
Subject: A backend("fltk") problem
In-Reply-To: <420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
References: <4A9749CF.6030708@isl.stanford.edu>	
	<19101.34310.961893.954083@segfault.lan>	
	<4A9D906A.8030606@isl.stanford.edu>	
	<19101.37238.710823.546142@segfault.lan>	
	<4A9D9C7B.9050101@isl.stanford.edu>	
	<19102.57857.878905.590704@segfault.lan>	
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
Message-ID: <4A9F40A9.9040002@isl.stanford.edu>

On 09/02/2009 08:46 PM, Shai Ayal wrote:
> On Thu, Sep 3, 2009 at 1:49 AM, Michael D.
> Godfrey<godfrey at isl.stanford.edu>  wrote:
>    
>> >  On 09/02/2009 02:22 PM, John W. Eaton wrote:
>>      
>>> >>
>>> >>  Off list, I sent Michael a patch to try to avoid the crash he was
>>> >>  seeing.
>>> >>
>>> >>  Back on the mailing list:
>>> >>
>>> >>  On  1-Sep-2009, Michael D. Godfrey wrote:
>>> >>
>>> >>  | I said:
>>> >>  |
>>> >>  |>    For now, I will just try commenting the ::error
>>> >>  |
>>> >>  | I said I would try this with almost zero expectation that it
>>> >>  | would work, but it does !!
>>> >>  |
>>> >>  | So far, I only wrote a title at the top of a plot, but it
>>> >>  | looks right and in a sans serif font that looks about right.
>>> >>
>>> >>  What versions of freetype and fontconfig do you have installed?  I
>>> >>  seem to have freetype 2.3.9 and fontconfig 2.6.0.
>>> >>
>>>        
>> >
>> >  [vzero:plot] rpm -q fontconfig
>> >  fontconfig-2.7.1-1.fc11.x86_64
>> >  fontconfig-2.7.1-1.fc11.i586
>> >  [vzero:plot] rpm -q freetype
>> >  freetype-2.3.9-5.fc11.x86_64
>> >  freetype-2.3.9-5.fc11.i586
>> >
>>      
>>> >>  When I try something like
>>> >>
>>> >>     set (0, 'defaultaxesfontname', 'foobarfont')
>>> >>     set (0, 'defaulttextfontname', 'foobarfont')
>>> >>     text (0.5, 0.5, 'foobar')
>>> >>
>>> >>  I don't see a crash.  It still works for me and uses some default
>>> >>  font (even without the change I sent to you).  Stepping through
>>> >>  ft_manager::do_get_font, I see that the font name is "foobarfont", but
>>> >>  even so, FcFontMatch returns a valid font object.  That's apparently
>>> >>  not happening for you, so maybe there is a difference in the versions
>>> >>  of freetype and/or fontconfig that we have installed, and my version
>>> >>  is returning some default font when there is no match on the font
>>> >>  pattern?  I see there is a call to
>>> >>
>>> >>  This all works for me even if I remove what I think are the
>>> >>  corresponding font packages that you mentioned.  On my system:
>>> >>
>>> >>     xfonts-base xfonts-100dpi xfonts-75dpi
>>> >>
>>> >>  So now I'm a bit confused about exactly what dependency we should be
>>> >>  adding.
>>> >>
>>>        
>> >
>> >  I am not clear about this either.  Right now I do not have
>> >  a copy of the current system without the patch that removes the
>> >  error::  lines.
>>      
>>> >>
>>> >>  jwe
>>> >>
>>>        
> I could not understand what the original problem was here.
>
>    
No need to worry about this.  The problem was with
interpreter tex mode.  This fails if some fonts are not
installed.  There is still a general problem of how to
avoid problems with differing fonts on all the different
systems.  Sadly, the Linux community has decided that
each distribution should have a random set of fonts,
with some "automatically" installed and others only
installed depending on specific packages...
>> >  In any case, the fonts that I mentioned,
>> >  xorg-x11-fonts-75dpi-7.2-8.fc11.noarch
>> >  xorg-x11-fonts-100dpi-7.2-8.fc11.noarc
>> >  only fixed the "interpreter", "tex" problem
>> >  in the unpatched system.
>> >
>> >  To add a brief summary of what I know about fltk/OpenGL:
>> >
>> >  1. With the unofficial patches, all plotting that I have
>> >      tried seems to work well.  This is mainly plots that
>> >      gnuplot could not handle at all.
>> >
>> >  2. The things that do not work are print, and the
>> >      "interpreter", "tex" mode.  The main reason print
>> >      fails to do anything is that the drawnow call seems
>> >      to do nothing.  It is clear that ghostscript is not being
>> >      set up correctly. I made a few changes in print.m to
>> >      get that far.  "interpreter", "tex"  is just ignored.
>>      
> The status of the fltk/OpenGL backend as far as I know is consistent
> with your observation: printing is not yet implemented - it is (was?)
> planned to be done using the gl2ps library (actually consisting of one
> c-file and one h-file). the tex interpreter is also unimplemented but
> as I understand Michael Goffioul laid down the groundwork for using
> LaTeX in the current text handling routines in that they use cached
> bitmaps, which are now generated by freetype, but could be generated
> by LaTeX.
> I don't think I'll be able to work on these for at least the coming
> month or so, but I will be available for email questions.
>
> Shai
>
>    
>> >  There may be more significant problems, but I think
>> >  that with the 2 above items resolved it would at least
>> >  be at a point where it could be made available as
>> >  a "beta" test.
>>      
> IMHO lack of printing is the #1 issue. tex is more on the nice to have list
>    
This is basically correct, but the TeX mode is very helpful,
at least for me.
> Shai
>    
Thanks for your response.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090902/041c0fea/attachment.html 

From soren at hauberg.org  Wed Sep  2 23:29:52 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 02 Sep 2009 21:29:52 -0700
Subject: A backend("fltk") problem
In-Reply-To: <420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
Message-ID: <1251952192.5467.3.camel@sh-t400>

tor, 03 09 2009 kl. 06:46 +0300, skrev Shai Ayal:
> IMHO lack of printing is the #1 issue.

I don't really know OpenGL, but wouldn't it be fairly simple to make
printing to bitmaps work? All you would have to do is to get access to
the buffer in which OpenGL performs the rendering and write that to disc
as an image. Since we have image writing (via 'imwrite') the only
problem would be to get access to the OpenGL buffer. I assume this is
trivial, but since I don't know OpenGL I might be mistaken.

Of course printing to a vector format is more useful, but this would be
a nice start.

S?ren



From godfrey at isl.stanford.edu  Thu Sep  3 00:47:46 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 02 Sep 2009 22:47:46 -0700
Subject: A backend("fltk") problem
In-Reply-To: <1251952192.5467.3.camel@sh-t400>
References: <4A9749CF.6030708@isl.stanford.edu>	
	<19101.34310.961893.954083@segfault.lan>	
	<4A9D906A.8030606@isl.stanford.edu>	
	<19101.37238.710823.546142@segfault.lan>	
	<4A9D9C7B.9050101@isl.stanford.edu>	
	<19102.57857.878905.590704@segfault.lan>	
	<4A9EF679.8050205@isl.stanford.edu>	
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
	<1251952192.5467.3.camel@sh-t400>
Message-ID: <4A9F5882.3090607@isl.stanford.edu>

On 09/02/2009 09:29 PM, S?ren Hauberg wrote:
> Of course printing to a vector format is more useful, but this would be
> a nice start.
>
> S?ren
>
>
>    
Take a look at:
http://www.geuz.org/gl2ps/

This seems like a good choice.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090902/ee62cd96/attachment-0001.html 

From shaiay at gmail.com  Thu Sep  3 01:27:03 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 3 Sep 2009 09:27:03 +0300
Subject: A backend("fltk") problem
In-Reply-To: <4A9F5882.3090607@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
	<1251952192.5467.3.camel@sh-t400> <4A9F5882.3090607@isl.stanford.edu>
Message-ID: <420fb9e60909022327r1b39d9a6kf1ec9c2ea15e4bed@mail.gmail.com>

> Take a look at:
> http://www.geuz.org/gl2ps/
>
> This seems like a good choice.

I agree that gl2ps is the best choice and, as I said earlier, it
consists of two files - a c-file and an h-file. I have some experience
from octplot with it, so I can tell you the problems right away :)
Text as usual. The PS fonts might have different metrics than the
screen fonts. This I tried to solve by using screen fionts which are
identical to the PS built-in fonts
If you want to use LaTeX style text with super & subscripts, gl2ps
does not support it out of the box and will have to be modified, but I
think the other Michael G. has already done something similar in
jhandles in the past, so he cxan give advice.

Shai

From marco_atzeri at yahoo.it  Thu Sep  3 03:01:26 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Thu, 3 Sep 2009 08:01:26 +0000 (GMT)
Subject: 3.2.3 RC2
In-Reply-To: <19102.47512.91816.791481@segfault.lan>
Message-ID: <856086.16041.qm@web25505.mail.ukl.yahoo.com>

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

 
> I also see this failure, but it doesn't happen on every
> run.? I'm
> running Octave on an amd64 system.
> 
> The test is:
> 
> ? n = 100;
> ? k = 7;
> ? a =
> sparse([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],[ones(1,n-2),0.4*n*ones(1,n),ones(1,n-2)]);
> ? [u,s,v] = svd(full(a));
> ? s = diag(s);
> ? [dum, idx] = sort(abs(s));
> ? s = s(idx);
> ? u = u(:,idx);
> ? v = v(:,idx);
> ? [u2,s2,v2,flag] = svds(a,k,0);
> ? s2 = diag(s2);
> ? assert(flag,!1);
> ? assert(s(k:-1:1), s2, 1e-10); 
> 
> If you run this repeatedly, do you see some successes and
> some
> failures?? If it does fail, do you see that the first
> assert sometimes
> fails, and other times it is the second?
> 
> I have not tried to debug the problem yet.
> 
> David, I'm copying you because you wrote svds and might be
> able to see
> the problem and perhaps a fix more quickly than I could.
> 
> Thanks,
> 
> jwe
> 

just tested on 3.2.3-RC1 on cygwin

first OK

second
warning: returning fewer singular values than requested
warning: try increasing the value of sigma

third
 error: assert (s (k:-1:1),s2,1e-10) expected
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004
but got
   38.060
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004
Dimensions don't match
error: called from:


similar on latest mercurial 

Marco



      



From highegg at gmail.com  Thu Sep  3 03:43:07 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 3 Sep 2009 10:43:07 +0200
Subject: FYI: reusing temporaries in nested array expressions
Message-ID: <69d8d540909030143o4095b66duec006532726a74cd@mail.gmail.com>

hi all,

using the machinery for in-place evaluation of computed assignment
operators (+=, *= etc), I implemented another possibly useful
optimization:
When evaluating nested expressions, Octave will now make some attempts
to reuse temporary arrays instead of allocating new one for each
result.
For instance, the expression
2*a + b
where a and b are large arrays, will now be done like this:

allocate c
forall i: c(i) = 2*a(i)
forall i: c(i) = c(i) + b(i)
c is the result

previously, the flow was slightly different:

allocate c
forall i: c(i) = 2*a(i)
allocate d
forall i: d(i) = c(i) + b(i)
deallocate c
d is the result

i.e., the memory requirements are cut down by the size of c. The
interpreter is not extra smart about this, it only reuses temporaries
from left to right, so that
(a+b)*2 will reuse a+b, but 2*(a+b) won't. The latter would need a bit
extensive checking whether the operand order can be changed, and I
don't think it's worth the trouble.
Also, the unary operators - and ! applied on a temporary will work
in-place; for instance
mask = ! isnan (x);
will actually work like this
mask = isnan (x);
for i=1:n; mask(i) = ! mask (i); end
but of course the loop is internal and compiled.

Besides the memory savings, it appears that the in-place loops are
slightly faster in some cases.
Consider the following benchmark:

n = 5000;
a = rand (n); b = rand (n);

disp ("sequential out-of-place evaluation");
tic;
c = a + 1;
c = c .* b;
c = c - 1;
toc

disp ("sequential in-place evaluation");
tic;
c = a;
c += 1;
c .*= b;
c -= 1;
toc

disp ("natural form evaluation");
tic;
c = (a + 1) .* b - 1;
toc

Core 2 Duo @ 2.83 GHz, g++ -O3 -march=native

Using octave 3.2.3 RC2, I get:

sequential out-of-place evaluation
Elapsed time is 0.432471 seconds.
sequential in-place evaluation
Elapsed time is 0.441618 seconds.
natural form evaluation
Elapsed time is 0.453721 seconds.

With a recent tip, I get:

sequential out-of-place evaluation
Elapsed time is 0.434277 seconds.
sequential in-place evaluation
Elapsed time is 0.331977 seconds.
natural form evaluation
Elapsed time is 0.445641 seconds.

and with the new patch, I get:

sequential out-of-place evaluation
Elapsed time is 0.433064 seconds.
sequential in-place evaluation
Elapsed time is 0.332374 seconds.
natural form evaluation
Elapsed time is 0.331975 seconds.

it seems the speed-up can go up to some 25%. Technically, I'm not sure
why that is happening, as the number of operations should be the same,
maybe it's cache effects, or easier optimization. In any case, I think
it's nice to have Octave do the evaluation a little smarter (yeah it's
the defend-your-own-ideas attitude).

enjoy

-- 
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 05:17:34 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Thu, 3 Sep 2009 10:17:34 +0000 (GMT)
Subject: Changeset : SPARSE_LIBS order in Makeconf.in 
Message-ID: <737763.88993.qm@web25501.mail.ukl.yahoo.com>

Hi,
attached change to meet the expected order of 

  SPARSE_LIBS = \
-  $(AMD_LIBS) $(CAMD_LIBS) $(COLAMD_LIBS) \
-    $(CCOLAMD_LIBS) $(CHOLMOD_LIBS) $(CXSPARSE_LIBS) \
-    $(UMFPACK_LIBS)
+    $(CHOLMOD_LIBS) $(UMFPACK_LIBS) \
+    $(AMD_LIBS) $(CAMD_LIBS) $(COLAMD_LIBS) \
+    $(CCOLAMD_LIBS) $(CXSPARSE_LIBS)

at least on cygwin the order is important.

Regards
Marco Atzeri



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hg_sparse_libs.patch
Type: text/x-diff
Size: 1324 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090903/d1cc54b3/attachment.bin 

From highegg at gmail.com  Thu Sep  3 05:21:34 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 3 Sep 2009 12:21:34 +0200
Subject: development snapshot
In-Reply-To: <19102.49674.637449.216165@segfault.lan>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
Message-ID: <69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>

On Wed, Sep 2, 2009 at 9:05 PM, John W. Eaton<jwe at octave.org> wrote:
> On 29-Jul-2009, Jaroslav Hajek wrote:
>
> | what about making a development snapshot soon, perhaps now?
> | Further, src/version.h still shows version 3.1.55 and api-v37. Is it
> | OK if I change it to 3.3.1 and api-v38?
>
> Sorry for not responding to this message earlier. ?Is now a good time
> to make a new snapshot?

I think so.

>?If there are no objections, I will try to
> start making more regular snapshots again. ?Should we start with
> 3.3.1?

I never understood why there was 3.1.50 instead of 3.1.0, but if
there's a good explanation I've missed...

> 3.3.50? ?Should we start planning for a new release? ?If so,
> what features are most important?
>

As far as I'm concerned, I've implemented most of my ideas, except
finishing fminbnd and some mapper improvements (erfinv, erfcx).
Everything's in NEWS (I see all entries are mine; isn't something
missing here?). A little more cleanup in liboctave is also possible.

I don't know what else is wanted.

New-style class support may be nice, but given the current status, is
it realistic to expect?
(Personally I'm happy, so far at least, with the old-style classes for
my purposes (only encapsulation), so I've got little motivation to
work on that; besides, I think it would be better done by someone who
has access to Matlab).

Concerning the FLTK backend or other plotting projects, I'm completely ignorant.

In any case, I'd appreciate a snapshot soon, perhaps now, despite
features still missing.

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  Thu Sep  3 08:55:33 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Thu, 3 Sep 2009 13:55:33 +0000 (GMT)
Subject: Changeset: LD_PRELOAD on run-octave.in and cygwin documentation
Message-ID: <596208.87279.qm@web25501.mail.ukl.yahoo.com>

Hi,
order and separator change on run-octave.in 

-LD_PRELOAD="$liboctinterp $liboctave $libcruft" \
+LD_PRELOAD="$libcruft:$liboctave:$liboctinterp" \


plus dedicated comment on README.Cygwin.

Regards
Marco Atzeri


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hg_preload_2.patch
Type: text/x-diff
Size: 3508 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090903/9330272d/attachment.bin 

From jwe at octave.org  Thu Sep  3 09:53:58 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 3 Sep 2009 10:53:58 -0400
Subject: Changeset: LD_PRELOAD on run-octave.in and cygwin documentation
In-Reply-To: <596208.87279.qm@web25501.mail.ukl.yahoo.com>
References: <596208.87279.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <19103.55430.498024.97808@segfault.lan>

On  3-Sep-2009, Marco Atzeri wrote:

| order and separator change on run-octave.in 
| 
| -LD_PRELOAD="$liboctinterp $liboctave $libcruft" \
| +LD_PRELOAD="$libcruft:$liboctave:$liboctinterp" \

The change in order is probably OK, but I'm not sure about making an
unconditional change from spaces to colons for separators.  The man
page for ld.so on my Debian system specifically says that LD_PRELOAD
is a whitespace-separated list.  Same for the ld.so man page I found
for Solaris on the web.  Although it is not documented, my system also
allows :, but I'm not sure about other systems.  Can someone with
access to a Solaris system check?

| plus dedicated comment on README.Cygwin.

If we make some change in the run-octave script, then I don't think
all the notes you added are necessary.

Since the run-octave script is generated, how about fixing the
commands that generate the LD_PRELOAD line so that your change is only
made for Cygwin systems?

jwe

From jwe at octave.org  Thu Sep  3 11:01:29 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 3 Sep 2009 12:01:29 -0400
Subject: development snapshot
In-Reply-To: <69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
Message-ID: <19103.59481.557945.168889@segfault.lan>

On  3-Sep-2009, Jaroslav Hajek wrote:

| On Wed, Sep 2, 2009 at 9:05 PM, John W. Eaton<jwe at octave.org> wrote:
| > On 29-Jul-2009, Jaroslav Hajek wrote:
| >
| > | what about making a development snapshot soon, perhaps now?
| > | Further, src/version.h still shows version 3.1.55 and api-v37. Is it
| > | OK if I change it to 3.3.1 and api-v38?
| >
| > Sorry for not responding to this message earlier. ?Is now a good time
| > to make a new snapshot?
| 
| I think so.
| 
| >?If there are no objections, I will try to
| > start making more regular snapshots again. ?Should we start with
| > 3.3.1?
| 
| I never understood why there was 3.1.50 instead of 3.1.0, but if
| there's a good explanation I've missed...

3.1.0 looks like a stable release version, 3.1.50 doesn't (at least to
me).

| As far as I'm concerned, I've implemented most of my ideas, except
| finishing fminbnd and some mapper improvements (erfinv, erfcx).
| Everything's in NEWS (I see all entries are mine; isn't something
| missing here?). A little more cleanup in liboctave is also possible.
| 
| I don't know what else is wanted.

My immediate plans are to work more on 64-bit support.  This mostly
means improved configure checks, but we also need to have large file
support.  I'm not sure what to do with Octave's binary file types
(load/save) as those have fixed 32-bit integer sizes for storing array
dimensions.  I guess this is why Matlab is now using some kind of HDF5
file format?

| New-style class support may be nice, but given the current status, is
| it realistic to expect?

I would be happy to see someone working on it, but I think that
project is too large to expect it to be working by the next stable
release.

| Concerning the FLTK backend or other plotting projects, I'm
| completely ignorant.

Likewise, I'm almost completely ignorant, but I would like to see this
improved to the point where it is useable by the next stable release,
then possibly switch to it as the default for the following stable
release.

| In any case, I'd appreciate a snapshot soon, perhaps now, despite
| features still missing.

OK.  I'll try to make one later today or tomorrow.

jwe


From jwe at octave.org  Thu Sep  3 11:01:29 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 3 Sep 2009 12:01:29 -0400
Subject: development snapshot
In-Reply-To: <69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
Message-ID: <19103.59481.557945.168889@segfault.lan>

On  3-Sep-2009, Jaroslav Hajek wrote:

| On Wed, Sep 2, 2009 at 9:05 PM, John W. Eaton<jwe at octave.org> wrote:
| > On 29-Jul-2009, Jaroslav Hajek wrote:
| >
| > | what about making a development snapshot soon, perhaps now?
| > | Further, src/version.h still shows version 3.1.55 and api-v37. Is it
| > | OK if I change it to 3.3.1 and api-v38?
| >
| > Sorry for not responding to this message earlier. ?Is now a good time
| > to make a new snapshot?
| 
| I think so.
| 
| >?If there are no objections, I will try to
| > start making more regular snapshots again. ?Should we start with
| > 3.3.1?
| 
| I never understood why there was 3.1.50 instead of 3.1.0, but if
| there's a good explanation I've missed...

3.1.0 looks like a stable release version, 3.1.50 doesn't (at least to
me).

| As far as I'm concerned, I've implemented most of my ideas, except
| finishing fminbnd and some mapper improvements (erfinv, erfcx).
| Everything's in NEWS (I see all entries are mine; isn't something
| missing here?). A little more cleanup in liboctave is also possible.
| 
| I don't know what else is wanted.

My immediate plans are to work more on 64-bit support.  This mostly
means improved configure checks, but we also need to have large file
support.  I'm not sure what to do with Octave's binary file types
(load/save) as those have fixed 32-bit integer sizes for storing array
dimensions.  I guess this is why Matlab is now using some kind of HDF5
file format?

| New-style class support may be nice, but given the current status, is
| it realistic to expect?

I would be happy to see someone working on it, but I think that
project is too large to expect it to be working by the next stable
release.

| Concerning the FLTK backend or other plotting projects, I'm
| completely ignorant.

Likewise, I'm almost completely ignorant, but I would like to see this
improved to the point where it is useable by the next stable release,
then possibly switch to it as the default for the following stable
release.

| In any case, I'd appreciate a snapshot soon, perhaps now, despite
| features still missing.

OK.  I'll try to make one later today or tomorrow.

jwe


From marco_atzeri at yahoo.it  Thu Sep  3 12:08:20 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Thu, 3 Sep 2009 17:08:20 +0000 (GMT)
Subject: R: Changeset: LD_PRELOAD on run-octave.in and cygwin documentation
In-Reply-To: <19103.55430.498024.97808@segfault.lan>
Message-ID: <218277.46511.qm@web25503.mail.ukl.yahoo.com>

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

> Da: John W. Eaton <jwe at octave.org>
> Oggetto: Changeset: LD_PRELOAD on run-octave.in and cygwin documentation
> A: "Marco Atzeri" <marco_atzeri at yahoo.it>
> Cc: "octave maintainers list" <maintainers at octave.org>
> Data: Gioved? 3 settembre 2009, 16:53
> On? 3-Sep-2009, Marco Atzeri
> wrote:
> 
> | order and separator change on run-octave.in 
> | 
> | -LD_PRELOAD="$liboctinterp $liboctave $libcruft" \
> | +LD_PRELOAD="$libcruft:$liboctave:$liboctinterp" \
> 
> The change in order is probably OK, but I'm not sure about
> making an
> unconditional change from spaces to colons for
> separators.? The man
> page for ld.so on my Debian system specifically says that
> LD_PRELOAD
> is a whitespace-separated list.? Same for the ld.so
> man page I found
> for Solaris on the web.? Although it is not
> documented, my system also
> allows :, but I'm not sure about other systems.? Can
> someone with
> access to a Solaris system check?

LD_PRELOAD should be both a colon-separated or space-separated
but I lost the reference to the relevant document.

Of course it is also possible the some system don't like
the colon-separated as cygwin don't like the space-separated;
in this case the change is not acceptable.

> 
> | plus dedicated comment on README.Cygwin.
> 
> If we make some change in the run-octave script, then I
> don't think
> all the notes you added are necessary.

If we change run-octave fine, otherwise the change in
README.Cygwin should be enough to advise the next that
falls on this cygwin peculiarity.  

> 
> Since the run-octave script is generated, how about fixing
> the
> commands that generate the LD_PRELOAD line so that your
> change is only
> made for Cygwin systems?

no problem, I have just no clue how to do it.

> 
> jwe
> 

Marco



      



From octave at phaselockedsystems.com  Thu Sep  3 12:10:33 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Thu, 03 Sep 2009 10:10:33 -0700
Subject: development snapshot
In-Reply-To: <19103.59481.557945.168889@segfault.lan>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>	<19102.49674.637449.216165@segfault.lan>	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
Message-ID: <4A9FF889.6040007@phaselockedsystems.com>

I still plan to work on it.  Hopefully I have two or three more weekends 
on this other project and then back to octave.

There are still issues with legacy OOP and the new-style stuff will be a 
big project in itself, so it is really unrealistic to hold a stable 
release for any OOP stuff (unless someone else kicks in and does it).

Bob

> | New-style class support may be nice, but given the current status, is
> | it realistic to expect?
>
> I would be happy to see someone working on it, but I think that
> project is too large to expect it to be working by the next stable
> release.
>   


From dbateman at dbateman.org  Thu Sep  3 16:40:28 2009
From: dbateman at dbateman.org (David Bateman)
Date: Thu, 03 Sep 2009 23:40:28 +0200
Subject: 3.2.3 RC2
In-Reply-To: <892b16670909021139r58c9c849ke484166dba6817d9@mail.gmail.com>
References: <892b16670909011435t7838c4a6g3436e6c28e7fc63b@mail.gmail.com>	
	<480941.19682.qm@web25502.mail.ukl.yahoo.com>	
	<892b16670909011521t132a5f30yab9d47ed354471b6@mail.gmail.com>	
	<19102.47512.91816.791481@segfault.lan>
	<892b16670909021139r58c9c849ke484166dba6817d9@mail.gmail.com>
Message-ID: <4AA037CC.4070603@dbateman.org>

Dmitri A. Sergatskov wrote:
> On Wed, Sep 2, 2009 at 1:29 PM, John W. Eaton<jwe at octave.org> wrote:
>
>   
>> The test is:
>>
>>  n = 100;
>>  k = 7;
>>  a = sparse([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],[ones(1,n-2),0.4*n*ones(1,n),ones(1,n-2)]);
>>  [u,s,v] = svd(full(a));
>>  s = diag(s);
>>  [dum, idx] = sort(abs(s));
>>  s = s(idx);
>>  u = u(:,idx);
>>  v = v(:,idx);
>>  [u2,s2,v2,flag] = svds(a,k,0);
>>  s2 = diag(s2);
>>  assert(flag,!1);
>>  assert(s(k:-1:1), s2, 1e-10);
>>
>> If you run this repeatedly, do you see some successes and some
>> failures?  If it does fail, do you see that the first assert sometimes
>> fails, and other times it is the second?
>>     
>
>   
I'd always had problems with ARPACK with matrices with lots of 
eigenvalues very close to each other and this test case was deliberately 
create to make life hard for ARPACK in this manner. Basically it seems 
iterative eigensolvers don't seem to like cases like that.

This test matrix has 100 real eigenvalues between 38 and 40, and it used 
to run fine for me, but I too am now seeing the same errors.. I suspect 
minor changes in the optimizations of the compiler that mean that the 
eigensolver no longer converges.

Choose a sigma of zero was to ensure that the smallest eigenvalues were 
always found and choosing a sigma closer to the actual minimum 
eigenvalue  will improve the convergence. Changing the line

  [u2,s2,v2,flag] = svds(a,k,0);

to

  [u2,s2,v2,flag] = svds(a,k,38);

or even

  [u2,s2,v2,flag] = svds(a,k,0.1);

removes this issue for me. So if we just assume that this is a 
particularly nasty problem, that ARPACK has difficulties handling then 
I'd suggest making this change as a means of getting the tests to pass 
while still testing the functionality of svds

D.

> It is alway seems to be in the second, but I get different warnings from
> time to time.  Most often it is:
>
> warning: returning fewer singular values than requested
> warning: try increasing the value of sigma
> error: assert (s (k:-1:1),s2,1e-10) expected
>    38.034
>    38.034
>    38.015
>    38.015
>    38.004
>    38.004
> but got
>    38.060
>    38.034
>    38.034
>    38.015
>    38.015
>    38.004
>    38.004
> Dimensions don't match
>   
WIth this issue you get a warning, so I'd consider this less of a problem..

>
> but sometimes it is just:
>
> error: assert (s (k:-1:1),s2,1e-10) expected
>    38.060
>    38.060
>    38.034
>    38.034
>    38.015
>    38.015
>    38.004
> but got
>    38.060
>    38.034
>    38.034
>    38.015
>    38.015
>    38.004
>    38.004
> maximum absolute error 0.0263523 exceeds tolerance 1e-10
>   

This one you don't get a warning and you're missing one of the pair of 
the minimum eigenvalue..

D.

>
>   
>> I have not tried to debug the problem yet.
>>
>> David, I'm copying you because you wrote svds and might be able to see
>> the problem and perhaps a fix more quickly than I could.
>>
>> Thanks,
>>
>> jwe
>>
>>     
>
> Dmitri.
> --
>
>   



-- 
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 leonardo at cose.fee.unicamp.br  Thu Sep  3 18:06:59 2009
From: leonardo at cose.fee.unicamp.br (Leonardo Martins)
Date: Thu, 3 Sep 2009 20:06:59 -0300
Subject: Contribution to the optimization toolbox
Message-ID: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>

Hello there,

I'm an experienced MATLAB user who has been working on applied
optimization for the last 6+ years and have recently been introduced
to the latest developments in Octave. Although many impressive
improvements have been done in several areas since last time I played
with Octave, from my very own perspective quite a few things could be
done for the optimization toolbox. I believe many MATLAB Optimization
Toolbox users would love to switch to Octave, and that's why I'm
writing to you.

I'm willing to help on the implementation of algorithms I have worked
on for the Octave base, but first would like to know from the
maintainers what the current development status is, and also what are
the plans for future improvements. I have experience with interior
point algorithms for nonlinear programming, as well C and MATLAB
programming.

Bottomline is: I would like to help but don't know how and where to start.

Thanks for your attention.

Regards,

  -- L.M.
Ph.D Student
School of Electrical and Computer Engineering
University of Campinas, Brazil

From godfrey at isl.stanford.edu  Thu Sep  3 22:38:19 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 03 Sep 2009 20:38:19 -0700
Subject: A backend("fltk") problem
In-Reply-To: <19102.49796.832539.546198@segfault.lan>
References: <4A9749CF.6030708@isl.stanford.edu>	<19101.34310.961893.954083@segfault.lan>	<4A9D906A.8030606@isl.stanford.edu>	<19101.37238.710823.546142@segfault.lan>	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.49796.832539.546198@segfault.lan>
Message-ID: <4AA08BAB.7070305@isl.stanford.edu>

On 09/02/2009 12:07 PM, John W. Eaton wrote:
> | So, in the very short run, just to improve on the current
> | seg fault, a changest that deletes lines 149-151,
> | tests for the existence of the FreeSans.ttf file in order
> | to produce some error message indicating the need
> | for that font, and then applies to line in your previous
> | patch  would be a help.
>
> I will try to propose a patch later today.
>
> jwe
>    
John, I just confirmed on my Fedora 11 x86_64 system, and
using the version of Octave with your emailed patch and the
error: removed, I get:

1. If the /usr/share/fonts/truetype/freefont/...   is removed
     the system seg faults with:
octave:2> title("hello")
octave:3> error: ft_manager: unable to load font: 
/usr/share/fonts/truetype/freefont/FreeSans.ttf
error: ft_render: unable to load appropriate font
error: ft_render: font not initialized
error: octave_base_value::convert_to_str_internal (): wrong type 
argument `<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type 
argument `<unknown type>'
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault
====================================

2. If the 2 fonts xorg-x11-fonts-75dpi-7.2-8.fc11.noarch
     and xorg-x11-fonts-100dpi-7.2-8.fc11.noarch are NOT
    installed the interpreter tex mechanism (in the
    backend("gnuplot")) stops working.
====================================

I am not sure that everyone reading this thread found these
facts clearly stated.

So, the one short-run fix should be to do something to
avoid the seg fault even though the "last resort" font is not
there, or make its installation part of Octave.  I think a test
that prevents seg fault is still called for.  The font could get
deleted, or, ...

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090903/42e97157/attachment.html 

From michael.creel at uab.es  Fri Sep  4 02:54:16 2009
From: michael.creel at uab.es (Michael Creel)
Date: Fri, 4 Sep 2009 09:54:16 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
Message-ID: <c8f260e70909040054td627b9dp5d276bfb928b53d7@mail.gmail.com>

Hi Leonardo,
I'm the author of samin and bfgsmin, which are in the optim toolbox.
The optim toolbox is a collection of tools by different authors,
without any planning or coordination. It's open to anyone who has
contributions to make. If someone has enough interest and energy to
try to make it a little more homogeneous, coordinated and complete,
that would be great.
Cheers, Michael

On Fri, Sep 4, 2009 at 1:06 AM, Leonardo Martins
<leonardo at cose.fee.unicamp.br> wrote:
> Hello there,
>
> I'm an experienced MATLAB user who has been working on applied
> optimization for the last 6+ years and have recently been introduced
> to the latest developments in Octave. Although many impressive
> improvements have been done in several areas since last time I played
> with Octave, from my very own perspective quite a few things could be
> done for the optimization toolbox. I believe many MATLAB Optimization
> Toolbox users would love to switch to Octave, and that's why I'm
> writing to you.
>
> I'm willing to help on the implementation of algorithms I have worked
> on for the Octave base, but first would like to know from the
> maintainers what the current development status is, and also what are
> the plans for future improvements. I have experience with interior
> point algorithms for nonlinear programming, as well C and MATLAB
> programming.
>
> Bottomline is: I would like to help but don't know how and where to start.
>
> Thanks for your attention.
>
> Regards,
>
> ?-- L.M.
> Ph.D Student
> School of Electrical and Computer Engineering
> University of Campinas, Brazil
>


From toroklev at gmail.com  Fri Sep  4 03:13:08 2009
From: toroklev at gmail.com (Levente Torok)
Date: Fri, 4 Sep 2009 10:13:08 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909040054td627b9dp5d276bfb928b53d7@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909040054td627b9dp5d276bfb928b53d7@mail.gmail.com>
Message-ID: <df8aed3b0909040113v2630dc9dr65a2d6ed5c19b972@mail.gmail.com>

Hi Leonardo,

I would like to suggest to start implementing of those functions that
you have already used in matlab
in order to make possible to run your former codes on octave similar to matlab.
It would be a help for yourself and everybody as well.
Or you might analyse functions in optimization package of matlab and
implement those that you find most missing form the
octave.
Cheers,

Levente

On Fri, Sep 4, 2009 at 9:54 AM, Michael Creel<michael.creel at uab.es> wrote:
> Hi Leonardo,
> I'm the author of samin and bfgsmin, which are in the optim toolbox.
> The optim toolbox is a collection of tools by different authors,
> without any planning or coordination. It's open to anyone who has
> contributions to make. If someone has enough interest and energy to
> try to make it a little more homogeneous, coordinated and complete,
> that would be great.
> Cheers, Michael
>
> On Fri, Sep 4, 2009 at 1:06 AM, Leonardo Martins
> <leonardo at cose.fee.unicamp.br> wrote:
>> Hello there,
>>
>> I'm an experienced MATLAB user who has been working on applied
>> optimization for the last 6+ years and have recently been introduced
>> to the latest developments in Octave. Although many impressive
>> improvements have been done in several areas since last time I played
>> with Octave, from my very own perspective quite a few things could be
>> done for the optimization toolbox. I believe many MATLAB Optimization
>> Toolbox users would love to switch to Octave, and that's why I'm
>> writing to you.
>>
>> I'm willing to help on the implementation of algorithms I have worked
>> on for the Octave base, but first would like to know from the
>> maintainers what the current development status is, and also what are
>> the plans for future improvements. I have experience with interior
>> point algorithms for nonlinear programming, as well C and MATLAB
>> programming.
>>
>> Bottomline is: I would like to help but don't know how and where to start.
>>
>> Thanks for your attention.
>>
>> Regards,
>>
>> ?-- L.M.
>> Ph.D Student
>> School of Electrical and Computer Engineering
>> University of Campinas, Brazil
>>
>
>


From highegg at gmail.com  Fri Sep  4 03:33:48 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 4 Sep 2009 10:33:48 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
Message-ID: <69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>

On Fri, Sep 4, 2009 at 1:06 AM, Leonardo
Martins<leonardo at cose.fee.unicamp.br> wrote:
> Hello there,
>
> I'm an experienced MATLAB user who has been working on applied
> optimization for the last 6+ years and have recently been introduced
> to the latest developments in Octave. Although many impressive
> improvements have been done in several areas since last time I played
> with Octave, from my very own perspective quite a few things could be
> done for the optimization toolbox. I believe many MATLAB Optimization
> Toolbox users would love to switch to Octave, and that's why I'm
> writing to you.
>
> I'm willing to help on the implementation of algorithms I have worked
> on for the Octave base, but first would like to know from the
> maintainers what the current development status is, and also what are
> the plans for future improvements. I have experience with interior
> point algorithms for nonlinear programming, as well C and MATLAB
> programming.
>
> Bottomline is: I would like to help but don't know how and where to start.
>
> Thanks for your attention.
>
> Regards,
>
> ?-- L.M.
> Ph.D Student
> School of Electrical and Computer Engineering
> University of Campinas, Brazil
>

Regarding the status of Octave core, it currently includes
fzero (1d nonlinear equation),
fsolve (n-d nonl. eqn.), fminunc (n-d unc. min.)

lsqnonneg (least squares with non-negative variables)
glpk (linear programming, wrapper over GNU GLPK),
qp (quadratic programming)
sqp (general nonlinear programming)

what logically belongs amongst the first four, and is missing, is
fminbnd - 1d minimization solver. It should probably implement Brent's
or any similar method combining golden section search with inverse
interpolation (quadratic or higher), and should be patterned after
fzero, including the optimget/optimset support. I intend to eventually
do that myself, but I would be grateful for any help. Of course, the
1D algorithm is relatively simple and well-known, but it could be a
good start for you.

qp and sqp are more elaborate. qp could probably benefit from the QR
and Cholesky updating classes recently introduced into Octave, to
avoid matrix factorizations in each step. I guess that would be a big
project, though.

regarding the optim package of OctaveForge, as Michael said, there is
currently no organization or development direction; it's just a
collection of optimization codes from various authors. You can
contribute virtually anything here now. In the future, I'd like to
make the package more orthogonal to Octave core and reuse some of its
mechanisms, in particular optimget/optimset.

In any case, if you'd like to contribute to Octave, it's vital you
start working with the development sources.

if you have further questions, don't suppress them :)

regards

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


From tmacchant at yahoo.co.jp  Fri Sep  4 05:15:59 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Fri, 4 Sep 2009 19:15:59 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <20090902120924.308010@gmx.net>
Message-ID: <20090904101559.68008.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello Ben Abbott and Benjamin Lindner

--- Benjamin Lindner  wrote:

> 
> > 
> > changeset:   9395:54a3fa5d4376
> > user:        Ben Abbott <bpabbott at mac.com>
> > date:        Thu Aug 06 07:30:34 2009 +0200
> > summary:     Avoid the flickering x11 window seen with rapid gnuplot
> > updates.
> > http://hg.tw-math.de/release-3-2-x/rev/54a3fa5d4376
> > 
> > 
> > The above changeset seems to be the origin by which mouse  zooming in 2D 
> > cannot be used.
> > 
> > I have tested binaries built  by MinGW-4.4.0 (Official Version) and the
> > gnuplot 4.3 cvs for windows
> > (the recent source) is used. The terminal is windows terminal.
> > 
> 
> I can confirm that this changeset breaks interactive usability.
> 
> > Anyway the chanageset should be re-modified to enable us to use mouse
> > zooming in windows terminal on
> > gnuplot backend.
> 
> I agree, this should be fixed, otherwise the gnuplot backend is pretty much useless on windows.

The changeset by Ben should be applied to also to "windows terminal".

The below patch solves the mouse zoom problem for windows term and problem that I have asked before

"How can I get successive plot on octave 3.2 as was obtained in octave 3.0.x"

http://www.nabble.com/How-can-I-get-successive-plot-on-octave-3.2-as-was-obtained-in-octave-3.0.x-tc24804743.html#a24839441

********************
--- gnuplot_drawnow.m.org	2009-08-26 15:17:08 +0900
+++ gnuplot_drawnow.m	2009-09-04 18:56:18 +0900
@@ -286,10 +286,10 @@
       ## the canvas size for terminals cdr/corel.
       term_str = sprintf ("%s %s", term_str, size_str);
     endif
-    ## Work around the gnuplot feature of growing the x11 window when
+    ## Work around the gnuplot feature of growing the x11 and windows window when
     ## the mouse and multiplot are set.
     fputs (plot_stream, "unset multiplot;\n");
-    if (! strcmp (term, "x11")
+    if (! ( strcmp (term, "x11") || strcmp (term, "windows") )
         || numel (findall (h, "type", "axes")) > 1
         || numel (findall (h, "type", "image")) > 0)
       fprintf (plot_stream, "%s\n", term_str);
@@ -299,7 +299,7 @@
         endif
       endif
       fputs (plot_stream, "set multiplot;\n");
-    elseif (strcmp (term, "x11"))
+    elseif (strcmp (term, "x11") || strcmp (term, "windows"))
       fprintf (plot_stream, "%s\n", term_str);
       if (nargin == 5)
         if (! isempty (file))
***************************************
 
I do not know whether Ben's patch should be also applied to 'aqua', 'wxt' or 'qt' term.

Regards

Tatsuto 


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

From michael.creel at uab.es  Fri Sep  4 06:24:32 2009
From: michael.creel at uab.es (Michael Creel)
Date: Fri, 4 Sep 2009 13:24:32 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>
Message-ID: <c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>

On Fri, Sep 4, 2009 at 10:33 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>
> Regarding the status of Octave core, it currently includes
> fzero (1d nonlinear equation),
> fsolve (n-d nonl. eqn.), fminunc (n-d unc. min.)
>
> lsqnonneg (least squares with non-negative variables)
> glpk (linear programming, wrapper over GNU GLPK),
> qp (quadratic programming)
> sqp (general nonlinear programming)
>
> what logically belongs amongst the first four, and is missing, is
> fminbnd - 1d minimization solver. It should probably implement Brent's
> or any similar method combining golden section search with inverse
> interpolation (quadratic or higher), and should be patterned after
> fzero, including the optimget/optimset support. I intend to eventually
> do that myself, but I would be grateful for any help. Of course, the
> 1D algorithm is relatively simple and well-known, but it could be a
> good start for you.
>
> qp and sqp are more elaborate. qp could probably benefit from the QR
> and Cholesky updating classes recently introduced into Octave, to
> avoid matrix factorizations in each step. I guess that would be a big
> project, though.
>
> regarding the optim package of OctaveForge, as Michael said, there is
> currently no organization or development direction; it's just a
> collection of optimization codes from various authors. You can
> contribute virtually anything here now. In the future, I'd like to
> make the package more orthogonal to Octave core and reuse some of its
> mechanisms, in particular optimget/optimset.
>
> In any case, if you'd like to contribute to Octave, it's vital you
> start working with the development sources.
>
> if you have further questions, don't suppress them :)
>
> regards
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>
>

With regard to optimization using Octave, there is a certain overlap
between Octave core and the optim toolbox. Likewise, algorithms appear
in both, but there is little standardized testing to make sure that
methods work well, or to figure out which of a set of algorithms works
best for a given type or problem.

To illustrate what I mean, I checked bfgsmin (in optim toolbox) and
fminunc (using Octave 3.2.3 release candidate. The test code runs 1000
replications of minimization of the Rosenbrock function (in optim
toolbox), using a random start vector. The test code is

################# test code #############################
dim = 5;
replications = 1000;
results = zeros(replications,4);
ub = 2;
lb = 0;
control = {100,0};

for i = 1:replications
	x = (ub-lb).*rand(dim,1) + lb;
	tic;
	[theta, obj_value, convergence] = bfgsmin("rosenbrock", {x}, control);
	results(i,1) = toc;
	results(i,2) = norm(theta-ones(dim,1)) < 1e-5;

	tic;
	[theta, obj_value] = fminunc("rosenbrock", x);
	results(i,3) = toc;
	results(i,4) = norm(theta-ones(dim,1)) < 1e-5;
endfor

mean(results)
#################  end test code #############################


When I run this, I get
octave:1> compare
ans =

   0.024725   0.999000   0.069155   0.972000

octave:2>

This means that bfgsmin is on average more than twice as fast as
fminunc (to be expected, perhaps, because the first is written as an
.oct function, the second is not). More importantly, bfgsmin gets the
right answer 99.9% of the time, while fminunc finds the right answer
97.2% of the time. I use the default tolerances of both methods here,
perhaps performance could be improved with a little tuning.

So, this is just to highlight the fact that there is a certain
proliferation of methods and a lack of a testbed to guide users in the
choice of algorithms. I'm sorry that I can't take on the job, but
perhaps some new and energetic users might be able to.

Michael

From highegg at gmail.com  Fri Sep  4 07:53:47 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 4 Sep 2009 14:53:47 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>
	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>
Message-ID: <69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>

On Fri, Sep 4, 2009 at 1:24 PM, Michael Creel<michael.creel at uab.es> wrote:
> On Fri, Sep 4, 2009 at 10:33 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>
>> Regarding the status of Octave core, it currently includes
>> fzero (1d nonlinear equation),
>> fsolve (n-d nonl. eqn.), fminunc (n-d unc. min.)
>>
>> lsqnonneg (least squares with non-negative variables)
>> glpk (linear programming, wrapper over GNU GLPK),
>> qp (quadratic programming)
>> sqp (general nonlinear programming)
>>
>> what logically belongs amongst the first four, and is missing, is
>> fminbnd - 1d minimization solver. It should probably implement Brent's
>> or any similar method combining golden section search with inverse
>> interpolation (quadratic or higher), and should be patterned after
>> fzero, including the optimget/optimset support. I intend to eventually
>> do that myself, but I would be grateful for any help. Of course, the
>> 1D algorithm is relatively simple and well-known, but it could be a
>> good start for you.
>>
>> qp and sqp are more elaborate. qp could probably benefit from the QR
>> and Cholesky updating classes recently introduced into Octave, to
>> avoid matrix factorizations in each step. I guess that would be a big
>> project, though.
>>
>> regarding the optim package of OctaveForge, as Michael said, there is
>> currently no organization or development direction; it's just a
>> collection of optimization codes from various authors. You can
>> contribute virtually anything here now. In the future, I'd like to
>> make the package more orthogonal to Octave core and reuse some of its
>> mechanisms, in particular optimget/optimset.
>>
>> In any case, if you'd like to contribute to Octave, it's vital you
>> start working with the development sources.
>>
>> if you have further questions, don't suppress them :)
>>
>> regards
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>>
>>
>
> With regard to optimization using Octave, there is a certain overlap
> between Octave core and the optim toolbox. Likewise, algorithms appear
> in both, but there is little standardized testing to make sure that
> methods work well, or to figure out which of a set of algorithms works
> best for a given type or problem.
>
> To illustrate what I mean, I checked bfgsmin (in optim toolbox) and
> fminunc (using Octave 3.2.3 release candidate. The test code runs 1000
> replications of minimization of the Rosenbrock function (in optim
> toolbox), using a random start vector. The test code is
>
> ################# test code #############################
> dim = 5;
> replications = 1000;
> results = zeros(replications,4);
> ub = 2;
> lb = 0;
> control = {100,0};
>
> for i = 1:replications
> ? ? ? ?x = (ub-lb).*rand(dim,1) + lb;
> ? ? ? ?tic;
> ? ? ? ?[theta, obj_value, convergence] = bfgsmin("rosenbrock", {x}, control);
> ? ? ? ?results(i,1) = toc;
> ? ? ? ?results(i,2) = norm(theta-ones(dim,1)) < 1e-5;
>
> ? ? ? ?tic;
> ? ? ? ?[theta, obj_value] = fminunc("rosenbrock", x);
> ? ? ? ?results(i,3) = toc;
> ? ? ? ?results(i,4) = norm(theta-ones(dim,1)) < 1e-5;
> endfor
>
> mean(results)
> ################# ?end test code #############################
>
>
> When I run this, I get
> octave:1> compare
> ans =
>
> ? 0.024725 ? 0.999000 ? 0.069155 ? 0.972000
>
> octave:2>
>
> This means that bfgsmin is on average more than twice as fast as
> fminunc (to be expected, perhaps, because the first is written as an
> .oct function, the second is not). More importantly, bfgsmin gets the
> right answer 99.9% of the time, while fminunc finds the right answer
> 97.2% of the time. I use the default tolerances of both methods here,
> perhaps performance could be improved with a little tuning.
>

Here is what I get testing your script, using optim-1.0.6 and
development octave.

ans =

   0.131749   0.999000   0.055406   0.970000

Since the 5D Rosenbrock function has two local optima, I'm not exactly
surprised about the 3% failures for fminunc.
I'd rather say it's interesting that bfgsmin is always successful,
despite the local optimum.

Another interesting thing is that I got the times reversed. Maybe you
used a newer version of bfgsmin?

Does it do any checking against local optima?
Also, I think bfgsmin somehow attempts to auto-discover the analytic
gradient, doesn't it? If so, does it happen in this case?

Interesting stuff starts to happen if I shift the optimum of the
objective so that x_opt(1) = 100:

ans =

   0.515509   0.010000   0.191053   0.060000


Clearly, neither code reacts well. Hmmm. Perhaps I can improve fminunc
a bit in this regard.

> So, this is just to highlight the fact that there is a certain
> proliferation of methods and a lack of a testbed to guide users in the
> choice of algorithms. I'm sorry that I can't take on the job, but
> perhaps some new and energetic users might be able to.
>

Choice of algorithms is always an art. So far fminunc got very little
testing, but I hope to put some into it as soon as I get the chance.


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


From leonardo at cose.fee.unicamp.br  Fri Sep  4 08:27:00 2009
From: leonardo at cose.fee.unicamp.br (Leonardo Martins)
Date: Fri, 4 Sep 2009 10:27:00 -0300
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>
	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>
	<69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
Message-ID: <8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>

First of all, thank you guys for promptly responding. Secondly, I have
two brief observations following your replies.

>> With regard to optimization using Octave, there is a certain overlap
>> between Octave core and the optim toolbox. Likewise, algorithms appear
>> in both, but there is little standardized testing to make sure that
>> methods work well, or to figure out which of a set of algorithms works
>> best for a given type or problem.

> Choice of algorithms is always an art. So far fminunc got very little
> testing, but I hope to put some into it as soon as I get the chance.

1) Regarding tests, has anyone ever considered interfacing
Octave/Optim Toolbox with CUTEr (http://hsl.rl.ac.uk/cuter-www/) for
more standardized testing? It can be a lot of work, but in the long
run I guess Octave can benefit from knowing exactly where it stands if
compared to other optimization software.

>>> The optim toolbox is a collection of tools by different authors,
>>> without any planning or coordination. It's open to anyone who has
>>> contributions to make. If someone has enough interest and energy to
>>> try to make it a little more homogeneous, coordinated and complete,
>>> that would be great.

2) It seemed to me that, in a first moment, rather than adding new
algorithms to the codebase, it would be more beneficial to build a
more "homogeneous and coordinated" toolbox, and only then make it
"complete." Am I right? That rises another question: what criteria are
used to determine whether a tool goes to the core/(from) toolbox? Is
there any workflow based on reliability, compatibility, or any other
criteria? Does it make more sense to work on the toolbox or the core?

I hope I'm not annoying you with so many questions. I just want to
make sure how I can be more useful to the project.

Thanks,

  -- L.M.

From michael.creel at uab.es  Fri Sep  4 09:13:23 2009
From: michael.creel at uab.es (Michael Creel)
Date: Fri, 4 Sep 2009 16:13:23 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>
	<69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
Message-ID: <c8f260e70909040713j62adeffeo74a667de95f89820@mail.gmail.com>

On Fri, Sep 4, 2009 at 2:53 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>
> Here is what I get testing your script, using optim-1.0.6 and
> development octave.
>
> ans =
>
> ? 0.131749 ? 0.999000 ? 0.055406 ? 0.970000
>
> Since the 5D Rosenbrock function has two local optima, I'm not exactly
> surprised about the 3% failures for fminunc.
> I'd rather say it's interesting that bfgsmin is always successful,
> despite the local optimum.

That's a good point. bfgsmin occasionally does a Hessian reset when it
runs into trouble, so it sometimes switches to steepest descent. Maybe
that's the reason.

>
> Another interesting thing is that I got the times reversed. Maybe you
> used a newer version of bfgsmin?

I'm using the lastest development version of bfgsmin, which hasn't had
changes recently. I don't know when optim-1.0.6 was released, but I
doubt that there is anything different - certainly there have been no
major changes. I would guess that the changes in the relative timings
are more to do with differences between Octave 3.2.3 release
candidate, and the development version. I'm impressed with the timings
for fminunc using the development version! The fact that an .m file
implementation can be so fast is very interesting.

>
> Does it do any checking against local optima?

No, just the Hessian reset when the approx Hessian is not p.d. enough.

> Also, I think bfgsmin somehow attempts to auto-discover the analytic
> gradient, doesn't it? If so, does it happen in this case?

I think that is the case here, I had forgotten about that. The
following code causes bfgsmin to use numeric gradients:

######################## new version ##################
1;
# example obj. fn.: no gradient
function obj_value = obj(x)
	obj_value = rosenbrock(x);
endfunction

dim = 5;
replications = 1000;
results = zeros(replications,4);
ub = 2;
lb = 0;
control = {100,0};

for i = 1:replications
	x = (ub-lb).*rand(dim,1) + lb;
	tic;
	[theta, obj_value, convergence] = bfgsmin("obj", {x}, control);
	results(i,1) = toc;
	results(i,2) = norm(theta - ones(dim,1)) < 1e-5;

	tic;
	[theta, obj_value] = fminunc("obj", x);
	results(i,3) = toc;
	results(i,4) = norm(theta - ones(dim,1)) < 1e-5;
endfor

mean(results)
######################## end new version ##################


With this, I get
octave:1> compare
ans =

   0.030752   1.000000   0.082802   0.970000

octave:2> compare
ans =

   0.029723   1.000000   0.081364   0.964000




>
> Interesting stuff starts to happen if I shift the optimum of the
> objective so that x_opt(1) = 100:

That is a pretty brutal thing to do to an optimization algorithm! This
problem would be detected by looking at the gradient at the start
value, and proper scaling would solve it, I believe. Poor scaling is a
user error, not a problem of the algorithm, I would say.

>
> ans =
>
> ? 0.515509 ? 0.010000 ? 0.191053 ? 0.060000
>
>
> Clearly, neither code reacts well. Hmmm. Perhaps I can improve fminunc
> a bit in this regard.

Great. But to facilitate testing and to avoid having redundant
algorithms, it would be nice to have a set of test problems to work
with. For example, this little test shows that fminunc is getting a
lot faster with the development version of Octave, and could probably
be made a little more robust with a little work. I'll have a look at
the fminunc code and see if I can make some suggestions. If it gets as
robust as bfgsmin, and is faster, then bfgsmin will probably need to
be retired. Of course, some other test problems would need to be
tried, too.

Cheers, Michael


From jwe at octave.org  Fri Sep  4 09:15:12 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 10:15:12 -0400
Subject: Contribution to the optimization toolbox
In-Reply-To: <8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>
	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>
	<69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
	<8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
Message-ID: <19105.8432.574974.379324@segfault.lan>

On  4-Sep-2009, Leonardo Martins wrote:

| 1) Regarding tests, has anyone ever considered interfacing
| Octave/Optim Toolbox with CUTEr (http://hsl.rl.ac.uk/cuter-www/) for
| more standardized testing? It can be a lot of work, but in the long
| run I guess Octave can benefit from knowing exactly where it stands if
| compared to other optimization software.

I haven't looked to see how CUTEr actually works, but I noticed that
it is distributed under a "non-commercial use only" license that is
incompatible with the GPL.  Whether this matters or not depends on
precisely how it is used.

| 2) It seemed to me that, in a first moment, rather than adding new
| algorithms to the codebase, it would be more beneficial to build a
| more "homogeneous and coordinated" toolbox, and only then make it
| "complete." Am I right?

What you decide to work on is your choice, but I would agree that
cleaning up what is already there might make the most sense as a place
to start.

| That rises another question: what criteria are
| used to determine whether a tool goes to the core/(from) toolbox?

Some of it is just history.  Long ago, everything was considered for
the core distribution.  Then came Octave Forge, then more formal
packages.  Some things have moved from Octave to packages.  Other
things have been moved to Octave.  Generally, I think it makes sense
for us to include in the core Octave distribution the things that
users expect to have with the base Matlab package, and for (at least
some of) the packages to cover what are in the corresponding Matlab
toolboxes.  It is not that we are slavishly cloning, but it seems most
useful for users who are using Octave to run code that was originally
written for Matlab.

It is important that if you choose to implement functions that are
also present in Matlab, that you NOT use any Matlab M-files as a basis
for your own implementation.  Your work must be independent and not a
derivative of any Matlab code.

If you plan to be working on Octave, then please join the maintainers
mailing list.

Also, for Octave, we try to use the term "package" instead of
"toolbox".

Thanks,

jwe

From jwe at octave.org  Fri Sep  4 10:27:41 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 11:27:41 -0400
Subject: R: Changeset: LD_PRELOAD on run-octave.in and cygwin documentation
In-Reply-To: <218277.46511.qm@web25503.mail.ukl.yahoo.com>
References: <19103.55430.498024.97808@segfault.lan>
	<218277.46511.qm@web25503.mail.ukl.yahoo.com>
Message-ID: <19105.12781.655188.358601@segfault.lan>

On  3-Sep-2009, Marco Atzeri wrote:

| --- Gio 3/9/09, John W. Eaton <jwe at octave.org> ha scritto:
| 
| > Since the run-octave script is generated, how about fixing
| > the
| > commands that generate the LD_PRELOAD line so that your
| > change is only
| > made for Cygwin systems?
| 
| no problem, I have just no clue how to do it.

I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/16907d1153d1

jwe

From jwe at octave.org  Fri Sep  4 10:31:37 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 11:31:37 -0400
Subject: Changeset: LD_PRELOAD on run-octave.in and cygwin documentation
In-Reply-To: <596208.87279.qm@web25501.mail.ukl.yahoo.com>
References: <596208.87279.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <19105.13017.373616.729311@segfault.lan>

On  3-Sep-2009, Marco Atzeri wrote:

| diff -r 5846c9c6ecd8 -r e51c07d34b2f README.Cygwin
| --- a/README.Cygwin	Thu Sep 03 12:09:39 2009 +0200
| +++ b/README.Cygwin	Thu Sep 03 15:46:38 2009 +0200
| @@ -14,19 +14,6 @@
|  	Marco Atzeri
|  	http://matzeri.altervista.org
|  
| -An obsolete version of Octave (2.1.73) is part of the normal net
| -distribution of Cygwin, available from http://www.cygwin.com.  Check
| -the package list in Cygwin's setup.exe installer if you would like to
| -try using it.  However, 2.1.73 is unsupported and we STRONGLY
| -recommended that you use a more recent version of Octave.
| -
| -It should be possible to build Octave on Windows systems with Cygwin,
| -but at the time of this writing, there are some performance problems
| -related to the way C++ exception handling is implemented with the
| -default Cygwin compiler.  This is a known problem with a long history.
| -If you would like to see this problem corrected, please search the
| -Cygwin mailing lists for threads related to "sjlj exception handling"
| -(or similar).
|  
|  There is also an "unofficial" Octave distribution for Cygwin:

I checked in this part of your patch.

Thanks,

jwe

From jwe at octave.org  Fri Sep  4 10:35:37 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 11:35:37 -0400
Subject: Changeset : SPARSE_LIBS order in Makeconf.in 
In-Reply-To: <737763.88993.qm@web25501.mail.ukl.yahoo.com>
References: <737763.88993.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <19105.13257.331620.619686@segfault.lan>

On  3-Sep-2009, Marco Atzeri wrote:

| Hi,
| attached change to meet the expected order of 
| 
|   SPARSE_LIBS = \
| -  $(AMD_LIBS) $(CAMD_LIBS) $(COLAMD_LIBS) \
| -    $(CCOLAMD_LIBS) $(CHOLMOD_LIBS) $(CXSPARSE_LIBS) \
| -    $(UMFPACK_LIBS)
| +    $(CHOLMOD_LIBS) $(UMFPACK_LIBS) \
| +    $(AMD_LIBS) $(CAMD_LIBS) $(COLAMD_LIBS) \
| +    $(CCOLAMD_LIBS) $(CXSPARSE_LIBS)
| 
| at least on cygwin the order is important.

I checked in this change.

Thanks,

jwe

From godfrey at isl.stanford.edu  Fri Sep  4 12:00:48 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Fri, 04 Sep 2009 10:00:48 -0700
Subject: Contribution to the optimization toolbox
In-Reply-To: <8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>	<69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>	<69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
	<8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
Message-ID: <4AA147C0.2040807@isl.stanford.edu>

On 09/04/2009 06:27 AM, Leonardo Martins wrote:
> First of all, thank you guys for promptly responding. Secondly, I have
> two brief observations following your replies.
>
>    
>>> >>  With regard to optimization using Octave, there is a certain overlap
>>> >>  between Octave core and the optim toolbox. Likewise, algorithms appear
>>> >>  in both, but there is little standardized testing to make sure that
>>> >>  methods work well, or to figure out which of a set of algorithms works
>>> >>  best for a given type or problem.
>>>        
>> >  Choice of algorithms is always an art. So far fminunc got very little
>> >  testing, but I hope to put some into it as soon as I get the chance.
>>      
> 1) Regarding tests, has anyone ever considered interfacing
> Octave/Optim Toolbox with CUTEr (http://hsl.rl.ac.uk/cuter-www/) for
> more standardized testing? It can be a lot of work, but in the long
> run I guess Octave can benefit from knowing exactly where it stands if
> compared to other optimization software.
>
>    
I looked at this briefly.  It could be of some use, but it appears
not to have been updated since 2002.  Quite a lot has happened
since then.
>>>> >>>  The optim toolbox is a collection of tools by different authors,
>>>> >>>  without any planning or coordination. It's open to anyone who has
>>>> >>>  contributions to make. If someone has enough interest and energy to
>>>> >>>  try to make it a little more homogeneous, coordinated and complete,
>>>> >>>  that would be great.
>>>>          
> 2) It seemed to me that, in a first moment, rather than adding new
> algorithms to the codebase, it would be more beneficial to build a
> more "homogeneous and coordinated" toolbox, and only then make it
> "complete." Am I right? That rises another question: what criteria are
> used to determine whether a tool goes to the core/(from) toolbox? Is
> there any workflow based on reliability, compatibility, or any other
> criteria? Does it make more sense to work on the toolbox or the core?
>
>    
This seems to me a very good idea.  I noticed from the Table of
Contents of the Current Manual that there is no separate Section
for Convex Optimization.  This has become increasingly important.
In any case, a key part of your providing more "organization" should
be improvements to the documentation.  (It is not a bad idea to
write the documentation before the code.)  If you want an excellent
introduction to convex optimization (in case you have not already
read it), try:
http://www.stanford.edu/~boyd/cvxbook/

It also happens that Stephen Boyd is supportive of Octave, and,
incidentally, he convinced Cambridge Press to permit his book
(and lecture notes, etc.) to be freely downloadable from the site
above.
> I hope I'm not annoying you with so many questions. I just want to
> make sure how I can be more useful to the project.
>    
No problem!
> Thanks,
>
>    -- L.M.
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090904/e352e1c0/attachment.html 

From soren at hauberg.org  Fri Sep  4 08:58:03 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Fri, 04 Sep 2009 06:58:03 -0700
Subject: Contribution to the optimization toolbox
In-Reply-To: <8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>
	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>
	<69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
	<8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
Message-ID: <1252072683.28183.16.camel@sh-t400>

fre, 04 09 2009 kl. 10:27 -0300, skrev Leonardo Martins:
> 1) Regarding tests, has anyone ever considered interfacing
> Octave/Optim Toolbox with CUTEr (http://hsl.rl.ac.uk/cuter-www/) for
> more standardized testing? It can be a lot of work, but in the long
> run I guess Octave can benefit from knowing exactly where it stands if
> compared to other optimization software.

It seems like CUTEr is non-free software (it does not allow for
commercial use), so I don't think we're allowed to interface with it.
Perhaps the Matlab interface can be used directly (Octave does support
MEX) ?

> That rises another question: what criteria are
> used to determine whether a tool goes to the core/(from) toolbox? Is
> there any workflow based on reliability, compatibility, or any other
> criteria?

I don't think any clear-cut criteria exists, but in general, things
should go into Octave core if

  1) they are in Matlab core, or
  2) they are of very general use.

In terms of optimisation, I would _guess_ that things should go into
Octave core if they are in Matlab core (for compatibility), and
otherwise in the 'optimization' package.

S?ren


From jwe at octave.org  Fri Sep  4 16:59:43 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 17:59:43 -0400
Subject: A backend("fltk") problem
In-Reply-To: <4AA08BAB.7070305@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.49796.832539.546198@segfault.lan>
	<4AA08BAB.7070305@isl.stanford.edu>
Message-ID: <19105.36303.848768.366731@segfault.lan>

On  3-Sep-2009, Michael D Godfrey wrote:

| John, I just confirmed on my Fedora 11 x86_64 system, and
| using the version of Octave with your emailed patch and the
| error: removed, I get:
| 
| 1. If the /usr/share/fonts/truetype/freefont/...   is removed
|      the system seg faults with:
| octave:2> title("hello")
| octave:3> error: ft_manager: unable to load font: 
| /usr/share/fonts/truetype/freefont/FreeSans.ttf
| error: ft_render: unable to load appropriate font
| error: ft_render: font not initialized
| error: octave_base_value::convert_to_str_internal (): wrong type 
| argument `<unknown type>'
| error: octave_base_value::convert_to_str_internal (): wrong type 
| argument `<unknown type>'
| panic: Segmentation fault -- stopping myself...
| attempting to save variables to `octave-core'...
| save to `octave-core' complete
| Segmentation fault

I checked in the following change which I think will avoid this
problem:

  http://hg.savannah.gnu.org/hgweb/octave/rev/2093499ec9f4

Thanks,

jwe

From jwe at octave.org  Fri Sep  4 17:03:02 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 4 Sep 2009 18:03:02 -0400
Subject: development snapshot
In-Reply-To: <19103.59481.557945.168889@segfault.lan>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
Message-ID: <19105.36502.204082.979320@segfault.lan>

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

| OK.  I'll try to make one later today or tomorrow.

I forgot that we still have a patent issue to deal with, and I'd like
to do that before making a snapshot.  I have an appointment to talk
with someone from the Software Freedom Law Center next Friday
afternoon, so the snapshot will have to wait until after that.

jwe

From marco_atzeri at yahoo.it  Sat Sep  5 04:56:49 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Sat, 5 Sep 2009 09:56:49 +0000 (GMT)
Subject: R: 3.2.3 RC2
In-Reply-To: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>
Message-ID: <137204.18131.qm@web25508.mail.ukl.yahoo.com>

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

> Da: Jaroslav Hajek <highegg at gmail.com>
> Oggetto: 3.2.3 RC2
> A: "octave maintainers list" <maintainers at octave.org>
> Data: Marted? 1 settembre 2009, 10:16
> hi all,
> 
> the 3.2.3 RC2 tarballs are available:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 

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


fine for cygwin

  PASS   5756
  FAIL      9 (usual failures on complex NaN sort )

Marco




      


From godfrey at isl.stanford.edu  Sat Sep  5 20:55:46 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 05 Sep 2009 18:55:46 -0700
Subject: fltk
In-Reply-To: <19107.2676.390066.31797@segfault.lan>
References: <4AA2EC30.5060009@isl.stanford.edu>	<19106.60818.604699.94352@segfault.lan>	<4AA2F032.9070303@isl.stanford.edu>
	<19107.2676.390066.31797@segfault.lan>
Message-ID: <4AA316A2.9030309@isl.stanford.edu>

John,

I just established what you must have already known.
Fedora systems need some other way of locating fonts.

I put the: file = "/usr/share/fonts/truetype/freefont/FreeSans.ttf";

back in and now I get correct plots, with warnings like:
octave:3> plot([1:100])
octave:4> warning: could not match any font: *-normal-normal-12
plot([100:title("hello")
octave:5> warning: could not match any font: *-normal-normal-12
warning: could not match any font: *-normal-normal-12
warning: could not match any font: *-normal-normal-12
warning: could not match any font: *-normal-normal-12
=========================================
but, the plots are correct including title, etc.

Do you know a font wizard?  I will try to study this more, but
any help would be nice.  It must be that the search that is being
used does not include the standard ISO fonts, like:
38:xorg-x11-fonts-ISO8859-1-75dpi-7.2-8.fc11.noarch
122:xorg-x11-fonts-ISO8859-2-100dpi-7.2-8.fc11.noarch
426:xorg-x11-fonts-ISO8859-9-100dpi-7.2-8.fc11.noarch
432:xorg-x11-fonts-ISO8859-2-75dpi-7.2-8.fc11.noarch
644:xorg-x11-fonts-ISO8859-14-100dpi-7.2-8.fc11.noarch
844:xorg-x11-fonts-ISO8859-15-100dpi-7.2-8.fc11.noarch
1007:xorg-x11-fonts-ISO8859-1-100dpi-7.2-8.fc11.noarch
1035:xorg-x11-fonts-ISO8859-9-75dpi-7.2-8.fc11.noarch
1408:xorg-x11-fonts-ISO8859-14-75dpi-7.2-8.fc11.noarch
1500:xorg-x11-fonts-ISO8859-15-75dpi-7.2-8.fc11.noarch
==============================================
which are in most Fedora systems and many others.  Of course,
this could be a fontconfig problens, too.  But, definitely have
fontconfig installed.  And, other applications that need fonts
seem to find them.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090905/6d98e66b/attachment.html 

From jwe at octave.org  Sat Sep  5 23:21:25 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 6 Sep 2009 00:21:25 -0400
Subject: fltk
In-Reply-To: <4AA316A2.9030309@isl.stanford.edu>
References: <4AA2EC30.5060009@isl.stanford.edu>
	<19106.60818.604699.94352@segfault.lan>
	<4AA2F032.9070303@isl.stanford.edu>
	<19107.2676.390066.31797@segfault.lan>
	<4AA316A2.9030309@isl.stanford.edu>
Message-ID: <19107.14533.260072.870074@segfault.lan>

On  5-Sep-2009, Michael D Godfrey wrote:

| I just established what you must have already known.
| Fedora systems need some other way of locating fonts.
| 
| I put the: file = "/usr/share/fonts/truetype/freefont/FreeSans.ttf";
| 
| back in and now I get correct plots,

It works on my system without using a fallback font file as seems to
be required on your system, so somehow fontconfig is returning a
default font and I don't have to do it.

What do the following return on your system?

  get (0, "defaultaxesfontname")
  get (0, "defaulttextfontname")

| with warnings like:
| octave:3> plot([1:100])
| octave:4> warning: could not match any font: *-normal-normal-12
| plot([100:title("hello")
| octave:5> warning: could not match any font: *-normal-normal-12
| warning: could not match any font: *-normal-normal-12
| warning: could not match any font: *-normal-normal-12
| warning: could not match any font: *-normal-normal-12

Yes, those warnings come before using the default font file.  Maybe to
limit the warning spew, we could keep a list of the missing fonts and
only issue the missing font warning once per font.  But of course we
should try to make it so that this is an exceptional thing.  Octave
should normally find the default font and not need the fallback font
file.

| Do you know a font wizard?

No, maybe someone on the list knows more and could help?

jwe

From godfrey at isl.stanford.edu  Sun Sep  6 00:29:28 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 05 Sep 2009 22:29:28 -0700
Subject: fltk and fonts
Message-ID: <4AA348B8.90802@isl.stanford.edu>

>
> What do the following return on your system?
>
>    get (0, "defaultaxesfontname")
>    get (0, "defaulttextfontname")
>
>    
octave:1> get (0, "defaultaxesfontname")
ans = *
octave:2> get (0, "defaulttextfontname")
ans = *
==================================
What do you get for these?

> That link leads to an empty page for me.
>
>    
Odd. I just clicked on the link in your email and the expected page came
up.  Maybe try a Google search on:
Shipping fonts in Fedora (FAQ)
which is the title of the page.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090905/482f10e7/attachment.html 

From highegg at gmail.com  Sun Sep  6 02:55:02 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 6 Sep 2009 09:55:02 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909040713j62adeffeo74a667de95f89820@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>
	<69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
	<c8f260e70909040713j62adeffeo74a667de95f89820@mail.gmail.com>
Message-ID: <69d8d540909060055l10c7e37al4631835f2386eb08@mail.gmail.com>

On Fri, Sep 4, 2009 at 4:13 PM, Michael Creel<michael.creel at uab.es> wrote:
> On Fri, Sep 4, 2009 at 2:53 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>
>> Here is what I get testing your script, using optim-1.0.6 and
>> development octave.
>>
>> ans =
>>
>> ? 0.131749 ? 0.999000 ? 0.055406 ? 0.970000
>>
>> Since the 5D Rosenbrock function has two local optima, I'm not exactly
>> surprised about the 3% failures for fminunc.
>> I'd rather say it's interesting that bfgsmin is always successful,
>> despite the local optimum.
>
> That's a good point. bfgsmin occasionally does a Hessian reset when it
> runs into trouble, so it sometimes switches to steepest descent. Maybe
> that's the reason.
>

Partially. I discovered the reason why fminunc was so much worse: it
was the factor = 100 setting in fminunc. This was taken from fsolve
and the original MINPACK and means that the starting trust region is
100 times the size of norm(x). While this may be OK for fzero, which
starts with a fresh correct Jacobian, it seems to make little sense
fro fminunc, which starts with a Hessian approximation equal to
identity matrix (and is often quite wrong), so essentially the
function starts from a 100x bigger random guess. I changed the default
values to factor = 1 for fsolve and even more conservative factor =
0.1 for fminunc. With this new setting, I get from your script:

ans =

   0.221018   1.000000   0.077295   1.000000

I also tried dim = 10:
ans =

   0.52277   1.00000   0.21817   1.00000

and dim = 50 (this is lengthy):
ans =

   5.63046   0.47000   3.84247   0.45000

with optimset ("GradObj", "on"), I get for dim = 5:
ans =

   0.221018   0.990000   0.036970   1.000000

and with dim = 10:
ans =

   0.538099   0.990000   0.067742   1.000000

so a lot of time is taken by the finite differences. I'm not sure
bfgsmin uses the analytic gradient at all, though; is there any way to
enforce it?

>>
>> Another interesting thing is that I got the times reversed. Maybe you
>> used a newer version of bfgsmin?
>
> I'm using the lastest development version of bfgsmin, which hasn't had
> changes recently. I don't know when optim-1.0.6 was released, but I
> doubt that there is anything different - certainly there have been no
> major changes. I would guess that the changes in the relative timings
> are more to do with differences between Octave 3.2.3 release
> candidate, and the development version. I'm impressed with the timings
> for fminunc using the development version! The fact that an .m file
> implementation can be so fast is very interesting.
>

Maybe there are also changes to fminunc that didn't yet get to 3.2.x.
I'll check. I'm working with optim-1.0.6; I tried the SVN version but
I can't get it to work: it seems the revision 5818
http://octave.svn.sourceforge.net/viewvc/octave?view=rev&revision=5818
broke things for me; I tried to fix it (including a screwed-up commit
where my debug lines got in), but I wasn't successful yet. I think
this is the only change since 1.0.6.

> Great. But to facilitate testing and to avoid having redundant
> algorithms, it would be nice to have a set of test problems to work
> with. For example, this little test shows that fminunc is getting a
> lot faster with the development version of Octave, and could probably
> be made a little more robust with a little work. I'll have a look at
> the fminunc code and see if I can make some suggestions. If it gets as
> robust as bfgsmin, and is faster, then bfgsmin will probably need to
> be retired.

Well I'm not sure about that. The point is that bfgsmin also contains
the LBFGS update. fminunc uses a factorized direct BFGS update (i.e.
updating the Cholesky factor of the hessian, via cholupdate), so one
step of it is O(N^2) and the memory is also O(N^2). This is equal to
the direct updating of inverse employed by bfgsmin; a possible
advantage to fminunc is that all the hidden intelligence of Octave's
matrix division is employed, including check for ill-conditioning.
However, for large systems, LBFGS is bound to win; it's asymptotically
superior.
The optimization arsenal provided by Octave & OctaveForge does not
need to be orthogonal, just broad enough.

On the whole, I'm now convinced that optimization algorithms are well
suited to be implemented as m-files. Very often in real applications,
the overhead of the algorithm itself is actually negligible, so one
doesn't need to worry too much about performance. And m-files have the
advantage that more people are able to play around with them, tweak
and improve them, and share the improvements.
Another advantage of m-files is their genericity; for instance,
fminunc will compute in single precision if given single precision
inputs. That may not be a big advantage, as single precision
optimization is rare, but the general mechanism is the point. For
instance, it took just a few small changes to make fsolve able to
solve complex (holomorphic) nonlinear systems, using complex Newton
method.
On the other hand, it's essential to have good building blocks for the
m-files. The choice between high-level code and building block,
between m-file and .oct file, is an art.

regards

-- 
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  Sun Sep  6 12:35:19 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 06 Sep 2009 10:35:19 -0700
Subject: fltk
In-Reply-To: <19107.14533.260072.870074@segfault.lan>
References: <4AA2EC30.5060009@isl.stanford.edu>	<19106.60818.604699.94352@segfault.lan>	<4AA2F032.9070303@isl.stanford.edu>	<19107.2676.390066.31797@segfault.lan>	<4AA316A2.9030309@isl.stanford.edu>
	<19107.14533.260072.870074@segfault.lan>
Message-ID: <4AA3F2D7.9070201@isl.stanford.edu>

On 09/05/2009 09:21 PM, John W. Eaton wrote:
> What do the following return on your system?
>
>    get (0, "defaultaxesfontname")
>    get (0, "defaulttextfontname")
>    
In Matlab, on the same machine I get:

 >> get (0, 'defaulttextfontname')

ans =

Helvetica

 >> get (0, 'defaulttaxtfontname')
??? Error using ==> get
Can't resolve object type in default property 'taxtfontname'

 >>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090906/7a73af23/attachment.html 

From godfrey at isl.stanford.edu  Sun Sep  6 13:04:44 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 06 Sep 2009 11:04:44 -0700
Subject: fltk
In-Reply-To: <19107.14787.360427.249871@segfault.lan>
References: <4AA2EC30.5060009@isl.stanford.edu>	<19106.60818.604699.94352@segfault.lan>	<4AA2F032.9070303@isl.stanford.edu>	<19107.2676.390066.31797@segfault.lan>	<4AA31B55.9070304@isl.stanford.edu>
	<19107.14787.360427.249871@segfault.lan>
Message-ID: <4AA3F9BC.7010709@isl.stanford.edu>

John,

Without the backend("fltk") I tried commands like:

  plot([1:100])
title("hello again")
get(gca,"fontname")
h = get (gca (),"title")
get (0, "defaulttextfontname")
set(h, "string", "more news")
set(h, "fontname", "Helvetica")
get (0, "defaulttextfontname")

They all worked as expected.  So, at least part of the
problem is due to differences in font property handling
between fltk and gnuplot.  It would seem to me that the
property handling should be the same (even same code)
for both.  Is this true?

Also, commands like set(h, "fontsize", 10) work correctly
in both gnuplot and fltk.  It seems to be only the fontname
property that goes wrong in fltk.

Michael


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090906/8b6820de/attachment.html 

From highegg at gmail.com  Mon Sep  7 01:34:36 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 7 Sep 2009 08:34:36 +0200
Subject: development snapshot
In-Reply-To: <19105.36502.204082.979320@segfault.lan>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
Message-ID: <69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>

On Sat, Sep 5, 2009 at 12:03 AM, John W. Eaton<jwe at octave.org> wrote:
> On ?3-Sep-2009, John W. Eaton wrote:
>
> | OK. ?I'll try to make one later today or tomorrow.
>
> I forgot that we still have a patent issue to deal with, and I'd like
> to do that before making a snapshot. ?I have an appointment to talk
> with someone from the Software Freedom Law Center next Friday
> afternoon, so the snapshot will have to wait until after that.
>

Here's an overview and couple more thoughts of mine about that matter
that you might find interesting. For most of those there was an
agreement in the discussion or at least nobody contested them:

1. The current implementation obviously infringes the patent.
Moreover, the patent claims are so broad that they cover virtually any
reasonable implementation.
2. In fact, the fundamental claim appears to be a logical consequence
of the mere *idea* of having overloaded handles.
3. Even the previous implementation of function handles
(non-overloaded) might possibly be infringing; provided that
"selection" is allowed to always select the same result.
4. The symbol_table::fcn_info internal class may also be infringing;
however, there is no obvious "first point in the program" where they
should be created.
5. Even prior to the current implementation, it was trivial to
constitute an infringement in the Octave language language itself:
merely creating `@(x) overloaded_function_name (x)" is obviously
covered by the patent's fundamental claim (satisfies all parts).
6. In that sense, Matlab itself may be seen as a prior art example to
the patented "invention", given that it was trivial to construct the
"invention" using the Matlab language ever since Matlab had function
overloading (some version 5.x or so?), which was probably before the
patent was filed. I don't think Octave had had function overloading
that soon, though.

-- 
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 02:31:42 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 7 Sep 2009 09:31:42 +0200
Subject: 3.2.3 RC3
Message-ID: <69d8d540909070031k7c316f59ma6f4aa11af36559@mail.gmail.com>

hi all,


the 3.2.3 RC3 tarballs are available at
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

changes since RC2:

changeset:   9425:f3961908395a
user:        David Bateman <dbateman at free.fr>
date:        Thu Sep 03 11:43:58 2009 +0200
summary:     Fix nesting error in options parsing of eigs

changeset:   9426:ed72d5ee3973
user:        David Bateman <dbateman at free.fr>
date:        Thu Sep 03 11:44:07 2009 +0200
summary:     Minor typo in new eigs.cc test

changeset:   9427:c40b4257caae
user:        John W. Eaton <jwe at octave.org>
date:        Fri Sep 04 06:59:44 2009 +0200
summary:     pr-output.cc (set_format (const Complex&, int&, int&)):
avoid passing NaN or Inf to log10

changeset:   9428:796c26e4af47
user:        John W. Eaton <jwe at octave.org>
date:        Mon Sep 07 08:01:41 2009 +0200
summary:     correctly toggle hold state

changeset:   9429:aef5dd9b5591
tag:         qparent
tag:         3-2-3-rc3
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Mon Sep 07 08:38:09 2009 +0200
summary:     fix minor typo

I think there is still the pertaining issue with mouse zooming in
Windows; but if there was a fix proposed, I missed it.

regards

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

From tmacchant at yahoo.co.jp  Mon Sep  7 03:04:47 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 7 Sep 2009 17:04:47 +0900 (JST)
Subject: changeset 9395 (3.2.=?ISO-2022-JP?B?GyRCI3gbKEI=?= branch) should be
	applied not only x11 term but on windows, wxt, ( and aqua) term
Message-ID: <20090907080447.76483.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello

The changeset 9395 (3.2.? branch) makes mouse zoom in 2d in windows and wxt terminals impossible.

It should be applied to all view terminals (x11, winodws, wxt and perhaps aqua).
At present I do not concern "qt" term.

Hello Ben Abbott  
Please confirm  the changeset below is also applicable to the "aqua" term 

****
Hello Jaroslav and John

If Ben will give affirmative reply, please the attach the changeset to 3.2.x and development branch.

Regards

Tatsuro

**************************
# Date 1252309506 -32400
# Node ID a9ad624197bab8f8b105fff36e8afae379b29474
# Parent  796c26e4af4709c9b35d454ea634573f13cabfaf
 changeset 9395 should be applied not only x11 term
 --
 user: Tatsuro Matsuoka
 branch 'default'
changed scripts/plot/gnuplot_drawnow.m

diff -r 796c26e4af47 -r a9ad624197ba scripts/plot/gnuplot_drawnow.m
--- a/scripts/plot/gnuplot_drawnow.m    Mon Sep 07 08:01:41 2009 +0200
+++ b/scripts/plot/gnuplot_drawnow.m    Mon Sep 07 16:45:06 2009 +0900
@@ -286,10 +286,10 @@
       ## the canvas size for terminals cdr/corel.
       term_str = sprintf ("%s %s", term_str, size_str);
     endif
-    ## Work around the gnuplot feature of growing the x11 window when
-    ## the mouse and multiplot are set.
+    ## Work around the gnuplot feature of growing the window (x11, windows, aqua, wxt)
+    ## when the mouse and multiplot are set.
     fputs (plot_stream, "unset multiplot;\n");
-    if (! strcmp (term, "x11")
+    if (! index("x11 windows aqua wxt", term)
         || numel (findall (h, "type", "axes")) > 1
         || numel (findall (h, "type", "image")) > 0)
       fprintf (plot_stream, "%s\n", term_str);
@@ -299,7 +299,7 @@
         endif
       endif
       fputs (plot_stream, "set multiplot;\n");
-    elseif (strcmp (term, "x11"))
+    elseif (index("x11 windows aqua wxt", term))
       fprintf (plot_stream, "%s\n", term_str);
       if (nargin == 5)
         if (! isempty (file))


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

From michael.creel at uab.es  Mon Sep  7 03:37:11 2009
From: michael.creel at uab.es (Michael Creel)
Date: Mon, 7 Sep 2009 10:37:11 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <1252072683.28183.16.camel@sh-t400>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
	<1252072683.28183.16.camel@sh-t400>
Message-ID: <c8f260e70909070137h67ee15f8v8202025f509fccd3@mail.gmail.com>

On Fri, Sep 4, 2009 at 3:58 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> fre, 04 09 2009 kl. 10:27 -0300, skrev Leonardo Martins:
>> 1) Regarding tests, has anyone ever considered interfacing
>> Octave/Optim Toolbox with CUTEr (http://hsl.rl.ac.uk/cuter-www/) for
>> more standardized testing? It can be a lot of work, but in the long
>> run I guess Octave can benefit from knowing exactly where it stands if
>> compared to other optimization software.
>
> It seems like CUTEr is non-free software (it does not allow for
> commercial use), so I don't think we're allowed to interface with it.
> Perhaps the Matlab interface can be used directly (Octave does support
> MEX) ?
>
>> That rises another question: what criteria are
>> used to determine whether a tool goes to the core/(from) toolbox? Is
>> there any workflow based on reliability, compatibility, or any other
>> criteria?
>
> I don't think any clear-cut criteria exists, but in general, things
> should go into Octave core if
>
> ?1) they are in Matlab core, or
> ?2) they are of very general use.
>
> In terms of optimisation, I would _guess_ that things should go into
> Octave core if they are in Matlab core (for compatibility), and
> otherwise in the 'optimization' package.
>
> S?ren
>
>

I have done a little searching, and there are a number of sources for
test functions for optimization, some of which provide Octave/Matlab
code.


From michael.creel at uab.es  Mon Sep  7 03:41:02 2009
From: michael.creel at uab.es (Michael Creel)
Date: Mon, 7 Sep 2009 10:41:02 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909070137h67ee15f8v8202025f509fccd3@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
	<1252072683.28183.16.camel@sh-t400>
	<c8f260e70909070137h67ee15f8v8202025f509fccd3@mail.gmail.com>
Message-ID: <c8f260e70909070141w501c9776wfe4a6ac74e36f88@mail.gmail.com>

On Mon, Sep 7, 2009 at 10:37 AM, Michael Creel <michael.creel at uab.es> wrote:
> On Fri, Sep 4, 2009 at 3:58 PM, S?ren Hauberg <soren at hauberg.org> wrote:
>> fre, 04 09 2009 kl. 10:27 -0300, skrev Leonardo Martins:
>>> 1) Regarding tests, has anyone ever considered interfacing
>>> Octave/Optim Toolbox with CUTEr (http://hsl.rl.ac.uk/cuter-www/) for
>>> more standardized testing? It can be a lot of work, but in the long
>>> run I guess Octave can benefit from knowing exactly where it stands if
>>> compared to other optimization software.
>>
>> It seems like CUTEr is non-free software (it does not allow for
>> commercial use), so I don't think we're allowed to interface with it.
>> Perhaps the Matlab interface can be used directly (Octave does support
>> MEX) ?
>>
>>> That rises another question: what criteria are
>>> used to determine whether a tool goes to the core/(from) toolbox? Is
>>> there any workflow based on reliability, compatibility, or any other
>>> criteria?
>>
>> I don't think any clear-cut criteria exists, but in general, things
>> should go into Octave core if
>>
>> ?1) they are in Matlab core, or
>> ?2) they are of very general use.
>>
>> In terms of optimisation, I would _guess_ that things should go into
>> Octave core if they are in Matlab core (for compatibility), and
>> otherwise in the 'optimization' package.
>>
>> S?ren
>>
>>
>
> I have done a little searching, and there are a number of sources for
> test functions for optimization, some of which provide Octave/Matlab
> code.
>

Whoops, I sent that before I meant to. I meant to add that a lot of
the provided code appears to be unlicensed or public domain. I would
guess from the context I found it in that the authors would probably
allow it to be used. but the authors would need to be contacted, of
course. Examples are:
http://www-optima.amp.i.kyoto-u.ac.jp/member/student/hedar/Hedar_files/TestGO_files/Page364.htm
http://www.mat.univie.ac.at/~neum/glopt/test.html

Michael


From michael.creel at uab.es  Mon Sep  7 03:57:27 2009
From: michael.creel at uab.es (Michael Creel)
Date: Mon, 7 Sep 2009 10:57:27 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909060055l10c7e37al4631835f2386eb08@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909040713j62adeffeo74a667de95f89820@mail.gmail.com>
	<69d8d540909060055l10c7e37al4631835f2386eb08@mail.gmail.com>
Message-ID: <c8f260e70909070157y50ac7aa8udbd671d5f877224a@mail.gmail.com>

On Sun, Sep 6, 2009 at 9:55 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>
> Partially. I discovered the reason why fminunc was so much worse: it
> was the factor = 100 setting in fminunc. This was taken from fsolve
> and the original MINPACK and means that the starting trust region is
> 100 times the size of norm(x). While this may be OK for fzero, which
> starts with a fresh correct Jacobian, it seems to make little sense
> fro fminunc, which starts with a Hessian approximation equal to
> identity matrix (and is often quite wrong), so essentially the
> function starts from a 100x bigger random guess. I changed the default
> values to factor = 1 for fsolve and even more conservative factor =
> 0.1 for fminunc. With this new setting, I get from your script:
>
> ans =
>
> ? 0.221018 ? 1.000000 ? 0.077295 ? 1.000000
>
> I also tried dim = 10:
> ans =
>
> ? 0.52277 ? 1.00000 ? 0.21817 ? 1.00000
>

Great! By the way, the version of fminunc in the 3.2.2 release
candidate has a typo down in the part at the end for guarded
evaluation. There is a jx/gx confusion which is obvious. I'm trying to
compile a checkout of the development version to see if I can
replicate your results, but it crashes with
In file included from ./txt-eng-ft.h:28,
                 from ./gl-render.h:43,
                 from ./DLD-FUNCTIONS/fltk_backend.cc:60:
/usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
such file or directory
In file included from ./gl-render.h:43,
                 from ./DLD-FUNCTIONS/fltk_backend.cc:60:
./txt-eng-ft.h:29:10: error: #include expects "FILENAME" or <FILENAME>
In file included from ./gl-render.h:43,
                 from ./DLD-FUNCTIONS/fltk_backend.cc:60:
./txt-eng-ft.h:76: error: ?FT_Face? does not name a type
g++ -c                    -fPIC -I. -I.. -I../liboctave -I../src
-I../libcruft/misc -DHAVE_CONFIG_H -O3 -march=native -funroll-loops
-Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 -pthread
./DLD-FUNCTIONS/gammainc.cc -o pic/gammainc.o
make[2]: *** [pic/fltk_backend.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/michael/Desktop/octave/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/home/michael/Desktop/octave'
make: *** [all] Error 2
michael at yosemite:~/Desktop/octave$


I have fltk, ftgl libraries installed. Can I disable the fltk stuff in
configuration?


>
> so a lot of time is taken by the finite differences. I'm not sure
> bfgsmin uses the analytic gradient at all, though; is there any way to
> enforce it?

This version shows how to use analytic/numeric with bfgsmin (set reps
to 1 and set control={100,3} for full verbosity)


##################### cut here ##################333
1;
# in the calls to the minimization functions, use "objective" if you
want analytic gradient, otherwise, use "objective2"

# example obj. fn.: with gradient
function [obj_value, gradient] = objective(x)
	[obj_value, gradient] = rosenbrock(x);
endfunction

# example obj. fn.: no gradient
function obj_value = objective2(x)
	obj_value = rosenbrock(x);
endfunction


dim = 5;
replications = 100;
results = zeros(replications,4);
ub = 2;
lb = 0;
control = {100,0};  # set the second number to 1,2,3 for increasing
levels of bfgsmin verbosity

for i = 1:replications
	x = (ub-lb).*rand(dim,1) + lb;
	tic;
	[theta, obj_value, convergence] = bfgsmin("objective2", {x}, control);
	results(i,1) = toc;
	results(i,2) = norm(theta - ones(dim,1)) < 1e-5;

	tic;
	[theta, obj_value] = fminunc("objective2", x);
	results(i,3) = toc;
	results(i,4) = norm(theta - ones(dim,1)) < 1e-5;
endfor

mean(results)
##################### cut here ##################333



> Maybe there are also changes to fminunc that didn't yet get to 3.2.x.
> I'll check. I'm working with optim-1.0.6; I tried the SVN version but
> I can't get it to work: it seems the revision 5818
> http://octave.svn.sourceforge.net/viewvc/octave?view=rev&revision=5818
> broke things for me; I tried to fix it (including a screwed-up commit
> where my debug lines got in), but I wasn't successful yet. I think
> this is the only change since 1.0.6.


I hadn't tried out the OF version of __bfgsmin.cc since those changes
were made. It didn't work for me, either. I checked in a working
version this morning. Thanks for the heads up.

>
>> Great. But to facilitate testing and to avoid having redundant
>> algorithms, it would be nice to have a set of test problems to work
>> with. For example, this little test shows that fminunc is getting a
>> lot faster with the development version of Octave, and could probably
>> be made a little more robust with a little work. I'll have a look at
>> the fminunc code and see if I can make some suggestions. If it gets as
>> robust as bfgsmin, and is faster, then bfgsmin will probably need to
>> be retired.
>
> Well I'm not sure about that. The point is that bfgsmin also contains
> the LBFGS update. fminunc uses a factorized direct BFGS update (i.e.
> updating the Cholesky factor of the hessian, via cholupdate), so one
> step of it is O(N^2) and the memory is also O(N^2). This is equal to
> the direct updating of inverse employed by bfgsmin; a possible
> advantage to fminunc is that all the hidden intelligence of Octave's
> matrix division is employed, including check for ill-conditioning.
> However, for large systems, LBFGS is bound to win; it's asymptotically
> superior.

Right, I forgot about lbfgs, I don't use it that often.

> The optimization arsenal provided by Octave & OctaveForge does not
> need to be orthogonal, just broad enough.
>
> On the whole, I'm now convinced that optimization algorithms are well
> suited to be implemented as m-files. Very often in real applications,
> the overhead of the algorithm itself is actually negligible, so one
> doesn't need to worry too much about performance. And m-files have the
> advantage that more people are able to play around with them, tweak
> and improve them, and share the improvements.
> Another advantage of m-files is their genericity; for instance,
> fminunc will compute in single precision if given single precision
> inputs. That may not be a big advantage, as single precision
> optimization is rare, but the general mechanism is the point. For
> instance, it took just a few small changes to make fsolve able to
> solve complex (holomorphic) nonlinear systems, using complex Newton
> method.
> On the other hand, it's essential to have good building blocks for the
> m-files. The choice between high-level code and building block,
> between m-file and .oct file, is an art.

I think that you're right, given that the .m file implementations are
getting faster. I will probably try to write lbfgs as an .m file at
some point. If that works out and it is more or less as fast as the
.oct version, then I think there is no reason to maintain the .oct
version. I am going to experiment with the development version of
Octave and see how things go.

Cheers, Michael

>
> regards
>
> --
> 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  7 08:28:05 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 7 Sep 2009 09:28:05 -0400
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909070157y50ac7aa8udbd671d5f877224a@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909040713j62adeffeo74a667de95f89820@mail.gmail.com>
	<69d8d540909060055l10c7e37al4631835f2386eb08@mail.gmail.com>
	<c8f260e70909070157y50ac7aa8udbd671d5f877224a@mail.gmail.com>
Message-ID: <19109.2662.742.855467@segfault.lan>

On  7-Sep-2009, Michael Creel wrote:

| I'm trying to
| compile a checkout of the development version to see if I can
| replicate your results, but it crashes with
| In file included from ./txt-eng-ft.h:28,
|                  from ./gl-render.h:43,
|                  from ./DLD-FUNCTIONS/fltk_backend.cc:60:
| /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
| such file or directory

I'd say fix this problem first.  Why is freetype/config/ftheader.h
missing?  Note that Octave is not including this file directly, it is
included from /usr/include/ft2build.h, so I think there is some
problem with your installation of FreeType.  Look at the
/usr/include/ft2build.h file to see if there are some clues there.

jwe

From michael.creel at uab.es  Mon Sep  7 10:36:43 2009
From: michael.creel at uab.es (Michael Creel)
Date: Mon, 7 Sep 2009 17:36:43 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <19109.2662.742.855467@segfault.lan>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909070157y50ac7aa8udbd671d5f877224a@mail.gmail.com>
	<19109.2662.742.855467@segfault.lan>
Message-ID: <c8f260e70909070836mfd71acfqfcf933ee152eedff@mail.gmail.com>

On Mon, Sep 7, 2009 at 3:28 PM, John W. Eaton <jwe at octave.org> wrote:
> On ?7-Sep-2009, Michael Creel wrote:
>
> | I'm trying to
> | compile a checkout of the development version to see if I can
> | replicate your results, but it crashes with
> | In file included from ./txt-eng-ft.h:28,
> | ? ? ? ? ? ? ? ? ?from ./gl-render.h:43,
> | ? ? ? ? ? ? ? ? ?from ./DLD-FUNCTIONS/fltk_backend.cc:60:
> | /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
> | such file or directory
>
> I'd say fix this problem first. ?Why is freetype/config/ftheader.h
> missing? ?Note that Octave is not including this file directly, it is
> included from /usr/include/ft2build.h, so I think there is some
> problem with your installation of FreeType. ?Look at the
> /usr/include/ft2build.h file to see if there are some clues there.
>
> jwe
>

Hmm, the fltk stuff is pretty new for me. I'm running Kubuntu 9.04,
and freetype, etc., come from the provided packages. My first problem
is that I don't have a clear idea of what libraries (or more usefully
for me, Debian package names) are required.  Perhaps I'm missing a
needed package. I can compile 3.2.x release candidates without
problems, including with the fltk backend. There doesn't seem to be a
switch to disable compilation of the fltk backend in the development
version. Is there some way to do that?
Michael


From highegg at gmail.com  Mon Sep  7 11:42:11 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 7 Sep 2009 18:42:11 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909070836mfd71acfqfcf933ee152eedff@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909070157y50ac7aa8udbd671d5f877224a@mail.gmail.com>
	<19109.2662.742.855467@segfault.lan>
	<c8f260e70909070836mfd71acfqfcf933ee152eedff@mail.gmail.com>
Message-ID: <69d8d540909070942i5d344dd8x16e8b062068980b9@mail.gmail.com>

On Mon, Sep 7, 2009 at 5:36 PM, Michael Creel<michael.creel at uab.es> wrote:
> On Mon, Sep 7, 2009 at 3:28 PM, John W. Eaton <jwe at octave.org> wrote:
>> On ?7-Sep-2009, Michael Creel wrote:
>>
>> | I'm trying to
>> | compile a checkout of the development version to see if I can
>> | replicate your results, but it crashes with
>> | In file included from ./txt-eng-ft.h:28,
>> | ? ? ? ? ? ? ? ? ?from ./gl-render.h:43,
>> | ? ? ? ? ? ? ? ? ?from ./DLD-FUNCTIONS/fltk_backend.cc:60:
>> | /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
>> | such file or directory
>>
>> I'd say fix this problem first. ?Why is freetype/config/ftheader.h
>> missing? ?Note that Octave is not including this file directly, it is
>> included from /usr/include/ft2build.h, so I think there is some
>> problem with your installation of FreeType. ?Look at the
>> /usr/include/ft2build.h file to see if there are some clues there.
>>
>> jwe
>>
>
> Hmm, the fltk stuff is pretty new for me. I'm running Kubuntu 9.04,
> and freetype, etc., come from the provided packages. My first problem
> is that I don't have a clear idea of what libraries (or more usefully
> for me, Debian package names) are required. ?Perhaps I'm missing a
> needed package. I can compile 3.2.x release candidates without
> problems, including with the fltk backend. There doesn't seem to be a
> switch to disable compilation of the fltk backend in the development
> version. Is there some way to do that?
> Michael
>
>

First, make sure you have all the -devel packages installed; there is
sometimes a missing dependency between those.
Can you locate the header <somepath>/freetype/config/ftheader.h? If
yes, just add -I<somepath> to CXXFLAGS.

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


From storrsjm at email.uc.edu  Mon Sep  7 13:58:32 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Mon, 7 Sep 2009 14:58:32 -0400
Subject: development snapshot
In-Reply-To: <69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
Message-ID: <a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>

One thing that I don't think has been satisfactorily resolved in our
discussions is whether statements that certain things are "impossible" in
the supporting text affect the scope of the claims? Maybe SFLC can help
clairify that.

If octave's implementation fundamentally relies on "doing the impossible" as
described in the supporting text can it possibly infringe?

--judd


For me the problem is that if you restrict your reading to the claims alone
it is unclear what "at the first point" means and you could possibly read it
as meaning

(1) At any time between handle creation and handle evaluation, or
(2) Specifically at the time/scope that the handle is created

If you then read the supporting text it seems that (2) is what was meant. I
don't really understand what influence the supporting text has over the
claims (if any). It seem reasonable to me that the supporting text is meant
to clarify the claims, but IANAL.

According to the supporting text it is "impossible" to correctly resolve the
handle unless the data structure is created at the same time and/or in the
same scope that the handle was created. To me this indicates that reading
(2) of the claims is correct.

Under reading (1) you get the massively expansive claims that could cover
closures, possibly most of symbolic computation, among other things (all of
which have prior art). I just don't think the USPTO could possibly have
granted the patent under such a broad reading of the claims.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090907/afcd7dc3/attachment.html 

From tmacchant at yahoo.co.jp  Mon Sep  7 18:13:26 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 8 Sep 2009 08:13:26 +0900 (JST)
Subject: 3.2.3 RC3
In-Reply-To: <69d8d540909070031k7c316f59ma6f4aa11af36559@mail.gmail.com>
Message-ID: <20090907231326.91656.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello

By GCC-4.4.0 (MinGW32 Offcial)

Summary:

  PASS   5751
  FAIL      4

The failures are alreay known.

 
--- Jaroslav Hajek  wrote:

> hi all,
> 
> 
> the 3.2.3 RC3 tarballs are available at
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> I think there is still the pertaining issue with mouse zooming in
> Windows; but if there was a fix proposed, I missed it.

I have proposed the patch just before you posted this thread.

http://www.nabble.com/changeset-9395-(3.2.?-branch)-should-be-applied-not-only-x11-term-but-on-windows,-wxt,-(-and-aqua)-term-tc25326547.html

I am now waiting the test of aqua term on MacOSX from Ben or other Mac Users.

Regards

Tatsuro


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

From octave at phaselockedsystems.com  Mon Sep  7 18:23:52 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Mon, 07 Sep 2009 16:23:52 -0700
Subject: development snapshot
In-Reply-To: <a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>	<19102.49674.637449.216165@segfault.lan>	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>	<19103.59481.557945.168889@segfault.lan>	<19105.36502.204082.979320@segfault.lan>	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
	<a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
Message-ID: <4AA59608.6070604@phaselockedsystems.com>

Judd Storrs wrote:
> One thing that I don't think has been satisfactorily resolved in our 
> discussions is whether statements that certain things are "impossible" 
> in the supporting text affect the scope of the claims? Maybe SFLC can 
> help clairify that.
>
> If octave's implementation fundamentally relies on "doing the 
> impossible" as described in the supporting text can it possibly infringe?
>

This is a question I have asked attorneys for year after year and never 
had an answer.  My interpretation is that you won't know until you face 
a judge.

> --judd
>
>
> For me the problem is that if you restrict your reading to the claims 
> alone it is unclear what "at the first point" means and you could 
> possibly read it as meaning
>

When interpreting the claims, the patent body serves as a dictionary.  
So if a term is not clear, e.g. "at the first point", you refer to the 
patent body to clarify.  If the patent body doesn't adequately clarify, 
then you refer to "standard practice" whatever the h&*l that means.  
There are a number of terms in the claims that this pertains to.  For 
example, the concept of a "dynamically typed language" really needs the 
patent body to interpret.  There is the concept of direct infringement 
vs. the "Doctrine of Equivalents" and things just get messy from there.

> (1) At any time between handle creation and handle evaluation, or
> (2) Specifically at the time/scope that the handle is created
>
> If you then read the supporting text it seems that (2) is what was 
> meant. I don't really understand what influence the supporting text 
> has over the claims (if any). It seem reasonable to me that the 
> supporting text is meant to clarify the claims, but IANAL.
>
> According to the supporting text it is "impossible" to correctly 
> resolve the handle unless the data structure is created at the same 
> time and/or in the same scope that the handle was created. To me this 
> indicates that reading (2) of the claims is correct.
>
> Under reading (1) you get the massively expansive claims that could 
> cover closures, possibly most of symbolic computation, among other 
> things (all of which have prior art). I just don't think the USPTO 
> could possibly have granted the patent under such a broad reading of 
> the claims.

I don't think there is any question that claim 1 and possibly other 
claims would be rejected if a validity lawsuit was brought against the 
Mathworks.  There are two serious questions.  First, how far down the 
list of claims would you have to go before things got more intelligent?  
Second, who is going to pay for all of this?

The second is really the more important.  We can argue about validity 
all day, but the patent is presumed valid until a judge (or jury) rules 
otherwise and that costs money.  I am fairly sure that there is plenty 
of prior art (in fact, I think maybe Python could serve as prior art).  
Still, unless you get someone with money to back you up it isn't really 
relevant.  One thing to keep in mind is that infringement is not really 
a technical thing (although technical experts are listened to very 
seriously in the courtroom and in the pretrial briefs) but is a legal 
thing.  The judge and jury are rarely technical and THEY will make the 
judgment.

Bob
---
Robert T. Short, Ph.D.
PhaseLocked Systems

From storrsjm at email.uc.edu  Mon Sep  7 20:41:05 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Mon, 7 Sep 2009 21:41:05 -0400
Subject: development snapshot
In-Reply-To: <4AA59608.6070604@phaselockedsystems.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
	<a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
	<4AA59608.6070604@phaselockedsystems.com>
Message-ID: <a0daad600909071841s584c161fne1925d9206eaa1c1@mail.gmail.com>

On Mon, Sep 7, 2009 at 7:23 PM, Robert T. Short <
octave at phaselockedsystems.com> wrote:

> I don't think there is any question that claim 1 and possibly other
> claims would be rejected if a validity lawsuit was brought against the
> Mathworks.
>

What I would caution is to not be so confident in the strength of the case
against the overall validity of the patent (I think you understand this).
Making a case against the broadest possible interpretation of the patent is
insufficient. Courts don't throw patents out unless they have to and in this
case they have the option of limiting the scope of the patent to the narrow
interpretation. I think its likely that the best that can be done is to get
the interpretation of the patent limited to the narrow reading.

You are correct that there is a very strong case against the broad reading
(including the Mathworks' own use of the word "impossible" within the patent
itself). However, I find our case against the narrow reading is weak yet.
I've looked for prior art (including python) to the narrow reading, and have
failed to find anything except Matlab.

I anticipate that if this went to trial the Mathworks could make a very
strong case that the patent addresses a problem that is specific to the
Matlab language and that upholding the narrow reading would only harm those
seeking to duplicate Matlab. I think it is far more likely that the court
could easily decide to limit the claims to the narrow reading instead of
rejecting all the entire claim outright.

So, the question is what is octave's strategic goal here?

If the goal is to take on Mathworks in court and to destroy the patent then
the correct tactical move is to implement the claims exactly as described
under the narrow reading so that the courts don't have the option of
limiting the scope of the patent.

If the goal is to avoid a legal confrontation, my instinct is that directly
implementing the narrow reading of the claims is a tactical blunder because
it gives the Mathworks their strongest case. Mathworks is more likely to
avoid court against octave if it is likely that their patents could be
limited by the courts or invalidated. Some degree of incompatibility between
octave's implementation and Matlab's could be a tactical advantage--it
strengthens our case if it is possible to provide code that works under the
narrow reading (i.e. Matlab's implementation) but fails under octave's (and
vice-versa).

But I realize both that I'm not able to implement any of this and that my
opinion is cheap.

--judd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090907/79f155b5/attachment.html 

From godfrey at isl.stanford.edu  Mon Sep  7 21:15:53 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Mon, 07 Sep 2009 19:15:53 -0700
Subject: Contribution to the optimization toolbox
In-Reply-To: <8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>	<69d8d540909040133n30fb7279v9c7dfcb925fc8825@mail.gmail.com>	<c8f260e70909040424g27ae7771r33139f8baa57aa4e@mail.gmail.com>	<69d8d540909040553v542a956ai97b9f91b6dc486d7@mail.gmail.com>
	<8ea5036f0909040627t62061d9ex7cd16c13f9b64b68@mail.gmail.com>
Message-ID: <4AA5BE59.8060202@isl.stanford.edu>

Leonardo,

I am the one, of your many responses, who mentioned
Convex Optimization.  I have learned 2 things since then:

1. The current  code that they have (under GPL2) allows
     "installation" into Octave as an option.

2. They (mainly Michael Grant) and some Octave developers
     have been "talking."

You will likely hear about this from other Octave developers.

The URL for the Userguide for cvx is:
http://www.stanford.edu/~boyd/cvx/cvx_usrguide.pdf
and the page where CVX is described is:
http://www.stanford.edu/~boyd/cvx/download.html

Hope this helps,

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090907/69f4abd0/attachment.html 

From jwe at octave.org  Mon Sep  7 22:08:09 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 7 Sep 2009 23:08:09 -0400
Subject: development snapshot
In-Reply-To: <a0daad600909071841s584c161fne1925d9206eaa1c1@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
	<a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
	<4AA59608.6070604@phaselockedsystems.com>
	<a0daad600909071841s584c161fne1925d9206eaa1c1@mail.gmail.com>
Message-ID: <19109.51865.572103.722481@segfault.lan>

On  7-Sep-2009, Judd Storrs wrote:

| So, the question is what is octave's strategic goal here?

For starters, discussing it on a public mailing list with an
accessible archive doesn't seem like the best move.

jwe

From godfrey at isl.stanford.edu  Tue Sep  8 00:03:31 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Mon, 07 Sep 2009 22:03:31 -0700
Subject: A backend("fltk") problem
In-Reply-To: <420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
References: <4A9749CF.6030708@isl.stanford.edu>	
	<19101.34310.961893.954083@segfault.lan>	
	<4A9D906A.8030606@isl.stanford.edu>	
	<19101.37238.710823.546142@segfault.lan>	
	<4A9D9C7B.9050101@isl.stanford.edu>	
	<19102.57857.878905.590704@segfault.lan>	
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
Message-ID: <4AA5E5A3.6090407@isl.stanford.edu>

On 09/02/2009 08:46 PM, Shai Ayal wrote:
> The status of the fltk/OpenGL backend as far as I know is consistent
> with your observation: printing is not yet implemented - it is (was?)
> planned to be done using the gl2ps library (actually consisting of one
> c-file and one h-file).

I just looked up the gl2ps stuff.  It is  standard in Fedora 11 and
I just installed it.  I looked quickly at the Manual and it looks pretty
straightforward.
.
So, unless you would rather do this yourself, could you very
briefly indicate where to start in the Octave code?

Earlier today I was working on some stuff with a number of
plots (and subplots).  I tried them with backend("fltk") and the plots
are all obviously better than the current development gnuplot-based
results.  This reinforces my view that it would be very helpful to
get this working.  Printing appears to be the main problem.

Michael



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090907/9431d826/attachment.html 

From dasergatskov at gmail.com  Tue Sep  8 00:21:57 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 8 Sep 2009 00:21:57 -0500
Subject: A backend("fltk") problem
In-Reply-To: <4AA5E5A3.6090407@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
	<4AA5E5A3.6090407@isl.stanford.edu>
Message-ID: <892b16670909072221y44e7e33ege25de504fb928a64@mail.gmail.com>

On Tue, Sep 8, 2009 at 12:03 AM, Michael D
Godfrey<godfrey at isl.stanford.edu> wrote:

>
> Earlier today I was working on some stuff with a number of
> plots (and subplots).? I tried them with backend("fltk") and the plots
> are all obviously better than the current development gnuplot-based
> results.

Can you elaborate on the "better" part? If you just like an anti-aliased look
than you can try to convince gnuplot to use e.g. wxt terminal instead of
plain vanila (and fast!) x11 terminal. E.g. by starting octave this way:

GNUTERM="wxt" octave

> Michael
>

Sincerely,

Dmitri.
--


From godfrey at isl.stanford.edu  Tue Sep  8 00:29:53 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Mon, 07 Sep 2009 22:29:53 -0700
Subject: A backend("fltk") problem
In-Reply-To: <892b16670909072221y44e7e33ege25de504fb928a64@mail.gmail.com>
References: <4A9749CF.6030708@isl.stanford.edu>	
	<19101.34310.961893.954083@segfault.lan>	
	<4A9D906A.8030606@isl.stanford.edu>	
	<19101.37238.710823.546142@segfault.lan>	
	<4A9D9C7B.9050101@isl.stanford.edu>	
	<19102.57857.878905.590704@segfault.lan>	
	<4A9EF679.8050205@isl.stanford.edu>	
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>	
	<4AA5E5A3.6090407@isl.stanford.edu>
	<892b16670909072221y44e7e33ege25de504fb928a64@mail.gmail.com>
Message-ID: <4AA5EBD1.60502@isl.stanford.edu>

On 09/07/2009 10:21 PM, Dmitri A. Sergatskov wrote:
> Can you elaborate on the "better" part? If you just like an anti-aliased look
> than you can try to convince gnuplot to use e.g. wxt terminal instead of
> plain vanila (and fast!) x11 terminal. E.g. by starting octave this way:
>    
There are quite a few differences:  x and y scale choice, subplot
layout so that title and graphs do not overlap, and others.  I have to
admit that I had to switch to Matlab to get some of the plots to be
usable PostScript.  But, the appearance of the fltk plots was better 
than Matlab.

Michael



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090907/84348f8f/attachment.html 

From shaiay at gmail.com  Tue Sep  8 01:36:02 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 8 Sep 2009 09:36:02 +0300
Subject: gl2ps
In-Reply-To: <4AA5E8DB.3010309@isl.stanford.edu>
References: <4AA5E8DB.3010309@isl.stanford.edu>
Message-ID: <420fb9e60909072336n5d968274ib52543a63564be2c@mail.gmail.com>

On Tue, Sep 8, 2009 at 8:17 AM, Michael D
Godfrey<godfrey at isl.stanford.edu> wrote:
> Am I oversimplifying a lot by saying that a routine
> like:
> Matrix
> opengl_renderer::draw_text (const std::string& txt,
> ??? ??? ??? ??? double x, double y, double z,
> ??? ??? ??? ??? int halign, int valign, double rotation)
>
> which calls:
> ?gl2psDrawPixels( GLsizei width, GLsizei height,
> GLint xorig, GLint yorig,
> GLenum format, GLenum type,
> const void *pixels )
>
> instead of glDrawPixels (w, h,
> ??? ??? GL_RGBA, GL_UNSIGNED_BYTE, pixels.data ());
>
> would do most of the work?

It should work, However the problem with this approach is that you'll
have bitmap fonts, which have the following drawbacks:
1. they do not scale nicely, so they would probably look bad in a printout
2. the bitmaps will increase the filesize considerably.

OTOH, using the gl2ps text routines which use the ps fonts have the
drawback that they do not support anything but "normal" text (i.e. no
LaTeX)

Shai


From shaiay at gmail.com  Tue Sep  8 01:44:36 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 8 Sep 2009 09:44:36 +0300
Subject: A backend("fltk") problem
In-Reply-To: <4AA5E5A3.6090407@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
	<4AA5E5A3.6090407@isl.stanford.edu>
Message-ID: <420fb9e60909072344q55766f66jc7e9df9033440d93@mail.gmail.com>

On Tue, Sep 8, 2009 at 8:03 AM, Michael D
Godfrey<godfrey at isl.stanford.edu> wrote:
> On 09/02/2009 08:46 PM, Shai Ayal wrote:
> So, unless you would rather do this yourself, could you very
> briefly indicate where to start in the Octave code?
I have no time currently, so please do it.
just of the top of my head (I'll have a deeper look at the code later
this week and get back to you with a better answer) , for the gl2ps
stuff, I think you should look at subclassing the opengl-renderer,
reusing as much code as possible, maybe just replacing the text
drawing routines.
You can have two approaches for the top-level printing stuff:
1. make it the fltk printer device (I think the backend class in
graphics.cc has stupor for printing in the backend)
2. make a operate "ps" backend, which might be better since it could
be reused by future backends, and also might be independent of the
screen  - i.e. enable batch production of graphs. The diadvantage is
you have some coding overhead in implementing some stuff from the
backend class.

Shai

From highegg at gmail.com  Tue Sep  8 02:56:41 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 8 Sep 2009 09:56:41 +0200
Subject: development snapshot
In-Reply-To: <a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
	<a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
Message-ID: <69d8d540909080056w6a06f425scb2d77ac9ef23d4a@mail.gmail.com>

On Mon, Sep 7, 2009 at 8:58 PM, Judd Storrs<storrsjm at email.uc.edu> wrote:
> One thing that I don't think has been satisfactorily resolved in our
> discussions is whether statements that certain things are "impossible" in
> the supporting text affect the scope of the claims? Maybe SFLC can help
> clairify that.
>
> If octave's implementation fundamentally relies on "doing the impossible" as
> described in the supporting text can it possibly infringe?
>
> --judd
>
>
> For me the problem is that if you restrict your reading to the claims alone
> it is unclear what "at the first point" means and you could possibly read it
> as meaning
>
> (1) At any time between handle creation and handle evaluation, or
> (2) Specifically at the time/scope that the handle is created
>
> If you then read the supporting text it seems that (2) is what was meant. I
> don't really understand what influence the supporting text has over the
> claims (if any). It seem reasonable to me that the supporting text is meant
> to clarify the claims, but IANAL.
>
> According to the supporting text it is "impossible" to correctly resolve the
> handle unless the data structure is created at the same time and/or in the
> same scope that the handle was created. To me this indicates that reading
> (2) of the claims is correct.
>
> Under reading (1) you get the massively expansive claims that could cover
> closures, possibly most of symbolic computation, among other things (all of
> which have prior art). I just don't think the USPTO could possibly have
> granted the patent under such a broad reading of the claims.
>

I also think that (2) was meant; however, I don't think it really
matters that much. The source of the incredible broadness of the
patent is that for "information leading to a set of functions visible
at the first point", storing name and scope is sufficient. Any
implementation must store the name, and any implementation must either
store the scope or extract any local-scope function in advance and
store that (which is what Octave does now).
Both of these are plain logical consequences of the mere idea of
having an overloaded function handle that can export local-scope
functions. It's just one of those patents that are obvious. The same
thing was achievable with anonymous functions before, like @(x)
myfunc(x).

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

From michael.goffioul at gmail.com  Tue Sep  8 03:54:43 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Tue, 8 Sep 2009 09:54:43 +0100
Subject: A backend("fltk") problem
In-Reply-To: <4AA5E5A3.6090407@isl.stanford.edu>
References: <4A9749CF.6030708@isl.stanford.edu>
	<19101.34310.961893.954083@segfault.lan>
	<4A9D906A.8030606@isl.stanford.edu>
	<19101.37238.710823.546142@segfault.lan>
	<4A9D9C7B.9050101@isl.stanford.edu>
	<19102.57857.878905.590704@segfault.lan>
	<4A9EF679.8050205@isl.stanford.edu>
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>
	<4AA5E5A3.6090407@isl.stanford.edu>
Message-ID: <128f38bd0909080154k60669be1qd9586a73360396d0@mail.gmail.com>

On Tue, Sep 8, 2009 at 6:03 AM, Michael D
Godfrey<godfrey at isl.stanford.edu> wrote:
> On 09/02/2009 08:46 PM, Shai Ayal wrote:
>
> The status of the fltk/OpenGL backend as far as I know is consistent
> with your observation: printing is not yet implemented - it is (was?)
> planned to be done using the gl2ps library (actually consisting of one
> c-file and one h-file).
>
> I just looked up the gl2ps stuff.? It is? standard in Fedora 11 and
> I just installed it.? I looked quickly at the Manual and it looks pretty
> straightforward.
> .
> So, unless you would rather do this yourself, could you very
> briefly indicate where to start in the Octave code?

I strongly suggest that you have a look at JHandles use of gl2ps,
which is what I planned to re-use in OpenGL renderer. The idea is
to derive from opengl_renderer and add the needed stuff for gl2ps:
- initialisation and completion
- color, linestyle... handling
- specific text handling

Except for text rendering, where I already did a large part of the
job in JHandles, the required coding is quite limited, as you built
the renderer on top of the existing OpenGL one.

Just as a concept, the idea is:

class gl2ps_renderer : public opengl_renderer
{
...
protected:
    void set_color(const Matrix& c)
    {
         opengl_renderer::set_color(c);
         // do gl2ps specific things
    }
...
};

Michael.


From highegg at gmail.com  Tue Sep  8 04:09:57 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 8 Sep 2009 11:09:57 +0200
Subject: development snapshot
In-Reply-To: <a0daad600909071841s584c161fne1925d9206eaa1c1@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
	<a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
	<4AA59608.6070604@phaselockedsystems.com>
	<a0daad600909071841s584c161fne1925d9206eaa1c1@mail.gmail.com>
Message-ID: <69d8d540909080209h21955ddai4c76c8ca87e0b89d@mail.gmail.com>

On Tue, Sep 8, 2009 at 3:41 AM, Judd Storrs<storrsjm at email.uc.edu> wrote:
> On Mon, Sep 7, 2009 at 7:23 PM, Robert T. Short
> <octave at phaselockedsystems.com> wrote:
>>
>> I don't think there is any question that claim 1 and possibly other
>> claims would be rejected if a validity lawsuit was brought against the
>> Mathworks.
>
> What I would caution is to not be so confident in the strength of the case
> against the overall validity of the patent (I think you understand this).
> Making a case against the broadest possible interpretation of the patent is
> insufficient. Courts don't throw patents out unless they have to and in this
> case they have the option of limiting the scope of the patent to the narrow
> interpretation. I think its likely that the best that can be done is to get
> the interpretation of the patent limited to the narrow reading.
>
> You are correct that there is a very strong case against the broad reading
> (including the Mathworks' own use of the word "impossible" within the patent
> itself). However, I find our case against the narrow reading is weak yet.
> I've looked for prior art (including python) to the narrow reading, and have
> failed to find anything except Matlab.
>
> I anticipate that if this went to trial the Mathworks could make a very
> strong case that the patent addresses a problem that is specific to the
> Matlab language and that upholding the narrow reading would only harm those
> seeking to duplicate Matlab. I think it is far more likely that the court
> could easily decide to limit the claims to the narrow reading instead of
> rejecting all the entire claim outright.
>

Yes, I think the patent addresses a problem that is, to my knowledge,
specific to the Matlab language. I don't think there was, prior to
this patent, another language with both the class-based overloading
and closures. Octave infringes the patent because it implements the
Matlab language. The point is that it is actually an idea, not
implementation, that is patented here, and a relatively simple one,
even though MathWorks came up first with it.

>
> So, the question is what is octave's strategic goal here?
>
> If the goal is to take on Mathworks in court and to destroy the patent then
> the correct tactical move is to implement the claims exactly as described
> under the narrow reading so that the courts don't have the option of
> limiting the scope of the patent.
>
> If the goal is to avoid a legal confrontation, my instinct is that directly
> implementing the narrow reading of the claims is a tactical blunder because
> it gives the Mathworks their strongest case. Mathworks is more likely to
> avoid court against octave if it is likely that their patents could be
> limited by the courts or invalidated. Some degree of incompatibility between
> octave's implementation and Matlab's could be a tactical advantage--it
> strengthens our case if it is possible to provide code that works under the
> narrow reading (i.e. Matlab's implementation) but fails under octave's (and
> vice-versa).
>

If by Octave's strategy you mean the community; I don't think we have
any strategic goal. The community is no legal entity and is spread
over the world with differing legal systems.
This problem is limited to USA due to its
over-permissive->over-restrictive patent system, so the decision
should be on US users. The position of mine and others not threatened
by the patent is worth little. Of course, I will try to help the
Octavers from US if needed.

If, as a result, Octave needs to be crippled, I shall probably fork a
separate patent-threat-free version. Not just to allow myself to
continue using the functionality, but also because doing so may
prevent MathWorks from re-filing the patent in EU if EU ever falls to
lobbying and allows software patents.

PS.
Seeing all this, I think it's amazing that so much good free software
is still being written in the USA. How do the other free software
developers in USA cope with the patent threats? Do they ignore them,
or spend hours studying patent claims, in order to find workarounds?
Gosh, it really feels so funny. In our country, United States have
been a symbol of freedom for decades. Now I talk to people from USA
about how to deal with the restrictions in their country. Kind of like
the Voice of America reversed :) OK, it's nothing like a serious
issue; but still, it's a bit weird.

best regards

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

From michael.creel at uab.es  Tue Sep  8 04:10:54 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 8 Sep 2009 11:10:54 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909070942i5d344dd8x16e8b062068980b9@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909070836mfd71acfqfcf933ee152eedff@mail.gmail.com>
	<69d8d540909070942i5d344dd8x16e8b062068980b9@mail.gmail.com>
Message-ID: <c8f260e70909080210l6f08a212ja9abab3f1321c81a@mail.gmail.com>

On Mon, Sep 7, 2009 at 6:42 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Mon, Sep 7, 2009 at 5:36 PM, Michael Creel<michael.creel at uab.es> wrote:
>> On Mon, Sep 7, 2009 at 3:28 PM, John W. Eaton <jwe at octave.org> wrote:
>>> On ?7-Sep-2009, Michael Creel wrote:
>>>
>>> | I'm trying to
>>> | compile a checkout of the development version to see if I can
>>> | replicate your results, but it crashes with
>>> | In file included from ./txt-eng-ft.h:28,
>>> | ? ? ? ? ? ? ? ? ?from ./gl-render.h:43,
>>> | ? ? ? ? ? ? ? ? ?from ./DLD-FUNCTIONS/fltk_backend.cc:60:
>>> | /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
>>> | such file or directory
>>>
>>> I'd say fix this problem first. ?Why is freetype/config/ftheader.h
>>> missing? ?Note that Octave is not including this file directly, it is
>>> included from /usr/include/ft2build.h, so I think there is some
>>> problem with your installation of FreeType. ?Look at the
>>> /usr/include/ft2build.h file to see if there are some clues there.
>>>
>>> jwe
>>>
>>
>> Hmm, the fltk stuff is pretty new for me. I'm running Kubuntu 9.04,
>> and freetype, etc., come from the provided packages. My first problem
>> is that I don't have a clear idea of what libraries (or more usefully
>> for me, Debian package names) are required. ?Perhaps I'm missing a
>> needed package. I can compile 3.2.x release candidates without
>> problems, including with the fltk backend. There doesn't seem to be a
>> switch to disable compilation of the fltk backend in the development
>> version. Is there some way to do that?
>> Michael
>>
>>
>
> First, make sure you have all the -devel packages installed; there is
> sometimes a missing dependency between those.
> Can you locate the header <somepath>/freetype/config/ftheader.h? If
> yes, just add -I<somepath> to CXXFLAGS.
>

John and Jaroslav - thanks for the tips, I just had to make a symlink
to put a directory in the place it was expected to be. The development
version is now working fine for me. With the development version, I
checked the little test script included below, and got the results

octave:3> compare
Results using analytic gradient
ans =

   0.018180   0.999000   0.093864   0.997000

Results using numeric gradient
ans =

   0.025299   0.999000   0.061082   1.000000


The recent change in the initial trust region setting has helped
fminunc. In my results, bfgsmin is still faster than fminunc, and
there is no difference for me in the performance of fminunc using
Octave 3.2.2 versus the checkout of development sources. Perhaps I am
using GradObj incorrectly, because for fminunc the numeric gradient is
faster than the analytic gradient.

At any rate, I don't make too much of these test results, because it's
only one test function and there are all sorts of reasons our results
can vary (architectures/compilation switches, etc).  This exercise
does show how having a body of tests could be useful for comparing
methods, and for checking for regressions.

Cheers, Michael

################## Last version of test code #######################3
1;
# in the calls to the minimization functions, use "objective" if you
want analytic gradient, otherwise, use "objective2"

# example obj. fn.: with gradient
function [obj_value, g] = objective(x)
        [obj_value, g] = rosenbrock(x);
endfunction

# example obj. fn.: no gradient
function obj_value = objective2(x)
        obj_value = rosenbrock(x);
endfunction


dim = 5;
replications = 1000;
results = zeros(replications,4);
ub = 2;
lb = 0;
control = {100,0};  # set the second number to 1,2,3 for increasing
levels of bfgsmin verbosity

optimset("GradObj", "on");
for i = 1:replications
        x = (ub-lb).*rand(dim,1) + lb;
        tic;
        [theta, obj_value, convergence] = bfgsmin("objective", {x}, control);
        results(i,1) = toc;
        results(i,2) = norm(theta - ones(dim,1)) < 1e-5;

        tic;
        [theta, obj_value] = fminunc("objective", x);
        results(i,3) = toc;
        results(i,4) = norm(theta - ones(dim,1)) < 1e-5;
endfor
printf("Results using analytic gradient\n");
mean(results)

optimset("GradObj", "off");
for i = 1:replications
        x = (ub-lb).*rand(dim,1) + lb;
        tic;
        [theta, obj_value, convergence] = bfgsmin("objective2", {x}, control);


From highegg at gmail.com  Tue Sep  8 04:59:58 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 8 Sep 2009 11:59:58 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909080210l6f08a212ja9abab3f1321c81a@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909070836mfd71acfqfcf933ee152eedff@mail.gmail.com>
	<69d8d540909070942i5d344dd8x16e8b062068980b9@mail.gmail.com>
	<c8f260e70909080210l6f08a212ja9abab3f1321c81a@mail.gmail.com>
Message-ID: <69d8d540909080259p7f43f351l3b004ae7a9965280@mail.gmail.com>

On Tue, Sep 8, 2009 at 11:10 AM, Michael Creel<michael.creel at uab.es> wrote:
> On Mon, Sep 7, 2009 at 6:42 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> On Mon, Sep 7, 2009 at 5:36 PM, Michael Creel<michael.creel at uab.es> wrote:
>>> On Mon, Sep 7, 2009 at 3:28 PM, John W. Eaton <jwe at octave.org> wrote:
>>>> On ?7-Sep-2009, Michael Creel wrote:
>>>>
>>>> | I'm trying to
>>>> | compile a checkout of the development version to see if I can
>>>> | replicate your results, but it crashes with
>>>> | In file included from ./txt-eng-ft.h:28,
>>>> | ? ? ? ? ? ? ? ? ?from ./gl-render.h:43,
>>>> | ? ? ? ? ? ? ? ? ?from ./DLD-FUNCTIONS/fltk_backend.cc:60:
>>>> | /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
>>>> | such file or directory
>>>>
>>>> I'd say fix this problem first. ?Why is freetype/config/ftheader.h
>>>> missing? ?Note that Octave is not including this file directly, it is
>>>> included from /usr/include/ft2build.h, so I think there is some
>>>> problem with your installation of FreeType. ?Look at the
>>>> /usr/include/ft2build.h file to see if there are some clues there.
>>>>
>>>> jwe
>>>>
>>>
>>> Hmm, the fltk stuff is pretty new for me. I'm running Kubuntu 9.04,
>>> and freetype, etc., come from the provided packages. My first problem
>>> is that I don't have a clear idea of what libraries (or more usefully
>>> for me, Debian package names) are required. ?Perhaps I'm missing a
>>> needed package. I can compile 3.2.x release candidates without
>>> problems, including with the fltk backend. There doesn't seem to be a
>>> switch to disable compilation of the fltk backend in the development
>>> version. Is there some way to do that?
>>> Michael
>>>
>>>
>>
>> First, make sure you have all the -devel packages installed; there is
>> sometimes a missing dependency between those.
>> Can you locate the header <somepath>/freetype/config/ftheader.h? If
>> yes, just add -I<somepath> to CXXFLAGS.
>>
>
> John and Jaroslav - thanks for the tips, I just had to make a symlink
> to put a directory in the place it was expected to be. The development
> version is now working fine for me. With the development version, I
> checked the little test script included below, and got the results
>
> octave:3> compare
> Results using analytic gradient
> ans =
>
> ? 0.018180 ? 0.999000 ? 0.093864 ? 0.997000
>
> Results using numeric gradient
> ans =
>
> ? 0.025299 ? 0.999000 ? 0.061082 ? 1.000000
>
>
> The recent change in the initial trust region setting has helped
> fminunc. In my results, bfgsmin is still faster than fminunc, and
> there is no difference for me in the performance of fminunc using
> Octave 3.2.2 versus the checkout of development sources. Perhaps I am
> using GradObj incorrectly, because for fminunc the numeric gradient is
> faster than the analytic gradient.
>

Yes, you are. optimset does not affect some global state; it just
constructs an option structure to be passed to fminunc. Note also that
the optim package contained an old simplistic "optimset" replacement
that shadowed Octave's version, I fixed that in SVN now.

Here's an improved script:

################## Last version of test code #######################3
1;
# in the calls to the minimization functions, use "objective" if you
# want analytic gradient, otherwise, use "objective2"

# example obj. fn.: with gradient
function [obj_value, g] = objective(x)
       [obj_value, g] = rosenbrock(x);
endfunction

# example obj. fn.: no gradient
function obj_value = objective2(x)
       obj_value = rosenbrock(x);
endfunction


dim = 5;
replications = 100;
results = zeros(replications,6);
ub = 2;
lb = 0;
control = {100,0};  # set the second number to 1,2,3 for increasing
levels of bfgsmin verbosity

opt = optimset("GradObj", "on");
for i = 1:replications
       x = (ub-lb).*rand(dim,1) + lb;
       tic;
       [theta, obj_value, convergence] = bfgsmin("objective", {x}, control);
       results(i,1) = toc;
       results(i,2) = norm(theta - ones(dim,1));
       results(i,3) = obj_value;

       tic;
       [theta, obj_value] = fminunc("objective", x, opt);
       results(i,4) = toc;
       results(i,5) = norm(theta - ones(dim,1));
       results(i,6) = obj_value;
       fprintf (stderr, "\r%d/%d", i, replications);
endfor
fputs (stderr, "\n");
printf("Results using analytic gradient\n");
mean(results)
median(results)

With a freshly installed package from SVN, I get:

octave:2> compare
100/100
Results using analytic gradient
ans =

   1.6776e-02   6.0941e-08   3.9499e-17   3.0260e-02   2.4907e-08   2.2290e-15

ans =

   1.6358e-02   2.2588e-08   1.9674e-18   2.9318e-02   1.1927e-08   5.1035e-16

The results are comparable, and now I confirm that bfgsmin is faster.
I think the problem previously was that I did not install it;
therefore, Octave extensively checked its date stamp while executing.

I tried also dim = 10:

octave:3> compare
100/100
Results using analytic gradient
ans =

   2.4335e-02   5.6294e-08   1.1550e-16   5.4346e-02   8.5339e-08   2.5899e-14

ans =

   2.3675e-02   3.0352e-08   3.2202e-17   5.3850e-02   3.6230e-08   1.1496e-14


dim = 50:
octave:4> compare
100/100
Results using analytic gradient
ans =

   7.5409e-02   3.5230e-01   6.6630e+00   2.7084e-01   1.4943e-05   1.2621e-10

ans =

   7.6525e-02   2.7970e-04   2.5038e-07   2.7125e-01   9.5309e-06   2.5546e-11

dim = 100:
octave:5> compare
100/100
Results using analytic gradient
ans =

   1.2308e-01   3.6788e+00   1.1264e+02   4.0221e-01   5.5711e-02   1.3950e-03

ans =

   1.2242e-01   3.6939e+00   9.5687e+01   4.0261e-01   3.9672e-02   3.8998e-04

apparently fminunc favors accuracy more than bfgsmin; this is
particularly visible for the higher dimensions;
its time consumption also grows more rapidly.
Obviously, both functions' results deteriorate significantly as the
problem's dimensionality increases, but probably the rosenbrock
problem gets quite difficult in higher dimensions.

In any case, now I have more toys to play with :)

best regards

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


From michael.creel at uab.es  Tue Sep  8 06:11:26 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 8 Sep 2009 13:11:26 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909080259p7f43f351l3b004ae7a9965280@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909080210l6f08a212ja9abab3f1321c81a@mail.gmail.com>
	<69d8d540909080259p7f43f351l3b004ae7a9965280@mail.gmail.com>
Message-ID: <c8f260e70909080411x6e51ea3dkd3bb17b42c927cd9@mail.gmail.com>

Thanks for the new version. Note that when dim is increased, bfgsmin
need to have max iters increased, otherwise it chokes before
converging. Setting control={10000,0} with dim=100, I get the results

octave:4> compare
100/100
Results using analytic gradient
ans =

   3.1157e-01   4.6628e-08   1.2482e-15   4.3526e-01   6.0199e-02   1.6613e-03

ans =

   2.9021e-01   2.9620e-08   3.5626e-16   4.3474e-01   4.5174e-02   5.0746e-04

so bfgsmin is finding the correct answer.


When dim is high, it makes sense to try lbfgs. Setting
control={10000,0,1,1,5} to use a memory of 5 iterations, the results
for dim=100 are

octave:6> compare
100/100
Results using analytic gradient
ans =

   9.0097e-02   1.1931e-06   1.6012e-12   4.3407e-01   5.7046e-02   1.5292e-03

ans =

   8.7479e-02   3.4221e-07   4.5890e-14   4.3370e-01   3.7205e-02   3.5980e-04

so lbfgs is considerably faster than bfgs.

For setting up a bank of test problems, do you think that this test
script captures the important metrics: speed and accuracy? Anything
else to add? I may take the project on,

Cheers, M.

From highegg at gmail.com  Tue Sep  8 06:48:19 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 8 Sep 2009 13:48:19 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909080411x6e51ea3dkd3bb17b42c927cd9@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909080210l6f08a212ja9abab3f1321c81a@mail.gmail.com>
	<69d8d540909080259p7f43f351l3b004ae7a9965280@mail.gmail.com>
	<c8f260e70909080411x6e51ea3dkd3bb17b42c927cd9@mail.gmail.com>
Message-ID: <69d8d540909080448k25f92ef2w9307349302c6394b@mail.gmail.com>

On Tue, Sep 8, 2009 at 1:11 PM, Michael Creel<michael.creel at uab.es> wrote:
> Thanks for the new version. Note that when dim is increased, bfgsmin
> need to have max iters increased, otherwise it chokes before
> converging. Setting control={10000,0} with dim=100, I get the results
>

Oh yes; that could have occured to me. In fact the same is true for
fminunc: default is 400 iters. Maybe it can be somehow computed based
on the problem's dimensionality?
Termination criteria may also play an important role.




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

From lindnerben at gmx.net  Tue Sep  8 09:20:27 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 08 Sep 2009 16:20:27 +0200
Subject: 3.2.3 RC2
In-Reply-To: <19101.38218.61959.506578@segfault.lan>
References: <69d8d540909010116k17f52fa6uef6c18d177a23349@mail.gmail.com>	<4A9D8671.7050007@gmx.net>
	<19101.38218.61959.506578@segfault.lan>
Message-ID: <4AA6682B.1000702@gmx.net>

John W. Eaton wrote:
> On  1-Sep-2009, Benjamin Lindner wrote:
> 
> | Jaroslav Hajek wrote:
> | > hi all,
> | > 
> | > the 3.2.3 RC2 tarballs are available:
> | > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> | 
> | Builds fine using mingw32 TDM-gcc-4.3.0-3.
> | Make check shows the already known failures.
> | 
> | However, as Tatsuro already pointed out, gnuplot does no longer allow 
> | interaction with either keyboard (e.g. grid on/of) or mouse (e.g. 
> | zooming). I tested this with the 2009-july-08 development binaries and a 
> | local build from the CVS snapshot of the same date.
> 
> Zooming doesn't work for me on a Debian system with 3.2.0, 3.2.2, or
> 3.2.3-RC2.  But toggling the grid does work with all three versions.
> I don't know whether zooming with the mouse is suppsoed to work with
> the version of gnuplot I have (4.2.5).  It does work for me when I
> start gnuplot outside of Octave and plot a funtion.  I'm not sure
> whether 4.2.5 can zoom when data comes from a pipe, as Octave is
> sending it now.
> 

For windows to even use the gnuplot backend one requires a true console 
(i.e. pipeable) application, which is available since 
CVS-4.3.0-2008-11-21 thanks to michael goffioul. The zooming feature if 
data is piped into gnuplot requires a build with -DVOLATILE_REFRESH, 
which is available IIRC for 4.3.0. So the available windows binaries 
allow zooming.

benjamin

From highegg at gmail.com  Tue Sep  8 09:20:36 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 8 Sep 2009 16:20:36 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <c8f260e70909080411x6e51ea3dkd3bb17b42c927cd9@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909080210l6f08a212ja9abab3f1321c81a@mail.gmail.com>
	<69d8d540909080259p7f43f351l3b004ae7a9965280@mail.gmail.com>
	<c8f260e70909080411x6e51ea3dkd3bb17b42c927cd9@mail.gmail.com>
Message-ID: <69d8d540909080720w61fb697cla4d74c73de2d8a3d@mail.gmail.com>

On Tue, Sep 8, 2009 at 1:11 PM, Michael Creel<michael.creel at uab.es> wrote:
> Thanks for the new version. Note that when dim is increased, bfgsmin
> need to have max iters increased, otherwise it chokes before
> converging. Setting control={10000,0} with dim=100, I get the results
>
> octave:4> compare
> 100/100
> Results using analytic gradient
> ans =
>
> ? 3.1157e-01 ? 4.6628e-08 ? 1.2482e-15 ? 4.3526e-01 ? 6.0199e-02 ? 1.6613e-03
>
> ans =
>
> ? 2.9021e-01 ? 2.9620e-08 ? 3.5626e-16 ? 4.3474e-01 ? 4.5174e-02 ? 5.0746e-04
>
> so bfgsmin is finding the correct answer.
>
>
> When dim is high, it makes sense to try lbfgs. Setting
> control={10000,0,1,1,5} to use a memory of 5 iterations, the results
> for dim=100 are
>
> octave:6> compare
> 100/100
> Results using analytic gradient
> ans =
>
> ? 9.0097e-02 ? 1.1931e-06 ? 1.6012e-12 ? 4.3407e-01 ? 5.7046e-02 ? 1.5292e-03
>
> ans =
>
> ? 8.7479e-02 ? 3.4221e-07 ? 4.5890e-14 ? 4.3370e-01 ? 3.7205e-02 ? 3.5980e-04
>
> so lbfgs is considerably faster than bfgs.
>
> For setting up a bank of test problems, do you think that this test
> script captures the important metrics: speed and accuracy? Anything
> else to add? I may take the project on,
>
> Cheers, M.
>

Looking at the problem from a slightly different perspective, it now
seems to me that taking the dogleg TR step selection method from
fsolve may not have been that good idea as I thought initially. For
fsolve, it shines because fsolve updates the model after each trial
step, even an unsuccessful one. Uhm. Maybe a line search technique
would be better. At least that would allow simply employing all three
updating techniques in fminunc: BFGS, factored dual BFGS, and LBFGS.

Btw., when I noticed that the rosenbrock function is actually a sum of
squares, just for fun I tried rewriting the problem as a nonlinear
least squares and feed it to fsolve. Doing thath, fsolve literally
crushed the problem converging in 7 iterations (8 function and one
jacobian evaluation). But of course that is a different story; it
exploits the structure of the problem.

Do you have any references for the line search used in bfgsmin?

-- 
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  8 09:21:35 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 8 Sep 2009 16:21:35 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909080720w61fb697cla4d74c73de2d8a3d@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909080210l6f08a212ja9abab3f1321c81a@mail.gmail.com>
	<69d8d540909080259p7f43f351l3b004ae7a9965280@mail.gmail.com>
	<c8f260e70909080411x6e51ea3dkd3bb17b42c927cd9@mail.gmail.com>
	<69d8d540909080720w61fb697cla4d74c73de2d8a3d@mail.gmail.com>
Message-ID: <69d8d540909080721w150a4fe0odf9e9210eb41f775@mail.gmail.com>

On Tue, Sep 8, 2009 at 4:20 PM, Jaroslav Hajek<highegg at gmail.com> wrote:
> On Tue, Sep 8, 2009 at 1:11 PM, Michael Creel<michael.creel at uab.es> wrote:
>> Thanks for the new version. Note that when dim is increased, bfgsmin
>> need to have max iters increased, otherwise it chokes before
>> converging. Setting control={10000,0} with dim=100, I get the results
>>
>> octave:4> compare
>> 100/100
>> Results using analytic gradient
>> ans =
>>
>> ? 3.1157e-01 ? 4.6628e-08 ? 1.2482e-15 ? 4.3526e-01 ? 6.0199e-02 ? 1.6613e-03
>>
>> ans =
>>
>> ? 2.9021e-01 ? 2.9620e-08 ? 3.5626e-16 ? 4.3474e-01 ? 4.5174e-02 ? 5.0746e-04
>>
>> so bfgsmin is finding the correct answer.
>>
>>
>> When dim is high, it makes sense to try lbfgs. Setting
>> control={10000,0,1,1,5} to use a memory of 5 iterations, the results
>> for dim=100 are
>>
>> octave:6> compare
>> 100/100
>> Results using analytic gradient
>> ans =
>>
>> ? 9.0097e-02 ? 1.1931e-06 ? 1.6012e-12 ? 4.3407e-01 ? 5.7046e-02 ? 1.5292e-03
>>
>> ans =
>>
>> ? 8.7479e-02 ? 3.4221e-07 ? 4.5890e-14 ? 4.3370e-01 ? 3.7205e-02 ? 3.5980e-04
>>
>> so lbfgs is considerably faster than bfgs.
>>
>> For setting up a bank of test problems, do you think that this test
>> script captures the important metrics: speed and accuracy? Anything
>> else to add? I may take the project on,
>>
>> Cheers, M.
>>
>
> Looking at the problem from a slightly different perspective, it now
> seems to me that taking the dogleg TR step selection method from
> fsolve may not have been that good idea as I thought initially. For
> fsolve, it shines because fsolve updates the model after each trial
> step, even an unsuccessful one. Uhm. Maybe a line search technique
> would be better. At least that would allow simply employing all three
> updating techniques in fminunc: BFGS, factored dual BFGS, and LBFGS.
>
> Btw., when I noticed that the rosenbrock function is actually a sum of
> squares, just for fun I tried rewriting the problem as a nonlinear
> least squares and feed it to fsolve. Doing thath, fsolve literally
> crushed the problem converging in 7 iterations (8 function and one
> jacobian evaluation).

I should have added; 7 iterations for dim = 100 :D


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


From lindnerben at gmx.net  Tue Sep  8 09:34:26 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 08 Sep 2009 16:34:26 +0200
Subject: changeset 9395 (3.2.x branch) should be applied not only x11
	term but on windows, wxt, ( and aqua) term
In-Reply-To: <20090907080447.76483.qmail@web3808.mail.bbt.yahoo.co.jp>
References: <20090907080447.76483.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <4AA66B72.80507@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> The changeset 9395 (3.2.x branch) makes mouse zoom in 2d in windows and wxt terminals impossible.
> 
> It should be applied to all view terminals (x11, winodws, wxt and perhaps aqua).
> At present I do not concern "qt" term.
> 
> Hello Ben Abbott  
> Please confirm  the changeset below is also applicable to the "aqua" term 
> 
> ****
> Hello Jaroslav and John
> 
> If Ben will give affirmative reply, please the attach the changeset to 3.2.x and development branch.
> 

Hmm, I tend to disagree.
With this patch we try fixing a hole in the cauldron by drilling 
additional holes.

I think it would be cleaner if the initial patch which supposedly fixes 
some behaviour for x11 (and only x11?) is repaired so that it only 
modifies behaviour for x11 and leaves the rest at status-quo.

Is the undesired behaviour of the x11 reminal really caused by octave's 
gnuplot backend? Or is it a gnuplot bug? If so, I think it would be 
better to fix it in gnuplot.

benjamin



From michael.creel at uab.es  Tue Sep  8 09:45:51 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 8 Sep 2009 16:45:51 +0200
Subject: Contribution to the optimization toolbox
In-Reply-To: <69d8d540909080720w61fb697cla4d74c73de2d8a3d@mail.gmail.com>
References: <8ea5036f0909031606x394b8517w13d8ed5188e6ee9f@mail.gmail.com>
	<c8f260e70909080411x6e51ea3dkd3bb17b42c927cd9@mail.gmail.com>
	<69d8d540909080720w61fb697cla4d74c73de2d8a3d@mail.gmail.com>
Message-ID: <c8f260e70909080745j4ed660f0u5db758f682f30415@mail.gmail.com>

On Tue, Sep 8, 2009 at 4:20 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>
> Looking at the problem from a slightly different perspective, it now
> seems to me that taking the dogleg TR step selection method from
> fsolve may not have been that good idea as I thought initially. For
> fsolve, it shines because fsolve updates the model after each trial
> step, even an unsuccessful one. Uhm. Maybe a line search technique
> would be better. At least that would allow simply employing all three
> updating techniques in fminunc: BFGS, factored dual BFGS, and LBFGS.
>
> Btw., when I noticed that the rosenbrock function is actually a sum of
> squares, just for fun I tried rewriting the problem as a nonlinear
> least squares and feed it to fsolve. Doing thath, fsolve literally
> crushed the problem converging in 7 iterations (8 function and one
> jacobian evaluation). But of course that is a different story; it
> exploits the structure of the problem.

Well, that's evidence that fsolve works well :-).

>
> Do you have any references for the line search used in bfgsmin?

I could come up with some - for example it must be in Gill, Murray and
Wright. It's just a Newton step by default, falling pack to bisection
if the Newton step fails. There are a lot of references for those
methods. I worked out the details of the implementation myself, by
experimentation. The Newton step is just based on a Taylor's series
approximation about a step of 1, and bisection just starts at 1 and
halves until an improvement is found, and then keeps going until the
benefits from continuing get small.. I put bounds on the Newton step
to avoid flying off into uncharted territory.

Michael

From godfrey at isl.stanford.edu  Tue Sep  8 09:45:51 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Tue, 08 Sep 2009 07:45:51 -0700
Subject: A backend("fltk") problem
In-Reply-To: <128f38bd0909080154k60669be1qd9586a73360396d0@mail.gmail.com>
References: <4A9749CF.6030708@isl.stanford.edu>	
	<19101.34310.961893.954083@segfault.lan>	
	<4A9D906A.8030606@isl.stanford.edu>	
	<19101.37238.710823.546142@segfault.lan>	
	<4A9D9C7B.9050101@isl.stanford.edu>	
	<19102.57857.878905.590704@segfault.lan>	
	<4A9EF679.8050205@isl.stanford.edu>	
	<420fb9e60909022046w78dd68e1xada0e42bd6a8e798@mail.gmail.com>	
	<4AA5E5A3.6090407@isl.stanford.edu>
	<128f38bd0909080154k60669be1qd9586a73360396d0@mail.gmail.com>
Message-ID: <4AA66E1F.8030107@isl.stanford.edu>

On 09/08/2009 01:54 AM, Michael Goffioul wrote:
> I strongly suggest that you have a look at JHandles use of gl2ps,
> which is what I planned to re-use in OpenGL renderer.
Thanks very much.  I will see what I can do.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090908/b947a6bd/attachment.html 

From tmacchant at yahoo.co.jp  Tue Sep  8 10:11:25 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 00:11:25 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <4AA66B72.80507@gmx.net>
Message-ID: <20090908151125.36223.qmail@web3806.mail.bbt.yahoo.co.jp>

Hello

--- Benjamin Lindner wrote:

> Hmm, I tend to disagree.
> With this patch we try fixing a hole in the cauldron by drilling 
> additional holes.
> 
> I think it would be cleaner if the initial patch which supposedly fixes 
> some behaviour for x11 (and only x11?) is repaired so that it only 
> modifies behaviour for x11 and leaves the rest at status-quo.

I confirmed the same issue occurs at not only x11 but also at windows, and wxt terminals. 
I do not know that this issue occurs at aqua terminal but I think this problem is not specific to x11
terminal but to all the screen terminals ('screen terminal means here one terminal on which a graph is
drawn in the graphic console but not to a file ').


> Is the undesired behaviour of the x11 reminal really caused by octave's 
> gnuplot backend? Or is it a gnuplot bug? If so, I think it would be 
> better to fix it in gnuplot.

Your opinion should be considered.  This issue clearly comes from the change between 3.0.x and 3.2.x. 
Therefore we should go back what is changed and why this change is implemented.
We should discern cooly what is a real origin of this problem.

Anyway we should  not seek an urgent and temporal answer on this issue.

Thanks!

Tatsuro

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

From bpabbott at mac.com  Tue Sep  8 10:17:39 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 08 Sep 2009 11:17:39 -0400
Subject: =?utf-8?Q?Re:_changeset_9395_=283.2.=EF=BD=98_branch=29_should_b?=
	=?utf-8?Q?e_applied_not_only_x11_term_but_on_windows,_wxt,_=28_a?=
	=?utf-8?Q?nd_aqua=29_term?=
In-Reply-To: <20090907080447.76483.qmail@web3808.mail.bbt.yahoo.co.jp>
References: <20090907080447.76483.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <39FB41CD-1456-4AE5-ACE4-4CE717F0CFCF@mac.com>

On Sep 7, 2009, at 4:04 AM, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>  
wrote:

> Hello
>
> The changeset 9395 (3.2.? branch) makes mouse zoom in 2d in windows  
> and wxt terminals impossible.
>
> It should be applied to all view terminals (x11, winodws, wxt and  
> perhaps aqua).
> At present I do not concern "qt" term.
>
> Hello Ben Abbott
> Please confirm  the changeset below is also applicable to the "aqua"  
> term
>
> ****
> Hello Jaroslav and John
>
> If Ben will give affirmative reply, please the attach the changeset  
> to 3.2.x and development branch.
>
> Regards
>
> Tatsuro

Gnuplot's "aqua" terminal doesn't support mouse zooming. So there is  
no need to include it.

Ben

From tmacchant at yahoo.co.jp  Tue Sep  8 10:27:31 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 00:27:31 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <4AA6682B.1000702@gmx.net>
Message-ID: <20090908152731.94079.qmail@web3807.mail.bbt.yahoo.co.jp>

Hello


--- Benjamin Lindner  wrote:

> For windows to even use the gnuplot backend one requires a true console 
> (i.e. pipeable) application, which is available since 
> CVS-4.3.0-2008-11-21 thanks to michael goffioul. The zooming feature if 
> data is piped into gnuplot requires a build with -DVOLATILE_REFRESH, 
> which is available IIRC for 4.3.0. So the available windows binaries 
> allow zooming.
> 
Mouse zooming in 2D plots is only available on gnuplot 4.3 at the ChangeLog date is 2007-08-31 for by
the extensive efforts by  Ethan Merritt.

2007-08-31  Ethan Merritt  <merritt at u.washington.edu>

	Version 2.9.? of Octave switched to piping all data to gnuplot in-line
	rather than via a temporary file.  This broke mouse zooming and replot.

	This patchset is an imperfect fix with several known problems:
	- Clipping of zoomed 3D contour plots is not correct.
	- splot volatile with image + zoom + unzoom is flaky
	- plot -> zoom -> set grid -> unzoom   loses the grid setting.
	- you cannot toggle log scaling on/off while using refresh.

	Introduce a new command "refresh" that acts like replot except that it
	does not re-read the input data.  Refresh is always needed in order to
	zoom or replot in-line data (input file '-'), but may optionally applied
	to normal data files also by appending the attribute 'volatile'.
              :
              :

Any version of gnuplot 4.2.x can realize the mouse zooming in 2D plot when the data are sent via pipe.

The gnuplot 4.2.6 is the last official version of 4.2.x.  The preparation of the next official release
gnuplot 4.4 has been started now.  Perhaps the mouse zooming for volatile data will be included in
version 4.4.  This should be confirmed at gnuplot-beta ML.

Regards

Tatsuro




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

From tmacchant at yahoo.co.jp  Tue Sep  8 10:37:32 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 00:37:32 +0900 (JST)
Subject: changeset 9395 (3.2.=?ISO-2022-JP?B?GyRCI3gbKEI=?= branch) should
	be applied not only x11 term but on windows, wxt, ( and aqua) term
In-Reply-To: <39FB41CD-1456-4AE5-ACE4-4CE717F0CFCF@mac.com>
Message-ID: <20090908153732.91206.qmail@web3810.mail.bbt.yahoo.co.jp>

Hello

We have to separate two issues.
1. The mouse zooming issue.
2. flickering x11, windows, wxt window seen with rapid gnuplot updates.

Does the second issue not occur on the aqua terminal ?

The attachment is used to confirm flickering screen for me.

Regards

Tatsuro  

--- Ben Abbott <bpabbott at mac.com> wrote:

> On Sep 7, 2009, at 4:04 AM, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>  
> wrote:
> 
> > Hello
> >
> > The changeset 9395 (3.2.? branch) makes mouse zoom in 2d in windows  
> > and wxt terminals impossible.
> >
> > It should be applied to all view terminals (x11, winodws, wxt and  
> > perhaps aqua).
> > At present I do not concern "qt" term.
> >
> > Hello Ben Abbott
> > Please confirm  the changeset below is also applicable to the "aqua"  
> > term
> >
> > ****
> > Hello Jaroslav and John
> >
> > If Ben will give affirmative reply, please the attach the changeset  
> > to 3.2.x and development branch.
> >
> > Regards
> >
> > Tatsuro
> 
> Gnuplot's "aqua" terminal doesn't support mouse zooming. So there is  
> no need to include it.
> 
> Ben


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exdiff.m
Type: application/octet-stream
Size: 1969 bytes
Desc: 3766810638-exdiff.m
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090909/987eb975/attachment-0001.obj 

From tmacchant at yahoo.co.jp  Tue Sep  8 10:39:10 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 00:39:10 +0900 (JST)
Subject: changeset 9395 (3.2.=?ISO-2022-JP?B?GyRCI3gbKEI=?= branch) should
	be applied not only x11 term but on windows, wxt, ( and aqua) term
In-Reply-To: <39FB41CD-1456-4AE5-ACE4-4CE717F0CFCF@mac.com>
Message-ID: <20090908153910.24783.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello

We have to separate two issues.
1. The mouse zooming issue.
2. flickering x11, windows, wxt window seen with rapid gnuplot updates.

Does the second issue not occur on the aqua terminal ?

The attachment is used to confirm flickering screen for me.

Regards

Tatsuro  

--- Ben Abbott <bpabbott at mac.com> wrote:

> On Sep 7, 2009, at 4:04 AM, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>  
> wrote:
> 
> > Hello
> >
> > The changeset 9395 (3.2.? branch) makes mouse zoom in 2d in windows  
> > and wxt terminals impossible.
> >
> > It should be applied to all view terminals (x11, winodws, wxt and  
> > perhaps aqua).
> > At present I do not concern "qt" term.
> >
> > Hello Ben Abbott
> > Please confirm  the changeset below is also applicable to the "aqua"  
> > term
> >
> > ****
> > Hello Jaroslav and John
> >
> > If Ben will give affirmative reply, please the attach the changeset  
> > to 3.2.x and development branch.
> >
> > Regards
> >
> > Tatsuro
> 
> Gnuplot's "aqua" terminal doesn't support mouse zooming. So there is  
> no need to include it.
> 
> Ben


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

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exdiff.m
Type: application/octet-stream
Size: 1969 bytes
Desc: 3766810638-exdiff.m
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090909/e051128a/attachment.obj 

From bpabbott at mac.com  Tue Sep  8 11:02:50 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 08 Sep 2009 12:02:50 -0400
Subject: =?UTF-8?Q?Re:_changeset_9395_(3.2.=EF=BD=98_branch)_should_be_applied_n?=
	=?UTF-8?Q?ot_only_x11_term_but_on_windows,_wxt,_(_and_aqua)_term?=
In-Reply-To: <67960100161429944272780614650311854769-Webmail@me.com>
References: <67960100161429944272780614650311854769-Webmail@me.com>
Message-ID: <162988337909795044824451184193067463824-Webmail@me.com>

On Tuesday, September 08, 2009, at 11:37AM, "Tatsuro MATSUOKA" <tmacchant at yahoo.co.jp> wrote:
>Hello
>
>We have to separate two issues.
>1. The mouse zooming issue.
>2. flickering x11, windows, wxt window seen with rapid gnuplot updates.
>
>Does the second issue not occur on the aqua terminal ?
>
>The attachment is used to confirm flickering screen for me.
>
>Regards
>
>Tatsuro 

When using "aqua", your patch does not have any effect for me.

Ben


From tmacchant at yahoo.co.jp  Tue Sep  8 12:25:00 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 02:25:00 +0900 (JST)
Subject: changeset 9395 (3.2.=?ISO-2022-JP?B?GyRCI3gbKEI=?= branch) should
	be applied not only x11 term but on windows, wxt, ( and aqua) term
In-Reply-To: <162988337909795044824451184193067463824-Webmail@me.com>
Message-ID: <20090908172500.11588.qmail@web3810.mail.bbt.yahoo.co.jp>

Hello

--- Ben Abbott  wrote:

> On Tuesday, September 08, 2009, at 11:37AM, "Tatsuro MATSUOKA" <tmacchant at yahoo.co.jp> wrote:
> >Hello
> >
> >We have to separate two issues.
> >1. The mouse zooming issue.
> >2. flickering x11, windows, wxt window seen with rapid gnuplot updates.
> >
> >Does the second issue not occur on the aqua terminal ?
> >
> >The attachment is used to confirm flickering screen for me.
> >
> >Regards
> >
> >Tatsuro 
> 
> When using "aqua", your patch does not have any effect for me.

Thank you for your information.  We have to looking around the code change between 3.0 and 3.2.

Regards

Tatsuro

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

From jwe at octave.org  Tue Sep  8 12:28:52 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 8 Sep 2009 13:28:52 -0400
Subject: fltk
In-Reply-To: <4AA3F9BC.7010709@isl.stanford.edu>
References: <4AA2EC30.5060009@isl.stanford.edu>
	<19106.60818.604699.94352@segfault.lan>
	<4AA2F032.9070303@isl.stanford.edu>
	<19107.2676.390066.31797@segfault.lan>
	<4AA31B55.9070304@isl.stanford.edu>
	<19107.14787.360427.249871@segfault.lan>
	<4AA3F9BC.7010709@isl.stanford.edu>
Message-ID: <19110.37972.523694.409343@segfault.lan>

On  6-Sep-2009, Michael D Godfrey wrote:

| Without the backend("fltk") I tried commands like:
| 
|   plot([1:100])
| title("hello again")
| get(gca,"fontname")
| h = get (gca (),"title")
| get (0, "defaulttextfontname")
| set(h, "string", "more news")
| set(h, "fontname", "Helvetica")
| get (0, "defaulttextfontname")
| 
| They all worked as expected.  So, at least part of the
| problem is due to differences in font property handling
| between fltk and gnuplot.  It would seem to me that the
| property handling should be the same (even same code)
| for both.  Is this true?
| 
| Also, commands like set(h, "fontsize", 10) work correctly
| in both gnuplot and fltk.  It seems to be only the fontname
| property that goes wrong in fltk.

The difference is that for gnuplot, we just pass the name of the font
to gnuplot in commands, like

  set title "foobar" font "Times,14" enhanced;

and then gnuplot finds and displays the font.

But as I understand things, the fltk/opengl backend requires us to
find the font ourselves (we are using fontconfig for this) and then
tell fltk which font to use.

I don't know how gnuplot does this job.  Is it using fontconfig?

In any case, it may be that we are simply using fontconfig
incorrectly.  If someone out there is an expert, I would be grateful
for some help in fixing these problems.

jwe

From jwe at octave.org  Tue Sep  8 12:35:30 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 8 Sep 2009 13:35:30 -0400
Subject: fltk and fonts
Message-ID: <19110.38370.312872.666870@segfault.lan>

On  5-Sep-2009, Michael D Godfrey wrote:

| >
| > What do the following return on your system?
| >
| >    get (0, "defaultaxesfontname")
| >    get (0, "defaulttextfontname")
| >
| >    
| octave:1> get (0, "defaultaxesfontname")
| ans = *
| octave:2> get (0, "defaulttextfontname")
| ans = *
| ==================================
| What do you get for these?

"*" is the default, which for Octave means "use the default font".
As you noted in another message, Matlab uses "Helvetica", but that
seems to cause more trouble since many people do not have Helvetica
and we would have to substitute anyway.

Ugh.  I don't want to have to think about all these details.
Something like fontconfig should handle it for us.

| Odd. I just clicked on the link in your email and the expected page came
| up.  Maybe try a Google search on:
| Shipping fonts in Fedora (FAQ)
| which is the title of the page.

OK, I looked at that page, but it seems like advice for people who
want to create packages containing fonts.

I guess what I'm leaning toward now is not including any fonts in
Octave.  Instead we should require fontconfig, and assume that it is
set up to do the right thing.  I'm not sure what configure changes
will be needed.  For binary packages, I think it is up to the packager
to get the dependencies right for the given system (debian, fedora,
windows, whatever).

jwe

From tmacchant at yahoo.co.jp  Tue Sep  8 18:28:58 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 08:28:58 +0900 (JST)
Subject: changeset 9395 (3.2.=?ISO-2022-JP?B?GyRCI3gbKEI=?= branch) should
	be applied not only x11 term buton windows, wxt, ( and aqua) term
In-Reply-To: <20090908153732.91206.qmail@web3810.mail.bbt.yahoo.co.jp>
Message-ID: <20090908232858.16533.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello

A simple code to  flickering graph window (x11, windows, wxt) seen with rapid gnuplot updates is:
.
for i=1:5 ; fplot ("cos", [0, 2*pi]); drawnow; end

This flicking confirmed at octave 3.2.x before octave-3.2.2 on x11, winodows and wxt.

I used for x11 term on octave 3.2.2 on cygwin and for windows and wxt terminals octave 3.2.2 on mingw.

(console mode of gnuplot for windows with wxt terminal was used one bundled with octave-3.0.3 MSVC. ) 

Regards

Tatsuro

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

From tmacchant at yahoo.co.jp  Tue Sep  8 18:28:59 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 08:28:59 +0900 (JST)
Subject: changeset 9395 (3.2.=?ISO-2022-JP?B?GyRCI3gbKEI=?= branch) should
	be applied not only x11 term buton windows, wxt, ( and aqua) term
In-Reply-To: <20090908153732.91206.qmail@web3810.mail.bbt.yahoo.co.jp>
Message-ID: <20090908232859.84136.qmail@web3801.mail.bbt.yahoo.co.jp>

Hello

A simple code to  flickering graph window (x11, windows, wxt) seen with rapid gnuplot updates is:
.
for i=1:5 ; fplot ("cos", [0, 2*pi]); drawnow; end
This flicking confirmed at octave 3.2.x before octave-3.2.2 on x11, winodows and wxt.

I used for x11 term on octave 3.2.2 on cygwin and for windows and wxt terminals octave 3.2.2 on mingw.

(console mode of gnuplot for windows with wxt terminal was used one bundled with octave-3.0.3 MSVC. ) 

Regards

Tatsuro

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

From dasergatskov at gmail.com  Tue Sep  8 18:49:11 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 8 Sep 2009 18:49:11 -0500
Subject: =?UTF-8?Q?Re=3A_changeset_9395_=283=2E2=2E=EF=BD=98_branch=29_should_be_applie?=
	=?UTF-8?Q?d_not_only_x11_term_buton_windows=2C_wxt=2C_=28_and_aqua=29_term?=
In-Reply-To: <20090908232858.16533.qmail@web3802.mail.bbt.yahoo.co.jp>
References: <20090908153732.91206.qmail@web3810.mail.bbt.yahoo.co.jp>
	<20090908232858.16533.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <892b16670909081649o4173cc47u733eca429963b16f@mail.gmail.com>

2009/9/8 Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>:
> Hello
>
> A simple code to ?flickering graph window (x11, windows, wxt) seen with rapid gnuplot updates is:
> .
> for i=1:5 ; fplot ("cos", [0, 2*pi]); drawnow; end
>
> This flicking confirmed at octave 3.2.x before octave-3.2.2 on x11, winodows and wxt.
>
> I used for x11 term on octave 3.2.2 on cygwin and for windows and wxt terminals octave 3.2.2 on mingw.
>
> (console mode of gnuplot for windows with wxt terminal was used one bundled with octave-3.0.3 MSVC. )
>

On x86_64 linux, octave  3.2.3rc2, and 4.3 cvs gnuplot I see
flickering of the plot with wxt terminal.
With X11 terminal, the plot itself is steady, but the window
decoration bar has flickering sign
Figure 1 -> Figure 1 applying (or acquiring?) colors... --> Figure 1

> Regards
>
> Tatsuro
>

Sincerely,

Dmitri.
--


From godfrey at isl.stanford.edu  Tue Sep  8 14:03:24 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Tue, 08 Sep 2009 12:03:24 -0700
Subject: fltk and fonts
In-Reply-To: <19110.38370.312872.666870@segfault.lan>
References: <19110.38370.312872.666870@segfault.lan>
Message-ID: <4AA6AA7C.10605@isl.stanford.edu>

On 09/08/2009 10:35 AM, John W. Eaton wrote:
> I guess what I'm leaning toward now is not including any fonts in
> Octave.  Instead we should require fontconfig, and assume that it is
> set up to do the right thing.
This seems to be the right choice.  The font story is a
slippery slope.  A point of fontconfig is to isolate applications
from at least some of the headaches.  It should also reduce
the burden of adapting to future changes.

It does appear that the gnuplot code passes through font
information, but it also does something with fonts because
I sometimes get font error messages from it.  This is happening
now, for instance.
> For binary packages, I think it is up to the packager
> to get the dependencies right for the given system (debian, fedora,
> windows, whatever).
>    
Anyhow, this is the right place for such dependencies.



From dasergatskov at gmail.com  Tue Sep  8 23:29:41 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Tue, 8 Sep 2009 23:29:41 -0500
Subject: fltk and fonts
In-Reply-To: <4AA6AA7C.10605@isl.stanford.edu>
References: <19110.38370.312872.666870@segfault.lan>
	<4AA6AA7C.10605@isl.stanford.edu>
Message-ID: <892b16670909082129s46a56b29q47a4e1f18361db8c@mail.gmail.com>

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

>
> It does appear that the gnuplot code passes through font
> information, but it also does something with fonts because
> I sometimes get font error messages from it. ?This is happening
> now, for instance.

With gnuplot situation is even worth since different gnuplot terminals
handle fonts differently. In particular X11 terminal does not use fontconfig
as far as I know.
But I am pleased with recent development of cairo based terminals
(pngcairo, pdfcairo, wxt) -- they seem to provide somewhat unified
look.

Dmitri.
--


From tmacchant at yahoo.co.jp  Tue Sep  8 17:55:51 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 07:55:51 +0900 (JST)
Subject: changeset 9395 (3.2.=?ISO-2022-JP?B?GyRCI3gbKEI=?= branch)
	should
	be applied not only x11 term but on windows, wxt, ( and aqua) term
In-Reply-To: <157573672043455368206689525655677601739-Webmail@me.com>
Message-ID: <20090908225551.18128.qmail@web3801.mail.bbt.yahoo.co.jp>

Hello

--- Ben Abbott  wrote:

> I should have also mentioned that there is no zooming when using the aqua terminal, and the
> flickering problem is not present either. I suspect the latter is because gnuplot has very
> limited control over the aqua windows. 

Thank you for your information.

Regards.

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

From tmacchant at yahoo.co.jp  Wed Sep  9 00:53:37 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 14:53:37 +0900 (JST)
Subject: 3.2.3 RC2
In-Reply-To: <20090908152731.94079.qmail@web3807.mail.bbt.yahoo.co.jp>
Message-ID: <20090909055338.41353.qmail@web3811.mail.bbt.yahoo.co.jp>

Hello

--- Tatsuro MATSUOKA  wrote:

> The gnuplot 4.2.6 is the last official version of 4.2.x.  The preparation of the next official
> release
> gnuplot 4.4 has been started now.  Perhaps the mouse zooming for volatile data will be included
> in
> version 4.4.  This should be confirmed at gnuplot-beta ML.
> 

I have confirmed.
See:

http://www.nabble.com/Re%3A-Will-%22Volatile-Data%22-in-gnuplot-4.3-(CVS)-be-planned-to-be-implemented-in-the-next-major-release-%3A-Ver-4.4.x---p25356873.html

Regards

Tatsuro


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

From thomas.weber.mail at gmail.com  Wed Sep  9 01:53:33 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Wed, 9 Sep 2009 08:53:33 +0200
Subject: development snapshot
In-Reply-To: <69d8d540909080056w6a06f425scb2d77ac9ef23d4a@mail.gmail.com>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
	<a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
	<69d8d540909080056w6a06f425scb2d77ac9ef23d4a@mail.gmail.com>
Message-ID: <20090909065333.GA8939@atlan>

Guys, 

may I kindly ask you to shut up NOW! 

Discussing patents on a public mailing list that is archived all around
the globe is plain stupid. 

For the reasons why, see Q2 in 
http://lkml.indiana.edu/hypermail/linux/kernel/0906.3/01501.html

This is the legal system, neither research nor development. Different
system, different rules.

If you want to continue, kick the list from the CC.

	Thomas



From tmacchant at yahoo.co.jp  Wed Sep  9 02:18:48 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 16:18:48 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <4AA66B72.80507@gmx.net>
Message-ID: <20090909071848.92702.qmail@web3804.mail.bbt.yahoo.co.jp>

Hello

--- Benjamin Lindner wrote:

> Hmm, I tend to disagree.
> With this patch we try fixing a hole in the cauldron by drilling 
> additional holes.
> 
> I think it would be cleaner if the initial patch which supposedly fixes 
> some behaviour for x11 (and only x11?) is repaired so that it only 
> modifies behaviour for x11 and leaves the rest at status-quo.
> 
> Is the undesired behaviour of the x11 reminal really caused by octave's 
> gnuplot backend? Or is it a gnuplot bug? If so, I think it would be 
> better to fix it in gnuplot.



fplot ("cos", [0, 2*pi])
drawnow("windows", "foo.txt", 9, "debug.txt") 

and see the debug.txt
Expiations attachment file are
debug_305.txt -- case octave 3.0.5/mingw
debug_322.txt -- case octave 3.2.2/mingw
debug_323_modifiedBenPatch.txt -- case octave 3.2.3/mingw with modified Ben's patch to windows
terminal

I add 'pause 2' to see  like 
cat debug_305.txt | gnuplot

For the case of debug_322.txt, screnn cleared and plot was carried out.
The above is cause of flicking.

This was caused by 'set multiplot;' at line 7 in debug_322.txt.

This bug caused by octave but not by gnuplot!!

Regards

Tatsuro

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

From bpabbott at mac.com  Tue Sep  8 14:05:58 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 08 Sep 2009 15:05:58 -0400
Subject: =?UTF-8?Q?Re:__Re:_changeset_9395_(3.2?=
	=?UTF-8?Q?.=EF=BD=98_branch)_should_be_applied?=
	=?UTF-8?Q?_not_only_x11_term_but_on_windows,_wxt,_(_and_aqua)_term?=
In-Reply-To: <162988337909795044824451184193067463824-Webmail@me.com>
References: <67960100161429944272780614650311854769-Webmail@me.com>
	<162988337909795044824451184193067463824-Webmail@me.com>
Message-ID: <157573672043455368206689525655677601739-Webmail@me.com>

On Tuesday, September 08, 2009, at 12:02PM, "Ben Abbott" <bpabbott at mac.com> wrote:
>On Tuesday, September 08, 2009, at 11:37AM, "Tatsuro MATSUOKA" <tmacchant at yahoo.co.jp> wrote:
>>Hello
>>
>>We have to separate two issues.
>>1. The mouse zooming issue.
>>2. flickering x11, windows, wxt window seen with rapid gnuplot updates.
>>
>>Does the second issue not occur on the aqua terminal ?
>>
>>The attachment is used to confirm flickering screen for me.
>>
>>Regards
>>
>>Tatsuro 
>
>When using "aqua", your patch does not have any effect for me.
>
>Ben
>

I should have also mentioned that there is no zooming when using the aqua terminal, and the flickering problem is not present either. I suspect the latter is because gnuplot has very limited control over the aqua windows. 

Ben



From tmacchant at yahoo.co.jp  Wed Sep  9 02:28:49 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 16:28:49 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <20090909071848.92702.qmail@web3804.mail.bbt.yahoo.co.jp>
Message-ID: <20090909072849.76647.qmail@web3810.mail.bbt.yahoo.co.jp>

Sorry I have fogotten to attach a file. 

Here I send it

Regards

Tatsuro
--- Tatsuro MATSUOKA <tmacchant at yahoo.co.jp> wrote:

> Hello
> 
> --- Benjamin Lindner wrote:
> 
> > Hmm, I tend to disagree.
> > With this patch we try fixing a hole in the cauldron by drilling 
> > additional holes.
> > 
> > I think it would be cleaner if the initial patch which supposedly fixes 
> > some behaviour for x11 (and only x11?) is repaired so that it only 
> > modifies behaviour for x11 and leaves the rest at status-quo.
> > 
> > Is the undesired behaviour of the x11 reminal really caused by octave's 
> > gnuplot backend? Or is it a gnuplot bug? If so, I think it would be 
> > better to fix it in gnuplot.
> 
> 
> 
> fplot ("cos", [0, 2*pi])
> drawnow("windows", "foo.txt", 9, "debug.txt") 
> 
> and see the debug.txt
> Expiations attachment file are
> debug_305.txt -- case octave 3.0.5/mingw
> debug_322.txt -- case octave 3.2.2/mingw
> debug_323_modifiedBenPatch.txt -- case octave 3.2.3/mingw with modified Ben's patch to windows
> terminal
> 
> I add 'pause 2' to see  like 
> cat debug_305.txt | gnuplot
> 
> For the case of debug_322.txt, screnn cleared and plot was carried out.
> The above is cause of flicking.
> 
> This was caused by 'set multiplot;' at line 7 in debug_322.txt.
> 
> This bug caused by octave but not by gnuplot!!
> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.txt.zip
Type: application/x-unknown
Size: 5629 bytes
Desc: 2543241385-debug.txt.zip
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090909/286e1679/attachment.bin 

From tmacchant at yahoo.co.jp  Wed Sep  9 03:41:21 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 9 Sep 2009 17:41:21 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <20090909072849.76647.qmail@web3810.mail.bbt.yahoo.co.jp>
Message-ID: <20090909084121.38838.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello

I the previous post it is revealed that mouse zooming disabling issue and flickering graphic window
seen with rapid gnuplot updates on the windows and wxt terminal in principle are the same of that for
x11 terminal.  The problems are caused by newly implemented code of octave 3.2 but not gnuplot.

For the case of 'aqua' term, the Ben's modification does not need to be applied.

So I would like to submit a changeset to apply Ben's modification for x11 terminal also 
to the windows and wxt terminals.

Regards

Tatsuro
  
# User Tatsu at Shiro
# Date 1252484905 -32400
# Node ID 01c05ed43f1362ce3ba0dacef8ceff6d03dffb74
# Parent  796c26e4af4709c9b35d454ea634573f13cabfaf
 Enter commit message.  Lines beginning with 'HG:' are removed.
 Leave message empty to abort commit.
 --
 user: Tasuro Matsuoka
 branch 'default'
changed scripts/plot/gnuplot_drawnow.m

diff -r 796c26e4af47 -r 01c05ed43f13 scripts/plot/gnuplot_drawnow.m
--- a/scripts/plot/gnuplot_drawnow.m    Mon Sep 07 08:01:41 2009 +0200
+++ b/scripts/plot/gnuplot_drawnow.m    Wed Sep 09 17:28:25 2009 +0900
@@ -286,10 +286,10 @@
       ## the canvas size for terminals cdr/corel.
       term_str = sprintf ("%s %s", term_str, size_str);
     endif
-    ## Work around the gnuplot feature of growing the x11 window when
-    ## the mouse and multiplot are set.
+    ## Work around the gnuplot feature of growing the window of 
+    ## x11, windows, and wxt terminals when the mouse and multiplot are set.
     fputs (plot_stream, "unset multiplot;\n");
-    if (! strcmp (term, "x11")
+    if (! index("x11 windows wxt",term)
         || numel (findall (h, "type", "axes")) > 1
         || numel (findall (h, "type", "image")) > 0)
       fprintf (plot_stream, "%s\n", term_str);
@@ -299,7 +299,7 @@
         endif
       endif
       fputs (plot_stream, "set multiplot;\n");
-    elseif (strcmp (term, "x11"))
+    elseif (index("x11 windows wxt",term))
       fprintf (plot_stream, "%s\n", term_str);
       if (nargin == 5)
         if (! isempty (file))


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

From bpabbott at mac.com  Wed Sep  9 06:47:03 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 09 Sep 2009 07:47:03 -0400
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <20090909071848.92702.qmail@web3804.mail.bbt.yahoo.co.jp>
References: <20090909071848.92702.qmail@web3804.mail.bbt.yahoo.co.jp>
Message-ID: <F699472C-E63C-4EA8-B8EC-43E9DB088FA8@mac.com>


On Sep 9, 2009, at 3:18 AM, Tatsuro MATSUOKA wrote:

> Hello
>
> --- Benjamin Lindner wrote:
>
>> Hmm, I tend to disagree.
>> With this patch we try fixing a hole in the cauldron by drilling
>> additional holes.
>>
>> I think it would be cleaner if the initial patch which supposedly  
>> fixes
>> some behaviour for x11 (and only x11?) is repaired so that it only
>> modifies behaviour for x11 and leaves the rest at status-quo.
>>
>> Is the undesired behaviour of the x11 reminal really caused by  
>> octave's
>> gnuplot backend? Or is it a gnuplot bug? If so, I think it would be
>> better to fix it in gnuplot.
>
> fplot ("cos", [0, 2*pi])
> drawnow("windows", "foo.txt", 9, "debug.txt")
>
> and see the debug.txt
> Expiations attachment file are
> debug_305.txt -- case octave 3.0.5/mingw
> debug_322.txt -- case octave 3.2.2/mingw
> debug_323_modifiedBenPatch.txt -- case octave 3.2.3/mingw with  
> modified Ben's patch to windows
> terminal
>
> I add 'pause 2' to see  like
> cat debug_305.txt | gnuplot
>
> For the case of debug_322.txt, screnn cleared and plot was carried  
> out.
> The above is cause of flicking.
>
> This was caused by 'set multiplot;' at line 7 in debug_322.txt.
>
> This bug caused by octave but not by gnuplot!!
>
> Regards
>
> Tatsuro

I had come to the same conclusion. The flickering is caused by set/ 
unset multiplot.

It *may* be possible that this can be fixed in gnuplot and I'm willing  
to file a bug report with the gnuplot developers, but thus far I've  
not be able to produce a simple script to demonstrate the behavior.

However, I favor applying Tatsuro's patch as it will have no negative  
impact and will eliminate the flickering for current releases of  
gnuplot. When/if the problem is fixed in a future version of gnuplot,  
the function __gnuplot_has_feature__ may be modified and used to  
produce the desired results for different versions of gnuplot.

Ben


From tmacchant at yahoo.co.jp  Wed Sep  9 18:07:00 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 10 Sep 2009 08:07:00 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <F699472C-E63C-4EA8-B8EC-43E9DB088FA8@mac.com>
Message-ID: <20090909230704.8334.qmail@web3809.mail.bbt.yahoo.co.jp>

Hello

--- Ben Abbott wrote:

> I had come to the same conclusion. The flickering is caused by set/ 
> unset multiplot.
> 
> It *may* be possible that this can be fixed in gnuplot and I'm willing  
> to file a bug report with the gnuplot developers, but thus far I've  
> not be able to produce a simple script to demonstrate the behavior.
> 
> However, I favor applying Tatsuro's patch as it will have no negative  
> impact and will eliminate the flickering for current releases of  
> gnuplot. When/if the problem is fixed in a future version of gnuplot,  
> the function __gnuplot_has_feature__ may be modified and used to  
> produce the desired results for different versions of gnuplot.

Thank you for your detailed comment.  I can understand what is problem.
It will be grate if the problem will be solved by fixing gnuplot.

However, thinking about the gnuplot distribution style on various platform, all users cannot always  
use the most recent gnuplot (perhaps cvs release). Therefore the patch  proposed by Ben for x11 and
the extension of it to windows and wxt terminal by me will can be accepted as a temporal
patch.  Perhaps the fix of gnuplot will be included in the next major official release of gnuplot of
ver. 4.4, the patches can be deleted.

Regards

Tatsuro 


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

From bpabbott at mac.com  Wed Sep  9 18:45:10 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 09 Sep 2009 19:45:10 -0400
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <20090909230704.8334.qmail@web3809.mail.bbt.yahoo.co.jp>
References: <20090909230704.8334.qmail@web3809.mail.bbt.yahoo.co.jp>
Message-ID: <0918952E-8480-480B-8A09-C27EB5BEDAE7@mac.com>


On Sep 9, 2009, at 7:07 PM, Tatsuro MATSUOKA wrote:

> Hello
>
> --- Ben Abbott wrote:
>
>> I had come to the same conclusion. The flickering is caused by set/
>> unset multiplot.
>>
>> It *may* be possible that this can be fixed in gnuplot and I'm  
>> willing
>> to file a bug report with the gnuplot developers, but thus far I've
>> not be able to produce a simple script to demonstrate the behavior.
>>
>> However, I favor applying Tatsuro's patch as it will have no negative
>> impact and will eliminate the flickering for current releases of
>> gnuplot. When/if the problem is fixed in a future version of gnuplot,
>> the function __gnuplot_has_feature__ may be modified and used to
>> produce the desired results for different versions of gnuplot.
>
> Thank you for your detailed comment.  I can understand what is  
> problem.
> It will be grate if the problem will be solved by fixing gnuplot.
>
> However, thinking about the gnuplot distribution style on various  
> platform, all users cannot always
> use the most recent gnuplot (perhaps cvs release). Therefore the  
> patch  proposed by Ben for x11 and
> the extension of it to windows and wxt terminal by me will can be  
> accepted as a temporal
> patch.  Perhaps the fix of gnuplot will be included in the next  
> major official release of gnuplot of
> ver. 4.4, the patches can be deleted.
>
> Regards
>
> Tatsuro

Tatsuro,

I'm unable to apply your changeset (due to EOL characters I think). Is  
the attached one ok?

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset.patch
Type: application/octet-stream
Size: 1986 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090909/2251d1aa/attachment.obj 
-------------- next part --------------





From tmacchant at yahoo.co.jp  Wed Sep  9 19:23:56 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 10 Sep 2009 09:23:56 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <0918952E-8480-480B-8A09-C27EB5BEDAE7@mac.com>
Message-ID: <20090910002356.14928.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello Ben

--- Ben Abbott wrote:

> Tatsuro,
> 
> I'm unable to apply your changeset (due to EOL characters I think). Is  
> the attached one ok?

Sorry it should be sent it as an attachment file.
Anyway I have confirmed your patch works on windows and wxt terminals.

Thanks!!

Tatsuro

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

From tmacchant at yahoo.co.jp  Thu Sep 10 05:29:28 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 10 Sep 2009 19:29:28 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <20090910002356.14928.qmail@web3814.mail.bbt.yahoo.co.jp>
Message-ID: <20090910102928.590.qmail@web3813.mail.bbt.yahoo.co.jp>

Hello Jaroslav and John

--- Tatsuro MATSUOKA wrote:

> Hello Ben
> 
> --- Ben Abbott wrote:
> 
> > Tatsuro,
> > 
> > I'm unable to apply your changeset (due to EOL characters I think). Is  
> > the attached one ok?
> 
> Sorry it should be sent it as an attachment file.
> Anyway I have confirmed your patch works on windows and wxt terminals.
> 
> Thanks!!

Please apply Ben's changeset posted to maintainers list on Sep 10, 2009; 08:45am (JST) to relead 3.2.x
repository. 

This patch is temporal until gnuplot 4.4 released. I think that the application of the patch to the
development branch is left to John's judgement.

Regards

Tatsuro


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

From bpabbott at mac.com  Thu Sep 10 07:04:51 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Thu, 10 Sep 2009 08:04:51 -0400
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <20090910102928.590.qmail@web3813.mail.bbt.yahoo.co.jp>
References: <20090910102928.590.qmail@web3813.mail.bbt.yahoo.co.jp>
Message-ID: <AEA083F4-2A8C-4247-9B8B-C94E188B1F0C@mac.com>


On Sep 10, 2009, at 6:29 AM, Tatsuro MATSUOKA wrote:

> Hello Jaroslav and John
>
> --- Tatsuro MATSUOKA wrote:
>
>> Hello Ben
>>
>> --- Ben Abbott wrote:
>>
>>> Tatsuro,
>>>
>>> I'm unable to apply your changeset (due to EOL characters I  
>>> think). Is
>>> the attached one ok?
>>
>> Sorry it should be sent it as an attachment file.
>> Anyway I have confirmed your patch works on windows and wxt  
>> terminals.
>>
>> Thanks!!
>
> Please apply Ben's changeset posted to maintainers list on Sep 10,  
> 2009; 08:45am (JST) to relead 3.2.x
> repository.
>
> This patch is temporal until gnuplot 4.4 released. I think that the  
> application of the patch to the
> development branch is left to John's judgement.
>
> Regards
>
> Tatsuro

I've just pushed it.

Ben


From tmacchant at yahoo.co.jp  Thu Sep 10 22:03:23 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Fri, 11 Sep 2009 12:03:23 +0900 (JST)
Subject: changeset 9395 (3.2.x branch) should be applied not only x11 term
	but on windows, wxt, ( and aqua) term
In-Reply-To: <AEA083F4-2A8C-4247-9B8B-C94E188B1F0C@mac.com>
Message-ID: <20090911030323.59743.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello Ben or Jaroslav

--- Ben Abbott wrote:
> I've just pushed it.

I have confirmed at the development branch. 
Thanks!!

However, at the 3.2.x branch, I could not find the changeset. Is this merely delay of the system? If
it is not pushed, please push it also to the 3.2.x branch.

Regards

Tatsuro




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

From godfrey at isl.stanford.edu  Fri Sep 11 22:00:10 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Fri, 11 Sep 2009 20:00:10 -0700
Subject: fontconfig failure on Fedora x86_64 systems
Message-ID: <4AAB0EBA.8010306@isl.stanford.edu>

John,

I found:
http://www.khngai.com/tools/man/index.php/man/fonts-conf/5

which describes how to debug fontconfig problems.
I tried following the instructions, using settings like:
setenv FC_DEBUG 1

This seems to show that many candidate fonts are found, but all
are rejected.  The ft_manager routine in txt-eng-ft.cc is
where the problem exists.  I will look some more to try to determine
the problem, but there is a lot that I do not know about  fontconfig...

If anyone has a good idea...

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090911/98971740/attachment.html 

From jwe at octave.org  Fri Sep 11 22:11:20 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 11 Sep 2009 23:11:20 -0400
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <4AAB0EBA.8010306@isl.stanford.edu>
References: <4AAB0EBA.8010306@isl.stanford.edu>
Message-ID: <19115.4440.379746.112915@segfault.lan>

On 11-Sep-2009, Michael D Godfrey wrote:

| I found:
| http://www.khngai.com/tools/man/index.php/man/fonts-conf/5
| 
| which describes how to debug fontconfig problems.
| I tried following the instructions, using settings like:
| setenv FC_DEBUG 1
| 
| This seems to show that many candidate fonts are found, but all
| are rejected.  The ft_manager routine in txt-eng-ft.cc is
| where the problem exists.  I will look some more to try to determine
| the problem, but there is a lot that I do not know about  fontconfig...

When I try starting the current development version of Octave with
FC_DEBUG=1 and execute the commands

octave:1> backend ('fltk')
octave:2> title ("foobar", "fontname", "surelythisisnotafontname")

I see the following output, which apparently shows that Bitstream Vera
Sans was selected as the default font even though I specified a
fontname that is not valid.  What do you see?


FC_DEBUG=1
FC_DEBUG=1
Match Pattern has 23 elts (size 32)
	family: "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "WenQuanYi Zen Hei"(w) "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w) "Helvetica"(w) "Lucida Sans Unicode"(w) "BPG Glaho International"(w) "Tahoma"(w) "Nachlieli"(w) "Lucida Sans Unicode"(w) "Yudit Unicode"(w) "Kerkis"(w) "ArmNet Helvetica"(w) "Artsounk"(w) "BPG UTF8 M"(w) "Norasi"(w) "Saysettha Unicode"(w) "JG Lao Old Arial"(w) "GF Zemen Unicode"(w) "Pigiarniq"(w) "B Davat"(w) "B Compset"(w) "Kacst-Qr"(w) "Urdu Nastaliq Unicode"(w) "Raghindi"(w) "Mukti Narrow"(w) "malayalam"(w) "Sampige"(w) "padmaa"(w) "Hapax Berb$,3u=u=(Bre"(w) "MS Gothic"(w) "UmePlus P Gothic"(w) "SimSun"(w) "PMingLiu"(w) "AR PL ShanHeiSun Uni"(w) "AR PL New Sung"(w) "MgOpen Modata"(w) "VL Gothic"(w) "IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) "AR PL KaitiM Big5"(w) "AR PL ShanHeiSun Uni"(w) "AR PL SungtiL GB"(w) "AR PL Mingti2L Big5"(w) "$,3u=u=u=u=u=u=(B $,3u=u=u=u=u=u=u=u=u=u=u=u=(B"(w) "ZYSong18030"(w) "TSCu_Paranar"(w) "UnDotum"(w) "Baekmuk Dotum"(w) "Baekmuk Gulim"(w) "KacstQura"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w) "Lohit Hindi"(w) "Lohit Punjabi"(w) "Lohit Tamil"(w) "Lohit Malayalam"(w) "Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) "LKLUG"(w) "FreeSans"(w) "Arial Unicode MS"(w) "Arial Unicode"(w) "Code2000"(w) "Code2001"(w) "lohit_bn"(w) "lohit_as"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Rekha"(w) "Kedage-n"(w) "Meera"(w) "utkal"(w) "Saab"(w) "TAMu_Kalyani"(w) "Pothana2000"(w) "sans-serif"(w) "Roya"(w) "Koodak"(w) "Terafik"(w) "Bitstream-Vera-Sans"(w) "sans-serif"(w)
	slant: 0(i)(s)
	weight: 100(i)(s)
	width: 100(i)(s)
	pixelsize: 14(f)(s)
	antialias: FcTrue(s)
	hintstyle: 3(i)(s)
	hinting: FcTrue(s)
	verticallayout: FcFalse(s)
	autohint: FcFalse(s)
	globaladvance: FcTrue(s)
	dpi: 94(f)(s)
	rgba: 5(i)(s)
	scale: 1(f)(s)
	minspace: FcFalse(s)
	lang: "C"(s)
	fontversion: 2147483647(i)(s)
	embolden: FcFalse(s)
	embeddedbitmap: FcTrue(s)
	decorative: FcFalse(s)
	encoding: "iso8859-1"(s)
	render: FcTrue(s)
	maxglyphmemory: 1048576(i)(s)

Best score 0 0 1e+99 200 0 0 0 0 0 2000 0 0 0 0 0 2.14735e+11Pattern has 19 elts (size 19)
	family: "Bitstream Vera Sans"(w)
	familylang: "en"(w)
	style: "Roman"(w)
	stylelang: "en"(w)
	fullname: "Bitstream Vera Sans"(w)
	fullnamelang: "en"(w)
	slant: 0(i)(w)
	weight: 80(i)(w)
	width: 100(i)(w)
	foundry: "bitstream"(w)
	file: "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf"(w)
	index: 0(i)(w)
	outline: FcTrue(w)
	scalable: FcTrue(w)
	charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
	0001: c00230c0 00030000 c00c0006 61000003 00040000 00000000 00000000 00000000
	0002: 00000000 00000000 00000000 00000000 00000000 00000000 3f0000c0 00000000
	0003: 00000000 00000000 00000000 00000000 00000000 00000200 00000001 00000000
	0020: 77180000 06010047 00000010 00000000 00000000 00001000 00000000 00000000
	0021: 00000000 00000004 00000000 00000000 00000000 00000000 00000000 00000000
	0022: 46268044 00000800 00000100 00000031 00000000 00000000 00000000 00000000
	0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 00000000
	00fb: 00000006 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(w)
	lang: aa|ast|ay|bi|br|ch|co|da|de|en|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|nso|oc|om|pt|rm|sma|smj|so|sq|ss|st|sv|sw|tn|tr|ts|vo|vot|wa|xh|yap|zu(w)
	fontversion: 131072(i)(w)
	fontformat: "TrueType"(w)
	decorative: FcFalse(w)

Match Pattern has 23 elts (size 32)
	family: "Bitstream Vera Sans Mono"(w) "DejaVu Sans Mono"(w) "WenQuanYi Zen Hei Mono"(w) "Bitstream Vera Sans Mono"(w) "DejaVu Sans Mono"(w) "Andale Mono"(w) "Courier New"(w) "Cumberland AMT"(w) "Luxi Mono"(w) "Nimbus Mono L"(w) "Courier"(w) "Miriam Mono"(w) "VL Gothic"(w) "IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) "MS Gothic"(w) "UmePlus Gothic"(w) "NSimSun"(w) "MingLiu"(w) "AR PL ShanHeiSun Uni"(w) "AR PL New Sung Mono"(w) "HanyiSong"(w) "AR PL SungtiL GB"(w) "AR PL Mingti2L Big5"(w) "ZYSong18030"(w) "UnBatang"(w) "UnDotum"(w) "Baekmuk Batang"(w) "Baekmuk Dotum"(w) "Baekmuk Gulim"(w) "Courier MonoThai"(w) "Hasida"(w) "Mitra Mono"(w) "GF Zemen Unicode"(w) "Hapax Berb$,3u=u=(Bre"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w) "Lohit Hindi"(w) "Lohit Punjabi"(w) "Lohit Tamil"(w) "Lohit Malayalam"(w) "Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) "LKLUG"(w) "FreeMono"(w) "monospace"(w) "Terafik"(w) "Dotum-Regular"(w) "monospace"(w)
	slant: 0(i)(s)
	weight: 100(i)(s)
	width: 100(i)(s)
	pixelsize: 10(f)(s)
	antialias: FcTrue(s)
	hintstyle: 3(i)(s)
	hinting: FcTrue(s)
	verticallayout: FcFalse(s)
	autohint: FcFalse(s)
	globaladvance: FcTrue(s)
	dpi: 94(f)(s)
	rgba: 5(i)(s)
	scale: 1(f)(s)
	minspace: FcFalse(s)
	lang: "C"(s)
	fontversion: 2147483647(i)(s)
	embolden: FcFalse(s)
	embeddedbitmap: FcTrue(s)
	decorative: FcFalse(s)
	encoding: "iso8859-1"(s)
	render: FcTrue(s)
	maxglyphmemory: 1048576(i)(s)

Best score 0 0 1e+99 200 0 0 0 0 0 2000 0 0 0 0 0 2.14735e+11Pattern has 20 elts (size 20)
	family: "Bitstream Vera Sans Mono"(w)
	familylang: "en"(w)
	style: "Roman"(w)
	stylelang: "en"(w)
	fullname: "Bitstream Vera Sans Mono"(w)
	fullnamelang: "en"(w)
	slant: 0(i)(w)
	weight: 80(i)(w)
	width: 100(i)(w)
	spacing: 100(i)(w)
	foundry: "bitstream"(w)
	file: "/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf"(w)
	index: 0(i)(w)
	outline: FcTrue(w)
	scalable: FcTrue(w)
	charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
	0001: c00230c0 00030000 c00c0006 61000003 00040000 00000000 00000000 00000000
	0002: 00000000 00000000 00000000 00000000 00000000 00000000 3f0000c0 00000000
	0003: 00000000 00000000 00000000 00000000 00000000 00000200 00000001 00000000
	0020: 77180000 06010047 00000010 00000000 00000000 00001000 00000000 00000000
	0021: 00000000 00000004 00000000 00000000 00000000 00000000 00000000 00000000
	0022: 46268044 00000800 00000100 00000031 00000000 00000000 00000000 00000000
	0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 00000000
	00fb: 00000006 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(w)
	lang: aa|ast|ay|bi|br|ch|co|da|de|en|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|nso|oc|om|pt|rm|sma|smj|so|sq|ss|st|sv|sw|tn|tr|ts|vo|vot|wa|xh|yap|zu(w)
	fontversion: 131072(i)(w)
	fontformat: "TrueType"(w)
	decorative: FcFalse(w)

Match Pattern has 14 elts (size 16)
	family: "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "WenQuanYi Zen Hei"(w) "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w) "Helvetica"(w) "Lucida Sans Unicode"(w) "BPG Glaho International"(w) "Tahoma"(w) "Nachlieli"(w) "Lucida Sans Unicode"(w) "Yudit Unicode"(w) "Kerkis"(w) "ArmNet Helvetica"(w) "Artsounk"(w) "BPG UTF8 M"(w) "Norasi"(w) "Saysettha Unicode"(w) "JG Lao Old Arial"(w) "GF Zemen Unicode"(w) "Pigiarniq"(w) "B Davat"(w) "B Compset"(w) "Kacst-Qr"(w) "Urdu Nastaliq Unicode"(w) "Raghindi"(w) "Mukti Narrow"(w) "malayalam"(w) "Sampige"(w) "padmaa"(w) "Hapax Berb$,3u=u=(Bre"(w) "MS Gothic"(w) "UmePlus P Gothic"(w) "SimSun"(w) "PMingLiu"(w) "AR PL ShanHeiSun Uni"(w) "AR PL New Sung"(w) "MgOpen Modata"(w) "VL Gothic"(w) "IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) "AR PL KaitiM Big5"(w) "AR PL ShanHeiSun Uni"(w) "AR PL SungtiL GB"(w) "AR PL Mingti2L Big5"(w) "$,3u=u=u=u=u=u=(B $,3u=u=u=u=u=u=u=u=u=u=u=u=(B"(w) "ZYSong18030"(w) "TSCu_Paranar"(w) "UnDotum"(w) "Baekmuk Dotum"(w) "Baekmuk Gulim"(w) "KacstQura"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w) "Lohit Hindi"(w) "Lohit Punjabi"(w) "Lohit Tamil"(w) "Lohit Malayalam"(w) "Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) "LKLUG"(w) "FreeSans"(w) "Arial Unicode MS"(w) "Arial Unicode"(w) "Code2000"(w) "Code2001"(w) "lohit_bn"(w) "lohit_as"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Rekha"(w) "Kedage-n"(w) "Meera"(w) "utkal"(w) "Saab"(w) "TAMu_Kalyani"(w) "Pothana2000"(w) "sans-serif"(w) "Roya"(w) "Koodak"(w) "Terafik"(w) "Bitstream-Vera-Sans"(w) "sans-serif"(w)
	slant: 0(i)(s)
	weight: 80(i)(s)
	width: 100(i)(s)
	pixelsize: 12(f)(s)
	hintstyle: 3(i)(s)
	hinting: FcTrue(s)
	verticallayout: FcFalse(s)
	autohint: FcFalse(s)
	globaladvance: FcTrue(s)
	lang: "C"(s)
	fontversion: 2147483647(i)(s)
	embeddedbitmap: FcTrue(s)
	decorative: FcFalse(s)

Best score 0 0 1e+99 200 0 0 0 0 0 0 0 0 0 0 0 2.14735e+11Pattern has 19 elts (size 19)
	family: "Bitstream Vera Sans"(w)
	familylang: "en"(w)
	style: "Roman"(w)
	stylelang: "en"(w)
	fullname: "Bitstream Vera Sans"(w)
	fullnamelang: "en"(w)
	slant: 0(i)(w)
	weight: 80(i)(w)
	width: 100(i)(w)
	foundry: "bitstream"(w)
	file: "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf"(w)
	index: 0(i)(w)
	outline: FcTrue(w)
	scalable: FcTrue(w)
	charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
	0001: c00230c0 00030000 c00c0006 61000003 00040000 00000000 00000000 00000000
	0002: 00000000 00000000 00000000 00000000 00000000 00000000 3f0000c0 00000000
	0003: 00000000 00000000 00000000 00000000 00000000 00000200 00000001 00000000
	0020: 77180000 06010047 00000010 00000000 00000000 00001000 00000000 00000000
	0021: 00000000 00000004 00000000 00000000 00000000 00000000 00000000 00000000
	0022: 46268044 00000800 00000100 00000031 00000000 00000000 00000000 00000000
	0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 00000000
	00fb: 00000006 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(w)
	lang: aa|ast|ay|bi|br|ch|co|da|de|en|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|nso|oc|om|pt|rm|sma|smj|so|sq|ss|st|sv|sw|tn|tr|ts|vo|vot|wa|xh|yap|zu(w)
	fontversion: 131072(i)(w)
	fontformat: "TrueType"(w)
	decorative: FcFalse(w)

Match Pattern has 14 elts (size 16)
	family: "surelythisisnotafontname"(s) "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w) "Helvetica"(w) "Lucida Sans Unicode"(w) "BPG Glaho International"(w) "Tahoma"(w) "Nachlieli"(w) "Lucida Sans Unicode"(w) "Yudit Unicode"(w) "Kerkis"(w) "ArmNet Helvetica"(w) "Artsounk"(w) "BPG UTF8 M"(w) "Norasi"(w) "Saysettha Unicode"(w) "JG Lao Old Arial"(w) "GF Zemen Unicode"(w) "Pigiarniq"(w) "B Davat"(w) "B Compset"(w) "Kacst-Qr"(w) "Urdu Nastaliq Unicode"(w) "Raghindi"(w) "Mukti Narrow"(w) "malayalam"(w) "Sampige"(w) "padmaa"(w) "Hapax Berb$,3u=u=(Bre"(w) "MS Gothic"(w) "UmePlus P Gothic"(w) "SimSun"(w) "PMingLiu"(w) "AR PL ShanHeiSun Uni"(w) "AR PL New Sung"(w) "MgOpen Modata"(w) "VL Gothic"(w) "IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) "AR PL KaitiM Big5"(w) "AR PL ShanHeiSun Uni"(w) "AR PL SungtiL GB"(w) "AR PL Mingti2L Big5"(w) "$,3u=u=u=u=u=u=(B $,3u=u=u=u=u=u=u=u=u=u=u=u=(B"(w) "ZYSong18030"(w) "TSCu_Paranar"(w) "UnDotum"(w) "Baekmuk Dotum"(w) "Baekmuk Gulim"(w) "KacstQura"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w) "Lohit Hindi"(w) "Lohit Punjabi"(w) "Lohit Tamil"(w) "Lohit Malayalam"(w) "Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) "LKLUG"(w) "FreeSans"(w) "Arial Unicode MS"(w) "Arial Unicode"(w) "Code2000"(w) "Code2001"(w) "lohit_bn"(w) "lohit_as"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Gargi_1.7"(w) "Rekha"(w) "Kedage-n"(w) "Meera"(w) "utkal"(w) "Saab"(w) "TAMu_Kalyani"(w) "Pothana2000"(w) "sans-serif"(w) "Roya"(w) "Koodak"(w) "Terafik"(w)
	slant: 0(i)(s)
	weight: 80(i)(s)
	width: 100(i)(s)
	pixelsize: 12(f)(s)
	hintstyle: 3(i)(s)
	hinting: FcTrue(s)
	verticallayout: FcFalse(s)
	autohint: FcFalse(s)
	globaladvance: FcTrue(s)
	lang: "C"(s)
	fontversion: 2147483647(i)(s)
	embeddedbitmap: FcTrue(s)
	decorative: FcFalse(s)

Best score 0 0 100 200 1 0 0 0 0 0 0 0 0 0 0 2.14735e+11Pattern has 19 elts (size 19)
	family: "Bitstream Vera Sans"(w)
	familylang: "en"(w)
	style: "Roman"(w)
	stylelang: "en"(w)
	fullname: "Bitstream Vera Sans"(w)
	fullnamelang: "en"(w)
	slant: 0(i)(w)
	weight: 80(i)(w)
	width: 100(i)(w)
	foundry: "bitstream"(w)
	file: "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf"(w)
	index: 0(i)(w)
	outline: FcTrue(w)
	scalable: FcTrue(w)
	charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
	0001: c00230c0 00030000 c00c0006 61000003 00040000 00000000 00000000 00000000
	0002: 00000000 00000000 00000000 00000000 00000000 00000000 3f0000c0 00000000
	0003: 00000000 00000000 00000000 00000000 00000000 00000200 00000001 00000000
	0020: 77180000 06010047 00000010 00000000 00000000 00001000 00000000 00000000
	0021: 00000000 00000004 00000000 00000000 00000000 00000000 00000000 00000000
	0022: 46268044 00000800 00000100 00000031 00000000 00000000 00000000 00000000
	0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 00000000
	00fb: 00000006 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(w)
	lang: aa|ast|ay|bi|br|ch|co|da|de|en|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|nso|oc|om|pt|rm|sma|smj|so|sq|ss|st|sv|sw|tn|tr|ts|vo|vot|wa|xh|yap|zu(w)
	fontversion: 131072(i)(w)
	fontformat: "TrueType"(w)
	decorative: FcFalse(w)



jwe


From godfrey at isl.stanford.edu  Fri Sep 11 23:06:18 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Fri, 11 Sep 2009 21:06:18 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <19115.4440.379746.112915@segfault.lan>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
Message-ID: <4AAB1E3A.5000302@isl.stanford.edu>

John,

My debug output starts with:
octave:1> backend("fltk")
octave:2> haber
b_th = 1.438775e+04
Theoretical max energy (T = 2320) at lambda: 1.249
Planck max energy (T = 2320) at 1.249 E(lambda) = 8.968e+01
Wien max energy (T = 2320) at 1.240 E(lambda) = 8.907e+01
octave:3> FC_DEBUG=1
FC_DEBUG=1
Match Pattern has 14 elts (size 16)
family: "DejaVu Sans"(w) "DejaVu LGC Sans"(w) "DejaVu LGC Sans"(w)
"FreeSans"(w) "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "Verdana"(w)
"Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w)
"Helvetica"(w) "Lucida Sans Unicode"(w) "BPG Glaho International"(w)
"Tahoma"(w) "Nachlieli"(w) "Lucida Sans Unicode"(w) "Yudit Unicode"(w)
"Kerkis"(w) "ArmNet Helvetica"(w) "Artsounk"(w) "BPG UTF8 M"(w)
"Waree"(w) "Loma"(w) "Garuda"(w) "Umpush"(w) "Saysettha Unicode"(w) "JG
Lao Old Arial"(w) "GF Zemen Unicode"(w) "Pigiarniq"(w) "B Davat"(w) "B
Compset"(w) "Kacst-Qr"(w) "Urdu Nastaliq Unicode"(w) "Raghindi"(w)
"Mukti Narrow"(w) "malayalam"(w) "Sampige"(w) "padmaa"(w) "Hapax
Berbe`re"(w) "MS Gothic"(w) "UmePlus P Gothic"(w) "SimSun"(w)
"PMingLiu"(w) "WenQuanYi Zen Hei"(w) "WenQuanYi Bitmap Song"(w) "AR PL
ShanHeiSun Uni"(w) "AR PL New Sung"(w) "MgOpen Modata"(w) "VL Gothic"(w)
"IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w)
"AR PL KaitiM GB"(w) "AR PL KaitiM Big5"(w) "AR PL ShanHeiSun Uni"(w)
"AR PL SungtiL GB"(w) "AR PL Mingti2L Big5"(w) "??????"(w)
"ZYSong18030"(w) "TSCu_Paranar"(w) "UnDotum"(w) "Baekmuk Dotum"(w)
"Baekmuk Gulim"(w) "KacstQura"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w)
"Lohit Hindi"(w) "Lohit Marathi"(w) "Lohit Maithili"(w) "Lohit
Kashmiri"(w) "Lohit Konkani"(w) "Lohit Nepali"(w) "Lohit Sindhi"(w)
"Lohit Punjabi"(w) "Lohit Tamil"(w) "Meera"(w) "Lohit Malayalam"(w)
"Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) "LKLUG"(w)
"Padauk"(w) "UnDotum"(w) "FreeSans"(w) "Arial Unicode MS"(w) "Arial
Unicode"(w) "Code2000"(w) "Code2001"(w) "Meera"(w) "sans-serif"(w)
"Roya"(w) "Koodak"(w) "Terafik"(w) "sans-serif"(w) "sans-serif"(w)
"sans-serif"(w) "FreeMono"(w) "monospace"(w)
slant: 0(i)(s)
weight: 80(i)(s)
=======================================================================

But, does not match the font:

Best score 0 0 100 200 1 0 0 0 0 0 0 0 0 0 0 2.14735e+11Pattern has 19 elts (size 19)
	family: "Bitstream Vera Sans"(w)
	familylang: "en"(w)
	style: "Roman"(w)
	stylelang: "en"(w)
	fullname: "Bitstream Vera Sans"(w)
	fullnamelang: "en"(w)
	slant: 0(i)(w)
	weight: 80(i)(w)
	width: 100(i)(w)
	foundry: "bitstream"(w)
	file: "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf"(w)
	index: 0(i)(w)
	outline: FcTrue(w)
==================================================================================

I will look at it a bit more tonight.
I did notice that I do not have:
/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf

I only have the freefont/  fonts down that path.

I think that there is something over-restrictive in the search pattern.

Michael


Michael

	scalable: FcTrue(w)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090911/466efdaf/attachment-0001.html 

From godfrey at isl.stanford.edu  Fri Sep 11 23:57:50 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Fri, 11 Sep 2009 21:57:50 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <19115.4440.379746.112915@segfault.lan>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
Message-ID: <4AAB2A4E.4050705@isl.stanford.edu>

John,

And, my system finds:
FcConfigSubstitute Pattern has 26 elts (size 32)
family: "Bitstream Vera Sans"(s)
familylang: "en"(s)
style: "Roman"(s)
stylelang: "en"(s)
fullname: "Bitstream Vera Sans"(s)
fullnamelang: "en"(s)
slant: 0(i)(s)
weight: 80(i)(s)
width: 100(i)(s)
pixelsize: 10(f)(s)
foundry: "bitstream"(s)
hintstyle: 3(i)(s)
hinting: FcTrue(s)
verticallayout: FcFalse(s)
autohint: FcFalse(s)
globaladvance: FcTrue(s)
file: "/usr/share/fonts/bitstream-vera/Vera.ttf"(s)
index: 0(i)(s)
outline: FcTrue(s)
scalable: FcTrue(s)
charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff
ffffffff ffffffff
0001: c00230c0 00030000 c00c0006 61000003 00040000 00000000 00000000
00000000
0002: 00000000 00000000 00000000 00000000 00000000 00000000 3f0000c0
00000000
0003: 00000000 00000000 00000000 00000000 00000000 00000200 00000001
00000000
0020: 77180000 06010047 00000010 00000000 00000000 00001000 00000000
00000000
0021: 00000000 00000004 00000000 00000000 00000000 00000000 00000000
00000000
0022: 46268044 00000800 00000100 00000031 00000000 00000000 00000000
00000000
0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400
00000000
00fb: 00000006 00000000 00000000 00000000 00000000 00000000 00000000
00000000
(s)
lang:
aa|an|ast|ay|bi|br|ch|co|crh|da|de|en|es|et|eu|fi|fil|fj|fo|fr|fur|fy|gd|gl|gv|ho|ht|ia|id|ie|io|is|it|jv|kj|ku-tr|kwm|lb|li|mg|ms|nb|nds|ng|nl|nn|no|nr|nso|oc|om|pap-an|pap-aw|pt|rm|rn|rw|sc|sg|sma|smj|sn|so|sq|ss|st|su|sv|sw|tl|tn|tr|ts|uz|vo|vot|wa|xh|yap|za|zu(s)
fontversion: 131072(i)(s)
fontformat: "TrueType"(s)
embeddedbitmap: FcTrue(s)
decorative: FcFalse(s)

================================================
But, rejects it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090911/25a1295c/attachment.html 

From godfrey at isl.stanford.edu  Sat Sep 12 00:33:00 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Fri, 11 Sep 2009 22:33:00 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <19115.4440.379746.112915@segfault.lan>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
Message-ID: <4AAB328C.6090907@isl.stanford.edu>

John,

My system uses fontconfig-2.7.1-1.
Is yous a different version?

Michael



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090911/c5ac96d3/attachment.html 

From jwe at octave.org  Sat Sep 12 05:49:57 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 12 Sep 2009 06:49:57 -0400
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <4AAB328C.6090907@isl.stanford.edu>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
	<4AAB328C.6090907@isl.stanford.edu>
Message-ID: <19115.31957.137913.95175@segfault.lan>

On 11-Sep-2009, Michael D Godfrey wrote:

| My system uses fontconfig-2.7.1-1.
| Is yous a different version?

$ dpkg -l fontconfig
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  fontconfig     2.6.0-4        generic font configuration library - support

jwe

From jwe at octave.org  Sat Sep 12 09:22:05 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 12 Sep 2009 10:22:05 -0400
Subject: Octave 3.3.50 available for ftp
Message-ID: <19115.44685.776976.709902@segfault.lan>

A new snapshot of Octave is now available from ftp.octave.org in the
directory /pub/octave/bleeding-edge:

  51b3d27bc6bf48a7e5964859ff261467  octave-3.3.50.tar.bz2
  355aa529db2228001fa12627a19f7f77  octave-3.3.50.tar.gz
  0731597b8ec1f21df211705215b381bb  octave-3.1.55-3.3.50.patch.bz2
  129c177cd8f58dc2b98ad6a453056d0f  octave-3.1.55-3.3.50.patch.gz

  -rw-r--r-- 1 506 1012 10823953 Sep 12 13:51 octave-3.3.50.tar.bz2
  -rw-r--r-- 1 506 1012 12351744 Sep 12 13:53 octave-3.3.50.tar.gz
  -rw-r--r-- 1 506 1012  1315884 Sep 12 13:53 octave-3.1.55-3.3.50.patch.bz2
  -rw-r--r-- 1 506 1012  1630268 Sep 12 13:53 octave-3.1.55-3.3.50.patch.gz

The snapshot is tagged in the usual way (ss-3-3-50) in the Mercurial
archive and will be marked as the "development" version of
Octave on the download page of the Octave web site.

Please remember that these snapshots are provided for testing
purposes.  I do not consider them to be Octave releases.  If people
think there will be confusion because of the version number, then we
can add a notice to the Octave startup message.  Changing the version
number to something like ss-2009-09-12 is not an option because it
will cause trouble with typical version comparison functions (for
example, that are sometimes used for building Octave Forge packages).

This snapshot includes the new experimental OpenGL-based graphics
code, but the gnuplot backend is used by default.  Assuming you have
all the required libraries and have built the OpenGL bits properly,
you should be able to switch to the new backend with the command

  backend ("fltk");

Plots should mostly work, but there may still be some font problems.
Printing has also not been implemented for the fltk backend.  PLEASE
DO NOT REPORT THESE LIMITATIONS AS BUGS.  If you would like to see
these features improve at a more rapid pace, please help with
implementing the things you miss most...

jwe

From jwe at octave.org  Sat Sep 12 11:17:07 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 12 Sep 2009 12:17:07 -0400
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <4AABBCBE.4000204@isl.stanford.edu>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
	<4AAB328C.6090907@isl.stanford.edu>
	<19115.31957.137913.95175@segfault.lan>
	<4AABBCBE.4000204@isl.stanford.edu>
Message-ID: <19115.51587.191331.608775@segfault.lan>

On 12-Sep-2009, Michael D Godfrey wrote:

| On 09/12/2009 03:49 AM, John W. Eaton wrote:
| > ii  fontconfig     2.6.0-4        generic font configuration library - support
| I should also have asked: what is your fltk version.
| Fedora currently uses fltk-1.1.9-4.fc11.
| The fltk site says fltk-1.3.0 is the current release.

$ dpkg -l '*fltk*' | grep ^ii
ii  libfltk1.1     1.1.9-6        Fast Light Toolkit - shared libraries
ii  libfltk1.1-dev 1.1.9-6        Fast Light Toolkit - development files

jwe

From godfrey at isl.stanford.edu  Sat Sep 12 12:10:46 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 12 Sep 2009 10:10:46 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <19115.51587.191331.608775@segfault.lan>
References: <4AAB0EBA.8010306@isl.stanford.edu>	<19115.4440.379746.112915@segfault.lan>	<4AAB328C.6090907@isl.stanford.edu>	<19115.31957.137913.95175@segfault.lan>	<4AABBCBE.4000204@isl.stanford.edu>
	<19115.51587.191331.608775@segfault.lan>
Message-ID: <4AABD616.7090209@isl.stanford.edu>

John,

Here is a very temporary (I think) fix for the font problem:

Edit line 144 of txt-eng-ft.cc to read:
           if (match)   // && res != FcResultNoMatch)
=======================================
This causes my fontconfig to select a perfectly reasonable
font (/usr/share/fonts/dejavu/DejaVuSans.ttf).  There may be some
reason for the additional && res != FcResultNoMatch test, but
I do not understand why it is needed.  At least this change makes
it easier to get on with the printing problem (and I learned a little
bit about all this fltk, GL2ps, OpenGL, etc., etc., stuff...

Do you want to see the output that I get for setenv FC_DEBUG 1
after the change?  It looks a lot like what you got.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090912/7dea2057/attachment.html 

From godfrey at isl.stanford.edu  Sat Sep 12 12:36:12 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 12 Sep 2009 10:36:12 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <19115.51587.191331.608775@segfault.lan>
References: <4AAB0EBA.8010306@isl.stanford.edu>	<19115.4440.379746.112915@segfault.lan>	<4AAB328C.6090907@isl.stanford.edu>	<19115.31957.137913.95175@segfault.lan>	<4AABBCBE.4000204@isl.stanford.edu>
	<19115.51587.191331.608775@segfault.lan>
Message-ID: <4AABDC0C.9060800@isl.stanford.edu>

John,

By the way, here is the "definition" of FcFontMatch from
www.fontconfig.org:

||FcPattern * FcFontMatch|(FcConfig */config/, FcPattern */p/, FcResult 
*/result/);|


    Description

Finds the font in /sets/ most closely matching /pattern/ and returns the 
result of FcFontRenderPrepare for that font and the provided pattern. 
This function should be called only after FcConfigSubstitute and 
FcDefaultSubstitute have been called for /p/; otherwise the results will 
not be correct. If /config/ is NULL, the current configuration is used.



Since, result is nowhere mentioned, this does not help much.  In fact,
the description is completely obscure to me.  In other examples on the web
I could find only uses of FcResultNoMatch that test on the returned 
value from
Fc* calls.  So, I think that testing on &res may be an error.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090912/f5fc0dfd/attachment.html 

From michael.goffioul at gmail.com  Sat Sep 12 12:53:33 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sat, 12 Sep 2009 18:53:33 +0100
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <4AABDC0C.9060800@isl.stanford.edu>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
	<4AAB328C.6090907@isl.stanford.edu>
	<19115.31957.137913.95175@segfault.lan>
	<4AABBCBE.4000204@isl.stanford.edu>
	<19115.51587.191331.608775@segfault.lan>
	<4AABDC0C.9060800@isl.stanford.edu>
Message-ID: <128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>

On Sat, Sep 12, 2009 at 6:36 PM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> John,
>
> By the way, here is the "definition" of FcFontMatch from
> www.fontconfig.org:
>
> FcPattern * FcFontMatch(FcConfig *config, FcPattern *p, FcResult *result);
>
> Description
>
> Finds the font in sets most closely matching pattern and returns the result
> of FcFontRenderPrepare for that font and the provided pattern. This function
> should be called only after FcConfigSubstitute and FcDefaultSubstitute have
> been called for p; otherwise the results will not be correct. If config is
> NULL, the current configuration is used.
>
> Since, result is nowhere mentioned, this does not help much.? In fact,
> the description is completely obscure to me.? In other examples on the web
> I could find only uses of FcResultNoMatch that test on the returned value
> from
> Fc* calls.? So, I think that testing on &res may be an error.

It's not an error and you're allowed to test on the FcResult result.
Although this seems to be too conservative. Maybe a simple
warning if result == FcResultNoMatch could be enough.
To be honest, I probably copied that from somewhere else
(by looking in fontconfig examples on the web), but I don't
remember.

Michael.


From godfrey at isl.stanford.edu  Sat Sep 12 13:16:36 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 12 Sep 2009 11:16:36 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>
References: <4AAB0EBA.8010306@isl.stanford.edu>	
	<19115.4440.379746.112915@segfault.lan>	
	<4AAB328C.6090907@isl.stanford.edu>	
	<19115.31957.137913.95175@segfault.lan>	
	<4AABBCBE.4000204@isl.stanford.edu>	
	<19115.51587.191331.608775@segfault.lan>	
	<4AABDC0C.9060800@isl.stanford.edu>
	<128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>
Message-ID: <4AABE584.5080008@isl.stanford.edu>

On 09/12/2009 10:53 AM, Michael Goffioul wrote:
> It's not an error and you're allowed to test on the FcResult result.
>    

I am sure you are right in principle, but just testing on
match seems to result in a "reasonable" font for now.
It is likely at some point to allow users to specify fonts
in more detail.  At that point this code could be enhanced.

By the way, do you know a source for documentation of
this stuff, other than fontconfig.org?

Michael (Godfrey)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090912/0908a850/attachment.html 

From dasergatskov at gmail.com  Sat Sep 12 13:27:48 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sat, 12 Sep 2009 13:27:48 -0500
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <4AABE584.5080008@isl.stanford.edu>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
	<4AAB328C.6090907@isl.stanford.edu>
	<19115.31957.137913.95175@segfault.lan>
	<4AABBCBE.4000204@isl.stanford.edu>
	<19115.51587.191331.608775@segfault.lan>
	<4AABDC0C.9060800@isl.stanford.edu>
	<128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>
	<4AABE584.5080008@isl.stanford.edu>
Message-ID: <892b16670909121127r5d36d425t816b0fc087f6ac4c@mail.gmail.com>

BTW, using 3.3.5 and trying (slightly modified) John's example:

octave:1> backend ("fltk")
octave:2> title ("foobar 10", "fontname", "Inconsolata")
octave:3> title ("foobar 10", "fontname", "Inconsolata")
octave:4> warning: could not match any font: *-normal-normal-12
warning: ft_render: unable to load appropriate font

Notice that the warning shows up only on the second invocation.
It did find and used Inconsolata font (it has a distinctly slashed zero).

Where does this warning is coming from?

Dmitri.
--

From michael.goffioul at gmail.com  Sat Sep 12 14:50:21 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sat, 12 Sep 2009 20:50:21 +0100
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <4AABE584.5080008@isl.stanford.edu>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<19115.4440.379746.112915@segfault.lan>
	<4AAB328C.6090907@isl.stanford.edu>
	<19115.31957.137913.95175@segfault.lan>
	<4AABBCBE.4000204@isl.stanford.edu>
	<19115.51587.191331.608775@segfault.lan>
	<4AABDC0C.9060800@isl.stanford.edu>
	<128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>
	<4AABE584.5080008@isl.stanford.edu>
Message-ID: <128f38bd0909121250j65f131cek664481787a507a45@mail.gmail.com>

On Sat, Sep 12, 2009 at 7:16 PM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/12/2009 10:53 AM, Michael Goffioul wrote:
>
> It's not an error and you're allowed to test on the FcResult result.
>
>
> I am sure you are right in principle, but just testing on
> match seems to result in a "reasonable" font for now.
> It is likely at some point to allow users to specify fonts
> in more detail.? At that point this code could be enhanced.
>
> By the way, do you know a source for documentation of
> this stuff, other than fontconfig.org?

No.

Michael.


From godfrey at isl.stanford.edu  Sat Sep 12 15:26:20 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 12 Sep 2009 13:26:20 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <892b16670909121127r5d36d425t816b0fc087f6ac4c@mail.gmail.com>
References: <4AAB0EBA.8010306@isl.stanford.edu>	<19115.4440.379746.112915@segfault.lan>	<4AAB328C.6090907@isl.stanford.edu>	<19115.31957.137913.95175@segfault.lan>	<4AABBCBE.4000204@isl.stanford.edu>	<19115.51587.191331.608775@segfault.lan>	<4AABDC0C.9060800@isl.stanford.edu>	<128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>	<4AABE584.5080008@isl.stanford.edu>
	<892b16670909121127r5d36d425t816b0fc087f6ac4c@mail.gmail.com>
Message-ID: <4AAC03EC.2020402@isl.stanford.edu>

On 09/12/2009 11:27 AM, Dmitri A. Sergatskov wrote:
> Where does this warning is coming from?
>
>    
It comes from txt-eng-ft.cc when it cannot find any matching
font using fontconfig.  A hard-coded default is then used.
The change That I proposed seems to result in a font
always being found.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090912/278bd2cb/attachment.html 

From dasergatskov at gmail.com  Sat Sep 12 15:47:43 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sat, 12 Sep 2009 15:47:43 -0500
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <4AAC03EC.2020402@isl.stanford.edu>
References: <4AAB0EBA.8010306@isl.stanford.edu>
	<4AAB328C.6090907@isl.stanford.edu>
	<19115.31957.137913.95175@segfault.lan>
	<4AABBCBE.4000204@isl.stanford.edu>
	<19115.51587.191331.608775@segfault.lan>
	<4AABDC0C.9060800@isl.stanford.edu>
	<128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>
	<4AABE584.5080008@isl.stanford.edu>
	<892b16670909121127r5d36d425t816b0fc087f6ac4c@mail.gmail.com>
	<4AAC03EC.2020402@isl.stanford.edu>
Message-ID: <892b16670909121347k17e6a797ya2533a9ec1d5411e@mail.gmail.com>

On Sat, Sep 12, 2009 at 3:26 PM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/12/2009 11:27 AM, Dmitri A. Sergatskov wrote:
>
> Where does this warning is coming from?
>
>
>
> It comes from txt-eng-ft.cc when it cannot find any matching
> font using fontconfig.? A hard-coded default is then used.
> The change That I proposed seems to result in a font
> always being found.

But it does find the font (and used it).

>
> Michael
>
>

Dmitri.
--


From godfrey at isl.stanford.edu  Sat Sep 12 17:33:10 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 12 Sep 2009 15:33:10 -0700
Subject: fontconfig failure on Fedora x86_64 systems
In-Reply-To: <892b16670909121347k17e6a797ya2533a9ec1d5411e@mail.gmail.com>
References: <4AAB0EBA.8010306@isl.stanford.edu>	
	<4AAB328C.6090907@isl.stanford.edu>	
	<19115.31957.137913.95175@segfault.lan>	
	<4AABBCBE.4000204@isl.stanford.edu>	
	<19115.51587.191331.608775@segfault.lan>	
	<4AABDC0C.9060800@isl.stanford.edu>	
	<128f38bd0909121053n11a17c6dsd8c780b7478c0ca1@mail.gmail.com>	
	<4AABE584.5080008@isl.stanford.edu>	
	<892b16670909121127r5d36d425t816b0fc087f6ac4c@mail.gmail.com>	
	<4AAC03EC.2020402@isl.stanford.edu>
	<892b16670909121347k17e6a797ya2533a9ec1d5411e@mail.gmail.com>
Message-ID: <4AAC21A6.8080608@isl.stanford.edu>

On 09/12/2009 01:47 PM, Dmitri A. Sergatskov wrote:
> But it does find the font (and used it).
>    
Yes.  There are usually lots of "possible" fonts.  The
search is supposed to find the "best" one, but this
is not very well-defined.  Actually, words like "best"
or right or wrong are not quite appropriate here.
Sort of alright is a good term...

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090912/990cc524/attachment.html 

From tmacchant at yahoo.co.jp  Sun Sep 13 00:04:00 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Sun, 13 Sep 2009 14:04:00 +0900 (JST)
Subject: Octave 3.3.50 available for ftp
In-Reply-To: <19115.44685.776976.709902@segfault.lan>
Message-ID: <20090913050400.8050.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello

--- "John W. Eaton" wrote:

> A new snapshot of Octave is now available from ftp.octave.org in the
> directory /pub/octave/bleeding-edge:

My binaries for cygwin have been deleted on the web.

The patch deletes the description of my binaries.

The information octave 3.2.2 on cygwin-1.7 should be added.

The addition is better to be done by the maintainer of the current release : Marco Atzeri.
Perhaps he will add changes.

Regards

Tatsuro
 

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: README.Cygwin.diff
Type: application/octet-stream
Size: 1100 bytes
Desc: 55167404-README.Cygwin.diff
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090913/c6b2a3ed/attachment.obj 

From shaiay at gmail.com  Sun Sep 13 06:05:15 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sun, 13 Sep 2009 14:05:15 +0300
Subject: fltk_backend zoom and corrdinate fixes
Message-ID: <420fb9e60909130405j3051f8deq28d0e24b1ff022ce@mail.gmail.com>

The attached changeset fixes some bugs in fltk backend mouse handling
-- mainly the coordinates in the status bar are taken relative to the
axis that the mouse pointer is in, and zooming/panning bugs fixed when
there are multiple plots.

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk2.patch
Type: text/x-diff
Size: 5920 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090913/f8211ebe/attachment.bin 

From highegg at gmail.com  Mon Sep 14 00:58:47 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 14 Sep 2009 07:58:47 +0200
Subject: 3.2.3 RC1
In-Reply-To: <4A9590DC.3060904@gmx.net>
References: <20090825061251.205040@gmx.net>
	<69d8d540908250129k1273eccaq3629b475379bc348@mail.gmail.com>
	<4A9590DC.3060904@gmx.net>
Message-ID: <69d8d540909132258x26a615b5hbff16592461b9f5d@mail.gmail.com>

On Wed, Aug 26, 2009 at 9:45 PM, Benjamin Lindner <lindnerben at gmx.net> wrote:
> Jaroslav Hajek wrote:
>>
>> On Tue, Aug 25, 2009 at 8:12 AM, Benjamin Lindner<lindnerben at gmx.net>
>> wrote:
>>>
>>> Hello,
>>>
>>> The imread/imfinfo issue as reported in
>>>
>>> http://www.nabble.com/imgwrite-imfinfo-fail-in-octave-3.2.x-td25004136.html
>>> should also be fixed before releasing a new 3.2.x version.
>>>
>>
>> Done.
>
> thanks
>
>>> Unfortunately there is no test of the imread/imwrite/imfinfo scripts in
>>> the 3.2.x branch, thus it does not show in "make check", so I missed it at
>>> first...
>>
>> Maybe there's a patch that can be transplanted?
>>
>
> The following two changesets added a test to imread.m in the development
> sources:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/ab563d2adc10
> http://hg.savannah.gnu.org/hgweb/octave/rev/8a082b66c1e0
>
> ben
>

I applied both of those.

thanks


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

From highegg at gmail.com  Mon Sep 14 02:38:58 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 14 Sep 2009 09:38:58 +0200
Subject: 3.2.3 RC4
Message-ID: <69d8d540909140038h47400cc4v543b83de80b22bf4@mail.gmail.com>

hi all,

the Octave 3.2.3 RC4 tarballs are here:
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

changes since RC3:

changeset:   9430:aecd82b05d32
user:        John W. Eaton <jwe at octave.org>
date:        Wed Sep 09 14:14:32 2009 +0200
summary:     pr-output.cc: new test

changeset:   9431:ee803fe0ec6b
user:        John W. Eaton <jwe at octave.org>
date:        Wed Sep 09 14:14:32 2009 +0200
summary:     dlmwrite.m: fix typo

changeset:   9432:f8925ecf14af
user:        John W. Eaton <jwe at octave.org>
date:        Wed Sep 09 14:15:04 2009 +0200
summary:     abort if floating point format is not recognized as IEEE

changeset:   9433:2a4231dbbcd1
user:        Ben Abbott <bpabbott at mac.com>
date:        Mon Sep 14 07:55:15 2009 +0200
summary:     gnuplot_drawnow.m: Avoid flickering plot windows.

changeset:   9434:f9e65ffeadf2
user:        Alexander Mamonov <mamonov at gmail.com>
date:        Mon Sep 14 07:57:38 2009 +0200
summary:     image/imread.m Test added.

changeset:   9435:bfb655164e6f
user:        John W. Eaton <jwe at octave.org>
date:        Mon Sep 14 07:57:38 2009 +0200
summary:     imread.m: fix test

changeset:   9436:6cd2e50ba1eb
tag:         qparent
tag:         3-2-3-rc4
user:        John W. Eaton <jwe at octave.org>
date:        Mon Sep 14 08:01:39 2009 +0200
summary:     lo-ieee.cc: include cstdlib, update copyright date

the only major issue fixed since RC3 was the gnuplot mouse zooming
problem, which I hope is now fixed.

unless there are new or persisting serious problems, these tarballs
will become the 3.2.3 release at Friday 18.9.

regards

-- 
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 14 12:13:43 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 14 Sep 2009 13:13:43 -0400
Subject: fltk_backend zoom and corrdinate fixes
In-Reply-To: <420fb9e60909130405j3051f8deq28d0e24b1ff022ce@mail.gmail.com>
References: <420fb9e60909130405j3051f8deq28d0e24b1ff022ce@mail.gmail.com>
Message-ID: <19118.31175.962763.765284@segfault.lan>

On 13-Sep-2009, Shai Ayal wrote:

| The attached changeset fixes some bugs in fltk backend mouse handling
| -- mainly the coordinates in the status bar are taken relative to the
| axis that the mouse pointer is in, and zooming/panning bugs fixed when
| there are multiple plots.

I applied it.

Thanks,

jwe

From lindnerben at gmx.net  Mon Sep 14 13:00:53 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 14 Sep 2009 20:00:53 +0200
Subject: 3.2.3 RC4
In-Reply-To: <69d8d540909140038h47400cc4v543b83de80b22bf4@mail.gmail.com>
References: <69d8d540909140038h47400cc4v543b83de80b22bf4@mail.gmail.com>
Message-ID: <4AAE84D5.6040503@gmx.net>

Jaroslav Hajek wrote:
> hi all,
> 
> the Octave 3.2.3 RC4 tarballs are here:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 

Building using TDM's mingw32 gcc-4.3.0-2 succeeds with make check 
resulting :

Summary:

   PASS   5746
   FAIL     11

octave-3.2.3\scripts/image\imread.m  PASS    0/1    FAIL 1
octave-3.2.3\src\data.cc  PASS  500/509  FAIL 9
test_string.m ...................... PASS   78/79   FAIL 1

the imread test currently fails because the graphicsmagick dll is not 
yet really location-independent, but depends on the correct setting of 
MAGICK_HOME environment variable (which is not set by the run-octave 
script).

Calling imread() from within an (properly) installed octave works.

The other fails are known.


> the only major issue fixed since RC3 was the gnuplot mouse zooming
> problem, which I hope is now fixed.

Yes it works for the windows terminal using gnuplot CVS-4.3.0-2009-07-08.

Thanks Tatsuro and Ben Abbot for following this one and fixing it.

benjamin

From jwe at octave.org  Mon Sep 14 13:15:43 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 14 Sep 2009 14:15:43 -0400
Subject: Octave 3.3.50 available for ftp
In-Reply-To: <20090913050400.8050.qmail@web3814.mail.bbt.yahoo.co.jp>
References: <19115.44685.776976.709902@segfault.lan>
	<20090913050400.8050.qmail@web3814.mail.bbt.yahoo.co.jp>
Message-ID: <19118.34895.967809.951153@segfault.lan>

On 13-Sep-2009, Tatsuro MATSUOKA wrote:

| --- "John W. Eaton" wrote:
| 
| > A new snapshot of Octave is now available from ftp.octave.org in the
| > directory /pub/octave/bleeding-edge:
| 
| My binaries for cygwin have been deleted on the web.
| 
| The patch deletes the description of my binaries.
| 
| The information octave 3.2.2 on cygwin-1.7 should be added.
| 
| The addition is better to be done by the maintainer of the current release : Marco Atzeri.
| Perhaps he will add changes.

I made this change.

Thanks,

jwe

From jwe at octave.org  Mon Sep 14 20:57:50 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 14 Sep 2009 21:57:50 -0400
Subject: development snapshot
In-Reply-To: <20090909065333.GA8939@atlan>
References: <69d8d540907290120r74c0da7dx680ccb6c795ddfe@mail.gmail.com>
	<19102.49674.637449.216165@segfault.lan>
	<69d8d540909030321l38b9a055k35c0b161a04b53e5@mail.gmail.com>
	<19103.59481.557945.168889@segfault.lan>
	<19105.36502.204082.979320@segfault.lan>
	<69d8d540909062334u14e7a9f6o4e1c15ece13dddd0@mail.gmail.com>
	<a0daad600909071158m50c62a51lc8e2560232bd0dee@mail.gmail.com>
	<69d8d540909080056w6a06f425scb2d77ac9ef23d4a@mail.gmail.com>
	<20090909065333.GA8939@atlan>
Message-ID: <19118.62622.459422.591490@segfault.lan>

As I mentioned earlier, I had an appointment to speak with an attorney
from the Software Freedom Law Center last Friday.  Now that I've
spoken with him, I'd like to make the following final comments about
this topic.  After reviewing this specific patent, my technical belief
is that its claims are obvious and, thus, invalid.  Therefore, I see
no reason to remove the code from Octave that supports dispatching on
function handles.  However, we must continue to prudently respect
patent rights.  I know that many of us do not agree with software
patents, and I understand there is a case now at the Supreme Court
that may render them largely invalid, but for now we have to abide by
the law, even if we don't like it.  We must not simply assume that all
patents are invalid, nor should we assume that all patents are
definitely valid simply because they have been granted.  Patents are
to be evaluated on a case by case basis when they arise as a concern
meriting our attention.

Therefore, unless we receive or hear of a threat from the owner a
patent, our best course of action is to continue doing what are doing
(writing software) and not go out looking for patents that may be a
problem.  If we did that, we could spend all our time just looking at
patents, since there are so many software patents out there today.
If or when there is a direct threat to Octave, we will immediately
seek counsel to deal with whatever specific threat arises and we will
respect any valid patent rights that exist.  In any case, we should
not discuss the specifics of any patents on public mailing lists.  For
that reason, if you'd like to communicate with me about this, please
do so directly.  For now, let's put this matter to the side and get
back to making Octave the best program it can be.

jwe


From thorsten.meyier at gmx.de  Tue Sep 15 09:12:44 2009
From: thorsten.meyier at gmx.de (Thorsten Meyer)
Date: Tue, 15 Sep 2009 16:12:44 +0200
Subject: bug in oct-cmplx.h?
Message-ID: <4AAFA0DC.7040801@gmx.de>

Jaroslav Hajek wrote:

> 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.
>   
Hi,

thanks for your quick reply.

Strange:
I had tried
  ./autogen
  ./config.status --recheck
already and there was no FLOAT_TRUNCATE in config.h.

Now I did
    ./autogen
    ./configure ...
as you suggested and after that its there all right.

I always thought that ./config.status --recheck did the same as
./configure (only that it saved me retyping the detailed configure
options).  Apparently, this is not (always) the case. Can you explain?

Thorsten



From jwe at octave.org  Tue Sep 15 09:56:35 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 15 Sep 2009 10:56:35 -0400
Subject: bug in oct-cmplx.h?
In-Reply-To: <4AAFA0DC.7040801@gmx.de>
References: <4AAFA0DC.7040801@gmx.de>
Message-ID: <19119.43811.56434.777809@segfault.lan>

On 15-Sep-2009, Thorsten Meyer wrote:

| I always thought that ./config.status --recheck did the same as
| ./configure (only that it saved me retyping the detailed configure
| options).  Apparently, this is not (always) the case. Can you explain?

Read the description of the --recheck option in the autoconf manual.
I don't think it does what you expect.  I think this is an autoconf
issue, but perhaps we could have better integration of autoconf and
Make, so that things are updated correctly and automatically when
there are changes to the configure scripts.  That we generally need to
run autogen.sh and configure when things change doesn't bother me too
much, so I'm unlikely to make changes, but I would of course consider
patches.

jwe

From highegg at gmail.com  Tue Sep 15 10:34:23 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 15 Sep 2009 17:34:23 +0200
Subject: user function return values
Message-ID: <69d8d540909150834w37202c24mdd2a9b602bb7c231@mail.gmail.com>

hi,

Today I discovered that user functions called via feval would always
return an octave_value_list of length equal to the number of declared
parameters, padded by undefined values for undefined outputs. I'm not
100% sure this was a bug, but I found it very surprising and quite
unexpected for extern apps embedding octave; for instance, I was
getting surprising bugs in pytave for very simple and correct calls.
So I took the liberty to change it:
http://hg.savannah.gnu.org/hgweb/octave/rev/080e11f1b0c1

If nargout is >= 1, return first nargout values from the output list,
incl. undefined values.
If nargout == 0, return the 1st value from the list if it is defined,
otherwise return 0.

The main point is to prevent undefined values being returned in the
list, unless the function actually didn't define the requested number
of output values.

make check passes for me, but chances still are that this may break
something, so if you see a gotcha, please let me know.

-- 
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  Tue Sep 15 10:51:58 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 15 Sep 2009 11:51:58 -0400
Subject: user function return values
In-Reply-To: <69d8d540909150834w37202c24mdd2a9b602bb7c231@mail.gmail.com>
References: <69d8d540909150834w37202c24mdd2a9b602bb7c231@mail.gmail.com>
Message-ID: <19119.47134.165354.742211@segfault.lan>

On 15-Sep-2009, Jaroslav Hajek wrote:

| Today I discovered that user functions called via feval would always
| return an octave_value_list of length equal to the number of declared
| parameters, padded by undefined values for undefined outputs. I'm not
| 100% sure this was a bug, but I found it very surprising and quite
| unexpected for extern apps embedding octave; for instance, I was
| getting surprising bugs in pytave for very simple and correct calls.
| So I took the liberty to change it:
| http://hg.savannah.gnu.org/hgweb/octave/rev/080e11f1b0c1
| 
| If nargout is >= 1, return first nargout values from the output list,
| incl. undefined values.
| If nargout == 0, return the 1st value from the list if it is defined,
| otherwise return 0.
| 
| The main point is to prevent undefined values being returned in the
| list, unless the function actually didn't define the requested number
| of output values.
| 
| make check passes for me, but chances still are that this may break
| something, so if you see a gotcha, please let me know.

Did this problem only show up if using feval from C++, or could it
also be seen from interpreted code?  If the latter, then can you give
an example?

Do you intend to use the test_feval function in a test?  If so, then I
think it shoudl be renamed __test_feval__ or something.  Otherwise, if
it was just for debugging, maybe it should be removed?

Thanks,

jwe

From thorsten.meyier at gmx.de  Tue Sep 15 11:24:26 2009
From: thorsten.meyier at gmx.de (Thorsten Meyer)
Date: Tue, 15 Sep 2009 18:24:26 +0200
Subject: bug in oct-cmplx.h?
In-Reply-To: <19119.43811.56434.777809@segfault.lan>
References: <4AAFA0DC.7040801@gmx.de> <19119.43811.56434.777809@segfault.lan>
Message-ID: <4AAFBFBA.4010604@gmx.de>

John W. Eaton wrote:
> On 15-Sep-2009, Thorsten Meyer wrote:
>
> | I always thought that ./config.status --recheck did the same as
> | ./configure (only that it saved me retyping the detailed configure
> | options).  Apparently, this is not (always) the case. Can you explain?
>
> Read the description of the --recheck option in the autoconf manual.
> I don't think it does what you expect.  I think this is an autoconf
> issue, but perhaps we could have better integration of autoconf and
> Make, so that things are updated correctly and automatically when
> there are changes to the configure scripts.  That we generally need to
> run autogen.sh and configure when things change doesn't bother me too
> much, so I'm unlikely to make changes, but I would of course consider
> patches.
>   
I have been using the make target "configfiles", that actually tries to
update the configuration files correctly. Only it's broken for config.h
(I did not realize that config.h is generated by config.status just like
the Makefiles when I implemented it).

Included is a simple patch that should fix the "configfiles" target wrt
config.h.

Is it ok to push it?

Thanks

Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_config.h_to_configfiles_target.patch
Type: text/x-patch
Size: 1034 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090915/f765346b/attachment-0001.bin 

From jwe at octave.org  Tue Sep 15 13:01:31 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 15 Sep 2009 14:01:31 -0400
Subject: bug in oct-cmplx.h?
In-Reply-To: <4AAFBFBA.4010604@gmx.de>
References: <4AAFA0DC.7040801@gmx.de> <19119.43811.56434.777809@segfault.lan>
	<4AAFBFBA.4010604@gmx.de>
Message-ID: <19119.54907.183523.619401@segfault.lan>

On 15-Sep-2009, Thorsten Meyer wrote:

| John W. Eaton wrote:
| > On 15-Sep-2009, Thorsten Meyer wrote:
| >
| > | I always thought that ./config.status --recheck did the same as
| > | ./configure (only that it saved me retyping the detailed configure
| > | options).  Apparently, this is not (always) the case. Can you explain?
| >
| > Read the description of the --recheck option in the autoconf manual.
| > I don't think it does what you expect.  I think this is an autoconf
| > issue, but perhaps we could have better integration of autoconf and
| > Make, so that things are updated correctly and automatically when
| > there are changes to the configure scripts.  That we generally need to
| > run autogen.sh and configure when things change doesn't bother me too
| > much, so I'm unlikely to make changes, but I would of course consider
| > patches.
| >   
| I have been using the make target "configfiles", that actually tries to
| update the configuration files correctly. Only it's broken for config.h
| (I did not realize that config.h is generated by config.status just like
| the Makefiles when I implemented it).
| 
| Included is a simple patch that should fix the "configfiles" target wrt
| config.h.

OK, I made a slightly different change as a part of a larger set of
tweaks to the configure script:

  http://hg.savannah.gnu.org/hgweb/octave/rev/4531741e5236

Thanks,

jwe

From highegg at gmail.com  Tue Sep 15 14:22:58 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 15 Sep 2009 21:22:58 +0200
Subject: user function return values
In-Reply-To: <19119.47134.165354.742211@segfault.lan>
References: <69d8d540909150834w37202c24mdd2a9b602bb7c231@mail.gmail.com>
	<19119.47134.165354.742211@segfault.lan>
Message-ID: <69d8d540909151222s3ecd3593i84dd581353571528@mail.gmail.com>

On Tue, Sep 15, 2009 at 5:51 PM, John W. Eaton <jwe at octave.org> wrote:
> On 15-Sep-2009, Jaroslav Hajek wrote:
>
> | Today I discovered that user functions called via feval would always
> | return an octave_value_list of length equal to the number of declared
> | parameters, padded by undefined values for undefined outputs. I'm not
> | 100% sure this was a bug, but I found it very surprising and quite
> | unexpected for extern apps embedding octave; for instance, I was
> | getting surprising bugs in pytave for very simple and correct calls.
> | So I took the liberty to change it:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/080e11f1b0c1
> |
> | If nargout is >= 1, return first nargout values from the output list,
> | incl. undefined values.
> | If nargout == 0, return the 1st value from the list if it is defined,
> | otherwise return 0.
> |
> | The main point is to prevent undefined values being returned in the
> | list, unless the function actually didn't define the requested number
> | of output values.
> |
> | make check passes for me, but chances still are that this may break
> | something, so if you see a gotcha, please let me know.
>
> Did this problem only show up if using feval from C++, or could it
> also be seen from interpreted code? ?If the latter, then can you give
> an example?
>

I don't think so. I think the code handling assignment copes up with
the excess variables.
At least I couldn't figure out a way to demonstrate this.

> Do you intend to use the test_feval function in a test? ?If so, then I
> think it shoudl be renamed __test_feval__ or something. ?Otherwise, if
> it was just for debugging, maybe it should be removed?
>

Oops. Sorry, that was a debugging hack. I removed it.
But doing a test sounds like a good idea, only I'm not sure creating a
built-in function for each test is OK.
Maybe there could be a special DLD function doing some basic tests for
the C++ interface?

-- 
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  Tue Sep 15 14:40:54 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 15 Sep 2009 15:40:54 -0400
Subject: user function return values
In-Reply-To: <69d8d540909151222s3ecd3593i84dd581353571528@mail.gmail.com>
References: <69d8d540909150834w37202c24mdd2a9b602bb7c231@mail.gmail.com>
	<19119.47134.165354.742211@segfault.lan>
	<69d8d540909151222s3ecd3593i84dd581353571528@mail.gmail.com>
Message-ID: <19119.60870.165566.900565@segfault.lan>

On 15-Sep-2009, Jaroslav Hajek wrote:

| Oops. Sorry, that was a debugging hack. I removed it.
| But doing a test sounds like a good idea, only I'm not sure creating a
| built-in function for each test is OK.
| Maybe there could be a special DLD function doing some basic tests for
| the C++ interface?

If you want to do this, then yes, I think it should be a .oct file
with a name like __cxx_interface_test__ or something.  Maybe it should
only be built to be used by the tests and not installed?

jwe

From godfrey at isl.stanford.edu  Wed Sep 16 00:33:10 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Tue, 15 Sep 2009 22:33:10 -0700
Subject: Documentation for backend("fltk")
Message-ID: <4AB07896.2070909@isl.stanford.edu>

I have been thinking about how to organize the documentation
for the fltk_OpenGL plotting feature.   Below is the beginning of an
updated plot.texi.  This indicates what I have in mind.  The main
problem, if the organization below seems reasonable, is how to
update the "Advanced Plotting" section.  One possibility is to
start with the features that are the same in both fltk and gnuplot
and then have 2 subsections which describe the features that
are specific to each plotting system.  This may get a bit confusing.

In any case, it would help if I could get reactions to this and
suggestions for a better structure.

First piece of plot.texi:

@node Plotting
@chapter Plotting
@cindex plotting
@cindex graphics

@menu
* Introduction::
* Basic Plotting::
* Graphics Handles::
* Advanced Plotting::
@end menu

@node Introduction
@section Introduction

Earlier versions of Octave provided plotting through the use of
gnuplot. This capability is still available.  But, a newer plotting
capability is provided by access to OpenGL.  Which plotting system
is used is controlled by the @code{backend} function.

@code{backend("fltk")} selects the FLTK_OpenGL system, and
@code{backend("gnuplot")} selects the gnuplot system.
The two systems may be used selectively through the use of the 
@code{backend}
property of the the graphics handle for each figure.  This is
more fully explained in @ref{Graphics Handles}.

@node Basic Plotting
@section Basic Plotting
=======================basic plotting as it is goes here==============
@node Graphics Handles
@section Graphics Handles

Graphics handles provide a uniform means of storing and manipulating
the properties of graphics objects.  The get and set commands are
used to obtain and set graphics handle properties.

A graphics handle property may be referenced by:

get(h, "property")

where h is a graphics handle and property is one of its properties.

The allowed properties of a graphics handle may be displayed by:
@code{get(h, "");}

Thus, for example,

@example
@group
h = figure();
get(h, "");
@end group
@end example

will display the allowed properties of the ``figure'' handle.
And,

@example
@group
aa=axes();
get(aa,"");
@end group
@end example

will display the allowed properties of the ``axes'' handle.

The root figure has index 0.  Its properties may be displayed by:

@code{get(0,"");}

The available graphics handles are: @code{figure}, @code{axes},
@code{line}, @code{text}, @code{patch},
and @code{surface}.
(@code{image} is still available, but is deprecated and will be removed.)


@node Advanced Plotting
@section Advanced Plotting
================Advanced Plotting with additional sections follows,
but with handle stuff move up to the section above==============

Michael


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090915/9954e16f/attachment.html 

From shaiay at gmail.com  Wed Sep 16 01:21:29 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Wed, 16 Sep 2009 09:21:29 +0300
Subject: Documentation for backend("fltk")
In-Reply-To: <4AB07896.2070909@isl.stanford.edu>
References: <4AB07896.2070909@isl.stanford.edu>
Message-ID: <420fb9e60909152321s481b7f19m836c83997567b867@mail.gmail.com>

On Wed, Sep 16, 2009 at 8:33 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> I have been thinking about how to organize the documentation
> for the fltk_OpenGL plotting feature.?? Below is the beginning of an
> updated plot.texi.? This indicates what I have in mind.? The main
> problem, if the organization below seems reasonable, is how to
> update the "Advanced Plotting" section.? One possibility is to
> start with the features that are the same in both fltk and gnuplot
> and then have 2 subsections which describe the features that
> are specific to each plotting system.? This may get a bit confusing.
>
> In any case, it would help if I could get reactions to this and
> suggestions for a better structure.
>
> First piece of plot.texi:
>
> @node Plotting
> @chapter Plotting
> @cindex plotting
> @cindex graphics
>
> @menu
> * Introduction::
> * Basic Plotting::
> * Graphics Handles::
> * Advanced Plotting::
> @end menu
>
> @node Introduction
> @section Introduction
>
> Earlier versions of Octave provided plotting through the use of
> gnuplot. This capability is still available.? But, a newer plotting
> capability is provided by access to OpenGL.? Which plotting system
> is used is controlled by the @code{backend} function.
>
> @code{backend("fltk")} selects the FLTK_OpenGL system, and
> @code{backend("gnuplot")} selects the gnuplot system.
> The two systems may be used selectively through the use of the
> @code{backend}
> property of the the graphics handle for each figure.? This is
> more fully explained in @ref{Graphics Handles}.
>
> @node Basic Plotting
> @section Basic Plotting
> =======================basic plotting as it is goes here==============
> @node Graphics Handles
> @section Graphics Handles
>
> Graphics handles provide a uniform means of storing and manipulating
> the properties of graphics objects.? The get and set commands are
> used to obtain and set graphics handle properties.
>
> A graphics handle property may be referenced by:
>
> get(h, "property")
>
> where h is a graphics handle and property is one of its properties.
>
> The allowed properties of a graphics handle may be displayed by:
> @code{get(h, "");}
>
> Thus, for example,
>
> @example
> @group
> h = figure();
> get(h, "");
> @end group
> @end example
>
> will display the allowed properties of the ``figure'' handle.
> And,
>
> @example
> @group
> aa=axes();
> get(aa,"");
> @end group
> @end example
>
> will display the allowed properties of the ``axes'' handle.
>
> The root figure has index 0.? Its properties may be displayed by:
>
> @code{get(0,"");}
>
> The available graphics handles are: @code{figure}, @code{axes},
> @code{line}, @code{text}, @code{patch},
> and @code{surface}.
> (@code{image} is still available, but is deprecated and will be removed.)
>
>
> @node Advanced Plotting
> @section Advanced Plotting
> ================Advanced Plotting with additional sections follows,
> but with handle stuff move up to the section above==============
>

It looks good to me, although (as you wrote in the documentation), all
the handle graphics stuff is in octave core and not coupled to any
specific backend such as gnuplot or fltk/open_gl
The backend specific sections should include specific
problems/features of a particular back end -- i.e. fltk backend does
not support printing yet, gnuplot might be slower for on-screen
graphics etc ....

Shai


From thorsten.meyier at gmx.de  Wed Sep 16 02:29:44 2009
From: thorsten.meyier at gmx.de (Thorsten Meyer)
Date: Wed, 16 Sep 2009 09:29:44 +0200
Subject: plot templates and options lists for set, plot etc.
In-Reply-To: <4A510BF1.1030004@gmx.de>
References: <h0e1im$k1b$1@ger.gmane.org>	<834BB2D5-476C-467E-AA4F-173C3AC3819E@mac.com>	<4A2A9C98.7040905@gmx.de>	<18987.46745.291803.265226@segfault.lan>	<F3C0D7A0-B92A-49CA-BD4E-32E45A6EA8C3@mac.com>	<18987.55627.712999.228501@segfault.lan>	<4A3FF9AB.7080103@gmx.de>	<19010.23227.606968.13598@segfault.lan>	<197FE62F-CA51-4052-ADC5-E09A39252CE6@mac.com>	<4A508D30.2000108@gmx.de>	<7A4FF226-DC6F-4225-BA17-E0A4D2D280DA@mac.com>	<4A50F894.6060505@gmx.de>
	<4A510BF1.1030004@gmx.de>
Message-ID: <4AB093E8.5050809@gmx.de>

Thorsten Meyer wrote:
> Here is a patch implementing struct and cell array arguments for the set function.
> 
> I have impplemented the matlab behaviour (as I understand it ...). See the tests
>  added to the patch for the details.
> 
> Could somebody please review the patch (what I do in the sources is still a lot
> of trial and error):
>  - Have I got the types of the various variables right?
>  - Is it ok to add doxygen style comments to the new methods? (the doxygen docs
> have helped me a lot to find my way in the sources)
>  - What about the coding style?
>  - Are the added methods for the graphics_object ok (also where I placed the
> definitions)?
> 
May I remind you of this patch of mine?
I attach an updated version. It compiles nicely and passes the tests I have
added to demonstrate and check the new behaviour. Yet, I still don't feel
confident enough to push it without review by someone with a better
understanding of the sources.

thanks

Thorsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_set_syntax.patch
Type: text/x-patch
Size: 9625 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090916/e6604caa/attachment-0001.bin 

From jwe at octave.org  Wed Sep 16 02:43:04 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 16 Sep 2009 03:43:04 -0400
Subject: plot templates and options lists for set, plot etc.
In-Reply-To: <4AB093E8.5050809@gmx.de>
References: <h0e1im$k1b$1@ger.gmane.org>
	<834BB2D5-476C-467E-AA4F-173C3AC3819E@mac.com>
	<4A2A9C98.7040905@gmx.de> <18987.46745.291803.265226@segfault.lan>
	<F3C0D7A0-B92A-49CA-BD4E-32E45A6EA8C3@mac.com>
	<18987.55627.712999.228501@segfault.lan> <4A3FF9AB.7080103@gmx.de>
	<19010.23227.606968.13598@segfault.lan>
	<197FE62F-CA51-4052-ADC5-E09A39252CE6@mac.com>
	<4A508D30.2000108@gmx.de>
	<7A4FF226-DC6F-4225-BA17-E0A4D2D280DA@mac.com>
	<4A50F894.6060505@gmx.de> <4A510BF1.1030004@gmx.de>
	<4AB093E8.5050809@gmx.de>
Message-ID: <19120.38664.367047.840593@segfault.lan>

On 16-Sep-2009, Thorsten Meyer wrote:

| Thorsten Meyer wrote:
| > Here is a patch implementing struct and cell array arguments for the set function.
| > 
| > I have impplemented the matlab behaviour (as I understand it ...). See the tests
| >  added to the patch for the details.
| > 
| > Could somebody please review the patch (what I do in the sources is still a lot
| > of trial and error):
| >  - Have I got the types of the various variables right?

| >  - Is it ok to add doxygen style comments to the new methods? (the
| >    doxygen docs

I don't use Doxygen, so I'm unlikely to remember to add the markup in
the comments I write.  If we decide to do this, then I think we should
try to do it on a more global scale.

| >  - What about the coding style?
| >  - Are the added methods for the graphics_object ok (also where I placed the
| > definitions)?

I try to keep the order of the declarations in the .h file the same as
the order in the .cc file.  If you've done that, then it is probably
OK.

| +//! Set properties given in two cell arrays containing names and values.
| +void
| +graphics_object::set (const Array<std::string> names,
| +                      const Cell values, octave_idx_type row)

I think this should be 

  graphics_object::set (const Array<std::string>& names,
                        const Cell& values, octave_idx_type row)

| +  if (! (names.numel () == values.columns ())) 

Why use

  ! (x == y)

instead of

  x != y

?

| +void
| +graphics_object::set (const Octave_map m)

This should be

  void
  graphics_object::set (const Octave_map& m)

| +//! Set a property to a value or to its (factory) default value.
| +void graphics_object::set_value_or_default (caseless_str& name,
| +                                            octave_value& val)

I think this should be

  void
  graphics_object::set_value_or_default (const caseless_str& name,
                                         const octave_value& val)

unless the function needs to modify NAME and VAL.  It doesn't appear
need to.

| +  if (val.is_string ())
| +    {
| +      caseless_str tval = val.string_value ();
| +
| +      if (tval.compare ("default"))
| +        val = get_default (name);
| +      else if (tval.compare ("factory"))
| +        val = get_factory_default (name);
| +    }
| +
| +  if (error_state)
| +    return;
| +
| +  rep->set (name, val);
| +}

With the non-const VAL, if VAL is a string, then it will also be
changed in the caller.  Is that really what you want?  I think it
would be better to define a local temporary value inside the
function.

jwe

From bpabbott at mac.com  Wed Sep 16 06:14:30 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 16 Sep 2009 07:14:30 -0400
Subject: Developers Sources on Mac OSX
Message-ID: <D54FA02B-0808-4756-AC76-DD098255369D@mac.com>

John,

After rebuilding all dependencies on Snow Leopard and adding your  
recent "configure tweaks", I'm able to build again! (Thanks!)

I only have one failure during "make check", for imread

   scripts/image/imread.m ................................. PASS     
0/1    FAIL 1

 >>>>> processing /Users/bpabbott/Development/mercurial/local_clone/ 
scripts/image/imread.m
   ***** test
  vpng = [ ...
   137,  80,  78,  71,  13,  10,  26,  10,   0,   0, ...
     0,  13,  73,  72,  68,  82,   0,   0,   0,   3, ...
     0,   0,   0,   3,   8,   2,   0,   0,   0, 217, ...
    74,  34, 232,   0,   0,   0,   1, 115,  82,  71, ...
    66,   0, 174, 206,  28, 233,   0,   0,   0,   4, ...
   103,  65,  77,  65,   0,   0, 177, 143,  11, 252, ...
    97,   5,   0,   0,   0,  32,  99,  72,  82,  77, ...
     0,   0, 122,  38,   0,   0, 128, 132,   0,   0, ...
   250,   0,   0,   0, 128, 232,   0,   0, 117,  48, ...
     0,   0, 234,  96,   0,   0,  58, 152,   0,   0, ...
    23, 112, 156, 186,  81,  60,   0,   0,   0,  25, ...
    73,  68,  65,  84,  24,  87,  99,  96,  96,  96, ...
   248, 255, 255,  63, 144,   4,  81, 111, 101,  84, ...
    16,  28, 160,  16,   0, 197, 214,  13,  34,  74, ...
   117, 213,  17,   0,   0,   0,   0,  73,  69,  78, ...
    68, 174,  66,  96, 130];
  fid = fopen('test.png', 'wb');
  fwrite(fid, vpng);
  fclose(fid);
  A = imread('test.png');
  delete('test.png');
  assert(A(:,:,1), uint8 ([0, 255, 0; 255, 237, 255; 0, 255, 0]));
  assert(A(:,:,2), uint8 ([0, 255, 0; 255,  28, 255; 0, 255, 0]));
  assert(A(:,:,3), uint8 ([0, 255, 0; 255,  36, 255; 0, 255, 0]));
!!!!! test failed
imread: invalid image file: Magick++ exception: Magick: No decode  
delegate for this image format (/Users/bpabbott/Development/mercurial/ 
local_clone/test/test.png) reported by magick/constitute.c:8413  
(ReadImage)>>>>> processing /Users/bpabbott/Development/mercurial/ 
local_clone/scripts/image/imshow.m

I never had this failure before. On the other hand, the one consistent  
failure I had for data.cc is gone (where an Inf was repleced by a NaN).

In any event, as time permits, and I can build again, I hope to become  
more active.

In the meantime, I'm unfamiliar with imread. I assume it relies upon  
imagemagick? My imagemagick is 6.4.1, if anyone can offer some advice,  
I'd appreciate it.

Ben



From soren at hauberg.org  Wed Sep 16 06:17:09 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 16 Sep 2009 13:17:09 +0200
Subject: Developers Sources on Mac OSX
In-Reply-To: <D54FA02B-0808-4756-AC76-DD098255369D@mac.com>
References: <D54FA02B-0808-4756-AC76-DD098255369D@mac.com>
Message-ID: <1253099829.4403.17.camel@sh-t400>

ons, 16 09 2009 kl. 07:14 -0400, skrev Ben Abbott:
> In the meantime, I'm unfamiliar with imread. I assume it relies upon  
> imagemagick? My imagemagick is 6.4.1, if anyone can offer some advice,  
> I'd appreciate it.

It's actually depending on GraphicsMagick and not ImageMagick, so that's
probably where you need to look.

S?ren


From bpabbott at mac.com  Wed Sep 16 06:40:21 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 16 Sep 2009 07:40:21 -0400
Subject: Developers Sources on Mac OSX
In-Reply-To: <1253099829.4403.17.camel@sh-t400>
References: <D54FA02B-0808-4756-AC76-DD098255369D@mac.com>
	<1253099829.4403.17.camel@sh-t400>
Message-ID: <C8714B68-8B63-4B20-AE30-6F973BF0B9F2@mac.com>


On Sep 16, 2009, at 7:17 AM, S?ren Hauberg wrote:

> ons, 16 09 2009 kl. 07:14 -0400, skrev Ben Abbott:
>> In the meantime, I'm unfamiliar with imread. I assume it relies upon
>> imagemagick? My imagemagick is 6.4.1, if anyone can offer some  
>> advice,
>> I'd appreciate it.
>
> It's actually depending on GraphicsMagick and not ImageMagick, so  
> that's
> probably where you need to look.
>
> S?ren

Ok. That explains it. Fink just recently added the GraphicsMagick  
package.

Ben
  

From marco_atzeri at yahoo.it  Wed Sep 16 10:12:27 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Wed, 16 Sep 2009 15:12:27 +0000 (GMT)
Subject: R: 3.2.3 RC4
In-Reply-To: <69d8d540909140038h47400cc4v543b83de80b22bf4@mail.gmail.com>
Message-ID: <868612.73930.qm@web25507.mail.ukl.yahoo.com>

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

> Da: Jaroslav Hajek <highegg at gmail.com>
> Oggetto: 3.2.3 RC4
> A: "octave maintainers list" <maintainers at octave.org>
> Data: Luned? 14 settembre 2009, 09:38
> hi all,
> 
> the Octave 3.2.3 RC4 tarballs are here:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> changes since RC3:
> 
> changeset:???9430:aecd82b05d32
> user:? ? ? ? John W. Eaton <jwe at octave.org>
> date:? ? ? ? Wed Sep 09 14:14:32 2009
> +0200
> summary:? ???pr-output.cc: new test
> 
> changeset:???9431:ee803fe0ec6b
> user:? ? ? ? John W. Eaton <jwe at octave.org>
> date:? ? ? ? Wed Sep 09 14:14:32 2009
> +0200
> summary:? ???dlmwrite.m: fix typo
> 
> changeset:???9432:f8925ecf14af
> user:? ? ? ? John W. Eaton <jwe at octave.org>
> date:? ? ? ? Wed Sep 09 14:15:04 2009
> +0200
> summary:? ???abort if floating point
> format is not recognized as IEEE
> 
> changeset:???9433:2a4231dbbcd1
> user:? ? ? ? Ben Abbott <bpabbott at mac.com>
> date:? ? ? ? Mon Sep 14 07:55:15 2009
> +0200
> summary:? ???gnuplot_drawnow.m: Avoid
> flickering plot windows.
> 
> changeset:???9434:f9e65ffeadf2
> user:? ? ? ? Alexander Mamonov <mamonov at gmail.com>
> date:? ? ? ? Mon Sep 14 07:57:38 2009
> +0200
> summary:? ???image/imread.m Test
> added.
> 
> changeset:???9435:bfb655164e6f
> user:? ? ? ? John W. Eaton <jwe at octave.org>
> date:? ? ? ? Mon Sep 14 07:57:38 2009
> +0200
> summary:? ???imread.m: fix test
> 
> changeset:???9436:6cd2e50ba1eb
> tag:? ? ? ???qparent
> tag:? ? ? ???3-2-3-rc4
> user:? ? ? ? John W. Eaton <jwe at octave.org>
> date:? ? ? ? Mon Sep 14 08:01:39 2009
> +0200
> summary:? ???lo-ieee.cc: include
> cstdlib, update copyright date
> 
> the only major issue fixed since RC3 was the gnuplot mouse
> zooming
> problem, which I hope is now fixed.
> 
> unless there are new or persisting serious problems, these
> tarballs
> will become the 3.2.3 release at Friday 18.9.

Hi Jaroslav,
on cygwin-1.7, it build fine and pass all the tests.

The gnuplot mouse zooming is not working

$ gnuplot --version
gnuplot 4.2 patchlevel 4 

but I presume is a gnuplot issue more than an octave
one. I am not really familiar with the issue.

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

Regards
Marco



      


From jwe at octave.org  Wed Sep 16 16:14:54 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 16 Sep 2009 17:14:54 -0400
Subject: gnulib and automake
Message-ID: <19121.21838.419944.184758@segfault.lan>

Instead of the current ad-hoc way of including portability and
replacement functions (things like mkdir, rmdir, strftime, etc.) in
Octave, I would like to start using functions from gnulib
(http://www.gnu.org/software/gnulib).  By using gnulib, we should get
improved portability and in some cases better or newer versions of
some of the replacement functions that we are currently using.

To see what would be required, I started trying to modify Octave's
configure scripts to use gnulib, but quickly found that it is fairly
complex to use gnulib without also using automake.

I've resisted using automake in the past because it seemed that it
would be a fairly large job to convert Octave's existing build
environment.  But at this point, I'm willing to give it a try just to
get gnulib working.

Switching to automake and using gnulib may mean some additional
disruption in building Octave during the transition.  Some changes to
the way Octave is built from the Mercurial archive may be needed.  At
the very least, you will need to have some way to get modules from
gnulib if you don't already have them.  But the rules for this should
all be in the configure (or bootstrap/autogen.sh) script, so you
should really only need a network connection, and then only if you
don't already have the necessary modules.

Are there any strong objections to making this change?

Is anyone on the list an expert automake user who would be willing to
help with the transition?

Thanks,

jwe

From tmacchant at yahoo.co.jp  Wed Sep 16 16:40:36 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 17 Sep 2009 06:40:36 +0900 (JST)
Subject: R: 3.2.3 RC4
In-Reply-To: <868612.73930.qm@web25507.mail.ukl.yahoo.com>
Message-ID: <20090916214036.8963.qmail@web3813.mail.bbt.yahoo.co.jp>

Hello

--- Marco Atzeri <marco_atzeri at yahoo.it> wrote:
> The gnuplot mouse zooming is not working
> 
> $ gnuplot --version
> gnuplot 4.2 patchlevel 4 
> 
> but I presume is a gnuplot issue more than an octave
> one. I am not really familiar with the issue.
> 
The main purpose of the patch by Ben is for kick out flicking plot issue.

If you execute the script like the below on the octave-3.2.2

for n=1:10
 plot(1;n);
 drawnow;
end

The plots will suffer ftom flicking.

This is fixed 3.2.3-RC1 for x11.
I noticed this issue not fixed for windows amd wxt termninals and the patch by Ben should be applied
to windows and wxt terminal.  That is main point of this issue.

The mouse zooming of 2D plot for the data from pipe can be possible the gnuplot ver. 4.3 (cvs) which
is newer than 2007 August.  On the gnuplot 4.2, the mouse zoom on 2d plot is not possibble.

This is mentioned in the OctaveForWindowsWiki at cygwin version being described.

Please see 
http://wiki.octave.org/wiki.pl?OctaveForWindows

I provide that gnuplot ver. 4.3 (cvs) for both cygwin-1.5 and cygwin-1.7 on my web site.

Regards

Tatsuro
 

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

From godfrey at isl.stanford.edu  Wed Sep 16 23:19:03 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 16 Sep 2009 21:19:03 -0700
Subject: terminology: handles, figures, objects, etc.
Message-ID: <4AB1B8B7.2020503@isl.stanford.edu>

I have seen (I think) graphics properties defined as
graphics objects and graphics handles.  So, there
seem to be 3 names in use: properties, objects, and
handles.  I believe that properties or objects are the "things"
and handles are the pointers.  In addition, the term index
appears to mean the class of handles and figures.

But, maybe their are other views.

In any case, what is the official terminology?
The choice seems to be between properties and
objects.

I plan to use the term Structures in titles which refer to sections
dealing with handles, figures and their objects? OK?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090916/83859b3b/attachment.html 

From godfrey at isl.stanford.edu  Wed Sep 16 23:31:54 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 16 Sep 2009 21:31:54 -0700
Subject: correction: terminology: handles, figures, objects, etc.
Message-ID: <4AB1BBBA.8050101@isl.stanford.edu>

Sorry for the typo:
for "But, maybe their are other views."
read "But, maybe there are other views."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090916/2a42ceb3/attachment.html 
-------------- next part --------------
An embedded message was scrubbed...
From: Michael D Godfrey <godfrey at isl.stanford.edu>
Subject: terminology: handles, figures, objects, etc.
Date: Wed, 16 Sep 2009 21:19:03 -0700
Size: 7315
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090916/2a42ceb3/attachment.mht 

From shaiay at gmail.com  Wed Sep 16 23:44:59 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 17 Sep 2009 07:44:59 +0300
Subject: terminology: handles, figures, objects, etc.
In-Reply-To: <4AB1B8B7.2020503@isl.stanford.edu>
References: <4AB1B8B7.2020503@isl.stanford.edu>
Message-ID: <420fb9e60909162144g5ad0643w316c6bacff2d11cb@mail.gmail.com>

On Thu, Sep 17, 2009 at 7:19 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> I have seen (I think) graphics properties defined as
> graphics objects and graphics handles.? So, there
> seem to be 3 names in use: properties, objects, and
> handles.? I believe that properties or objects are the "things"
> and handles are the pointers.? In addition, the term index
> appears to mean the class of handles and figures.
>
> But, maybe their are other views.
>
> In any case, what is the official terminology?
> The choice seems to be between properties and
> objects.
>
> I plan to use the term Structures in titles which refer to sections
> dealing with handles, figures and their objects? OK?
>

My understanding is that we have objects which are "high-level"
constructs such as lines, axes, etc... The objects are reference by
their handle which is a unique identifier
Each of these objects has properties (i.e. lines have width, xdata, etc...)
so the "set(h,prop,val)" function sets the property "prop" of the
object refernced by the handle "h" to the value "val"

Shai


From shaiay at gmail.com  Thu Sep 17 03:53:00 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 17 Sep 2009 11:53:00 +0300
Subject: fltk_backend patch to fix keyboard commands
Message-ID: <420fb9e60909170153p8dff229ubbe67c4b0e24eec4@mail.gmail.com>

keyboard commands "a" and "g" now affect the axes under the mouse
pointer rather than the current axes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk_keyboard.patch
Type: text/x-diff
Size: 2593 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090917/ed9198b2/attachment-0001.bin 

From maho at riken.jp  Thu Sep 17 00:10:04 2009
From: maho at riken.jp (Maho NAKATA)
Date: Thu, 17 Sep 2009 14:10:04 +0900 (JST)
Subject: multiple precision version of BLAS and LAPACK
Message-ID: <20090917.141004.59640143160112045.maho@riken.jp>

Hi developers of octave,
my name is Nakata Maho, Japanese, who is interested in Octave.
Thanks for good software!

Just my interest, I have been developing multiple precision version
of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer of
SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
developing is from the SDPA-GMP.

I wonder what I can contribute to octave. Any advice is really appreciated.

[1] http://mplapack.sourceforge.net/
[2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html

Best,
-- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
   Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090917/e5faa5e6/attachment.bin 

From octave at phaselockedsystems.com  Thu Sep 17 08:45:02 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Thu, 17 Sep 2009 06:45:02 -0700
Subject: terminology: handles, figures, objects, etc.
In-Reply-To: <4AB1B8B7.2020503@isl.stanford.edu>
References: <4AB1B8B7.2020503@isl.stanford.edu>
Message-ID: <4AB23D5E.9030202@phaselockedsystems.com>

An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090917/b13dcd53/attachment.html 

From octave at phaselockedsystems.com  Thu Sep 17 09:46:40 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Thu, 17 Sep 2009 07:46:40 -0700
Subject: plot templates and options lists for set, plot etc.
In-Reply-To: <19120.38664.367047.840593@segfault.lan>
References: <h0e1im$k1b$1@ger.gmane.org>	<834BB2D5-476C-467E-AA4F-173C3AC3819E@mac.com>	<4A2A9C98.7040905@gmx.de>
	<18987.46745.291803.265226@segfault.lan>	<F3C0D7A0-B92A-49CA-BD4E-32E45A6EA8C3@mac.com>	<18987.55627.712999.228501@segfault.lan>
	<4A3FF9AB.7080103@gmx.de>	<19010.23227.606968.13598@segfault.lan>	<197FE62F-CA51-4052-ADC5-E09A39252CE6@mac.com>	<4A508D30.2000108@gmx.de>	<7A4FF226-DC6F-4225-BA17-E0A4D2D280DA@mac.com>	<4A50F894.6060505@gmx.de>
	<4A510BF1.1030004@gmx.de>	<4AB093E8.5050809@gmx.de>
	<19120.38664.367047.840593@segfault.lan>
Message-ID: <4AB24BD0.5050105@phaselockedsystems.com>

John W. Eaton wrote:
> On 16-Sep-2009, Thorsten Meyer wrote:
>
> | Thorsten Meyer wrote:
> | > Here is a patch implementing struct and cell array arguments for the set function.
> | > 
> | > I have impplemented the matlab behaviour (as I understand it ...). See the tests
> | >  added to the patch for the details.
> | > 
> | > Could somebody please review the patch (what I do in the sources is still a lot
> | > of trial and error):
> | >  - Have I got the types of the various variables right?
>
> | >  - Is it ok to add doxygen style comments to the new methods? (the
> | >    doxygen docs
>
> I don't use Doxygen, so I'm unlikely to remember to add the markup in
> the comments I write.  If we decide to do this, then I think we should
> try to do it on a more global scale.
>   
One of the biggest problems with becoming a contributor to octave is 
trying to understand the structure and flow of the software.  Even after 
spending hours attempting to figure octave out I still don't really 
understand how things go together.  It is easy to say "ask for help" but 
such questions usually produce only perfunctory answers.

As far as I am concerned the consistent use of a tool like Doxygen is a 
convenient way ensuring that the code is appropriately and consistently 
commented.

We have standards for documenting m-files and oct-files so that the user 
is presented with consistent help text, why would we not do such a thing 
for the source code?  As much pain as it would be the payoff would be 
significant over time.


I don't care what tool we use, but doxygen seems to have become more or 
less a standard and it will produce various sorts of UML diagrams 
including static structure diagrams.  It will do this without any 
comments but the diagrams become very difficult to follow without some 
comments.  The downside to doxygen-style markup is that the comments 
themselves get a little clumsy, but that is far more true of the texinfo 
style doc structure we impose on user functions.

Just in general, it seems we should have a minimum level of comments in 
each file.  A header that describes what the classes are for, some 
comments for each method and some comments for all data elements.

Just some thoughts.

Bob

From godfrey at isl.stanford.edu  Thu Sep 17 09:51:45 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 17 Sep 2009 07:51:45 -0700
Subject: terminology: handles, figures, objects, etc.
In-Reply-To: <4AB23D5E.9030202@phaselockedsystems.com>
References: <4AB1B8B7.2020503@isl.stanford.edu>
	<4AB23D5E.9030202@phaselockedsystems.com>
Message-ID: <4AB24D01.9030706@isl.stanford.edu>

On 09/17/2009 06:45 AM, Robert T. Short wrote:
> A handle is a programmatic way to refer to the object.

This is sort of correct, but then ishandle() is a bit hard to explain,
since it returns false for some objects.

Michael



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

From tmacchant at yahoo.co.jp  Thu Sep 17 16:46:24 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Fri, 18 Sep 2009 06:46:24 +0900 (JST)
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <20090917.141004.59640143160112045.maho@riken.jp>
Message-ID: <20090917214624.38123.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello Maho NAKATA

I am not a developper but a tester of octave on windows/MinGW.
I cannot adveise you on this matter but can contribute to test on windows/MinGW.

BTW
I am very glad to see Japanse powerful staff comming to the octave list.
If your work on octave will be successful, it would be grateful for me your introducing your work to
Japanese octave users on the wiki site for Japanese octave users.

http://www40.atwiki.jp/gnuoctavejp

My web site (Japanes) for octave is

http://www.tatsuromatsuoka.com/octave/jpn/OctaveWinMemo.html

Regards

Tatsuro

--- Maho NAKATA wrote:

> Hi developers of octave,
> my name is Nakata Maho, Japanese, who is interested in Octave.
> Thanks for good software!
> 
> Just my interest, I have been developing multiple precision version
> of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer of
> SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
> MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
> developing is from the SDPA-GMP.
> 
> I wonder what I can contribute to octave. Any advice is really appreciated.
> 
> [1] http://mplapack.sourceforge.net/
> [2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html
> 
> Best,
> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>    Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
> 


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

From tmacchant at yahoo.co.jp  Thu Sep 17 16:46:32 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Fri, 18 Sep 2009 06:46:32 +0900 (JST)
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <20090917.141004.59640143160112045.maho@riken.jp>
Message-ID: <20090917214632.42679.qmail@web3805.mail.bbt.yahoo.co.jp>

Hello Maho NAKATA

I am not a developper but a tester of octave on windows/MinGW.
I cannot adveise you on this matter but can contribute to test on windows/MinGW.

BTW
I am very glad to see Japanse powerful staff comming to the octave list.
If your work on octave will be successful, it would be grateful for me your introducing your work to
Japanese octave users on the wiki site for Japanese octave users.

http://www40.atwiki.jp/gnuoctavejp

My web site (Japanes) for octave is

http://www.tatsuromatsuoka.com/octave/jpn/OctaveWinMemo.html

Regards

Tatsuro

--- Maho NAKATA wrote:

> Hi developers of octave,
> my name is Nakata Maho, Japanese, who is interested in Octave.
> Thanks for good software!
> 
> Just my interest, I have been developing multiple precision version
> of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer of
> SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
> MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
> developing is from the SDPA-GMP.
> 
> I wonder what I can contribute to octave. Any advice is really appreciated.
> 
> [1] http://mplapack.sourceforge.net/
> [2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html
> 
> Best,
> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>    Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
> 


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

From tmacchant at yahoo.co.jp  Thu Sep 17 16:46:32 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Fri, 18 Sep 2009 06:46:32 +0900 (JST)
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <20090917.141004.59640143160112045.maho@riken.jp>
Message-ID: <20090917214633.44612.qmail@web3811.mail.bbt.yahoo.co.jp>

Hello Maho NAKATA

I am not a developper but a tester of octave on windows/MinGW.
I cannot adveise you on this matter but can contribute to test on windows/MinGW.

BTW
I am very glad to see Japanse powerful staff comming to the octave list.
If your work on octave will be successful, it would be grateful for me your introducing your work to
Japanese octave users on the wiki site for Japanese octave users.

http://www40.atwiki.jp/gnuoctavejp

My web site (Japanes) for octave is

http://www.tatsuromatsuoka.com/octave/jpn/OctaveWinMemo.html

Regards

Tatsuro

--- Maho NAKATA wrote:

> Hi developers of octave,
> my name is Nakata Maho, Japanese, who is interested in Octave.
> Thanks for good software!
> 
> Just my interest, I have been developing multiple precision version
> of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer of
> SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
> MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
> developing is from the SDPA-GMP.
> 
> I wonder what I can contribute to octave. Any advice is really appreciated.
> 
> [1] http://mplapack.sourceforge.net/
> [2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html
> 
> Best,
> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>    Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
> 


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

From octave at phaselockedsystems.com  Thu Sep 17 17:16:46 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Thu, 17 Sep 2009 15:16:46 -0700
Subject: terminology: handles, figures, objects, etc.
In-Reply-To: <4AB24D01.9030706@isl.stanford.edu>
References: <4AB1B8B7.2020503@isl.stanford.edu>
	<4AB23D5E.9030202@phaselockedsystems.com>
	<4AB24D01.9030706@isl.stanford.edu>
Message-ID: <4AB2B54E.90809@phaselockedsystems.com>

An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090917/ce815702/attachment.html 

From chat95 at mac.com  Thu Sep 17 21:28:18 2009
From: chat95 at mac.com (Maho NAKATA)
Date: Fri, 18 Sep 2009 11:28:18 +0900 (JST)
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <514_1253223985_4AB2AE31_514_3123_1_20090917214624.38123.qmail@web3808.mail.bbt.yahoo.co.jp>
References: <20090917.141004.59640143160112045.maho@riken.jp>
	<514_1253223985_4AB2AE31_514_3123_1_20090917214624.38123.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <20090918.112818.850602504823363353.chat95@mac.com>

Hi Matsuoka-san

From: Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>
Subject: (SPAM) Re: multiple precision version of BLAS and LAPACK
Date: Fri, 18 Sep 2009 06:46:24 +0900 (JST)

> I am not a developper but a tester of octave on windows/MinGW.
> I cannot adveise you on this matter but can contribute to test on windows/MinGW.
glad to see you. I'm interested in mingw but I don't have much time to test.
mpack is still early stage, and please subscribe mpack mailing list
and i'm happy if we have some discussion.

Best,
-- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
   Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090918/c8ba87f0/attachment.bin 

From highegg at gmail.com  Fri Sep 18 00:52:26 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 18 Sep 2009 07:52:26 +0200
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <20090917.141004.59640143160112045.maho@riken.jp>
References: <20090917.141004.59640143160112045.maho@riken.jp>
Message-ID: <69d8d540909172252n33f2c082wd3733716ad8f4a7d@mail.gmail.com>

On Thu, Sep 17, 2009 at 7:10 AM, Maho NAKATA <maho at riken.jp> wrote:
> Hi developers of octave,
> my name is Nakata Maho, Japanese, who is interested in Octave.
> Thanks for good software!
>
> Just my interest, I have been developing multiple precision version
> of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer of
> SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
> MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
> developing is from the SDPA-GMP.
>
> I wonder what I can contribute to octave. Any advice is really appreciated.
>
> [1] http://mplapack.sourceforge.net/
> [2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html
>
> Best,
> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
> ? Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
>

Hello,

Octave can conveniently be extended using external C++ packages. If
you'd like to contribute a multi-precision package, probably the best
way to start is to check out David Bateman's fixed point numbers
package:
http://octave.sourceforge.net/fixed/
I don't think we want multiprecision computing in Octave's core now,
but that may change in the future.


hth

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


From chat95 at mac.com  Fri Sep 18 05:21:02 2009
From: chat95 at mac.com (Maho NAKATA)
Date: Fri, 18 Sep 2009 19:21:02 +0900 (JST)
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <69d8d540909172252n33f2c082wd3733716ad8f4a7d@mail.gmail.com>
References: <20090917.141004.59640143160112045.maho@riken.jp>
	<69d8d540909172252n33f2c082wd3733716ad8f4a7d@mail.gmail.com>
Message-ID: <20090918.192102.75173118738920117.chat95@mac.com>

Hello Jaroslav Hajek,

Many thanks for your kind reply. I'll look at it and maybe the
start from here looks very nice.

Best,

From: Jaroslav Hajek <highegg at gmail.com>
Subject: Re: multiple precision version of BLAS and LAPACK
Date: Fri, 18 Sep 2009 07:52:26 +0200

> On Thu, Sep 17, 2009 at 7:10 AM, Maho NAKATA <maho at riken.jp> wrote:
>> Hi developers of octave,
>> my name is Nakata Maho, Japanese, who is interested in Octave.
>> Thanks for good software!
>>
>> Just my interest, I have been developing multiple precision version
>> of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer of
>> SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
>> MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
>> developing is from the SDPA-GMP.
>>
>> I wonder what I can contribute to octave. Any advice is really appreciated.
>>
>> [1] http://mplapack.sourceforge.net/
>> [2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html
>>
>> Best,
>> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>> ? Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
>>
> 
> Hello,
> 
> Octave can conveniently be extended using external C++ packages. If
> you'd like to contribute a multi-precision package, probably the best
> way to start is to check out David Bateman's fixed point numbers
> package:
> http://octave.sourceforge.net/fixed/
> I don't think we want multiprecision computing in Octave's core now,
> but that may change in the future.
> 
> 
> hth
> 
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090918/4edca31f/attachment.bin 

From marco_atzeri at yahoo.it  Fri Sep 18 08:16:15 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Fri, 18 Sep 2009 13:16:15 +0000 (GMT)
Subject: Changeset: redefined library_path_var for cygwin
Message-ID: <384284.67283.qm@web25501.mail.ukl.yahoo.com>

John,
this complete your previous patch

http://hg.savannah.gnu.org/hgweb/octave/rev/16907d1153d1

now "make check" works fine also for cygwin

Regards
Marco



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hg_path_patch
Type: application/octet-stream
Size: 1034 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090918/232d1161/attachment-0001.obj 

From dbateman at dbateman.org  Fri Sep 18 11:26:22 2009
From: dbateman at dbateman.org (David Bateman)
Date: Fri, 18 Sep 2009 18:26:22 +0200
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <20090918.192102.75173118738920117.chat95@mac.com>
References: <20090917.141004.59640143160112045.maho@riken.jp>	<69d8d540909172252n33f2c082wd3733716ad8f4a7d@mail.gmail.com>
	<20090918.192102.75173118738920117.chat95@mac.com>
Message-ID: <4AB3B4AE.5090300@dbateman.org>

The fixed package was aimed at doing fixed point calculations for 
DSP/ASIC bit accurate analysis and do it fast. Typically 16 bit numbers 
or less are all that are used in that case.. GMP is for much larger 
numbers than that.. I'd suggest looking at the VPA type in the symbolic 
package instead.

David


Maho NAKATA wrote:
> Hello Jaroslav Hajek,
>
> Many thanks for your kind reply. I'll look at it and maybe the
> start from here looks very nice.
>
> Best,
>
> From: Jaroslav Hajek <highegg at gmail.com>
> Subject: Re: multiple precision version of BLAS and LAPACK
> Date: Fri, 18 Sep 2009 07:52:26 +0200
>
>   
>> On Thu, Sep 17, 2009 at 7:10 AM, Maho NAKATA <maho at riken.jp> wrote:
>>     
>>> Hi developers of octave,
>>> my name is Nakata Maho, Japanese, who is interested in Octave.
>>> Thanks for good software!
>>>
>>> Just my interest, I have been developing multiple precision version
>>> of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer of
>>> SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
>>> MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
>>> developing is from the SDPA-GMP.
>>>
>>> I wonder what I can contribute to octave. Any advice is really appreciated.
>>>
>>> [1] http://mplapack.sourceforge.net/
>>> [2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html
>>>
>>> Best,
>>> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>>>   Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
>>>
>>>       
>> Hello,
>>
>> Octave can conveniently be extended using external C++ packages. If
>> you'd like to contribute a multi-precision package, probably the best
>> way to start is to check out David Bateman's fixed point numbers
>> package:
>> http://octave.sourceforge.net/fixed/
>> I don't think we want multiprecision computing in Octave's core now,
>> but that may change in the future.
>>
>>
>> hth
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>>
>>     


-- 
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 octave at phaselockedsystems.com  Fri Sep 18 12:27:35 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Fri, 18 Sep 2009 10:27:35 -0700
Subject: terminology: handles, figures, objects, etc.
In-Reply-To: <4AB2D256.4010003@isl.stanford.edu>
References: <4AB1B8B7.2020503@isl.stanford.edu>
	<4AB23D5E.9030202@phaselockedsystems.com>
	<4AB24D01.9030706@isl.stanford.edu>
	<4AB2B54E.90809@phaselockedsystems.com>
	<4AB2D256.4010003@isl.stanford.edu>
Message-ID: <4AB3C307.5000805@phaselockedsystems.com>

Michael D Godfrey wrote:
> =============================================
> The above is true, but is not what the Manual says:
>
> ishandle (h) [Built-in Function]
> Return true if h is a graphics handle and false otherwise.
> ishghandle (h) [Function File]
> Return true if h is a graphics handle and false otherwise.
> isfigure (h) [Function File]
> Return true if h is a graphics handle that contains a figure object 
> and false otherwise
> =============================================
> I believed the Manual when I wrote the earlier email.
>
> So far the response suggests that a Section in the Manual devoted to 
> the precise
> definition of these terms would be a good idea.  I will circulate a 
> draft soon.
>
> Thanks,
> Michael
>
I don't see the problem, except maybe that a graphics handle doesn't 
"contain" a figure object but rather references one.

Anyway, whatever you write I promise to read.  A good description of the 
difference between classes, objects, handles, etc. would be a good 
addition to the manual.

Bob

From chat95 at mac.com  Sat Sep 19 04:11:36 2009
From: chat95 at mac.com (Maho NAKATA)
Date: Sat, 19 Sep 2009 18:11:36 +0900 (JST)
Subject: multiple precision version of BLAS and LAPACK
In-Reply-To: <4AB3B4AE.5090300@dbateman.org>
References: <69d8d540909172252n33f2c082wd3733716ad8f4a7d@mail.gmail.com>
	<20090918.192102.75173118738920117.chat95@mac.com>
	<4AB3B4AE.5090300@dbateman.org>
Message-ID: <20090919.181136.75173118738924240.chat95@mac.com>

Hi David Bateman,
Nice to meet you. ok, I'll invesitgate it.
Thanks

From: David Bateman <dbateman at dbateman.org>
Subject: Re: multiple precision version of BLAS and LAPACK
Date: Fri, 18 Sep 2009 18:26:22 +0200

> The fixed package was aimed at doing fixed point calculations for
> DSP/ASIC bit accurate analysis and do it fast. Typically 16 bit
> numbers or less are all that are used in that case.. GMP is for much
> larger numbers than that.. I'd suggest looking at the VPA type in the
> symbolic package instead.
>
> David
>
>
> Maho NAKATA wrote:
>> Hello Jaroslav Hajek,
>>
>> Many thanks for your kind reply. I'll look at it and maybe the
>> start from here looks very nice.
>>
>> Best,
>>
>> From: Jaroslav Hajek <highegg at gmail.com>
>> Subject: Re: multiple precision version of BLAS and LAPACK
>> Date: Fri, 18 Sep 2009 07:52:26 +0200
>>
>>
>>> On Thu, Sep 17, 2009 at 7:10 AM, Maho NAKATA <maho at riken.jp> wrote:
>>>
>>>> Hi developers of octave,
>>>> my name is Nakata Maho, Japanese, who is interested in Octave.
>>>> Thanks for good software!
>>>>
>>>> Just my interest, I have been developing multiple precision version
>>>> of BLAS and LAPACK, using qd/dd/gmp [1]. I have a principal developer
>>>> of
>>>> SDPA-GMP [2], semidefinite programming solver using GMP. Actually,
>>>> MPACK, multiple precision arithmetic version of BLAS and LAPACK I have
>>>> developing is from the SDPA-GMP.
>>>>
>>>> I wonder what I can contribute to octave. Any advice is really
>>>> appreciated.
>>>>
>>>> [1] http://mplapack.sourceforge.net/
>>>> [2] http://sdpa.indsys.chuo-u.ac.jp/sdpa/download.html
>>>>
>>>> Best,
>>>> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>>>>   Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
>>>>
>>>>
>>> Hello,
>>>
>>> Octave can conveniently be extended using external C++ packages. If
>>> you'd like to contribute a multi-precision package, probably the best
>>> way to start is to check out David Bateman's fixed point numbers
>>> package:
>>> http://octave.sourceforge.net/fixed/
>>> I don't think we want multiprecision computing in Octave's core now,
>>> but that may change in the future.
>>>
>>>
>>> hth
>>>
>>> --
>>> RNDr. Jaroslav Hajek
>>> computing expert & GNU Octave developer
>>> Aeronautical Research and Test Institute (VZLU)
>>> Prague, Czech Republic
>>> url: www.highegg.matfyz.cz
>>>
>>>
>
>
> --
> David Bateman                                dbateman at dbateman.org
> 35 rue Gambetta                              +33 1 46 04 02 18 (Home)
> 92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090919/85291861/attachment.bin 

From godfrey at isl.stanford.edu  Sat Sep 19 20:56:33 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 19 Sep 2009 18:56:33 -0700
Subject: terminology: handles, figures, objects, etc.
In-Reply-To: <4AB2D256.4010003@isl.stanford.edu>
References: <4AB1B8B7.2020503@isl.stanford.edu>
	<4AB23D5E.9030202@phaselockedsystems.com>
	<4AB24D01.9030706@isl.stanford.edu>
	<4AB2B54E.90809@phaselockedsystems.com>
	<4AB2D256.4010003@isl.stanford.edu>
Message-ID: <4AB58BD1.8090205@isl.stanford.edu>

On 09/17/2009 05:20 PM, Michael D Godfrey wrote:
> On 09/17/2009 03:16 PM, Robert T. Short wrote:
>> octave:1> f1 = figure(1);  %  This creates a figure object.  The 
>> handle is f1, but f1 is NOT an object.
>> octave:2> ishandle(f1)      %  You can see this by using ishandle and 
>> isobject.  The actual object is buried
>> ans =  1                            %   in the octave dataspace, and 
>> you can't get it directly but you CAN manipulate
>> octave:3> isobject(f1)       %  the properties through the handle.
>> ans = 0                             % Thus a handle is simple an 
>> opaque reference to the object.  It could be an index 
> =============================================
> The above is true, but is not what the Manual says:
>
> ishandle (h) [Built-in Function]
> Return true if h is a graphics handle and false otherwise.
> ishghandle (h) [Function File]
> Return true if h is a graphics handle and false otherwise.
> isfigure (h) [Function File]
> Return true if h is a graphics handle that contains a figure object 
> and false otherwise
> =============================================
> I believed the Manual when I wrote the earlier email.
>
> So far the response suggests that a Section in the Manual devoted to 
> the precise
> definition of these terms would be a good idea.  I will circulate a 
> draft soon.
>
> Thanks,
> Michael
Just noticed that this went only to Robert.
This is for the rest of the list.
Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090919/14795441/attachment.html 

From shaiay at users.sourceforge.net  Sun Sep 20 04:14:25 2009
From: shaiay at users.sourceforge.net (Shai Ayal)
Date: Sun, 20 Sep 2009 12:14:25 +0300
Subject: remove check for FTGL
Message-ID: <420fb9e60909200214v7ffcaeeer68dcdd3f071c138a@mail.gmail.com>

The attached patch removes the check for FTGL since we don't really
need it anymore - actually it was only planned to be used but never
used and bypassed by Michael Goffioul's text renderer

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove_ftgl.patch
Type: text/x-diff
Size: 3026 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090920/eac8c060/attachment.bin 

From shaiay at users.sourceforge.net  Sun Sep 20 12:45:14 2009
From: shaiay at users.sourceforge.net (Shai Ayal)
Date: Sun, 20 Sep 2009 20:45:14 +0300
Subject: decreasing compile time tricks?
Message-ID: <420fb9e60909201045r63229844gf7bf0c826afed99a@mail.gmail.com>

Hi

I have again started playing with the source (got a new modern
computer). I usually just change fltk_backend, but doing a make still
takes a few minuets and does lots of things.
I recall there were some options to reduce compile time -- can someone
remind me?


Shai

From highegg at gmail.com  Sun Sep 20 14:32:39 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 20 Sep 2009 21:32:39 +0200
Subject: decreasing compile time tricks?
In-Reply-To: <420fb9e60909201045r63229844gf7bf0c826afed99a@mail.gmail.com>
References: <420fb9e60909201045r63229844gf7bf0c826afed99a@mail.gmail.com>
Message-ID: <69d8d540909201232h3d455d7ahf09f149fc68d0a8e@mail.gmail.com>

On Sun, Sep 20, 2009 at 7:45 PM, Shai Ayal <shaiay at users.sourceforge.net> wrote:
> Hi
>
> I have again started playing with the source (got a new modern
> computer). I usually just change fltk_backend, but doing a make still
> takes a few minuets and does lots of things.
> I recall there were some options to reduce compile time -- can someone
> remind me?
>
>
> Shai
>

CXXFLAGS defaults to -O2 -g. For me, taking -g away always seemed to
speed things up noticeably (produces several times smaller binaries,
which might be the case), but you lose the debugging ability.

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

From octave at phaselockedsystems.com  Sun Sep 20 15:12:04 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Sun, 20 Sep 2009 13:12:04 -0700
Subject: decreasing compile time tricks?
In-Reply-To: <420fb9e60909201204l53cac622n3f736899900cb947@mail.gmail.com>
References: <420fb9e60909201045r63229844gf7bf0c826afed99a@mail.gmail.com>	
	<4AB6760D.7080600@phaselockedsystems.com>
	<420fb9e60909201204l53cac622n3f736899900cb947@mail.gmail.com>
Message-ID: <4AB68C94.8080003@phaselockedsystems.com>

An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090920/fff112b2/attachment.html 

From godfrey at isl.stanford.edu  Sun Sep 20 19:28:56 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 20 Sep 2009 17:28:56 -0700
Subject: Revisions to Plotting Sections of the Manual
Message-ID: <4AB6C8C8.9060107@isl.stanford.edu>

I have attached 2 PDF files just for comment.  These
show much of what I have done so far.  A lot still
needs to be done, but I would like to know anything
helpful about what I have.  Particularly, I would
like to know about mistakes or ways of expressing the
capabilities better.

Page 244 is the most important.  I intend to expand this
some, but would like to know if it seems not to be headed
in the right direction.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090920/55fd7763/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave_p205.pdf
Type: application/pdf
Size: 24926 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090920/55fd7763/attachment-0002.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave_p244-246.pdf
Type: application/pdf
Size: 56237 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090920/55fd7763/attachment-0003.pdf 

From highegg at gmail.com  Mon Sep 21 00:50:11 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 21 Sep 2009 07:50:11 +0200
Subject: Octave 3.2.3
Message-ID: <69d8d540909202250t5ba6dbafne607e65c63828888@mail.gmail.com>

hi all,

with another small delay, here are the 3.2.3 release tarballs:
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

thanks to all contributors for their help.

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

From shaiay at gmail.com  Mon Sep 21 03:36:10 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 21 Sep 2009 11:36:10 +0300
Subject: Revisions to Plotting Sections of the Manual
In-Reply-To: <4AB6C8C8.9060107@isl.stanford.edu>
References: <4AB6C8C8.9060107@isl.stanford.edu>
Message-ID: <420fb9e60909210136u94703edkd3c3d71fe3a2b2b7@mail.gmail.com>

On Mon, Sep 21, 2009 at 3:28 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> I have attached 2 PDF files just for comment.? These
> show much of what I have done so far.? A lot still
> needs to be done, but I would like to know anything
> helpful about what I have.? Particularly, I would
> like to know about mistakes or ways of expressing the
> capabilities better.
>
> Page 244 is the most important.? I intend to expand this
> some, but would like to know if it seems not to be headed
> in the right direction.

Some comments:
Section 15.3: In general, I think it might be clearer to talk about
the hierarchy of the graphics objects -- it root -> figure -> axes ->
(lines, surface, patch text) , where a->b means that the parent "a"
can have many children "b"
section 15.3.1: I don't think image should be depreciated - it is
essential and exists in the competing brand
Also, missing are the *series objects (barseries etc...)

Shai


From godfrey at isl.stanford.edu  Mon Sep 21 09:08:36 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Mon, 21 Sep 2009 07:08:36 -0700
Subject: Revisions to Plotting Sections of the Manual
In-Reply-To: <420fb9e60909210136u94703edkd3c3d71fe3a2b2b7@mail.gmail.com>
References: <4AB6C8C8.9060107@isl.stanford.edu>
	<420fb9e60909210136u94703edkd3c3d71fe3a2b2b7@mail.gmail.com>
Message-ID: <4AB788E4.8090607@isl.stanford.edu>

On 09/21/2009 01:36 AM, Shai Ayal wrote:
> section 15.3.1: I don't think image should be depreciated - it is
> essential and exists in the competing brand
>    
That was in the old Manual.  I will drop it.

And, thanks for the other suggestions.  All seem good to me.
Will take care of them.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090921/8ec33524/attachment.html 

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 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 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 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 tmacchant at yahoo.co.jp  Tue Sep 22 19:12:02 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 23 Sep 2009 09:12:02 +0900 (JST)
Subject: octave-3.3.50 built by mingw-gcc-4.4.0 cannot be executed.
Message-ID: <20090923001202.49818.qmail@web3807.mail.bbt.yahoo.co.jp>

Hello

I have built octave-3.3.50 mingw-gcc-4.4.0.

At the prompt I execute octave from the prompt

$ octave

$
 
Octave starts but finishes soon without any messages.
I have tried gdb traces.  Unfortunately liboctave.dll conflicts user.dll without striping debug
symbols.

However some information is obtained.

[New thread 3940.0x8c4]
warning: HEAP[octave.exe]:
warning: Invalid Address specified to RtlFreeHeap( 003F0000, 6FCB8FB8 )


set_liboctave_warning_with_id_handler (f=0x6e92ab78 <liboctinterp!_Z15warning_with_idPKcS0_z>)
    at ../../../../octave-3.3.50/libcruft/misc/lo-error.c:79

Benjamin have not been reported such errors so that the error intrinsic for my system.

Does anyone give me advises?

Regards

Tatsuro

Some of gdb traces.********************************************  
Breakpoint 1 at 0x4013b9: file ../../../octave-3.3.50/src/main.c, line 34.
(gdb) r
Starting program: c:\programs\octavebuild\bin/octave.exe
[New thread 3940.0x8c4]
warning: HEAP[octave.exe]:
warning: Invalid Address specified to RtlFreeHeap( 003F0000, 6FCB8FB8 )
  :
  :
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c94120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
  :
  :
61      {
(gdb) n
62        if (f)
(gdb) n
63          current_liboctave_error_handler = f;
(gdb) n
66      }
(gdb) n
0x6ea7b9eb in octave_main () from c:\programs\octavebuild\bin\liboctinterp.dll
(gdb) n
Single stepping until exit from function octave_main,
which has no line number information.
0x6ef4bbcc in xerbla_ () from c:\programs\octavebuild\bin\liboctinterp.dll
(gdb) n
Single stepping until exit from function xerbla_,
which has no line number information.
set_liboctave_warning_handler (f=0x6e92aba8 <liboctinterp!_Z7warningPKcz>)
    at ../../../../octave-3.3.50/libcruft/misc/lo-error.c:70
70      {
(gdb) n
71        if (f)
(gdb) n
72          current_liboctave_warning_handler = f;
(gdb) n
75      }
(gdb) n
0x6ea7b9f7 in octave_main () from c:\programs\octavebuild\bin\liboctinterp.dll
(gdb) n

0x6ea7b9f7 in octave_main () from c:\programs\octavebuild\bin\liboctinterp.dll
(gdb) n
Single stepping until exit from function octave_main,
which has no line number information.
0x6ef4bbd4 in xerbla_ () from c:\programs\octavebuild\bin\liboctinterp.dll
(gdb) n
Single stepping until exit from function xerbla_,
which has no line number information.
set_liboctave_warning_with_id_handler (f=0x6e92ab78 <liboctinterp!_Z15warning_with_idPKcS0_z>)
    at ../../../../octave-3.3.50/libcruft/misc/lo-error.c:79
79      {
(gdb) n
80        if (f)
(gdb) n
81          current_liboctave_warning_with_id_handler = f;
(gdb) n
84      }
(gdb) n
0x6ea7ba03 in octave_main () from c:\programs\octavebuild\bin\liboctinterp.dll
(gdb) n
Single stepping until exit from function octave_main,
which has no line number information.
warning: HEAP[octave.exe]:
warning: Invalid Address specified to RtlFreeHeap( 003F0000, 6FCB8FB8 )



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

From highegg at gmail.com  Wed Sep 23 05:50:48 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 23 Sep 2009 12:50:48 +0200
Subject: FYI: optimizing certain matrix arithmetic
Message-ID: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>

hi all,

the following three patches:
http://hg.savannah.gnu.org/hgweb/octave/rev/afcf852256d2
http://hg.savannah.gnu.org/hgweb/octave/rev/0d3b248f4ab6
http://hg.savannah.gnu.org/hgweb/octave/rev/7e5b4de5fbfe

add new optimizations for matrix multiplication and division. Quote for NEWS:

 ** More efficient matrix division handling. Octave is now able to
handle the expressions

       M' \ v
       M.' \ v
       v / M

    (M is a matrix and v is a vector) more efficiently in certain cases.
    In particular, if M is triangular, all three expressions will be
handled by a single call to
    xTRTRS, with appropriate flags. Previously, all three expressions
required a physical transpose
    of M.

 ** More efficient handling of certain mixed real-complex matrix operations.
    For instance, if RM is a real matrix and CM a complex matrix,

      RM * CM

    can now be evaluated either as

      complex (RM * real (CM), RM * imag (CM))

    or as

      complex (RM) * CM,

    depending on the dimensions. The 1st form requires more
temporaries and copying,
    but halves the count of FLOPs, which normally brings better performance if
    RM has enough rows. Previously, the 2nd form was always used.

    Matrix division is similarly affected.

The triangular optimization is well demonstrated by this benchmark:

n = 500;
R = triu (rand (n));
u = rand (n, 1);

tic; for i = 1:1000; R \ u; endfor; toc
tic; for i = 1:1000; u' / R; endfor; toc
tic; for i = 1:1000; R' \ u; endfor; toc

R = tril (rand (n));
u = rand (n, 1);

tic; for i = 1:1000; R \ u; endfor; toc
tic; for i = 1:1000; u' / R; endfor; toc
tic; for i = 1:1000; R' \ u; endfor; toc

u = u + I*rand (n, 1);
tic; for i = 1:1000; R \ u; endfor; toc
tic; for i = 1:1000; R' \ u; endfor; toc


with a recent tip, I got (Core 2 Duo @ 2.83 GHz, g++ -O3
-march=native, self-built GotoBLAS + LAPACK):

Elapsed time is 0.225974 seconds.
Elapsed time is 0.78818 seconds.
Elapsed time is 1.81756 seconds.
Elapsed time is 0.219842 seconds.
Elapsed time is 0.79384 seconds.
Elapsed time is 1.83497 seconds.
Elapsed time is 4.32738 seconds.
Elapsed time is 7.73774 seconds.

with the new patches, I get

Elapsed time is 0.221489 seconds.
Elapsed time is 0.204968 seconds.
Elapsed time is 0.204267 seconds.
Elapsed time is 0.219243 seconds.
Elapsed time is 0.20444 seconds.
Elapsed time is 0.202193 seconds.
Elapsed time is 0.227214 seconds.
Elapsed time is 0.209824 seconds.

This is particularly cool when working intensively with Cholesky, LU
or QR factorizations - you can do both A \ v and A' \ v almost as
efficiently as with raw BLAS.

Also, there's some speed-up with real x complex multiplication and
division, which is not a very common operation, but sometimes needed.
The point is that for bigger matrices, complex (RM * real (CM), RM *
imag (CM)) is typically up to 2x faster than complex (RM) * CM.
Surprised? Just count the FLOPs. On the other hand, the former
expression is less friendly for Octave's complex storage.

The benchmark is:

n = 800;
a = rand (n);
b = rand (n) + i*rand (n);
tic; a * b; toc
tic; b * a; toc
tic; a' * b; toc
tic; b * a'; toc
tic; a \ b; toc
tic; b / a; toc

with a recent tip:

Elapsed time is 0.431021 seconds.
Elapsed time is 0.410468 seconds.
Elapsed time is 0.411169 seconds.
Elapsed time is 0.412252 seconds.
Elapsed time is 0.641075 seconds.
Elapsed time is 0.66255 seconds.

with the new patches:

Elapsed time is 0.221522 seconds.
Elapsed time is 0.2183 seconds.
Elapsed time is 0.22033 seconds.
Elapsed time is 0.22058 seconds.
Elapsed time is 0.297738 seconds.
Elapsed time is 0.325542 seconds.

The conclusion is that Octave 3.4 will again be able to map linear
algebra code more efficiently onto BLAS and LAPACK than the previous
version.

-- 
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  Wed Sep 23 19:23:15 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 23 Sep 2009 17:23:15 -0700
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
Message-ID: <4ABABBF3.8040203@isl.stanford.edu>

Just for the record, a comparison with the "other system"
model name    : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping    : 2
cpu MHz        : 1000.000
cache size    : 512 KB
bogomips    : 2009.24

Other system:

 >> matrix_upd
Elapsed time is 0.693973 seconds.
Elapsed time is 0.713473 seconds.
Elapsed time is 0.578210 seconds.
Elapsed time is 0.626382 seconds.
Elapsed time is 1.109518 seconds.
Elapsed time is 1.074281 seconds.
 >> matrix_upd
Elapsed time is 0.672716 seconds.
Elapsed time is 0.589409 seconds.
Elapsed time is 0.586399 seconds.
Elapsed time is 0.588210 seconds.
Elapsed time is 0.917150 seconds.
Elapsed time is 0.965731 seconds.
 >> matrix_upd
Elapsed time is 0.654106 seconds.
Elapsed time is 0.579242 seconds.
Elapsed time is 0.579452 seconds.
Elapsed time is 0.606396 seconds.
Elapsed time is 0.900270 seconds.
Elapsed time is 0.981272 seconds.
 >>
================================
Octave:

octave:1> matrix_upd
Elapsed time is 3.63911 seconds.
Elapsed time is 3.60394 seconds.
Elapsed time is 3.28712 seconds.
Elapsed time is 3.68529 seconds.
Elapsed time is 1.00189 seconds.
Elapsed time is 1.05105 seconds.
octave:2> matrix_upd
Elapsed time is 3.59402 seconds.
Elapsed time is 3.68178 seconds.
Elapsed time is 3.41025 seconds.
Elapsed time is 3.81864 seconds.
Elapsed time is 0.995547 seconds.
Elapsed time is 1.0422 seconds.
octave:3> matrix_upd
Elapsed time is 3.67623 seconds.
Elapsed time is 3.61439 seconds.
Elapsed time is 3.27442 seconds.
Elapsed time is 3.69338 seconds.
Elapsed time is 0.959457 seconds.
Elapsed time is 0.994716 seconds.
octave:4>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090923/0602e47b/attachment.html 

From jwe at octave.org  Wed Sep 23 20:40:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 23 Sep 2009 21:40:32 -0400
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <4ABABBF3.8040203@isl.stanford.edu>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<4ABABBF3.8040203@isl.stanford.edu>
Message-ID: <19130.52752.945886.219123@segfault.lan>

On 23-Sep-2009, Michael D Godfrey wrote:

| Just for the record, a comparison with the "other system"

What LAPACK and BLAS libraries are linked with your copy of Octave?

jwe

From encisomo at in.tum.de  Wed Sep 23 15:04:18 2009
From: encisomo at in.tum.de (Jaiver Enciso)
Date: Wed, 23 Sep 2009 22:04:18 +0200
Subject: divergence function
Message-ID: <4ABA7F42.2070603@in.tum.de>

Hi All,

I'm glad to contribute with the 'divergence' function. This function
is used to compute divergence of vector field and is part of Matlab's 
core functions.

In doubt, please feel free to contact me.

Regards,
Javier
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: divergence.m
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090923/5b7c1452/attachment.ksh 

From godfrey at isl.stanford.edu  Wed Sep 23 22:17:01 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 23 Sep 2009 20:17:01 -0700
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <19130.52752.945886.219123@segfault.lan>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>	<4ABABBF3.8040203@isl.stanford.edu>
	<19130.52752.945886.219123@segfault.lan>
Message-ID: <4ABAE4AD.9000300@isl.stanford.edu>

On 09/23/2009 06:40 PM, John W. Eaton wrote:
> What LAPACK and BLAS libraries are linked with your copy of Octave?
>
>    
lapack-3.2.1-3.fc11.x86_64
blas-3.2.1-3.fc11.x86_64

Is this enough information?  If not, tell me what to
look for.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090923/c2787412/attachment.html 

From godfrey at isl.stanford.edu  Wed Sep 23 22:41:41 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 23 Sep 2009 20:41:41 -0700
Subject: Revisions to Plotting Sections of the Manual
In-Reply-To: <420fb9e60909210136u94703edkd3c3d71fe3a2b2b7@mail.gmail.com>
References: <4AB6C8C8.9060107@isl.stanford.edu>
	<420fb9e60909210136u94703edkd3c3d71fe3a2b2b7@mail.gmail.com>
Message-ID: <4ABAEA75.4030808@isl.stanford.edu>

On 09/21/2009 01:36 AM, Shai Ayal wrote:
> Some comments:
> Section 15.3: In general, I think it might be clearer to talk about
> the hierarchy of the graphics objects -- it root ->  figure ->  axes ->
> (lines, surface, patch text) , where a->b means that the parent "a"
> can have many children "b"
> section 15.3.1: I don't think image should be depreciated - it is
> essential and exists in the competing brand
> Also, missing are the *series objects (barseries etc...)
>    
I think that I have dealt with these comments.  Thanks very
much.  These are important points.  I will send an updated set
of pages fairly soon.

I will also include more about "backend" stuff in the introduction.
There are a few issues in that to be cleared up.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090923/cedc3632/attachment.html 

From highegg at gmail.com  Thu Sep 24 00:30:13 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 24 Sep 2009 07:30:13 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <4ABAE4AD.9000300@isl.stanford.edu>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<4ABABBF3.8040203@isl.stanford.edu>
	<19130.52752.945886.219123@segfault.lan>
	<4ABAE4AD.9000300@isl.stanford.edu>
Message-ID: <69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>

On Thu, Sep 24, 2009 at 5:17 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/23/2009 06:40 PM, John W. Eaton wrote:
>
> What LAPACK and BLAS libraries are linked with your copy of Octave?
>
>
>
> lapack-3.2.1-3.fc11.x86_64
> blas-3.2.1-3.fc11.x86_64
>
> Is this enough information?? If not, tell me what to
> look for.
>
> Michael
>

This is almost certainly the non-optimized reference BLAS
implementation from Netlib. If the other product uses an optimized
BLAS, which is likely, then the comparison makes little sense.

-- 
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 24 08:38:24 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 24 Sep 2009 06:38:24 -0700
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>	
	<4ABABBF3.8040203@isl.stanford.edu>	
	<19130.52752.945886.219123@segfault.lan>	
	<4ABAE4AD.9000300@isl.stanford.edu>
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
Message-ID: <4ABB7650.7000308@isl.stanford.edu>

On 09/23/2009 10:30 PM, Jaroslav Hajek wrote:
> This is almost certainly the non-optimized reference BLAS
> implementation from Netlib. If the other product uses an optimized
> BLAS, which is likely, then the comparison makes little sense.
>
>    
It makes sense if the question is: what is the relative performance
on these operations between the standard distributions of
Matlab and Octave on Fedora Linux.  And, seems good to me.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090924/cdca3073/attachment.html 

From highegg at gmail.com  Thu Sep 24 14:31:02 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 24 Sep 2009 21:31:02 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <4ABB7650.7000308@isl.stanford.edu>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<4ABABBF3.8040203@isl.stanford.edu>
	<19130.52752.945886.219123@segfault.lan>
	<4ABAE4AD.9000300@isl.stanford.edu>
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
	<4ABB7650.7000308@isl.stanford.edu>
Message-ID: <69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>

On Thu, Sep 24, 2009 at 3:38 PM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/23/2009 10:30 PM, Jaroslav Hajek wrote:
>
> This is almost certainly the non-optimized reference BLAS
> implementation from Netlib. If the other product uses an optimized
> BLAS, which is likely, then the comparison makes little sense.
>
>
>
> It makes sense if the question is: what is the relative performance
> on these operations between the standard distributions of
> Matlab and Octave on Fedora Linux.? And, seems good to me.
>
> Michael
>

I thought there was something like choice between libblas and libatlas
for the Fedora distribution of Octave... but maybe I'm wrong.
In any case, I was under the impression that your comparison was with
a self-compiled Octave...

-- 
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 24 16:45:04 2009
From: godfrey at isl.stanford.edu (Michael Godfrey)
Date: Thu, 24 Sep 2009 14:45:04 -0700
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>	
	<4ABABBF3.8040203@isl.stanford.edu>	
	<19130.52752.945886.219123@segfault.lan>	
	<4ABAE4AD.9000300@isl.stanford.edu>	
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>	
	<4ABB7650.7000308@isl.stanford.edu>
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>
Message-ID: <4ABBE860.7090307@isl.stanford.edu>

On 09/24/2009 12:31 PM, Jaroslav Hajek wrote:
> In any case, I was under the impression that your comparison was with
> a self-compiled Octave...
>    
I ran the tests using the Octave that I built this morning from the current
development tree -- this included your most recent changeset.  So, what
BLAS/LAPACK did I get?  I  assumed that I would be using the Fedora
installed ones.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090924/07941533/attachment.html 

From highegg at gmail.com  Fri Sep 25 00:16:26 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 25 Sep 2009 07:16:26 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <4ABBE860.7090307@isl.stanford.edu>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<4ABABBF3.8040203@isl.stanford.edu>
	<19130.52752.945886.219123@segfault.lan>
	<4ABAE4AD.9000300@isl.stanford.edu>
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
	<4ABB7650.7000308@isl.stanford.edu>
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>
	<4ABBE860.7090307@isl.stanford.edu>
Message-ID: <69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>

On Thu, Sep 24, 2009 at 11:45 PM, Michael Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/24/2009 12:31 PM, Jaroslav Hajek wrote:
>
> In any case, I was under the impression that your comparison was with
> a self-compiled Octave...
>
>
> I ran the tests using the Octave that I built this morning from the current
> development tree -- this included your most recent changeset.

If you compiled Octave yourself, you can hardly call that a "standard
distribution".
Is there no ATLAS package for Fedora?

-- 
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  Fri Sep 25 00:26:38 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 24 Sep 2009 22:26:38 -0700
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>	
	<4ABABBF3.8040203@isl.stanford.edu>	
	<19130.52752.945886.219123@segfault.lan>	
	<4ABAE4AD.9000300@isl.stanford.edu>	
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>	
	<4ABB7650.7000308@isl.stanford.edu>	
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>	
	<4ABBE860.7090307@isl.stanford.edu>
	<69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>
Message-ID: <4ABC548E.50309@isl.stanford.edu>

On 09/24/2009 10:16 PM, Jaroslav Hajek wrote:
> If you compiled Octave yourself, you can hardly call that a "standard
> distribution".
>    
Sorry I was not exactly precise.  This will be a standard
distribution to due course.
> Is there no ATLAS package for Fedora?
>
>    
Yes, there is atlas and atlas-devel, and some other things
with atlas in their name.  Does Octave use these?


From shaiay at gmail.com  Fri Sep 25 00:33:55 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Fri, 25 Sep 2009 08:33:55 +0300
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <4ABC548E.50309@isl.stanford.edu>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<4ABABBF3.8040203@isl.stanford.edu>
	<19130.52752.945886.219123@segfault.lan>
	<4ABAE4AD.9000300@isl.stanford.edu>
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
	<4ABB7650.7000308@isl.stanford.edu>
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>
	<4ABBE860.7090307@isl.stanford.edu>
	<69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>
	<4ABC548E.50309@isl.stanford.edu>
Message-ID: <420fb9e60909242233q205a65d1k75ddcbcdf158c3d5@mail.gmail.com>

On Fri, Sep 25, 2009 at 8:26 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/24/2009 10:16 PM, Jaroslav Hajek wrote:
>>
>> If you compiled Octave yourself, you can hardly call that a "standard
>> distribution".
>>
>
> Sorry I was not exactly precise. ?This will be a standard
> distribution to due course.
>>
>> Is there no ATLAS package for Fedora?
>>
>>
>
> Yes, there is atlas and atlas-devel, and some other things
> with atlas in their name. ?Does Octave use these?

ATLAS is an attempt to empirically optimize BLAS, and acts in as a
replacement for the BLAS routines. As such it will provide better
performance. AFIK matlab uses ATLAS.
More info at : http://math-atlas.sourceforge.net/

Shai


From highegg at gmail.com  Fri Sep 25 00:38:42 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 25 Sep 2009 07:38:42 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <4ABC548E.50309@isl.stanford.edu>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<4ABABBF3.8040203@isl.stanford.edu>
	<19130.52752.945886.219123@segfault.lan>
	<4ABAE4AD.9000300@isl.stanford.edu>
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
	<4ABB7650.7000308@isl.stanford.edu>
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>
	<4ABBE860.7090307@isl.stanford.edu>
	<69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>
	<4ABC548E.50309@isl.stanford.edu>
Message-ID: <69d8d540909242238x1a3bdccah2c9b4de717b7e338@mail.gmail.com>

On Fri, Sep 25, 2009 at 7:26 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/24/2009 10:16 PM, Jaroslav Hajek wrote:
>>
>> If you compiled Octave yourself, you can hardly call that a "standard
>> distribution".
>>
>
> Sorry I was not exactly precise. ?This will be a standard
> distribution to due course.

Aha! Now I get it :) Cool.

>>
>> Is there no ATLAS package for Fedora?
>>
>>
>
> Yes, there is atlas and atlas-devel, and some other things
> with atlas in their name. ?Does Octave use these?
>

Octave *can* use these instead of the Netlib BLAS. LAPACK can also be
optionally linked against it.

-- 
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 00:40:47 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 25 Sep 2009 07:40:47 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <420fb9e60909242233q205a65d1k75ddcbcdf158c3d5@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<19130.52752.945886.219123@segfault.lan>
	<4ABAE4AD.9000300@isl.stanford.edu>
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
	<4ABB7650.7000308@isl.stanford.edu>
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>
	<4ABBE860.7090307@isl.stanford.edu>
	<69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>
	<4ABC548E.50309@isl.stanford.edu>
	<420fb9e60909242233q205a65d1k75ddcbcdf158c3d5@mail.gmail.com>
Message-ID: <69d8d540909242240q692c769fp363752b44553f9fe@mail.gmail.com>

On Fri, Sep 25, 2009 at 7:33 AM, Shai Ayal <shaiay at gmail.com> wrote:
> On Fri, Sep 25, 2009 at 8:26 AM, Michael D Godfrey
> <godfrey at isl.stanford.edu> wrote:
>> On 09/24/2009 10:16 PM, Jaroslav Hajek wrote:
>>>
>>> If you compiled Octave yourself, you can hardly call that a "standard
>>> distribution".
>>>
>>
>> Sorry I was not exactly precise. ?This will be a standard
>> distribution to due course.
>>>
>>> Is there no ATLAS package for Fedora?
>>>
>>>
>>
>> Yes, there is atlas and atlas-devel, and some other things
>> with atlas in their name. ?Does Octave use these?
>
> ATLAS is an attempt to empirically optimize BLAS, and acts in as a
> replacement for the BLAS routines. As such it will provide better
> performance. AFIK matlab uses ATLAS.

Does it? I thought they shipped Matlab with the MKL from Intel...
which usually outperforms ATLAS somewhat, at least on Intel CPUs...


-- 
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  Fri Sep 25 00:46:54 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 24 Sep 2009 22:46:54 -0700
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <420fb9e60909242233q205a65d1k75ddcbcdf158c3d5@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>	
	<4ABABBF3.8040203@isl.stanford.edu>	
	<19130.52752.945886.219123@segfault.lan>	
	<4ABAE4AD.9000300@isl.stanford.edu>	
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>	
	<4ABB7650.7000308@isl.stanford.edu>	
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>	
	<4ABBE860.7090307@isl.stanford.edu>	
	<69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>	
	<4ABC548E.50309@isl.stanford.edu>
	<420fb9e60909242233q205a65d1k75ddcbcdf158c3d5@mail.gmail.com>
Message-ID: <4ABC594E.9020501@isl.stanford.edu>

On 09/24/2009 10:33 PM, Shai Ayal wrote:
> ATLAS is an attempt to empirically optimize BLAS, and acts in as a
> replacement for the BLAS routines. As such it will provide better
> performance. AFIK matlab uses ATLAS.
>    
If I have BLAS/LAPACK and Altlas installed, how to I tell
Octave what to do?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090924/4b91ddb1/attachment.html 

From highegg at gmail.com  Fri Sep 25 00:50:52 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 25 Sep 2009 07:50:52 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <4ABC594E.9020501@isl.stanford.edu>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<4ABAE4AD.9000300@isl.stanford.edu>
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>
	<4ABB7650.7000308@isl.stanford.edu>
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>
	<4ABBE860.7090307@isl.stanford.edu>
	<69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>
	<4ABC548E.50309@isl.stanford.edu>
	<420fb9e60909242233q205a65d1k75ddcbcdf158c3d5@mail.gmail.com>
	<4ABC594E.9020501@isl.stanford.edu>
Message-ID: <69d8d540909242250o5ace14f4mc8309952233ae3ea@mail.gmail.com>

On Fri, Sep 25, 2009 at 7:46 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 09/24/2009 10:33 PM, Shai Ayal wrote:
>
> ATLAS is an attempt to empirically optimize BLAS, and acts in as a
> replacement for the BLAS routines. As such it will provide better
> performance. AFIK matlab uses ATLAS.
>
>
> If I have BLAS/LAPACK and Altlas installed, how to I tell
> Octave what to do?
>

If you have both atlas and atlas-devel, it should be auto-discovered.
As a result, you should get something like
BLAS_LIBS=-latlas -lcblas -lf77blas

Is this not happening? If not, can you show your config.log?

-- 
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  Fri Sep 25 01:13:27 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 24 Sep 2009 23:13:27 -0700
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909242250o5ace14f4mc8309952233ae3ea@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>	
	<4ABAE4AD.9000300@isl.stanford.edu>	
	<69d8d540909232230h6b92870doef301710eeff620a@mail.gmail.com>	
	<4ABB7650.7000308@isl.stanford.edu>	
	<69d8d540909241231x75234205g6520440a1fe28d2c@mail.gmail.com>	
	<4ABBE860.7090307@isl.stanford.edu>	
	<69d8d540909242216s1f91ae19w87674389422d54ba@mail.gmail.com>	
	<4ABC548E.50309@isl.stanford.edu>	
	<420fb9e60909242233q205a65d1k75ddcbcdf158c3d5@mail.gmail.com>	
	<4ABC594E.9020501@isl.stanford.edu>
	<69d8d540909242250o5ace14f4mc8309952233ae3ea@mail.gmail.com>
Message-ID: <4ABC5F87.2070408@isl.stanford.edu>

On 09/24/2009 10:50 PM, Jaroslav Hajek wrote:
> Is this not happening? If not, can you show your config.log?
>
>    
It is not happening. config.log says:
[godfrey-pbdsl3:octave_fltk_devel] grep -i atlas config.log
1729:configure:16724: checking for ATL_xerbla in -latlas
1730:configure:16767: gcc -o conftest -g -O2    conftest.c -latlas  
-lm   -L/usr/lib/gcc/x86_64-redhat-linux/4.4.1 
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../lib64 
-L/lib/../lib64 -L/usr/lib/../lib64 
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../.. -lgfortranbegin 
-lgfortran -lm >&5
1731:/usr/bin/ld: cannot find -latlas
17058:ac_cv_lib_atlas_ATL_xerbla=no
======================
The atlas libs seem to be in: /usr/lib64/atlas/

Someone seems to have a path problem.  Too late
here for me to look at it tonight.
\Michael


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090924/b9a2b403/attachment.html 

From bpabbott at mac.com  Fri Sep 25 01:55:56 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Fri, 25 Sep 2009 08:55:56 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
Message-ID: <7FFEF1E9-C3A3-433A-A0DC-B2F434E40420@mac.com>


On Sep 23, 2009, at 12:50 PM, Jaroslav Hajek wrote:

> hi all,
>
> the following three patches:
> http://hg.savannah.gnu.org/hgweb/octave/rev/afcf852256d2
> http://hg.savannah.gnu.org/hgweb/octave/rev/0d3b248f4ab6
> http://hg.savannah.gnu.org/hgweb/octave/rev/7e5b4de5fbfe
>
> add new optimizations for matrix multiplication and division. Quote  
> for NEWS:
>
> ** More efficient matrix division handling. Octave is now able to
> handle the expressions
>
>       M' \ v
>       M.' \ v
>       v / M
>
>    (M is a matrix and v is a vector) more efficiently in certain  
> cases.
>    In particular, if M is triangular, all three expressions will be
> handled by a single call to
>    xTRTRS, with appropriate flags. Previously, all three expressions
> required a physical transpose
>    of M.
>
> ** More efficient handling of certain mixed real-complex matrix  
> operations.
>    For instance, if RM is a real matrix and CM a complex matrix,
>
>      RM * CM
>
>    can now be evaluated either as
>
>      complex (RM * real (CM), RM * imag (CM))
>
>    or as
>
>      complex (RM) * CM,
>
>    depending on the dimensions. The 1st form requires more
> temporaries and copying,
>    but halves the count of FLOPs, which normally brings better  
> performance if
>    RM has enough rows. Previously, the 2nd form was always used.
>
>    Matrix division is similarly affected.
>
> The triangular optimization is well demonstrated by this benchmark:
>
> n = 500;
> R = triu (rand (n));
> u = rand (n, 1);
>
> tic; for i = 1:1000; R \ u; endfor; toc
> tic; for i = 1:1000; u' / R; endfor; toc
> tic; for i = 1:1000; R' \ u; endfor; toc
>
> R = tril (rand (n));
> u = rand (n, 1);
>
> tic; for i = 1:1000; R \ u; endfor; toc
> tic; for i = 1:1000; u' / R; endfor; toc
> tic; for i = 1:1000; R' \ u; endfor; toc
>
> u = u + I*rand (n, 1);
> tic; for i = 1:1000; R \ u; endfor; toc
> tic; for i = 1:1000; R' \ u; endfor; toc
>
>
> with a recent tip, I got (Core 2 Duo @ 2.83 GHz, g++ -O3
> -march=native, self-built GotoBLAS + LAPACK):
>
> Elapsed time is 0.225974 seconds.
> Elapsed time is 0.78818 seconds.
> Elapsed time is 1.81756 seconds.
> Elapsed time is 0.219842 seconds.
> Elapsed time is 0.79384 seconds.
> Elapsed time is 1.83497 seconds.
> Elapsed time is 4.32738 seconds.
> Elapsed time is 7.73774 seconds.
>
> with the new patches, I get
>
> Elapsed time is 0.221489 seconds.
> Elapsed time is 0.204968 seconds.
> Elapsed time is 0.204267 seconds.
> Elapsed time is 0.219243 seconds.
> Elapsed time is 0.20444 seconds.
> Elapsed time is 0.202193 seconds.
> Elapsed time is 0.227214 seconds.
> Elapsed time is 0.209824 seconds.
>
> This is particularly cool when working intensively with Cholesky, LU
> or QR factorizations - you can do both A \ v and A' \ v almost as
> efficiently as with raw BLAS.
>
> Also, there's some speed-up with real x complex multiplication and
> division, which is not a very common operation, but sometimes needed.
> The point is that for bigger matrices, complex (RM * real (CM), RM *
> imag (CM)) is typically up to 2x faster than complex (RM) * CM.
> Surprised? Just count the FLOPs. On the other hand, the former
> expression is less friendly for Octave's complex storage.
>
> The benchmark is:
>
> n = 800;
> a = rand (n);
> b = rand (n) + i*rand (n);
> tic; a * b; toc
> tic; b * a; toc
> tic; a' * b; toc
> tic; b * a'; toc
> tic; a \ b; toc
> tic; b / a; toc
>
> with a recent tip:
>
> Elapsed time is 0.431021 seconds.
> Elapsed time is 0.410468 seconds.
> Elapsed time is 0.411169 seconds.
> Elapsed time is 0.412252 seconds.
> Elapsed time is 0.641075 seconds.
> Elapsed time is 0.66255 seconds.
>
> with the new patches:
>
> Elapsed time is 0.221522 seconds.
> Elapsed time is 0.2183 seconds.
> Elapsed time is 0.22033 seconds.
> Elapsed time is 0.22058 seconds.
> Elapsed time is 0.297738 seconds.
> Elapsed time is 0.325542 seconds.
>
> The conclusion is that Octave 3.4 will again be able to map linear
> algebra code more efficiently onto BLAS and LAPACK than the previous
> version.

Running Matlab on Mac OSX (MKL, or ???)

Elapsed time is 0.277841 seconds.
Elapsed time is 2.040261 seconds.
Elapsed time is 2.051063 seconds.
Elapsed time is 0.276847 seconds.
Elapsed time is 2.070356 seconds.
Elapsed time is 2.023176 seconds.
Elapsed time is 0.381263 seconds.
Elapsed time is 2.177680 seconds.

Octave compiled with Apples Lapack/Blas (vecLib).

Elapsed time is 0.211057 seconds.
Elapsed time is 0.230565 seconds.
Elapsed time is 0.202384 seconds.
Elapsed time is 0.219704 seconds.
Elapsed time is 0.219448 seconds.
Elapsed time is 0.198678 seconds.
Elapsed time is 0.308611 seconds.
Elapsed time is 0.282597 seconds.

Ben


From hellyj at ucsd.edu  Fri Sep 25 19:26:48 2009
From: hellyj at ucsd.edu (Helly John)
Date: Fri, 25 Sep 2009 17:26:48 -0700
Subject: Welcome to the "Octave-maintainers" mailing list
In-Reply-To: <mailman.0.1253924539.1196.octave-maintainers@octave.org>
References: <mailman.0.1253924539.1196.octave-maintainers@octave.org>
Message-ID: <577EA1AA-B772-4525-905E-9BE9C9C4AF82@ucsd.edu>

Hi.

I'm new to Octave and gnuplot and Aquaterm but have just installed all  
of these on my system.  Here's the configuration:

- Mac OS X 10.6.1
- AquaTerm v1.0.1 (1.0.1)
- Octave-3.2.2
- GNUPLOT 4.2 patchlevel 6

When I try to plot in octave this is what happens:
*****************************************************************
octave-3.2.2:1> Y=[1:10]
Y =

     1    2    3    4    5    6    7    8    9   10

octave-3.2.2:2> plot(Y)
Unknown or ambiguous terminal name 'aqua'

gnuplot> set terminal aqua enhanced title "Figure 1" size 560 420
                       ^
          line 0: unknown or ambiguous terminal type; type just 'set  
terminal' for a list

          line 0: No terminal defined


gnuplot> plot "-" binary format='%float64' record=10 using ($1):($2)  
axes x1y1 title "" with lines linestyle 1 ;
               ^
          line 0: use 'set term' to set terminal type first

octave-3.2.2:3> system ("echo $GNUTERM")
aqua
ans = 0
octave-3.2.2:4>
*****************************************************************

Do you have any suggestions as to what might be wrong?
Thanks.

-----------------------------------------------
John Helly / San Diego Supercomputer Center & Climate, Atmospheric  
Science, and Physical Oceanography/Scripps Institution of  
Oceanography / UCSD / +01 760 840 8660 mobile / stonesteps (Skype) /  
stonesteps7 (iChat) / http://www.sdsc.edu/~hellyj




From hellyj at ucsd.edu  Fri Sep 25 19:28:05 2009
From: hellyj at ucsd.edu (Helly John)
Date: Fri, 25 Sep 2009 17:28:05 -0700
Subject: Problem with octave/gnuplot/aquaterm on Snow Leopard
Message-ID: <4751394B-A5C9-4119-BE7D-DC9E07216A95@ucsd.edu>

Hi.

I'm new to Octave and gnuplot and Aquaterm but have just installed all
of these on my system.  Here's the configuration:

- Mac OS X 10.6.1
- AquaTerm v1.0.1 (1.0.1)
- Octave-3.2.2
- GNUPLOT 4.2 patchlevel 6

When I try to plot in octave this is what happens:
*****************************************************************
octave-3.2.2:1> Y=[1:10]
Y =

     1    2    3    4    5    6    7    8    9   10

octave-3.2.2:2> plot(Y)
Unknown or ambiguous terminal name 'aqua'

gnuplot> set terminal aqua enhanced title "Figure 1" size 560 420
                       ^
          line 0: unknown or ambiguous terminal type; type just 'set
terminal' for a list

          line 0: No terminal defined


gnuplot> plot "-" binary format='%float64' record=10 using ($1):($2)
axes x1y1 title "" with lines linestyle 1 ;
               ^
          line 0: use 'set term' to set terminal type first

octave-3.2.2:3> system ("echo $GNUTERM")
aqua
ans = 0
octave-3.2.2:4>
*****************************************************************

Do you have any suggestions as to what might be wrong?
Thanks.
-----------------------------------------------
John Helly / San Diego Supercomputer Center & Climate, Atmospheric  
Science, and Physical Oceanography/Scripps Institution of  
Oceanography / UCSD / +01 760 840 8660 mobile / stonesteps (Skype) /  
stonesteps7 (iChat) / http://www.sdsc.edu/~hellyj




From jwe at octave.org  Fri Sep 25 19:46:22 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 25 Sep 2009 20:46:22 -0400
Subject: Problem with octave/gnuplot/aquaterm on Snow Leopard
In-Reply-To: <4751394B-A5C9-4119-BE7D-DC9E07216A95@ucsd.edu>
References: <4751394B-A5C9-4119-BE7D-DC9E07216A95@ucsd.edu>
Message-ID: <19133.25694.612964.699745@segfault.lan>

On 25-Sep-2009, Helly John wrote:

| I'm new to Octave and gnuplot and Aquaterm but have just installed all
| of these on my system.  Here's the configuration:

I'm not an OS X user, so I can't answer the specific question about
how to set up the Aqua terminal for plotting, but I think it is
supposed to work.

It would probably be better to ask your question on the
help at octave.org list.  The maintainers list is for discussion about
the development of Octave.

jwe


From hellyj at ucsd.edu  Fri Sep 25 19:47:08 2009
From: hellyj at ucsd.edu (Helly John)
Date: Fri, 25 Sep 2009 17:47:08 -0700
Subject: Problem with octave/gnuplot/aquaterm on Snow Leopard
In-Reply-To: <19133.25694.612964.699745@segfault.lan>
References: <4751394B-A5C9-4119-BE7D-DC9E07216A95@ucsd.edu>
	<19133.25694.612964.699745@segfault.lan>
Message-ID: <EB2A4A4E-5EA7-4F41-9256-90EFA8035AA8@ucsd.edu>

Thanks, will do.
J.

On Sep 25, 2009, at 5:46 PM, John W. Eaton wrote:

On 25-Sep-2009, Helly John wrote:

| I'm new to Octave and gnuplot and Aquaterm but have just installed all
| of these on my system.  Here's the configuration:

I'm not an OS X user, so I can't answer the specific question about
how to set up the Aqua terminal for plotting, but I think it is
supposed to work.

It would probably be better to ask your question on the
help at octave.org list.  The maintainers list is for discussion about
the development of Octave.

jwe


-----------------------------------------------
John Helly / San Diego Supercomputer Center & Climate, Atmospheric  
Science, and Physical Oceanography/Scripps Institution of  
Oceanography / UCSD / +01 760 840 8660 mobile / stonesteps (Skype) /  
stonesteps7 (iChat) / http://www.sdsc.edu/~hellyj




From thomas.weber.mail at gmail.com  Sat Sep 26 01:42:37 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Sat, 26 Sep 2009 08:42:37 +0200
Subject: Octave 3.2.3
In-Reply-To: <69d8d540909202250t5ba6dbafne607e65c63828888@mail.gmail.com>
References: <69d8d540909202250t5ba6dbafne607e65c63828888@mail.gmail.com>
Message-ID: <20090926064237.GA22642@atlan>

On Mon, Sep 21, 2009 at 07:50:11AM +0200, Jaroslav Hajek wrote:
> hi all,
> 
> with another small delay, here are the 3.2.3 release tarballs:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> thanks to all contributors for their help.

If this is a final release, could it be uploaded onto the GNU mirrors,
please?

Thanks
	Thomas

From shaiay at gmail.com  Sun Sep 27 01:12:42 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sun, 27 Sep 2009 09:12:42 +0300
Subject: fltk backend fix & mouse wheel scroll factor
Message-ID: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>

Hi

The attached changset fixes a bug which did not show the zoom box.
Also added a function to enable the user to control the zoom factor
when using mouse wheel zoom.

I think that with this changeset, the fltk_backend is quite usable as
a viewer to the gl-renderer. I am open to feature requests.

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk_fixes.chngeset
Type: application/octet-stream
Size: 2922 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090927/030229d2/attachment.obj 

From soren at hauberg.org  Sun Sep 27 03:16:45 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 27 Sep 2009 10:16:45 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
Message-ID: <1254039405.4424.27.camel@sh-t400>

s?n, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
> The attached changset fixes a bug which did not show the zoom box.
> Also added a function to enable the user to control the zoom factor
> when using mouse wheel zoom.
> 
> I think that with this changeset, the fltk_backend is quite usable as
> a viewer to the gl-renderer.

I think this is really nice. With this changeset, the FLTK backend is
very nice to use for 2D plots (much better than both gnuplot and
matlab).

>  I am open to feature requests.

Well, then I'm gonna file a request :-) It would be great to have better
support for navigating in 3D. Basically, I think dragging the mouse
should make 3D plots rotate around some point (center of mass?), while
scrolling should change the distance between the camera and said point.

S?ren


From soren at hauberg.org  Sun Sep 27 09:40:50 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 27 Sep 2009 16:40:50 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
Message-ID: <1254062450.4424.68.camel@sh-t400>

s?n, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
> The attached changset fixes a bug which did not show the zoom box.
> Also added a function to enable the user to control the zoom factor
> when using mouse wheel zoom.
> 
> I think that with this changeset, the fltk_backend is quite usable as
> a viewer to the gl-renderer. I am open to feature requests.

I've just stumbled upon a bug, that may or may not be related to this
changeset. If I

  a) click somewhere on a plot with the right mouse button without
     releasing it,

  b) move the mouse somewhere else inside the plot, and

  c) release the right button,

then nothing happens, except from then on, I cannot zoom any more using
the mouse wheel.

S?ren


From shaiay at gmail.com  Sun Sep 27 10:22:28 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sun, 27 Sep 2009 18:22:28 +0300
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <1254062450.4424.68.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254062450.4424.68.camel@sh-t400>
Message-ID: <420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>

On Sun, Sep 27, 2009 at 5:40 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> s?n, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
>> The attached changset fixes a bug which did not show the zoom box.
>> Also added a function to enable the user to control the zoom factor
>> when using mouse wheel zoom.
>>
>> I think that with this changeset, the fltk_backend is quite usable as
>> a viewer to the gl-renderer. I am open to feature requests.
>
> I've just stumbled upon a bug, that may or may not be related to this
> changeset. If I
>
> ?a) click somewhere on a plot with the right mouse button without
> ? ? releasing it,
>
> ?b) move the mouse somewhere else inside the plot, and
>
> ?c) release the right button,
>
> then nothing happens, except from then on, I cannot zoom any more using
> the mouse wheel.

Strange. When I do a right drag inside a plot I get a zoom-frame. When
I release the right button the plot zooms accordingly, and the scroll
wheel works all of the time.
What system are you running on, and if you have it installed, what is
the output of
glxinfo | grep render

Shai


From soren at hauberg.org  Sun Sep 27 10:30:27 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 27 Sep 2009 17:30:27 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254062450.4424.68.camel@sh-t400>
	<420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>
Message-ID: <1254065427.4424.72.camel@sh-t400>

s?n, 27 09 2009 kl. 18:22 +0300, skrev Shai Ayal:
> Strange. When I do a right drag inside a plot I get a zoom-frame. When
> I release the right button the plot zooms accordingly, and the scroll
> wheel works all of the time.
> What system are you running on, and if you have it installed, what is
> the output of
> glxinfo | grep render

This is on Ubuntu 9.04 with an Intel graphics card. The glxinfo output
is

        No kernel support for execution fencing, disabling texture
        tiling
        direct rendering: Yes
        OpenGL renderer string: Mesa DRI Mobile Intel? GM45 Express
        Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2

Intel graphics cards are known to have some issues on this version of
Ubuntu, so it just might be a driver issue. I would, however, find that
somewhat weird since the FLTK backend in general works quite well.

S?ren


From shaiay at gmail.com  Sun Sep 27 10:58:17 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sun, 27 Sep 2009 18:58:17 +0300
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <1254065427.4424.72.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254062450.4424.68.camel@sh-t400>
	<420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>
	<1254065427.4424.72.camel@sh-t400>
Message-ID: <420fb9e60909270858l7b884b50s18fbd620be046ef2@mail.gmail.com>

On Sun, Sep 27, 2009 at 6:30 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> s?n, 27 09 2009 kl. 18:22 +0300, skrev Shai Ayal:
>> Strange. When I do a right drag inside a plot I get a zoom-frame. When
>> I release the right button the plot zooms accordingly, and the scroll
>> wheel works all of the time.
>> What system are you running on, and if you have it installed, what is
>> the output of
>> glxinfo | grep render
>
> This is on Ubuntu 9.04 with an Intel graphics card. The glxinfo output
> is
>
> ? ? ? ?No kernel support for execution fencing, disabling texture
> ? ? ? ?tiling
> ? ? ? ?direct rendering: Yes
> ? ? ? ?OpenGL renderer string: Mesa DRI Mobile Intel? GM45 Express
> ? ? ? ?Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2
>
> Intel graphics cards are known to have some issues on this version of
> Ubuntu, so it just might be a driver issue. I would, however, find that
> somewhat weird since the FLTK backend in general works quite well.

I think this IS an intel issue. I have an intel card at work, so I can
try it there, but it'll have to wait until tuesday.
If you can't bear the suspense, you can try to run X w/o DRI and see
what happens.

Shai


From jpswensen at comcast.net  Sun Sep 27 18:05:02 2009
From: jpswensen at comcast.net (John Swensen)
Date: Sun, 27 Sep 2009 19:05:02 -0400
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <1254039405.4424.27.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254039405.4424.27.camel@sh-t400>
Message-ID: <B0E23643-DE67-413F-AE54-120BA32935F3@comcast.net>


On Sep 27, 2009, at 4:16 AM, S?ren Hauberg wrote:

> s?n, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
>> The attached changset fixes a bug which did not show the zoom box.
>> Also added a function to enable the user to control the zoom factor
>> when using mouse wheel zoom.
>>
>> I think that with this changeset, the fltk_backend is quite usable as
>> a viewer to the gl-renderer.
>
> I think this is really nice. With this changeset, the FLTK backend is
> very nice to use for 2D plots (much better than both gnuplot and
> matlab).
>
>> I am open to feature requests.
>
> Well, then I'm gonna file a request :-) It would be great to have  
> better
> support for navigating in 3D. Basically, I think dragging the mouse
> should make 3D plots rotate around some point (center of mass?), while
> scrolling should change the distance between the camera and said  
> point.

I have always been a big fan of how the 3D solid modeling programs  
(e.g. ProE and SolidWorks) do their 3D navigation.  The way I see it  
working with Octave is as follows.  There would be 4 different "views"  
available from the plotting window.  Views 1-3 would be associated  
with looking at the plot along each of the cardinal axes.  The four  
would be the "working view".  The user has 2 options regarding how the  
object rotations (or the camera rotates about the object).  The first  
is based on a center of mass idea as you indicated.  This works great  
for solid modeling, since objects have a clear center of mass, but for  
plotting it is more difficult since it becomes not obvious how to  
weight things like lines.  A cloud of points would be easiest to  
implement this behavior.  The second way that solid modeling programs  
work is to allow you to set the center of rotation by switching to the  
3 orthogonal views to set the point of rotation.  Then, you can return  
to the "working view" and rotate and pan as would be expected.  This  
would be harder to implement, and I'm not exactly sure how this meshes  
with how the property tree manages camera position, but I think it  
would help keep from grumbling and muttering unspeakable things every  
time I try to rotate and pan in both Matlab and Octave.

John Swensen



From godfrey at isl.stanford.edu  Sun Sep 27 19:05:26 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 27 Sep 2009 17:05:26 -0700
Subject: Minor odd things about get(0,...)
Message-ID: <4ABFFDC6.60808@isl.stanford.edu>

I was working on better explanation of get() and noticed:

1. get(0) and get(0,"") produce similar but not exactly the
     same output.  If you try these 2 commands you will see:

    1.1 get(0) does not sort its list, get(0,"") does.  Not quite
          a bug, more an observation.
    1.2 There is one property missing from the get(0) list:
          __myhandle__ . get(0,"__myhandle__") returns ans=0.
          And, of course, so does get(0,"__my")
    1.3 "default" appears to be a special case.  It is not in the
          property lists,  and get(0,"def") gives:
          error: get: unknown root property def
          But, get(0, "default") returns:
         ans =
        {
            0x0 struct array containing the fields:

        }
=============================================
Should I try to explain this, or just pretend I did not notice?
For now, I will write the description as if these minor items did
not exist, i.e. I will say something like get(0) and get(0,"") both
return lists of the properties for the root handle.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090927/fdb86545/attachment.html 

From godfrey at isl.stanford.edu  Sun Sep 27 19:14:06 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 27 Sep 2009 17:14:06 -0700
Subject: more minor items about graphics handles
Message-ID: <4ABFFFCE.40804@isl.stanford.edu>

I just noticed the get(0,"default<xxxxx>") syntax.
Is this why "default" is special?  So far,
the only example that I know of the above syntax is:
get(0,"defaultfigure__backend__").  Other strings for
<xxxxxx> produce, for example for <xxxxx> set to
screensize, you get:
error: get: invalid default property `screensize'

I will try to figure this out, but a quick pointer would help.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090927/02d2f089/attachment.html 

From bpabbott at mac.com  Sun Sep 27 19:24:56 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sun, 27 Sep 2009 20:24:56 -0400
Subject: more minor items about graphics handles
In-Reply-To: <4ABFFFCE.40804@isl.stanford.edu>
References: <4ABFFFCE.40804@isl.stanford.edu>
Message-ID: <37B66F17-E688-4DA9-8EF4-5C9664D03289@mac.com>


On Sep 27, 2009, at 8:14 PM, Michael D Godfrey wrote:

> I just noticed the get(0,"default<xxxxx>") syntax.
> Is this why "default" is special?  So far,
> the only example that I know of the above syntax is:
> get(0,"defaultfigure__backend__").  Other strings for
> <xxxxxx> produce, for example for <xxxxx> set to
> screensize, you get:
> error: get: invalid default property `screensize'
>
> I will try to figure this out, but a quick pointer would help.
>
> Michael

The "default" values are constructed as "default"+type+property.

For example, get(0, "defaulttextfontsize") or get(0, "get (0,  
"defaultaxescolororder")

Is that what you're looking for?

Ben


From godfrey at isl.stanford.edu  Sun Sep 27 19:31:55 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 27 Sep 2009 17:31:55 -0700
Subject: more minor items about graphics handles
In-Reply-To: <37B66F17-E688-4DA9-8EF4-5C9664D03289@mac.com>
References: <4ABFFFCE.40804@isl.stanford.edu>
	<37B66F17-E688-4DA9-8EF4-5C9664D03289@mac.com>
Message-ID: <4AC003FB.5090905@isl.stanford.edu>

On 09/27/2009 05:24 PM, Ben Abbott wrote:
> The "default" values are constructed as "default"+type+property.
>
> For example, get(0, "defaulttextfontsize") or get(0, "get (0, 
> "defaultaxescolororder")
>
> Is that what you're looking for?
>
> Ben 
Oh, yes now I remember seeing mention of that somewhere.
Is there a defined syntax for this beyond what you gave above?
How, for instance, would you get the default screensize?

Anyhow, I can now do a better search through the Manual.

Thanks,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090927/639ea2c6/attachment.html 

From bpabbott at mac.com  Sun Sep 27 19:37:05 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sun, 27 Sep 2009 20:37:05 -0400
Subject: more minor items about graphics handles
In-Reply-To: <4AC003FB.5090905@isl.stanford.edu>
References: <4ABFFFCE.40804@isl.stanford.edu>
	<37B66F17-E688-4DA9-8EF4-5C9664D03289@mac.com>
	<4AC003FB.5090905@isl.stanford.edu>
Message-ID: <6116B5A8-75A0-43E8-9F38-66FE6F9848F0@mac.com>


On Sep 27, 2009, at 8:31 PM, Michael D Godfrey wrote:

> On 09/27/2009 05:24 PM, Ben Abbott wrote:
>> The "default" values are constructed as "default"+type+property.
>>
>> For example, get(0, "defaulttextfontsize") or get(0, "get (0,  
>> "defaultaxescolororder")
>>
>> Is that what you're looking for?
>>
>> Ben
> Oh, yes now I remember seeing mention of that somewhere.
> Is there a defined syntax for this beyond what you gave above?
> How, for instance, would you get the default screensize?

As far as I know there is no "defaultxxxx" for root properties.

Ben



From shaiay at gmail.com  Mon Sep 28 01:57:22 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 28 Sep 2009 08:57:22 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <B0E23643-DE67-413F-AE54-120BA32935F3@comcast.net>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254039405.4424.27.camel@sh-t400>
	<B0E23643-DE67-413F-AE54-120BA32935F3@comcast.net>
Message-ID: <420fb9e60909272357r75100151pc371e4f60ddbdf2c@mail.gmail.com>

On Mon, Sep 28, 2009 at 1:05 AM, John Swensen <jpswensen at comcast.net> wrote:
>
> On Sep 27, 2009, at 4:16 AM, S?ren Hauberg wrote:
>
>> s?n, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
>>>
>>> The attached changset fixes a bug which did not show the zoom box.
>>> Also added a function to enable the user to control the zoom factor
>>> when using mouse wheel zoom.
>>>
>>> I think that with this changeset, the fltk_backend is quite usable as
>>> a viewer to the gl-renderer.
>>
>> I think this is really nice. With this changeset, the FLTK backend is
>> very nice to use for 2D plots (much better than both gnuplot and
>> matlab).
>>
>>> I am open to feature requests.
>>
>> Well, then I'm gonna file a request :-) It would be great to have better
>> support for navigating in 3D. Basically, I think dragging the mouse
>> should make 3D plots rotate around some point (center of mass?), while
>> scrolling should change the distance between the camera and said point.
>
> I have always been a big fan of how the 3D solid modeling programs (e.g.
> ProE and SolidWorks) do their 3D navigation. ?The way I see it working with
> Octave is as follows. ?There would be 4 different "views" available from the
> plotting window. ?Views 1-3 would be associated with looking at the plot
> along each of the cardinal axes. ?The four would be the "working view". ?The
> user has 2 options regarding how the object rotations (or the camera rotates
> about the object). ?The first is based on a center of mass idea as you
> indicated. ?This works great for solid modeling, since objects have a clear
> center of mass, but for plotting it is more difficult since it becomes not
> obvious how to weight things like lines. ?A cloud of points would be easiest
> to implement this behavior. ?The second way that solid modeling programs
> work is to allow you to set the center of rotation by switching to the 3
> orthogonal views to set the point of rotation. ?Then, you can return to the
> "working view" and rotate and pan as would be expected. ?This would be
> harder to implement, and I'm not exactly sure how this meshes with how the
> property tree manages camera position, but I think it would help keep from
> grumbling and muttering unspeakable things every time I try to rotate and
> pan in both Matlab and Octave.

These are both good suggestions.
1. for the center of mass rotation -- I am not sure but I think this
should be implemented in octave-core level, rather than in the
backend. This would also add some computational burden. I could
implement the degenerate case of rotating about the center of view
(i.e. the middle of the axes)
2. the solid model way - this is purely backend stuff, and actually
might be easier to implement. Do you have more details -- how exactly
do you select the point in the orthogonal views?

Shai


From pgonzalez at bluel.com  Mon Sep 28 07:23:25 2009
From: pgonzalez at bluel.com (Pete Gonzalez)
Date: Mon, 28 Sep 2009 08:23:25 -0400
Subject: Possible contribution for the "signal" package
Message-ID: <4AC0AABD.4050402@bluel.com>

We are offering to contribute an original implementation of the filter 
design algorithm described in this paper:

I. W. Selesnick, M. Lang, and C. S. Burrus. A modified algorithm for 
constrained least square design of multiband FIR filters without 
specified transition bands. IEEE Trans. on Signal Processing, 
46(2):497-501, February 1998.


Here's a brief explanation of why this code is interesting:

Books often create the impression that Finite Impulse Response (FIR) 
filters are inferior to Infinite Impulse Response (IIR), since IIR 
filters are more advanced.  (More advanced is better, right?)  But 
actually FIR filters have a number of advantages:

   1.6.1 What are the advantages of FIR Filters compared to IIR filters?
   http://dspguru.com/info/faqs/fir/basics.htm


There are two traditional approaches for designing FIR filters.  The 
simple approach is called the windowing or "frequency sampling" method. 
  It obtains the coefficients via an inverse DFT, possibly applying a 
window function to improve behavior between the DFT points.  This is 
fir1.m/fir2.m in Octave.  It's very stable, but produces suboptimal 
results because there is no formal error criterion.

The other traditional approach is the Parks-McClellan solver published 
in 1972, based on the Remez exchange algorithm.  This is remez.cc in 
Octave.  It produces significantly better results (optimal in the 
Chebyshev sense), but the algorithm frequently fails to converge.  It 
also requires careful manual tuning of transition bands, which was 
unacceptable for our application, since we needed to generate FIR 
filters at runtime (i.e. without human oversight).

Despite these shortcomings, these two approaches are the canon of 
classic texts like Lyons' "Understanding DSP", Rorabaugh's "DSP Primer", 
etc.  But in the 1990's a number of innovative new algorithms were 
developed for FIR design.  Sidney Burrus summarizes the results in his 
online book draft:

   "Constrained Approximation and Mixed Criteria"
   http://cnx.org/content/m16923/latest/


If you don't want to babysit your algorithm or carefully tweak its 
results, the most interesting innovation is the Constrained Least 
Squares (CLS) method.  It has three key advantages:  First, although 
it's not proven, in practice CLS always converges for reasonable error 
constraints.  Second, you don't need to specify transition bands -- it 
implicitly finds the smallest transition bands that satisfy the 
specified error, which makes it very "user friendly".  Lastly, the error 
metric provides a theoretical balance between two extremes (see Figure 1 
in the above link), which is helpful for general applications.

Unfortunately Octave's "signal" package does not currently include a CLS 
choice for FIR design.  We have created an optimized C++ implementation 
which we're offering to contribute as an Octave extension under the LGPL 
license.  As far as I know, this is the first implementation of its 
kind.  It's the bandpass version, which will also solve highpass and 
lowpass designs (simply by setting a cutoff to 0 or pi).  It would not 
be difficult to generalize the code for the multiband piecewise 
scenario, but I suspect that relatively few applications would actually 
benefit from that.

Anyway, I think this is a valuable addition to an engineer's toolbox, 
and I hope that you find it useful.  I didn't see an official guideline 
for Octave submissions, so if you need any minor changes to comply with 
your conventions, let me know.

Please CC any replies to the mailing list, since unknown e-mail 
addresses often end up in my spam folder.  ;-)

Thanks,
Pete Gonzalez

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cl2bp.cc
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090928/7c51d4ac/attachment-0001.ksh 

From soren at hauberg.org  Mon Sep 28 08:30:46 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Mon, 28 Sep 2009 15:30:46 +0200
Subject: Possible contribution for the "signal" package
In-Reply-To: <4AC0AABD.4050402@bluel.com>
References: <4AC0AABD.4050402@bluel.com>
Message-ID: <1254144646.4497.23.camel@sh-t400>

man, 28 09 2009 kl. 08:23 -0400, skrev Pete Gonzalez:
> We are offering to contribute an original implementation of the filter 
> design algorithm described in this paper:

I've replied to this message on the Octave-Forge list as it is concerned
with the 'signal' package.

S?ren


From jwe at octave.org  Mon Sep 28 14:24:30 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 28 Sep 2009 15:24:30 -0400
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
Message-ID: <19137.3438.750331.102963@segfault.lan>

On 27-Sep-2009, Shai Ayal wrote:

| The attached changset fixes a bug which did not show the zoom box.
| Also added a function to enable the user to control the zoom factor
| when using mouse wheel zoom.
| 
| I think that with this changeset, the fltk_backend is quite usable as
| a viewer to the gl-renderer.

I applied it.  Zooming seems to work well for me now with either the
scroll wheel or the click and drag method.

| I am open to feature requests.

Just about zooming/rotating issues, or other things?  :-)

If we just had images working, then the fltk backend might be able to
run all the demos...

jwe

From shaiay at gmail.com  Mon Sep 28 14:45:10 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 28 Sep 2009 21:45:10 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <19137.3438.750331.102963@segfault.lan>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
Message-ID: <420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>

On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe at octave.org> wrote:
> On 27-Sep-2009, Shai Ayal wrote:
>
> | The attached changset fixes a bug which did not show the zoom box.
> | Also added a function to enable the user to control the zoom factor
> | when using mouse wheel zoom.
> |
> | I think that with this changeset, the fltk_backend is quite usable as
> | a viewer to the gl-renderer.
>
> I applied it. ?Zooming seems to work well for me now with either the
> scroll wheel or the click and drag method.
>
> | I am open to feature requests.
>
> Just about zooming/rotating issues, or other things? ?:-)
>
> If we just had images working, then the fltk backend might be able to
> run all the demos...

My problem right now is that I have only very short timeslots (~1
hour) for this, so I try to do small simple stuff. I'll have a look at
the image code (probably copy from jhandles as usual..) and see if it
fits the timeslot.

Shai


From jpswensen at comcast.net  Mon Sep 28 16:42:47 2009
From: jpswensen at comcast.net (John Swensen)
Date: Mon, 28 Sep 2009 17:42:47 -0400
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
Message-ID: <6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>


On Sep 28, 2009, at 3:45 PM, Shai Ayal wrote:

> On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe at octave.org> wrote:
>> On 27-Sep-2009, Shai Ayal wrote:
>>
>> | The attached changset fixes a bug which did not show the zoom box.
>> | Also added a function to enable the user to control the zoom factor
>> | when using mouse wheel zoom.
>> |
>> | I think that with this changeset, the fltk_backend is quite  
>> usable as
>> | a viewer to the gl-renderer.
>>
>> I applied it.  Zooming seems to work well for me now with either the
>> scroll wheel or the click and drag method.
>>
>> | I am open to feature requests.
>>
>> Just about zooming/rotating issues, or other things?  :-)
>>
>> If we just had images working, then the fltk backend might be able to
>> run all the demos...
>
> My problem right now is that I have only very short timeslots (~1
> hour) for this, so I try to do small simple stuff. I'll have a look at
> the image code (probably copy from jhandles as usual..) and see if it
> fits the timeslot.
>
> Shai
>

Is implementing the images in the gl renderer and harder than making a  
texture with the image on it as a very small negative z-depth, so that  
things plotted on top of it show up?  If that is the case, then I may  
be able to take look at this.

John

From tmacchant at yahoo.co.jp  Mon Sep 28 22:19:56 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 29 Sep 2009 12:19:56 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50 built
	by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090923001202.49818.qmail@web3807.mail.bbt.yahoo.co.jp>
Message-ID: <20090929031956.28217.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello

--- Tatsuro MATSUOKA  wrote:
> I have built octave-3.3.50 mingw-gcc-4.4.0.
> 
> At the prompt I execute octave from the prompt
> 
> $ octave
> 
> $
>  
> Octave starts but finishes soon without any messages.

This problem caused by the linker flags acquired from fltk-config.

  FLTK backend libs:    -L/c/Programs/OctaveBuild/lib -mwindows -Lc:/Programs/OctaveBuild/lib
-Lc:/Programs/WinDevTools/lib -Lc:/Programs/GnuWin32/lib -mno-cygwin -Wl,--enable-auto-import
-Wl,--enable-runtime-pseudo-reloc -lfltk_gl -lglu32-lopengl32 -lfltk -lpthread -lole32 -lcomctl32

The above incules -mwindows and this flag made it impossible to startup octave.

Similar problem occur console mode gnuplot 4.3 for windows with wxt terminal.
See 

http://www.nabble.com/console-mode-gnuplot-for-windows-with-wxt-doen-not-work-(gnuplot-4.3---mingw)-td25536073.html

http://www.nabble.com/Patch-for-makefile.mgw-for-console-mode-of-gnuplot-4.3-for-windows-td25643747.html

First I have kick out this problem by tweaking wx-config, by which 'make' of gnuplot gets linker flag.
 However, this kind of tweaking is better to be avoided if possible.

I have discussed linker option problem with the developer of wxWidgets. He proposed to use
-Wl,--subsystem,console option to override of -mwindows.

In the gnuplot case, I now propose two patches
FIrst:
-	WX_LIBS = $(shell wx-config --libs)
+	WX_LIBS = $(shell wx-config --libs | sed -e 's/ -Wl,--subsystem,windows -mwindows//')
Second:
 	WX_LIBS = $(shell wx-config --libs)
+	ifdef PIPES
+		WX_LIBS += -Wl,--subsystem,console
+	endif

In case that I consider the patch for fltk-config for windows, is which way is better?

Regards

Tatsuro

--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

From shaiay at gmail.com  Mon Sep 28 23:30:34 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 29 Sep 2009 06:30:34 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
	<6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>
Message-ID: <420fb9e60909282130k737ab7bfq46704bc2e99f6147@mail.gmail.com>

On Mon, Sep 28, 2009 at 11:42 PM, John Swensen <jpswensen at comcast.net> wrote:
>
> On Sep 28, 2009, at 3:45 PM, Shai Ayal wrote:
>
>> On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe at octave.org> wrote:
>>>
>>> On 27-Sep-2009, Shai Ayal wrote:
>>>
>>> | The attached changset fixes a bug which did not show the zoom box.
>>> | Also added a function to enable the user to control the zoom factor
>>> | when using mouse wheel zoom.
>>> |
>>> | I think that with this changeset, the fltk_backend is quite usable as
>>> | a viewer to the gl-renderer.
>>>
>>> I applied it. ?Zooming seems to work well for me now with either the
>>> scroll wheel or the click and drag method.
>>>
>>> | I am open to feature requests.
>>>
>>> Just about zooming/rotating issues, or other things? ?:-)
>>>
>>> If we just had images working, then the fltk backend might be able to
>>> run all the demos...
>>
>> My problem right now is that I have only very short timeslots (~1
>> hour) for this, so I try to do small simple stuff. I'll have a look at
>> the image code (probably copy from jhandles as usual..) and see if it
>> fits the timeslot.
>>
>> Shai
>>
>
> Is implementing the images in the gl renderer and harder than making a
> texture with the image on it as a very small negative z-depth, so that
> things plotted on top of it show up? ?If that is the case, then I may be
> able to take look at this.

That should do the trick, and there is even a texture helper class
already in gl-render.cc
However there might be a complication if the image is large (10
megapixel images are not uncommon) - I am not sure but there will be
limits to texture sizes. Maybe using a gl bitmap might be better? I
have not studied this yet, so I'm unsure

Shai


From shaiay at gmail.com  Mon Sep 28 23:40:17 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 29 Sep 2009 06:40:17 +0200
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50 
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090929031956.28217.qmail@web3814.mail.bbt.yahoo.co.jp>
References: <20090923001202.49818.qmail@web3807.mail.bbt.yahoo.co.jp>
	<20090929031956.28217.qmail@web3814.mail.bbt.yahoo.co.jp>
Message-ID: <420fb9e60909282140p45c02c82xb8e90c07f9aa6345@mail.gmail.com>

2009/9/29 Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>:
> Hello
>
> --- Tatsuro MATSUOKA ?wrote:
>> I have built octave-3.3.50 mingw-gcc-4.4.0.
>>
>> At the prompt I execute octave from the prompt
>>
>> $ octave
>>
>> $
>>
>> Octave starts but finishes soon without any messages.
>
> This problem caused by the linker flags acquired from fltk-config.
>
> ?FLTK backend libs: ? ?-L/c/Programs/OctaveBuild/lib -mwindows -Lc:/Programs/OctaveBuild/lib
> -Lc:/Programs/WinDevTools/lib -Lc:/Programs/GnuWin32/lib -mno-cygwin -Wl,--enable-auto-import
> -Wl,--enable-runtime-pseudo-reloc -lfltk_gl -lglu32-lopengl32 -lfltk -lpthread -lole32 -lcomctl32
>
> The above incules -mwindows and this flag made it impossible to startup octave.
>
> Similar problem occur console mode gnuplot 4.3 for windows with wxt terminal.
> See
>
> http://www.nabble.com/console-mode-gnuplot-for-windows-with-wxt-doen-not-work-(gnuplot-4.3---mingw)-td25536073.html
>
> http://www.nabble.com/Patch-for-makefile.mgw-for-console-mode-of-gnuplot-4.3-for-windows-td25643747.html
>
> First I have kick out this problem by tweaking wx-config, by which 'make' of gnuplot gets linker flag.
> ?However, this kind of tweaking is better to be avoided if possible.
>
> I have discussed linker option problem with the developer of wxWidgets. He proposed to use
> -Wl,--subsystem,console option to override of -mwindows.
>
> In the gnuplot case, I now propose two patches
> FIrst:
> - ? ? ? WX_LIBS = $(shell wx-config --libs)
> + ? ? ? WX_LIBS = $(shell wx-config --libs | sed -e 's/ -Wl,--subsystem,windows -mwindows//')
> Second:
> ? ? ? ?WX_LIBS = $(shell wx-config --libs)
> + ? ? ? ifdef PIPES
> + ? ? ? ? ? ? ? WX_LIBS += -Wl,--subsystem,console
> + ? ? ? endif
>
> In case that I consider the patch for fltk-config for windows, is which way is better?
>
Hi

I have never used fltk with mingw, only cygwin, so I don't know :(
Did you try to compile with these flags? what were the results of
removing -mwindows -- did the fltk backend compile/run?

Shai


From tmacchant at yahoo.co.jp  Tue Sep 29 02:03:31 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 29 Sep 2009 16:03:31 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <420fb9e60909282140p45c02c82xb8e90c07f9aa6345@mail.gmail.com>
Message-ID: <20090929070331.56078.qmail@web3805.mail.bbt.yahoo.co.jp>

Hello

--- Shai Ayal  wrote:

> Hi
> 
> I have never used fltk with mingw, only cygwin, so I don't know :(
> Did you try to compile with these flags? what were the results of
> removing -mwindows -- did the fltk backend compile/run?

Yes it work if I remove '-mwindows' flag from fltk-config. (Howeever, eigs.cc test causes segfault! in
the yesterday run).
 
It is also case for wxWidget case for gnuplot.  I discussed one of the wxWidget developer. I proposed
that -mwindows flag is to be removed from wx-config.  However, my proposal is rejected because most
users use native windows application. 

Tweaking wx-config is easy but the tweaking without careful consideration is better to be avoided. I'm
afraid that it may cause unwanted results when I use wxWidget libraries for other applications.

In the case of fltk and octave, I think it would better to modify configure setting of octave than to
modify fltk-config.  That is because fltk is not only used for octave. So that change of default
setting should be avoided if possible. 

How do other people think about this case ?

Regards

Tatsuro 

--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

From michael.creel at uab.es  Tue Sep 29 03:38:05 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 29 Sep 2009 10:38:05 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <7FFEF1E9-C3A3-433A-A0DC-B2F434E40420@mac.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<7FFEF1E9-C3A3-433A-A0DC-B2F434E40420@mac.com>
Message-ID: <c8f260e70909290138x6cbc695ai646e8822812c6a00@mail.gmail.com>

Hi all,

On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark

%%%%%%%%%%%%%%%%%%%%%%
n = 500;
R = triu (rand (n));
u = rand (n, 1);

tic; for i = 1:1000; R \ u; endfor; toc
tic; for i = 1:1000; u' / R; endfor; toc
tic; for i = 1:1000; R' \ u; endfor; toc

R = tril (rand (n));
u = rand (n, 1);

tic; for i = 1:1000; R \ u; endfor; toc
tic; for i = 1:1000; u' / R; endfor; toc
tic; for i = 1:1000; R' \ u; endfor; toc

u = u + I*rand (n, 1);
tic; for i = 1:1000; R \ u; endfor; toc
tic; for i = 1:1000; R' \ u; endfor; toc


n = 800;
a = rand (n);
b = rand (n) + i*rand (n);
tic; a * b; toc
tic; b * a; toc
tic; a' * b; toc
tic; b * a'; toc
tic; a \ b; toc
tic; b / a; toc
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get


octave:4> bench
Elapsed time is 0.20216 seconds.
Elapsed time is 1.93894 seconds.
Elapsed time is 2.33824 seconds.
Elapsed time is 0.188448 seconds.
Elapsed time is 1.95657 seconds.
Elapsed time is 2.43552 seconds.
Elapsed time is 4.08299 seconds.
Elapsed time is 7.84752 seconds.
Elapsed time is 0.213021 seconds.
Elapsed time is 0.21117 seconds.
Elapsed time is 0.218387 seconds.
Elapsed time is 0.217174 seconds.
Elapsed time is 0.452714 seconds.
Elapsed time is 0.391383 seconds.
octave:5>



Matlab 2008b gives
>> bench
Elapsed time is 0.289161 seconds.
Elapsed time is 0.566446 seconds.
Elapsed time is 0.562623 seconds.
Elapsed time is 0.253456 seconds.
Elapsed time is 0.574304 seconds.
Elapsed time is 0.570281 seconds.
Elapsed time is 0.253070 seconds.
Elapsed time is 0.572601 seconds.
Elapsed time is 0.102086 seconds.
Elapsed time is 0.102677 seconds.
Elapsed time is 0.103080 seconds.
Elapsed time is 0.103759 seconds.
Elapsed time is 0.165608 seconds.
Elapsed time is 0.181704 seconds.
>>


Octave 3.2.3+ from today, self compiled, gives
octave:1> bench
Elapsed time is 0.208794 seconds.
Elapsed time is 0.189178 seconds.
Elapsed time is 0.186724 seconds.
Elapsed time is 0.188649 seconds.
Elapsed time is 0.192915 seconds.
Elapsed time is 0.19166 seconds.
Elapsed time is 0.186277 seconds.
Elapsed time is 0.19102 seconds.
Elapsed time is 0.212707 seconds.
Elapsed time is 0.211013 seconds.
Elapsed time is 0.210491 seconds.
Elapsed time is 0.210447 seconds.
Elapsed time is 0.431791 seconds.
Elapsed time is 0.367412 seconds.
octave:2>

Congratulations!
Michael






On Fri, Sep 25, 2009 at 8:55 AM, Ben Abbott <bpabbott at mac.com> wrote:
>
> On Sep 23, 2009, at 12:50 PM, Jaroslav Hajek wrote:
>
>> hi all,
>>
>> the following three patches:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/afcf852256d2
>> http://hg.savannah.gnu.org/hgweb/octave/rev/0d3b248f4ab6
>> http://hg.savannah.gnu.org/hgweb/octave/rev/7e5b4de5fbfe
>>
>> add new optimizations for matrix multiplication and division. Quote for
>> NEWS:
>>
>> ** More efficient matrix division handling. Octave is now able to
>> handle the expressions
>>
>> ? ? ?M' \ v
>> ? ? ?M.' \ v
>> ? ? ?v / M
>>
>> ? (M is a matrix and v is a vector) more efficiently in certain cases.
>> ? In particular, if M is triangular, all three expressions will be
>> handled by a single call to
>> ? xTRTRS, with appropriate flags. Previously, all three expressions
>> required a physical transpose
>> ? of M.
>>
>> ** More efficient handling of certain mixed real-complex matrix
>> operations.
>> ? For instance, if RM is a real matrix and CM a complex matrix,
>>
>> ? ? RM * CM
>>
>> ? can now be evaluated either as
>>
>> ? ? complex (RM * real (CM), RM * imag (CM))
>>
>> ? or as
>>
>> ? ? complex (RM) * CM,
>>
>> ? depending on the dimensions. The 1st form requires more
>> temporaries and copying,
>> ? but halves the count of FLOPs, which normally brings better performance
>> if
>> ? RM has enough rows. Previously, the 2nd form was always used.
>>
>> ? Matrix division is similarly affected.
>>
>> The triangular optimization is well demonstrated by this benchmark:
>>
>> n = 500;
>> R = triu (rand (n));
>> u = rand (n, 1);
>>
>> tic; for i = 1:1000; R \ u; endfor; toc
>> tic; for i = 1:1000; u' / R; endfor; toc
>> tic; for i = 1:1000; R' \ u; endfor; toc
>>
>> R = tril (rand (n));
>> u = rand (n, 1);
>>
>> tic; for i = 1:1000; R \ u; endfor; toc
>> tic; for i = 1:1000; u' / R; endfor; toc
>> tic; for i = 1:1000; R' \ u; endfor; toc
>>
>> u = u + I*rand (n, 1);
>> tic; for i = 1:1000; R \ u; endfor; toc
>> tic; for i = 1:1000; R' \ u; endfor; toc
>>
>>
>> with a recent tip, I got (Core 2 Duo @ 2.83 GHz, g++ -O3
>> -march=native, self-built GotoBLAS + LAPACK):
>>
>> Elapsed time is 0.225974 seconds.
>> Elapsed time is 0.78818 seconds.
>> Elapsed time is 1.81756 seconds.
>> Elapsed time is 0.219842 seconds.
>> Elapsed time is 0.79384 seconds.
>> Elapsed time is 1.83497 seconds.
>> Elapsed time is 4.32738 seconds.
>> Elapsed time is 7.73774 seconds.
>>
>> with the new patches, I get
>>
>> Elapsed time is 0.221489 seconds.
>> Elapsed time is 0.204968 seconds.
>> Elapsed time is 0.204267 seconds.
>> Elapsed time is 0.219243 seconds.
>> Elapsed time is 0.20444 seconds.
>> Elapsed time is 0.202193 seconds.
>> Elapsed time is 0.227214 seconds.
>> Elapsed time is 0.209824 seconds.
>>
>> This is particularly cool when working intensively with Cholesky, LU
>> or QR factorizations - you can do both A \ v and A' \ v almost as
>> efficiently as with raw BLAS.
>>
>> Also, there's some speed-up with real x complex multiplication and
>> division, which is not a very common operation, but sometimes needed.
>> The point is that for bigger matrices, complex (RM * real (CM), RM *
>> imag (CM)) is typically up to 2x faster than complex (RM) * CM.
>> Surprised? Just count the FLOPs. On the other hand, the former
>> expression is less friendly for Octave's complex storage.
>>
>> The benchmark is:
>>
>> n = 800;
>> a = rand (n);
>> b = rand (n) + i*rand (n);
>> tic; a * b; toc
>> tic; b * a; toc
>> tic; a' * b; toc
>> tic; b * a'; toc
>> tic; a \ b; toc
>> tic; b / a; toc
>>
>> with a recent tip:
>>
>> Elapsed time is 0.431021 seconds.
>> Elapsed time is 0.410468 seconds.
>> Elapsed time is 0.411169 seconds.
>> Elapsed time is 0.412252 seconds.
>> Elapsed time is 0.641075 seconds.
>> Elapsed time is 0.66255 seconds.
>>
>> with the new patches:
>>
>> Elapsed time is 0.221522 seconds.
>> Elapsed time is 0.2183 seconds.
>> Elapsed time is 0.22033 seconds.
>> Elapsed time is 0.22058 seconds.
>> Elapsed time is 0.297738 seconds.
>> Elapsed time is 0.325542 seconds.
>>
>> The conclusion is that Octave 3.4 will again be able to map linear
>> algebra code more efficiently onto BLAS and LAPACK than the previous
>> version.
>
> Running Matlab on Mac OSX (MKL, or ???)
>
> Elapsed time is 0.277841 seconds.
> Elapsed time is 2.040261 seconds.
> Elapsed time is 2.051063 seconds.
> Elapsed time is 0.276847 seconds.
> Elapsed time is 2.070356 seconds.
> Elapsed time is 2.023176 seconds.
> Elapsed time is 0.381263 seconds.
> Elapsed time is 2.177680 seconds.
>
> Octave compiled with Apples Lapack/Blas (vecLib).
>
> Elapsed time is 0.211057 seconds.
> Elapsed time is 0.230565 seconds.
> Elapsed time is 0.202384 seconds.
> Elapsed time is 0.219704 seconds.
> Elapsed time is 0.219448 seconds.
> Elapsed time is 0.198678 seconds.
> Elapsed time is 0.308611 seconds.
> Elapsed time is 0.282597 seconds.
>
> Ben
>
>


From highegg at gmail.com  Tue Sep 29 03:44:23 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 10:44:23 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <c8f260e70909290138x6cbc695ai646e8822812c6a00@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<7FFEF1E9-C3A3-433A-A0DC-B2F434E40420@mac.com>
	<c8f260e70909290138x6cbc695ai646e8822812c6a00@mail.gmail.com>
Message-ID: <69d8d540909290144x4dcf3655xa3ddc673b7be281d@mail.gmail.com>

On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
> Hi all,
>
> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>
> %%%%%%%%%%%%%%%%%%%%%%
> n = 500;
> R = triu (rand (n));
> u = rand (n, 1);
>
> tic; for i = 1:1000; R \ u; endfor; toc
> tic; for i = 1:1000; u' / R; endfor; toc
> tic; for i = 1:1000; R' \ u; endfor; toc
>
> R = tril (rand (n));
> u = rand (n, 1);
>
> tic; for i = 1:1000; R \ u; endfor; toc
> tic; for i = 1:1000; u' / R; endfor; toc
> tic; for i = 1:1000; R' \ u; endfor; toc
>
> u = u + I*rand (n, 1);
> tic; for i = 1:1000; R \ u; endfor; toc
> tic; for i = 1:1000; R' \ u; endfor; toc
>
>
> n = 800;
> a = rand (n);
> b = rand (n) + i*rand (n);
> tic; a * b; toc
> tic; b * a; toc
> tic; a' * b; toc
> tic; b * a'; toc
> tic; a \ b; toc
> tic; b / a; toc
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>
>
> octave:4> bench
> Elapsed time is 0.20216 seconds.
> Elapsed time is 1.93894 seconds.
> Elapsed time is 2.33824 seconds.
> Elapsed time is 0.188448 seconds.
> Elapsed time is 1.95657 seconds.
> Elapsed time is 2.43552 seconds.
> Elapsed time is 4.08299 seconds.
> Elapsed time is 7.84752 seconds.
> Elapsed time is 0.213021 seconds.
> Elapsed time is 0.21117 seconds.
> Elapsed time is 0.218387 seconds.
> Elapsed time is 0.217174 seconds.
> Elapsed time is 0.452714 seconds.
> Elapsed time is 0.391383 seconds.
> octave:5>
>
>
>
> Matlab 2008b gives
>>> bench
> Elapsed time is 0.289161 seconds.
> Elapsed time is 0.566446 seconds.
> Elapsed time is 0.562623 seconds.
> Elapsed time is 0.253456 seconds.
> Elapsed time is 0.574304 seconds.
> Elapsed time is 0.570281 seconds.
> Elapsed time is 0.253070 seconds.
> Elapsed time is 0.572601 seconds.
> Elapsed time is 0.102086 seconds.
> Elapsed time is 0.102677 seconds.
> Elapsed time is 0.103080 seconds.
> Elapsed time is 0.103759 seconds.
> Elapsed time is 0.165608 seconds.
> Elapsed time is 0.181704 seconds.
>>>
>
>
> Octave 3.2.3+ from today, self compiled, gives
> octave:1> bench
> Elapsed time is 0.208794 seconds.
> Elapsed time is 0.189178 seconds.
> Elapsed time is 0.186724 seconds.
> Elapsed time is 0.188649 seconds.
> Elapsed time is 0.192915 seconds.
> Elapsed time is 0.19166 seconds.
> Elapsed time is 0.186277 seconds.
> Elapsed time is 0.19102 seconds.
> Elapsed time is 0.212707 seconds.
> Elapsed time is 0.211013 seconds.
> Elapsed time is 0.210491 seconds.
> Elapsed time is 0.210447 seconds.
> Elapsed time is 0.431791 seconds.
> Elapsed time is 0.367412 seconds.
> octave:2>
>
> Congratulations!
> Michael
>

It's interesting you didn't get any speed-up in the second part of the
benchmark, compared to 3.0.1...
What BLAS and LAPACK are you using? What's your compiler configuration?
Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
mean "3.3.50+", i.e. the development version?

thanks

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

From tmacchant at yahoo.co.jp  Tue Sep 29 03:22:51 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 29 Sep 2009 17:22:51 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090929070331.56078.qmail@web3805.mail.bbt.yahoo.co.jp>
Message-ID: <20090929082251.37122.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello

--- Tatsuro MATSUOKA wrote:

> Yes it work if I remove '-mwindows' flag from fltk-config. (Howeever, eigs.cc test causes
> segfault! in
> the yesterday run).
>  
> It is also case for wxWidget case for gnuplot.  I discussed one of the wxWidget developer. I
> proposed
> that -mwindows flag is to be removed from wx-config.  However, my proposal is rejected because
> most
> users use native windows application. 
> 
> Tweaking wx-config is easy but the tweaking without careful consideration is better to be
> avoided. I'm
> afraid that it may cause unwanted results when I use wxWidget libraries for other applications.
> 
> In the case of fltk and octave, I think it would better to modify configure setting of octave
> than to
> modify fltk-config.  That is because fltk is not only used for octave. So that change of default
> setting should be avoided if possible. 
> 
> How do other people think about this case ?


I have considered the patch

--- configure.in.orig	2009-09-12 19:52:06 +0900
+++ configure.in	2009-09-29 16:56:09 +0900
@@ -845,7 +845,7 @@
   warn_fltk_config="FLTK config script not found.  Native graphics will be disabled."
 else
   FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`"
-  FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`"
+  FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags | sed -e 's/ -mwindows//'`"
   
   AC_MSG_CHECKING(for OpenGL support in FLTK)
   cat > conftest.cc <<EOF

******************************
By the patch

FLTK backend libs:    -L/c/Programs/OctaveBuild/lib -mwindows -Lc:/Programs/OctaveBuild/lib
-Lc:/Programs/WinDevTools/lib -Lc:/Programs/GnuWin32/lib -mno-cygwin -Wl,--enable-auto-import
-Wl,--enable-runtime-pseudo-reloc -lfltk_gl -lglu32-lopengl32 -lfltk -lpthread -lole32 -lcomctl32

  |
  |
  V

 FLTK backend libs:    -L/c/Programs/OctaveBuild/lib -Lc:/Programs/OctaveBuild/lib
-Lc:/Programs/WinDevTools/lib -Lc:/Programs/GnuWin32/lib -mno-cygwin -Wl,--enable-auto-import
-Wl,--enable-runtime-pseudo-reloc -lfltk_gl -lglu32 -lopengl32-lfltk -lpthread -lole32 -lcomctl32

Regards

Tatsuro

--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

From michael.goffioul at gmail.com  Tue Sep 29 03:53:56 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Tue, 29 Sep 2009 09:53:56 +0100
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909282130k737ab7bfq46704bc2e99f6147@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
	<6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>
	<420fb9e60909282130k737ab7bfq46704bc2e99f6147@mail.gmail.com>
Message-ID: <128f38bd0909290153y263b4c7aw59bc5c95ea6ae728@mail.gmail.com>

The way I did it in JHandles is by using a texture and drawing a filled
rectangle in the middle of the plot box (z == (zmin+zmax)/2). The
low-level code is already present in octave; for instance you can
already apply a texture to a surface object (did you know that?).

Adding image support to octave is something that is in my mind for
a couple of months now. But besides lack of time (I'm busy with
another personal project), the main thing I'd like to implement before
that is a good, efficient and generic cache system in the graphics
code. Indeed, as converting the image data into something that is
usable in OpenGL and loading it into video memory is a time-consuming
process, you'd want to cache the result (texture index) for re-use on
the next redraw (that's done in JHandles). The main problem I still
have to resolve is where to store the cache objects (octave, renderer,
backend...) and the process of invalidating the cache. For instance,
concerning the latter, changing the figure colormap might invalidate
images cached texture if they use indexed colors.

Now, the current code in octave uses regular OpenGL textures, but
this approach has several limitations:
- the texture needs to be square and a power of 2, which can be very
  inefficient for non-square images, or with a size that is 2^n+1 pixel
  wide; in that case, detecting non-square texture support in the
  OpenGL engine and using it is probably a better approach
- textures are limited in size: for instance on my laptop the maximum
  texture size is 2048*2048; decomposing the main texture into several
  subtextures can work around the problem, but that's not trivial

Michael.


On Tue, Sep 29, 2009 at 5:30 AM, Shai Ayal <shaiay at gmail.com> wrote:
> On Mon, Sep 28, 2009 at 11:42 PM, John Swensen <jpswensen at comcast.net> wrote:
>>
>> On Sep 28, 2009, at 3:45 PM, Shai Ayal wrote:
>>
>>> On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe at octave.org> wrote:
>>>>
>>>> On 27-Sep-2009, Shai Ayal wrote:
>>>>
>>>> | The attached changset fixes a bug which did not show the zoom box.
>>>> | Also added a function to enable the user to control the zoom factor
>>>> | when using mouse wheel zoom.
>>>> |
>>>> | I think that with this changeset, the fltk_backend is quite usable as
>>>> | a viewer to the gl-renderer.
>>>>
>>>> I applied it. ?Zooming seems to work well for me now with either the
>>>> scroll wheel or the click and drag method.
>>>>
>>>> | I am open to feature requests.
>>>>
>>>> Just about zooming/rotating issues, or other things? ?:-)
>>>>
>>>> If we just had images working, then the fltk backend might be able to
>>>> run all the demos...
>>>
>>> My problem right now is that I have only very short timeslots (~1
>>> hour) for this, so I try to do small simple stuff. I'll have a look at
>>> the image code (probably copy from jhandles as usual..) and see if it
>>> fits the timeslot.
>>>
>>> Shai
>>>
>>
>> Is implementing the images in the gl renderer and harder than making a
>> texture with the image on it as a very small negative z-depth, so that
>> things plotted on top of it show up? ?If that is the case, then I may be
>> able to take look at this.
>
> That should do the trick, and there is even a texture helper class
> already in gl-render.cc
> However there might be a complication if the image is large (10
> megapixel images are not uncommon) - I am not sure but there will be
> limits to texture sizes. Maybe using a gl bitmap might be better? I
> have not studied this yet, so I'm unsure
>
> Shai
>
>


From shaiay at gmail.com  Tue Sep 29 04:01:38 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 29 Sep 2009 11:01:38 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <128f38bd0909290153y263b4c7aw59bc5c95ea6ae728@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
	<6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>
	<420fb9e60909282130k737ab7bfq46704bc2e99f6147@mail.gmail.com>
	<128f38bd0909290153y263b4c7aw59bc5c95ea6ae728@mail.gmail.com>
Message-ID: <420fb9e60909290201l1be24621o411f9e369aa627c5@mail.gmail.com>

On Tue, Sep 29, 2009 at 10:53 AM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> The way I did it in JHandles is by using a texture and drawing a filled
> rectangle in the middle of the plot box (z == (zmin+zmax)/2). The
> low-level code is already present in octave; for instance you can
> already apply a texture to a surface object (did you know that?).
>
> Adding image support to octave is something that is in my mind for
> a couple of months now. But besides lack of time (I'm busy with
> another personal project), the main thing I'd like to implement before
> that is a good, efficient and generic cache system in the graphics
> code. Indeed, as converting the image data into something that is
> usable in OpenGL and loading it into video memory is a time-consuming
> process, you'd want to cache the result (texture index) for re-use on
> the next redraw (that's done in JHandles). The main problem I still
> have to resolve is where to store the cache objects (octave, renderer,
> backend...) and the process of invalidating the cache. For instance,
> concerning the latter, changing the figure colormap might invalidate
> images cached texture if they use indexed colors.
>
> Now, the current code in octave uses regular OpenGL textures, but
> this approach has several limitations:
> - the texture needs to be square and a power of 2, which can be very
> ?inefficient for non-square images, or with a size that is 2^n+1 pixel
> ?wide; in that case, detecting non-square texture support in the
> ?OpenGL engine and using it is probably a better approach
> - textures are limited in size: for instance on my laptop the maximum
> ?texture size is 2048*2048; decomposing the main texture into several
> ?subtextures can work around the problem, but that's not trivial

What would you say to using opengl bitmaps? As far as a\I managed to
read up on them this morning thy don't have a size limit, and they can
be scaled. They are limited -- they do not participate in all they
perspective and 3D stuff, but I think images are meant to be this way
-- if you want something more sophisticated you can use a textured
surface, or convert the image to a surface.

Shai


From michael.goffioul at gmail.com  Tue Sep 29 04:12:00 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Tue, 29 Sep 2009 10:12:00 +0100
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909290201l1be24621o411f9e369aa627c5@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
	<6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>
	<420fb9e60909282130k737ab7bfq46704bc2e99f6147@mail.gmail.com>
	<128f38bd0909290153y263b4c7aw59bc5c95ea6ae728@mail.gmail.com>
	<420fb9e60909290201l1be24621o411f9e369aa627c5@mail.gmail.com>
Message-ID: <128f38bd0909290212v7ed1d211t37ae39b40363cd12@mail.gmail.com>

On Tue, Sep 29, 2009 at 10:01 AM, Shai Ayal <shaiay at gmail.com> wrote:
> What would you say to using opengl bitmaps? As far as a\I managed to
> read up on them this morning thy don't have a size limit, and they can
> be scaled. They are limited -- they do not participate in all they
> perspective and 3D stuff, but I think images are meant to be this way
> -- if you want something more sophisticated you can use a textured
> surface, or convert the image to a surface.

I see 2 problems with using bitmaps:
- they are not 3D
- you have a 1-to-1 pixel mapping between the bitmap and the screen,
  which is not what Matlab is doing; for instance a colorbar is just a
  c x 1 image object rendered in a m x n box (m>c, n>>1); you can do
  that seamlessly with textures

Moreover, texture rendering is much faster than using bitmaps.

From j4r.e4o at gmail.com  Tue Sep 29 04:16:22 2009
From: j4r.e4o at gmail.com (Javier Enciso)
Date: Tue, 29 Sep 2009 11:16:22 +0200
Subject: divergence function
Message-ID: <4AC1D066.9090803@googlemail.com>

Hi All,

I' not sure whether this email already reach you guys, I wasn't member 
of the mailing list, anyway I just resend it.

I'm glad to contribute with the 'divergence' function. This function
is used to compute divergence of vector field and is part of Matlab's
core functions.

In doubt, please feel free to contact me.

Regards,
Javier
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: divergence.m
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090929/0c51d578/attachment-0001.ksh 

From shaiay at gmail.com  Tue Sep 29 04:22:00 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 29 Sep 2009 11:22:00 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <128f38bd0909290212v7ed1d211t37ae39b40363cd12@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
	<6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>
	<420fb9e60909282130k737ab7bfq46704bc2e99f6147@mail.gmail.com>
	<128f38bd0909290153y263b4c7aw59bc5c95ea6ae728@mail.gmail.com>
	<420fb9e60909290201l1be24621o411f9e369aa627c5@mail.gmail.com>
	<128f38bd0909290212v7ed1d211t37ae39b40363cd12@mail.gmail.com>
Message-ID: <420fb9e60909290222t1a5ca9c2geab30c700a1e7e75@mail.gmail.com>

On Tue, Sep 29, 2009 at 11:12 AM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> I see 2 problems with using bitmaps:
> - they are not 3D
But images are not 3D either right?

> - you have a 1-to-1 pixel mapping between the bitmap and the screen,
> ?which is not what Matlab is doing; for instance a colorbar is just a
> ?c x 1 image object rendered in a m x n box (m>c, n>>1); you can do
> ?that seamlessly with textures
I thought so too, but I found out this morning about glPixelZoom which
will scale the bitmap:
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/pixelzoom.html

> Moreover, texture rendering is much faster than using bitmaps
I suppose this will depend on the hardware. I would think that at
least for software only implementations like mesa, bitmap would be
faster since less processing is needed before drawing (e.g. no
transformation matrix)

Shai


From highegg at gmail.com  Tue Sep 29 04:38:54 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 11:38:54 +0200
Subject: divergence function
In-Reply-To: <4AC1D066.9090803@googlemail.com>
References: <4AC1D066.9090803@googlemail.com>
Message-ID: <69d8d540909290238l110bc56ap21ecf2748d6b0ccd@mail.gmail.com>

On Tue, Sep 29, 2009 at 11:16 AM, Javier Enciso <j4r.e4o at gmail.com> wrote:
> Hi All,
>
> I' not sure whether this email already reach you guys, I wasn't member of
> the mailing list, anyway I just resend it.
>
> I'm glad to contribute with the 'divergence' function. This function
> is used to compute divergence of vector field and is part of Matlab's
> core functions.
>
> In doubt, please feel free to contact me.
>
> Regards,
> Javier
>

Hello Javier,

I have a couple of suggestions:
1. Please don't use tabs (or 8 spaces) to indent the code; use two
spaces. This is done everywhere in Octave sources.

2. blocks like
>                        x = varargin {1};
>                        y = varargin {2};
>                        z = varargin {3};
>                        u = varargin {4};
>                        v = varargin {5};
>                        w = varargin {6};
can be abbreviated to

[x,y,z,u,v,w] = deal (varargin{1:6});

this improves readability. Consider doing it.

3. in check_dim, the for loops can be avoided:

function [] = check_dim (varargin)
  if (!size_equal (varargin{:})
    error ("Size of matrices must be equal");
  endif

  switch (nargin)
  case {2, 4}
    if (any (cellfun (@ndims, varargin) != 2))
      error ("Matrices must have 2 dimensions");
    endif
  case {3, 6}			
    if (any (cellfun (@ndims, varargin) != 3))
      error ("Matrices must have 3 dimensions");
    endif
  endswitch
endfunction


no big concern about performance in this case, since nargin is small,
but it also seems to improve readability, at least to me...

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

From michael.creel at uab.es  Tue Sep 29 05:26:52 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 29 Sep 2009 12:26:52 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909290144x4dcf3655xa3ddc673b7be281d@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290138x6cbc695ai646e8822812c6a00@mail.gmail.com>
	<69d8d540909290144x4dcf3655xa3ddc673b7be281d@mail.gmail.com>
Message-ID: <c8f260e70909290326u76f85d88n4fafa62eaa327654@mail.gmail.com>

On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>> Hi all,
>>
>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>
>> %%%%%%%%%%%%%%%%%%%%%%
>> n = 500;
>> R = triu (rand (n));
>> u = rand (n, 1);
>>
>> tic; for i = 1:1000; R \ u; endfor; toc
>> tic; for i = 1:1000; u' / R; endfor; toc
>> tic; for i = 1:1000; R' \ u; endfor; toc
>>
>> R = tril (rand (n));
>> u = rand (n, 1);
>>
>> tic; for i = 1:1000; R \ u; endfor; toc
>> tic; for i = 1:1000; u' / R; endfor; toc
>> tic; for i = 1:1000; R' \ u; endfor; toc
>>
>> u = u + I*rand (n, 1);
>> tic; for i = 1:1000; R \ u; endfor; toc
>> tic; for i = 1:1000; R' \ u; endfor; toc
>>
>>
>> n = 800;
>> a = rand (n);
>> b = rand (n) + i*rand (n);
>> tic; a * b; toc
>> tic; b * a; toc
>> tic; a' * b; toc
>> tic; b * a'; toc
>> tic; a \ b; toc
>> tic; b / a; toc
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>
>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>
>>
>> octave:4> bench
>> Elapsed time is 0.20216 seconds.
>> Elapsed time is 1.93894 seconds.
>> Elapsed time is 2.33824 seconds.
>> Elapsed time is 0.188448 seconds.
>> Elapsed time is 1.95657 seconds.
>> Elapsed time is 2.43552 seconds.
>> Elapsed time is 4.08299 seconds.
>> Elapsed time is 7.84752 seconds.
>> Elapsed time is 0.213021 seconds.
>> Elapsed time is 0.21117 seconds.
>> Elapsed time is 0.218387 seconds.
>> Elapsed time is 0.217174 seconds.
>> Elapsed time is 0.452714 seconds.
>> Elapsed time is 0.391383 seconds.
>> octave:5>
>>
>>
>>
>> Matlab 2008b gives
>>>> bench
>> Elapsed time is 0.289161 seconds.
>> Elapsed time is 0.566446 seconds.
>> Elapsed time is 0.562623 seconds.
>> Elapsed time is 0.253456 seconds.
>> Elapsed time is 0.574304 seconds.
>> Elapsed time is 0.570281 seconds.
>> Elapsed time is 0.253070 seconds.
>> Elapsed time is 0.572601 seconds.
>> Elapsed time is 0.102086 seconds.
>> Elapsed time is 0.102677 seconds.
>> Elapsed time is 0.103080 seconds.
>> Elapsed time is 0.103759 seconds.
>> Elapsed time is 0.165608 seconds.
>> Elapsed time is 0.181704 seconds.
>>>>
>>
>>
>> Octave 3.2.3+ from today, self compiled, gives
>> octave:1> bench
>> Elapsed time is 0.208794 seconds.
>> Elapsed time is 0.189178 seconds.
>> Elapsed time is 0.186724 seconds.
>> Elapsed time is 0.188649 seconds.
>> Elapsed time is 0.192915 seconds.
>> Elapsed time is 0.19166 seconds.
>> Elapsed time is 0.186277 seconds.
>> Elapsed time is 0.19102 seconds.
>> Elapsed time is 0.212707 seconds.
>> Elapsed time is 0.211013 seconds.
>> Elapsed time is 0.210491 seconds.
>> Elapsed time is 0.210447 seconds.
>> Elapsed time is 0.431791 seconds.
>> Elapsed time is 0.367412 seconds.
>> octave:2>
>>
>> Congratulations!
>> Michael
>>
>
> It's interesting you didn't get any speed-up in the second part of the
> benchmark, compared to 3.0.1...
> What BLAS and LAPACK are you using? What's your compiler configuration?
> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
> mean "3.3.50+", i.e. the development version?
>
> thanks
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

Oops, sorry, it's 3.3.50+, updated this morning.

I make using
make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
-march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
-funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"

./configure reports
  BLAS libraries:       -llapack -lcblas -lf77blas -latlas

so I assume that Octave is using Atlas (the atlas dev package that
comes with Kubuntu Jaunty amd64).

Michael

From highegg at gmail.com  Tue Sep 29 05:47:01 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 12:47:01 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <c8f260e70909290326u76f85d88n4fafa62eaa327654@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290138x6cbc695ai646e8822812c6a00@mail.gmail.com>
	<69d8d540909290144x4dcf3655xa3ddc673b7be281d@mail.gmail.com>
	<c8f260e70909290326u76f85d88n4fafa62eaa327654@mail.gmail.com>
Message-ID: <69d8d540909290347u4d2f9a3bs98a71f55219d8913@mail.gmail.com>

On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es> wrote:
> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>>> Hi all,
>>>
>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%
>>> n = 500;
>>> R = triu (rand (n));
>>> u = rand (n, 1);
>>>
>>> tic; for i = 1:1000; R \ u; endfor; toc
>>> tic; for i = 1:1000; u' / R; endfor; toc
>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>
>>> R = tril (rand (n));
>>> u = rand (n, 1);
>>>
>>> tic; for i = 1:1000; R \ u; endfor; toc
>>> tic; for i = 1:1000; u' / R; endfor; toc
>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>
>>> u = u + I*rand (n, 1);
>>> tic; for i = 1:1000; R \ u; endfor; toc
>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>
>>>
>>> n = 800;
>>> a = rand (n);
>>> b = rand (n) + i*rand (n);
>>> tic; a * b; toc
>>> tic; b * a; toc
>>> tic; a' * b; toc
>>> tic; b * a'; toc
>>> tic; a \ b; toc
>>> tic; b / a; toc
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>
>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>
>>>
>>> octave:4> bench
>>> Elapsed time is 0.20216 seconds.
>>> Elapsed time is 1.93894 seconds.
>>> Elapsed time is 2.33824 seconds.
>>> Elapsed time is 0.188448 seconds.
>>> Elapsed time is 1.95657 seconds.
>>> Elapsed time is 2.43552 seconds.
>>> Elapsed time is 4.08299 seconds.
>>> Elapsed time is 7.84752 seconds.
>>> Elapsed time is 0.213021 seconds.
>>> Elapsed time is 0.21117 seconds.
>>> Elapsed time is 0.218387 seconds.
>>> Elapsed time is 0.217174 seconds.
>>> Elapsed time is 0.452714 seconds.
>>> Elapsed time is 0.391383 seconds.
>>> octave:5>
>>>
>>>
>>>
>>> Matlab 2008b gives
>>>>> bench
>>> Elapsed time is 0.289161 seconds.
>>> Elapsed time is 0.566446 seconds.
>>> Elapsed time is 0.562623 seconds.
>>> Elapsed time is 0.253456 seconds.
>>> Elapsed time is 0.574304 seconds.
>>> Elapsed time is 0.570281 seconds.
>>> Elapsed time is 0.253070 seconds.
>>> Elapsed time is 0.572601 seconds.
>>> Elapsed time is 0.102086 seconds.
>>> Elapsed time is 0.102677 seconds.
>>> Elapsed time is 0.103080 seconds.
>>> Elapsed time is 0.103759 seconds.
>>> Elapsed time is 0.165608 seconds.
>>> Elapsed time is 0.181704 seconds.
>>>>>
>>>
>>>
>>> Octave 3.2.3+ from today, self compiled, gives
>>> octave:1> bench
>>> Elapsed time is 0.208794 seconds.
>>> Elapsed time is 0.189178 seconds.
>>> Elapsed time is 0.186724 seconds.
>>> Elapsed time is 0.188649 seconds.
>>> Elapsed time is 0.192915 seconds.
>>> Elapsed time is 0.19166 seconds.
>>> Elapsed time is 0.186277 seconds.
>>> Elapsed time is 0.19102 seconds.
>>> Elapsed time is 0.212707 seconds.
>>> Elapsed time is 0.211013 seconds.
>>> Elapsed time is 0.210491 seconds.
>>> Elapsed time is 0.210447 seconds.
>>> Elapsed time is 0.431791 seconds.
>>> Elapsed time is 0.367412 seconds.
>>> octave:2>
>>>
>>> Congratulations!
>>> Michael
>>>
>>
>> It's interesting you didn't get any speed-up in the second part of the
>> benchmark, compared to 3.0.1...
>> What BLAS and LAPACK are you using? What's your compiler configuration?
>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
>> mean "3.3.50+", i.e. the development version?
>>
>> thanks
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>>
>
> Oops, sorry, it's 3.3.50+, updated this morning.
>
> I make using
> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>

In general, if you're with a newer gcc on a 64-bit architecture, I
advise you against -funroll-loops. For me, it usually gets some +1% of
additional speed of some operations, at the cost of increasing the
binaries' size by more than 50%. Seems like a bad tradeoff.

> ./configure reports
> ?BLAS libraries: ? ? ? -llapack -lcblas -lf77blas -latlas
>
> so I assume that Octave is using Atlas (the atlas dev package that
> comes with Kubuntu Jaunty amd64).
>
> Michael
>

Apparently, yes. Hmm. It's really weird you got almost exactly the same figures.
If you apply the attached patch, rebuild and re-run the benchmark,
what do you get?

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.diff
Type: text/x-diff
Size: 1141 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090929/83cec91e/attachment.bin 

From michael.goffioul at gmail.com  Tue Sep 29 06:13:49 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Tue, 29 Sep 2009 12:13:49 +0100
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909290222t1a5ca9c2geab30c700a1e7e75@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909281245i4c61e44dnb39be453ca4947f1@mail.gmail.com>
	<6B37A254-4ED6-4DC4-95A3-84DFA0D7F70A@comcast.net>
	<420fb9e60909282130k737ab7bfq46704bc2e99f6147@mail.gmail.com>
	<128f38bd0909290153y263b4c7aw59bc5c95ea6ae728@mail.gmail.com>
	<420fb9e60909290201l1be24621o411f9e369aa627c5@mail.gmail.com>
	<128f38bd0909290212v7ed1d211t37ae39b40363cd12@mail.gmail.com>
	<420fb9e60909290222t1a5ca9c2geab30c700a1e7e75@mail.gmail.com>
Message-ID: <128f38bd0909290413i1441dc9dn654681e8d4ac08b2@mail.gmail.com>

On Tue, Sep 29, 2009 at 10:22 AM, Shai Ayal <shaiay at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 11:12 AM, Michael Goffioul
> <michael.goffioul at gmail.com> wrote:
>> I see 2 problems with using bitmaps:
>> - they are not 3D
> But images are not 3D either right?

What I meant is that you won't be able to render images in
3D plot. You could still then use surface objects, but the
limitations I mentioned are still valid.

>> - you have a 1-to-1 pixel mapping between the bitmap and the screen,
>> ?which is not what Matlab is doing; for instance a colorbar is just a
>> ?c x 1 image object rendered in a m x n box (m>c, n>>1); you can do
>> ?that seamlessly with textures
> I thought so too, but I found out this morning about glPixelZoom which
> will scale the bitmap:
> http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/pixelzoom.html

That might help indeed.

>> Moreover, texture rendering is much faster than using bitmaps
> I suppose this will depend on the hardware. I would think that at
> least for software only implementations like mesa, bitmap would be
> faster since less processing is needed before drawing (e.g. no
> transformation matrix)

I'm not sure that it'll depend so much on the hardware. The bottleneck
will be the process of uploading the bitmap into the video memory, that
you'll have to do each time you want to draw the image (I don't see
any way of caching that). And to be honest, I have the impression that
graphics card are optimized for texture handling, not for direct buffer
access.

Anyway, if you want to give it try, please do. It's better than nothing.

Michael.


From michael.creel at uab.es  Tue Sep 29 06:34:39 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 29 Sep 2009 13:34:39 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909290347u4d2f9a3bs98a71f55219d8913@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290326u76f85d88n4fafa62eaa327654@mail.gmail.com>
	<69d8d540909290347u4d2f9a3bs98a71f55219d8913@mail.gmail.com>
Message-ID: <c8f260e70909290434s112ae456q6307d5c9463b1282@mail.gmail.com>

On Tue, Sep 29, 2009 at 12:47 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es> wrote:
>> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>>>> Hi all,
>>>>
>>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>>>
>>>> %%%%%%%%%%%%%%%%%%%%%%
>>>> n = 500;
>>>> R = triu (rand (n));
>>>> u = rand (n, 1);
>>>>
>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>
>>>> R = tril (rand (n));
>>>> u = rand (n, 1);
>>>>
>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>
>>>> u = u + I*rand (n, 1);
>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>
>>>>
>>>> n = 800;
>>>> a = rand (n);
>>>> b = rand (n) + i*rand (n);
>>>> tic; a * b; toc
>>>> tic; b * a; toc
>>>> tic; a' * b; toc
>>>> tic; b * a'; toc
>>>> tic; a \ b; toc
>>>> tic; b / a; toc
>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>>
>>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>>
>>>>
>>>> octave:4> bench
>>>> Elapsed time is 0.20216 seconds.
>>>> Elapsed time is 1.93894 seconds.
>>>> Elapsed time is 2.33824 seconds.
>>>> Elapsed time is 0.188448 seconds.
>>>> Elapsed time is 1.95657 seconds.
>>>> Elapsed time is 2.43552 seconds.
>>>> Elapsed time is 4.08299 seconds.
>>>> Elapsed time is 7.84752 seconds.
>>>> Elapsed time is 0.213021 seconds.
>>>> Elapsed time is 0.21117 seconds.
>>>> Elapsed time is 0.218387 seconds.
>>>> Elapsed time is 0.217174 seconds.
>>>> Elapsed time is 0.452714 seconds.
>>>> Elapsed time is 0.391383 seconds.
>>>> octave:5>
>>>>
>>>>
>>>>
>>>> Matlab 2008b gives
>>>>>> bench
>>>> Elapsed time is 0.289161 seconds.
>>>> Elapsed time is 0.566446 seconds.
>>>> Elapsed time is 0.562623 seconds.
>>>> Elapsed time is 0.253456 seconds.
>>>> Elapsed time is 0.574304 seconds.
>>>> Elapsed time is 0.570281 seconds.
>>>> Elapsed time is 0.253070 seconds.
>>>> Elapsed time is 0.572601 seconds.
>>>> Elapsed time is 0.102086 seconds.
>>>> Elapsed time is 0.102677 seconds.
>>>> Elapsed time is 0.103080 seconds.
>>>> Elapsed time is 0.103759 seconds.
>>>> Elapsed time is 0.165608 seconds.
>>>> Elapsed time is 0.181704 seconds.
>>>>>>
>>>>
>>>>
>>>> Octave 3.2.3+ from today, self compiled, gives
>>>> octave:1> bench
>>>> Elapsed time is 0.208794 seconds.
>>>> Elapsed time is 0.189178 seconds.
>>>> Elapsed time is 0.186724 seconds.
>>>> Elapsed time is 0.188649 seconds.
>>>> Elapsed time is 0.192915 seconds.
>>>> Elapsed time is 0.19166 seconds.
>>>> Elapsed time is 0.186277 seconds.
>>>> Elapsed time is 0.19102 seconds.
>>>> Elapsed time is 0.212707 seconds.
>>>> Elapsed time is 0.211013 seconds.
>>>> Elapsed time is 0.210491 seconds.
>>>> Elapsed time is 0.210447 seconds.
>>>> Elapsed time is 0.431791 seconds.
>>>> Elapsed time is 0.367412 seconds.
>>>> octave:2>
>>>>
>>>> Congratulations!
>>>> Michael
>>>>
>>>
>>> It's interesting you didn't get any speed-up in the second part of the
>>> benchmark, compared to 3.0.1...
>>> What BLAS and LAPACK are you using? What's your compiler configuration?
>>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
>>> mean "3.3.50+", i.e. the development version?
>>>
>>> thanks
>>>
>>> --
>>> RNDr. Jaroslav Hajek
>>> computing expert & GNU Octave developer
>>> Aeronautical Research and Test Institute (VZLU)
>>> Prague, Czech Republic
>>> url: www.highegg.matfyz.cz
>>>
>>
>> Oops, sorry, it's 3.3.50+, updated this morning.
>>
>> I make using
>> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
>> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
>> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>>
>
> In general, if you're with a newer gcc on a 64-bit architecture, I
> advise you against -funroll-loops. For me, it usually gets some +1% of
> additional speed of some operations, at the cost of increasing the
> binaries' size by more than 50%. Seems like a bad tradeoff.
>
>> ./configure reports
>> ?BLAS libraries: ? ? ? -llapack -lcblas -lf77blas -latlas
>>
>> so I assume that Octave is using Atlas (the atlas dev package that
>> comes with Kubuntu Jaunty amd64).
>>
>> Michael
>>
>
> Apparently, yes. Hmm. It's really weird you got almost exactly the same figures.
> If you apply the attached patch, rebuild and re-run the benchmark,
> what do you get?
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

With that patch applied, I get
octave:1> bench
Elapsed time is 0.194493 seconds.
Elapsed time is 0.192309 seconds.
Elapsed time is 0.189026 seconds.
Elapsed time is 0.188679 seconds.
Elapsed time is 0.195958 seconds.
Elapsed time is 0.193521 seconds.
Elapsed time is 0.187596 seconds.
Elapsed time is 0.193254 seconds.
Elapsed time is 0.215135 seconds.
Elapsed time is 0.213705 seconds.
Elapsed time is 0.21341 seconds.
Elapsed time is 0.212501 seconds.
Elapsed time is 0.363992 seconds.
Elapsed time is 0.368094 seconds.

so there is an improvement in the second to last number.

Cheers, M.


From shaiay at gmail.com  Tue Sep 29 06:38:32 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 29 Sep 2009 13:38:32 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909270858l7b884b50s18fbd620be046ef2@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254062450.4424.68.camel@sh-t400>
	<420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>
	<1254065427.4424.72.camel@sh-t400>
	<420fb9e60909270858l7b884b50s18fbd620be046ef2@mail.gmail.com>
Message-ID: <420fb9e60909290438v70119fffu9f8fc76e86dda505@mail.gmail.com>

On Sun, Sep 27, 2009 at 5:58 PM, Shai Ayal <shaiay at gmail.com> wrote:
> On Sun, Sep 27, 2009 at 6:30 PM, S?ren Hauberg <soren at hauberg.org> wrote:
>> s?n, 27 09 2009 kl. 18:22 +0300, skrev Shai Ayal:
>>> Strange. When I do a right drag inside a plot I get a zoom-frame. When
>>> I release the right button the plot zooms accordingly, and the scroll
>>> wheel works all of the time.
>>> What system are you running on, and if you have it installed, what is
>>> the output of
>>> glxinfo | grep render
>>
>> This is on Ubuntu 9.04 with an Intel graphics card. The glxinfo output
>> is
>>
>> ? ? ? ?No kernel support for execution fencing, disabling texture
>> ? ? ? ?tiling
>> ? ? ? ?direct rendering: Yes
>> ? ? ? ?OpenGL renderer string: Mesa DRI Mobile Intel? GM45 Express
>> ? ? ? ?Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2
>>
>> Intel graphics cards are known to have some issues on this version of
>> Ubuntu, so it just might be a driver issue. I would, however, find that
>> somewhat weird since the FLTK backend in general works quite well.
>
> I think this IS an intel issue. I have an intel card at work, so I can
> try it there, but it'll have to wait until tuesday.
> If you can't bear the suspense, you can try to run X w/o DRI and see
> what happens.
Well, I tried to try it with an intel card, but X on my intel computer
would not run! I had to revert to vesa drivers, and everything looks
OK.
I think this is an issue with the overlays, like I use to draw the
zoom rubber-band. I might try to draw it normally, not in an overlay
(maybe adding a cool blue transparent rectangle like in the gnuplot
wxt terminal).

Shai


From soren at hauberg.org  Tue Sep 29 06:40:36 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 29 Sep 2009 13:40:36 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909290438v70119fffu9f8fc76e86dda505@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254062450.4424.68.camel@sh-t400>
	<420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>
	<1254065427.4424.72.camel@sh-t400>
	<420fb9e60909270858l7b884b50s18fbd620be046ef2@mail.gmail.com>
	<420fb9e60909290438v70119fffu9f8fc76e86dda505@mail.gmail.com>
Message-ID: <1254224436.4472.61.camel@sh-t400>

tir, 29 09 2009 kl. 13:38 +0200, skrev Shai Ayal:
> I think this is an issue with the overlays, like I use to draw the
> zoom rubber-band. I might try to draw it normally, not in an overlay
> (maybe adding a cool blue transparent rectangle like in the gnuplot
> wxt terminal).

I don't see any rubber-band during drag-zoom, so this sounds like part
of the problem.

S?ren


From shaiay at gmail.com  Tue Sep 29 06:42:29 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 29 Sep 2009 13:42:29 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <1254224436.4472.61.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254062450.4424.68.camel@sh-t400>
	<420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>
	<1254065427.4424.72.camel@sh-t400>
	<420fb9e60909270858l7b884b50s18fbd620be046ef2@mail.gmail.com>
	<420fb9e60909290438v70119fffu9f8fc76e86dda505@mail.gmail.com>
	<1254224436.4472.61.camel@sh-t400>
Message-ID: <420fb9e60909290442v1669ce34o33cd7a8ffb7a51c1@mail.gmail.com>

On Tue, Sep 29, 2009 at 1:40 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> tir, 29 09 2009 kl. 13:38 +0200, skrev Shai Ayal:
>> I think this is an issue with the overlays, like I use to draw the
>> zoom rubber-band. I might try to draw it normally, not in an overlay
>> (maybe adding a cool blue transparent rectangle like in the gnuplot
>> wxt terminal).
>
> I don't see any rubber-band during drag-zoom, so this sounds like part
> of the problem.
>
Do the problems start when you try to zoom with the right button, or
are they always there?
Shai


From highegg at gmail.com  Tue Sep 29 06:44:53 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 13:44:53 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <c8f260e70909290434s112ae456q6307d5c9463b1282@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290326u76f85d88n4fafa62eaa327654@mail.gmail.com>
	<69d8d540909290347u4d2f9a3bs98a71f55219d8913@mail.gmail.com>
	<c8f260e70909290434s112ae456q6307d5c9463b1282@mail.gmail.com>
Message-ID: <69d8d540909290444j64981b41l3480fc0e523e8e42@mail.gmail.com>

On Tue, Sep 29, 2009 at 1:34 PM, Michael Creel <michael.creel at uab.es> wrote:
> On Tue, Sep 29, 2009 at 12:47 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es> wrote:
>>> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>>>>> Hi all,
>>>>>
>>>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>>>>
>>>>> %%%%%%%%%%%%%%%%%%%%%%
>>>>> n = 500;
>>>>> R = triu (rand (n));
>>>>> u = rand (n, 1);
>>>>>
>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>
>>>>> R = tril (rand (n));
>>>>> u = rand (n, 1);
>>>>>
>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>
>>>>> u = u + I*rand (n, 1);
>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>
>>>>>
>>>>> n = 800;
>>>>> a = rand (n);
>>>>> b = rand (n) + i*rand (n);
>>>>> tic; a * b; toc
>>>>> tic; b * a; toc
>>>>> tic; a' * b; toc
>>>>> tic; b * a'; toc
>>>>> tic; a \ b; toc
>>>>> tic; b / a; toc
>>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>>>
>>>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>>>
>>>>>
>>>>> octave:4> bench
>>>>> Elapsed time is 0.20216 seconds.
>>>>> Elapsed time is 1.93894 seconds.
>>>>> Elapsed time is 2.33824 seconds.
>>>>> Elapsed time is 0.188448 seconds.
>>>>> Elapsed time is 1.95657 seconds.
>>>>> Elapsed time is 2.43552 seconds.
>>>>> Elapsed time is 4.08299 seconds.
>>>>> Elapsed time is 7.84752 seconds.
>>>>> Elapsed time is 0.213021 seconds.
>>>>> Elapsed time is 0.21117 seconds.
>>>>> Elapsed time is 0.218387 seconds.
>>>>> Elapsed time is 0.217174 seconds.
>>>>> Elapsed time is 0.452714 seconds.
>>>>> Elapsed time is 0.391383 seconds.
>>>>> octave:5>
>>>>>
>>>>>
>>>>>
>>>>> Matlab 2008b gives
>>>>>>> bench
>>>>> Elapsed time is 0.289161 seconds.
>>>>> Elapsed time is 0.566446 seconds.
>>>>> Elapsed time is 0.562623 seconds.
>>>>> Elapsed time is 0.253456 seconds.
>>>>> Elapsed time is 0.574304 seconds.
>>>>> Elapsed time is 0.570281 seconds.
>>>>> Elapsed time is 0.253070 seconds.
>>>>> Elapsed time is 0.572601 seconds.
>>>>> Elapsed time is 0.102086 seconds.
>>>>> Elapsed time is 0.102677 seconds.
>>>>> Elapsed time is 0.103080 seconds.
>>>>> Elapsed time is 0.103759 seconds.
>>>>> Elapsed time is 0.165608 seconds.
>>>>> Elapsed time is 0.181704 seconds.
>>>>>>>
>>>>>
>>>>>
>>>>> Octave 3.2.3+ from today, self compiled, gives
>>>>> octave:1> bench
>>>>> Elapsed time is 0.208794 seconds.
>>>>> Elapsed time is 0.189178 seconds.
>>>>> Elapsed time is 0.186724 seconds.
>>>>> Elapsed time is 0.188649 seconds.
>>>>> Elapsed time is 0.192915 seconds.
>>>>> Elapsed time is 0.19166 seconds.
>>>>> Elapsed time is 0.186277 seconds.
>>>>> Elapsed time is 0.19102 seconds.
>>>>> Elapsed time is 0.212707 seconds.
>>>>> Elapsed time is 0.211013 seconds.
>>>>> Elapsed time is 0.210491 seconds.
>>>>> Elapsed time is 0.210447 seconds.
>>>>> Elapsed time is 0.431791 seconds.
>>>>> Elapsed time is 0.367412 seconds.
>>>>> octave:2>
>>>>>
>>>>> Congratulations!
>>>>> Michael
>>>>>
>>>>
>>>> It's interesting you didn't get any speed-up in the second part of the
>>>> benchmark, compared to 3.0.1...
>>>> What BLAS and LAPACK are you using? What's your compiler configuration?
>>>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
>>>> mean "3.3.50+", i.e. the development version?
>>>>
>>>> thanks
>>>>
>>>> --
>>>> RNDr. Jaroslav Hajek
>>>> computing expert & GNU Octave developer
>>>> Aeronautical Research and Test Institute (VZLU)
>>>> Prague, Czech Republic
>>>> url: www.highegg.matfyz.cz
>>>>
>>>
>>> Oops, sorry, it's 3.3.50+, updated this morning.
>>>
>>> I make using
>>> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
>>> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
>>> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>>>
>>
>> In general, if you're with a newer gcc on a 64-bit architecture, I
>> advise you against -funroll-loops. For me, it usually gets some +1% of
>> additional speed of some operations, at the cost of increasing the
>> binaries' size by more than 50%. Seems like a bad tradeoff.
>>
>>> ./configure reports
>>> ?BLAS libraries: ? ? ? -llapack -lcblas -lf77blas -latlas
>>>
>>> so I assume that Octave is using Atlas (the atlas dev package that
>>> comes with Kubuntu Jaunty amd64).
>>>
>>> Michael
>>>
>>
>> Apparently, yes. Hmm. It's really weird you got almost exactly the same figures.
>> If you apply the attached patch, rebuild and re-run the benchmark,
>> what do you get?
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>>
>
> With that patch applied, I get
> octave:1> bench
> Elapsed time is 0.194493 seconds.
> Elapsed time is 0.192309 seconds.
> Elapsed time is 0.189026 seconds.
> Elapsed time is 0.188679 seconds.
> Elapsed time is 0.195958 seconds.
> Elapsed time is 0.193521 seconds.
> Elapsed time is 0.187596 seconds.
> Elapsed time is 0.193254 seconds.
> Elapsed time is 0.215135 seconds.
> Elapsed time is 0.213705 seconds.
> Elapsed time is 0.21341 seconds.
> Elapsed time is 0.212501 seconds.
> Elapsed time is 0.363992 seconds.
> Elapsed time is 0.368094 seconds.
>
> so there is an improvement in the second to last number.
>
> Cheers, M.
>

OK, it's funny. I now understand where the problem is. Just change the line

b = rand (n) + i*rand (n);

to

b = rand (n) + I*rand (n);

(note the big I). At this point, i is still defined from the previous
loops as a real numeric value (!)
And run the benchmarks again. I think this affects Matlab, too.
In any case, it is apparent that your Matlab is linked to something
faster than ATLAS; probably Intel's MKL.

regards

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


From michael.creel at uab.es  Tue Sep 29 06:54:19 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 29 Sep 2009 13:54:19 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909290444j64981b41l3480fc0e523e8e42@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290434s112ae456q6307d5c9463b1282@mail.gmail.com>
	<69d8d540909290444j64981b41l3480fc0e523e8e42@mail.gmail.com>
Message-ID: <c8f260e70909290454q200f2acdv62fcccb956624d3d@mail.gmail.com>

On Tue, Sep 29, 2009 at 1:44 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 1:34 PM, Michael Creel <michael.creel at uab.es> wrote:
>> On Tue, Sep 29, 2009 at 12:47 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>> On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es> wrote:
>>>> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>>>>>
>>>>>> %%%%%%%%%%%%%%%%%%%%%%
>>>>>> n = 500;
>>>>>> R = triu (rand (n));
>>>>>> u = rand (n, 1);
>>>>>>
>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>
>>>>>> R = tril (rand (n));
>>>>>> u = rand (n, 1);
>>>>>>
>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>
>>>>>> u = u + I*rand (n, 1);
>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>
>>>>>>
>>>>>> n = 800;
>>>>>> a = rand (n);
>>>>>> b = rand (n) + i*rand (n);
>>>>>> tic; a * b; toc
>>>>>> tic; b * a; toc
>>>>>> tic; a' * b; toc
>>>>>> tic; b * a'; toc
>>>>>> tic; a \ b; toc
>>>>>> tic; b / a; toc
>>>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>>>>
>>>>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>>>>
>>>>>>
>>>>>> octave:4> bench
>>>>>> Elapsed time is 0.20216 seconds.
>>>>>> Elapsed time is 1.93894 seconds.
>>>>>> Elapsed time is 2.33824 seconds.
>>>>>> Elapsed time is 0.188448 seconds.
>>>>>> Elapsed time is 1.95657 seconds.
>>>>>> Elapsed time is 2.43552 seconds.
>>>>>> Elapsed time is 4.08299 seconds.
>>>>>> Elapsed time is 7.84752 seconds.
>>>>>> Elapsed time is 0.213021 seconds.
>>>>>> Elapsed time is 0.21117 seconds.
>>>>>> Elapsed time is 0.218387 seconds.
>>>>>> Elapsed time is 0.217174 seconds.
>>>>>> Elapsed time is 0.452714 seconds.
>>>>>> Elapsed time is 0.391383 seconds.
>>>>>> octave:5>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Matlab 2008b gives
>>>>>>>> bench
>>>>>> Elapsed time is 0.289161 seconds.
>>>>>> Elapsed time is 0.566446 seconds.
>>>>>> Elapsed time is 0.562623 seconds.
>>>>>> Elapsed time is 0.253456 seconds.
>>>>>> Elapsed time is 0.574304 seconds.
>>>>>> Elapsed time is 0.570281 seconds.
>>>>>> Elapsed time is 0.253070 seconds.
>>>>>> Elapsed time is 0.572601 seconds.
>>>>>> Elapsed time is 0.102086 seconds.
>>>>>> Elapsed time is 0.102677 seconds.
>>>>>> Elapsed time is 0.103080 seconds.
>>>>>> Elapsed time is 0.103759 seconds.
>>>>>> Elapsed time is 0.165608 seconds.
>>>>>> Elapsed time is 0.181704 seconds.
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> Octave 3.2.3+ from today, self compiled, gives
>>>>>> octave:1> bench
>>>>>> Elapsed time is 0.208794 seconds.
>>>>>> Elapsed time is 0.189178 seconds.
>>>>>> Elapsed time is 0.186724 seconds.
>>>>>> Elapsed time is 0.188649 seconds.
>>>>>> Elapsed time is 0.192915 seconds.
>>>>>> Elapsed time is 0.19166 seconds.
>>>>>> Elapsed time is 0.186277 seconds.
>>>>>> Elapsed time is 0.19102 seconds.
>>>>>> Elapsed time is 0.212707 seconds.
>>>>>> Elapsed time is 0.211013 seconds.
>>>>>> Elapsed time is 0.210491 seconds.
>>>>>> Elapsed time is 0.210447 seconds.
>>>>>> Elapsed time is 0.431791 seconds.
>>>>>> Elapsed time is 0.367412 seconds.
>>>>>> octave:2>
>>>>>>
>>>>>> Congratulations!
>>>>>> Michael
>>>>>>
>>>>>
>>>>> It's interesting you didn't get any speed-up in the second part of the
>>>>> benchmark, compared to 3.0.1...
>>>>> What BLAS and LAPACK are you using? What's your compiler configuration?
>>>>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
>>>>> mean "3.3.50+", i.e. the development version?
>>>>>
>>>>> thanks
>>>>>
>>>>> --
>>>>> RNDr. Jaroslav Hajek
>>>>> computing expert & GNU Octave developer
>>>>> Aeronautical Research and Test Institute (VZLU)
>>>>> Prague, Czech Republic
>>>>> url: www.highegg.matfyz.cz
>>>>>
>>>>
>>>> Oops, sorry, it's 3.3.50+, updated this morning.
>>>>
>>>> I make using
>>>> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
>>>> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
>>>> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>>>>
>>>
>>> In general, if you're with a newer gcc on a 64-bit architecture, I
>>> advise you against -funroll-loops. For me, it usually gets some +1% of
>>> additional speed of some operations, at the cost of increasing the
>>> binaries' size by more than 50%. Seems like a bad tradeoff.
>>>
>>>> ./configure reports
>>>> ?BLAS libraries: ? ? ? -llapack -lcblas -lf77blas -latlas
>>>>
>>>> so I assume that Octave is using Atlas (the atlas dev package that
>>>> comes with Kubuntu Jaunty amd64).
>>>>
>>>> Michael
>>>>
>>>
>>> Apparently, yes. Hmm. It's really weird you got almost exactly the same figures.
>>> If you apply the attached patch, rebuild and re-run the benchmark,
>>> what do you get?
>>>
>>> --
>>> RNDr. Jaroslav Hajek
>>> computing expert & GNU Octave developer
>>> Aeronautical Research and Test Institute (VZLU)
>>> Prague, Czech Republic
>>> url: www.highegg.matfyz.cz
>>>
>>
>> With that patch applied, I get
>> octave:1> bench
>> Elapsed time is 0.194493 seconds.
>> Elapsed time is 0.192309 seconds.
>> Elapsed time is 0.189026 seconds.
>> Elapsed time is 0.188679 seconds.
>> Elapsed time is 0.195958 seconds.
>> Elapsed time is 0.193521 seconds.
>> Elapsed time is 0.187596 seconds.
>> Elapsed time is 0.193254 seconds.
>> Elapsed time is 0.215135 seconds.
>> Elapsed time is 0.213705 seconds.
>> Elapsed time is 0.21341 seconds.
>> Elapsed time is 0.212501 seconds.
>> Elapsed time is 0.363992 seconds.
>> Elapsed time is 0.368094 seconds.
>>
>> so there is an improvement in the second to last number.
>>
>> Cheers, M.
>>
>
> OK, it's funny. I now understand where the problem is. Just change the line
>
> b = rand (n) + i*rand (n);
>
> to
>
> b = rand (n) + I*rand (n);
>
> (note the big I). At this point, i is still defined from the previous
> loops as a real numeric value (!)
> And run the benchmarks again. I think this affects Matlab, too.
> In any case, it is apparent that your Matlab is linked to something
> faster than ATLAS; probably Intel's MKL.
>
> regards
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

That's one of those bugs that causes rockets to go off course, I
guess! OK, it makes sense now. Matlab has been available here for a
while, but I haven't used it much. I don't know the details of what
libraries it uses - it's v2009b. The JIT compilation is pretty
impressive, but the mechanisms for using MPI are not as nice as Octave
+ MPITB.
Thanks, M.


From soren at hauberg.org  Tue Sep 29 07:00:09 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 29 Sep 2009 14:00:09 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <420fb9e60909290442v1669ce34o33cd7a8ffb7a51c1@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254062450.4424.68.camel@sh-t400>
	<420fb9e60909270822t21602b97p43a1248aa8b17cc1@mail.gmail.com>
	<1254065427.4424.72.camel@sh-t400>
	<420fb9e60909270858l7b884b50s18fbd620be046ef2@mail.gmail.com>
	<420fb9e60909290438v70119fffu9f8fc76e86dda505@mail.gmail.com>
	<1254224436.4472.61.camel@sh-t400>
	<420fb9e60909290442v1669ce34o33cd7a8ffb7a51c1@mail.gmail.com>
Message-ID: <1254225609.4472.69.camel@sh-t400>

tir, 29 09 2009 kl. 13:42 +0200, skrev Shai Ayal:
> On Tue, Sep 29, 2009 at 1:40 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> > tir, 29 09 2009 kl. 13:38 +0200, skrev Shai Ayal:
> >> I think this is an issue with the overlays, like I use to draw the
> >> zoom rubber-band. I might try to draw it normally, not in an overlay
> >> (maybe adding a cool blue transparent rectangle like in the gnuplot
> >> wxt terminal).
> >
> > I don't see any rubber-band during drag-zoom, so this sounds like part
> > of the problem.
> >
> Do the problems start when you try to zoom with the right button, or
> are they always there?

Everything works until I start dragging with the right button down.

S?ren


From bpabbott at mac.com  Tue Sep 29 07:05:56 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 29 Sep 2009 08:05:56 -0400
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909290444j64981b41l3480fc0e523e8e42@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290326u76f85d88n4fafa62eaa327654@mail.gmail.com>
	<69d8d540909290347u4d2f9a3bs98a71f55219d8913@mail.gmail.com>
	<c8f260e70909290434s112ae456q6307d5c9463b1282@mail.gmail.com>
	<69d8d540909290444j64981b41l3480fc0e523e8e42@mail.gmail.com>
Message-ID: <AC51D7D9-6EAF-409D-97BE-2C1901BA67E1@mac.com>


On Sep 29, 2009, at 7:44 AM, Jaroslav Hajek wrote:

> On Tue, Sep 29, 2009 at 1:34 PM, Michael Creel  
> <michael.creel at uab.es> wrote:
>> On Tue, Sep 29, 2009 at 12:47 PM, Jaroslav Hajek  
>> <highegg at gmail.com> wrote:
>>> On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es 
>>> > wrote:
>>>> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek  
>>>> <highegg at gmail.com> wrote:
>>>>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es 
>>>>> > wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the  
>>>>>> benchmark
>>>>>>
>>>>>> %%%%%%%%%%%%%%%%%%%%%%
>>>>>> n = 500;
>>>>>> R = triu (rand (n));
>>>>>> u = rand (n, 1);
>>>>>>
>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>
>>>>>> R = tril (rand (n));
>>>>>> u = rand (n, 1);
>>>>>>
>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>
>>>>>> u = u + I*rand (n, 1);
>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>
>>>>>>
>>>>>> n = 800;
>>>>>> a = rand (n);
>>>>>> b = rand (n) + i*rand (n);
>>>>>> tic; a * b; toc
>>>>>> tic; b * a; toc
>>>>>> tic; a' * b; toc
>>>>>> tic; b * a'; toc
>>>>>> tic; a \ b; toc
>>>>>> tic; b / a; toc
>>>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>>>>
>>>>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>>>>
>>>>>>
>>>>>> octave:4> bench
>>>>>> Elapsed time is 0.20216 seconds.
>>>>>> Elapsed time is 1.93894 seconds.
>>>>>> Elapsed time is 2.33824 seconds.
>>>>>> Elapsed time is 0.188448 seconds.
>>>>>> Elapsed time is 1.95657 seconds.
>>>>>> Elapsed time is 2.43552 seconds.
>>>>>> Elapsed time is 4.08299 seconds.
>>>>>> Elapsed time is 7.84752 seconds.
>>>>>> Elapsed time is 0.213021 seconds.
>>>>>> Elapsed time is 0.21117 seconds.
>>>>>> Elapsed time is 0.218387 seconds.
>>>>>> Elapsed time is 0.217174 seconds.
>>>>>> Elapsed time is 0.452714 seconds.
>>>>>> Elapsed time is 0.391383 seconds.
>>>>>> octave:5>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Matlab 2008b gives
>>>>>>>> bench
>>>>>> Elapsed time is 0.289161 seconds.
>>>>>> Elapsed time is 0.566446 seconds.
>>>>>> Elapsed time is 0.562623 seconds.
>>>>>> Elapsed time is 0.253456 seconds.
>>>>>> Elapsed time is 0.574304 seconds.
>>>>>> Elapsed time is 0.570281 seconds.
>>>>>> Elapsed time is 0.253070 seconds.
>>>>>> Elapsed time is 0.572601 seconds.
>>>>>> Elapsed time is 0.102086 seconds.
>>>>>> Elapsed time is 0.102677 seconds.
>>>>>> Elapsed time is 0.103080 seconds.
>>>>>> Elapsed time is 0.103759 seconds.
>>>>>> Elapsed time is 0.165608 seconds.
>>>>>> Elapsed time is 0.181704 seconds.
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> Octave 3.2.3+ from today, self compiled, gives
>>>>>> octave:1> bench
>>>>>> Elapsed time is 0.208794 seconds.
>>>>>> Elapsed time is 0.189178 seconds.
>>>>>> Elapsed time is 0.186724 seconds.
>>>>>> Elapsed time is 0.188649 seconds.
>>>>>> Elapsed time is 0.192915 seconds.
>>>>>> Elapsed time is 0.19166 seconds.
>>>>>> Elapsed time is 0.186277 seconds.
>>>>>> Elapsed time is 0.19102 seconds.
>>>>>> Elapsed time is 0.212707 seconds.
>>>>>> Elapsed time is 0.211013 seconds.
>>>>>> Elapsed time is 0.210491 seconds.
>>>>>> Elapsed time is 0.210447 seconds.
>>>>>> Elapsed time is 0.431791 seconds.
>>>>>> Elapsed time is 0.367412 seconds.
>>>>>> octave:2>
>>>>>>
>>>>>> Congratulations!
>>>>>> Michael
>>>>>>
>>>>>
>>>>> It's interesting you didn't get any speed-up in the second part  
>>>>> of the
>>>>> benchmark, compared to 3.0.1...
>>>>> What BLAS and LAPACK are you using? What's your compiler  
>>>>> configuration?
>>>>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear,  
>>>>> did you
>>>>> mean "3.3.50+", i.e. the development version?
>>>>>
>>>>> thanks
>>>>>
>>>>> --
>>>>> RNDr. Jaroslav Hajek
>>>>> computing expert & GNU Octave developer
>>>>> Aeronautical Research and Test Institute (VZLU)
>>>>> Prague, Czech Republic
>>>>> url: www.highegg.matfyz.cz
>>>>>
>>>>
>>>> Oops, sorry, it's 3.3.50+, updated this morning.
>>>>
>>>> I make using
>>>> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
>>>> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
>>>> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>>>>
>>>
>>> In general, if you're with a newer gcc on a 64-bit architecture, I
>>> advise you against -funroll-loops. For me, it usually gets some  
>>> +1% of
>>> additional speed of some operations, at the cost of increasing the
>>> binaries' size by more than 50%. Seems like a bad tradeoff.
>>>
>>>> ./configure reports
>>>>  BLAS libraries:       -llapack -lcblas -lf77blas -latlas
>>>>
>>>> so I assume that Octave is using Atlas (the atlas dev package that
>>>> comes with Kubuntu Jaunty amd64).
>>>>
>>>> Michael
>>>>
>>>
>>> Apparently, yes. Hmm. It's really weird you got almost exactly the  
>>> same figures.
>>> If you apply the attached patch, rebuild and re-run the benchmark,
>>> what do you get?
>>>
>>> --
>>> RNDr. Jaroslav Hajek
>>> computing expert & GNU Octave developer
>>> Aeronautical Research and Test Institute (VZLU)
>>> Prague, Czech Republic
>>> url: www.highegg.matfyz.cz
>>>
>>
>> With that patch applied, I get
>> octave:1> bench
>> Elapsed time is 0.194493 seconds.
>> Elapsed time is 0.192309 seconds.
>> Elapsed time is 0.189026 seconds.
>> Elapsed time is 0.188679 seconds.
>> Elapsed time is 0.195958 seconds.
>> Elapsed time is 0.193521 seconds.
>> Elapsed time is 0.187596 seconds.
>> Elapsed time is 0.193254 seconds.
>> Elapsed time is 0.215135 seconds.
>> Elapsed time is 0.213705 seconds.
>> Elapsed time is 0.21341 seconds.
>> Elapsed time is 0.212501 seconds.
>> Elapsed time is 0.363992 seconds.
>> Elapsed time is 0.368094 seconds.
>>
>> so there is an improvement in the second to last number.
>>
>> Cheers, M.
>>
>
> OK, it's funny. I now understand where the problem is. Just change  
> the line
>
> b = rand (n) + i*rand (n);
>
> to
>
> b = rand (n) + I*rand (n);
>
> (note the big I). At this point, i is still defined from the previous
> loops as a real numeric value (!)
> And run the benchmarks again. I think this affects Matlab, too.
> In any case, it is apparent that your Matlab is linked to something
> faster than ATLAS; probably Intel's MKL.
>
> regards

I've read that Matlab does use MKL. Some examples are below.

	http://mail.scipy.org/pipermail/nipy-devel/2009-August/001847.html

	http://www.nabble.com/Re%3A-question-about-the-atlas-and-p22830193.html

Ben




From highegg at gmail.com  Tue Sep 29 07:08:34 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 14:08:34 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <c8f260e70909290454q200f2acdv62fcccb956624d3d@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290434s112ae456q6307d5c9463b1282@mail.gmail.com>
	<69d8d540909290444j64981b41l3480fc0e523e8e42@mail.gmail.com>
	<c8f260e70909290454q200f2acdv62fcccb956624d3d@mail.gmail.com>
Message-ID: <69d8d540909290508x450cf118h209cea96790f3471@mail.gmail.com>

On Tue, Sep 29, 2009 at 1:54 PM, Michael Creel <michael.creel at uab.es> wrote:
> On Tue, Sep 29, 2009 at 1:44 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> On Tue, Sep 29, 2009 at 1:34 PM, Michael Creel <michael.creel at uab.es> wrote:
>>> On Tue, Sep 29, 2009 at 12:47 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>> On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es> wrote:
>>>>> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>>>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>>>>>>
>>>>>>> %%%%%%%%%%%%%%%%%%%%%%
>>>>>>> n = 500;
>>>>>>> R = triu (rand (n));
>>>>>>> u = rand (n, 1);
>>>>>>>
>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>
>>>>>>> R = tril (rand (n));
>>>>>>> u = rand (n, 1);
>>>>>>>
>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>
>>>>>>> u = u + I*rand (n, 1);
>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>
>>>>>>>
>>>>>>> n = 800;
>>>>>>> a = rand (n);
>>>>>>> b = rand (n) + i*rand (n);
>>>>>>> tic; a * b; toc
>>>>>>> tic; b * a; toc
>>>>>>> tic; a' * b; toc
>>>>>>> tic; b * a'; toc
>>>>>>> tic; a \ b; toc
>>>>>>> tic; b / a; toc
>>>>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>>>>>
>>>>>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>>>>>
>>>>>>>
>>>>>>> octave:4> bench
>>>>>>> Elapsed time is 0.20216 seconds.
>>>>>>> Elapsed time is 1.93894 seconds.
>>>>>>> Elapsed time is 2.33824 seconds.
>>>>>>> Elapsed time is 0.188448 seconds.
>>>>>>> Elapsed time is 1.95657 seconds.
>>>>>>> Elapsed time is 2.43552 seconds.
>>>>>>> Elapsed time is 4.08299 seconds.
>>>>>>> Elapsed time is 7.84752 seconds.
>>>>>>> Elapsed time is 0.213021 seconds.
>>>>>>> Elapsed time is 0.21117 seconds.
>>>>>>> Elapsed time is 0.218387 seconds.
>>>>>>> Elapsed time is 0.217174 seconds.
>>>>>>> Elapsed time is 0.452714 seconds.
>>>>>>> Elapsed time is 0.391383 seconds.
>>>>>>> octave:5>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Matlab 2008b gives
>>>>>>>>> bench
>>>>>>> Elapsed time is 0.289161 seconds.
>>>>>>> Elapsed time is 0.566446 seconds.
>>>>>>> Elapsed time is 0.562623 seconds.
>>>>>>> Elapsed time is 0.253456 seconds.
>>>>>>> Elapsed time is 0.574304 seconds.
>>>>>>> Elapsed time is 0.570281 seconds.
>>>>>>> Elapsed time is 0.253070 seconds.
>>>>>>> Elapsed time is 0.572601 seconds.
>>>>>>> Elapsed time is 0.102086 seconds.
>>>>>>> Elapsed time is 0.102677 seconds.
>>>>>>> Elapsed time is 0.103080 seconds.
>>>>>>> Elapsed time is 0.103759 seconds.
>>>>>>> Elapsed time is 0.165608 seconds.
>>>>>>> Elapsed time is 0.181704 seconds.
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Octave 3.2.3+ from today, self compiled, gives
>>>>>>> octave:1> bench
>>>>>>> Elapsed time is 0.208794 seconds.
>>>>>>> Elapsed time is 0.189178 seconds.
>>>>>>> Elapsed time is 0.186724 seconds.
>>>>>>> Elapsed time is 0.188649 seconds.
>>>>>>> Elapsed time is 0.192915 seconds.
>>>>>>> Elapsed time is 0.19166 seconds.
>>>>>>> Elapsed time is 0.186277 seconds.
>>>>>>> Elapsed time is 0.19102 seconds.
>>>>>>> Elapsed time is 0.212707 seconds.
>>>>>>> Elapsed time is 0.211013 seconds.
>>>>>>> Elapsed time is 0.210491 seconds.
>>>>>>> Elapsed time is 0.210447 seconds.
>>>>>>> Elapsed time is 0.431791 seconds.
>>>>>>> Elapsed time is 0.367412 seconds.
>>>>>>> octave:2>
>>>>>>>
>>>>>>> Congratulations!
>>>>>>> Michael
>>>>>>>
>>>>>>
>>>>>> It's interesting you didn't get any speed-up in the second part of the
>>>>>> benchmark, compared to 3.0.1...
>>>>>> What BLAS and LAPACK are you using? What's your compiler configuration?
>>>>>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
>>>>>> mean "3.3.50+", i.e. the development version?
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> --
>>>>>> RNDr. Jaroslav Hajek
>>>>>> computing expert & GNU Octave developer
>>>>>> Aeronautical Research and Test Institute (VZLU)
>>>>>> Prague, Czech Republic
>>>>>> url: www.highegg.matfyz.cz
>>>>>>
>>>>>
>>>>> Oops, sorry, it's 3.3.50+, updated this morning.
>>>>>
>>>>> I make using
>>>>> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
>>>>> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
>>>>> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>>>>>
>>>>
>>>> In general, if you're with a newer gcc on a 64-bit architecture, I
>>>> advise you against -funroll-loops. For me, it usually gets some +1% of
>>>> additional speed of some operations, at the cost of increasing the
>>>> binaries' size by more than 50%. Seems like a bad tradeoff.
>>>>
>>>>> ./configure reports
>>>>> ?BLAS libraries: ? ? ? -llapack -lcblas -lf77blas -latlas
>>>>>
>>>>> so I assume that Octave is using Atlas (the atlas dev package that
>>>>> comes with Kubuntu Jaunty amd64).
>>>>>
>>>>> Michael
>>>>>
>>>>
>>>> Apparently, yes. Hmm. It's really weird you got almost exactly the same figures.
>>>> If you apply the attached patch, rebuild and re-run the benchmark,
>>>> what do you get?
>>>>
>>>> --
>>>> RNDr. Jaroslav Hajek
>>>> computing expert & GNU Octave developer
>>>> Aeronautical Research and Test Institute (VZLU)
>>>> Prague, Czech Republic
>>>> url: www.highegg.matfyz.cz
>>>>
>>>
>>> With that patch applied, I get
>>> octave:1> bench
>>> Elapsed time is 0.194493 seconds.
>>> Elapsed time is 0.192309 seconds.
>>> Elapsed time is 0.189026 seconds.
>>> Elapsed time is 0.188679 seconds.
>>> Elapsed time is 0.195958 seconds.
>>> Elapsed time is 0.193521 seconds.
>>> Elapsed time is 0.187596 seconds.
>>> Elapsed time is 0.193254 seconds.
>>> Elapsed time is 0.215135 seconds.
>>> Elapsed time is 0.213705 seconds.
>>> Elapsed time is 0.21341 seconds.
>>> Elapsed time is 0.212501 seconds.
>>> Elapsed time is 0.363992 seconds.
>>> Elapsed time is 0.368094 seconds.
>>>
>>> so there is an improvement in the second to last number.
>>>
>>> Cheers, M.
>>>
>>
>> OK, it's funny. I now understand where the problem is. Just change the line
>>
>> b = rand (n) + i*rand (n);
>>
>> to
>>
>> b = rand (n) + I*rand (n);
>>
>> (note the big I). At this point, i is still defined from the previous
>> loops as a real numeric value (!)
>> And run the benchmarks again. I think this affects Matlab, too.
>> In any case, it is apparent that your Matlab is linked to something
>> faster than ATLAS; probably Intel's MKL.
>>
>> regards
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>>
>
> That's one of those bugs that causes rockets to go off course, I
> guess!

Yes, definitely. Maybe we could do something about it...

> OK, it makes sense now. Matlab has been available here for a
> while, but I haven't used it much. I don't know the details of what
> libraries it uses - it's v2009b.

You can usually tell by inspecting the binaries using ldd. But it
doesn't matter much.
I will be glad if you post the results of the corrected benchmark.

> The JIT compilation is pretty
> impressive, but the mechanisms for using MPI are not as nice as Octave
> + MPITB.

I definitely need to look at MPITB some day :)

regards

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


From highegg at gmail.com  Tue Sep 29 07:15:38 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 29 Sep 2009 14:15:38 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909290508x450cf118h209cea96790f3471@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<c8f260e70909290434s112ae456q6307d5c9463b1282@mail.gmail.com>
	<69d8d540909290444j64981b41l3480fc0e523e8e42@mail.gmail.com>
	<c8f260e70909290454q200f2acdv62fcccb956624d3d@mail.gmail.com>
	<69d8d540909290508x450cf118h209cea96790f3471@mail.gmail.com>
Message-ID: <69d8d540909290515u4ed9d69al7b3d25656e777f46@mail.gmail.com>

On Tue, Sep 29, 2009 at 2:08 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 1:54 PM, Michael Creel <michael.creel at uab.es> wrote:
>> On Tue, Sep 29, 2009 at 1:44 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>> On Tue, Sep 29, 2009 at 1:34 PM, Michael Creel <michael.creel at uab.es> wrote:
>>>> On Tue, Sep 29, 2009 at 12:47 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>>> On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es> wrote:
>>>>>> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>>>>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>>>>>>>
>>>>>>>> %%%%%%%%%%%%%%%%%%%%%%
>>>>>>>> n = 500;
>>>>>>>> R = triu (rand (n));
>>>>>>>> u = rand (n, 1);
>>>>>>>>
>>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>>
>>>>>>>> R = tril (rand (n));
>>>>>>>> u = rand (n, 1);
>>>>>>>>
>>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>>
>>>>>>>> u = u + I*rand (n, 1);
>>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>>
>>>>>>>>
>>>>>>>> n = 800;
>>>>>>>> a = rand (n);
>>>>>>>> b = rand (n) + i*rand (n);
>>>>>>>> tic; a * b; toc
>>>>>>>> tic; b * a; toc
>>>>>>>> tic; a' * b; toc
>>>>>>>> tic; b * a'; toc
>>>>>>>> tic; a \ b; toc
>>>>>>>> tic; b / a; toc
>>>>>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>>>>>>
>>>>>>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>>>>>>
>>>>>>>>
>>>>>>>> octave:4> bench
>>>>>>>> Elapsed time is 0.20216 seconds.
>>>>>>>> Elapsed time is 1.93894 seconds.
>>>>>>>> Elapsed time is 2.33824 seconds.
>>>>>>>> Elapsed time is 0.188448 seconds.
>>>>>>>> Elapsed time is 1.95657 seconds.
>>>>>>>> Elapsed time is 2.43552 seconds.
>>>>>>>> Elapsed time is 4.08299 seconds.
>>>>>>>> Elapsed time is 7.84752 seconds.
>>>>>>>> Elapsed time is 0.213021 seconds.
>>>>>>>> Elapsed time is 0.21117 seconds.
>>>>>>>> Elapsed time is 0.218387 seconds.
>>>>>>>> Elapsed time is 0.217174 seconds.
>>>>>>>> Elapsed time is 0.452714 seconds.
>>>>>>>> Elapsed time is 0.391383 seconds.
>>>>>>>> octave:5>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Matlab 2008b gives
>>>>>>>>>> bench
>>>>>>>> Elapsed time is 0.289161 seconds.
>>>>>>>> Elapsed time is 0.566446 seconds.
>>>>>>>> Elapsed time is 0.562623 seconds.
>>>>>>>> Elapsed time is 0.253456 seconds.
>>>>>>>> Elapsed time is 0.574304 seconds.
>>>>>>>> Elapsed time is 0.570281 seconds.
>>>>>>>> Elapsed time is 0.253070 seconds.
>>>>>>>> Elapsed time is 0.572601 seconds.
>>>>>>>> Elapsed time is 0.102086 seconds.
>>>>>>>> Elapsed time is 0.102677 seconds.
>>>>>>>> Elapsed time is 0.103080 seconds.
>>>>>>>> Elapsed time is 0.103759 seconds.
>>>>>>>> Elapsed time is 0.165608 seconds.
>>>>>>>> Elapsed time is 0.181704 seconds.
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Octave 3.2.3+ from today, self compiled, gives
>>>>>>>> octave:1> bench
>>>>>>>> Elapsed time is 0.208794 seconds.
>>>>>>>> Elapsed time is 0.189178 seconds.
>>>>>>>> Elapsed time is 0.186724 seconds.
>>>>>>>> Elapsed time is 0.188649 seconds.
>>>>>>>> Elapsed time is 0.192915 seconds.
>>>>>>>> Elapsed time is 0.19166 seconds.
>>>>>>>> Elapsed time is 0.186277 seconds.
>>>>>>>> Elapsed time is 0.19102 seconds.
>>>>>>>> Elapsed time is 0.212707 seconds.
>>>>>>>> Elapsed time is 0.211013 seconds.
>>>>>>>> Elapsed time is 0.210491 seconds.
>>>>>>>> Elapsed time is 0.210447 seconds.
>>>>>>>> Elapsed time is 0.431791 seconds.
>>>>>>>> Elapsed time is 0.367412 seconds.
>>>>>>>> octave:2>
>>>>>>>>
>>>>>>>> Congratulations!
>>>>>>>> Michael
>>>>>>>>
>>>>>>>
>>>>>>> It's interesting you didn't get any speed-up in the second part of the
>>>>>>> benchmark, compared to 3.0.1...
>>>>>>> What BLAS and LAPACK are you using? What's your compiler configuration?
>>>>>>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
>>>>>>> mean "3.3.50+", i.e. the development version?
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> --
>>>>>>> RNDr. Jaroslav Hajek
>>>>>>> computing expert & GNU Octave developer
>>>>>>> Aeronautical Research and Test Institute (VZLU)
>>>>>>> Prague, Czech Republic
>>>>>>> url: www.highegg.matfyz.cz
>>>>>>>
>>>>>>
>>>>>> Oops, sorry, it's 3.3.50+, updated this morning.
>>>>>>
>>>>>> I make using
>>>>>> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
>>>>>> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
>>>>>> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>>>>>>
>>>>>
>>>>> In general, if you're with a newer gcc on a 64-bit architecture, I
>>>>> advise you against -funroll-loops. For me, it usually gets some +1% of
>>>>> additional speed of some operations, at the cost of increasing the
>>>>> binaries' size by more than 50%. Seems like a bad tradeoff.
>>>>>
>>>>>> ./configure reports
>>>>>> ?BLAS libraries: ? ? ? -llapack -lcblas -lf77blas -latlas
>>>>>>
>>>>>> so I assume that Octave is using Atlas (the atlas dev package that
>>>>>> comes with Kubuntu Jaunty amd64).
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>
>>>>> Apparently, yes. Hmm. It's really weird you got almost exactly the same figures.
>>>>> If you apply the attached patch, rebuild and re-run the benchmark,
>>>>> what do you get?
>>>>>
>>>>> --
>>>>> RNDr. Jaroslav Hajek
>>>>> computing expert & GNU Octave developer
>>>>> Aeronautical Research and Test Institute (VZLU)
>>>>> Prague, Czech Republic
>>>>> url: www.highegg.matfyz.cz
>>>>>
>>>>
>>>> With that patch applied, I get
>>>> octave:1> bench
>>>> Elapsed time is 0.194493 seconds.
>>>> Elapsed time is 0.192309 seconds.
>>>> Elapsed time is 0.189026 seconds.
>>>> Elapsed time is 0.188679 seconds.
>>>> Elapsed time is 0.195958 seconds.
>>>> Elapsed time is 0.193521 seconds.
>>>> Elapsed time is 0.187596 seconds.
>>>> Elapsed time is 0.193254 seconds.
>>>> Elapsed time is 0.215135 seconds.
>>>> Elapsed time is 0.213705 seconds.
>>>> Elapsed time is 0.21341 seconds.
>>>> Elapsed time is 0.212501 seconds.
>>>> Elapsed time is 0.363992 seconds.
>>>> Elapsed time is 0.368094 seconds.
>>>>
>>>> so there is an improvement in the second to last number.
>>>>
>>>> Cheers, M.
>>>>
>>>
>>> OK, it's funny. I now understand where the problem is. Just change the line
>>>
>>> b = rand (n) + i*rand (n);
>>>
>>> to
>>>
>>> b = rand (n) + I*rand (n);
>>>
>>> (note the big I). At this point, i is still defined from the previous
>>> loops as a real numeric value (!)
>>> And run the benchmarks again. I think this affects Matlab, too.
>>> In any case, it is apparent that your Matlab is linked to something
>>> faster than ATLAS; probably Intel's MKL.
>>>
>>> regards
>>>
>>> --
>>> RNDr. Jaroslav Hajek
>>> computing expert & GNU Octave developer
>>> Aeronautical Research and Test Institute (VZLU)
>>> Prague, Czech Republic
>>> url: www.highegg.matfyz.cz
>>>
>>
>> That's one of those bugs that causes rockets to go off course, I
>> guess!
>
> Yes, definitely. Maybe we could do something about it...
>
>> OK, it makes sense now. Matlab has been available here for a
>> while, but I haven't used it much. I don't know the details of what
>> libraries it uses - it's v2009b.
>
> You can usually tell by inspecting the binaries using ldd. But it
> doesn't matter much.
> I will be glad if you post the results of the corrected benchmark.
>

Btw., I guess that you have two cores, right? If so, it is likely that
your Matlab uses both of them. You can achieve a similar effect by
linking Octave to a multi-threaded ATLAS.

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


From michael.creel at uab.es  Tue Sep 29 08:13:37 2009
From: michael.creel at uab.es (Michael Creel)
Date: Tue, 29 Sep 2009 15:13:37 +0200
Subject: FYI: optimizing certain matrix arithmetic
In-Reply-To: <69d8d540909290515u4ed9d69al7b3d25656e777f46@mail.gmail.com>
References: <69d8d540909230350h2dc245d5p8f09ce279398c86d@mail.gmail.com>
	<69d8d540909290508x450cf118h209cea96790f3471@mail.gmail.com>
	<69d8d540909290515u4ed9d69al7b3d25656e777f46@mail.gmail.com>
Message-ID: <c8f260e70909290613r5a348602o6ce4948df6064c2d@mail.gmail.com>

On Tue, Sep 29, 2009 at 2:15 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 2:08 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> On Tue, Sep 29, 2009 at 1:54 PM, Michael Creel <michael.creel at uab.es> wrote:
>>> On Tue, Sep 29, 2009 at 1:44 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>> On Tue, Sep 29, 2009 at 1:34 PM, Michael Creel <michael.creel at uab.es> wrote:
>>>>> On Tue, Sep 29, 2009 at 12:47 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>>>> On Tue, Sep 29, 2009 at 12:26 PM, Michael Creel <michael.creel at uab.es> wrote:
>>>>>>> On Tue, Sep 29, 2009 at 10:44 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>>>>>> On Tue, Sep 29, 2009 at 10:38 AM, Michael Creel <michael.creel at uab.es> wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> On an Apple Macbook Pro running Ubuntu Jaunty amd64, using the benchmark
>>>>>>>>>
>>>>>>>>> %%%%%%%%%%%%%%%%%%%%%%
>>>>>>>>> n = 500;
>>>>>>>>> R = triu (rand (n));
>>>>>>>>> u = rand (n, 1);
>>>>>>>>>
>>>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>>>
>>>>>>>>> R = tril (rand (n));
>>>>>>>>> u = rand (n, 1);
>>>>>>>>>
>>>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>>>> tic; for i = 1:1000; u' / R; endfor; toc
>>>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>>>
>>>>>>>>> u = u + I*rand (n, 1);
>>>>>>>>> tic; for i = 1:1000; R \ u; endfor; toc
>>>>>>>>> tic; for i = 1:1000; R' \ u; endfor; toc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> n = 800;
>>>>>>>>> a = rand (n);
>>>>>>>>> b = rand (n) + i*rand (n);
>>>>>>>>> tic; a * b; toc
>>>>>>>>> tic; b * a; toc
>>>>>>>>> tic; a' * b; toc
>>>>>>>>> tic; b * a'; toc
>>>>>>>>> tic; a \ b; toc
>>>>>>>>> tic; b / a; toc
>>>>>>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>>>>>>>
>>>>>>>>> Octave3.0.1 that comes with Ubuntu Jaunty amd64, I get
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> octave:4> bench
>>>>>>>>> Elapsed time is 0.20216 seconds.
>>>>>>>>> Elapsed time is 1.93894 seconds.
>>>>>>>>> Elapsed time is 2.33824 seconds.
>>>>>>>>> Elapsed time is 0.188448 seconds.
>>>>>>>>> Elapsed time is 1.95657 seconds.
>>>>>>>>> Elapsed time is 2.43552 seconds.
>>>>>>>>> Elapsed time is 4.08299 seconds.
>>>>>>>>> Elapsed time is 7.84752 seconds.
>>>>>>>>> Elapsed time is 0.213021 seconds.
>>>>>>>>> Elapsed time is 0.21117 seconds.
>>>>>>>>> Elapsed time is 0.218387 seconds.
>>>>>>>>> Elapsed time is 0.217174 seconds.
>>>>>>>>> Elapsed time is 0.452714 seconds.
>>>>>>>>> Elapsed time is 0.391383 seconds.
>>>>>>>>> octave:5>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Matlab 2008b gives
>>>>>>>>>>> bench
>>>>>>>>> Elapsed time is 0.289161 seconds.
>>>>>>>>> Elapsed time is 0.566446 seconds.
>>>>>>>>> Elapsed time is 0.562623 seconds.
>>>>>>>>> Elapsed time is 0.253456 seconds.
>>>>>>>>> Elapsed time is 0.574304 seconds.
>>>>>>>>> Elapsed time is 0.570281 seconds.
>>>>>>>>> Elapsed time is 0.253070 seconds.
>>>>>>>>> Elapsed time is 0.572601 seconds.
>>>>>>>>> Elapsed time is 0.102086 seconds.
>>>>>>>>> Elapsed time is 0.102677 seconds.
>>>>>>>>> Elapsed time is 0.103080 seconds.
>>>>>>>>> Elapsed time is 0.103759 seconds.
>>>>>>>>> Elapsed time is 0.165608 seconds.
>>>>>>>>> Elapsed time is 0.181704 seconds.
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Octave 3.2.3+ from today, self compiled, gives
>>>>>>>>> octave:1> bench
>>>>>>>>> Elapsed time is 0.208794 seconds.
>>>>>>>>> Elapsed time is 0.189178 seconds.
>>>>>>>>> Elapsed time is 0.186724 seconds.
>>>>>>>>> Elapsed time is 0.188649 seconds.
>>>>>>>>> Elapsed time is 0.192915 seconds.
>>>>>>>>> Elapsed time is 0.19166 seconds.
>>>>>>>>> Elapsed time is 0.186277 seconds.
>>>>>>>>> Elapsed time is 0.19102 seconds.
>>>>>>>>> Elapsed time is 0.212707 seconds.
>>>>>>>>> Elapsed time is 0.211013 seconds.
>>>>>>>>> Elapsed time is 0.210491 seconds.
>>>>>>>>> Elapsed time is 0.210447 seconds.
>>>>>>>>> Elapsed time is 0.431791 seconds.
>>>>>>>>> Elapsed time is 0.367412 seconds.
>>>>>>>>> octave:2>
>>>>>>>>>
>>>>>>>>> Congratulations!
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>
>>>>>>>> It's interesting you didn't get any speed-up in the second part of the
>>>>>>>> benchmark, compared to 3.0.1...
>>>>>>>> What BLAS and LAPACK are you using? What's your compiler configuration?
>>>>>>>> Also, what exactly is your tip? The "3.2.3+" is a bit unclear, did you
>>>>>>>> mean "3.3.50+", i.e. the development version?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>>
>>>>>>>> --
>>>>>>>> RNDr. Jaroslav Hajek
>>>>>>>> computing expert & GNU Octave developer
>>>>>>>> Aeronautical Research and Test Institute (VZLU)
>>>>>>>> Prague, Czech Republic
>>>>>>>> url: www.highegg.matfyz.cz
>>>>>>>>
>>>>>>>
>>>>>>> Oops, sorry, it's 3.3.50+, updated this morning.
>>>>>>>
>>>>>>> I make using
>>>>>>> make -j2 CFLAGS="-O3 -march=native -funroll-loops" FFLAGS="-O3
>>>>>>> -march=native -funroll-loops" XTRA_CFLAGS="-O3 -march=native
>>>>>>> -funroll-loops" XTRA_CXXFLAGS="-O3 -march=native -funroll-loops"
>>>>>>>
>>>>>>
>>>>>> In general, if you're with a newer gcc on a 64-bit architecture, I
>>>>>> advise you against -funroll-loops. For me, it usually gets some +1% of
>>>>>> additional speed of some operations, at the cost of increasing the
>>>>>> binaries' size by more than 50%. Seems like a bad tradeoff.
>>>>>>
>>>>>>> ./configure reports
>>>>>>> ?BLAS libraries: ? ? ? -llapack -lcblas -lf77blas -latlas
>>>>>>>
>>>>>>> so I assume that Octave is using Atlas (the atlas dev package that
>>>>>>> comes with Kubuntu Jaunty amd64).
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>
>>>>>> Apparently, yes. Hmm. It's really weird you got almost exactly the same figures.
>>>>>> If you apply the attached patch, rebuild and re-run the benchmark,
>>>>>> what do you get?
>>>>>>
>>>>>> --
>>>>>> RNDr. Jaroslav Hajek
>>>>>> computing expert & GNU Octave developer
>>>>>> Aeronautical Research and Test Institute (VZLU)
>>>>>> Prague, Czech Republic
>>>>>> url: www.highegg.matfyz.cz
>>>>>>
>>>>>
>>>>> With that patch applied, I get
>>>>> octave:1> bench
>>>>> Elapsed time is 0.194493 seconds.
>>>>> Elapsed time is 0.192309 seconds.
>>>>> Elapsed time is 0.189026 seconds.
>>>>> Elapsed time is 0.188679 seconds.
>>>>> Elapsed time is 0.195958 seconds.
>>>>> Elapsed time is 0.193521 seconds.
>>>>> Elapsed time is 0.187596 seconds.
>>>>> Elapsed time is 0.193254 seconds.
>>>>> Elapsed time is 0.215135 seconds.
>>>>> Elapsed time is 0.213705 seconds.
>>>>> Elapsed time is 0.21341 seconds.
>>>>> Elapsed time is 0.212501 seconds.
>>>>> Elapsed time is 0.363992 seconds.
>>>>> Elapsed time is 0.368094 seconds.
>>>>>
>>>>> so there is an improvement in the second to last number.
>>>>>
>>>>> Cheers, M.
>>>>>
>>>>
>>>> OK, it's funny. I now understand where the problem is. Just change the line
>>>>
>>>> b = rand (n) + i*rand (n);
>>>>
>>>> to
>>>>
>>>> b = rand (n) + I*rand (n);
>>>>
>>>> (note the big I). At this point, i is still defined from the previous
>>>> loops as a real numeric value (!)
>>>> And run the benchmarks again. I think this affects Matlab, too.
>>>> In any case, it is apparent that your Matlab is linked to something
>>>> faster than ATLAS; probably Intel's MKL.
>>>>
>>>> regards
>>>>
>>>> --
>>>> RNDr. Jaroslav Hajek
>>>> computing expert & GNU Octave developer
>>>> Aeronautical Research and Test Institute (VZLU)
>>>> Prague, Czech Republic
>>>> url: www.highegg.matfyz.cz
>>>>
>>>
>>> That's one of those bugs that causes rockets to go off course, I
>>> guess!
>>
>> Yes, definitely. Maybe we could do something about it...
>>
>>> OK, it makes sense now. Matlab has been available here for a
>>> while, but I haven't used it much. I don't know the details of what
>>> libraries it uses - it's v2009b.
>>
>> You can usually tell by inspecting the binaries using ldd. But it
>> doesn't matter much.
>> I will be glad if you post the results of the corrected benchmark.
>>
>
> Btw., I guess that you have two cores, right? If so, it is likely that
> your Matlab uses both of them. You can achieve a similar effect by
> linking Octave to a multi-threaded ATLAS.
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>



The corrected benchmark, which works for both Octave and Matlab,
(uses 'j'  for complex unit) is

%%%%%%%%%%%%%%%%%%
n = 500;
R = triu (rand (n));
u = rand (n, 1);

tic; for i = 1:1000; R \ u; end; toc
tic; for i = 1:1000; u' / R; end; toc
tic; for i = 1:1000; R' \ u; end; toc

R = tril (rand (n));
u = rand (n, 1);

tic; for i = 1:1000; R \ u; end; toc
tic; for i = 1:1000; u' / R; end; toc
tic; for i = 1:1000; R' \ u; end; toc

u = u + j*rand (n, 1);
tic; for i = 1:1000; R \ u; end; toc
tic; for i = 1:1000; R' \ u; end; toc


n = 800;
a = rand (n);
b = rand (n) + j*rand (n);
tic; a * b; toc
tic; b * a; toc
tic; a' * b; toc
tic; b * a'; toc
tic; a \ b; toc
tic; b / a; toc
%%%%%%%%%%%%%%%%%%%%%


Matlab gives
>> bench
Elapsed time is 0.321079 seconds.
Elapsed time is 0.617195 seconds.
Elapsed time is 0.576792 seconds.
Elapsed time is 0.253461 seconds.
Elapsed time is 0.599158 seconds.
Elapsed time is 0.658734 seconds.
Elapsed time is 0.314414 seconds.
Elapsed time is 0.703873 seconds.
Elapsed time is 0.206035 seconds.
Elapsed time is 0.206898 seconds.
Elapsed time is 0.207248 seconds.
Elapsed time is 0.208293 seconds.
Elapsed time is 0.274126 seconds.
Elapsed time is 0.344650 seconds.


Octave 3.3.50+ (with the patch you posted) gives
octave:1> bench
Elapsed time is 0.202895 seconds.
Elapsed time is 0.195078 seconds.
Elapsed time is 0.193112 seconds.
Elapsed time is 0.18874 seconds.
Elapsed time is 0.196512 seconds.
Elapsed time is 0.193809 seconds.
Elapsed time is 0.290697 seconds.
Elapsed time is 0.297939 seconds.
real * complex: split
Elapsed time is 0.624116 seconds.
complex * real: split
Elapsed time is 0.451244 seconds.
Elapsed time is 0.450199 seconds.
Elapsed time is 0.452107 seconds.
Elapsed time is 0.65004 seconds.
Elapsed time is 0.694705 seconds.
octave:2>


As far as I can tell, matlab is using only 1 core. Perhaps it would
use both cores if it had to work with larger matrices.

Michael


From j4r.e4o at gmail.com  Tue Sep 29 09:11:44 2009
From: j4r.e4o at gmail.com (Javier Enciso)
Date: Tue, 29 Sep 2009 16:11:44 +0200
Subject: divergence function
In-Reply-To: <69d8d540909290238l110bc56ap21ecf2748d6b0ccd@mail.gmail.com>
References: <4AC1D066.9090803@googlemail.com>
	<69d8d540909290238l110bc56ap21ecf2748d6b0ccd@mail.gmail.com>
Message-ID: <4AC215A0.5010407@googlemail.com>

Jaroslav Hajek wrote:
> On Tue, Sep 29, 2009 at 11:16 AM, Javier Enciso <j4r.e4o at gmail.com> wrote:
>> Hi All,
>>
>> I' not sure whether this email already reach you guys, I wasn't member of
>> the mailing list, anyway I just resend it.
>>
>> I'm glad to contribute with the 'divergence' function. This function
>> is used to compute divergence of vector field and is part of Matlab's
>> core functions.
>>
>> In doubt, please feel free to contact me.
>>
>> Regards,
>> Javier
>>
> 
> Hello Javier,
> 
> I have a couple of suggestions:
> 1. Please don't use tabs (or 8 spaces) to indent the code; use two
> spaces. This is done everywhere in Octave sources.
> 
> 2. blocks like
>>                        x = varargin {1};
>>                        y = varargin {2};
>>                        z = varargin {3};
>>                        u = varargin {4};
>>                        v = varargin {5};
>>                        w = varargin {6};
> can be abbreviated to
> 
> [x,y,z,u,v,w] = deal (varargin{1:6});
> 
> this improves readability. Consider doing it.
> 
> 3. in check_dim, the for loops can be avoided:
> 
> function [] = check_dim (varargin)
>   if (!size_equal (varargin{:})
>     error ("Size of matrices must be equal");
>   endif
> 
>   switch (nargin)
>   case {2, 4}
>     if (any (cellfun (@ndims, varargin) != 2))
>       error ("Matrices must have 2 dimensions");
>     endif
>   case {3, 6}			
>     if (any (cellfun (@ndims, varargin) != 3))
>       error ("Matrices must have 3 dimensions");
>     endif
>   endswitch
> endfunction
> 
> 
> no big concern about performance in this case, since nargin is small,
> but it also seems to improve readability, at least to me...
> 

Hi Jaroslav,

Thanks for your suggestions, it really helps to improve the readability 
of the code. ;-)

I already made the corrections and I hope the code is ready to be 
shipped. If you (or someone else) have any other concern, please let me 
know.

Regards,
Javier
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: divergence.m
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090929/8266e5ec/attachment.ksh 

From soren at hauberg.org  Tue Sep 29 09:20:20 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 29 Sep 2009 16:20:20 +0200
Subject: divergence function
In-Reply-To: <4AC215A0.5010407@googlemail.com>
References: <4AC1D066.9090803@googlemail.com>
	<69d8d540909290238l110bc56ap21ecf2748d6b0ccd@mail.gmail.com>
	<4AC215A0.5010407@googlemail.com>
Message-ID: <1254234020.4443.3.camel@sh-t400>

tir, 29 09 2009 kl. 16:11 +0200, skrev Javier Enciso:
> I already made the corrections and I hope the code is ready to be 
> shipped. If you (or someone else) have any other concern, please let me 
> know.

A few minor things:

  * In your cases you have, e.g.

      case 2
        [u, v] = deal (varargin{1:2});

    since you know that 'varargin' has two elements, you can just write

      case 2
        [u, v] = deal (varargin{:});

  * When calling 'error', the message should start with the name of the
    function raising the error, i.e.

      error ("divergence: size of matrices must be equal");

  * Instead of

      function [] = check_dim (varargin)

    you should probably just write

      function check_dim (varargin)

Otherwise I think it looks good :-)

S?ren


From lindnerben at gmx.net  Tue Sep 29 13:51:58 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 29 Sep 2009 20:51:58 +0200
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built	by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090929031956.28217.qmail@web3814.mail.bbt.yahoo.co.jp>
References: <20090929031956.28217.qmail@web3814.mail.bbt.yahoo.co.jp>
Message-ID: <4AC2574E.7030305@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> --- Tatsuro MATSUOKA  wrote:
>> I have built octave-3.3.50 mingw-gcc-4.4.0.
>>
>> At the prompt I execute octave from the prompt
>>
>> $ octave
>>
>> $
>>  
>> Octave starts but finishes soon without any messages.
> 
> This problem caused by the linker flags acquired from fltk-config.
> 
>   FLTK backend libs:    -L/c/Programs/OctaveBuild/lib -mwindows -Lc:/Programs/OctaveBuild/lib
> -Lc:/Programs/WinDevTools/lib -Lc:/Programs/GnuWin32/lib -mno-cygwin -Wl,--enable-auto-import
> -Wl,--enable-runtime-pseudo-reloc -lfltk_gl -lglu32-lopengl32 -lfltk -lpthread -lole32 -lcomctl32
> 
> The above incules -mwindows and this flag made it impossible to startup octave.
> 
> Similar problem occur console mode gnuplot 4.3 for windows with wxt terminal.
> See 
> 
> http://www.nabble.com/console-mode-gnuplot-for-windows-with-wxt-doen-not-work-(gnuplot-4.3---mingw)-td25536073.html
> 
> http://www.nabble.com/Patch-for-makefile.mgw-for-console-mode-of-gnuplot-4.3-for-windows-td25643747.html
> 
> First I have kick out this problem by tweaking wx-config, by which 'make' of gnuplot gets linker flag.
>  However, this kind of tweaking is better to be avoided if possible.
> 
> I have discussed linker option problem with the developer of wxWidgets. He proposed to use
> -Wl,--subsystem,console option to override of -mwindows.

That's not the way to do it IMO.

> In the gnuplot case, I now propose two patches
> FIrst:
> -	WX_LIBS = $(shell wx-config --libs)
> +	WX_LIBS = $(shell wx-config --libs | sed -e 's/ -Wl,--subsystem,windows -mwindows//')
> Second:
>  	WX_LIBS = $(shell wx-config --libs)
> +	ifdef PIPES
> +		WX_LIBS += -Wl,--subsystem,console
> +	endif
> 
> In case that I consider the patch for fltk-config for windows, is which way is better?

As in the gnuplot issue, the former.

benjamin

From lindnerben at gmx.net  Tue Sep 29 13:55:32 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 29 Sep 2009 20:55:32 +0200
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090929082251.37122.qmail@web3814.mail.bbt.yahoo.co.jp>
References: <20090929082251.37122.qmail@web3814.mail.bbt.yahoo.co.jp>
Message-ID: <4AC25824.3010606@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> --- Tatsuro MATSUOKA wrote:
> 
>> Yes it work if I remove '-mwindows' flag from fltk-config. (Howeever, eigs.cc test causes
>> segfault! in
>> the yesterday run).
>>  
>> It is also case for wxWidget case for gnuplot.  I discussed one of the wxWidget developer. I
>> proposed
>> that -mwindows flag is to be removed from wx-config.  However, my proposal is rejected because
>> most
>> users use native windows application. 
>>
>> Tweaking wx-config is easy but the tweaking without careful consideration is better to be
>> avoided. I'm
>> afraid that it may cause unwanted results when I use wxWidget libraries for other applications.
>>
>> In the case of fltk and octave, I think it would better to modify configure setting of octave
>> than to
>> modify fltk-config.  That is because fltk is not only used for octave. So that change of default
>> setting should be avoided if possible. 
>>
>> How do other people think about this case ?
> 

For the mingw binaries, since I need to build fltk from source, I can 
remove the -mwindows flag there from fltk-config, so I would't need to 
have it dealt with in octave's configure script.

Does this problem also occur on cygwin?

If we deal with this in octave's configure script, then I'd suggest it 
be done only for mingw (and cygwn?) platform.

> 
> I have considered the patch
> 
> --- configure.in.orig	2009-09-12 19:52:06 +0900
> +++ configure.in	2009-09-29 16:56:09 +0900
> @@ -845,7 +845,7 @@
>    warn_fltk_config="FLTK config script not found.  Native graphics will be disabled."
>  else
>    FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`"
> -  FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`"
> +  FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags | sed -e 's/ -mwindows//'`"

I'd suggest

sed -e "+s-mwindows++g"

to be more robust.


From j4r.e4o at gmail.com  Tue Sep 29 14:05:32 2009
From: j4r.e4o at gmail.com (Javier Enciso)
Date: Tue, 29 Sep 2009 21:05:32 +0200
Subject: divergence function
In-Reply-To: <1254234020.4443.3.camel@sh-t400>
References: <4AC1D066.9090803@googlemail.com>	
	<69d8d540909290238l110bc56ap21ecf2748d6b0ccd@mail.gmail.com>	
	<4AC215A0.5010407@googlemail.com> <1254234020.4443.3.camel@sh-t400>
Message-ID: <4AC25A7C.4000801@googlemail.com>

S?ren Hauberg wrote:
> tir, 29 09 2009 kl. 16:11 +0200, skrev Javier Enciso:
>> I already made the corrections and I hope the code is ready to be 
>> shipped. If you (or someone else) have any other concern, please let me 
>> know.
> 
> A few minor things:
> 
>   * In your cases you have, e.g.
> 
>       case 2
>         [u, v] = deal (varargin{1:2});
> 
>     since you know that 'varargin' has two elements, you can just write
> 
>       case 2
>         [u, v] = deal (varargin{:});
> 
>   * When calling 'error', the message should start with the name of the
>     function raising the error, i.e.
> 
>       error ("divergence: size of matrices must be equal");
> 
>   * Instead of
> 
>       function [] = check_dim (varargin)
> 
>     you should probably just write
> 
>       function check_dim (varargin)
> 
> Otherwise I think it looks good :-)
> 
> S?ren
> 
> 

Hi S?ren,

Thanks again for your suggestions. Here it goes the correction and if 
any other improvement is spotted, please let me know.

Btw, is there a formal guideline for coding style? I guess I'm missing 
that document. ;-)

Cheers,
Javier
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: divergence.m
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090929/11c1b424/attachment.ksh 

From soren at hauberg.org  Wed Sep 30 00:58:29 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 30 Sep 2009 07:58:29 +0200
Subject: divergence function
In-Reply-To: <4AC25A7C.4000801@googlemail.com>
References: <4AC1D066.9090803@googlemail.com>
	<69d8d540909290238l110bc56ap21ecf2748d6b0ccd@mail.gmail.com>
	<4AC215A0.5010407@googlemail.com> <1254234020.4443.3.camel@sh-t400>
	<4AC25A7C.4000801@googlemail.com>
Message-ID: <1254290309.5170.3.camel@sh-t400>

tir, 29 09 2009 kl. 21:05 +0200, skrev Javier Enciso:
> Thanks again for your suggestions. Here it goes the correction and if 
> any other improvement is spotted, please let me know.

Thanks!

> Btw, is there a formal guideline for coding style? I guess I'm missing 
> that document. ;-)

I think there is a chapter or appendix in the Octave manual about
contribution guidelines, which includes coding style.

S?ren


From tmacchant at yahoo.co.jp  Wed Sep 30 02:18:42 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 30 Sep 2009 16:18:42 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <420fb9e60909282140p45c02c82xb8e90c07f9aa6345@mail.gmail.com>
Message-ID: <20090930071842.90462.qmail@web3807.mail.bbt.yahoo.co.jp>

Hello

--- Shai Ayal wrote:
> 
> I have never used fltk with mingw, only cygwin, so I don't know :(
> Did you try to compile with these flags? what were the results of
> removing -mwindows -- did the fltk backend compile/run?
> 
>From the cygwin-1.7 prompt

$ $ fltk-config --use-gl --ldflags
-L/usr/local/lib -mwindows -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc -lfltk_gl
-lglu32 -lopengl32 -lfltk -lpthread -lole32 -luuid -lcomctl32

This fltk is installed by setup-1.7.exe.

The '-mwindows' option is not deleted. 

Hi Marco.
In the cygwin case, is not the -mwindow option harmful for building octave in the development branch ?

You can follow the context the below 
http://www.nabble.com/octave-3.3.50-built-by-mingw-gcc-4.4.0-cannot-be-executed.-td25569527.html

Regards

Tatsuro   


--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

From marco_atzeri at yahoo.it  Wed Sep 30 03:31:42 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Wed, 30 Sep 2009 08:31:42 +0000 (GMT)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090930071842.90462.qmail@web3807.mail.bbt.yahoo.co.jp>
Message-ID: <111053.24794.qm@web25501.mail.ukl.yahoo.com>

> Da: Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>
> Oggetto: Re: fltk-config for windows gives -mwindows flag (was octave-3.3.50  built by mingw-gcc-4.4.0 cannot be executed.)
> A: "Marco Atzeri" <marco_atzeri at yahoo.it>
> Cc: maintainers at octave.org, "Shai Ayal" <shaiay at gmail.com>
> Data: Mercoled? 30 settembre 2009, 09:18
> Hello
> 
> --- Shai Ayal wrote:
> > 
> > I have never used fltk with mingw, only cygwin, so I
> don't know :(
> > Did you try to compile with these flags? what were the
> results of
> > removing -mwindows -- did the fltk backend
> compile/run?
> > 
> From the cygwin-1.7 prompt
> 
> $ $ fltk-config --use-gl --ldflags
> -L/usr/local/lib -mwindows -Wl,--enable-auto-import
> -Wl,--enable-runtime-pseudo-reloc -lfltk_gl
> -lglu32 -lopengl32 -lfltk -lpthread -lole32 -luuid
> -lcomctl32
> 
> This fltk is installed by setup-1.7.exe.
> 
> The '-mwindows' option is not deleted. 
> 
> Hi Marco.
> In the cygwin case, is not the -mwindow option harmful for
> building octave in the development branch ?
> 
> You can follow the context the below 
> http://www.nabble.com/octave-3.3.50-built-by-mingw-gcc-4.4.0-cannot-be-executed.-td25569527.html

Hi Tatsuro,
currently fltk don't work on cygwin; at least for me.
The windows is created but only garbage is plotted.

I presume it is due to the available fltk 
that is the not X11 version while the other GL 
graphics library are X11.

So for the time being all my test are built with

../octave/configure --enable-float-truncate --libexecdir=/usr/lib --enable-shared --without-fltk --without-framework-opengl CFLAGS=-Dtimezone=_timezone CC="gcc-4 -shared-libgcc" F77=gfortran-4 CXX=g++-4 CPP=cpp-4

> 
> Regards
> 
> Tatsuro???

Marco



      


From tmacchant at yahoo.co.jp  Wed Sep 30 06:01:23 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 30 Sep 2009 20:01:23 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <111053.24794.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <20090930110124.65083.qmail@web3804.mail.bbt.yahoo.co.jp>

Hello

--- Marco Atzeri  wrote:

> Hi Tatsuro,
> currently fltk don't work on cygwin; at least for me.
> The windows is created but only garbage is plotted.
> 
> I presume it is due to the available fltk 
> that is the not X11 version while the other GL 
> graphics library are X11.
> 
> So for the time being all my test are built with
> 
> ../octave/configure --enable-float-truncate --libexecdir=/usr/lib --enable-shared --without-fltk
> --without-framework-opengl CFLAGS=-Dtimezone=_timezone CC="gcc-4 -shared-libgcc" F77=gfortran-4
> CXX=g++-4 CPP=cpp-4
> 
 Thank you for your reply.
I will propose the patch for mingw only.

Regards

Tatsuro


--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

From tmacchant at yahoo.co.jp  Wed Sep 30 06:15:33 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 30 Sep 2009 20:15:33 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <4AC25824.3010606@gmx.net>
Message-ID: <20090930111533.90584.qmail@web3806.mail.bbt.yahoo.co.jp>

Hello


--- Benjamin Lindner  wrote:
> For the mingw binaries, since I need to build fltk from source, I can 
> remove the -mwindows flag there from fltk-config, so I would't need to 
> have it dealt with in octave's configure script.
> 
> Does this problem also occur on cygwin?
> 
> If we deal with this in octave's configure script, then I'd suggest it 
> be done only for mingw (and cygwn?) platform.
> 
> sed -e "+s-mwindows++g"
The above is typo. sed -e "s+-mwindows++g" is correct. 

--- Marco Atzeri  wrote:

> Hi Tatsuro,
> currently fltk don't work on cygwin; at least for me.
> The windows is created but only garbage is plotted.

Although Benjamin said "so I would't need to have it dealt with in octave's configure script", I
propose here the patch for FLTK_LDFLAGS.

Regards

Tatsuro

--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk-config_mingw.changeset
Type: application/x-unknown
Size: 826 bytes
Desc: 2999286454-fltk-config_mingw.changeset
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090930/9ee3dad1/attachment.bin 

From tmacchant at yahoo.co.jp  Wed Sep 30 06:31:23 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 30 Sep 2009 20:31:23 +0900 (JST)
Subject: README.MinGW?
Message-ID: <20090930113123.34079.qmail@web3812.mail.bbt.yahoo.co.jp>

Today I noticed that there are README.MSVC, README.Cygwin but not README.MinGW in the octave source
trees.

The README.MSVC is out dated and would be better to deleted. (Michael agreed to delete it.)

I think that README.MinGW is better to be added to the source trees.

Regards

Tatsuro

--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/