octave-dev — GNU Octave developers' list

Re: [OctDev] bug in regexp

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

Regexp follows Paul Kienzle's convention, rather than MATLAB's.  I
think it was probably coded before MATLAB had regexp?  'pcregexp'
follows the same convention as 'regexp', so if you update the
interface, please look at both.

Regards
St=E9fan

P.S. Metasymbols work with `pcregexp'

On Tue, Sep 06, 2005 at 08:33:53AM -0400, Hall, Benjamin wrote:
> There is an interface incompatibility between octave-forge regexp and
> Matlab's regexp, most importantly, the order of the inputs
>=20
> Octave:
> [match s1 s2 ...] =3D regexp(pattern,string)
>=20
> Matlab:
> [START,FINISH,TOKENS] =3D REGEXP(STRING,EXPRESSION)=20
>=20
> Also, I don't know if it is me, but I have never been able to get any o=
f the
> metasymbols to work:
>=20
> pat =3D '(\d)+';  ## Octave complains about "\d", so
> pat =3D '(\\d)+';
>=20
> str =3D 'number of points is 475'
>=20
> regexp(pat,str)
>=20
> returns an empty matrix.

RE: [OctDev] bug in regexp

[Hall, B. <ben...@pw...>]

There is an interface incompatibility between octave-forge regexp and
Matlab's regexp, most importantly, the order of the inputs

Octave:
[match s1 s2 ...] =3D regexp(pattern,string)

Matlab:
[START,FINISH,TOKENS] =3D REGEXP(STRING,EXPRESSION)=20

Also, I don't know if it is me, but I have never been able to get any =
of the
metasymbols to work:

pat =3D '(\d)+';  ## Octave complains about "\d", so
pat =3D '(\\d)+';

str =3D 'number of points is 475'

regexp(pat,str)

returns an empty matrix.

-----Original Message-----
From: Etienne Grossmann [mailto:et...@cs...]
Sent: Sunday, September 04, 2005 10:36 AM
To: et...@cs...; et...@is...;
eti...@la...
Cc: Stefan van der Walt; Octave Forge; et...@cs...
Subject: Re: [OctDev] bug in regexp



  Hi All,

I'm sorry for raising a false alarm, the problem I reported was due to
running an octave compile w/ one libc6 on a machine w/ another libc6
installed.

  Etienne

On Thu, Sep 01, 2005 at 08:40:14AM -0400, Etienne Grossmann wrote:
#=20
#   Hi All,
#=20
# thx for your replies. I use CVS octave-forge w/ octave 2.9.3 ... =
could
# it be a  library issue? It's libc6 2.3.5-3 (Debian) that provides
# regexp.h for regexp.cc.
#=20
#   Thx,
#=20
#   Etienne
#=20
# PS I'm terse to minimize typing to avoid arm pain.
#=20
# etienne@madrid: cvs update
# et...@cv...'s password:
# cvs update: Updating .
# etienne@madrid: make clean
# rm -f *.o core octave-core *.oct *~
# etienne@madrid: make
# mkoctfile -DHAVE_OCTAVE_29 -v regexp.cc
# g++ -c -fPIC -I/usr/local/include/octave-2.9.3
-I/usr/local/include/octave-2.9.3/octave -I/usr/local/include -mieee-fp =
-g
-O2 -DHAVE_OCTAVE_29 regexp.cc -o regexp.o
# g++ -shared -Wl,-Bsymbolic -o regexp.oct regexp.o
-L/usr/local/lib/octave-2.9.3 -loctinterp -loctave -lcruft -llapack =
-lcblas
-lf77blas -latlas -lfftw3 -lreadline -lncurses -ldl -lhdf5 -lz -lm
-L/usr/lib/gcc/i486-linux-gnu/3.4.5
-L/usr/lib/gcc/i486-linux-gnu/3.4.5/../../../../lib
-L/usr/lib/gcc/i486-linux-gnu/3.4.5/../../.. -L/lib/../lib =
-L/usr/lib/../lib
-lhdf5 -lz -lfrtbegin -lg2c -lm -lgcc_s
#=20
#=20
# On Thu, Sep 01, 2005 at 12:28:14PM +0200, Stefan van der Walt wrote:
# # Hi Etienne
# #=20
# # On Wed, Aug 31, 2005 at 06:41:33PM -0400, Etienne Grossmann wrote:
# # >=20
# # >   Hi All,
# # >=20
# # > I found this one, did not find any obvious cause and don't have =
time
# # > to look into it in depth.
# # >=20
# # > octave:1> regexp ("a","aaa")
# # > panic: Segmentation fault -- stopping myself...
# # > attempting to save variables to `octave-core'...
# # > save to `octave-core' complete
# #=20
# # I see
# #=20
# # octave:1> regexp("a", "aaa")
# # ans =3D
# #=20
# #   1  1
# #=20
# #=20
# # Do you have the latest Octave Forge version?  I am currently using =
the
# # Debian package from 2004/11/16.
# #=20
# # Regards
# # St=E9fan
#=20
# --=20
# Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle =
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
Security * Process Improvement & Measurement * =
http://www.sqe.com/bsce5sf
_______________________________________________
Octave-dev mailing list
Oct...@li...
https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] bug in regexp

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

  Hi All,

I'm sorry for raising a false alarm, the problem I reported was due to
running an octave compile w/ one libc6 on a machine w/ another libc6
installed.

  Etienne

