octave-dev — GNU Octave developers' list

Re: [OctDev] image/dilate.m image/erode.m

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

Okay, added.

I had no problems with the docs giving errors.

I really appreciate the tests and demos!

I'm surprised you couldn't use filter2(...,'same') to trim the
array automatically.  I'm not saying it will work (I didn't look
closely at the program logic), but I thought this would be
a primary example of where 'same' would be used.

Thanks,

- Paul

On Jul 28, 2004, at 7:34 PM, Josep Mon=E9s i Teixidor wrote:

> Hi,
>
> My first contribution octave-forge :)
>
> The docs of MATLAB functions are here:
> http://www-ccs.ucsd.edu/matlab/toolbox/images/dilate.html
> http://www-ccs.ucsd.edu/matlab/toolbox/images/erode.html
>
> It should be compatible with MATLAB's image toolbox counterparts
> (although i don't have MATLAB to test them). When masks are even it is
> not very well documented, so if someone has MATLAB with image toolbox
> please exec "dilate([0,1,0],[1,0])" (or check if asserts at the end of
> file fail).
>
> It only supports 'spatial' algorithm (no 'frequency').
>
> I've done my best to include texinfo docs, but I really don't know how
> to test it (makeinfo reports errors). Can anybody help me here please?
>
> Regards,
> --=20
> Josep Mon=E9s i Teixidor
> Clau GnuPG: gpg --recv-keys 80E85CC4
> <dilate.m><erode.m>=

Re: [OctDev] Build problems on solaris 2.8 (octave-forge 2004.07.07)

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

On Jul 28, 2004, at 10:55 AM, Robert Reutemann wrote:

> Hi
>
> Trying to build the latest octave-forge release
> (2004.07.07) on solaris (sparc) 2.8 using gcc 3.4.1
> with octave 2.1.57 I ran into a couple of problems.

Thanks for reporting them.

> To get through the build process, I had to do
> use the following workarounds. Some of this is
> probably due to the exact setup here, some of
> them might be more general problems.
>
> - /bin/sh versus /bin/bash
>   The octave-forge build seems to assume that /bin/sh
>   actually is a bash shell, which it isn't on a std
>   solaris box.
>   I therefore changed "/bin/sh" to "/bin/bash" in
>   the following places:
>   - Makeconf (SHELL = ...)
>   - all *.sh files in all directories (#!/bin/bash,
>     not #!/bin/sh).

We are trying to be shell agnostic.  Please report
the sh incompatibilities rather than requiring bash
on the target machine.

> - term.h does not compile on solaris if curses.h
>   isn't included first.
>   For this, I commented out the TERM_H and TERMCAP
>   stuff in Makeconf.
>   This should probably be handled better by the
>   configure process, but I don't know enough about
>   that to try to fix it.

I'm very tempted to remove the term dependent
modules unless someone fixes the configure.  I
will ignore it for awhile longer.

>
> - "-R" option in "X_LIBS"
>   My configure sets "-R/usr/openwin/lib" in X_LIBS,
>   which leads to problems since mkoctfile does not
>   accept "-R".
>   I therefore removed the "-R" option from X_LIBS in
>   Makeconf (might lead to problems later on, but
>   at least build should work ...).

This is an octave bug.  Please report it to bu...@oc...

I tried to set it up so that everything that could be
built would be built and the rest ignored.  Is that
not the case?  Maybe I should fail silently ;-)

> - dispatch.cc doesn't compile
>   gcc does not compile the last statement in
>   main/miscellaneous/dispatch.cc
>   ("template std::map<std::string,std::string>;").
>   I therefore commented that out.

I'm using:

	#if defined(__GNUG__)
	template class std::map<std::string,std::string>;
	#endif

I see octave doesn't even use #if defined(__GNUG__)
anymore.

Can you please report the error message.

Did you need to do similar changes in Octave?

Anyone know the correct incantation?

> - installing: install-sh not found due to relative
>   path.
>   install-sh is set with a relative path ("./install-sh")
>   in Makeconf and octinst.sh (INSTALL = ...). This fails
>   when INSTALL is executed in subdirs.
>   I therefore set this to the full absolute path to
>   install-sh in those two definitions.

I'm using autoconf AC_PROG_INSTALL.  Anyone know
how to make it use absolute path?

> With this, I can build and install octave-forge.
>
> gmake check fails (segmentation violation while in
> main/signal). I don't know yet, what other problems
> I still have.

I would be much obliged if you could split up the
make check work so that it only checks a directory
at a time.  At least that way it will minimize the
consequences of a segfault.  You probably don't
want to go down to the level of the individual file
since that will start and restart octave too many
times.  Alternatively, the test program could monitor
progress and restart at the next test after a segfault.

> If anybody has experience with building octave and
> octave-forge on solaris 2.8 with gcc I'll be thankful
> for any hints and better solutions.

Please post your experiences on the octave wiki

	http://wiki.octave.org

Category Install.

- Paul

[OctDev] image/dilate.m image/erode.m

[Josep i T. <jm...@pu...>]

Hi,

My first contribution octave-forge :)

