Octave Forge

Hello,

maybe we could put an entry for 'vmesh' in the INDEX file, under
'Surface plots'.

  Cheers,

  Etienne

On Thu, May 15, 2003 at 05:34:35PM -0400, Paul Kienzle wrote:
# All,
# 
# We need a new release to support octave-2.1.48 since
# OCTAVE_LOCAL_BUFFER now requires #include <memory>.
# I've updated the half-dozen files that require it
# (inc. comm/gf.cc and sparse/make_sparse.h).
# 
# Here is my take on the changes since the last release.
# Please correct any errors in octave-forge/RELEASE-NOTES 
# 
# * Support for octave 2.1.36-2.1.48.
# 
# * Communications:
#   - sqrt over Galois field
#   - BCH code, modulator
#   - bug fixes and documentation improvements
# 
# * Image:
#   - add rotate_scale()
# 
# * Optimization:
#   - add Nick Higham's adsmax, mdsmax nmsmax for fmins
#   - lp() fix range error
# 
# * Plotting:
#   - surf()/surfc() support gnuplot 3.8i shaded surfaces
#   - add peaks()
#   - legend() inside/ouside/boxon/boxoff/right/left
# 
# * Signal Processing
#   - return statespace and laplacian IIR filters (butter, cheby1, cheby2, ellip)
#   - fix aryule
# 
# * Statistics:
#   - add normplot()
#   - scatter() optimization
# 
# * Symbolic:
#   - added poly2sym, sym2poly, numden, findsymbols, findsym, symlsolve,
#     symfsolve, syminfo
#   - subs() accepts cell arrays
# 
# * TSA/NaN:
#   - many bug fixes and documentation improvements
#   - quantiles -> Quantile
# 
# * Miscellaneous:
#   - add cellstr()
#   - fieldnames() now returns cell array
#   - listen() bugfixes
#   - ellipke() supports m < 0
#   - extend deal() to handle [a,b] = deal(b,a)
#   - dlmread() converted to C++ for speed and more flexible input
# 
# * administration:
#   - target specific build instructions (MacOSX, windows, Irix)
# 
# 
# 
# -------------------------------------------------------
# Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
# The only event dedicated to issues related to Linux enterprise solutions
# http://www.enterpriselinuxforum.com
# 
# _______________________________________________
# Octave-dev mailing list
# Octave-dev@...
# https://lists.sourceforge.net/lists/listinfo/octave-dev
# 
# 

-- 
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

On Thursday, May 15, 2003, at 11:34 PM, Paul Kienzle wrote:
> * Communications:
>   - sqrt over Galois field
>   - BCH code, modulator
>   - bug fixes and documentation improvements

I'm still having a problem with the install_doc target in 
main/comms/Makefile on OS X (described in a previous mail).

>
> * administration:
>   - target specific build instructions (MacOSX, windows, Irix)
>

Could someone confirm that the following patches are OK on non-OSX 
systems (and generally acceptable)?

/Per


Index: configure.base
===================================================================
RCS file: /cvsroot/octave/octave-forge/configure.base,v
retrieving revision 1.14
diff -u -w -r1.14 configure.base
--- configure.base      15 May 2003 16:05:50 -0000      1.14
+++ configure.base      21 May 2003 18:31:12 -0000
@@ -224,6 +224,15 @@
  AC_PROG_INSTALL
  AC_PROG_RANLIB

+dnl Use $(COPY_FLAGS) to set options for cp when installing .oct files.
+COPY_FLAGS="-fdp"
+case "$canonical_host_type" in
+    powerpc-apple-darwin*)
+        COPY_FLAGS="-Rfp"
+    ;;
+esac
+AC_SUBST(COPY_FLAGS)
+
  dnl Use $(STRIP) in the makefile to strip executables.  If not found,
  dnl STRIP expands to ':', which in the makefile does nothing.
  dnl Don't need this for .oct files since mkoctfile handles them 
directly

Index: octinst.sh.in
===================================================================
RCS file: /cvsroot/octave/octave-forge/octinst.sh.in,v
retrieving revision 1.4
diff -u -w -r1.4 octinst.sh.in
--- octinst.sh.in       9 Mar 2003 02:34:44 -0000       1.4
+++ octinst.sh.in       21 May 2003 18:56:57 -0000
@@ -21,6 +21,7 @@
  INSTALL_DATA="@INSTALL_DATA@"
  INSTALL_PROGRAM="@INSTALL_PROGRAM@"
  MKPKGADD="@TOPDIR@..."
+COPY_FLAGS="@COPY_FLAGS@"

  # grab the m-files
  files=`echo $source/*.m`
@@ -34,7 +35,7 @@
  if test "$files" != "$source/*.oct" ; then
      $INSTALL -d $opath
  ## Grrr... install doesn't preserve links.  Hope this works.
-    cp -fdp $files $opath
+    cp $COPY_FLAGS $files $opath
  fi

  # create PKG_ADD


------------
Per Persson
Blekinge Institute of Technology
Dept. of Signal Processing and Telecommunications

www:   http://www.its.bth.se/staff/pee
e-mail: per.persson@...