On Thu, Sep 01, 2005 at 08:40:14AM -0400, Etienne Grossmann wrote:
#=20
#   Hi All,
#=20
# thx for your replies. I use CVS octave-forge w/ octave 2.9.3 ... could
# it be a  library issue? It's libc6 2.3.5-3 (Debian) that provides
# regexp.h for regexp.cc.
#=20
#   Thx,
#=20
#   Etienne
#=20
# PS I'm terse to minimize typing to avoid arm pain.
#=20
# etienne@madrid: cvs update
# et...@cv...'s password:
# cvs update: Updating .
# etienne@madrid: make clean
# rm -f *.o core octave-core *.oct *~
# etienne@madrid: make
# mkoctfile -DHAVE_OCTAVE_29 -v regexp.cc
# g++ -c -fPIC -I/usr/local/include/octave-2.9.3 -I/usr/local/include/oct=
ave-2.9.3/octave -I/usr/local/include -mieee-fp -g -O2 -DHAVE_OCTAVE_29 r=
egexp.cc -o regexp.o
# g++ -shared -Wl,-Bsymbolic -o regexp.oct regexp.o -L/usr/local/lib/octa=
ve-2.9.3 -loctinterp -loctave -lcruft -llapack -lcblas -lf77blas -latlas =
-lfftw3 -lreadline -lncurses -ldl -lhdf5 -lz -lm -L/usr/lib/gcc/i486-linu=
x-gnu/3.4.5 -L/usr/lib/gcc/i486-linux-gnu/3.4.5/../../../../lib -L/usr/li=
b/gcc/i486-linux-gnu/3.4.5/../../.. -L/lib/../lib -L/usr/lib/../lib -lhdf=
5 -lz -lfrtbegin -lg2c -lm -lgcc_s
#=20
#=20
# On Thu, Sep 01, 2005 at 12:28:14PM +0200, Stefan van der Walt wrote:
# # Hi Etienne
# #=20
# # On Wed, Aug 31, 2005 at 06:41:33PM -0400, Etienne Grossmann wrote:
# # >=20
# # >   Hi All,
# # >=20
# # > I found this one, did not find any obvious cause and don't have tim=
e
# # > to look into it in depth.
# # >=20
# # > octave:1> regexp ("a","aaa")
# # > panic: Segmentation fault -- stopping myself...
# # > attempting to save variables to `octave-core'...
# # > save to `octave-core' complete
# #=20
# # I see
# #=20
# # octave:1> regexp("a", "aaa")
# # ans =3D
# #=20
# #   1  1
# #=20
# #=20
# # Do you have the latest Octave Forge version?  I am currently using th=
e
# # Debian package from 2004/11/16.
# #=20
# # Regards
# # St=E9fan
#=20
# --=20
# Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

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

Re: [OctDev] bug in regexp

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

  Hi All,

thx for your replies. I use CVS octave-forge w/ octave 2.9.3 ... could
it be a  library issue? It's libc6 2.3.5-3 (Debian) that provides
regexp.h for regexp.cc.

  Thx,

  Etienne

PS I'm terse to minimize typing to avoid arm pain.

etienne@madrid: cvs update
et...@cv...'s password:
cvs update: Updating .
etienne@madrid: make clean
rm -f *.o core octave-core *.oct *~
etienne@madrid: make
mkoctfile -DHAVE_OCTAVE_29 -v regexp.cc
g++ -c -fPIC -I/usr/local/include/octave-2.9.3 -I/usr/local/include/octav=
e-2.9.3/octave -I/usr/local/include -mieee-fp -g -O2 -DHAVE_OCTAVE_29 reg=
exp.cc -o regexp.o
g++ -shared -Wl,-Bsymbolic -o regexp.oct regexp.o -L/usr/local/lib/octave=
-2.9.3 -loctinterp -loctave -lcruft -llapack -lcblas -lf77blas -latlas -l=
fftw3 -lreadline -lncurses -ldl -lhdf5 -lz -lm -L/usr/lib/gcc/i486-linux-=
gnu/3.4.5 -L/usr/lib/gcc/i486-linux-gnu/3.4.5/../../../../lib -L/usr/lib/=
gcc/i486-linux-gnu/3.4.5/../../.. -L/lib/../lib -L/usr/lib/../lib -lhdf5 =
-lz -lfrtbegin -lg2c -lm -lgcc_s


On Thu, Sep 01, 2005 at 12:28:14PM +0200, Stefan van der Walt wrote:
# Hi Etienne
#=20
# On Wed, Aug 31, 2005 at 06:41:33PM -0400, Etienne Grossmann wrote:
# >=20
# >   Hi All,
# >=20
# > I found this one, did not find any obvious cause and don't have time
# > to look into it in depth.
# >=20
# > octave:1> regexp ("a","aaa")
# > panic: Segmentation fault -- stopping myself...
# > attempting to save variables to `octave-core'...
# > save to `octave-core' complete
#=20
# I see
#=20
# octave:1> regexp("a", "aaa")
# ans =3D
#=20
#   1  1
#=20
#=20
# Do you have the latest Octave Forge version?  I am currently using the
# Debian package from 2004/11/16.
#=20
# Regards
# St=E9fan

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

[OctDev] bug in regexp

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

  Hi All,

I found this one, did not find any obvious cause and don't have time
to look into it in depth.

octave:1> regexp ("a","aaa")
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete

octave:1> which regexp
regexp is the dynamically-linked function from the file
/home/etienne/prog/octave/octave-forge/octave-forge/main/strings/regexp.oct

does anyone have this too?

  Etienne 

uname output:     Linux madrid 2.4.22-1-686-smp #5 SMP Sat Oct 4 14:35:05 EST 2003 i686 GNU/Linux
configure opts:
Fortran compiler: g77
FFLAGS:           -O -mieee-fp
F2C:
F2CFLAGS:
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/3.4.5 -L/usr/lib/gcc/i486-linux-gnu/3.4.5/../../../../lib -L/usr/lib/gcc/i486-linux-gnu/3.4.5/../../.. -L/lib/../lib -L/usr/lib/../lib -lhdf5 -lz -lfrtbegin -lg2c -lm -lgcc_s
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.0.1 (Debian 4.0.1-2)
CFLAGS:           -g -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.0.1
CXXFLAGS:         -g -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/local/lib/octave-2.9.3
BLAS_LIBS:        -llapack -lcblas -lf77blas -latlas
FFTW_LIBS:        -lfftw3
LIBS:             -lreadline  -lncurses -ldl -lhdf5 -lz -lm
LEXLIB:
LIBPLPLOT:
LIBDLFCN:
LIBGLOB:          %OCTAVE_CONF_LIBGLOB%
SED:              /bin/sed