The docs of MATLAB functions are here:
http://www-ccs.ucsd.edu/matlab/toolbox/images/dilate.html
http://www-ccs.ucsd.edu/matlab/toolbox/images/erode.html

It should be compatible with MATLAB's image toolbox counterparts
(although i don't have MATLAB to test them). When masks are even it is
not very well documented, so if someone has MATLAB with image toolbox
please exec "dilate([0,1,0],[1,0])" (or check if asserts at the end of
file fail).

It only supports 'spatial' algorithm (no 'frequency').

I've done my best to include texinfo docs, but I really don't know how
to test it (makeinfo reports errors). Can anybody help me here please?

Regards,
-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

[OctDev] Build problems on solaris 2.8 (octave-forge 2004.07.07)

[Robert R. <re...@ii...>]

Hi

Trying to build the latest octave-forge release
(2004.07.07) on solaris (sparc) 2.8 using gcc 3.4.1
with octave 2.1.57 I ran into a couple of problems.

To get through the build process, I had to do
use the following workarounds. Some of this is
probably due to the exact setup here, some of
them might be more general problems.

- /bin/sh versus /bin/bash
   The octave-forge build seems to assume that /bin/sh
   actually is a bash shell, which it isn't on a std
   solaris box.
   I therefore changed "/bin/sh" to "/bin/bash" in
   the following places:
   - Makeconf (SHELL = ...)
   - all *.sh files in all directories (#!/bin/bash,
     not #!/bin/sh).

- term.h does not compile on solaris if curses.h
   isn't included first.
   For this, I commented out the TERM_H and TERMCAP
   stuff in Makeconf.
   This should probably be handled better by the
   configure process, but I don't know enough about
   that to try to fix it.

- "-R" option in "X_LIBS"
   My configure sets "-R/usr/openwin/lib" in X_LIBS,
   which leads to problems since mkoctfile does not
   accept "-R".
   I therefore removed the "-R" option from X_LIBS in
   Makeconf (might lead to problems later on, but
   at least build should work ...).

- dispatch.cc doesn't compile
   gcc does not compile the last statement in
   main/miscellaneous/dispatch.cc
   ("template std::map<std::string,std::string>;").
   I therefore commented that out.

- installing: install-sh not found due to relative
   path.
   install-sh is set with a relative path ("./install-sh")
   in Makeconf and octinst.sh (INSTALL = ...). This fails
   when INSTALL is executed in subdirs.
   I therefore set this to the full absolute path to
   install-sh in those two definitions.

With this, I can build and install octave-forge.

gmake check fails (segmentation violation while in
main/signal). I don't know yet, what other problems
I still have.

If anybody has experience with building octave and
octave-forge on solaris 2.8 with gcc I'll be thankful
for any hints and better solutions.


Versions:
  - sparc-sun-solaris2.8
  - octave 2.1.57
  - octave-forge 2004.07.07
  - gcc 3.4.1
  - autoconf 2.59
  - automake 1.8b
  - gmake 3.80


Thanks, Robert

[OctDev] Release of octave-gpc 0.1.5

[Rafael L. <rla...@us...>]

Hi,

I just released version 0.1.5 of octave-gpc.  The tarball can be downloaded
from the File Release area at SourceForge.

This version contains only minor fixes for making the functions work with
Octave 2.1.57, due to recent changes in the API for the Octave_map class.
This version of Octave is the minimum required now, since no efforts will be
done to insure backwards compatibility.

-- 
Rafael

Re: [OctDev] More limitations in coding functions

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

According to Quentin Spencer <qsp...@ie...> (on 07/16/04):
> David Bateman wrote:
> 
> >Quentin,
> >
> >Try the version I just committed. I removed the restriction on
> >calculating the minimum distance and vastly accelerated this code, and
> >I reduced the restriction on the syndrome table. There is still a
> >restriction at the moment in that the syndrome table must not have
> >more than 2^32 rows. This is enormous, and so I don't think I'll both
> >removing this restriction, and more memory than any machine I have access
> >to.
> > 
> >
> It works! I did some quick speed tests and got times just slightly 
> faster (~5%) than Matlab 6.5.

Humm, 5% faster is a bit of a slippery number. The octave code uses a DLD
for the calculation of the syndrome table and a dot-m file for the rest.
Matlab uses dot-m for everything. So is the 5% faster just for the calculation
of the syndrome? Or is it for the encode/decode? If its the second then I'm
happy, since the speed is then comaprable. If it is the first, I'm less happy
since on longer decodes octave will probably loose out.

D.

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

Re: [OctDev] More limitations in coding functions

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

David Bateman wrote:

>Quentin,
>
>Try the version I just committed. I removed the restriction on
>calculating the minimum distance and vastly accelerated this code, and
>I reduced the restriction on the syndrome table. There is still a
>restriction at the moment in that the syndrome table must not have
>more than 2^32 rows. This is enormous, and so I don't think I'll both
>removing this restriction, and more memory than any machine I have access
>to.
>  
>
It works! I did some quick speed tests and got times just slightly 
faster (~5%) than Matlab 6.5.

-Quentin

Re: [OctDev] More limitations in coding functions

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

Quentin,

Try the version I just committed. I removed the restriction on
calculating the minimum distance and vastly accelerated this code, and
I reduced the restriction on the syndrome table. There is still a
restriction at the moment in that the syndrome table must not have
more than 2^32 rows. This is enormous, and so I don't think I'll both
removing this restriction, and more memory than any machine I have access
to.

The code I used to test with was

1;
fprintf("  Hamming Coding:                           ");
nsym = 100;
m = 8;
[par, gen, n, k] = hammgen (m);
if (any(any(gen2par(par) != gen)))
  error("FAILED");
endif
if (gfweight(gen) != 3)
  error("FAILED");
endif
msg = randint(nsym,k);
code = encode(msg,n,k,"hamming");
noisy = mod(code + randerr(nsym,n), 2);
dec = decode(noisy,n,k,"hamming");
if (any(any(dec != msg)))
  error("FAILED");
endif         
try			# Protect! If bitshift isn't install!!
  msg = randint(nsym,1,n);
  code = encode(msg,n,k,"hamming/decimal");
  noisy = mod(code + bitshift(1,randint(nsym,1,n)), n+1);
  dec = decode(noisy,n,k,"hamming/decimal");
  if (any(dec != msg))
    error("FAILED");
  endif
catch
end
fprintf("PASSED\n");

The gfweight call still takes a while with m=8, so you might prefer to disable
it. I believe this removes all of the restrictions on the comms toolbox.

Cheers
David

According to Quentin Spencer <qsp...@ie...> (on 07/08/04):
> This time I tried:
> decode(x,255,247,'hamming')
> and received the following error message:
> error: syndtable: message and codeword length must be less than 32
> error: evaluating assignment expression near line 248, column 5
> error: evaluating if command near line 245, column 7
> error: evaluating if command near line 203, column 5
> error: evaluating if command near line 188, column 3
> error: called from `decode' in file 
> `/usr/share/octave/2.1.57/site/m/octave-forge/comm/decode.m'
> 
> So, it appears some modification of the syndtable function is necessary 
> to make this work for hamming codes larger than the (31,36) code.
> 
> -Quentin
> 
> 
> 
> -------------------------------------------------------
> 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 www.blackhat.com
> _______________________________________________
> 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

[OctDev] usage of imread.m in octave

[Ole J. H. <wat...@ya...>]

Hi.

Octave-Forge has imread.m as part of the signal processing module inside.
I am using imread like this:
X = imread('testimage.jpg');
The testimage.jpg can be found here 
http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/examples/

And imshow(X), will then give me a black-white image, but it's supposed 
to be a colour image.
Why doesn't this works? Where does it fails, what is wrong, and does 
someone have a fix for this?

Oplot-developers have implemented the same thing, but the image popups 
in Oplot instead of ImageMagic. :-)

Cheers,

Ole J.

[OctDev] Pareto, tabulate, histfit

[Alberto T. B. <t-a...@li...>]

new functions:

Pareto charts
frequency table
histogram with normal density plot

Re: [OctDev] More limitations in coding functions

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

Reading the comment in syndtable.cc 

  // Could convert this to unsigned long long, but there isn't much point.
  // the syndrome table can already have 2^32 rows with n columns, which
  // is already unrealistically large. The result is DON'T use this with
  // large BCH codes!!!!

you'll see why this limitation exists. In fact the problem is not the
syndrome table itself, but the calculation of all possible ways to have
n bit errors in a codeword which can be extremely large. I imagine there
is a better way to calculate the syndrome table and in fact until this
constraint is relaxed BCH and RS codes are the best bet :-) ...

