3.2.3 RC2

[Jaroslav Hajek-2]

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@...>
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@...>
date:        Thu Aug 13 20:20:32 2009 +0200
summary:     skip double declaration of tztime

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

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

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

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

changeset:   9418:68f62a3337f5
user:        Rob Mahurin <rob@...>
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@...>
date:        Tue Sep 01 09:25:53 2009 +0200
summary:     fix griddata

changeset:   9420:abe96098735c
user:        John W. Eaton <jwe@...>
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@...>
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@...>
date:        Tue Sep 01 09:31:39 2009 +0200
summary:     datestr: add missing semicolon

changeset:   9423:8fd98b0a62a0
user:        Jaroslav Hajek <highegg@...>
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@...>
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

[Tatsuro MATSUOKA-2]

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@...> wrote:

>
> changeset:   9416:7ed8182b783d
> user:        John W. Eaton <jwe@...>
> 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/

[Benjamin Lindner]

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@...>
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

[Dmitri A. Sergatskov]

On Tue, Sep 1, 2009 at 3:39 PM, Benjamin Lindner<lindnerben@...> 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@...>
> 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.
--

[John W. Eaton-3]

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

[John W. Eaton-3]

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

[Marco atzeri-3]

-- Mar 1/9/09, Dmitri A. Sergatskov <dasergatskov@...> 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


     

[Dmitri A. Sergatskov]

On Tue, Sep 1, 2009 at 5:14 PM, Marco Atzeri<marco_atzeri@...> 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.
--

[Dmitri A. Sergatskov]

On Tue, Sep 1, 2009 at 4:45 PM, John W. Eaton<jwe@...> 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.
--

[Tatsuro MATSUOKA-2]

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@...>
> 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/

[Tatsuro MATSUOKA-2]

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@...> wrote:

> -- Mar 1/9/09, Dmitri A. Sergatskov <dasergatskov@...> 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/

[Tatsuro MATSUOKA-2]

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@...> wrote:
>
> > -- Mar 1/9/09, Dmitri A. Sergatskov <dasergatskov@...> 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/

[Tatsuro MATSUOKA-2]

Hello



changeset:   9395:54a3fa5d4376
user:        Ben Abbott <bpabbott@...>
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@...>
> > 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/

[Benjamin Lindner]

>
> changeset:   9395:54a3fa5d4376
> user:        Ben Abbott <bpabbott@...>
> 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

[dbateman]

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.

[Benjamin Lindner]

>
>
>
> 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

[John W. Eaton-3]

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

| On Tue, Sep 1, 2009 at 5:14 PM, Marco Atzeri<marco_atzeri@...> 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

[Dmitri A. Sergatskov]

On Wed, Sep 2, 2009 at 1:29 PM, John W. Eaton<jwe@...> 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.
--

[Marco atzeri-3]

--- Mer 2/9/09, John W. Eaton <jwe@...> 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



     

[dbateman]

Dmitri A. Sergatskov wrote:

> On Wed, Sep 2, 2009 at 1:29 PM, John W. Eaton<jwe@...> 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@...
35 rue Gambetta                              [phone] (Home)
92100 Boulogne-Billancourt FRANCE            [phone] (Mob)