DEFS:
                                                                                                   
  -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION=""
  -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1
  -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
  -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
  -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=1
  -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1
  -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=gnu_v3 -DHAVE_LIBM=1
  -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1
  -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_IEEE754_DATA_FORMAT=1
  -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __
  -DHAVE_BLAS=1 -DHAVE_UMFPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1
  -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1
  -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1
  -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2
  -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1
  -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DHAVE_PLACEMENT_DELETE=1
  -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1
  -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1
  -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1
  -DHAVE_GRP_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1
  -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
  -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1
  -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1
  -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1
  -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1
  -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1
  -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1
  -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1
  -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1
  -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1
  -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1
  -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1
  -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1
  -DHAVE_KILL=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1
  -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1
  -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1
  -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1
  -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1
  -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1
  -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_STAT=1
  -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1
  -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1
  -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_VFPRINTF=1
  -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_LIBDL=1
  -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1
  -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1
  -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1
  -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1
  -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1
  -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1
  -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1
  -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DSYS_SIGLIST_DECLARED=1
  -DHAVE_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DHAVE_GETRUSAGE=1
  -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot"
  -DGNUPLOT_HAS_FRAMES=1

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

Re: [OctDev] [i,j,v] = find(sparse(1:10,1:10,1:10,11,11))

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

  Viva 2.9.3!

(in fact 2.9.2). Thanks a lot David, I didn't even know there was an
"experimental" distribution of Debian packages.

  find(sparse(...)) now works on Machine 1, I will ask our sysad to
install 2.9.X on Machine 2. I guess that solves it.

  Thanks again,

  Etienne

On Wed, Aug 24, 2005 at 03:47:00PM +0200, David Bateman wrote:
# Etienne Grossmann wrote:
# 
# > Hi all,
# >
# >on two different Debian machines, I get:
# >
# >======================================================================
# >octave:3> [i,j,v] = find (sparse ([1 2 3 2],[2 4 2 5],1:4,30000,50000));
# >error: octave_base_value::array_value(): wrong type argument `sparse'
# >======================================================================
# >
# > Moreover on Machine 1, 
# >
# >======================================================================
# >octave:2> [i,j,v] = spfind(sparse(1:10,1:10,1:10,11,11))
# >panic: Segmentation fault -- stopping myself...
# >attempting to save variables to `octave-core'...
# >save to `octave-core' complete
# >======================================================================
# >
# > Whereas w/ Machine 2, I get:
# >
# >======================================================================
# >octave:5> [i,j,v] = spfind(sparse(1:10,1:10,1:10,11,11))
# >[snip] ... normal output ...
# >======================================================================
# >
# >
# > 
# >
# Strange the octave-forge sparse stuff for me working perfectly for these.
# 
# > I have octave 2.1.71 from debian (octave2.1-headers and octave2.1)
# >and a fresh CVS octave-forge (checkout, autogen.sh, config, make) in
# >both cases.
# >
# > I imagine there's @ least a dispatch issue, but don't know enough
# >about dispatch to find it.
# >
# > I would greatly appreciate if anyone had an explanation/fix.
# >
# > 
# >
# However, they also work perfectly in 2.9.3 and the sparse stuff there... 
# The only thing in the octave-forge sparse stuff that isn't in 2.9.3 is 
# the spinv and the iterative functions. The iterative functions are 
# implemented as dot-m in octave-forge and so you can copy them, and I'm 
# not sure where exactly you'd want to use spinv as the inverse of a 
# sparse matrix is full. So I consider 2.9.3 to be in a good state to be 
# considered as a replacement of the octave-forge sparse code. It is also 
# in debian experimental so you could use pinning to get 2.9.3 under 
# debian if you like...
# 
# The fact is with the new sparse stuff in octave I don't think its likely 
# any bugs in the octave-forge will be tracked down...
# 
# Regards
# David
# 
# -- 
# David Bateman                                Dav...@mo...
# Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
# Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
# 91193 Gif-Sur-Yvette FRANCE
# 
# The information contained in this communication has been classified as: 
# 
# [x] General Business Information 
# [ ] Motorola Internal Use Only 
# [ ] Motorola Confidential Proprietary
# 

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

Re: [OctDev] [i,j,v] = find(sparse(1:10,1:10,1:10,11,11))

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

Etienne Grossmann wrote:

>  Hi all,
>
>on two different Debian machines, I get:
>
>======================================================================
>octave:3> [i,j,v] = find (sparse ([1 2 3 2],[2 4 2 5],1:4,30000,50000));
>error: octave_base_value::array_value(): wrong type argument `sparse'
>======================================================================
>
>  Moreover on Machine 1, 
>
>======================================================================
>octave:2> [i,j,v] = spfind(sparse(1:10,1:10,1:10,11,11))
>panic: Segmentation fault -- stopping myself...
>attempting to save variables to `octave-core'...
>save to `octave-core' complete
>======================================================================
>
>  Whereas w/ Machine 2, I get:
>
>======================================================================
>octave:5> [i,j,v] = spfind(sparse(1:10,1:10,1:10,11,11))
>[snip] ... normal output ...
>======================================================================
>
>
>  
>
Strange the octave-forge sparse stuff for me working perfectly for these.

>  I have octave 2.1.71 from debian (octave2.1-headers and octave2.1)
>and a fresh CVS octave-forge (checkout, autogen.sh, config, make) in
>both cases.
>
>  I imagine there's @ least a dispatch issue, but don't know enough
>about dispatch to find it.
>
>  I would greatly appreciate if anyone had an explanation/fix.
>
>  
>
However, they also work perfectly in 2.9.3 and the sparse stuff there... 
The only thing in the octave-forge sparse stuff that isn't in 2.9.3 is 
the spinv and the iterative functions. The iterative functions are 
implemented as dot-m in octave-forge and so you can copy them, and I'm 
not sure where exactly you'd want to use spinv as the inverse of a 
sparse matrix is full. So I consider 2.9.3 to be in a good state to be 
considered as a replacement of the octave-forge sparse code. It is also 
in debian experimental so you could use pinning to get 2.9.3 under 
debian if you like...

The fact is with the new sparse stuff in octave I don't think its likely 
any bugs in the octave-forge will be tracked down...

Regards
David

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

[OctDev] [i,j,v] = find(sparse(1:10,1:10,1:10,11,11))

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

  Hi all,

on two different Debian machines, I get:

======================================================================
octave:3> [i,j,v] = find (sparse ([1 2 3 2],[2 4 2 5],1:4,30000,50000));
error: octave_base_value::array_value(): wrong type argument `sparse'
======================================================================

  Moreover on Machine 1, 

