octave-dev — GNU Octave developers' list

Re: [OctDev] graceplot does not work with grace6

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

On Feb 27, 2005, at 1:36 PM, Teemu Ikonen wrote:

> On Sun, 27 Feb 2005 14:27:04 +0100, Rafael Laboissiere
> <ra...@de...> wrote:
>> In my Debian sarge system, the graceplot alternative is not working 
>> with the
>> grace6 package.  Is this a known issue?
>
> Yes,
>
> graceplot is based on the Grace command interpreter, which is not 
> supported
> in the Grace 5.99 version. Without it, interfacing external
> applications will be hard, if not impossible.
>
> See:
> http://plasma-gate.weizmann.ac.il/Grace/phpbb/viewtopic.php?t=160

Can you test for this somehow, preferably at runtime, but at configure
time if necessary?

Thanks,

- Paul

Re: [OctDev] graceplot does not work with grace6

[Teemu I. <tpi...@gm...>]

On Sun, 27 Feb 2005 14:27:04 +0100, Rafael Laboissiere
<ra...@de...> wrote:
> In my Debian sarge system, the graceplot alternative is not working with the
> grace6 package.  Is this a known issue?

Yes, 

graceplot is based on the Grace command interpreter, which is not supported
in the Grace 5.99 version. Without it, interfacing external
applications will be hard, if not impossible.

See:
http://plasma-gate.weizmann.ac.il/Grace/phpbb/viewtopic.php?t=160

Teemu

Re: [OctDev] [dnj@x.dtu.dk: octave-forge: Replacing a submatrix of a sparse matrix results in a full matrix]

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

Rafael Laboissiere wrote:

>package octave-forge
>tags 295395 upstream
>forwarded 295395 oct...@li...
>thanks
>
>----- Forwarded message from Dennis J=F8rgensen <dnj@x.dtu.dk> -----
>
>From: Dennis J=F8rgensen <dnj@x.dtu.dk>
>Subject: octave-forge: Replacing a submatrix of a sparse matrix results =
in a full
> matrix
>Date: Tue, 15 Feb 2005 16:28:50 +0100
>To: Debian Bug Tracking System <su...@bu...>
>
>Package: octave-forge
>Version: 2004.11.16-3
>Severity: normal
>
>
>With the following commands, I would have expected matrix A to
>stay sparse:
>
>octave:1> A =3D sparse(4,4);
>octave:2> A([1 2 4],[1 2 4]) =3D sprand(3,3,0.2);
>octave:3> issparse(A)
>ans =3D 0
>
>
>Same commands in Matlab:
>
>
> =20
>
>>>A =3D sparse(4,4);    =20
>>>A([1 2 4],[1 2 4]) =3D sprand(3,3,0.2);
>>>issparse(A)
>>>     =20
>>>
>
>ans =3D
>
>     1
>
>
>Replacing sprand() with something returning a full matrix yields
>the same results: sparse 'A' in Matlab, full in Octave.
>
>
>
>Regards,
>
>
>  Dennis J??rgensen
> =20
>

Yes, I know. This is what made me start writing the sparse matrix patch=20
that is currently in the unstable CVS of octave. I started to write a=20
patch to the assign functions for the sparse matrix code and quickly=20
found myself with 2,000 lines of code, and felt if I was going to do=20
that, that I might as well replace the whole thing. The good news is as=20
this was the problem that made me start writing this code, the assign=20
behaviour of the sparse matrices in the unstable octave CVS work as you=20
would expect.... Downside, is that I don't expect a patch for the=20
octave-forge version of the sparse matrix code, as it is completely=20
superseded by the version in octave itself..

D.

[OctDev] [dnj@x.dtu.dk: octave-forge: Replacing a submatrix of a sparse matrix results in a full matrix]

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

package octave-forge
tags 295395 upstream
forwarded 295395 oct...@li...
thanks

----- Forwarded message from Dennis Jørgensen <dnj@x.dtu.dk> -----

From: Dennis Jørgensen <dnj@x.dtu.dk>
Subject: octave-forge: Replacing a submatrix of a sparse matrix results in a full
 matrix
