octave-dev — GNU Octave developers' list

Re: [OctDev] Octave-forge packaging

[Rafael L. <ra...@la...>]

* Dmitri A. Sergatskov <das...@gm...> [2005-04-23 00:05]:

> I do not use gpc (at least directly -- may be it is used by some
> package), but I do not understand why it is in nonfree/ directory.
> The license says:
> 
> <<<<
> 
> Copyright information:
> 
> Copyright (C) 2001, 2004  Rafael Laboissiere <ra...@la...>
> 
> [...]
> 
> Looks quite GNUish to me.

Indeed, octave-gpc is released under the GNU GPL.  However, octave-gpc
links against the General Polygon Clipping Library
(http://www.cs.man.ac.uk/aig/staff/alan/software/gpc.html), which has a
non-free license.  I already approached the upstream author several times
asking him to change the license terms, but he is not willing to do it.

I packaged the GPC library for Debian.  You can find it at:

    http://packages.debian.org/src:gpcl

-- 
Rafael

Re: [OctDev] Octave-forge packaging

[Dmitri A. S. <das...@gm...>]

Quentin Spencer wrote:
...
> anyone out there tell me how this is done for Debian? Furthermore, I 
> wonder if it wouldn't be better to make the nonfree part a separate 
> package or remove it from octave-forge--does anyone even use it?
> 

I like csaps (from nonfree/splines/). The only non-free file there
is gcvsplf.f (taken from netlib). I could not find any license info
on netlib, but octave-forge has  LICENSE.gcvsplf which pretty much
prohibits commercial use of the software (not commercial distribution,
as far as I can tell -- IANAL).

I do not use gpc (at least directly -- may be it is used by some
package), but I do not understand why it is in nonfree/ directory.
The license says:

<<<<

Copyright information:

Copyright (C) 2001, 2004  Rafael Laboissiere <ra...@la...>

    Permission is granted to anyone to make or distribute verbatim copies
    of this document as received, in any medium, provided that the
    copyright notice and this permission notice are preserved,
    thus giving the recipient permission to redistribute in turn.

    Permission is granted to distribute modified versions
    of this document, or of portions of it,
    under the above conditions, provided also that they
    carry prominent notices stating who last changed them.

 >>>>

Looks quite GNUish to me.

> -Quentin
> 

Dmitri.
-- 

[OctDev] Octave-forge packaging

[Quentin S. <qsp...@ie...>]

I've been packaging octave-forge RPMs for a while and I'm currently in 
the process of getting it into Fedora Extras. In the review process, 
someone pointed out the presence of the nonfree code in the source, 
which may make it ineligible for distribution with Fedora. I'm not 
compiling or including the nonfree software with the binaries, but I'm 
not yet sure if its presence in the source is a problem or not. Can 
anyone out there tell me how this is done for Debian? Furthermore, I 
wonder if it wouldn't be better to make the nonfree part a separate 
package or remove it from octave-forge--does anyone even use it?

-Quentin

Re: [OctDev] xmltree_read problem

[Laurent M. <ma...@cr...>]

On Thu, 21 Apr 2005 17:34:37 -0600
"Dmitri A. Sergatskov" <das...@gm...> wrote:

> Dmitri A. Sergatskov wrote:
> > With 2005.04.21 snapshot:
> >=20
> > [dima@tumbleweed miscellaneous]$ make all
> > mkoctfile -DHAVE_OCTAVE_29 -v -DUSE_TERM -DHAVE_TERMCAP_H -c xmltree_re=
ad.c
> > gcc4 -c -fPIC -I/usr/local/include/octave-2.9.1=20
> > -I/usr/local/include/octave-2.9.1/octave -I/usr/local/include -mieee-fp=
=20
> > -O3 -march=3Dathlon-mp -pipe -DHAVE_OCTAVE_29 -DUSE_TERM -DHAVE_TERMCAP=
_H=20
> > xmltree_read.c -o xmltree_read.o
> > xmltree_read.act: In function ___read_xmltree___:
> > xmltree_read.act:353: error: ___xml_in___ undeclared (first use in this=
=20
> > function)
> > xmltree_read.act:353: error: (Each undeclared identifier is reported=20
> > only once
> > xmltree_read.act:353: error: for each function it appears in.)
> > make: *** [xmltree_read.o] Error 1
> >=20
>=20
> Apparently the same problem as
>=20
> http://www.octave.org/octave-lists/archive/help-octave.2004/msg01327.html
>=20
> i.e. touching xmltree_read.c prior to build solves the problem
>=20
> Are there any reason we would want to rebuild xmltree_read.c from
> xmltree_read.l?

I don't think so. XML function are based on fleXML which is not supported s=
ince
4 years. Thoses functions have to be re-implemented to rely on libxml... I =
hope
to find some spare times to do it :-)

         Laurent