======================================================================
octave:2> [i,j,v] = spfind(sparse(1:10,1:10,1:10,11,11))
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
======================================================================

  Whereas w/ Machine 2, I get:

======================================================================
octave:5> [i,j,v] = spfind(sparse(1:10,1:10,1:10,11,11))
[snip] ... normal output ...
======================================================================


  I have octave 2.1.71 from debian (octave2.1-headers and octave2.1)
and a fresh CVS octave-forge (checkout, autogen.sh, config, make) in
both cases.

  I imagine there's @ least a dispatch issue, but don't know enough
about dispatch to find it.

  I would greatly appreciate if anyone had an explanation/fix.

  Tia,

  Etienne
 


======================================================================
Machine 1
======================================================================
uname output:     Linux anonimo 2.6.11 #3 SMP Wed Aug 10 15:09:03 UTC 2005 i686 GNU/Linux
configure opts:   '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3' '--with-lapack=-llapack-3' '--with-hdf5' '--with-fftw' '--with-f77=/usr/bin/g77' '--enable-shared' '--enable-rpath' '--disable-static' '--build' 'i486-linux-gnu' 'CC=/usr/bin/gcc' 'CXX=/usr/bin/g++' 'F77=/usr/bin/g77' 'build_alias=i486-linux-gnu'
Fortran compiler: /usr/bin/g77
FFLAGS:           -O2
F2C:              
F2CFLAGS:         
FLIBS:            -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6 -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. -lhdf5 -lz -lfrtbegin -lg2c -lm -lgcc_s
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc 
C compiler:       /usr/bin/gcc, version 3.3.6 (Debian 1:3.3.6-7)
CFLAGS:           -O2
CPICFLAG:         -fPIC
C++ compiler:     /usr/bin/g++, version 3.3.6
CXXFLAGS:         -O2
CXXPICFLAG:       -fPIC
LD_CXX:           /usr/bin/g++
LDFLAGS:          -s
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-2.1.71
BLAS_LIBS:        -llapack-3 -lblas-3
FFTW_LIBS:        -lfftw3
LIBS:             -lreadline  -lncurses -ldl -lhdf5 -lz -lm 
LEXLIB:           
LIBPLPLOT:        
LIBDLFCN:         
LIBGLOB:          %OCTAVE_CONF_LIBGLOB%
SED:              /bin/sed
DEFS:

  -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION=""
  -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1
  -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
  -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
  -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
  -DHAVE_UNISTD_H=1 -DSEPCHAR=1 -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1
  -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1
  -DCXX_ABI=gnu_v3 -DHAVE_LIBM=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1
  -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_IEEE754_DATA_FORMAT=1
  -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __
  -DHAVE_BLAS=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1
  -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1
  -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1
  -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8
  -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos
  -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1
  -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1
  -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1
  -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MEMORY_H=1
  -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDLIB_H=1
  -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1
  -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1
  -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1
  -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1
  -DHAVE_UNISTD_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1
  -DHAVE_SGTTY_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1
  -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_DUP2=1
  -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1
  -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1
  -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1
  -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1
  -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1
  -DHAVE_KILL=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1
  -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1
  -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1
  -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1
  -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1
  -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1
  -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_STAT=1
  -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1
  -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1
  -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_VFPRINTF=1
  -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_LIBDL=1
  -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1
  -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1
  -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1
  -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1
  -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1
  -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1
  -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1
  -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DSYS_SIGLIST_DECLARED=1
  -DHAVE_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DHAVE_GETRUSAGE=1
  -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot"
  -DGNUPLOT_HAS_FRAMES=

======================================================================
Machine 2
======================================================================
uname output:     Linux madrid 2.4.22-1-686-smp #5 SMP Sat Oct 4 14:35:05 EST 2003 i686 GNU/Linux
configure opts:   '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3' '--with-lapack=-llapack-3' '--with-hdf5' '--with-fftw' '--with-f77=/usr/bin/g77' '--enable-shared' '--enable-rpath' '--disable-static' '--build' 'i486-linux-gnu' 'CC=/usr/bin/gcc' 'CXX=/usr/bin/g++' 'F77=/usr/bin/g77' 'build_alias=i486-linux-gnu'
Fortran compiler: /usr/bin/g77
FFLAGS:           -O2
F2C:              
F2CFLAGS:         
FLIBS:            -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6 -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. -lhdf5 -lz -lfrtbegin -lg2c -lm -lgcc_s
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc 
C compiler:       /usr/bin/gcc, version 3.3.6 (Debian 1:3.3.6-7)
CFLAGS:           -O2
CPICFLAG:         -fPIC
C++ compiler:     /usr/bin/g++, version 3.3.6
CXXFLAGS:         -O2
CXXPICFLAG:       -fPIC
LD_CXX:           /usr/bin/g++
LDFLAGS:          -s
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-2.1.71
BLAS_LIBS:        -llapack-3 -lblas-3
FFTW_LIBS:        -lfftw3
LIBS:             -lreadline  -lncurses -ldl -lhdf5 -lz -lm 
LEXLIB:           
LIBPLPLOT:        
LIBDLFCN:         
LIBGLOB:          %OCTAVE_CONF_LIBGLOB%
SED:              /bin/sed
DEFS:

  -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION=""
  -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1
  -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
  -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
  -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
  -DHAVE_UNISTD_H=1 -DSEPCHAR=1 -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1
  -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1
  -DCXX_ABI=gnu_v3 -DHAVE_LIBM=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1
  -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_IEEE754_DATA_FORMAT=1
  -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __
  -DHAVE_BLAS=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1
  -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1
  -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1
  -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8
  -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos
  -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1
  -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1
  -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1
  -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MEMORY_H=1
  -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDLIB_H=1
  -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1
  -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1
  -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1
  -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1
  -DHAVE_UNISTD_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1
  -DHAVE_SGTTY_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1
  -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_DUP2=1
  -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1
  -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1
  -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1
  -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1
  -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1
  -DHAVE_KILL=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1
  -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1
  -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1
  -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1
  -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1
  -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1
  -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_STAT=1
  -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1
  -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1
  -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_VFPRINTF=1
  -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_LIBDL=1
  -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1
  -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1
  -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1
  -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1
  -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1
  -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1
  -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1
  -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DSYS_SIGLIST_DECLARED=1
  -DHAVE_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DHAVE_GETRUSAGE=1
  -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot"
  -DGNUPLOT_HAS_FRAMES=