If you have any better way to calculate the syndrome table I'd be
happy to get some advice..

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

[OctDev] More limitations in coding functions

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

This time I tried:
decode(x,255,247,'hamming')
and received the following error message:
error: syndtable: message and codeword length must be less than 32
error: evaluating assignment expression near line 248, column 5
error: evaluating if command near line 245, column 7
error: evaluating if command near line 203, column 5
error: evaluating if command near line 188, column 3
error: called from `decode' in file 
`/usr/share/octave/2.1.57/site/m/octave-forge/comm/decode.m'

So, it appears some modification of the syndtable function is necessary 
to make this work for hamming codes larger than the (31,36) code.

-Quentin

[OctDev] get_authors hacker

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

Does anyone want to 'own' the author list?

The list is extracted automatically from the source
by the perl program admin/get_authors.

If somebody wants to update the code and/or
the source files so that all the authors are
being properly attributed I would be much obliged.

Thanks in advance,

Paul Kienzle
pki...@us...

[OctDev] octave-forge release candidate

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

I put an octave-forge release candidate on the source-forge
download site today.  We will have at least one more pass
since interp2() seems to be broken.

Meanwhile could all the first-adopters out there please give
it a try on your architecture and report what is broken.  Also,
pick a few functions (like interp2) which do not have test cases
for them and write a few so that at least we know that every
function runs a little bit.

