octave-dev — GNU Octave developers' list

[OctDev] imrotate.m

[Todd N. <to...@gm...>]

Hello,

I made a change where I round the corners matrix.  In the tests that I
performed it seems to provide for better rotations.  I also modified
the special cases so that it doesn't rely on rot90, etc.

octave:160> a
a =

   1   2   3   4   5
   6   7   8   9  10
  11  12  13  14  15
  16  17  18  19  20
  21  22  23  24  25

Pre Patch: 

octave:161> imrotate(a,45)
ans =

   0   0   0   4  10   0   0   0
   0   0   3   9   9  15   0   0
   0   2   7   8  14  19  20   0
   0   6   7  12  18  19  24   0
   0   0  11  17  17  23   0   0
   0   0   0  16  22   0   0   0

Post Patch:

octave:162> imrotate(a,45)
ans =

   0   0   4   5  10   0   0
   0   3   3   9  15  15   0
   1   2   8  13  14  20  25
   1   6  12  13  18  24  25
   0  11  11  17  23  23   0
   0   0  16  21  22   0   0


Todd

[OctDev] Re: octave-dev mailing list

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

Todd,

octave-dev is indeed active, and I did see your post on imrotate. I
don't see anything about imresize.  help-octave and bug-octave are
much more active.

Your patch looks okay, though I would do mod 360 regardless of whether
theta was negative.

I'm disappointed that the current imrotate gives an incorrect result you
showed in your example, and would like to see that addressed as well.
For example, what happens if the angle is 269.999999?  Discretizing
the angle before checking if it is 270 would be useful.

Thanks,

- Paul

On Feb 9, 2005, at 11:08 PM, Todd Neal wrote:

> Hello,
>
> I saw on octave-maintainers that you are involved in Octave-forge. I
> sent an email to the  octave-dev list on Sourceforge and haven't
> recevied any responses.  Is there a more active list ?
>
>
> I am also working on imresize.m clone for Octave and wanted to discuss
> it with someone else who was interested.
>
>
> Thanks, Todd
>

[OctDev] Bug in imrotate.m

[Todd N. <to...@gm...>]

Hello,

I was looking at imrotate and tried it on a simple test matrix and got
the wrong result:

octave:1> a=[1,2,3;4,5,6;7,8,9]
a =

  1  2  3
  4  5  6
  7  8  9

octave:2> imrotate(a,270)
ans =

  0  7  4  1
  8  5  2  2
  9  6  3  0

I wrote a patch to handle the special cases where rotations are of
angles divisible by 90, it speeds up these rotations tremendously and
returns the correct result.

Before Patch:
octave:5> a=rand(1000);
octave:6> tic;imrotate(a,90);toc
ans = 16.821

After Patch:
octave:7> tic;imrotate(a,90);toc
ans = 0.37471


Thanks, 
Todd

[OctDev] New imrotate: nearest, bilinear, bicubic, Fourier

[Justus P. <Jus...@UL...>]

Hi,

Here's a new version of imrotate() for review and inclusion in
octave-forge.

Here are the changes with respect to the previous version:

- Integration of Jeff Orchard's original Fourier-based method into the
  same interface by mapping to his original file. The latter should be
  hidden from the user in some way (are there private/ directories in
  Octave as there are in Matlab?).

- Addition of bicubic interpolation. This code is not limited to this
  particular use and could perhaps be moved into a separate file. The
  source data must be a matrix, and the interpolated points can be
  anywhere within that grid (in some way, this is about half way
  between interp2() and griddata()).

- My previous version rounded the target intensities to integer
  values. This is no longer done. Also, bicubically interpolated gray
  values may overshoot and thus exceed the [0,256) range. The same
  holds for the Fourier method.

I attach a comprehensive test suite. Run "testimrotate".
The files that should go into CVS are imrotate.m and imrotate_Fourier.m.

Cheers,
Justus

[OctDev] Re: pkg-octave project created at Alioth/Debian

[Rafa <raf...@uc...>]

Hello,

my name is Jose Rafael Rodriguez Galvan (yes, another Rafael :).
I am a profesor in the Department of Mathematics at the C=E1diz
University (Spain) and Director of the OSLUCA [0], the Free Software
Office of the C=E1diz University.

I have been using Debian for years and I think it's a good moment for
helping. I am not a DD (though I wold like, some day, to be),=20
my work in debian comes down to packaging wxMaxima, a wxWidgets
interface for the CAS Maxima, which I'm intending to maintain [1].