Date: Tue, 15 Feb 2005 16:28:50 +0100
To: Debian Bug Tracking System <su...@bu...>

Package: octave-forge
Version: 2004.11.16-3
Severity: normal


With the following commands, I would have expected matrix A to
stay sparse:

octave:1> A = sparse(4,4);
octave:2> A([1 2 4],[1 2 4]) = sprand(3,3,0.2);
octave:3> issparse(A)
ans = 0


Same commands in Matlab:


>> A = sparse(4,4);     
>> A([1 2 4],[1 2 4]) = sprand(3,3,0.2);
>> issparse(A)

ans =

     1


Replacing sprand() with something returning a full matrix yields
the same results: sparse 'A' in Matlab, full in Octave.



Regards,


  Dennis J??rgensen


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
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  atlas3-sse [liblapack.so 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-8       Runtime library for GNU Fortran 77
ii  libgcc1                  1:3.4.3-9       GCC support library
ii  libginac1.3              1.3.0-2         The GiNaC framework (runtime libra
ii  libgmp3                  4.1.4-5         Multiprecision arithmetic library
ii  libgsl0                  1.6-1           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-15          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-8       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-3        GNU Octave language for numerical 
ii  xlibs                    4.3.0.dfsg.1-11 X Keyboard Extension (XKB) configu
ii  zlib1g                   1:1.2.2-4       compression library - runtime

-- no debconf information



----- End forwarded message -----

-- 
Rafael

[OctDev] graceplot does not work with grace6

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

In my Debian sarge system, the graceplot alternative is not working with the
grace6 package.  Is this a known issue?

-- 
Rafael

[OctDev] Bug#296973: octave-forge: weekday has incorrect documentation

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

package octave-forge
tags 296973 upstream
forwarded 296973 oct...@li...
thanks

----- Forwarded message from Bill Denney <bi...@gi...> -----

From: Bill Denney <bi...@gi...>
Subject: [Pkg-octave-devel] Bug#296973: octave-forge: weekday has incorrect documentation
Date: Fri, 25 Feb 2005 23:54:30 -0500
To: Debian Bug Tracking System <su...@bu...>
Reply-To: Bill Denney <bi...@gi...>, 29...@bu...

Package: octave-forge
Version: 2004.11.16-3
Severity: minor

The weekday function has incorrect documentation.  Its documentation 
appears to be a copy of datevec's documentation.  The doc at the 
beginning should read something like:

--- Begin Documentation
## -*- texinfo -*-
## @deftypefn {Function File} {[d,s] =} weekday(date, [P])
## Takes a date (in either datenum format or a string that datenum can
## parse) and returns the number for the day of the week (0 = "Sun", 
## 1 = "Mon", ... , "Sat")
##
## The parameter @code{P} is needed to convert date strings with 2 digit
## years into dates with 4 digit years.  2 digit years are assumed to be
## between @code{P} and @code{P+99}. If @code{P} is not given then the 
## current year - 50 is used, so that dates are centered on the present.
## For birthdates, you would want @code{P} to be current year - 99.  For
## appointments, you would want @code{P} to be current year.
##
## @seealso{date,clock,now,datestr,datenum,datevec,calendar} 
## @end deftypefn
--- End Documentation

Hopefully, I'll be able to submit a patch that will help with making 
datevec accept strings soon, too.

Bill

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

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-8       Runtime library for GNU Fortran 77
ii  libgcc1                  1:3.4.3-6       GCC support library
ii  libginac1.3              1.3.0-2         The GiNaC framework (runtime libra
ii  libgmp3                  4.1.4-5         Multiprecision arithmetic library
ii  libgsl0                  1.6-1           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-8       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


_______________________________________________
Pkg-octave-devel mailing list
Pkg...@li...
http://lists.alioth.debian.org/mailman/listinfo/pkg-octave-devel



----- End forwarded message -----

-- 
Rafael

Re: [OctDev] imrotate

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

On Feb 24, 2005, at 2:24 PM, Justus Piater wrote:
>
>> I would still like you to tell me which tests you prefer.  I know I've
>> thrown a lot of suggestions your way :-)
>
> I went through all of the suggestions and cast comprehensive versions
> of the essence of them into the following three tests, which I suggest
> to be added to the end of imrotate.m.
>

Justus,

I've added these tests.

Thanks,

	- Paul

Re: [OctDev] imrotate

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

Paul Kienzle <pki...@us...> wrote on Tue, 22 Feb 2005
07:13:43 -0500:

> Justus,
>
> I was testing the wrong code.  When I look at it now it looks fine.
> Sorry to trouble you.

Frankly, it did trouble me ("imrotate seems to be broken for all
of...", "particularly glaring", "Can the [other!?] users of this
function please come up with a fix"). But I accept your apology.

> I would still like you to tell me which tests you prefer.  I know I've
> thrown a lot of suggestions your way :-)

I went through all of the suggestions and cast comprehensive versions
of the essence of them into the following three tests, which I suggest
to be added to the end of imrotate.m.

Justus


%!test
%! ## Verify minimal loss across six rotations that add up to 360 +/- 1 deg=
.:
%! methods =3D { "nearest", "bilinear", "bicubic", "Fourier" };
%! angles     =3D [ 59  60  61  ];
%! tolerances =3D [ 7.4 8.5 8.6	  # nearest
%!                3.5 3.1 3.5     # bilinear
%!                2.7 0.1 2.7     # bicubic
%!                2.7 1.6 2.8 ];  # Fourier
%! x =3D peaks(50);
%! x -=3D min(min(x));	      # Fourier does not handle neg. values well
%! for m =3D 1:(length(methods))
%!   y =3D x;
%!   for i =3D 1:5
%!     y =3D imrotate(y, 60, methods(m), "crop");
%!   end
%!   for a =3D 1:(length(angles))
%!     assert(norm((x - imrotate(y, angles(a), methods(m), "crop"))
%!                 (10:40, 10:40)) < tolerances(m,a));
%!   end
%! end


%!test
%! ## Verify exactness of near-90 and 90-degree rotations:
%! X =3D rand(99);
%! for angle =3D [90 180 270]
%!   for da =3D [-0.1 0.1]
%!     Y =3D imrotate(X,   angle + da , "nearest");
%!     Z =3D imrotate(Y, -(angle + da), "nearest");
%!     assert(norm(X - Z) =3D=3D 0); # exact zero-sum rotation
%!     assert(norm(Y - imrotate(X, angle, "nearest")) =3D=3D 0); # near zer=
o-sum
%!   end
%! end


%!test
%! ## Verify preserved pixel density:
%! methods =3D { "nearest", "bilinear", "bicubic", "Fourier" };
%! ## This test does not seem to do justice to the Fourier method...:
%! tolerances =3D [ 4 2.2 2.0 209 ];
%! range =3D 3:9:100;
%! for m =3D 1:(length(methods))
%!   t =3D [];
%!   for n =3D range
%!     t(end + 1) =3D sum(imrotate(eye(n), 20, methods(m))(:));
%!   end
%!   assert(t, range, tolerances(m));
%! end


--=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: [Pkg-octave-devel] Re: [OctDev] Buildd failure for octave-forge on sparc

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

* Paul Kienzle <pki...@us...> [2005-02-23 22:53]:

> This routine doesn't actually reference X11.  The new version on CVS
> moves the includes into the "#if 0" block around the inform() function.

Thanks, I will patch the octave-forge package and upload it again.

-- 
Rafael

[OctDev] Re: Buildd failure for octave-forge on sparc

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

* Ben Collins <bco...@de...> [2005-02-23 16:47]:

> I don't see the correct -I's pointing to the X11 stuff, so maybe the
> detection (autoconf?) isn't seeing the x11 headers or libraries for some
> reason.

Yes, I noticed this as well, but the -I's are not present in the other
buildd logs neither and there are no compilation errors in the other arches.
The question is: how can g++ find the hX11 headers in all arches and not in
sparc?

-- 
Rafael

Re: [OctDev] Buildd failure for octave-forge on sparc

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

This routine doesn't actually reference X11.  The new version on CVS
moves the includes into the "#if 0" block around the inform() function.

-  Paul
On Feb 23, 2005, at 6:01 PM, Rafael Laboissiere wrote:

> octave-forge failed to build on sparc with the following error message:
>
> Processing main/audio/...
> make[3]: Entering directory
> `/build/buildd/octave-forge-2004.11.16/main/audio'
> mkoctfile -DHAVE_OCTAVE_21 -v -c aurecord.cc
> /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.65  
> -I/usr/include/octave-2.1.65/octave -O2 -DHAVE_OCTAVE_21 aurecord.cc  
> -o
> aurecord.o
> aurecord.cc:22:19: X11/X.h: No such file or directory
> aurecord.cc:23:22: X11/Xlib.h: No such file or directory
> make[3]: *** [aurecord.o] Error 1
>
> Files X.h and Xlib.h must be present in the system in the usual place,
> because the package x-dev was installed by the build daemon.  Does  
> someone
> understand the reason for the failure?
>
> The complete build log is at:
>
> http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.11.16 
> -4&arch=sparc&stamp=1109181451&file=log&as=raw
>

[OctDev] Re: Buildd failure for octave-forge on sparc

[Ben C. <bco...@de...>]

I don't see the correct -I's pointing to the X11 stuff, so maybe the
detection (autoconf?) isn't seeing the x11 headers or libraries for some
reason.

On Thu, Feb 24, 2005 at 12:01:35AM +0100, Rafael Laboissiere wrote:
> octave-forge failed to build on sparc with the following error message: 
> 
> Processing main/audio/...          
> make[3]: Entering directory
> `/build/buildd/octave-forge-2004.11.16/main/audio'      
> mkoctfile -DHAVE_OCTAVE_21 -v -c aurecord.cc                             
> /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.65 -I/usr/include/octave-2.1.65/octave -O2 -DHAVE_OCTAVE_21 aurecord.cc -o
> aurecord.o          
> aurecord.cc:22:19: X11/X.h: No such file or directory            
> aurecord.cc:23:22: X11/Xlib.h: No such file or directory                  
> make[3]: *** [aurecord.o] Error 1                  
> 
> Files X.h and Xlib.h must be present in the system in the usual place,
> because the package x-dev was installed by the build daemon.  Does someone
> understand the reason for the failure?
> 
> The complete build log is at:
> 
> http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.11.16-4&arch=sparc&stamp=1109181451&file=log&as=raw
> 
> 
> -- 
> Rafael
> 
> 
> -- 
> To UNSUBSCRIBE, email to deb...@li...
> with a subject of "unsubscribe". Trouble? Contact lis...@li...
> 

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

[OctDev] Buildd failure for octave-forge on sparc

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

octave-forge failed to build on sparc with the following error message: 

Processing main/audio/...          
make[3]: Entering directory
`/build/buildd/octave-forge-2004.11.16/main/audio'      
mkoctfile -DHAVE_OCTAVE_21 -v -c aurecord.cc                             
/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.65 -I/usr/include/octave-2.1.65/octave -O2 -DHAVE_OCTAVE_21 aurecord.cc -o
aurecord.o          
aurecord.cc:22:19: X11/X.h: No such file or directory            
aurecord.cc:23:22: X11/Xlib.h: No such file or directory                  
make[3]: *** [aurecord.o] Error 1                  

Files X.h and Xlib.h must be present in the system in the usual place,
because the package x-dev was installed by the build daemon.  Does someone
understand the reason for the failure?

The complete build log is at:

http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.11.16-4&arch=sparc&stamp=1109181451&file=log&as=raw


-- 
Rafael

Re: [OctDev] Re: Octave Wiki *Call for Volunteers*

[Corey H. <ch...@cs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Etienne Grossmann wrote:
> - I give an admin pwd to volunteers (not via email: I send my tel # to
>   volunteers or vice versa and I give you a password). 

  Depending on the difference between your timezone and mine, this might
be ok.  However if we have volunteers from outside the US, just
scheduling the phone call might be a pain.
  If you're worried about securely sending passwords, GPG/PGP might be
the way to go.

crh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCG5ZpWBjzOA9cliERAjFEAJ9c/Rme9I72wgOou07/NJIagRw1YQCfYF3y
mqQUBBHN9i6NxG5XZCoY/0w=
=uQb1
-----END PGP SIGNATURE-----

Re: [OctDev] Re: Octave Wiki *Call for Volunteers*

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

  Hi Volunteers,

it's good to see willing people! I propose the following:

- I give an admin pwd to volunteers (not via email: I send my tel # to
  volunteers or vice versa and I give you a password). 
- When volunteers feel comfy about the security level, I open the
  wiki.
- I continue doing all maintenance that requires loging in the wiki
  host machine, at my previous work  place. I am not root there. Extra
  perl modules can be installed using the PREFIX option, but, Todd,
  you will need to explain me clearly what I should do.

  Sounds ok?

  Etienne

On Tue, Feb 22, 2005 at 08:28:09AM -0600, Todd Neal wrote:
# On Tue, 22 Feb 2005 09:05:39 -0500, Etienne Grossmann
[snip]
# >
# >   Hi All,
# >
# > this mail is to ask for volunteers who would take the responsibility
# > to :
# >
# > - Repair daily any defacement that occurs on the wiki
# > - Update the bannedhost page of the wiki.
# >
# > Please answer to this list if you're interested. If volunteers show
# > up, I'll open up the wiki.
# >
# >   Cheers,
# >
# >   Etienne
# >
# > PS I am *not* a volunteer.
# 
# I'll volunteer to help with this maintenance.  It may also help to
# install the XML::RSS Perl module.  That should be all that is needed

  I'll try to do that, but I don't really grok this part.

# for an RSS feed at http://wiki.octave.org/wiki.pl?action=rss to start
# working.  This would allow one to check the recent changes page
# several times a day easily without loading the entire page.
# 
# Todd
# 
[snip]

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

Re: [OctDev] Re: Octave Wiki *Call for Volunteers*

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

Todd Neal wrote:

>On Tue, 22 Feb 2005 16:03:37 +0100, David Bateman
><Dav...@mo...> wrote:
>  
>
>>Etienne Grossmann wrote:
>>
>>    
>>
>>> Sorry to repeat the mail; the subject should have "call for
>>>volunteers" in it.
>>>
>>>
>>>
>>>      
>>>
>>I don't mind volunteering, I'd remove the spam as I visit in any case.
>>But I think there needs to be a large number of users with this
>>priviledge to reduce the total workload.
>>
>>D.
>>    
>>
>
>Removing spam could be done by any user, but adding the url's to the
>BannedContent page is reserved for Admin users with Oddmuse.  This
>prevents someone from adding things like "." to the BannedContent page
>which would match any post.
>
>Todd
>  
>

I was adding the links and keywords to a link to chongqed at

http://wiki.octave.org/wiki.pl?RemoveDefacements

so that the spam would backfire as the pagerank would go to chongqed who 
describes what scumbags these spammers are. So adding to BannedContent 
would be even easier...

D.

Re: [OctDev] Re: Octave Wiki *Call for Volunteers*

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

On Tue, 22 Feb 2005 16:03:37 +0100, David Bateman
<Dav...@mo...> wrote:
> Etienne Grossmann wrote:
> 
> >  Sorry to repeat the mail; the subject should have "call for
> >volunteers" in it.
> >
> >
> >
> 
> I don't mind volunteering, I'd remove the spam as I visit in any case.
> But I think there needs to be a large number of users with this
> priviledge to reduce the total workload.
> 
> D.

Removing spam could be done by any user, but adding the url's to the
BannedContent page is reserved for Admin users with Oddmuse.  This
prevents someone from adding things like "." to the BannedContent page
which would match any post.

Todd

Re: [OctDev] Re: Octave Wiki *Call for Volunteers*

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

Etienne Grossmann wrote:

>  Sorry to repeat the mail; the subject should have "call for
>volunteers" in it.
>
>  
>

I don't mind volunteering, I'd remove the spam as I visit in any case. 
But I think there needs to be a large number of users with this 
priviledge to reduce the total workload.

D.

Re: [OctDev] Re: Octave Wiki *Call for Volunteers*

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

On Tue, 22 Feb 2005 09:05:39 -0500, Etienne Grossmann
<et...@cs...> wrote:
> Date: Tue, 22 Feb 2005 09:01:00 -0500
> From: Etienne Grossmann <et...@cs...>
> To: Todd Neal <to...@gm...>
> Cc: David Bateman <Dav...@mo...>,
>    oct...@li..., et...@cs...
> Subject: Re: [OctDev] Re: Octave Wiki
>
>   Hi All,
>
> this mail is to ask for volunteers who would take the responsibility
> to :
>
> - Repair daily any defacement that occurs on the wiki
> - Update the bannedhost page of the wiki.
>
> Please answer to this list if you're interested. If volunteers show
> up, I'll open up the wiki.
>
>   Cheers,
>
>   Etienne
>
> PS I am *not* a volunteer.

I'll volunteer to help with this maintenance.  It may also help to
install the XML::RSS Perl module.  That should be all that is needed
for an RSS feed at http://wiki.octave.org/wiki.pl?action=rss to start
working.  This would allow one to check the recent changes page
several times a day easily without loading the entire page.

Todd

Re: [OctDev] Re: Octave Wiki

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

Sorry, I'm not volunteering, but just thinking about things that would 
make maintenance easier. Does there exist Wiki software there that 
e-mails updates to a moderator for approval? It seems that maintenance 
would be easier if someone just had to look at an e-mail and click on an 
"approve" link for the changes to be accepted. This would need to be 
combined with blacklisting to minimize traffic. The wiki isn't 
particularly busy, so I don't think it would be too much of a burden on 
the maintainer.

-Quentin



Etienne Grossmann wrote:

>  Hi All,
>
>this mail is to ask for volunteers who would take the responsibility
>to : 
>
>- Repair daily any defacement that occurs on the wiki
>- Update the bannedhost page of the wiki.
>
>Please answer to this list if you're interested. If volunteers show
>up, I'll open up the wiki.
>
>  Cheers,
>
>  Etienne
>
>PS I am *not* a volunteer.
>
>On Mon, Feb 21, 2005 at 09:33:59AM -0600, Todd Neal wrote:
># > The problem ith a banned host page is that most spammer come in through
># > proxies, so they just pick a new proxies and try again.. So a bannedhost
># > page is a lame anti-spam measure.. It really needs to be upto date.. If
># > you want an effective measure in the same vain, see
># > http://blacklist.chongqed.org as a means of preventing links that match
># > a certain regex... The people at chongqed keep this upto date, and you
># > can see other links on their pages on how to set this up.
># > 
># 
># Those regex's can be put in the BannedContent page and that would
># prevent those sites from being advertised.  I don't know how often
># http://blacklist.chongqed.org is updated but we could grab the list
># from EmacsWiki to start off with as well.
># 
># It looks like all that is needed now is for a few volunteers to get an
># admin password so they can modify the BannedContent and BannedHosts
># page and check the wiki daily for new spam.
># 
># Todd
># 
># 
># -------------------------------------------------------
># SF email is sponsored by - The IT Product Guide
># Read honest & candid reviews on hundreds of IT Products from real users.
># Discover which products truly live up to the hype. Start reading now.
># http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
># _______________________________________________
># Octave-dev mailing list
># Oct...@li...
># https://lists.sourceforge.net/lists/listinfo/octave-dev
>
>  
>

[OctDev] Re: Octave Wiki *Call for Volunteers*

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

  Sorry to repeat the mail; the subject should have "call for
volunteers" in it.


----- Forwarded message from Etienne Grossmann <et...@cs...> -----

Date: Tue, 22 Feb 2005 09:01:00 -0500
From: Etienne Grossmann <et...@cs...>
To: Todd Neal <to...@gm...>
Cc: David Bateman <Dav...@mo...>,
   oct...@li..., et...@cs...
Subject: Re: [OctDev] Re: Octave Wiki


  Hi All,

this mail is to ask for volunteers who would take the responsibility
to : 

- Repair daily any defacement that occurs on the wiki
- Update the bannedhost page of the wiki.

Please answer to this list if you're interested. If volunteers show
up, I'll open up the wiki.

  Cheers,

  Etienne

PS I am *not* a volunteer.

On Mon, Feb 21, 2005 at 09:33:59AM -0600, Todd Neal wrote:
# > The problem ith a banned host page is that most spammer come in through
# > proxies, so they just pick a new proxies and try again.. So a bannedhost
# > page is a lame anti-spam measure.. It really needs to be upto date.. If
# > you want an effective measure in the same vain, see
# > http://blacklist.chongqed.org as a means of preventing links that match
# > a certain regex... The people at chongqed keep this upto date, and you
# > can see other links on their pages on how to set this up.
# > 
# 
# Those regex's can be put in the BannedContent page and that would
# prevent those sites from being advertised.  I don't know how often
# http://blacklist.chongqed.org is updated but we could grab the list
# from EmacsWiki to start off with as well.
# 
# It looks like all that is needed now is for a few volunteers to get an
# admin password so they can modify the BannedContent and BannedHosts
# page and check the wiki daily for new spam.
# 
# Todd
# 
# 
# -------------------------------------------------------
# SF email is sponsored by - The IT Product Guide
# Read honest & candid reviews on hundreds of IT Products from real users.
# Discover which products truly live up to the hype. Start reading now.
# http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

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

----- End forwarded message -----

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

Re: [OctDev] Re: Octave Wiki

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

  Hi All,

this mail is to ask for volunteers who would take the responsibility
to : 

- Repair daily any defacement that occurs on the wiki
- Update the bannedhost page of the wiki.

Please answer to this list if you're interested. If volunteers show
up, I'll open up the wiki.

  Cheers,

  Etienne

PS I am *not* a volunteer.

On Mon, Feb 21, 2005 at 09:33:59AM -0600, Todd Neal wrote:
# > The problem ith a banned host page is that most spammer come in through
# > proxies, so they just pick a new proxies and try again.. So a bannedhost
# > page is a lame anti-spam measure.. It really needs to be upto date.. If
# > you want an effective measure in the same vain, see
# > http://blacklist.chongqed.org as a means of preventing links that match
# > a certain regex... The people at chongqed keep this upto date, and you
# > can see other links on their pages on how to set this up.
# > 
# 
# Those regex's can be put in the BannedContent page and that would
# prevent those sites from being advertised.  I don't know how often
# http://blacklist.chongqed.org is updated but we could grab the list
# from EmacsWiki to start off with as well.
# 
# It looks like all that is needed now is for a few volunteers to get an
# admin password so they can modify the BannedContent and BannedHosts
# page and check the wiki daily for new spam.
# 
# Todd
# 
# 
# -------------------------------------------------------
# SF email is sponsored by - The IT Product Guide
# Read honest & candid reviews on hundreds of IT Products from real users.
# Discover which products truly live up to the hype. Start reading now.
# http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

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

[OctDev] image reading/writing patches

[Debian U. <st...@su...>]

Hi everyone

I recently proposed changing the image reading/writing routines to use
a common image structure.  This patch is an attempt in that direction.

Currently, a gray scale image is a matrix with values in [0,255] while
an RGB image consists of three such gray-scale images.  Some image
routines expect values between [0,1] while others prefer [0,255].  By
using the appropriate numerical classes, I hope to remove this
inconsistency.

The suggested image format (as used by the other brand) is:

Image Type      Matrix Size        Numerical Class
--------------------------------------------------
B&W             MxN                logical
Gray-level      MxN                uint8 or uint16 (depends on depth)
RGB             MxNx3              uint8 or uint16 (depends on depth)

I attach two functions which achieve this: imread2.m (a replacement for
imread.m) and imshow2.m (a wrapper for imshow.m).  'imshow2' can be
installed using dispatch:

  dispatch('imshow', 'imshow2', 'any')

imread2 uses pngread and jpgread when available, or otherwise resorts
to the ImageMagick utilities 'convert' and 'identify'.  Paul mentioned
that we might want to look at libgd.  This is a good idea because of
two reasons I can think of immediately:

1. Fast image loading of multiple formats

While ImageMagick supports many formats, it forces us to convert
images to raw portable gray-maps before loading them into octave.
libgd supports many formats and can be linked directly into an
oct-file.

2. Image manipulation

libgd has built-in support for popular image processing functions,
such as histogram equilization.  Also, lines, text and other
primitives can be drawn onto images.  These functions can simply be
wrapped in .oct files.

I have not updated all the functions in the image toolbox to use the
new format.  I will do so once we all agree on the image structure.  I
would like some ideas on the use of colour-maps and how they fit into
the bigger picture.

Regards
Stefan

Re: [OctDev] imrotate

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

Justus,

I was testing the wrong code.  When I look at it now it looks fine.
Sorry to trouble you.

I would still like you to tell me which tests you prefer.  I know I've
thrown a lot of suggestions your way :-)

Thanks,

- Paul

On Feb 22, 2005, at 6:32 AM, Justus Piater wrote:

> Paul Kienzle <pki...@us...> wrote on Tue, 22 Feb 2005
> 01:09:38 -0500:
>
>> FWIW, matlab also exhibits the alternating bright-dim stripes but =
less
>> severely than yours.
>
> For imrotate(eye(...), ..., ...) I just verified that for all of
> "nearest", "bilinear" and "bicubic", Matlab's (6.5) and my code
> produce *exactly* the same result, modulo the following:
>
> - My code crops the image a little more aggressively than Matlab
>   does. I round the size such that 90.1 and 90 degrees (e.g.) give the
>   same result. Matlab uses the ceil. It's a matter of taste.
>
>   Moreover, Matlab appears to pad the image with zeros, while I do not
>   pad. Thus, Matlab fills in more values/produces a larger
>   image. However, I do not see why we should pad; the value of zero is
>   about as arbitrary as any other value. My code fills in (the
>   arbitrary value of) zero wherever the result is not defined. Again,
>   it's a matter of taste, but my method yields simpler code.
>
> - Both Matlab and my code may produce an odd-size result image for an
>   even-size source image, and vice versa. In those cases where
>   Matlab's and my code produce resulting image sizes of opposing
>   parity, the results are obviously not identical, but neither is more
>   "correct" than the other.
>
> Justus
>
> --=20
> Justus H. Piater, Ph.D.        =20
> 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] imrotate

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

Paul,

Paul Kienzle <pki...@us...> wrote on Sat, 19 Feb 2005
15:47:00 -0500:

> Here are some more tests you might include:
>
>    % Make sure the dithering preserves pixel density
>    t=3Dzeros(1,5);
>    for n=3D1:15; t(n) =3D sum(imrotate(eye(n),20,'bilinear')(:)); end
>    assert(t,[1:15]);

This test in fact works. The only difference is that my code always
produces a slightly smaller sum because it does not pad the image (see
my previous message for a brief discussion). With growing image sizes
and fixed rotation angle, the difference is bounded:
assert(t,[1:n], 2.2) should pass for any n.

>    % Make sure the size matches the expected size assuming square pixels.
>    angle=3D20; t=3Dzeros(15,2);
>    for n=3D1:15; t(n,:) =3D size(imrotate(ones(n,3*n),angle,'bilinear'));=
 end
>    a =3D angle*pi/180;
>    x =3D ceil([(1:n);3*(1:n)]'*[cos(a) sin(a);sin(a) cos(a)]);
>    assert(t,x);

If you insist... the code for computing the image size is trivial. But
to be fair, use round() because this is what imrotate does. In that
case, a tolerance of 1 is sufficient to pass the assert(), except for
the very first element. But I really would not include this test. It
is only a rough estimate, the code in imrotate is at least as simple
and does it better.

Justus

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