Thanks,

Paul Kienzle
pki...@us...

Re: [OctDev] Re: make clean

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

Dapr=E8s Paul Kienzle <pki...@us...> (le 07/07/2004):
> Yeah, I was thinking about what would be required this morning
> and deciding that it wasn't going to be so easy as I thought.  Any
> idea how Octave does it?  After all, Makefile doesn't exist before
> configure is run.  Having a 'dist.sh' script in each subdirectory
> that needs it is another way independent of make of doing this,
> though since we always have 'Makefile' around in octave-forge
> this isn't so compelling.

The "dist" target in octMakefile within octave is nearly 40 lines long.
It looks like it does much of the work itself rather than handing things
off to the subdirectories. I don't think this is an option in octave-forg=
e.

The only problem is the need of the variables defined in Makeconf for
something that needs to be built for the dist target. This hopefully
shouldn't come up that often. The fix I have if pretty generic. The
tests for the args of TEXINFO etc are perhaps the only place things
might cause a problem (if you have the tools installed that this). These
tests were more my paranoia than anything, so the effect disabling of=20
these for the dist target in main/comm and main/fixed is probably not
an issue.

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

Re: [OctDev] Re: make clean

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

Yeah, I was thinking about what would be required this morning
and deciding that it wasn't going to be so easy as I thought.  Any
idea how Octave does it?  After all, Makefile doesn't exist before
configure is run.  Having a 'dist.sh' script in each subdirectory
that needs it is another way independent of make of doing this,
though since we always have 'Makefile' around in octave-forge
this isn't so compelling.