======================================================================


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

[OctDev] RE: Updated: octave-2.1.71-2

[Billings, P. <PBi...@SY...>]

I apologize, I was completely in error.  I mixed up which screen I was
looking at.  The octave-2.1.71-2 build you just put out was fast for matrix
ops as well.  The octave_config_info reflects both FFTW and lapack/blas
libs.

So sorry for the bad report!

Paul


> -----Original Message-----
> From: Paul Billings [mailto:pbi...@sy...]
> Sent: Monday, August 15, 2005 10:23 AM
> To: ant...@ya...
> Cc: mai...@oc...; oct...@li...
> Subject: RE: Updated: octave-2.1.71-2
>
>
> James,
>
> Good job on the FFTW packaging.  I can confirm identical FFT
> speeds with a version that I had explicitly built to work with FFTW.
>
> On the down side, however: matrix operations are slower.  Almost
> 70% slower for the 256x256 matrix multiply I just tested.
> octave_config_info('BLAS_LIBS') returns a blank string, whereas
> the previous build had returned "-llapack -lblas".  I didn't
> build these libraries, so they must be coming from Cygwin.
> Perhaps they should be added to the dependency tree for octave?
>
> Incidentally, your long-term goal of getting ATLAS into the
> build/installation procedure will be well worth it.  The matrix
> multiply when using the above mentioned libblas is almost a
> factor of 10 slower than when using ATLAS.
>
> Paul
>
>
> > -----Original Message-----
> > From: James R. Phillips [mailto:ant...@ya...]
> > Sent: Monday, August 15, 2005 3:10 AM
> > To: cyg...@cy...
> > Cc: mai...@oc...; oct...@li...
> > Subject: Updated: octave-2.1.71-2
> >
> >
> > INFO
> > ====
> > The cygwin octave package has been updated to release 2.1.71-2.
> >
> > Changes:
> >
> >  +Rebuilt to link against fftw3 libraries, for faster fft operations.
> >  +Links with --enable-auto-image-base flag to reduce need for
> > rebasing dlls.
> >  +Fixed packaging error related to /usr/share/info/dir
> >
> > More information in the octave-2.1.71.README file.
> >
> > GNU Octave is a (mostly Matlab (R) compatible) high-level
> > language, primarily
> > intended for numerical computations.  It provides a convenient
> > command-line
> > interface for solving linear and nonlinear problems numerically.
> >
> > Octave Home Page: http://www.octave.org
> >
> > UPDATE
> > ======
> >
> > To update your installation, click on the "Install Cygwin now"
> link on the
> > http://cygwin.com/ web page.  This downloads setup.exe to your
> > system.  Save it
> > and run setup, answer the questions and pick up 'octave' from the 'Math'
> > category. Then click on the 'skip' field next to 'octave' until
> > '2.1.71-2' is
> > displayed.
> >
> > DOWNLOAD:
> > =========
> > Note that downloads from sources.redhat.com (aka cygwin.com)
> > aren't allowed due
> > to bandwidth limitations.  This means that you will need to find
> > a mirror which
> > has this update, please choose the one nearest to you:
> >
> > http://cygwin.com/mirrors.html
> >
> >
> > QUESTIONS:
> > ==========
> > If you want to make a point or ask a question the Cygwin mailing
> > list is the
> > appropriate place.
> >
> >
> > CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
> > =================================
> > To unsubscribe to the cygwin-announce mailing list, look at the
> > "List-Unsubscribe: " tag in the email header of this message.
> > Send email to
> > the address specified there.  It will be in the format:
> >
> > cygwin-announce-unsubscribe-YOU=YOU...@cy...
> >
> > If you need more information on unsubscribing, start reading here:
> >
> > http://sources.redhat.com/lists.html#unsubscribe-simple
> >
> > Please read *all* of the information on unsubscribing that is available
> > starting at this URL.
> >
> > MAINTAINER
> > ==========
> > James R. Phillips
> >
> >
> >

[OctDev] RE: Updated: octave-2.1.71-2

[Billings, P. <PBi...@SY...>]

James,

Good job on the FFTW packaging.  I can confirm identical FFT speeds with a
version that I had explicitly built to work with FFTW.

On the down side, however: matrix operations are slower.  Almost 70% slower
for the 256x256 matrix multiply I just tested.
octave_config_info('BLAS_LIBS') returns a blank string, whereas the previous
build had returned "-llapack -lblas".  I didn't build these libraries, so
they must be coming from Cygwin.  Perhaps they should be added to the
dependency tree for octave?

Incidentally, your long-term goal of getting ATLAS into the
build/installation procedure will be well worth it.  The matrix multiply
when using the above mentioned libblas is almost a factor of 10 slower than
when using ATLAS.

Paul