I have been always interested in free software related to Mathematics
and Engineering, concretely I have used Octave, but I have never helped
in it's development. Maintaining octave and related packages sounds good
for me, so you can count on my help for anything you consider necessary.

Rafa.

El mi=E9, 19-01-2005 a las 09:15, Rafael Laboissiere escribi=F3:
> [N.B.: I am reposting the message below outside the thread initiated by
>   Dirk Eddelbuettel.  I apologize for the cross-posting, but I am
>   trying to reach the most people I can.]
>=20
> The pkg-octave project has just been created at Alioth (alioth.debian.org=
),
> as well as a mailing list for general development discussion
> (pkg...@li...).  I set the Reply-To for this
> message to that list, so that further discussion can continue there. =20
>=20
> The goal is to encourage co-maintenance of as many Debian Octave-related
> packages in the pkg-octave project at Alioth as we can.  Developing a com=
mon
> infrastructure for add-on Octave package building is also in our plans.  =
Any
> person (either Debian or non-Debian maintainer/developer) interested in
> Octave related Debian packages is encouraged to join this project.
>=20
> --=20
> Rafael

[0] http://softwarelibre.uca.es
[1] http://lists.debian.org/debian-devel/2005/01/msg01157.html

--=20
J. Rafael Rodriguez Galvan.
OSLUCA, http://softwarelibre.uca.es
  Oficina de Software Libre, Universidad de C=E1diz.
  Free Software Office, Cadiz University, Spain.

[OctDev] pkg-octave project created at Alioth/Debian

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

[N.B.: I am reposting the message below outside the thread initiated by
  Dirk Eddelbuettel.  I apologize for the cross-posting, but I am
  trying to reach the most people I can.]

The pkg-octave project has just been created at Alioth (alioth.debian.org),
as well as a mailing list for general development discussion
(pkg...@li...).  I set the Reply-To for this
message to that list, so that further discussion can continue there.  

The goal is to encourage co-maintenance of as many Debian Octave-related
packages in the pkg-octave project at Alioth as we can.  Developing a common
infrastructure for add-on Octave package building is also in our plans.  Any
person (either Debian or non-Debian maintainer/developer) interested in
Octave related Debian packages is encouraged to join this project.

-- 
Rafael

Re: [OctDev] Re: Bug#290343: octave-forge: symbolic manipulation triggers segfault panic

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

This is not really a bug, except maybe in documentation, or lack 
thereof.
Arguably anything which makes a package harder to use than it could be 
is
a bug, but I have no plans to address that.

You need to say 'symbols' before using the symbolic package.  Putting
it into your .octaverc file if you are often using the symbolic package
would be useful.

	octave:1> symbols

Then you need to define you symbolic variables:

	octave:2> x = sym('x')
	x =

	x

And the expressions which use them:

	octave:3> A = Cos(x)
	A =

	cos(x)

Before you can manipulate those expressions:

	octave:4> differentiate(A,x)
	ans =
	
	-sin(x)

Note that if you don't like using Cos(x) you can use the dispatch
mechanism to define cos(x) -> Cos(x) for symbolic x as follows:

	octave:5> dispatch('cos','Cos','ex')
	octave:6> A = cos(x)
	A =

	cos(x)
	octave:7> differentiate(A,x)
	ans =

	-sin(x)

- Paul


On Jan 13, 2005, at 10:24 PM, Dirk Eddelbuettel wrote:

> On Thu, Jan 13, 2005 at 10:09:30AM -0700, Andre Lehovich wrote:
>> Package: octave-forge
>> Version: 2004.11.16-3
>> Severity: normal
>>
>> While experimenting with symbolic manipulation I was able to
>> crash octave.  This may be due to operator error; I don't
>> know how to use octave-forge's symbolic toolbox, so I'm just
>> feeding random stuff at it.  Here is a transcript:
>>
>> |# 0 home ~; octave
>> |GNU Octave, version 2.1.64 (i386-pc-linux-gnu).
>> |Copyright (C) 2004 John W. Eaton.
>> |This is free software; see the source code for copying conditions.
>> |There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
>> |FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.
>> |
>> |Additional information about Octave is available at 
>> http://www.octave.org.
>> |
>> |Please contribute if you find this software useful.
>> |For more information, visit http://www.octave.org/help-wanted.html
>> |
>> |Report bugs to <bu...@oc...> (but first, please read
>> |http://www.octave.org/bugs.html to learn how to write a helpful 
>> report).
>> |
>> |octave:1> A = sym('Cos(x)')
>> |A =
>> |
>> |Cos(x)
>> |octave:2> x = sym('x')
>> |x =
>> |
>> |x
>> |octave:3> differentiate(A,x)
>> |panic: Segmentation fault -- stopping myself...
>> |attempting to save variables to `octave-core'...
>> |error: octave_base_value::save_binary(): wrong type argument `ex'
>> |save to `octave-core' complete
>> |Segmentation fault
>
> Ok, thanks, will pass that along.
>
> Dirk
>
>
>> -- System Information:
>> Debian Release: 3.1
>>   APT prefers testing
>>   APT policy: (900, 'testing')
>> Architecture: i386 (i586)
>> Kernel: Linux 2.4.28
>> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>>
>> Versions of packages octave-forge depends on:
>> ii  atlas3-base [liblapack.s 3.6.0-19        Automatically Tuned 
>> Linear Algebra
>> ii  fftw3                    3.0.1-11        Library for computing 
>> Fast Fourier
>> ii  libc6                    2.3.2.ds1-20    GNU C Library: Shared 
>> libraries an
>> ii  libcln3                  1.1.9-1         Class Library for 
>> Numbers (C++)
>> ii  libg2c0                  1:3.3.5-5       Runtime library for GNU 
>> Fortran 77
>> ii  libgcc1                  1:3.4.3-6       GCC support library
>> ii  libginac1.3              1.3.0-1         The GiNaC framework 
>> (runtime libra
>> ii  libgmp3                  4.1.4-5         Multiprecision 
>> arithmetic library
>> ii  libgsl0                  1.5-2           The GNU Scientific 
>> Library (GSL) -
>> ii  libhdf5-serial-1.6.2-0 [ 1.6.2-3         Hierarchical Data Format 
>> 5 (HDF5)
>> ii  libice6                  4.3.0.dfsg.1-10 Inter-Client Exchange 
>> library
>> ii  libjpeg62                6b-9            The Independent JPEG 
>> Group's JPEG
>> ii  libncurses5              5.4-4           Shared libraries for 
>> terminal hand
>> ii  libpng12-0               1.2.8rel-1      PNG library - runtime
>> ii  libqhull5                2003.1-1        Calculate convex hulls 
>> and related
>> ii  libreadline4             4.3-11          GNU readline and history 
>> libraries
>> ii  libsm6                   4.3.0.dfsg.1-10 X Window System Session 
>> Management
>> ii  libstdc++5               1:3.3.5-5       The GNU Standard C++ 
>> Library v3
>> ii  libx11-6                 4.3.0.dfsg.1-10 X Window System protocol 
>> client li
>> ii  octave2.1                2.1.64-1        The GNU Octave language 
>> for numeri
>> ii  xlibs                    4.3.0.dfsg.1-10 X Keyboard Extension 
>> (XKB) configu
>> ii  zlib1g                   1:1.2.2-3       compression library - 
>> runtime
>>
>> -- no debconf information
>
> -- 
> Better to have an approximate answer to the right question than a 
> precise
> answer to the wrong question.  --  John Tukey as quoted by John 
> Chambers
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] Re: 'text' problems

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

Stefan van der Walt wrote:

>On Fri, Dec 03, 2004 at 03:12:40AM -0600, Pascal A. Dupuis wrote:
>  
>
>>atstr = sprintf("%f,%f", position(1),position(2));
>>
>>str = sprintf("%f", 1e-9) 
>>results in ... 0!
>>
>>The following patch seems to work for me:
>>
>>---------------------------------------------------
>>--- text.m.orig 2004-12-03 10:08:10.000000000 +0100
>>+++ text.m      2004-12-03 10:08:42.000000000 +0100
>>@@ -147,9 +147,9 @@
>>     font = "";
>>   endif
>>   if position(3)!=0,
>>-    atstr = sprintf("%f,%f,%f", position(1),position(2),position(3));
>>+    atstr = sprintf("%e,%e,%e", position(1),position(2),position(3));
>>   else
>>-    atstr = sprintf("%f,%f", position(1),position(2));
>>+    atstr = sprintf("%e,%e", position(1),position(2));
>>   endif
>>   command = sprintf('gset label "%s" at %s %s %s %s%s',
>>                    str, units, atstr, align, rotate, font);
>>----------------------------------------------------------
>>    
>>
>
>If you do that, bigger numbers will also be printed in engineering
>notation.  I.e.
>
>octave:22> sprintf("%e\n", 1024)
>ans = 1.024000e+03
>
>What is the most common behaviour required of "text"?
>
>Regards
>Stefan
>  
>
Stefan the "%e" was replaced with "%g" in octave-forge and committed 
when Pascale reported the problem. Using "%g" should give the best of 
both worlds...

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] Re: 'text' problems

[Laurent M. <lau...@mo...>]

On Wed, 12 Jan 2005 15:28:56 +0200
Stefan van der Walt <st...@su...> wrote:
> On Fri, Dec 03, 2004 at 03:12:40AM -0600, Pascal A. Dupuis wrote:
> > atstr = sprintf("%f,%f", position(1),position(2));
> > 
> > str = sprintf("%f", 1e-9) 
> > results in ... 0!
> > 
> > The following patch seems to work for me:
> > 
> > ---------------------------------------------------
> > --- text.m.orig 2004-12-03 10:08:10.000000000 +0100
> > +++ text.m      2004-12-03 10:08:42.000000000 +0100
> > @@ -147,9 +147,9 @@
> >      font = "";
> >    endif
> >    if position(3)!=0,
> > -    atstr = sprintf("%f,%f,%f", position(1),position(2),position(3));
> > +    atstr = sprintf("%e,%e,%e", position(1),position(2),position(3));
> >    else
> > -    atstr = sprintf("%f,%f", position(1),position(2));
> > +    atstr = sprintf("%e,%e", position(1),position(2));
> >    endif
> >    command = sprintf('gset label "%s" at %s %s %s %s%s',
> >                     str, units, atstr, align, rotate, font);
> > ----------------------------------------------------------
> 
> If you do that, bigger numbers will also be printed in engineering
> notation.  I.e.
> 
> octave:22> sprintf("%e\n", 1024)
> ans = 1.024000e+03


May we use sprintf("%g\n", 1024) ?

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

Re: [OctDev] Greylevel morphological operations + other ideas

[Etienne G. <et...@cs...>]

  Hi Stefan,

On Fri, Jan 14, 2005 at 01:48:50AM +0200, Stefan van der Walt wrote:
# Hi Etienne
# 
# Adding grey-level morphology is a good idea.  Does MATLAB have any
# similar functions?  What sort of interface do they use?
   ^^^
  Not last time I checked. We're free not to imitate braindead
behavior, and invent our own, like

   gl_erode(im,radii)
   gl_dilate(im,radii)
   gl_morph(im,radius1,operation1,...,radiusS,operationS) 


# We should really also be looking at re-implementing octave-forge's
# image handling.  Now that octave supports uint16 etc., we do not need
# to guess image depths anymore.  Colour images should be stored as
# MxNx3 matrices of the correct value type (not as three different images).

  Since you mentionned the other product, is that how Matlab does it?
 
# Unless someone else feels highly motivated, I will start on this
# sometime closer to February (maybe by first adding some rudimentary
# unit tests to all imaging functions, to track what breaks with the
# changes).
# 
# Another feature I would like to add is the handling of videos.  I was
# thinking of using libavifile -- does anyone here have any experience
# with it?

  Not me :-(.

  Cheers,

  Etienne
 
# Finally, the image histogram equalisation function is still not
# working correctly.  But fixing it will be a lot easier once the image
# types are implemented.
# 
# Regards
# Stefan
# 
# On Thu, Jan 06, 2005 at 01:48:36PM -0500, Etienne Grossmann wrote:
# > 
# > 
# >   Hi All,
# > 
# > I consider adding some greylevel image morphology functionality to
# > octave-forge. I have this function:
# > 
# > 
# > ## im2 = g_all (im,scales)       - Greylevel morphological opertations
# > ##
# > ##      Open, close, erode and dilate greylevel image im at various scales.
# > ##      Dilation at scale s is the greatest greylevel within radius s.
# > ##      Erosion  at scale s is the least greylevel within radius s.
# > ##      Opening  is erosion followed by dilation (all at the same scale).
# > ##      Closing  is dilation followed by erosion (all at the same scale).
# > ## 
# > ## im     : R x C       : Image
# > ## scales : 1 x S       : Scales at which morphological operations are performed
# > ##
# > ## im2     : R x C x 4*S : Opened (4*i+1), closed (4*i+2), eroded (4*i+3) and
# > ##                        dilated (4*i+4) images (i in 0:S-1)
# > ##
# > ## See also: g_open_close.
# > ## Todo    : Make this function more efficient.
# > 
# >   Any suggestions on other possible interfaces? I can also put
# > fucs for individual operation.
# > 
# >    Cheers,
# > 
# >   Etienne
[snip]

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

Re: [OctDev] Greylevel morphological operations + other ideas

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

Hi Etienne

Adding grey-level morphology is a good idea.  Does MATLAB have any
similar functions?  What sort of interface do they use?

We should really also be looking at re-implementing octave-forge's
image handling.  Now that octave supports uint16 etc., we do not need
to guess image depths anymore.  Colour images should be stored as
MxNx3 matrices of the correct value type (not as three different images).

Unless someone else feels highly motivated, I will start on this
sometime closer to February (maybe by first adding some rudimentary
unit tests to all imaging functions, to track what breaks with the
changes).

Another feature I would like to add is the handling of videos.  I was
thinking of using libavifile -- does anyone here have any experience
with it?

Finally, the image histogram equalisation function is still not
working correctly.  But fixing it will be a lot easier once the image
types are implemented.

Regards
Stefan

On Thu, Jan 06, 2005 at 01:48:36PM -0500, Etienne Grossmann wrote:
> 
> 
>   Hi All,
> 
> I consider adding some greylevel image morphology functionality to
> octave-forge. I have this function:
> 
> 
> ## im2 = g_all (im,scales)       - Greylevel morphological opertations
> ##
> ##      Open, close, erode and dilate greylevel image im at various scales.
> ##      Dilation at scale s is the greatest greylevel within radius s.
> ##      Erosion  at scale s is the least greylevel within radius s.
> ##      Opening  is erosion followed by dilation (all at the same scale).
> ##      Closing  is dilation followed by erosion (all at the same scale).
> ## 
> ## im     : R x C       : Image
> ## scales : 1 x S       : Scales at which morphological operations are performed
> ##
> ## im2     : R x C x 4*S : Opened (4*i+1), closed (4*i+2), eroded (4*i+3) and
> ##                        dilated (4*i+4) images (i in 0:S-1)
> ##
> ## See also: g_open_close.
> ## Todo    : Make this function more efficient.
> 
>   Any suggestions on other possible interfaces? I can also put
> fucs for individual operation.
> 
>    Cheers,
> 
>   Etienne
> 
> -- 
> Etienne Grossmann ------ http://www.cs.uky.edu/~etienne
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] Re: 'text' problems

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

On Fri, Dec 03, 2004 at 03:12:40AM -0600, Pascal A. Dupuis wrote:
> atstr = sprintf("%f,%f", position(1),position(2));
> 
> str = sprintf("%f", 1e-9) 
> results in ... 0!
> 
> The following patch seems to work for me:
> 
> ---------------------------------------------------
> --- text.m.orig 2004-12-03 10:08:10.000000000 +0100
> +++ text.m      2004-12-03 10:08:42.000000000 +0100
> @@ -147,9 +147,9 @@
>      font = "";
>    endif
>    if position(3)!=0,
> -    atstr = sprintf("%f,%f,%f", position(1),position(2),position(3));
> +    atstr = sprintf("%e,%e,%e", position(1),position(2),position(3));
>    else
> -    atstr = sprintf("%f,%f", position(1),position(2));
> +    atstr = sprintf("%e,%e", position(1),position(2));
>    endif
>    command = sprintf('gset label "%s" at %s %s %s %s%s',
>                     str, units, atstr, align, rotate, font);
> ----------------------------------------------------------

If you do that, bigger numbers will also be printed in engineering
notation.  I.e.

octave:22> sprintf("%e\n", 1024)
ans = 1.024000e+03

What is the most common behaviour required of "text"?

Regards
Stefan

[OctDev] Re: Bug#290343: octave-forge: symbolic manipulation triggers segfault panic

[Dirk E. <ed...@de...>]

On Thu, Jan 13, 2005 at 10:09:30AM -0700, Andre Lehovich wrote:
> Package: octave-forge
> Version: 2004.11.16-3
> Severity: normal
> 
> While experimenting with symbolic manipulation I was able to
> crash octave.  This may be due to operator error; I don't
> know how to use octave-forge's symbolic toolbox, so I'm just
> feeding random stuff at it.  Here is a transcript:
> 
> |# 0 home ~; octave
> |GNU Octave, version 2.1.64 (i386-pc-linux-gnu).
> |Copyright (C) 2004 John W. Eaton.
> |This is free software; see the source code for copying conditions.
> |There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
> |FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.
> |
> |Additional information about Octave is available at http://www.octave.org.
> |
> |Please contribute if you find this software useful.
> |For more information, visit http://www.octave.org/help-wanted.html
> |
> |Report bugs to <bu...@oc...> (but first, please read
> |http://www.octave.org/bugs.html to learn how to write a helpful report).
> |
> |octave:1> A = sym('Cos(x)')
> |A =
> |
> |Cos(x)
> |octave:2> x = sym('x')
> |x =
> |
> |x
> |octave:3> differentiate(A,x)
> |panic: Segmentation fault -- stopping myself...
> |attempting to save variables to `octave-core'...
> |error: octave_base_value::save_binary(): wrong type argument `ex'
> |save to `octave-core' complete
> |Segmentation fault