Thanks,

- Paul

On Jul 7, 2004, at 5:45 AM, David Bateman wrote:

> Ok, I've committed a change that builds the fixed and comm packages
> docs as part of the "make dist" target and removed the texinfo and
> postscript files from the repository.
>
> I had to allow the dist, distclean and clean targets to propogate to
> the subdirectories even without the Makeconf file being available.
> For this reason I had to change "include Makeconf" to "sinclude
> Makeconf" basically everywhere.
>
> If the Makeconf file exists when you do the "make dist" this is the
> surest way to get things right. Otherwise the variables MKTEXI, DVIPS,
> etc are set to default values in main/{comm,fixed}/doc/Makefile
> that should probably work, but no guarentees.
>
> Regards
> David
>
> Dapr=E8s Paul Kienzle <pki...@us...> (le =
07/07/2004):
>>
>> On Jul 6, 2004, at 8:29 AM, David Bateman wrote:
>>
>>> According to Paul Kienzle <pki...@us...> (on
>>> 07/06/04):
>>>>
>>>> My preference is to put the docs somewhere on the website for
>>>> those who can't build them, and use something like 'if not built
>>>> then echo "Docs not built.  Get them from octave.sf.net"'.
>>>
>>> Errr, that's harder due to the fact that I'd have to test for the
>>> presence of perl and a properly installed texinfo package. The way
>>> I proposed in what the octave distributions do themselves, and so
>>> I'd be happy with this way. Also I install the texinfo file, so that
>>> online help is available from within octave itself. If the file is
>>> not built or not part of the distribution, then this online help
>>> won't be available.....
>>>
>>> In any case I checked in the change that includes the postscript and
>>> texinfo help files as part of the distribution. If you really think=20=

>>> its
>>> a bad idea given the above, I'll have to rethink what to do...
>>
>> Okay, how about we have a 'make dist' target that builds these
>> and cleans up any intermediate files.  That way people installing
>> the release tarball have what they need and only the release
>> manager needs to have all the required tools installed.   You are
>> welcome to release as often as you need.
>>
>> Paul Kienzle
>> pki...@us...
>>
>>
>>
>> -------------------------------------------------------
>> 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 www.blackhat.com
>> _______________________________________________
>> 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)
> 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] Re: make clean

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

Ok, I've committed a change that builds the fixed and comm packages
docs as part of the "make dist" target and removed the texinfo and
postscript files from the repository.=20

I had to allow the dist, distclean and clean targets to propogate to
the subdirectories even without the Makeconf file being available.
For this reason I had to change "include Makeconf" to "sinclude
Makeconf" basically everywhere.=20

If the Makeconf file exists when you do the "make dist" this is the
surest way to get things right. Otherwise the variables MKTEXI, DVIPS,
etc are set to default values in main/{comm,fixed}/doc/Makefile
that should probably work, but no guarentees.

Regards
David

Dapr=E8s Paul Kienzle <pki...@us...> (le 07/07/2004):
>=20
> On Jul 6, 2004, at 8:29 AM, David Bateman wrote:
>=20
> >According to Paul Kienzle <pki...@us...> (on=20
> >07/06/04):
> >>
> >>My preference is to put the docs somewhere on the website for
> >>those who can't build them, and use something like 'if not built
> >>then echo "Docs not built.  Get them from octave.sf.net"'.
> >
> >Errr, that's harder due to the fact that I'd have to test for the
> >presence of perl and a properly installed texinfo package. The way
> >I proposed in what the octave distributions do themselves, and so
> >I'd be happy with this way. Also I install the texinfo file, so that
> >online help is available from within octave itself. If the file is
> >not built or not part of the distribution, then this online help
> >won't be available.....
> >
> >In any case I checked in the change that includes the postscript and
> >texinfo help files as part of the distribution. If you really think it=
s
> >a bad idea given the above, I'll have to rethink what to do...
>=20
> Okay, how about we have a 'make dist' target that builds these
> and cleans up any intermediate files.  That way people installing
> the release tarball have what they need and only the release
> manager needs to have all the required tools installed.   You are
> welcome to release as often as you need.
>=20
> Paul Kienzle
> pki...@us...
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> 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