--=20
Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de MOTOROLA
Tel: +33 (0)1 69 35 48 30 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Email=
: ma...@cr...

Re: [OctDev] xmltree_read problem

[Dmitri A. S. <das...@gm...>]

Dmitri A. Sergatskov wrote:
> With 2005.04.21 snapshot:
> 
> [dima@tumbleweed miscellaneous]$ make all
> mkoctfile -DHAVE_OCTAVE_29 -v -DUSE_TERM -DHAVE_TERMCAP_H -c xmltree_read.c
> gcc4 -c -fPIC -I/usr/local/include/octave-2.9.1 
> -I/usr/local/include/octave-2.9.1/octave -I/usr/local/include -mieee-fp 
> -O3 -march=athlon-mp -pipe -DHAVE_OCTAVE_29 -DUSE_TERM -DHAVE_TERMCAP_H 
> xmltree_read.c -o xmltree_read.o
> xmltree_read.act: In function ‘read_xmltree’:
> xmltree_read.act:353: error: ‘xml_in’ undeclared (first use in this 
> function)
> xmltree_read.act:353: error: (Each undeclared identifier is reported 
> only once
> xmltree_read.act:353: error: for each function it appears in.)
> make: *** [xmltree_read.o] Error 1
> 

Apparently the same problem as

http://www.octave.org/octave-lists/archive/help-octave.2004/msg01327.html

i.e. touching xmltree_read.c prior to build solves the problem

Are there any reason we would want to rebuild xmltree_read.c from
xmltree_read.l?

Dmitri.
-- 

[OctDev] xmltree_read problem

[Dmitri A. S. <das...@gm...>]

With 2005.04.21 snapshot:

[dima@tumbleweed miscellaneous]$ make all
mkoctfile -DHAVE_OCTAVE_29 -v -DUSE_TERM -DHAVE_TERMCAP_H -c xmltree_read.c
gcc4 -c -fPIC -I/usr/local/include/octave-2.9.1 -I/usr/local/include/octave-2.9.1/octave -I/usr/local/include -mieee-fp -O3 -march=athlon-mp -pipe -DHAVE_OCTAVE_29 
-DUSE_TERM -DHAVE_TERMCAP_H xmltree_read.c -o xmltree_read.o
xmltree_read.act: In function ‘read_xmltree’:
xmltree_read.act:353: error: ‘xml_in’ undeclared (first use in this function)
xmltree_read.act:353: error: (Each undeclared identifier is reported only once
xmltree_read.act:353: error: for each function it appears in.)
make: *** [xmltree_read.o] Error 1

Dmitri.
-- 

[OctDev] Re: Where is __gnuplot_replot__ ?

[Quentin S. <qsp...@ie...>]

Dmitri A. Sergatskov wrote:

> Joe Koski wrote:
>
>> As an attempt to remove the annoying warnings about gset and graw 
>> from my
>> output, I tried rewriting print.m using only __gnuplot_raw__ with a 
>> string
>
> ...
>
> I did conversion for all plot functions in octave-forge.
> In
> ftp://coffee.phys.unm.edu/pub/dima/octave/octave-forge-2005.04.18-plot.diff.bz2 
>
> ...

Thank you Dmitri for doing this work. Because these changes break 
backward compatibility, I was hesitant to check these into CVS without 
consensus of the other octave-forge developers, but no objections have 
been raised since I brought this up previously on the list, so I have 
taken the liberty of checking in all of the changes. I think we are due 
for a new octave-forge release some time because the old one is, well, 
old. However, there are still some other functions in other directories 
that should be converted to the new gnuplot syntax before then.

-Quentin

[OctDev] plot functions with new gnuplot interface

[Dmitri A. S. <das...@gm...>]

I made a new diff for plot functions for
octave-forge/main/plot
The diff is against CVS snapshot 2005-04-18

In ftp://coffee.phys.unm.edu/pub/dima/octave/

The diff
octave-forge-2005.04.18-plot.diff.bz2

Tar of the entire plot/ directory:
octave-forge-2005.04.18-plot.tar.bz2

I did some light testing against octave-2.9.1.
I think both fill.m and fill3.m has been and are still broken.
Otherwise "It works for Me" (TM).

Sincerely,

