Menu
▾
▴
octave-dev — GNU Octave developers' list
This list is closed, nobody may subscribe to it.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(10) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(4) |
Mar
|
Apr
(3) |
May
(13) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(8) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
(19) |
Apr
(8) |
May
(8) |
Jun
(8) |
Jul
(4) |
Aug
(8) |
Sep
(19) |
Oct
(13) |
Nov
(37) |
Dec
(2) |
| 2003 |
Jan
(7) |
Feb
(23) |
Mar
(16) |
Apr
(4) |
May
(18) |
Jun
(9) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(39) |
Dec
(57) |
| 2004 |
Jan
(21) |
Feb
(15) |
Mar
(17) |
Apr
(9) |
May
(17) |
Jun
(65) |
Jul
(33) |
Aug
(48) |
Sep
(93) |
Oct
(35) |
Nov
(18) |
Dec
(4) |
| 2005 |
Jan
(20) |
Feb
(59) |
Mar
(17) |
Apr
(59) |
May
(77) |
Jun
(32) |
Jul
(34) |
Aug
(8) |
Sep
(34) |
Oct
(26) |
Nov
(65) |
Dec
(66) |
| 2006 |
Jan
(45) |
Feb
(37) |
Mar
(50) |
Apr
(32) |
May
(48) |
Jun
(42) |
Jul
(12) |
Aug
(53) |
Sep
(51) |
Oct
(79) |
Nov
(46) |
Dec
(25) |
| 2007 |
Jan
(120) |
Feb
(78) |
Mar
(45) |
Apr
(91) |
May
(155) |
Jun
(66) |
Jul
(96) |
Aug
(110) |
Sep
(145) |
Oct
(189) |
Nov
(68) |
Dec
(160) |
| 2008 |
Jan
(163) |
Feb
(212) |
Mar
(209) |
Apr
(157) |
May
(216) |
Jun
(120) |
Jul
(80) |
Aug
(83) |
Sep
(98) |
Oct
(120) |
Nov
(80) |
Dec
(129) |
| 2009 |
Jan
(45) |
Feb
(80) |
Mar
(174) |
Apr
(142) |
May
(133) |
Jun
(191) |
Jul
(183) |
Aug
(138) |
Sep
(77) |
Oct
(141) |
Nov
(209) |
Dec
(131) |
| 2010 |
Jan
(85) |
Feb
(213) |
Mar
(245) |
Apr
(222) |
May
(168) |
Jun
(82) |
Jul
(50) |
Aug
(144) |
Sep
(92) |
Oct
(80) |
Nov
(64) |
Dec
(78) |
| 2011 |
Jan
(58) |
Feb
(98) |
Mar
(112) |
Apr
(98) |
May
(64) |
Jun
(150) |
Jul
(126) |
Aug
(59) |
Sep
(271) |
Oct
(154) |
Nov
(321) |
Dec
(183) |
| 2012 |
Jan
(146) |
Feb
(217) |
Mar
(426) |
Apr
(208) |
May
(206) |
Jun
(230) |
Jul
(158) |
Aug
(170) |
Sep
(237) |
Oct
(260) |
Nov
(178) |
Dec
|
|
From: Paul K. <pki...@us...> - 2004-12-18 04:14:51
|
On Dec 17, 2004, at 8:23 PM, Corey Halpin wrote: > I'm the proud new maintainer (recently adopted) of the octave-forge > package for fink. Great! > Mac OS X supports a number of file systems. The default, HFS+, is > not > case sensitive. However OS X also supports UFS, which is case > sensitive. This means that the attached patch needs to be applied in > order to build octave-forge correctly on OS X systems that use UFS. Applied, thanks. - Paul |
|
From: Corey H. <ch...@cs...> - 2004-12-18 01:23:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello octave-dev! I'm the proud new maintainer (recently adopted) of the octave-forge package for fink. Mac OS X supports a number of file systems. The default, HFS+, is not case sensitive. However OS X also supports UFS, which is case sensitive. This means that the attached patch needs to be applied in order to build octave-forge correctly on OS X systems that use UFS. Thought you'd like to know. regards, crh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBw4Z+WBjzOA9cliERAnmjAJ980FNesnu3p2qHYM8Lg1z0ONcolgCcCGuT wDmgzcEQswQ3hMwQ1J6Q9dc= =8+0o -----END PGP SIGNATURE----- |
|
From: Orion P. <or...@co...> - 2004-12-16 19:30:01
|
I've been having some issues with octave's signbit() code in lo-ieee.h. I think I've gotten them resolved, but I also needed to patch octave-forge-2004.11.16/main/fixed/int/fixed.cc to include <octave/config.h>. This seems like a good thing in general to include before "internal" octave include files. --- octave-forge-2004.11.16/main/fixed/int/fixed.cc.orig 2004-12-16 12:24:49.946684945 -0700 +++ octave-forge-2004.11.16/main/fixed/int/fixed.cc 2004-12-16 12:23:14.139144545 -0700 @@ -45,6 +45,7 @@ #define lo_ieee_isinf(x) isinf(x) #else +#include <octave/config.h> #include <octave/lo-ieee.h> #endif -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com |
|
From: Dirk E. <ed...@de...> - 2004-11-19 05:01:23
|
On Thu, Nov 18, 2004 at 10:15:08PM -0600, Dirk Eddelbuettel wrote: > On Thu, Nov 18, 2004 at 10:52:12PM -0500, Dan McMahill wrote: [...] > > On Thu, Nov 18, 2004 at 08:38:02PM -0600, Dirk Eddelbuettel wrote: > > > On Thu, Nov 18, 2004 at 03:12:53PM +0000, Christophe Rhodes wrote: [...] > > This looks like the following patch hasn't been applied yet: > > > > --- /dev/null Mon Oct 18 16:08:42 2004 > > +++ extra/mex/configure.add Mon Oct 18 16:26:09 2004 > > @@ -0,0 +1,3 @@ > > + > > +AC_PROG_AWK > > + > > > > That should have been part of the patches in bug #1062239 > > (http://sourceforge.net/tracker/index.php?func=detail&aid=1062239&group_id=2888&atid=102888) > > but that part seems to be missing. Maybe someone forgot to 'cvs add configure.add'. > > Yes indeed! Thanks for the speedy reply! > > I'll apply by hand and see how it goes. Thanks -- that did it. New version being uploaded as I type. Dirk -- If your hair is standing up, then you are in extreme danger. -- http://www.usafa.af.mil/dfp/cockpit-phys/fp1ex3.htm |
|
From: Dirk E. <ed...@de...> - 2004-11-19 04:15:17
|
On Thu, Nov 18, 2004 at 10:52:12PM -0500, Dan McMahill wrote: > > > On Thu, Nov 18, 2004 at 08:38:02PM -0600, Dirk Eddelbuettel wrote: > > On Thu, Nov 18, 2004 at 03:12:53PM +0000, Christophe Rhodes wrote: > > > Package: octave-forge > > > Version: 2004.11.16-1 > > > Severity: normal > > > > > > Hi, > > > > > > My copy of /usr/bin/mex seems to have a literal @AWK@ left in it -- > > > which stops mex from working. Is it the sign of an autoconf gone wrong? > > > Hand-editing the script to have awk rather than @AWK@ makes it work. > > > > Thanks for the bug report, which I am passing on to the octave-forge > > hackers. This looks like something we can probably patch rather quickly in > > both the package and upstream cvs. > > > > Here what my build log shows: > > > > Processing extra/mex/ > > make[3]: Entering directory /tmp/buildd/octave-forge-2004.11.16/extra/mex' > > mkoctfile -DHAVE_OCTAVE_21 -v -c -o mex.o mex.cc > > /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.63 > > -I/usr/include/octave-2.1.63/ > > octave -mieee-fp -O2 -DHAVE_OCTAVE_21 mex.cc -o mex.o > > cat mex.in | sed -e "s:@MKOCTFILE@:mkoctfile -DHAVE_OCTAVE_21 > > -v:;s:@LIBPATH@:/u > > sr/lib/octave/2.1.63/site/oct/i386-pc-linux-gnu/octave-forge:g;s:@MEXLIB@:mex.o: > > g" \ > > -e 's;@_AWK_@;@AWK@;g' > mex > > chmod a+x mex > > > > Probably something wrong with configure ... > > This looks like the following patch hasn't been applied yet: > > --- /dev/null Mon Oct 18 16:08:42 2004 > +++ extra/mex/configure.add Mon Oct 18 16:26:09 2004 > @@ -0,0 +1,3 @@ > + > +AC_PROG_AWK > + > > That should have been part of the patches in bug #1062239 > (http://sourceforge.net/tracker/index.php?func=detail&aid=1062239&group_id=2888&atid=102888) > but that part seems to be missing. Maybe someone forgot to 'cvs add configure.add'. Yes indeed! Thanks for the speedy reply! I'll apply by hand and see how it goes. Dirk > -Dan > > -- -- If your hair is standing up, then you are in extreme danger. -- http://www.usafa.af.mil/dfp/cockpit-phys/fp1ex3.htm |
|
From: Dan M. <dan...@mc...> - 2004-11-19 03:53:49
|
On Thu, Nov 18, 2004 at 08:38:02PM -0600, Dirk Eddelbuettel wrote: > On Thu, Nov 18, 2004 at 03:12:53PM +0000, Christophe Rhodes wrote: > > Package: octave-forge > > Version: 2004.11.16-1 > > Severity: normal > > > > Hi, > > > > My copy of /usr/bin/mex seems to have a literal @AWK@ left in it -- > > which stops mex from working. Is it the sign of an autoconf gone wrong? > > Hand-editing the script to have awk rather than @AWK@ makes it work. > > Thanks for the bug report, which I am passing on to the octave-forge > hackers. This looks like something we can probably patch rather quickly in > both the package and upstream cvs. > > Here what my build log shows: > > Processing extra/mex/ > make[3]: Entering directory /tmp/buildd/octave-forge-2004.11.16/extra/mex' > mkoctfile -DHAVE_OCTAVE_21 -v -c -o mex.o mex.cc > /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.63 > -I/usr/include/octave-2.1.63/ > octave -mieee-fp -O2 -DHAVE_OCTAVE_21 mex.cc -o mex.o > cat mex.in | sed -e "s:@MKOCTFILE@:mkoctfile -DHAVE_OCTAVE_21 > -v:;s:@LIBPATH@:/u > sr/lib/octave/2.1.63/site/oct/i386-pc-linux-gnu/octave-forge:g;s:@MEXLIB@:mex.o: > g" \ > -e 's;@_AWK_@;@AWK@;g' > mex > chmod a+x mex > > Probably something wrong with configure ... This looks like the following patch hasn't been applied yet: --- /dev/null Mon Oct 18 16:08:42 2004 +++ extra/mex/configure.add Mon Oct 18 16:26:09 2004 @@ -0,0 +1,3 @@ + +AC_PROG_AWK + That should have been part of the patches in bug #1062239 (http://sourceforge.net/tracker/index.php?func=detail&aid=1062239&group_id=2888&atid=102888) but that part seems to be missing. Maybe someone forgot to 'cvs add configure.add'. -Dan -- |
|
From: Dirk E. <ed...@de...> - 2004-11-19 02:38:19
|
On Thu, Nov 18, 2004 at 03:12:53PM +0000, Christophe Rhodes wrote:
> Package: octave-forge
> Version: 2004.11.16-1
> Severity: normal
>
> Hi,
>
> My copy of /usr/bin/mex seems to have a literal @AWK@ left in it --
> which stops mex from working. Is it the sign of an autoconf gone wrong?
> Hand-editing the script to have awk rather than @AWK@ makes it work.
Thanks for the bug report, which I am passing on to the octave-forge
hackers. This looks like something we can probably patch rather quickly in
both the package and upstream cvs.
Here what my build log shows:
Processing extra/mex/
make[3]: Entering directory /tmp/buildd/octave-forge-2004.11.16/extra/mex'
mkoctfile -DHAVE_OCTAVE_21 -v -c -o mex.o mex.cc
/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.63
-I/usr/include/octave-2.1.63/
octave -mieee-fp -O2 -DHAVE_OCTAVE_21 mex.cc -o mex.o
cat mex.in | sed -e "s:@MKOCTFILE@:mkoctfile -DHAVE_OCTAVE_21
-v:;s:@LIBPATH@:/u
sr/lib/octave/2.1.63/site/oct/i386-pc-linux-gnu/octave-forge:g;s:@MEXLIB@:mex.o:
g" \
-e 's;@_AWK_@;@AWK@;g' > mex
chmod a+x mex
Probably something wrong with configure ...
Regards, Dirk
> Cheers,
>
> Christophe
>
> -- System Information:
> Debian Release: 3.1
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> Kernel: Linux 2.6.7csr1
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>
> Versions of packages octave-forge depends on:
> ii atlas3-base [liblapack.s 3.6.0-19 Automatically Tuned Linear Algebra
> ii fftw3 3.0.1-10 Library for computing Fast Fourier
> ii lapack3 [liblapack.so.3] 3.0.20000531a-5 library of linear algebra routines
> ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an
> ii libcln3 1.1.9-1 Class Library for Numbers (C++)
> ii libg2c0 1:3.3.5-2 Runtime library for GNU Fortran 77
> ii libgcc1 1:3.4.2-3 GCC support library
> ii libginac1.3 1.3.0-1 The GiNaC framework (runtime libra
> ii libgmp3 4.1.4-4 Multiprecision arithmetic library
> ii libgsl0 1.5-2 The GNU Scientific Library (GSL) -
> ii libhdf5-serial-1.6.2-0 [ 1.6.2-3 Hierarchical Data Format 5 (HDF5)
> ii libice6 4.3.0.dfsg.1-8 Inter-Client Exchange library
> ii libjpeg62 6b-9 The Independent JPEG Group's JPEG
> ii libncurses5 5.4-4 Shared libraries for terminal hand
> ii libpng12-0 1.2.7-1 PNG library - runtime
> ii libqhull5 2003.1-1 Calculate convex hulls and related
> ii libreadline4 4.3-15 GNU readline and history libraries
> ii libsm6 4.3.0.dfsg.1-8 X Window System Session Management
> ii libstdc++5 1:3.3.5-2 The GNU Standard C++ Library v3
> ii libx11-6 4.3.0.dfsg.1-8 X Window System protocol client li
> ii octave2.1 2.1.63-1 The GNU Octave language for numeri
> ii refblas3 [libblas.so.3] 1.2-6 Basic Linear Algebra Subroutines 3
> ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m
> ii zlib1g 1:1.2.2-3 compression library - runtime
>
> -- no debconf information
--
If your hair is standing up, then you are in extreme danger.
-- http://www.usafa.af.mil/dfp/cockpit-phys/fp1ex3.htm
|
|
From: Michael C. <mic...@ua...> - 2004-11-17 12:40:32
|
On Wednesday 17 November 2004 12:19, Teemu Ikonen wrote:
> On 17/11/04 12:52, Michael Creel wrote:
> > Hi again, I just wanted to point out another thing that seems funny - the
> > counter does not move from octave:1> to octave:2> the first time analyze
> > is run. What's up with that?
>
> That's because of the error:
>
> octave:1> error("error")
> error: error
> octave:1>
>
> Teemu
I was guessing that was the reason. The funny thing is that a plot _does_
appear, and a file _is_ saved to disk, even though the counter doesn't move.
M.
|
|
From: Teemu I. <tpi...@pc...> - 2004-11-17 12:19:09
|
On 17/11/04 12:52, Michael Creel wrote:
> Hi again, I just wanted to point out another thing that seems funny - the
> counter does not move from octave:1> to octave:2> the first time analyze is
> run. What's up with that?
That's because of the error:
octave:1> error("error")
error: error
octave:1>
Teemu
|
|
From: Stefan v. d. W. <st...@su...> - 2004-11-17 12:14:47
|
This is related to the popen thread on the maintainers list. You can
apply some dirty fixes to make legend work, but unless the underlying
problem is sorted out, it won't help much in the long run.
Regards
Stefan
On Wed, Nov 17, 2004 at 12:31:04PM +0000, Michael Creel wrote:
> I've been having some problems with legend.m in the plot subdir.
>
> Running analyze.m (attached) gives the following:
>
> octave:1> analyze
> error: invalid row index = 0
> error: evaluating argument list element number 1
> error: evaluating argument list element number 1
> error: evaluating prefix operator `!' near line 190, column 7
> error: if: error evaluating conditional expression
> error: evaluating if command near line 190, column 3
> error: called from `legend' in file
> `/usr/share/octave/2.1.60/site/m/octave-forge/plot/legend.m'
> error: near line 11 of file `/home/mcreel/mpi_work/mle/analyze.m'
> octave:1> analyze
> warning: in fopen near line 55, column 3:
> warning: fopen: default open mode is now binary
> octave:2>
>
>
> Note that the error only occurs the first time (?!). On the first run, the
> legend is not displayed properly. On the second run, the legend appears, but
> the line colors in the legend are different from those of the lines.
>
> Commenting out lines 190-192 of legend.m seems to solve the problem, but I'm
> not sure what those lines are intended to do, so I don't want to make a
> change in CVS myself.
>
> analyze.m and the data file are attached to allow replication. TIA, Michael
> # Created by Octave 2.1.57, Mon Nov 15 11:10:30 2004 EST <knoppix@Knoppix>
> # name: results
> # type: matrix
> # rows: 16
> # columns: 5
> 0 177.842718999833 34 177.842718999833 34
> 1 102.047008000314 34 80.9450099989772 28
> 2 74.6442850008607 34 76.3819399997592 37
> 3 60.9242219999433 34 51.8810830004513 31
> 4 52.3526020012796 34 44.7404210008681 31
> 5 47.1040069982409 34 39.3766609989107 30
> 6 43.8579909987748 34 33.3388470001519 27
> 7 42.2064960002899 34 33.983719997108 29
> 8 40.4449319988489 34 33.7770080007613 30
> 9 40.2781639993191 34 32.7890330031514 30
> 10 39.4343860000372 34 33.5620189979672 31
> 11 39.2160080000758 34 30.0757489986718 28
> 12 39.6577120013535 34 32.039197999984 30
> 13 39.4133560024202 34 30.1878300011158 28
> 14 40.2218270003796 34 32.7937540002167 30
> 15 40.0913539975882 34 33.1381429992616 30
> load Cluster-16_nodes-ML-NBSNP-results.out;
>
> m = max(results(:,4));
> axis([1,10,0,m]);
> plot(results(:,2));
> hold on;
> plot(results(:,4)./ results(:,5)*34);
> t = results(1,4) ./ (1:16)';
> plot(t);
>
> legend("Actual time", "Actual time (alt)","Lower limit",-1);
> legend("show");
> xlabel("number of nodes");
> ylabel("time");
> replot;
> print("mle_results.eps", "-depsc2");
>
|
|
From: Michael C. <mic...@ua...> - 2004-11-17 11:54:05
|
On Wednesday 17 November 2004 12:31, Michael Creel wrote: Hi again, I just wanted to point out another thing that seems funny - the counter does not move from octave:1> to octave:2> the first time analyze is run. What's up with that? > I've been having some problems with legend.m in the plot subdir. > > Running analyze.m (attached) gives the following: > > octave:1> analyze > error: invalid row index = 0 > error: evaluating argument list element number 1 > error: evaluating argument list element number 1 > error: evaluating prefix operator `!' near line 190, column 7 > error: if: error evaluating conditional expression > error: evaluating if command near line 190, column 3 > error: called from `legend' in file > `/usr/share/octave/2.1.60/site/m/octave-forge/plot/legend.m' > error: near line 11 of file `/home/mcreel/mpi_work/mle/analyze.m' > octave:1> analyze > warning: in fopen near line 55, column 3: > warning: fopen: default open mode is now binary > octave:2> > > |
|
From: Michael C. <mic...@ua...> - 2004-11-17 11:32:30
|
I've been having some problems with legend.m in the plot subdir. Running analyze.m (attached) gives the following: octave:1> analyze error: invalid row index = 0 error: evaluating argument list element number 1 error: evaluating argument list element number 1 error: evaluating prefix operator `!' near line 190, column 7 error: if: error evaluating conditional expression error: evaluating if command near line 190, column 3 error: called from `legend' in file `/usr/share/octave/2.1.60/site/m/octave-forge/plot/legend.m' error: near line 11 of file `/home/mcreel/mpi_work/mle/analyze.m' octave:1> analyze warning: in fopen near line 55, column 3: warning: fopen: default open mode is now binary octave:2> Note that the error only occurs the first time (?!). On the first run, the legend is not displayed properly. On the second run, the legend appears, but the line colors in the legend are different from those of the lines. Commenting out lines 190-192 of legend.m seems to solve the problem, but I'm not sure what those lines are intended to do, so I don't want to make a change in CVS myself. analyze.m and the data file are attached to allow replication. TIA, Michael |
|
From: Justus P. <Jus...@UL...> - 2004-11-08 17:09:52
|
> I tried this out here, and didn't see anything funny. OK, this makes me feel better because it's now obviously me who has a weird problem and not octave-forge that contains broken code. I'll get back to the list as soon as I have news. Thanks for your feedback. Justus --=20 Justus H. Piater, Ph.D. http://www.montefiore.ulg.ac.be/~piater/ Institut Montefiore, B28 Phone: +32-4-366-2279 Universit=E9 de Li=E8ge, Belgium Fax: +32-4-366-2620 |
|
From: Michael C. <mic...@ua...> - 2004-11-08 16:50:20
|
I tried this out here, and didn't see anything funny. I'm using 2.1.57 from
debian unstable with self-compiled octave forge CVS (updated last thursday or
friday). The attachment is the output of the last line here, 10 million
draws. If there is no resolution to this problem I can do formal testing for
normality and lack of serial correlation.
Michael
octave:1> hist(randn(1000000,1),50,1)
octave:2> hist(randn(1000000,1),100,1)
octave:3> hist(randn(1000000,1),1000,1)
octave:4> hist(randn(10000000,1),1000,1)
octave:5> print("randn.eps","-depsc2");
|
|
From: David B. <Dav...@mo...> - 2004-11-08 15:37:19
|
Dapr=E8s Justus Piater <Jus...@UL...> (le 08/11/2004):
> > I can't regenerate this problem with octave-forge CVS or with 2004.09=
.09.
> > I used the commands
> >
> > octave:1> hist(randn(1,1e6),-3.75:0.5:3.75)
> > octave:2> var(randn(1,1e6))
> > ans =3D 1.0001
> > octave:3> mean(randn(1,1e6))
> > ans =3D -4.9951e-04
>=20
> This does not give enough resolution to demonstrate the problem, nor
> does it visualize temporal dependencies. However, randn() from
> octave-forge-2004.09.09, does give me a wrong
I also tried your dots command and got a clean distribution.
> octave> randn("seed", 12345);
> octave> var(randn(1,1e6))
> ans =3D 0.71239
So you clearly have a real problem.
> I append printouts of the output of the following sequence of
> commands:
>=20
> octave> randn("seed", 12345);
> octave> plot(1:10000, randn(1, 10000), ".");
> octave> print("-depsc2", "randn-dots.eps");
> octave> randn("seed", 12345);
> octave> hist(randn(1,1e6),-3.75:0.001:3.75);
> octave> print("-depsc2", "randn-hist.eps");
>=20
> The second figure suggests that the output of randn() possibly
> converges to normal over very long sequences of random numbers (albeit
> with a wrong variance), but notice the ditch at zero that persists
> even after 6 million samples.
>=20
> The non-normality is revealed by the first figure that demonstrates
> that the samples are nowhere near Gaussian for sample sizes of at
> least up to several thousands, due to a strange sequential clustering
> effect.
>=20
> I also append the counterparts of these figures using the randn() from
> octave-2.1.57, which do not exhibit these problems (but, incidentally,
> there are strange tails in the histograms).
>=20
> > before doing your test and seed if it helps. It might also be a build
> > issue, so can you try with the "-DALLBITS" flag or without it and
> > see if it makes a difference if 32 or 64 bit ints are used.
>=20
> For info, my rand.cc from octave-forge/FIXES was compiled with
> -DALLBITS (the default). I don't have the time right now to
> investigate more deeply, but will later if nobody else can reproduce
> the problem.
I tried on my side with and without -DALLBITS and could not generate the
problem... So without confirmation I think the only way to resolve this i=
s
if you try to do it.. I'd suggest a first steps are to try with and witho=
ut
-DALLBITS and also to do the same style of tests on rand to see if it has
the same behaviour. This will allow confirmation of whether the problem
is in the ziggurat code that forms the normal distribution, or in the
underlying random integer (32- or 53-bit) generators.
Regards
David
--=20
David Bateman Dav...@mo...
Motorola CRM +33 1 69 35 48 04 (Ph)=20
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:=20
[x] General Business Information=20
[ ] Motorola Internal Use Only=20
[ ] Motorola Confidential Proprietary
|
|
From: Michael C. <mic...@ua...> - 2004-11-08 15:32:03
|
On Monday 08 November 2004 14:08, Justus Piater wrote:
> > I can't regenerate this problem with octave-forge CVS or with 2004.09.09.
> > I used the commands
> >
> > octave:1> hist(randn(1,1e6),-3.75:0.5:3.75)
> > octave:2> var(randn(1,1e6))
> > ans = 1.0001
> > octave:3> mean(randn(1,1e6))
> > ans = -4.9951e-04
>
> This does not give enough resolution to demonstrate the problem, nor
> does it visualize temporal dependencies. However, randn() from
> octave-forge-2004.09.09, does give me a wrong
>
> octave> randn("seed", 12345);
> octave> var(randn(1,1e6))
> ans = 0.71239
>
This works ok here (recent octave forge CVS)
octave:1> randn("seed",12345);
octave:2> var(randn(1,1e6))
ans = 0.99900
octave:3>
Also, I get proper plots, not like the ones you give that show temporal
dependency.
Michael
|
|
From: Justus P. <Jus...@UL...> - 2004-11-08 15:11:02
|
> I can't regenerate this problem with octave-forge CVS or with 2004.09.09.
> I used the commands
>
> octave:1> hist(randn(1,1e6),-3.75:0.5:3.75)
> octave:2> var(randn(1,1e6))
> ans =3D 1.0001
> octave:3> mean(randn(1,1e6))
> ans =3D -4.9951e-04
This does not give enough resolution to demonstrate the problem, nor
does it visualize temporal dependencies. However, randn() from
octave-forge-2004.09.09, does give me a wrong
octave> randn("seed", 12345);
octave> var(randn(1,1e6))
ans =3D 0.71239
I append printouts of the output of the following sequence of
commands:
octave> randn("seed", 12345);
octave> plot(1:10000, randn(1, 10000), ".");
octave> print("-depsc2", "randn-dots.eps");
octave> randn("seed", 12345);
octave> hist(randn(1,1e6),-3.75:0.001:3.75);
octave> print("-depsc2", "randn-hist.eps");
The second figure suggests that the output of randn() possibly
converges to normal over very long sequences of random numbers (albeit
with a wrong variance), but notice the ditch at zero that persists
even after 6 million samples.
The non-normality is revealed by the first figure that demonstrates
that the samples are nowhere near Gaussian for sample sizes of at
least up to several thousands, due to a strange sequential clustering
effect.
I also append the counterparts of these figures using the randn() from
octave-2.1.57, which do not exhibit these problems (but, incidentally,
there are strange tails in the histograms).
> before doing your test and seed if it helps. It might also be a build
> issue, so can you try with the "-DALLBITS" flag or without it and
> see if it makes a difference if 32 or 64 bit ints are used.
For info, my rand.cc from octave-forge/FIXES was compiled with
-DALLBITS (the default). I don't have the time right now to
investigate more deeply, but will later if nobody else can reproduce
the problem.
Justus
APPENDICES - Images as .eps and .eps.gz
Buggy results (octave-forge-2004.09.09):
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-dots.eps
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-dots.eps.gz
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-hist.eps
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-hist.eps.gz
Good results (octave-2.1.57):
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-dots-good.eps
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-dots-good.eps.gz
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-hist-good.eps
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-hist-good.eps.gz
--=20
Justus H. Piater, Ph.D. http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28 Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium Fax: +32-4-366-2620
|
|
From: David B. <Dav...@mo...> - 2004-11-08 11:27:28
|
I can't regenerate this problem with octave-forge CVS or with 2004.09.09.
I used the commands
octave:1> hist(randn(1,1e6),-3.75:0.5:3.75)
octave:2> var(randn(1,1e6))
ans =3D 1.0001
octave:3> mean(randn(1,1e6))
ans =3D -4.9951e-04
Which clearly showed a normal distribution and the correct mean and varianc=
e.
Maybe your problem is to do with the seeding of the generator, however it
this case you would also have a poor return from rand from octave-forge,
since they both use the same basic generator... Try running
randn("seed", 12345)
before doing your test and seed if it helps. It might also be a build
issue, so can you try with the "-DALLBITS" flag or without it and
see if it makes a difference if 32 or 64 bit ints are used.
It would be better if you can properly diagnose your problem, as the
randn generator in 2.1.57 is much shorter period than that from
octave-forge and is much slower, but equally is the report of the form
you sent does no one any good, and if it is a true bug others should
profit from your problems/solutions.
Regards
David
According to Justus Piater <Jus...@UL...> (on 11/08/04):
> Hi,
>=20
> randn() from octave-forge-2004.09.09 (CVS version 1.11) appears to be
> broken. The generated numbers are clearly not normally distributed:
> Numbers near zero (the most likely numbers) are extremely rare, and
> stretches of generated numbers appear to be sampled from different
> distributions that vary from some 10s to some 1000s of numbers in
> length.
>=20
> See for yourselves by issuing
>=20
> plot(1:10000, randn(1, 10000), ".");
>=20
> I have not tested later versions from CVS, but the CVS logs do not
> suggest that this has been fixed. For my purposes, I'm reverting back
> to the randn() from octave-2.1.57 whose output looks ok.
>=20
> Justus
>=20
> --=20
> Justus H. Piater, Ph.D. http://www.montefiore.ulg.ac.be/~piater/
> Institut Montefiore, B28 Phone: +32-4-366-2279
> Universit=E9 de Li=E8ge, Belgium Fax: +32-4-366-2620
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
--=20
David Bateman Dav...@mo...
Motorola CRM +33 1 69 35 48 04 (Ph)=20
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:=20
[x] General Business Information=20
[ ] Motorola Internal Use Only=20
[ ] Motorola Confidential Proprietary
|
|
From: Michael C. <mic...@ua...> - 2004-11-08 11:15:01
|
That would be serious if it were true, but I just tried it out and it looks ok to me, using randn from current CVS. Also try out hist(randn(10000,1),30,1); Are you sure you're interpreting the plot correctly? The x axis labels are just the indices of the 10000 random numbers. If you're sure your interpretation is correct, could you attach an image of the plot you see to a message? M. On Monday 08 November 2004 09:55, Justus Piater wrote: > Hi, > > randn() from octave-forge-2004.09.09 (CVS version 1.11) appears to be > broken. The generated numbers are clearly not normally distributed: > Numbers near zero (the most likely numbers) are extremely rare, and > stretches of generated numbers appear to be sampled from different > distributions that vary from some 10s to some 1000s of numbers in > length. > > See for yourselves by issuing > > plot(1:10000, randn(1, 10000), "."); > > I have not tested later versions from CVS, but the CVS logs do not > suggest that this has been fixed. For my purposes, I'm reverting back > to the randn() from octave-2.1.57 whose output looks ok. > > Justus |
|
From: Justus P. <Jus...@UL...> - 2004-11-08 09:55:32
|
Hi,
randn() from octave-forge-2004.09.09 (CVS version 1.11) appears to be
broken. The generated numbers are clearly not normally distributed:
Numbers near zero (the most likely numbers) are extremely rare, and
stretches of generated numbers appear to be sampled from different
distributions that vary from some 10s to some 1000s of numbers in
length.
See for yourselves by issuing
plot(1:10000, randn(1, 10000), ".");
I have not tested later versions from CVS, but the CVS logs do not
suggest that this has been fixed. For my purposes, I'm reverting back
to the randn() from octave-2.1.57 whose output looks ok.
Justus
--=20
Justus H. Piater, Ph.D. http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28 Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium Fax: +32-4-366-2620
|
|
From: Quentin S. <qsp...@ie...> - 2004-11-05 16:48:39
|
The following is a suggestion for anyone interested in a project. I may eventually try to do this myself, but I thought I would mention it here in case someone else has an interest in it. In MATLAB 7, the filter design function remez has been deprecated in favor of a function called "firpm" (the letters PM meaning Parks-McLellan). In addition, a new filter function has been added called "firls", which uses a least-squares design approach. The functions firpm and firls use similar calling conventions to the old remez function. I think it would make sense to eventually move "remez" to "firpm", with perhaps a remez.m script that calls firpm (this is what appears to happen in MATLAB 7). I have found the firls function to be quite useful, for reasons described below. Writing the code for the firls function could be a bit of a project. I have found a pretty decent description of how it works at http://cnx.rice.edu/content/m10577/latest/ . It appears to me that unlike the Parks-McLellan algorithm, this approach is non-iterative, so I think it could be reasonable fast written as an m file. While these filters do not satisfy the equiripple constraint of the Parks-McLellan approach, there are situations in which they can be desirable. One case is where the specifications make it difficult for the Parks-McLellan algorithm to converge. In my experience least squares filters tend to achieve a better average stop band attenuation for the same filter length than their equiripple Parks-McLellan counterparts, which makes them desirable in situations where exactly meeting a certain ripple level is not critical. regards, Quentin |
|
From: Ole J. H. <wat...@ya...> - 2004-10-29 11:09:00
|
Hi. I have been struggling with NSIS, Cygwin and Windows lately, but have now made a stand alone installation package for octave-2.1.60, included octave-forge (CVS -version), some cygwin libraries, and support for gnuplot (windows version). You don't need Cygwin to run Octave, since the run-time libraries are included. ;-) Remember that there are no atlas or blas included here. It's purely Octave code. I compiled octave and octave-forge with gcc-3.3.3, and benchmarked my octave according to the benchmark suites found in http://www.sciviews.org/other/benchmark.htm. Thanks to D. Bateman, I could run the complete test. ;-) Attaches the gcd2.m file, that are required to finish point 3.C of the benchmark test. Take a look at the results from the bench-test. m-files are slow, but some oct-files are pretty acceptable. How does this compare with the Linux system? Could it be an advantage, if I compiled octave with gcc-3.2.2 instead? Could someone compare with gcc-3.2.2? I am having some hacking left to do, but when this is ready, I'll will make the stand-alone Octave available at sourceforge or octave.org. If you are really in a dead or alive situation with Octave on Windows, then send me an email. I will then give you access to my ftp, as fast as I can. ;-) Cheers, Ole J. And my results are: octave-2.1.60:8> benchmark Octave Benchmark 2 ================== Number of times each test is run__________________________: 3 I. Matrix calculation --------------------- Creation, transp., deformation of a 1500x1500 matrix (sec): 1.093 800x800 normal distributed random matrix ^1000______ (sec): 0.899 Sorting of 2,000,000 random values__________________ (sec): 1.34 700x700 cross-product matrix (b = a' * a)___________ (sec): 4.224 Linear regression over a 600x600 matrix (c = a \ b') (sec): 0.9883 ------------------------------------------------------ Trimmed geom. mean (2 extremes eliminated): 1.131 II. Matrix functions -------------------- FFT over 800,000 random values______________________ (sec): 0.9717 Eigenvalues of a 320x320 random matrix______________ (sec): 1.215 Determinant of a 650x650 random matrix______________ (sec): 1.166 Cholesky decomposition of a 900x900 matrix__________ (sec): 0.6697 Inverse of a 400x400 random matrix__________________ (sec): 0.9513 ------------------------------------------------------ Trimmed geom. mean (2 extremes eliminated): 1.025 III. Programmation ------------------ 750,000 Fibonacci numbers calculation (vector calc)_ (sec): 1.726 Creation of a 2250x2250 Hilbert matrix (matrix calc) (sec): 0.8423 Grand common divisors of 70,000 pairs (recursion)___ (sec): 3.229 Creation of a 220x220 Toeplitz matrix (loops)_______ (sec): 38.49 Escoufier's method on a 37x37 matrix (mixed)________ (sec): 26.15 ------------------------------------------------------ Trimmed geom. mean (2 extremes eliminated): 5.263 Total time for all 15 tests_________________________ (sec): 83.96 Overall mean (sum of I, II and III trimmed means/3)_ (sec): 1.828 --- End of test --- |
|
From: Ole J. H. <wat...@ya...> - 2004-10-29 11:08:50
|
Hi. I have been struggling with NSIS, Cygwin and Windows lately, but have now made a stand alone installation package for octave-2.1.60, included octave-forge (CVS -version), some cygwin libraries, and support for gnuplot (windows version). You don't need Cygwin to run Octave, since the run-time libraries are included. ;-) Remember that there are no atlas or blas included here. It's purely Octave code. I compiled octave and octave-forge with gcc-3.3.3, and benchmarked my octave according to the benchmark suites found in http://www.sciviews.org/other/benchmark.htm. Thanks to D. Bateman, I could run the complete test. ;-) Attaches the gcd2.m file, that are required to finish point 3.C of the benchmark test. Take a look at the results from the bench-test. m-files are slow, but some oct-files are pretty acceptable. How does this compare with the Linux system? Could it be an advantage, if I compiled octave with gcc-3.2.2 instead? Could someone compare with gcc-3.2.2? I am having some hacking left to do, but when this is ready, I'll will make the stand-alone Octave available at sourceforge or octave.org. If you are really in a dead or alive situation with Octave on Windows, then send me an email. I will then give you access to my ftp, as fast as I can. ;-) Cheers, Ole J. And my results are: octave-2.1.60:8> benchmark Octave Benchmark 2 ================== Number of times each test is run__________________________: 3 I. Matrix calculation --------------------- Creation, transp., deformation of a 1500x1500 matrix (sec): 1.093 800x800 normal distributed random matrix ^1000______ (sec): 0.899 Sorting of 2,000,000 random values__________________ (sec): 1.34 700x700 cross-product matrix (b = a' * a)___________ (sec): 4.224 Linear regression over a 600x600 matrix (c = a \ b') (sec): 0.9883 ------------------------------------------------------ Trimmed geom. mean (2 extremes eliminated): 1.131 II. Matrix functions -------------------- FFT over 800,000 random values______________________ (sec): 0.9717 Eigenvalues of a 320x320 random matrix______________ (sec): 1.215 Determinant of a 650x650 random matrix______________ (sec): 1.166 Cholesky decomposition of a 900x900 matrix__________ (sec): 0.6697 Inverse of a 400x400 random matrix__________________ (sec): 0.9513 ------------------------------------------------------ Trimmed geom. mean (2 extremes eliminated): 1.025 III. Programmation ------------------ 750,000 Fibonacci numbers calculation (vector calc)_ (sec): 1.726 Creation of a 2250x2250 Hilbert matrix (matrix calc) (sec): 0.8423 Grand common divisors of 70,000 pairs (recursion)___ (sec): 3.229 Creation of a 220x220 Toeplitz matrix (loops)_______ (sec): 38.49 Escoufier's method on a 37x37 matrix (mixed)________ (sec): 26.15 ------------------------------------------------------ Trimmed geom. mean (2 extremes eliminated): 5.263 Total time for all 15 tests_________________________ (sec): 83.96 Overall mean (sum of I, II and III trimmed means/3)_ (sec): 1.828 --- End of test --- |
|
From: David B. <Dav...@mo...> - 2004-10-29 07:49:56
|
gcd2.m was delivered with this benchmark. I attach a copy here. D. According to Ole Jacob Hagen <wat...@ya...> (on 10/29/04): > Hi, again. > > Do you have some suggestions how to override or remove the warnings I am > getting? > That would be terrific. > > > Cheers, > > Ole J. > > A benchmark test, with my Octave, compiled with gcc-3.3.3... > Fails in the rest, since we have no gcd2....can I use gcd? > > > I. Matrix calculation > > --------------------- > > > >Creation, transp., deformation of a 1500x1500 matrix (sec): 1.008 > >800x800 normal distributed random matrix ^1000______ (sec): 0.8307 > >Sorting of 2,000,000 random values__________________ (sec): 1.291 > >700x700 cross-product matrix (b = a' * a)___________ (sec): 4.181 > >Linear regression over a 600x600 matrix (c = a \ b') (sec): 0.9707 > > ------------------------------------------------------ > >FFT over 800,000 random values______________________ (sec): 0.9987 > >Eigenvalues of a 320x320 random matrix______________ (sec): 1.196 > >Determinant of a 650x650 random matrix______________ (sec): 1.216 > >Cholesky decomposition of a 900x900 matrix__________ (sec): 0.6573 > >Inverse of a 400x400 random matrix__________________ (sec): 0.8017 > > ------------------------------------------------------ > > Trimmed geom. mean (2 extremes eliminated): 0.9855 > > > > III. Programmation > > ------------------ > >750,000 Fibonacci numbers calculation (vector calc)_ (sec): 1.772 > >Creation of a 2250x2250 Hilbert matrix (matrix calc) (sec): 1.078 > > > > > > > ------------------------------------------------------- > This Newsletter Sponsored by: Macrovision > For reliable Linux application installations, use the industry's leading > setup authoring tool, InstallShield X. Learn more and evaluate > today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Stefan v. d. W. <st...@su...> - 2004-10-29 06:43:00
|
Gnuplot allows the user to zoom in and out of a graph. This, however, only works while gnuplot is active. I.e.: $ gnuplot -persist gnuplot> plot(sin(x))/x I can zoom around happily. gnuplot> exit No more zooming. I guess fixing it will require quite a few changes to gnuplot. gzoom works but requires the calculation of the axes prior to zooming. An easyish-to-implement feature that gnuplot sorely misses is plot-handles, i.e. a way to refer to a graph already drawn. Is there anyone here with links to the gnuplot community that can make a few suggestions to them? Regards Stefan |
541 messages has been excluded from this view by a project administrator.