On Wed, May 21, 2003 at 09:08:32PM +0200, Per Persson wrote:
> On Thursday, May 15, 2003, at 11:34 PM, Paul Kienzle wrote:
> >
> > * administration:
> >   - target specific build instructions (MacOSX, windows, Irix)
> >
> 
> Could someone confirm that the following patches are OK on non-OSX 
> systems (and generally acceptable)?

They look fine (but I haven't tested them) and are acceptable short term.

Longer term I should figure out a better way of indicating which links to
make at install time rather than trying to copy the linked files.

Really long term, Octave should have a better way to indicate that routine
xxx is located in object file yyy rather than relying on symbolic links in
the file system, but that's a topic for another list.

- Paul

I would like make a new octave-forge release.  Please let me
know when you all are ready.

- Paul

The stuff in the directory main/fixed/examples doesn't build on OS X,
but as I don't have this OS I can't debug it. It was Per Persson who
pointed this out, and suggested he might find time to fix it, but as
he hasn't yet, I just added a test to disable building of this code
if the canonical_host_type includes the string "darwin".

The only other possible thing in my code was a bug report by Tom
G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate
his problem, and I can make no sense of why this problem occurs for
him, except to think he might have a problem with the install of his
compiler. So at this point I can propose no fix. If you really want to
be on the save side, I can disable the building of the parts of the
code that caused his problem as it only occurs in the classes for
fixed point NDArrays. As I haven't integrated this with the rest of
the code yet, they could only be used from within an oct-file in any
case. during the lead-up to a release I expect more people will do
builds of octave-forge and we'll see if other people have the same
problems as Tom G. Smith and if so we can then think about disabling
the build..

Cheers
David

Dapr=E8s Paul Kienzle <pkienzle@...> (le 15/06/2004):
> I would like make a new octave-forge release.  Please let me
> know when you all are ready.
>=20
> - Paul
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                David.Bateman@...
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

On Jun 15, 2004, at 09:56, David Bateman wrote:

> The stuff in the directory main/fixed/examples doesn't build on OS X,
> but as I don't have this OS I can't debug it. It was Per Persson who
> pointed this out, and suggested he might find time to fix it, but as
> he hasn't yet, I just added a test to disable building of this code
> if the canonical_host_type includes the string "darwin".

Thanks!

>
> The only other possible thing in my code was a bug report by Tom
> G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate
> his problem, and I can make no sense of why this problem occurs for
> him, except to think he might have a problem with the install of his
> compiler.

FWIW, I'm seeing the same thing here:
fixedCNDArray.cc: In member function `FixedComplexNDArray
    FixedComplexNDArray::sumsq(int) const':
fixedCNDArray.cc:638: error: operands to ?: have different types
make[2]: *** [fixedCNDArray.o] Error 1
make[1]: *** [fixed/] Error 2
make: *** [main/] Error 2

Mac OS X 10.3, GCC 3.3

/Per
(just now checking octave-forge CVS against octave 2.1.57 and CVS on OS=20=

X...)


> So at this point I can propose no fix. If you really want to
> be on the save side, I can disable the building of the parts of the
> code that caused his problem as it only occurs in the classes for
> fixed point NDArrays. As I haven't integrated this with the rest of
> the code yet, they could only be used from within an oct-file in any
> case. during the lead-up to a release I expect more people will do
> builds of octave-forge and we'll see if other people have the same
> problems as Tom G. Smith and if so we can then think about disabling
> the build..
>
> Cheers
> David
>
> Dapr=E8s Paul Kienzle <pkienzle@...> (le =
15/06/2004):
>> I would like make a new octave-forge release.  Please let me
>> know when you all are ready.
>>
>> - Paul
>>
>>

Dapr=E8s Per Persson <persquare@...> (le 15/06/2004):
> >The only other possible thing in my code was a bug report by Tom
> >G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate
> >his problem, and I can make no sense of why this problem occurs for
> >him, except to think he might have a problem with the install of his
> >compiler.
>=20
> FWIW, I'm seeing the same thing here:
> fixedCNDArray.cc: In member function `FixedComplexNDArray
>    FixedComplexNDArray::sumsq(int) const':
> fixedCNDArray.cc:638: error: operands to ?: have different types
> make[2]: *** [fixedCNDArray.o] Error 1
> make[1]: *** [fixed/] Error 2
> make: *** [main/] Error 2
>=20
> Mac OS X 10.3, GCC 3.3

Damn, so its likely a bug then. What a pain I can't generate it myself.
Time to dig a bit further into the issue...

cheers
David



--=20
David Bateman                                David.Bateman@...
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

Dapr=E8s Per Persson <persquare@...> (le 15/06/2004):
> FWIW, I'm seeing the same thing here:
> fixedCNDArray.cc: In member function `FixedComplexNDArray
>    FixedComplexNDArray::sumsq(int) const':
> fixedCNDArray.cc:638: error: operands to ?: have different types
> make[2]: *** [fixedCNDArray.o] Error 1
> make[1]: *** [fixed/] Error 2
> make: *** [main/] Error 2

Ok, on the assumption that the "pow" function is returning double,=20
and that the "if" statement is basically a costing me speed, I
eliminated both in an attempt to resolve this issue. This is=20
probably the best thing to do in any case. The function "sumsq"
in fixedCNDArray.cc should now read

FixedComplexNDArray
FixedComplexNDArray::sumsq (int dim) const
{
  FixedPointComplex zero;
  MX_ND_REDUCTION (acc +=3D elem (iter_idx) * conj (elem (iter_idx)),
		   retval.elem (iter_idx) =3D acc, zero,=20
		   FixedPointComplex acc =3D zero, FixedComplexNDArray);
}

I've committed this to the cvs, but unless you have access to the develop=
ers
site you won't see this change for a few hours. Could you check and see
that this fixes all the build problems you are/were having...

Cheers
David

--=20
David Bateman                                David.Bateman@...
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

I finally got octave-forge to build with qhull support using the patches
John sent to the octave list yesterday. I can't build without the
changes (I'm using Fedora Core 2). I'm surprised this problem hasn't
come up sooner. Are the lines he removed necessary for anyone? This
definitely needs to be fixed before a release, but I'm not very familiar
with the geometry functions, so I would prefer to defer to someone who
is to make these changes.

-Quentin

Here's another bug I found recently:

hammgen's documentation claims it can take input arguments M between 3
and 16, but it actually fails for M>6. This appears to be an
undocumented limitation in cyclgen. Looking at the source code to
cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit
number is used in the computation. I would love to see someone figure
out how to support larger sizes than 64 (like up to 65535 as hammgen
suggests, for example), but I don't have time to figure this out by
myself. If this isn't fixed before a new release, at least the
documentation of hammgen should be modified until it is.

-Quentin

Hummm, another one of my bugs.... Ok, I'll look at it...

Cheers
David

Dapr=E8s Quentin Spencer <qspencer@...> (le 15/06/2004):
> Here's another bug I found recently:
>=20
> hammgen's documentation claims it can take input arguments M between 3
> and 16, but it actually fails for M>6. This appears to be an
> undocumented limitation in cyclgen. Looking at the source code to
> cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit
> number is used in the computation. I would love to see someone figure
> out how to support larger sizes than 64 (like up to 65535 as hammgen
> suggests, for example), but I don't have time to figure this out by
> myself. If this isn't fixed before a new release, at least the
> documentation of hammgen should be modified until it is.
>=20
> -Quentin
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                David.Bateman@...
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

Quentin,

I wrote the hammgen function over a year ago now and I'm scratching
my head to think why I wrote the test for an irreducible polynomial
the way I did in cyclgen.cc and cyclpoly.cc. I vaguely remember that
there was a reason, but not the details. I think it might have been=20
a limitation elsewhere that I later removed and have now fixed. In
any case hammgen upto 16 seems to work correctly and a quick test
of cyclgen and cyclpoly seperately seem to be ok.=20

However, if you have any specific tests of these three functions,=20
could you try them and see that they now give the right result,
with the code I just checked into the CVS...

Regards
David

Dapr=E8s Quentin Spencer <qspencer@...> (le 15/06/2004):
> Here's another bug I found recently:
>=20
> hammgen's documentation claims it can take input arguments M between 3
> and 16, but it actually fails for M>6. This appears to be an
> undocumented limitation in cyclgen. Looking at the source code to
> cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit
> number is used in the computation. I would love to see someone figure
> out how to support larger sizes than 64 (like up to 65535 as hammgen
> suggests, for example), but I don't have time to figure this out by
> myself. If this isn't fixed before a new release, at least the
> documentation of hammgen should be modified until it is.
>=20
> -Quentin
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                David.Bateman@...
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

Hi all,

just to say that I fixed minimize(), test_min_[1-4] and
test_minimize_1 so that they use bfgsmin() instead of bfgs().

  I should still do some list -> cell work, but that will wait a
little more.

  Cheers,

  Etienne

On Mon, Jun 14, 2004 at 06:37:58PM -0400, Paul Kienzle wrote:
# I would like make a new octave-forge release.  Please let me
# know when you all are ready.
# 
# - Paul
# 
# 
# 
# -------------------------------------------------------
# This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
# Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
# Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
# REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
# _______________________________________________
# Octave-dev mailing list
# Octave-dev@...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

David,

Thanks. The updates fixed hammgen. However, now I've found another bug. 
I don't know if it was there all along or newly introduced. The 
following command should produce the 16x255 parity check matrix for a 
BCH 2-error correcting code:
cyclgen(255,bchpoly(255,239))

The result instead is:
error: cyclgen: generator polynomial does not produce cyclic code

I verified the resulting polynomial against MATLAB and they matched.

regards,
Quentin

David Bateman wrote:

>Quentin,
>
>I wrote the hammgen function over a year ago now and I'm scratching
>my head to think why I wrote the test for an irreducible polynomial
>the way I did in cyclgen.cc and cyclpoly.cc. I vaguely remember that
>there was a reason, but not the details. I think it might have been 
>a limitation elsewhere that I later removed and have now fixed. In
>any case hammgen upto 16 seems to work correctly and a quick test
>of cyclgen and cyclpoly seperately seem to be ok. 
>
>However, if you have any specific tests of these three functions, 
>could you try them and see that they now give the right result,
>with the code I just checked into the CVS...
>
>Regards
>David
>  
>

According to Quentin Spencer <qspencer@...> (on 06/16/04):
> David,
> 
> Thanks. The updates fixed hammgen. However, now I've found another bug. 
> I don't know if it was there all along or newly introduced. The 
> following command should produce the 16x255 parity check matrix for a 
> BCH 2-error correcting code:
> cyclgen(255,bchpoly(255,239))
> 
> The result instead is:
> error: cyclgen: generator polynomial does not produce cyclic code
> 
> I verified the resulting polynomial against MATLAB and they matched.

Ok, I'm a bit draft. The test I added checks if the polynomial is primitive
rather than just irreducible. I'd previously tried to adapt this test in
the older code, but failed.

So I went back to the basic implementation of dividing x^n-1 by the
polynomial and checking that there was no remainder. It appears to
work correctly for you test case now. Though maybe you want to give
it a bit more testing.. Changes checked into the CVS

Regards
David

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

OK, I tested your changes to the coding stuff and this is what I found:

bchpoly appears to give correct results for the cases I tested
cyclgen(255,bchpoly(255,247)) gives the correct result
cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
first 8x8 submatrix, and zeros everywhere else !?
cyclpoly gives a vector containing all zeros for every input I tried.

Well, I guess there's at least some progress since one case worked. I'm
sorry the news isn't better.

-Quentin


David Bateman wrote:

>According to Quentin Spencer <qspencer@...> (on 06/16/04):
>  
>
>>David,
>>
>>Thanks. The updates fixed hammgen. However, now I've found another bug. 
>>I don't know if it was there all along or newly introduced. The 
>>following command should produce the 16x255 parity check matrix for a 
>>BCH 2-error correcting code:
>>cyclgen(255,bchpoly(255,239))
>>
>>The result instead is:
>>error: cyclgen: generator polynomial does not produce cyclic code
>>
>>I verified the resulting polynomial against MATLAB and they matched.
>>    
>>
>
>Ok, I'm a bit draft. The test I added checks if the polynomial is primitive
>rather than just irreducible. I'd previously tried to adapt this test in
>the older code, but failed.
>
>So I went back to the basic implementation of dividing x^n-1 by the
>polynomial and checking that there was no remainder. It appears to
>work correctly for you test case now. Though maybe you want to give
>it a bit more testing.. Changes checked into the CVS
>
>Regards
>David
>
>  
>

I believe it probably still works correctly for small values of n, since
that was all I tested previously. Oh, well it looks like the method I used
to create the generator matrix is too naive...

Cheers
David

According to Quentin Spencer <qspencer@...> (on 06/18/04):
> OK, I tested your changes to the coding stuff and this is what I found:
> 
> bchpoly appears to give correct results for the cases I tested
> cyclgen(255,bchpoly(255,247)) gives the correct result
> cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
> first 8x8 submatrix, and zeros everywhere else !?
> cyclpoly gives a vector containing all zeros for every input I tried.
> 
> Well, I guess there's at least some progress since one case worked. I'm
> sorry the news isn't better.
> 
> -Quentin
> 
> 
> David Bateman wrote:
> 
> >According to Quentin Spencer <qspencer@...> (on 06/16/04):
> > 
> >
> >>David,
> >>
> >>Thanks. The updates fixed hammgen. However, now I've found another bug. 
> >>I don't know if it was there all along or newly introduced. The 
> >>following command should produce the 16x255 parity check matrix for a 
> >>BCH 2-error correcting code:
> >>cyclgen(255,bchpoly(255,239))
> >>
> >>The result instead is:
> >>error: cyclgen: generator polynomial does not produce cyclic code
> >>
> >>I verified the resulting polynomial against MATLAB and they matched.
> >>   
> >>
> >
> >Ok, I'm a bit draft. The test I added checks if the polynomial is primitive
> >rather than just irreducible. I'd previously tried to adapt this test in
> >the older code, but failed.
> >
> >So I went back to the basic implementation of dividing x^n-1 by the
> >polynomial and checking that there was no remainder. It appears to
> >work correctly for you test case now. Though maybe you want to give
> >it a bit more testing.. Changes checked into the CVS
> >
> >Regards
> >David
> >
> > 
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

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

Try the attached patch. It works for all of the test cases you propose he=
re.
Just a stupid little bug it seems.. This patch is applied to the CVS

Cheers
David

Dapr=E8s Quentin Spencer <qspencer@...> (le 18/06/2004):
> OK, I tested your changes to the coding stuff and this is what I found:
>=20
> bchpoly appears to give correct results for the cases I tested
> cyclgen(255,bchpoly(255,247)) gives the correct result
> cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
> first 8x8 submatrix, and zeros everywhere else !?
> cyclpoly gives a vector containing all zeros for every input I tried.
>=20
> Well, I guess there's at least some progress since one case worked. I'm
> sorry the news isn't better.
>=20
> -Quentin
>=20
>=20
> David Bateman wrote:
>=20
> >According to Quentin Spencer <qspencer@...> (on 06/16/04):
> >=20
> >
> >>David,
> >>
> >>Thanks. The updates fixed hammgen. However, now I've found another bu=
g.=20
> >>I don't know if it was there all along or newly introduced. The=20
> >>following command should produce the 16x255 parity check matrix for a=
=20
> >>BCH 2-error correcting code:
> >>cyclgen(255,bchpoly(255,239))
> >>
> >>The result instead is:
> >>error: cyclgen: generator polynomial does not produce cyclic code
> >>
> >>I verified the resulting polynomial against MATLAB and they matched.
> >>  =20
> >>
> >
> >Ok, I'm a bit draft. The test I added checks if the polynomial is prim=
itive
> >rather than just irreducible. I'd previously tried to adapt this test =
in
> >the older code, but failed.
> >
> >So I went back to the basic implementation of dividing x^n-1 by the
> >polynomial and checking that there was no remainder. It appears to
> >work correctly for you test case now. Though maybe you want to give
> >it a bit more testing.. Changes checked into the CVS
> >
> >Regards
> >David
> >
> >=20
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                David.Bateman@...
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

So are all the issues addressed that we are going to address?

If I've been following correctly, the comm and fixed toolboxes
are now ready.

Arguably there are still bugs in symbolic and sparse since
neither use the new concatenation mechanism and neither
use the new save mechanism that David put into place.

And there is the issue of what to do about shadowed
octave functions which I wrote about earlier.

If no one volunteers, I'm content to leave this issues into the
next release in order to get this release out now.  It will be
a couple of weeks at least before I can get to it.

In which case, we are ready for Dirk to build a new Debian
version, assuming he is not too busy at the moment.

Paul Kienzle
pkienzle@...

Dapr=E8s Paul Kienzle <pkienzle@...> (le 21/06/2004):
> So are all the issues addressed that we are going to address?
>=20
> If I've been following correctly, the comm and fixed toolboxes
> are now ready.

I think the fixed point and cyclgen/cyclpoly bugs are fixed...

> Arguably there are still bugs in symbolic and sparse since
> neither use the new concatenation mechanism and neither
> use the new save mechanism that David put into place.

What new concatenation method? Do you mean "cat", in that
case it can be argued that neither does the galois or
fixed point types. In any case either if these are implemented
there is nothing to stop a user using "[]" and getting the
wrong result, so implementing these functions just gives a=20
false sense of security.... Still need to get "[]" fixed
within octave itself..

> And there is the issue of what to do about shadowed
> octave functions which I wrote about earlier.
>=20
> If no one volunteers, I'm content to leave this issues into the
> next release in order to get this release out now.  It will be
> a couple of weeks at least before I can get to it.

Which? The next release or this one :-)

Cheers
David

--=20
David Bateman                                David.Bateman@...
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

On Mon, Jun 21, 2004 at 07:19:43AM -0400, Paul Kienzle wrote:
> In which case, we are ready for Dirk to build a new Debian
> version, assuming he is not too busy at the moment.

Sure, let me know where to grab a tarball from, or if I must, I'd attempt a
CVS checkout.  

This should fix three open Debian bugs

	http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=octave-forge

so a release is probably a good idea indeed.

Dirk

-- 
FEATURE:  VW Beetle license plate in California

Dirk,

It seems hdf5-1.6.2-3 is a valid candidate for debian testing, but is
stalled since it says it breaks octave, python, etc. Without this=20
octave-forge can't migrate into testing. Does this mean that octave,
etc in testing need to be rebuilt against the new hdf5 library, so
it also can migrate to testing?

Regards
David

Dapr=E8s Dirk Eddelbuettel <edd@...> (le 21/06/2004):
> On Mon, Jun 21, 2004 at 07:19:43AM -0400, Paul Kienzle wrote:
> > In which case, we are ready for Dirk to build a new Debian
> > version, assuming he is not too busy at the moment.
>=20
> Sure, let me know where to grab a tarball from, or if I must, I'd attem=
pt a
> CVS checkout. =20
>=20
> This should fix three open Debian bugs
>=20
> 	http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=3Doctave-forge
>=20
> so a release is probably a good idea indeed.
>=20
> Dirk
>=20
> --=20
> FEATURE:  VW Beetle license plate in California
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                David.Bateman@...
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

On Mon, Jun 21, 2004 at 02:14:15PM +0200, David Bateman wrote:
> 
> Dirk,
> 
> It seems hdf5-1.6.2-3 is a valid candidate for debian testing, but is
> stalled since it says it breaks octave, python, etc. Without this 
> octave-forge can't migrate into testing. Does this mean that octave,
> etc in testing need to be rebuilt against the new hdf5 library, so
> it also can migrate to testing?

Possibly. I have no insights other than the (helpful) page 'why is package X
not in testing' (at http://bjorn.haxx.se/debian/) says. 

Rafael is up to snuff on these things as octave influences his octave-*
packages, incl. plplot.

Dirk

-- 
FEATURE:  VW Beetle license plate in California

* Dirk Eddelbuettel <edd@...> [2004-06-21 07:59]:

> On Mon, Jun 21, 2004 at 02:14:15PM +0200, David Bateman wrote:
> > 
> > Dirk,
> > 
> > It seems hdf5-1.6.2-3 is a valid candidate for debian testing, but is
> > stalled since it says it breaks octave, python, etc. Without this 
> > octave-forge can't migrate into testing. Does this mean that octave,
> > etc in testing need to be rebuilt against the new hdf5 library, so
> > it also can migrate to testing?
> 
> Possibly. I have no insights other than the (helpful) page 'why is package X
> not in testing' (at http://bjorn.haxx.se/debian/) says. 
> 
> Rafael is up to snuff on these things as octave influences his octave-*
> packages, incl. plplot.

The problem is that there are circular dependencies between the new hdf5
packages and lots of others (including octave2.1, octave-forge and
octave-plplot).  This can be seen at:

    http://bjorn.haxx.se/debian/testing.pl?package=hdf5

The only way to fix this dead-lock situation is by manually adding a hint to
the program that promotes packages from unstable to testing (britney).  The
hints can be seen at:

    http://ftp-master.debian.org/testing/hints/

One thing that complicates the situation is that the number of packages
involved is quite high and new versions are constantly uploaded to unstable.
Since the 10-days rule must be obeyed, the joint promotion of all packages
keep being delayed.

Should we impose a freeze on the involved packages until they get all
together into testing?
   
[ N.B.: Steve Langasek is one of the ftp-admins who is helping us with this
  issue.  Josselin Mouette is the maintainer of the Debian hdf5 packages.  I
  am CC:ing this message to them.  ]

-- 
Rafael

Dapr=E8s Rafael Laboissiere <rafael@...> (le 21/06/2004):
> Should we impose a freeze on the involved packages until they get all
> together into testing?

Yes, please... :-)

D.

--=20
David Bateman                                David.Bateman@...
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

On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote:
> Dapr?s Rafael Laboissiere <rafael@...> (le 21/06/2004):
> > Should we impose a freeze on the involved packages until they get all
> > together into testing?
> 
> Yes, please... :-)

Before or after the tarball for octave-forge that spawned this discussion is
added?

Dirk

-- 
FEATURE:  VW Beetle license plate in California

Dapr=E8s Dirk Eddelbuettel <edd@...> (le 21/06/2004):
> On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote:
> > Dapr?s Rafael Laboissiere <rafael@...> (le 21/06/2004):
> > > Should we impose a freeze on the involved packages until they get a=
ll
> > > together into testing?
> >=20
> > Yes, please... :-)
>=20
> Before or after the tarball for octave-forge that spawned this discussi=
on is
> added?

I can wait two times ten days to get it... So before I suppose. Unless on=
e
of the other blocking packages just added something and we can slip somet=
hing
in with further delays being implied...

Cheers
David

--=20
David Bateman                                David.Bateman@...
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

On Mon, Jun 21, 2004 at 04:47:23PM +0200, Rafael Laboissiere wrote:
> The problem is that there are circular dependencies between the new hdf5
> packages and lots of others (including octave2.1, octave-forge and
> octave-plplot).  This can be seen at:

>     http://bjorn.haxx.se/debian/testing.pl?package=3Dhdf5

> The only way to fix this dead-lock situation is by manually adding a hint=
 to
> the program that promotes packages from unstable to testing (britney).  T=
he
> hints can be seen at:

>     http://ftp-master.debian.org/testing/hints/

> One thing that complicates the situation is that the number of packages
> involved is quite high and new versions are constantly uploaded to unstab=
le.
> Since the 10-days rule must be obeyed, the joint promotion of all packages
> keep being delayed.

> Should we impose a freeze on the involved packages until they get all
> together into testing?

I would appreciate this.  It's unfortunate to see that plplot has
recently reset the clock on testing propagation for these packages; it
looks like octave2.1 is very close to being ready, since it has been
built on m68k and alpha and it's just a question of prodding the buildd
admins into getting those packages uploaded.

Since the clock has been reset, I don't see any reason a new
octave-forge upload should be a problem, if it's done soon; of course,
if there are architecture-specific problems getting octave-forge ready,
this does not hold true.  You might also consider using an upload
priority of "medium" here, to help prevent delays, or else just hold off
for 8 days before uploading.

> [ N.B.: Steve Langasek is one of the ftp-admins who is helping us with th=
is
>   issue.  Josselin Mouette is the maintainer of the Debian hdf5 packages.=
  I
>   am CC:ing this message to them.  ]

Release assistant, not ftp-admin.  Please don't mistake me for someone
with direct authority over the archive. :)

Cheers,
--=20
Steve Langasek
postmodern programmer

* Steve Langasek <vorlon@...> [2004-06-21 11:33]:

> On Mon, Jun 21, 2004 at 04:47:23PM +0200, Rafael Laboissiere wrote:
> > The problem is that there are circular dependencies between the new hdf5
> > packages and lots of others (including octave2.1, octave-forge and
> > octave-plplot).  This can be seen at:
> 
> >     http://bjorn.haxx.se/debian/testing.pl?package=hdf5
> 
> > The only way to fix this dead-lock situation is by manually adding a hint to
> > the program that promotes packages from unstable to testing (britney).  The
> > hints can be seen at:
> 
> >     http://ftp-master.debian.org/testing/hints/
> 
> > One thing that complicates the situation is that the number of packages
> > involved is quite high and new versions are constantly uploaded to unstable.
> > Since the 10-days rule must be obeyed, the joint promotion of all packages
> > keep being delayed.
> 
> > Should we impose a freeze on the involved packages until they get all
> > together into testing?
> 
> I would appreciate this.  It's unfortunate to see that plplot has
> recently reset the clock on testing propagation for these packages; [...]

Mea culpa.

> [...] it looks like octave2.1 is very close to being ready, since it has
> been built on m68k and alpha and it's just a question of prodding the
> buildd admins into getting those packages uploaded.
> 
> Since the clock has been reset, I don't see any reason a new
> octave-forge upload should be a problem, if it's done soon; of course,
> if there are architecture-specific problems getting octave-forge ready,
> this does not hold true.  You might also consider using an upload
> priority of "medium" here, to help prevent delays, or else just hold off
> for 8 days before uploading.

The use of hold off is perhaps a good idea.  Here is the list of source
packages concerned by the eventual freeze (this message is being Cc:ed to
their maintainers):

    hdf5 (J. Mouette)
    mpb (J. Mouette)
    pytables (F. Alted)
    octave2.1 (D. Eddelbuetel)
    octave-forge (D. Eddelbuetel)
    plplot (R. Laboissiere)
    statdataml (R. Laboissiere)

I think that in seven days from now everything will be stabilized (plplot
already successfully built on all architectures), unless new versions of
octave2.1 and octave-forge are uploaded to unstable.

When establishing the hint, you will probably have to take care of the
following packages:

    octave-gpc (R. Laboissiere)
    octave-sp (D. Eddelbuetel)

which would be made uninstallable by the upgrade of hdf5.    

> Release assistant, not ftp-admin.  Please don't mistake me for someone
> with direct authority over the archive. :)

Okay, I will not blame you for ftp-admin problems anymore :-)

-- 
Rafael

Hi all,

On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote:
> Dapr?s Rafael Laboissiere <rafael@...> (le 21/06/2004):
> > Should we impose a freeze on the involved packages until they get all
> > together into testing?
> 
> Yes, please... :-)

It looks like things moved according to plan and octave2.1 and octave-forge
are now in testing.

So shall we release a new octave-forge tarball for Debian unstable and/or
the world at large?  I'm CCing to the the submitter and bug report of a
recent BTS request for a fresher octave-forge.

Dirk

-- 
White House officials praised the performance of the controversial 
new Diebold electronic voting machines, which successfully tabulated 
final results from Florida before a single vote was cast.
          -- Andy Borowitz, http://borowitzreport.com, 29 June 2004

Will it cause problems for you if the build succeeds even
when it fails?  That is, if I put in the -k business so that
people can ignore things that don't build on their architecture
unless they really need them, it won't generate an exit
status on Debian builds.

On second thought, I can put in a make parameter such as:
	make STOP=1
Use this if you want to build and stop at the first error.  If
nobody disagrees, that's what I will do.  I'll skip the nice
report of what doesn't build for now.

Paul Kienzle
pkienzle@...

On Jul 3, 2004, at 10:29 AM, Dirk Eddelbuettel wrote:

>
> Hi all,
>
> On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote:
>> Dapr?s Rafael Laboissiere <rafael@...> (le 21/06/2004):
>>> Should we impose a freeze on the involved packages until they get all
>>> together into testing?
>>
>> Yes, please... :-)
>
> It looks like things moved according to plan and octave2.1 and 
> octave-forge
> are now in testing.
>
> So shall we release a new octave-forge tarball for Debian unstable 
> and/or
> the world at large?  I'm CCing to the the submitter and bug report of a
> recent BTS request for a fresher octave-forge.
>
> Dirk
>
> -- 
> White House officials praised the performance of the controversial
> new Diebold electronic voting machines, which successfully tabulated
> final results from Florida before a single vote was cast.
>           -- Andy Borowitz, http://borowitzreport.com, 29 June 2004
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit http://www.blackhat.com
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

On Sat, Jul 03, 2004 at 01:27:07PM -0400, Paul Kienzle wrote:
> Will it cause problems for you if the build succeeds even
> when it fails?  That is, if I put in the -k business so that
> people can ignore things that don't build on their architecture
> unless they really need them, it won't generate an exit
> status on Debian builds.

Well, I'd rather have it succeed in the first place for me. 

> On second thought, I can put in a make parameter such as:
> 	make STOP=1
> Use this if you want to build and stop at the first error.  If
> nobody disagrees, that's what I will do.  I'll skip the nice
> report of what doesn't build for now.

I think I can also make it fault tolerant at my level because debian/rules,
a makefile, can call 'make' as '-make' and even if your make failed, it
would continue.

But I think that would open a can of worms. We need to decide between you
and me what we think will build under Debian, and then just build it. On
i386 and all other ten or eleven arches, if possible.

Dirk

-- 
White House officials praised the performance of the controversial 
new Diebold electronic voting machines, which successfully tabulated 
final results from Florida before a single vote was cast.
          -- Andy Borowitz, http://borowitzreport.com, 29 June 2004

I just returned from vacation and noticed that CVS contained several 
updates to the files in question in my previous mail below. I'm happy to 
report that cyclgen appears to work properly for the inputs that I 
tested. I also tested cyclpoly and discovered that when compared to the 
ouput of the same function in Matlab, the results are the same but 
appear in reverse order, i.e. fliplr(cyclgen(255,247)) is equivalent to 
cyclgen(255,247) in Matlab. Thank you for all the work you have done in 
fixing these functions.

-Quentin



Quentin Spencer wrote:

> OK, I tested your changes to the coding stuff and this is what I found:
>
> bchpoly appears to give correct results for the cases I tested
> cyclgen(255,bchpoly(255,247)) gives the correct result
> cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
> first 8x8 submatrix, and zeros everywhere else !?
> cyclpoly gives a vector containing all zeros for every input I tried.
>
> Well, I guess there's at least some progress since one case worked. I'm
> sorry the news isn't better.
>
> -Quentin
>
>
> David Bateman wrote:
>
>> According to Quentin Spencer <qspencer@...> (on 06/16/04):
>>
>>> David,
>>>
>>> Thanks. The updates fixed hammgen. However, now I've found another 
>>> bug. I don't know if it was there all along or newly introduced. The 
>>> following command should produce the 16x255 parity check matrix for 
>>> a BCH 2-error correcting code:
>>> cyclgen(255,bchpoly(255,239))
>>>
>>> The result instead is:
>>> error: cyclgen: generator polynomial does not produce cyclic code
>>>
>>> I verified the resulting polynomial against MATLAB and they matched.
>>
>> Ok, I'm a bit draft. The test I added checks if the polynomial is 
>> primitive
>> rather than just irreducible. I'd previously tried to adapt this test in
>> the older code, but failed.
>>
>> So I went back to the basic implementation of dividing x^n-1 by the
>> polynomial and checking that there was no remainder. It appears to
>> work correctly for you test case now. Though maybe you want to give
>> it a bit more testing.. Changes checked into the CVS
>>
>> Regards
>> David
>

Quentin,

The reason for the reversal is a stupidity in matlab. I can't remember
the details offhand but I believe hammgen and cyclgen return the matrices
in reverse order. Similarly the polynomials with cyclpoly are reversed...
I tried to keep the functions consistent with each other, so that they
might be used interchangably.

Regards
David

According to Quentin Spencer <qspencer@...> (on 07/06/04):
> I just returned from vacation and noticed that CVS contained several 
> updates to the files in question in my previous mail below. I'm happy to 
> report that cyclgen appears to work properly for the inputs that I 
> tested. I also tested cyclpoly and discovered that when compared to the 
> ouput of the same function in Matlab, the results are the same but 
> appear in reverse order, i.e. fliplr(cyclgen(255,247)) is equivalent to 
> cyclgen(255,247) in Matlab. Thank you for all the work you have done in 
> fixing these functions.
> 
> -Quentin
> 
> 
> 
> Quentin Spencer wrote:
> 
> >OK, I tested your changes to the coding stuff and this is what I found:
> >
> >bchpoly appears to give correct results for the cases I tested
> >cyclgen(255,bchpoly(255,247)) gives the correct result
> >cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
> >first 8x8 submatrix, and zeros everywhere else !?
> >cyclpoly gives a vector containing all zeros for every input I tried.
> >
> >Well, I guess there's at least some progress since one case worked. I'm
> >sorry the news isn't better.
> >
> >-Quentin
> >
> >
> >David Bateman wrote:
> >
> >>According to Quentin Spencer <qspencer@...> (on 06/16/04):
> >>
> >>>David,
> >>>
> >>>Thanks. The updates fixed hammgen. However, now I've found another 
> >>>bug. I don't know if it was there all along or newly introduced. The 
> >>>following command should produce the 16x255 parity check matrix for 
> >>>a BCH 2-error correcting code:
> >>>cyclgen(255,bchpoly(255,239))
> >>>
> >>>The result instead is:
> >>>error: cyclgen: generator polynomial does not produce cyclic code
> >>>
> >>>I verified the resulting polynomial against MATLAB and they matched.
> >>
> >>Ok, I'm a bit draft. The test I added checks if the polynomial is 
> >>primitive
> >>rather than just irreducible. I'd previously tried to adapt this test in
> >>the older code, but failed.
> >>
> >>So I went back to the basic implementation of dividing x^n-1 by the
> >>polynomial and checking that there was no remainder. It appears to
> >>work correctly for you test case now. Though maybe you want to give
> >>it a bit more testing.. Changes checked into the CVS
> >>
> >>Regards
> >>David
> >

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