Dmitri.
-- 


   	

[OctDev] Re: Legend.m (Was: Alternative to gset nokey;)

[Dmitri A. S. <das...@gm...>]

Quentin Spencer wrote:
> Dmitri A. Sergatskov wrote:
> 
>> Please find attached a version of legend.m modified to
>> use new __gnuplot_... interface.
>> Also attached is the diff against current (2005-04-15)
>> version from cvs.
> 
> 
> I could check this into CVS, but this will break backward compatibility 
> with older versions of octave. Are we willing to do that? Do we want to 
> branch the CVS as has been done with octave? There are a lot of 
> functions in octave-forge that need this kind of work ("grep -r gset *" 
> returns a list too long to count, though I'm sure legend is by far the 
> most widely used function affected by this).
> 

I have changed some time ago all octave-forge plot utils to use new
interface. The diff is at:

  ftp://coffee.phys.unm.edu/pub/dima/octave/plot.diff.bz2

There are few problems with the diff (in particular with legend.m,
that is why I posted this update). I am am about to do an updated
diff (in particular I am changing __gnuplot_set__ to __gnuplot_raw__
wherever it possible), but the existing one is reasonable already.

Dmitri.
-- 

[OctDev] Re: Legend.m (Was: Alternative to gset nokey;)

[Quentin S. <qsp...@ie...>]

Dmitri A. Sergatskov wrote:

> Please find attached a version of legend.m modified to
> use new __gnuplot_... interface.
> Also attached is the diff against current (2005-04-15)
> version from cvs.

I could check this into CVS, but this will break backward compatibility 
with older versions of octave. Are we willing to do that? Do we want to 
branch the CVS as has been done with octave? There are a lot of 
functions in octave-forge that need this kind of work ("grep -r gset *" 
returns a list too long to count, though I'm sure legend is by far the 
most widely used function affected by this).

Re: [OctDev] pcre.h not found

[Dmitri A. S. <das...@gm...>]

Stefan van der Walt wrote:
> On Wed, Apr 13, 2005 at 03:16:47PM -0600, Dmitri A. Sergatskov wrote:
> 
...
>>
>>But it also means that actual source files should also have ugliness like
>>
>>#ifdef __HAVE_PCRE__
>>	#include <pcre.h>
>>#elsif __HAVE_PCRE_PCRE__
>>	#include <pcre/pcre.h>
> 
> 
> This shouldn't be necessary if we specify -I/usr/lib/pcre
> 

Right you are.

> Regards
> Stefan
> 

Dmitri.
-- 

Re: [OctDev] pcre.h not found

[Stefan v. d. W. <st...@su...>]

On Wed, Apr 13, 2005 at 03:16:47PM -0600, Dmitri A. Sergatskov wrote:
> Stefan van der Walt wrote:
> 
> >
> >I think that Debian (and some other distros) modify the path to
> >pcre.h.  I notice now that there is a `pcre-config' available.  Maybe
> >we should rather use that to determine compiler flags.
> >
> 
> Yes we can use that:
> 
> [dima@localhost ~]$ pcre-config --cflags
> -I/usr/include/pcre
> 
> But it also means that actual source files should also have ugliness like
> 
> #ifdef __HAVE_PCRE__
> 	#include <pcre.h>
> #elsif __HAVE_PCRE_PCRE__
> 	#include <pcre/pcre.h>

This shouldn't be necessary if we specify -I/usr/lib/pcre

Regards
Stefan

Re: [OctDev] pcre.h not found

[Dmitri A. S. <das...@gm...>]

Stefan van der Walt wrote:

> 
> I think that Debian (and some other distros) modify the path to
> pcre.h.  I notice now that there is a `pcre-config' available.  Maybe
> we should rather use that to determine compiler flags.
> 

Yes we can use that:

[dima@localhost ~]$ pcre-config --cflags
-I/usr/include/pcre

But it also means that actual source files should also have ugliness like

#ifdef __HAVE_PCRE__
	#include <pcre.h>
#elsif __HAVE_PCRE_PCRE__
	#include <pcre/pcre.h>

...

It also appears that RH is switching back to normal location
(at least pcre package from development tree has headers 
in /usr/include). So may be we just leave it as it is, perhaps
add a warning that pcre.h should be symlinked to a standard
location?

> Regards
> Stefan
> 

Dmitri.
-- 

Re: [OctDev] pcre.h not found

[Stefan v. d. W. <st...@su...>]

Attached is a much simpler patch that should resolve the situation,
irrespective of any shuffling done by distros.