Ok, thanks, will pass that along.

Dirk


> -- System Information:
> Debian Release: 3.1
>   APT prefers testing
>   APT policy: (900, 'testing')
> Architecture: i386 (i586)
> Kernel: Linux 2.4.28
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> 
> Versions of packages octave-forge depends on:
> ii  atlas3-base [liblapack.s 3.6.0-19        Automatically Tuned Linear Algebra
> ii  fftw3                    3.0.1-11        Library for computing Fast Fourier
> ii  libc6                    2.3.2.ds1-20    GNU C Library: Shared libraries an
> ii  libcln3                  1.1.9-1         Class Library for Numbers (C++)
> ii  libg2c0                  1:3.3.5-5       Runtime library for GNU Fortran 77
> ii  libgcc1                  1:3.4.3-6       GCC support library
> ii  libginac1.3              1.3.0-1         The GiNaC framework (runtime libra
> ii  libgmp3                  4.1.4-5         Multiprecision arithmetic library
> ii  libgsl0                  1.5-2           The GNU Scientific Library (GSL) -
> ii  libhdf5-serial-1.6.2-0 [ 1.6.2-3         Hierarchical Data Format 5 (HDF5) 
> ii  libice6                  4.3.0.dfsg.1-10 Inter-Client Exchange library
> ii  libjpeg62                6b-9            The Independent JPEG Group's JPEG 
> ii  libncurses5              5.4-4           Shared libraries for terminal hand
> ii  libpng12-0               1.2.8rel-1      PNG library - runtime
> ii  libqhull5                2003.1-1        Calculate convex hulls and related
> ii  libreadline4             4.3-11          GNU readline and history libraries
> ii  libsm6                   4.3.0.dfsg.1-10 X Window System Session Management
> ii  libstdc++5               1:3.3.5-5       The GNU Standard C++ Library v3
> ii  libx11-6                 4.3.0.dfsg.1-10 X Window System protocol client li
> ii  octave2.1                2.1.64-1        The GNU Octave language for numeri
> ii  xlibs                    4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu
> ii  zlib1g                   1:1.2.2-3       compression library - runtime
> 
> -- no debconf information

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers

Re: [OctDev] wiki defaced again

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

One technique that has worked for others is to simply ignore
edits with more than 5 links.  I would also suggest ignoring
edits which come within a few seconds of each other so that
autobots won't be able to easily work around it.  Or maybe
some combination, so that you only allow one link per 15
seconds between edit time and submit time.

If the defacement is coming from a particular site or two, then
a blacklist which rejects any edits containing links to that
URL, or from those URL's which are doing the edits.

Somebody want to look into programming this?

BTW, we may want to consider a switch to mediawiki since it
handles math markup.  E.g.,

	http://en.wikipedia.org/wiki/Discrete_Fourier_transform

They may already have some spam-blocking tools.

- Paul

On Jan 13, 2005, at 7:06 AM, Etienne Grossmann wrote:

>
>   Hi All,
>
> as you may have noticed, it seems our wiki was defaced again,
> presumably because I had left it open. I hope it is fixed now.
>
>   Etienne
>
> -- 
> Etienne Grossmann ------ http://www.cs.uky.edu/~etienne
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] wiki defaced again

[Etienne G. <et...@cs...>]

  Hi All,

as you may have noticed, it seems our wiki was defaced again,
presumably because I had left it open. I hope it is fixed now.

  Etienne

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

Re: [OctDev] randn() broken

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

I was using gcc 3.3.1 and didn't see the problem. I'm now using 3.4.1
and also don't see the problem... If it is a problem with gcc, then
a simplier piece of code than randn that demonstrates the problem would
be needed.

However, as it seems to be fixed the alternative is to check the resolved
bugs in gcc between 3.3.1 and 3.4.1 and see if there is anything that mig=
ht
relate (big task). Alternatively, just ignore the problem and get JWE to
bump the recommended version of gcc to compile octave upto gcc 3.4.x

Regards
David

According to Justus Piater <Jus...@UL...> (on 01/12/05):
> I have some more news:
>=20
> It seems that compiling octave-forge-2004.09.09/FIXES/rand.cc (and
> perhaps later versions) using gcc 3.3.x produces a dysfunctional
> randn(). Older and newer compilers seem to work fine.
>=20
> Is this compatible with our experience out there?
>=20
> Specifically:
> - My faulty setup was compiled using gcc 3.3.2 (i686).
> - Simply recompiling rand.cc using gcc 3.4.1 produced a correct randn().
> - Another user reported similar problems with gcc 3.3.3 and gcc 3.3.5.
> - The same user reported a working version with gcc 3.2.2.
>=20
>=20
> Since the thread is already more than two months old, here's a
> reminder of the problem.
>=20
> Output (faulty) of the following sequence of commands is available at
> http://www.montefiore.ulg.ac.be/~piater/Demos/randn-dots.eps[.gz]:
>=20
> octave> randn("seed", 12345);
> octave> plot(1:10000, randn(1, 10000), ".");
>=20
> The figure demonstrates that the samples are nowhere near Gaussian for
> sample sizes of at least up to several thousands, due to a strange
> sequential clustering effect.
>=20
> --=20
> Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater=
/
> Institut Montefiore, B28        Phone: +32-4-366-2279
> Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> 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] randn() broken

[Justus P. <Jus...@UL...>]

I have some more news:

It seems that compiling octave-forge-2004.09.09/FIXES/rand.cc (and
perhaps later versions) using gcc 3.3.x produces a dysfunctional
randn(). Older and newer compilers seem to work fine.

Is this compatible with our experience out there?

Specifically:
- My faulty setup was compiled using gcc 3.3.2 (i686).
- Simply recompiling rand.cc using gcc 3.4.1 produced a correct randn().
- Another user reported similar problems with gcc 3.3.3 and gcc 3.3.5.
- The same user reported a working version with gcc 3.2.2.


Since the thread is already more than two months old, here's a
reminder of the problem.

Output (faulty) of the following sequence of commands is available at
http://www.montefiore.ulg.ac.be/~piater/Demos/randn-dots.eps[.gz]:

octave> randn("seed", 12345);
octave> plot(1:10000, randn(1, 10000), ".");

The figure demonstrates that the samples are nowhere near Gaussian for
sample sizes of at least up to several thousands, due to a strange
sequential clustering effect.

--=20
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620

Re: [OctDev] Re: Wiki

[Etienne G. <et...@cs...>]

  Done. Try it and let me know.

  Cheers,

  Etienne

On Fri, Jan 07, 2005 at 02:07:16PM -0600, Nick Longo wrote:
# Fortunately (or unfortunately), I have recieved a fixed IP for my
# laptop and I can not edit the wiki from this IP.  My new IP is
# 128.135.72.42
# 
# Yours,
# NPML
# 
# On Wed, 5 Jan 2005, Nick Longo wrote:
# 
# >... and I quote.
# >
# >``Editing not allowed for 128.135.149.118 / stats-dhcp-118.uchicago.edu:
# >user, ip, or network is blocked.
# >
# >Please contact octave-dev at lists.sourceforge.net, specifying your
# >IP, if you would like to contribute to this site''
# >
# >I would like to be able to edit this site.
# >
# >Thanks,
# >Nick
# >
# 
# 
# -------------------------------------------------------
# The SF.Net email is sponsored by: Beat the post-holiday blues
# Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
# It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

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

[OctDev] Re: Wiki

[Nick L. <nmi...@ma...>]

Fortunately (or unfortunately), I have recieved a fixed IP for my
laptop and I can not edit the wiki from this IP.  My new IP is
128.135.72.42

Yours,
NPML

On Wed, 5 Jan 2005, Nick Longo wrote:

> ... and I quote.
>
> ``Editing not allowed for 128.135.149.118 / stats-dhcp-118.uchicago.edu:
> user, ip, or network is blocked.
>
> Please contact octave-dev at lists.sourceforge.net, specifying your
> IP, if you would like to contribute to this site''
>
> I would like to be able to edit this site.
>
> Thanks,
> Nick
>

[OctDev] dxfwrite.m

[Larry D. <ldo...@re...>]

Laurent -

Just scratching an itch.

The DXF files made by CVS dxfwrite.m do not load
properly into AutoCAD 2002.  That attached version
"works for me".  Please test for regression, and
consider checking back into CVS.

I couldn't find an e-mail address for Patrick Labbe.

     - Larry

[OctDev] Greylevel morphological operations

[Etienne G. <et...@cs...>]

  Hi All,

I consider adding some greylevel image morphology functionality to
octave-forge. I have this function:


## im2 = g_all (im,scales)       - Greylevel morphological opertations
##
##      Open, close, erode and dilate greylevel image im at various scales.
##      Dilation at scale s is the greatest greylevel within radius s.
##      Erosion  at scale s is the least greylevel within radius s.
##      Opening  is erosion followed by dilation (all at the same scale).
##      Closing  is dilation followed by erosion (all at the same scale).
## 
## im     : R x C       : Image
## scales : 1 x S       : Scales at which morphological operations are performed
##
## im2     : R x C x 4*S : Opened (4*i+1), closed (4*i+2), eroded (4*i+3) and
##                        dilated (4*i+4) images (i in 0:S-1)
##
## See also: g_open_close.
## Todo    : Make this function more efficient.

  Any suggestions on other possible interfaces? I can also put
fucs for individual operation.

   Cheers,

  Etienne

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

Re: [OctDev] Wiki

[Etienne G. <et...@cs...>]

  Hi Nick,

should be done. Please let me know whether you manage to edit. And
thanks for contributing to the wiki.

  Cheers,

  Etienne

On Wed, Jan 05, 2005 at 03:12:18PM -0600, Nick Longo wrote:
# ... and I quote.
# 
# ``Editing not allowed for 128.135.149.118 / stats-dhcp-118.uchicago.edu:
# user, ip, or network is blocked.
# 
# Please contact octave-dev at lists.sourceforge.net, specifying your
# IP, if you would like to contribute to this site''
# 
# I would like to be able to edit this site.
# 
# Thanks,
# Nick
# 
# 
# -------------------------------------------------------
# The SF.Net email is sponsored by: Beat the post-holiday blues
# Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
# It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

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

[OctDev] Wiki

[Nick L. <nmi...@ma...>]

... and I quote.

``Editing not allowed for 128.135.149.118 / stats-dhcp-118.uchicago.edu:
user, ip, or network is blocked.

Please contact octave-dev at lists.sourceforge.net, specifying your
IP, if you would like to contribute to this site''

I would like to be able to edit this site.

Thanks,
Nick

Re: [OctDev] Fix to fixed.cc

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

According to Orion Poplawski <or...@co...> (on 12/16/04):
> I've been having some issues with octave's signbit() code in lo-ieee.h. 
> I think I've gotten them resolved, but I also needed to patch 
> octave-forge-2004.11.16/main/fixed/int/fixed.cc to include 
> <octave/config.h>.  This seems like a good thing in general to include 
> before "internal" octave include files.

This file was supposed to be independently usuable from octave and so
shouldn't necessarily need config.h. It was also included in fixed.h,
so the proper fix is to more the inclusion of fixed.h to above the
inclusion of lo-ieee.h. I committed this fix...

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] Minor makefile bug for Mac OS X buld

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

On Dec 18, 2004, at 02:23, Corey Halpin wrote:
> -	CC -ObjC -o bin/ofsndplay OFSndPLay.cc -framework Cocoa
> +	cc -ObjC -o bin/ofsndplay OFSndPlay.cc -framework Cocoa

Interesting how many typos I could make in a single line..., it was 
meant to read

$(CC) -ObjC -o bin/ofsndplay OFSndPlay.cc -framework Cocoa

Fixed in CVS.

/Per