Re: [OctDev] Re: make clean

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

A "make dist" target seems like a pretty good idea. At this point I think
only the docs in main/comm/doc and main/fixed/doc would need to be built
for a distribution.=20

In any case with a quick look at this, it's not straightforward since the
docs need Makeconf to identify where to find the scripts mktexi and mkdoc.
However, Makeconf is removed with a "make dist". What I think would be th=
e
easiest fix is to recreate the variable MKDOC and MKTEXI if they don't
exist, due to the fact that Makeconf doesn't exist..

I'm thinking about it..

D.


Dapr=E8s Paul Kienzle <pki...@us...> (le 07/07/2004):
>=20
> On Jul 6, 2004, at 8:29 AM, David Bateman wrote:
>=20
> >According to Paul Kienzle <pki...@us...> (on=20
> >07/06/04):
> >>
> >>My preference is to put the docs somewhere on the website for
> >>those who can't build them, and use something like 'if not built
> >>then echo "Docs not built.  Get them from octave.sf.net"'.
> >
> >Errr, that's harder due to the fact that I'd have to test for the
> >presence of perl and a properly installed texinfo package. The way
> >I proposed in what the octave distributions do themselves, and so
> >I'd be happy with this way. Also I install the texinfo file, so that
> >online help is available from within octave itself. If the file is
> >not built or not part of the distribution, then this online help
> >won't be available.....
> >
> >In any case I checked in the change that includes the postscript and
> >texinfo help files as part of the distribution. If you really think it=
s
> >a bad idea given the above, I'll have to rethink what to do...
>=20
> Okay, how about we have a 'make dist' target that builds these
> and cleans up any intermediate files.  That way people installing
> the release tarball have what they need and only the release
> manager needs to have all the required tools installed.   You are
> welcome to release as often as you need.
>=20
> Paul Kienzle
> pki...@us...
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> 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

[OctDev] Re: Off-by-one error in bmpwrite.m?

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

On Jul 5, 2004, at 6:28 AM, Per Persson wrote:

> Hi,
> in preparing a new image.m for Mac OS X (based on code from J. Koski)  
> that uses bmpwrite(), and I think I've found a bug in bmpwrite.m.
>
> The color for {R,G,B}={1, 1, 1} is random on OS X and I think the  
> problem is that the index into colormap in a .bmp file is zero-based  
> (couldn't find a definitive authority). The help for bmpwrite doesn't  
> state that a zero-based index is used, so I assume that the patch  
> below is the right fix.

Here's a pretty good authority that says you are right:

	http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Please update the server.

Thanks,

Paul Kienzle
pki...@us...

>
> /Per
>
> Index: main/image/bmpwrite.m
> ===================================================================
> RCS file: /cvsroot/octave/octave-forge/main/image/bmpwrite.m,v
> retrieving revision 1.2
> diff -u -d -b -w -r1.2 bmpwrite.m
> --- main/image/bmpwrite.m       27 Nov 2002 08:40:10 -0000      1.2
> +++ main/image/bmpwrite.m       5 Jul 2004 10:16:01 -0000
> @@ -37,7 +37,7 @@
>
>      ## raster image, each line on a 32-bit boundary, padded with zeros
>      ## lines written bottom to top.
> -     
> fwrite(file,postpad(flipud(x)',ceil(columns(x)/4)*4),"uchar",0,arch);
> +     
> fwrite(file,postpad(flipud(x-1)',ceil(columns(x)/ 
> 4)*4),"uchar",0,arch);
>      fclose(file);
>  endfunction
>

Re: [OctDev] Re: make clean

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

On Jul 6, 2004, at 8:29 AM, David Bateman wrote:

> According to Paul Kienzle <pki...@us...> (on 
> 07/06/04):
>>
>> My preference is to put the docs somewhere on the website for
>> those who can't build them, and use something like 'if not built
>> then echo "Docs not built.  Get them from octave.sf.net"'.
>
> Errr, that's harder due to the fact that I'd have to test for the
> presence of perl and a properly installed texinfo package. The way
> I proposed in what the octave distributions do themselves, and so
> I'd be happy with this way. Also I install the texinfo file, so that
> online help is available from within octave itself. If the file is
> not built or not part of the distribution, then this online help
> won't be available.....
>
> In any case I checked in the change that includes the postscript and
> texinfo help files as part of the distribution. If you really think its
> a bad idea given the above, I'll have to rethink what to do...

Okay, how about we have a 'make dist' target that builds these
and cleans up any intermediate files.  That way people installing
the release tarball have what they need and only the release
manager needs to have all the required tools installed.   You are
welcome to release as often as you need.

Paul Kienzle
pki...@us...

Re: [OctDev] new release?

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

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 <qsp...@ie...> (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 <qsp...@ie...> (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                                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

Re: [OctDev] new release?

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

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 <qsp...@ie...> (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
>

Re: [OctDev] Re: make clean

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

According to Paul Kienzle <pki...@us...> (on 07/06/04):
> 
> My preference is to put the docs somewhere on the website for
> those who can't build them, and use something like 'if not built
> then echo "Docs not built.  Get them from octave.sf.net"'.

Errr, that's harder due to the fact that I'd have to test for the 
presence of perl and a properly installed texinfo package. The way
I proposed in what the octave distributions do themselves, and so
I'd be happy with this way. Also I install the texinfo file, so that
online help is available from within octave itself. If the file is
not built or not part of the distribution, then this online help
won't be available.....

In any case I checked in the change that includes the postscript and
texinfo help files as part of the distribution. If you really think its
a bad idea given the above, I'll have to rethink what to do...

Regards
David

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

[OctDev] Re: make clean

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

On Jul 6, 2004, at 5:14 AM, David Bateman wrote:

> Paul,
>
> On another point, as a large number of my problems seem to come from
> the documentation to the communciations and fixed point toolboxes,
> would it make sense to check in copies of the postscript and the
> texinfo files, so that they wouldn't need to be built by a normal
> user? This would mean fooling with "make clean" in the documentation
> so that they aren't removed accidentally. Would this be a worthwhile
> change?

My preference is to put the docs somewhere on the website for
those who can't build them, and use something like 'if not built
then echo "Docs not built.  Get them from octave.sf.net"'.

Other ideas?

- Paul

[OctDev] Off-by-one error in bmpwrite.m?

[Per P. <per...@ma...>]

Hi,
in preparing a new image.m for Mac OS X (based on code from J. Koski) 
that uses bmpwrite(), and I think I've found a bug in bmpwrite.m.

The color for {R,G,B}={1, 1, 1} is random on OS X and I think the 
problem is that the index into colormap in a .bmp file is zero-based 
(couldn't find a definitive authority). The help for bmpwrite doesn't 
state that a zero-based index is used, so I assume that the patch below 
is the right fix.

/Per

Index: main/image/bmpwrite.m
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/image/bmpwrite.m,v
retrieving revision 1.2
diff -u -d -b -w -r1.2 bmpwrite.m
--- main/image/bmpwrite.m       27 Nov 2002 08:40:10 -0000      1.2
+++ main/image/bmpwrite.m       5 Jul 2004 10:16:01 -0000
@@ -37,7 +37,7 @@

      ## raster image, each line on a 32-bit boundary, padded with zeros
      ## lines written bottom to top.
-    
fwrite(file,postpad(flipud(x)',ceil(columns(x)/4)*4),"uchar",0,arch);
+    
fwrite(file,postpad(flipud(x-1)',ceil(columns(x)/4)*4),"uchar",0,arch);
      fclose(file);
  endfunction