I think it is safe to assume that pcre.h is present if pcre-config is?
Otherwise we can explicitly check, using the output from

`pcre-config --cflags`

Regards
Stefan

On Wed, Apr 13, 2005 at 10:52:06PM +0200, Stefan van der Walt wrote:
> On Wed, Apr 13, 2005 at 08:33:22AM -0600, Dmitri A. Sergatskov wrote:
> > On 4/13/05, Stefan van der Walt <st...@su...> wrote:
> > > How about the following patch, as well as renaming pcregexp.cc to
> > > pcregexp.cc.in and doing a variable substitution:
> > > 
> > ...
> > 
> > At this moment I am not even sure that this is not a bug with the pcre-devel
> > package. Perhaps, they should have made a symlink
> > pcre.h -> pcre/pcre.h ?
> 
> I think that Debian (and some other distros) modify the path to
> pcre.h.  I notice now that there is a `pcre-config' available.  Maybe
> we should rather use that to determine compiler flags.
> 
> Regards
> Stefan
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] pcre.h not found

[Stefan v. d. W. <st...@su...>]

On Wed, Apr 13, 2005 at 08:33:22AM -0600, Dmitri A. Sergatskov wrote:
> On 4/13/05, Stefan van der Walt <st...@su...> wrote:
> > How about the following patch, as well as renaming pcregexp.cc to
> > pcregexp.cc.in and doing a variable substitution:
> > 
> ...
> 
> At this moment I am not even sure that this is not a bug with the pcre-devel
> package. Perhaps, they should have made a symlink
> pcre.h -> pcre/pcre.h ?

I think that Debian (and some other distros) modify the path to
pcre.h.  I notice now that there is a `pcre-config' available.  Maybe
we should rather use that to determine compiler flags.

Regards
Stefan

Re: [OctDev] pcre.h not found

[Dmitri A. S. <das...@gm...>]

On 4/13/05, Stefan van der Walt <st...@su...> wrote:
> How about the following patch, as well as renaming pcregexp.cc to
> pcregexp.cc.in and doing a variable substitution:
>=20
...

At this moment I am not even sure that this is not a bug with the pcre-deve=
l
package. Perhaps, they should have made a symlink
pcre.h -> pcre/pcre.h ?

Sincerely,
Dmitri.
--

Re: [OctDev] pcre.h not found

[Stefan v. d. W. <st...@su...>]

How about the following patch, as well as renaming pcregexp.cc to
pcregexp.cc.in and doing a variable substitution:

#include <@PCRE_H@>

If you think this will do the job I can apply the patch.

It's a pity we arn't use subversion: svn move instead of delete (lose
history), rename, commit.

Regards
Stefan

Index: configure.add
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/octave/octave-forge/main/strings/configure.add,v
retrieving revision 1.2
diff -u -r1.2 configure.add
--- configure.add       1 Mar 2005 16:33:33 -0000       1.2
+++ configure.add       13 Apr 2005 12:57:00 -0000
@@ -5,7 +5,13 @@
 else

     AC_SUBST(HAVE_PCRE)
-    AC_CHECK_HEADER(pcre.h, HAVE_PCRE=3Dyes, HAVE_PCRE=3Dno)
+    AC_SUBST(PCRE_H)
+
+    AC_CHECK_HEADER(pcre.h, [HAVE_PCRE=3Dyes;PCRE_H=3Dpcre.h], HAVE_PCRE=
=3Dno)
+    if test $HAVE_PCRE =3D no ; then
+        AC_CHECK_HEADER(pcre/pcre.h, [HAVE_PCRE=3Dyes;PCRE_H=3Dpcre/pcre.h=
], HAVE_PCRE=3Dno)
+    fi
+
     if test $HAVE_PCRE =3D yes ; then
        OF_CHECK_LIB(pcre, pcre_compile, HAVE_PCRE=3Dyes, HAVE_PCRE=3Dno)
        if test $HAVE_PCRE =3D no ; then
@@ -16,7 +22,8 @@
     else
        STATUS=3D"pcre.h not found"
     fi
-
+
+    AC_OUTPUT(main/strings/pcregexp.cc)
 fi

 STATUS_MSG=3D"$STATUS_MSG