> -----Original Message-----
> From: James R. Phillips [mailto:ant...@ya...]
> Sent: Monday, August 15, 2005 3:10 AM
> To: cyg...@cy...
> Cc: mai...@oc...; oct...@li...
> Subject: Updated: octave-2.1.71-2
>
>
> INFO
> ====
> The cygwin octave package has been updated to release 2.1.71-2.
>
> Changes:
>
>  +Rebuilt to link against fftw3 libraries, for faster fft operations.
>  +Links with --enable-auto-image-base flag to reduce need for
> rebasing dlls.
>  +Fixed packaging error related to /usr/share/info/dir
>
> More information in the octave-2.1.71.README file.
>
> GNU Octave is a (mostly Matlab (R) compatible) high-level
> language, primarily
> intended for numerical computations.  It provides a convenient
> command-line
> interface for solving linear and nonlinear problems numerically.
>
> Octave Home Page: http://www.octave.org
>
> UPDATE
> ======
>
> To update your installation, click on the "Install Cygwin now" link on the
> http://cygwin.com/ web page.  This downloads setup.exe to your
> system.  Save it
> and run setup, answer the questions and pick up 'octave' from the 'Math'
> category. Then click on the 'skip' field next to 'octave' until
> '2.1.71-2' is
> displayed.
>
> DOWNLOAD:
> =========
> Note that downloads from sources.redhat.com (aka cygwin.com)
> aren't allowed due
> to bandwidth limitations.  This means that you will need to find
> a mirror which
> has this update, please choose the one nearest to you:
>
> http://cygwin.com/mirrors.html
>
>
> QUESTIONS:
> ==========
> If you want to make a point or ask a question the Cygwin mailing
> list is the
> appropriate place.
>
>
> CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
> =================================
> To unsubscribe to the cygwin-announce mailing list, look at the
> "List-Unsubscribe: " tag in the email header of this message.
> Send email to
> the address specified there.  It will be in the format:
>
> cygwin-announce-unsubscribe-YOU=YOU...@cy...
>
> If you need more information on unsubscribing, start reading here:
>
> http://sources.redhat.com/lists.html#unsubscribe-simple
>
> Please read *all* of the information on unsubscribing that is available
> starting at this URL.
>
> MAINTAINER
> ==========
> James R. Phillips
>
>
>

[OctDev] Updated: octave-forge-2005.06.13-3

[James R. P. <ant...@ya...>]

INFO
====
The cygwin octave-forge package has been updated to release 2005.06.13-3.

There was a corrupted version of this upload that existed briefly on the
mirrors as octave-forge-2005.06.13-2; if you installed this, you definitely
need to update.

Changes:

 +Links with --enable-auto-image-base flag to reduce need for rebasing dlls
 +Supports (and requires) cygwin gsl package
 +New build script builds out-of-tree using shtool-mkshadow

More information in the octave-forge-2005.06.13-3.README file.

The octave-forge project contains over 500 contributed functions for GNU Octave
which are not in the main distribution. These functions are grouped according
to the following subdirectories: audio, comm, control, general, geometry,
ident, image, io, linear-algebra, miscellaneous, optim, path, plot, set,
signal, sparse, specfun, special-matrix, splines, statistics, strings, struct,
symbolic, time. The Cygwin distribution of octave-forge also incorporates
m-files from the octave-ci collection.

octave-forge home page: http://octave.sourceforge.net

octave-ci collection: ftp://ftp.ci.tuwien.ac.at/pub/octave/octave-ci.tar.gz



UPDATE
======

To update your installation, click on the "Install Cygwin now" link on the
http://cygwin.com/ web page.  This downloads setup.exe to your system.  Save it
and run setup, answer the questions and pick up 'octave-forge' from the 'Math'
category. Then click on the 'skip' field next to 'octave-forge' until
'2005.06.13-2' is
displayed.

DOWNLOAD:
=========
Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due
to bandwidth limitations.  This means that you will need to find a mirror which
has this update, please choose the one nearest to you: 

http://cygwin.com/mirrors.html


QUESTIONS:
==========
If you want to make a point or ask a question the Cygwin mailing list is the
appropriate place.


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=================================
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send email to
the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=YOU...@cy...

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

MAINTAINER
==========
James R. Phillips

[OctDev] Updated: octave-2.1.71-2

[James R. P. <ant...@ya...>]

INFO
====
The cygwin octave package has been updated to release 2.1.71-2.

Changes:

 +Rebuilt to link against fftw3 libraries, for faster fft operations.
 +Links with --enable-auto-image-base flag to reduce need for rebasing dlls.
 +Fixed packaging error related to /usr/share/info/dir

More information in the octave-2.1.71.README file.

GNU Octave is a (mostly Matlab (R) compatible) high-level language, primarily
intended for numerical computations.  It provides a convenient command-line
interface for solving linear and nonlinear problems numerically.

Octave Home Page: http://www.octave.org

UPDATE
======

To update your installation, click on the "Install Cygwin now" link on the
http://cygwin.com/ web page.  This downloads setup.exe to your system.  Save it
and run setup, answer the questions and pick up 'octave' from the 'Math'
category. Then click on the 'skip' field next to 'octave' until '2.1.71-2' is
displayed.

DOWNLOAD:
=========
Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due
to bandwidth limitations.  This means that you will need to find a mirror which
has this update, please choose the one nearest to you: 

http://cygwin.com/mirrors.html


QUESTIONS:
==========
If you want to make a point or ask a question the Cygwin mailing list is the
appropriate place.


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=================================
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send email to
the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=YOU...@cy...

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

MAINTAINER
==========
James R. Phillips

Re: [OctDev] difficulty with Octave_map.assign(string,Cell)

[paul <ppr...@wi...>]

Michael Hearne wrote:

>I'm getting a segmentation fault when trying to assign a Cell array to an
>Octave_map object, and I don't quite understand why.  What is the appropriate
>way to insert a cell array into an Octave_map?  Below is some sample code and
>the results I get.
>
>Thanks in advance,
>
>Mike
>
>-------------------------------------------------------------
>#include <oct.h>
>#include <ov-cell.h>
>#include <ov-struct.h>
>#include <string>
>
>using namespace std;
>
>DEFUN_DLD(testoctave, args, nargout,
>          "Play around with stuff."){
>	
>	Octave_map tstruct;
>	octave_cell cellnames;
>	message("1","Before cell assignment");
>	cellnames.assign(octave_value(1),octave_value("fred"));
>	cellnames.assign(octave_value(2),octave_value("wilma"));
>	message("2","Before struct 'couple' assignment");
>	tstruct.assign("couple","Flintstones");
>	message("3","Before struct 'names' assignment");
>	tstruct.assign("names",cellnames);
>	message("4","After struct 'names' assignment");
>	octave_value_list retval;
>	return retval;
>}
>-------------------------------------------------------------
>  
>
Michael,
  I got your program to work doing the following:

#include <oct.h>
#include <ov-cell.h>
#include <ov-struct.h>
#include <string>

using namespace std;

DEFUN_DLD(test2, args, nargout,
          "Play around with stuff."){
   
    Octave_map tstruct;
    Cell cellnames(dim_vector(1,2));
    message("1","Before cell assignment");
  cellnames(0)=string("fred");
  cellnames(1)=string("wilma");
    message("2","Before struct 'couple' assignment");
    tstruct.assign("couple","Flintstones");
    message("3","Before struct 'names' assignment");
    tstruct.assign("names",octave_value(cellnames));
    message("4","After struct 'names' assignment");
    octave_value_list retval;
  retval.append(tstruct);
    return retval;
}

As always with writing .oct programs, I'm not sure what made it work. 
I've never had much luck using octave_cell instead of Cell, and one of 
my gripes is that there are no comments in the headers as to what these 
things are intended for.

Paul Probert

[OctDev] difficulty with Octave_map.assign(string,Cell)

[Michael H. <mhe...@ya...>]

I'm getting a segmentation fault when trying to assign a Cell array to an
Octave_map object, and I don't quite understand why.  What is the appropriate
way to insert a cell array into an Octave_map?  Below is some sample code and
the results I get.

Thanks in advance,

Mike

-------------------------------------------------------------
#include <oct.h>
#include <ov-cell.h>
#include <ov-struct.h>
#include <string>

using namespace std;

DEFUN_DLD(testoctave, args, nargout,
          "Play around with stuff."){
	
	Octave_map tstruct;
	octave_cell cellnames;
	message("1","Before cell assignment");
	cellnames.assign(octave_value(1),octave_value("fred"));
	cellnames.assign(octave_value(2),octave_value("wilma"));
	message("2","Before struct 'couple' assignment");
	tstruct.assign("couple","Flintstones");
	message("3","Before struct 'names' assignment");
	tstruct.assign("names",cellnames);
	message("4","After struct 'names' assignment");
	octave_value_list retval;
	return retval;
}
-------------------------------------------------------------

The results look like this:

1: Before cell assignment
2: Before struct 'couple' assignment
3: Before struct 'names' assignment
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault

Re: [OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

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

On Thu, Jul 28, 2005 at 07:32:03AM -0400, Paul Kienzle wrote:
>=20
> Rather than peppering our code with #ifdef, I would suggest supporting=20
> the
> latest API only and writing a translation layer to the older APIs.  Let
> configure sort out whether the translation is included.  Maybe somebody
> has already done so and gave it to the libMagick community?  Or are the
> API's so incompatible that this won't work?

Maybe the higher-level libMagick++ doesn't suffer from these
problems.  I'll take a look.

Regards
St=E9fan

Re: [OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

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

On Jul 27, 2005, at 10:56 PM, Andy Adler wrote:

> On 7/27/05, Paul Kienzle <pki...@us...> wrote:
>>
>> On Jul 26, 2005, at 3:57 AM, Stefan van der Walt wrote:
>>
>>> On Tue, Jul 26, 2005 at 12:06:14AM -0400, Andy Adler wrote:
>>>> Damn. libMagick API versions was a problem three years ago. I 
>>>> decided to
>>>> ignore them for a few years to hope they sorted themselves out. 
>>>> Looks like I'll
>>>> have to wait for another few years.
>>>
>>> I hoped that we could use libraries like libgd or libimlib, but these
>>> are all huge overkill.
>>
>> Can the additional features of these libraries be exposed to octave,
>> and maybe replace some of the other functions in the image processing
>> toolbox?
>
> For a general purpose image processing interface, the libMagick API
> is really the best. It transparently handles all image formats and 
> offers
> the ability to do lots of image processing operations. Unfortunately,
> different versions change significantly, so the code will be littered 
> with
> #ifdefs. This still may be the best solution. If imread depends on
> imagemagick binaries, then depending on the libraries should be OK.

Rather than peppering our code with #ifdef, I would suggest supporting 
the
latest API only and writing a translation layer to the older APIs.  Let
configure sort out whether the translation is included.  Maybe somebody
has already done so and gave it to the libMagick community?  Or are the
API's so incompatible that this won't work?

- Paul

Re: [OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[Andy A. <ax...@gm...>]

On 7/27/05, Paul Kienzle <pki...@us...> wrote:
>=20
> On Jul 26, 2005, at 3:57 AM, Stefan van der Walt wrote:
>=20
> > On Tue, Jul 26, 2005 at 12:06:14AM -0400, Andy Adler wrote:
> >> Damn. libMagick API versions was a problem three years ago. I decided =
to
> >> ignore them for a few years to hope they sorted themselves out. Looks =
like I'll
> >> have to wait for another few years.
> >
> > I hoped that we could use libraries like libgd or libimlib, but these
> > are all huge overkill.
>=20
> Can the additional features of these libraries be exposed to octave,
> and maybe replace some of the other functions in the image processing
> toolbox?

For a general purpose image processing interface, the libMagick API
is really the best. It transparently handles all image formats and offers
the ability to do lots of image processing operations. Unfortunately,=20
different versions change significantly, so the code will be littered with
#ifdefs. This still may be the best solution. If imread depends on=20
imagemagick binaries, then depending on the libraries should be OK.

Andy

Re: [OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

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

On Jul 26, 2005, at 9:43 PM, Andy Adler wrote:

> On 7/26/05, Stefan van der Walt <st...@su...> wrote:
>> Please see the attached imread2.m, pngread.cc etc.
>>
>> The only thing to note about these is that they already return colour
>> images in the MxNx3 format.  Octave 2.9 branch supports showing these,
>> but many other functions don't (yet).  I don't think this should be a
>> problem if I provide an im2gray function, though.
>
> In my opinion, you should commit these. Imread2 should replace
> imread. As we move to Octave 3.0, now is the time to clean out cruft
> like imread returning parameters compatible with matlab 4.
>
> Do any others have opinions on this?

It would be nice to support old and new versions of Matlab's 
ever-changing API so that as much as possible code just works.  
However, with nobody willing do do the work, I agree that dropping the 
Matlab 4 support is the best path forward.  Someday somebody who cares 
can implement a v4 wrapper on functions which have changed.

- Paul

Re: [OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

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

On Jul 26, 2005, at 3:57 AM, Stefan van der Walt wrote:

> On Tue, Jul 26, 2005 at 12:06:14AM -0400, Andy Adler wrote:
>> Damn. libMagick API versions was a problem three years ago. I decided 
>> to
>> ignore them for a few years to hope they sorted themselves out. Looks 
>> like I'll
>> have to wait for another few years.
>
> I hoped that we could use libraries like libgd or libimlib, but these
> are all huge overkill.

Can the additional features of these libraries be exposed to octave,
and maybe replace some of the other functions in the image processing 
toolbox?

- Paul

Re: [OctDev] structure type in .oct files

[<so...@ha...>]

Michael Hearne wrote:
(snip)
> 2)  Can you create struct objects in a .oct file?  If
> so, are there any examples of this in existing
> modules?
You might want to take a look at
http://perso.wanadoo.fr/prthomas/intro.html#structure

> Mike
/S=F8ren

[OctDev] structure type in .oct files

[Michael H. <mhe...@ya...>]

All:  I am developing a module to allow Octave users
access to ESRI-compatible shapefiles using the
shapelib (http://shapelib.maptools.org/) API.  I have
two questions:

1)  Has anyone already done this, in which case I
suppose I should stop...:)
2)  Can you create struct objects in a .oct file?  If
so, are there any examples of this in existing
modules?

Thanks,

Mike

Re: [OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[<so...@ha...>]

Andy Adler wrote:
(snip)
> In my opinion, you should commit these. Imread2 should replace
> imread. As we move to Octave 3.0, now is the time to clean out cruft
> like imread returning parameters compatible with matlab 4.
>=20
> Do any others have opinions on this?
I couldn't agree more. One of the great things about major releases is=20
that the old "garbage" can be thrown out.

> Andy
/S=F8ren

[OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[Andy A. <ax...@gm...>]

On 7/26/05, Stefan van der Walt <st...@su...> wrote:
> Please see the attached imread2.m, pngread.cc etc.
>=20
> The only thing to note about these is that they already return colour
> images in the MxNx3 format.  Octave 2.9 branch supports showing these,
> but many other functions don't (yet).  I don't think this should be a
> problem if I provide an im2gray function, though.

In my opinion, you should commit these. Imread2 should replace
imread. As we move to Octave 3.0, now is the time to clean out cruft
like imread returning parameters compatible with matlab 4.

Do any others have opinions on this?

Andy

[OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

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

On Tue, Jul 26, 2005 at 12:06:14AM -0400, Andy Adler wrote:
> Damn. libMagick API versions was a problem three years ago. I decided t=
o
> ignore them for a few years to hope they sorted themselves out. Looks l=
ike I'll
> have to wait for another few years.

I hoped that we could use libraries like libgd or libimlib, but these
are all huge overkill.

> For now, I'll modify imread to use jpgread/pngread. Tell me when you've
> committed your modifications.

Please see the attached imread2.m, pngread.cc etc.

The only thing to note about these is that they already return colour
images in the MxNx3 format.  Octave 2.9 branch supports showing these,
but many other functions don't (yet).  I don't think this should be a
problem if I provide an im2gray function, though.

'imread2' also makes use of files instead of pipes, since those
are rather slow.  The ImageMagick 'identify' utility is used to decide
on the image depth.

Regards
St=E9fan

[OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[Andy A. <ax...@gm...>]

Damn. libMagick API versions was a problem three years ago. I decided to
ignore them for a few years to hope they sorted themselves out. Looks like =
I'll
have to wait for another few years.

For now, I'll modify imread to use jpgread/pngread. Tell me when you've
committed your modifications.

Andy

On 7/25/05, Stefan van der Walt <st...@su...> wrote:
> ImageMagick unfortunately also links to libjpeg and libpng to read
> those two formats.  Also, the libMagick API has changed from version 6
> to 8 -- some distributions like Debian keep to v6 while others like
> Mandrake have moved to v8.
>=20
> Whichever way, the API example given on their webpage compiles but
> doesn't run with either versions!
>=20
> St=E9fan
>=20
> On Sun, Jul 24, 2005 at 08:24:11AM -0400, Andy Adler wrote:
> > St=E9fan,
> >
> > That sounds like a good idea. On the other hand, a better implementatio=
n
> > would be to write an oct file  to link to the imagemagick libraries dir=
ectly.
> >
> > After that, the only reason to have jpgread etc is for users that don't=
 have
> > libmagick.a.
> >
> > What do you think?
> >
> > Andy
> >
> > On 7/24/05, Stefan van der Walt <st...@su...> wrote:
> > > Last time I checked, the pipes implementation was much slower than th=
e
> > > file approach for large images.  Can you verify whether this is still
> > > the case?
> > >
> > > I have made some fixes to pngread and jpegread, which I will submit
> > > soon.  Then, we can use those functions in imread.m to load JPGs and
> > > PNGs, but revert to ImageMagick otherwise.
> > >
> > > Regards
> > > St=E9fan
>