On Wed, Apr 13, 2005 at 07:35:14AM -0400, Paul Kienzle wrote:
> The spelling error is in:
>=20
> 	main/strings/configure.add
>=20
> I don't know what the proper solution to pcre/pcre.h
> is off hand.
>=20
> - Paul
>=20
> On Apr 13, 2005, at 3:09 AM, Dmitri A. Sergatskov wrote:
>=20
> >using 2005.04.12 cvs snapshot.
> >
> >./configure reports
> >
> >...
> >
> >Perl compatible regular expresions: pcre.h not found
> >                                   ^^^^^^^^^^^^(sic!)
> >
> >pcre.h is in /usr/include/pcre/pcre.h
> >
> >Configure apparently checks for <pcre.h> (and not for <pcre/pcre.h>) .
> >I do not know what is really broken here, and what is the
> >proper way of fixing it. (I also cannot figure out
> >where did "expresions" is coming from, may be this is an autoconf
> >typo.)
> >
> >Sincerely,
> >
> >Dmitri.
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] pcre.h not found

[Paul K. <pki...@us...>]

The spelling error is in:

	main/strings/configure.add

I don't know what the proper solution to pcre/pcre.h
is off hand.

- Paul

On Apr 13, 2005, at 3:09 AM, Dmitri A. Sergatskov wrote:

> using 2005.04.12 cvs snapshot.
>
> ./configure reports
>
> ...
>
> Perl compatible regular expresions: pcre.h not found
>                                    ^^^^^^^^^^^^(sic!)
>
> pcre.h is in /usr/include/pcre/pcre.h
>
> Configure apparently checks for <pcre.h> (and not for <pcre/pcre.h>) .
> I do not know what is really broken here, and what is the
> proper way of fixing it. (I also cannot figure out
> where did "expresions" is coming from, may be this is an autoconf
> typo.)
>
> Sincerely,
>
> Dmitri.
> --
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] pcre.h not found

[Dmitri A. S. <das...@gm...>]

using 2005.04.12 cvs snapshot.

./configure reports

...

Perl compatible regular expresions: pcre.h not found
                                   ^^^^^^^^^^^^(sic!)

pcre.h is in /usr/include/pcre/pcre.h

Configure apparently checks for <pcre.h> (and not for <pcre/pcre.h>) .=20
I do not know what is really broken here, and what is the
proper way of fixing it. (I also cannot figure out
where did "expresions" is coming from, may be this is an autoconf=20
typo.)

Sincerely,

Dmitri.
--

Re: [OctDev] random numbers for distributed computations

[Michael C. <mic...@ua...>]

One last note, the reference
 http://www.cosc.canterbury.ac.nz/research/reports/TechReps/2005/tr_0503.pdf
leads me to believe that the method used by the octave-forge rand.cc is 
reliable. Thanks to everyone for the information, Michael

Re: [OctDev] random numbers for distributed computations

[Francesco P. <Po...@is...>]

>OK, you're saying that a generator with period 5 could produce values like
>1 2 2 1 2 *** 1 2 2 1 2 *** 1 2 2 1 2
>so the set of unique values is smaller than the period, correct?

Generally speaking, yes.  For Octave, yes.

>This may be, but for the moment my main question is whether the set of unique 
>values that is generated depends upon the initial seed

No, the set is always the same.

>						       , or whether it's just 
>the starting point in the sequence that depends on the initial seed.

Yes, that's it.

-- 
Francesco Potortì (ricercatore)        Voice: +39 050 315 3058 (op.2111)
ISTI - Area della ricerca CNR          Fax:   +39 050 313 8091
via G. Moruzzi 1, I-56124 Pisa         Email: Po...@is...
Web: http://fly.isti.cnr.it/           Key:   fly.isti.cnr.it/public.key

Re: [OctDev] random numbers for distributed computations

[Michael C. <mic...@ua...>]

On Monday 11 April 2005 13:14, David Bateman wrote:
> Michael Creel wrote:
> >On Monday 11 April 2005 11:57, Francesco Potorti` wrote:
> >>>I have a question about this. If a RNG has a period of X, that means
> >>> that there are X unique values that are generated, and then the
> >>> sequence repeats.
> >>
> >>No, it means that the sequence repeats after X values are produced.  The
> >>period length says nothing about the space of values.  However, for good
> >>general purpose generators, the size of the space of values is much
> >>smaller than the period.
> >
> >OK, you're saying that a generator with period 5 could produce values like
> >1 2 2 1 2 *** 1 2 2 1 2 *** 1 2 2 1 2
> >so the set of unique values is smaller than the period, correct?
> >
> >This may be, but for the moment my main question is whether the set of
> > unique values that is generated depends upon the initial seed, or whether
> > it's just the starting point in the sequence that depends on the initial
> > seed. Could the unique values be 3 and 4, say, or will they always be 1
> > and 2? M.
>
> The octave-forge generators are based on the Mersenne Twister, and it
> doesn't have a seed but rather a state of 32 values. So the unique
> starting points are defined from this state vector.. The period of the
> Mersenne Twister is 2^19937-1, so I wouldn''t worry about it repeating
> itself in yours or my lifetimes.
>
> Regards
> David

Well, the issue of how the starting values are chosen is potentially 
important. See this paper for reference:
http://w3.tmit.bme.hu/~vidacs/education/simulation_techniques/sim_papers/01_01_hechenleitner-ips2003.pdf

However, on page 8, there is a test of the Mersenne Twister, and the results 
indicate that using a random starting points on each node will very likely 
give independent streams on a cluster, due to the astronomical period of the 
MT. But with a shorter period, there would be trouble. But at any rate, I 
convinced that this is a non-issue, at least on my platform of choice. 
Thanks, Michael

[OctDev] Repeating same sequence of rand/randn between octave/matlab

[David B. <Dav...@mo...>]

I was recently required to reproduce the same sequence of random numbers 
in octave and matlab to demonstrate bit accurate simulation between two 
versions of the same simulator (one under octave and the other under 
matlab). My means of doing this was to replace the matlab rand/randn 
functions with ones based on the code from octave-forge. I attach the 
mexFunction to allow this to this message in case others find themselves 
in the same position.

There are a couple of points to note.

1) You must obtain randmtzig.c from octave-forge
2) The compile flag will be dependent on the machine but to compile the 
code for matlab under x86 linux I used
     "mex -O -DEXPORT -DALLBITS -DUSE_X86_32=1 rand.c"
3) The mexFunction should either be copied or symbolically linked to 
randn mexFunction (under linux randn.mexglx)
4) The octave-forge versions of rand.oct and rand.oct must NOT be a 
symbolic link from one to the other. This ensures that
    the two random function use separate instantiations of the Mersenne 
Twister. This is not the case for a standard install
   of octave-forge and so again rand.oct and randn.oct should be copied.
5) Both rand and randn must be seeded separately at the start of the 
simulation since they use seperate instantiations of
    the Mersenne Twister

Enjoy
David

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +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

Re: [OctDev] random numbers for distributed computations

[David B. <Dav...@mo...>]

Michael Creel wrote:

>On Monday 11 April 2005 11:57, Francesco Potorti` wrote:
>  
>
>>>I have a question about this. If a RNG has a period of X, that means that
>>>there are X unique values that are generated, and then the sequence
>>>repeats.
>>>      
>>>
>>No, it means that the sequence repeats after X values are produced.  The
>>period length says nothing about the space of values.  However, for good
>>general purpose generators, the size of the space of values is much
>>smaller than the period.
>>    
>>
>
>OK, you're saying that a generator with period 5 could produce values like
>1 2 2 1 2 *** 1 2 2 1 2 *** 1 2 2 1 2
>so the set of unique values is smaller than the period, correct?
>
>This may be, but for the moment my main question is whether the set of unique 
>values that is generated depends upon the initial seed, or whether it's just 
>the starting point in the sequence that depends on the initial seed. Could 
>the unique values be 3 and 4, say, or will they always be 1 and 2?
>M.
>
>  
>

The octave-forge generators are based on the Mersenne Twister, and it 
doesn't have a seed but rather a state of 32 values. So the unique 
starting points are defined from this state vector.. The period of the 
Mersenne Twister is 2^19937-1, so I wouldn''t worry about it repeating 
itself in yours or my lifetimes.

Regards
David

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +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

Re: [OctDev] random numbers for distributed computations

[Michael C. <mic...@ua...>]

On Monday 11 April 2005 11:57, Francesco Potorti` wrote:
> >I have a question about this. If a RNG has a period of X, that means that
> >there are X unique values that are generated, and then the sequence
> > repeats.
>
> No, it means that the sequence repeats after X values are produced.  The
> period length says nothing about the space of values.  However, for good
> general purpose generators, the size of the space of values is much
> smaller than the period.

OK, you're saying that a generator with period 5 could produce values like
1 2 2 1 2 *** 1 2 2 1 2 *** 1 2 2 1 2
so the set of unique values is smaller than the period, correct?

This may be, but for the moment my main question is whether the set of unique 
values that is generated depends upon the initial seed, or whether it's just 
the starting point in the sequence that depends on the initial seed. Could 
the unique values be 3 and 4, say, or will they always be 1 and 2?
M.