octave-dev — GNU Octave developers' list

[OctDev] new minimization functions

[Michael C. <mic...@ua...>]

I've put some new minimization functions in CVS, in the directory 
main/optim/mintoolkit. They're in a directory of their own so that their 
interdependencies are more clear. I'll add some documentation shortly, but 
for now there are example files. Any comments are welcome, and can anyone 
tell me how to delete the Optimize subdirectory from main/optim? Or is it 
already gone? (CVS newbie)

Regards, Michael

[OctDev] automatic_replot

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

Dear All,

"automatic_replot" is now default to 1 and so this breaks some code in
octave-forge. In particular my comms code in apkconst, eyediagram, 
modmap, qaskenco, scatterplot. If you use plotting in octave-forge you
should carefully if it now does what you want it to. In particular 
my problem was code like thie

  unwind_protect
    ...
    title("Dummy title");
    ...
  unwind_protect_cleanup
    title("");
  end_unwind_protect

which I had to change to be

  try ar = automatic_replot;
  catch ar = 0;
  end

  unwind_protect
    ...
    title("Dummy title");
    ...
  unwind_protect_cleanup
    title("");
    automatic_replot = ar;
  end_unwind_protect

I'll check in code for my changes soon.

Regards
David

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

The information contained in this communication has been classified as: 

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

[OctDev] optim directory

[Michael C. <mic...@ua...>]

There has clearly been a lot of work by people like Ben Sapp and Etienne 
Grossman behind the files in main/optim, but some of this is getting out of 
date in that it generates error messages due to use of deprecated functions, 
or has been superceded by improved versions.

I'm offering to try to clean up main/optim by moving files that generate error 
messages to main/optim/deprecated, and eliminating files that are superceded 
by improved versions, even if it will break things that go to deprecated. 

I suggest that any function for optimization that gets into main/optim should 
be able to deal with objective functions of the form

[obj_value, whatever_else,...] = f(args)

where args is a cell array that must include the parameter to be minimized 
over, and which may include data and other fixed parameters. args may be 
defined as a vector (or scalar) if there is only one argument. By default, 
minimization should be with respect to the first element of args, but with 
the possibility to select other elements.

If we can agree on a function interface, it will be a lot easier to agree upon 
what goes into main/optim, and code re-use will be a lot more simple.

Comments?

Michael

[OctDev] Re: oct files for BFGS, numeric derivatives

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

On Mar 9, 2004, at 10:32 AM, Michael Creel wrote:

> It seems that camelcase filenames are not common in the octave world,  
> so I'm a
> bit uncomfortable with the names I'm using. I would use bfgs, newton,
> gradient and hessian as file names, but there are already files in
> octave-forge with these or very similar names. Any suggestions?

Yes --- only have one copy of the functions.   How do you
expect the user to decide between Hessian and hessian?
Rather than octave-forge being a collection of all the code
ever written for octave, I would rather have it as the best
we know of for octave.

And the sooner we make API changes the better, since we
are experiencing exponential growth:

http://sourceforge.net/project/stats/index.php? 
report=months&group_id=2888

Paul Kienzle
pki...@us...

Re: [OctDev] A fix for edit.m

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

On Mar 4, 2004, at 4:51 AM, Per Persson wrote:

> Hi,
> on Mac OS X edit.m breaks when issuing 'edit' without any parameters.
> The cause seems to be a difference in how whitespace is treated (on OS 
> X spaces are allowed in file- & pathnames).
> The [EDITOR %s] part comes out as 'emacs ' (trailing space) instead of 
> 'emacs'.
>
> A potentital fix is pasted below. I don't have any other system to 
> test it on so I won't commit it just yet.

I prefer the following fix.  In the rest of the function
I am not protecting the editor command with quotes, so why
should I if no file name is given?  If the user needs quotes, they
can put them on themselves using

	edit  editor  "'path with spaces/editor' %s"

A more awkward issue is whether edit.m should put quotes around %s.
The user can't do it because that will break edit without any 
parameters.
edit.m shouldn't do it because some editor commands won't what single
quotes surrounding the file name.  Suggestions?


diff -c -p -r1.12 edit.m
*** edit.m      16 Dec 2003 21:53:46 -0000      1.12
--- edit.m      5 Mar 2004 05:42:54 -0000
*************** function edit(file,state)
*** 100,106 ****

     ## start the editor without a file if no file is given
     if nargin < 1
!     system(['cd "',FUNCTION_HOME,'" ; "',sprintf(FUNCTION_EDITOR,""), 
'"']);
       return
     endif

--- 100,106 ----

     ## start the editor without a file if no file is given
     if nargin < 1
!     system(['cd "',FUNCTION_HOME,'" ; ',sprintf(FUNCTION_EDITOR,"")]);
       return
     endif


>
> /Per
>
> Index: edit.m
> ===================================================================
> RCS file: /cvsroot/octave/octave-forge/main/miscellaneous/edit.m,v
> retrieving revision 1.12
> diff -u -d -b -w -r1.12 edit.m
> --- edit.m      16 Dec 2003 21:53:46 -0000      1.12
> +++ edit.m      1 Mar 2004 10:23:41 -0000
> @@ -100,7 +100,7 @@
>
>    ## start the editor without a file if no file is given
>    if nargin < 1
> -    system(['cd "',FUNCTION_HOME,'" ; "',sprintf(FUNCTION_EDITOR,""), 
> '"']);
> +    system(['cd "',FUNCTION_HOME,'" ; "',strtok(FUNCTION_EDITOR, " 
> "),'"']);
>      return
>    endif
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] A fix for edit.m

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

Hi,
on Mac OS X edit.m breaks when issuing 'edit' without any parameters.
The cause seems to be a difference in how whitespace is treated (on OS 
X spaces are allowed in file- & pathnames).
The [EDITOR %s] part comes out as 'emacs ' (trailing space) instead of 
'emacs'.

A potentital fix is pasted below. I don't have any other system to test 
it on so I won't commit it just yet.

/Per

Index: edit.m
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/miscellaneous/edit.m,v
retrieving revision 1.12
diff -u -d -b -w -r1.12 edit.m
--- edit.m      16 Dec 2003 21:53:46 -0000      1.12
+++ edit.m      1 Mar 2004 10:23:41 -0000
@@ -100,7 +100,7 @@

    ## start the editor without a file if no file is given
    if nargin < 1
-    system(['cd "',FUNCTION_HOME,'" ; "',sprintf(FUNCTION_EDITOR,""), 
'"']);
+    system(['cd "',FUNCTION_HOME,'" ; "',strtok(FUNCTION_EDITOR, " 
"),'"']);
      return
    endif

[OctDev] Re: Regarding Octave

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

On Mon, Mar 01, 2004 at 09:50:52AM -0800, Henry F. Mollet wrote:
# Do I have this roughly correct for Mac OS X 10.2.8?
# Henry
# 1. qhull = symolic tookbox. What does qhull stand for? A recent posting by

  Nope! It's the contrary. 

  QHull is for Convex Hull (of a set of points) : it's computational
geometry.

# Per Persson indicated that he's working on it to make it work.
# 
# 2. ginac = geometry toolbox. What does ginac stand for? As above for qhull
# re use on Mac OS X.

  Symbolic toolbox. From the description of the Debian package:
GiNaC (which stands for "GiNaC is Not a CAS (Computer Algebra
System)") is a library for doing symbolic (i.e. non-numeric)
computation directly in the C++ programming language.

# 3. atlas = automatically tuned linear algebra subgroups. No longer needed in
# OS X 10.2 because atlas is provided as part of vecLib which includes blas,
# lapack, vDSP, and vMathLib.
# 
# 4. fftw = discrete fourier transform. Can it be considered to be a toolbox?
# When I last installed octave 2.1.46 using fink it was part of the
# installation. I most likely have not used it, would not know how to use it
# but I know what a discrete fourier tranform is because I use it in the
# analysis of life cycle graphs.
# 
# 5. hdf = scientific data format. Can it considered to be a toolbox? What
# exactly does it do? Fink installed it but I doubt that I've used it, nor
# would I know how to use it.
# 

  Save data in .hdf format, a "universal" format for numerical data,
iigc.

  Hth,

  Etienne

# 
# 
# 
# 
# on 2/29/04 12:48 PM, Paul Kienzle at pki...@us... wrote:
# 
# > 
# > On Feb 29, 2004, at 11:59 AM, Etienne Grossmann wrote:
# > 
# >> 
# >>   Hi,
# >> 
# >> if you use Debian Linux, it can be as simple as entering the commands
# >> 
# >>   apt-get install octave2.1
# >> 
# >> and octave-2.1 will be installed. I don't know how it works w/ other
# >> linux distributions, but I think Red Hat and Suse have Octave binary
# >> packages. This seems to be what is said on octave's download page
# >> 
# >>   http://www.octave.org/download.html
# >> 
# >> You did read the 'binaries' section of that page, right?
# >> 
# >>   For Windows -not my area of expertise- it points to cygwin and
# >> octave-forge. In the later, at
# >> 
# >>   http://sourceforge.net/project/showfiles.php?group_id=2888
# >> 
# >> I see a file called
# >> 
# >>   octave-2.1.50a-inst.exe
# >> 
# >> this *may* be a binary for octave itself. Hey! Someone on the list? Is
# >> this an octave binary? Anyone who knows, please answer!
# > 
# > Yes, octave-2.1.50a-inst.exe is an installable package with
# > octave+octave-forge+gnuplot+cygwin all bundled together.
# > It uses different registry keys from Cygwin, so it won't interfere
# > with an existing installation.  It does not use Atlas or FFTW
# > or HDF.  Qhull and GiNaC are not included, so no symbolic
# > and no geometry toolbox.
# > 
# > For those without broadband, I would prefer to have these
# > available as separate packages but that will be a project
# > for somebody else.
# > 
# > Paul Kienzle
# > pki...@us...
# > 
# > 
# > 
# > -------------------------------------------------------------
# > Octave is freely available under the terms of the GNU GPL.
# > 
# > Octave's home on the web:  http://www.octave.org
# > How to fund new projects:  http://www.octave.org/funding.html
# > Subscription information:  http://www.octave.org/archive.html
# > -------------------------------------------------------------
# 

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

[OctDev] Re: Regarding Octave

[Henry F. M. <mo...@pa...>]

Do I have this roughly correct for Mac OS X 10.2.8?
Henry
1. qhull = symolic tookbox. What does qhull stand for? A recent posting by
Per Persson indicated that he's working on it to make it work.

2. ginac = geometry toolbox. What does ginac stand for? As above for qhull
re use on Mac OS X.

3. atlas = automatically tuned linear algebra subgroups. No longer needed in
OS X 10.2 because atlas is provided as part of vecLib which includes blas,
lapack, vDSP, and vMathLib.

4. fftw = discrete fourier transform. Can it be considered to be a toolbox?
When I last installed octave 2.1.46 using fink it was part of the
installation. I most likely have not used it, would not know how to use it
but I know what a discrete fourier tranform is because I use it in the
analysis of life cycle graphs.

5. hdf = scientific data format. Can it considered to be a toolbox? What
exactly does it do? Fink installed it but I doubt that I've used it, nor
would I know how to use it.






on 2/29/04 12:48 PM, Paul Kienzle at pki...@us... wrote:

> 
> On Feb 29, 2004, at 11:59 AM, Etienne Grossmann wrote:
> 
>> 
>>   Hi,
>> 
>> if you use Debian Linux, it can be as simple as entering the commands
>> 
>>   apt-get install octave2.1
>> 
>> and octave-2.1 will be installed. I don't know how it works w/ other
>> linux distributions, but I think Red Hat and Suse have Octave binary
>> packages. This seems to be what is said on octave's download page
>> 
>>   http://www.octave.org/download.html
>> 
>> You did read the 'binaries' section of that page, right?
>> 
>>   For Windows -not my area of expertise- it points to cygwin and
>> octave-forge. In the later, at
>> 
>>   http://sourceforge.net/project/showfiles.php?group_id=2888
>> 
>> I see a file called
>> 
>>   octave-2.1.50a-inst.exe
>> 
>> this *may* be a binary for octave itself. Hey! Someone on the list? Is
>> this an octave binary? Anyone who knows, please answer!
> 
> Yes, octave-2.1.50a-inst.exe is an installable package with
> octave+octave-forge+gnuplot+cygwin all bundled together.
> It uses different registry keys from Cygwin, so it won't interfere
> with an existing installation.  It does not use Atlas or FFTW
> or HDF.  Qhull and GiNaC are not included, so no symbolic
> and no geometry toolbox.
> 
> For those without broadband, I would prefer to have these
> available as separate packages but that will be a project
> for somebody else.
> 
> Paul Kienzle
> pki...@us...
> 
> 
> 
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
> 
> Octave's home on the web:  http://www.octave.org
> How to fund new projects:  http://www.octave.org/funding.html
> Subscription information:  http://www.octave.org/archive.html
> -------------------------------------------------------------

[OctDev] Re: Regarding Octave

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

On Feb 29, 2004, at 11:59 AM, Etienne Grossmann wrote:

>
>   Hi,
>
> if you use Debian Linux, it can be as simple as entering the commands
>
>   apt-get install octave2.1
>
> and octave-2.1 will be installed. I don't know how it works w/ other
> linux distributions, but I think Red Hat and Suse have Octave binary
> packages. This seems to be what is said on octave's download page
>
>   http://www.octave.org/download.html
>
> You did read the 'binaries' section of that page, right?
>
>   For Windows -not my area of expertise- it points to cygwin and
> octave-forge. In the later, at
>
>   http://sourceforge.net/project/showfiles.php?group_id=2888
>
> I see a file called
>
>   octave-2.1.50a-inst.exe
>
> this *may* be a binary for octave itself. Hey! Someone on the list? Is
> this an octave binary? Anyone who knows, please answer!

Yes, octave-2.1.50a-inst.exe is an installable package with
octave+octave-forge+gnuplot+cygwin all bundled together.
It uses different registry keys from Cygwin, so it won't interfere
with an existing installation.  It does not use Atlas or FFTW
or HDF.  Qhull and GiNaC are not included, so no symbolic
and no geometry toolbox.

For those without broadband, I would prefer to have these
available as separate packages but that will be a project
for somebody else.

Paul Kienzle
pki...@us...

[OctDev] Re: Regarding Octave

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

  Hi,

if you use Debian Linux, it can be as simple as entering the commands

  apt-get install octave2.1

and octave-2.1 will be installed. I don't know how it works w/ other
linux distributions, but I think Red Hat and Suse have Octave binary
packages. This seems to be what is said on octave's download page 

  http://www.octave.org/download.html

You did read the 'binaries' section of that page, right? 

  For Windows -not my area of expertise- it points to cygwin and
octave-forge. In the later, at

  http://sourceforge.net/project/showfiles.php?group_id=2888

I see a file called

  octave-2.1.50a-inst.exe

this *may* be a binary for octave itself. Hey! Someone on the list? Is
this an octave binary? Anyone who knows, please answer!

  Hth,

  Etienne



On Sun, Feb 29, 2004 at 07:25:03AM -0800, Saba Karim Shah wrote:
# Hi,
# 
# Thanks for your reply, I hope it will be of help. Can
# you please let me know the exact links of the files
# that I can download both for Linux and for Windows. 
# 
# I am fimilar with Linux and with Windows as well. I am
# also familiar with command based programs.
# 
# Regards,
# Saba Karim
# 
[snip]

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

Re: [OctDev] Re: Three build failures on alpha,hppa,ia64 (Re: octave-forge 2004-02-12 release)

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

On Fri, Feb 13, 2004 at 08:03:25AM -0500, Paul Kienzle wrote:
> Replacing the $(CC) with $(MKOCTFILE) in
> main/miscellaneous/Makefile should work.  We have another

Yes, it seems to have worked -- the 2004.02.12 upload with my patch below
has already built on a few systems, including the three where it had failed
previously. From http://buildd.debian.org/build.php?pkg=octave-forge :

2004.02.12-1 (ia64) (latest build at Feb 12 23:48: maybe-successful)
2004.02.12-1 (alpha) (latest build at Feb 12 23:56: maybe-successful)
2004.02.12-1 (s390) (latest build at Feb 12 23:56: maybe-successful)
2004.02.12-1 (hppa) (latest build at Feb 12 23:56: maybe-successful)
2004.02.12-1 (sparc) (latest build at Feb 13 00:28: maybe-successful)
2004.02.12-1 (powerpc) (latest build at Feb 12 23:59: maybe-successful)
2004.02.12-1 (arm) (latest build at Feb 13 02:27: maybe-successful)
      
Dirk

> problem, though, in that the yyin symbol from xmltree_read
> conflicts with the yyin/yyout symbols from octave's lexer, giving the
> following error on OS X:
> 
> mkoctfile -DHAVE_OCTAVE_21 -v xmlread.o xmltree_read.o xmltree.o -o  
> xmlread.oct
> g++ -bundle -bundle_loader /opt/local/bin/octave-2.1.50 -o xmlread.oct  
> xmlread.o xmltree_read.o xmltree.o -L/opt/local/lib/octave-2.1.50  
> -loctave -lcruft -loctinterp -framework vecLib
> ld: warning multiple definitions of symbol _yyin
> xmltree_read.o definition of _yyin in section (__DATA,__data)
> /opt/local/bin/octave-2.1.50 definition of _yyin
> ld: warning multiple definitions of symbol _yyout
> xmltree_read.o definition of _yyout in section (__DATA,__data)
> /opt/local/bin/octave-2.1.50 definition of _yyout
> 
> Any ideas?
> 
> Paul Kienzle
> pki...@us...
> 
> On Feb 12, 2004, at 10:19 PM, Dirk Eddelbuettel wrote:
> 
> >On Thu, Feb 12, 2004 at 01:53:22PM -0600, Dirk Eddelbuettel wrote:
> >>On Thu, Feb 12, 2004 at 03:28:39AM -0500, Paul Kienzle wrote:
> >>>Tested against octave-2.1.53 and octave-2.1.40.  Many functions will
> >>>also work on earlier versions of Octave.  Use make -k to build what
> >>>functions can be built and ignore the rest.
> >>
> >>Cf http://buildd.debian.org/build.php?pkg=octave-forge and see the  
> >>build
> >>failures for alpha, hppa and ia64 for the Feb 9 snapshot I uploaded  
> >>earlier
> >>-- all in the same xml area. hppa may have the best compiler warning  
> >>in
> >>http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.02.09 
> >>-1&arch=hppa&stamp=1076389950&file=log&as=raw
> >>
> >>mkoctfile -DHAVE_OCTAVE_21 -v -c xmlread.cc -o xmlread.o
> >>/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.53
> >>-I/usr/include/octave-2.1.53/octave -O2 -DHAVE_OCTAVE_21 xmlread.cc -o
> >>xmlread.o
> >>/usr/bin/gcc -c xmltree_read.c -o xmltree_read.o
> >>/usr/bin/gcc -c xmltree.c -o xmltree.o
> >>mkoctfile -DHAVE_OCTAVE_21 -v xmlread.o xmltree_read.o xmltree.o -o
> >>xmlread.oct
> >>/usr/bin/g++ -shared -o xmlread.oct xmlread.o xmltree_read.o xmltree.o
> >>/usr/bin/ld: xmltree_read.o: relocation R_PARISC_DPREL21L can not be  
> >>used
> >>when making a shared object; recompile with -fPIC
> >>xmltree_read.o: could not read symbols: Bad value
> >>collect2: ld returned 1 exit status
> >>make[3]: *** [xmlread.oct] Error 1
> >>make[3]: Leaving directory
> >>build/buildd/octave-forge-2004.02.09/main/miscellaneous'
> >>make[2]: *** [miscellaneous/] Error 2
> >>make[2]: Leaving directory build/buildd/octave-forge-2004.02.09/main'
> >>make[1]: *** [main/] Error 2
> >>make[1]: Leaving directory build/buildd/octave-forge-2004.02.09'
> >>make: *** [build-stamp] Error 2
> >>********************************************************************** 
> >>********
> >>Build finished at 20040210-0512
> >>FAILED [dpkg-buildpackage died]
> >>
> >>xmlread is compiled with -fPIC, xmltree isn't. Could someone have a  
> >>look at
> >>the corresponding Makefile and send a patch?
> >>
> >>Thanks!
> >
> >This seems to at least not do harm on i386 where the resulting xmlread  
> >still
> >appears to work. Well the help comes up, and 'xmlread("/dev/null")'  
> >ends
> >gracefully.  We'll see what alpha, hppa and ia64 will do.
> >
> >--- octave-forge-2004.02.12.orig/main/miscellaneous/Makefile
> >+++ octave-forge-2004.02.12/main/miscellaneous/Makefile
> >@@ -23,7 +23,8 @@
> > 	$(MKOCTFILE) -c listencanfork.c
> >
> > xmltree.o: xmltree.c xmltree.h
> >-	$(CC) -c $< -o $@
> >+	$(MKOCTFILE) $(MISCDEFS) -c $<
> >+#	$(CC) -c $< -o $@
> >
> > ifdef FLEXML
> > xmltree_read.l: xmltree_read.act octave.dtd
> >@@ -36,12 +37,15 @@
> > endif
> >
> > xmltree_read.o: xmltree_read.c xmltree_read.h
> >-	$(CC) -c $< -o $@
> >+	$(MKOCTFILE) $(MISCDEFS) -c $<
> >+#	$(CC) -c $< -o $@
> >
> > xmlread.o: xmlread.cc xmltree_read.h xmltree.h
> >-	$(MKOCTFILE) -c $< -o $@
> >+	$(MKOCTFILE) $(MISCDEFS) -c $<
> >+#	$(MKOCTFILE) -c $< -o $@
> >
> > xmlread.oct: xmlread.o xmltree_read.o xmltree.o
> >-	$(MKOCTFILE) $^ -o $@
> >+	$(MKOCTFILE) $^
> >+#	$(MKOCTFILE) $^ -o $@
> >
> > clean: ; -$(RM) *.o octave-core core *.oct *~
> >
> >
> >>
> >>Dirk
> >>
> >>-- 
> >>The relationship between the computed price and reality is as yet  
> >>unknown.
> >>                                             -- From the pac(8)  
> >>manual page
> >
> >-- 
> >The relationship between the computed price and reality is as yet  
> >unknown.
> >                                             -- From the pac(8) manual  
> >page
> >
> >
> >-------------------------------------------------------
> >SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >Build and deploy apps & Web services for Linux with
> >a free DVD software kit from IBM. Click Now!
> >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >_______________________________________________
> >Octave-dev mailing list
> >Oct...@li...
> >https://lists.sourceforge.net/lists/listinfo/octave-dev
> >
> 
> 

-- 
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

Re: [OctDev] Re: Three build failures on alpha,hppa,ia64 (Re: octave-forge 2004-02-12 release)

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

Replacing the $(CC) with $(MKOCTFILE) in
main/miscellaneous/Makefile should work.  We have another
problem, though, in that the yyin symbol from xmltree_read
conflicts with the yyin/yyout symbols from octave's lexer, giving the
following error on OS X:

mkoctfile -DHAVE_OCTAVE_21 -v xmlread.o xmltree_read.o xmltree.o -o  
xmlread.oct
g++ -bundle -bundle_loader /opt/local/bin/octave-2.1.50 -o xmlread.oct  
xmlread.o xmltree_read.o xmltree.o -L/opt/local/lib/octave-2.1.50  
-loctave -lcruft -loctinterp -framework vecLib
ld: warning multiple definitions of symbol _yyin
xmltree_read.o definition of _yyin in section (__DATA,__data)
/opt/local/bin/octave-2.1.50 definition of _yyin
ld: warning multiple definitions of symbol _yyout
xmltree_read.o definition of _yyout in section (__DATA,__data)
/opt/local/bin/octave-2.1.50 definition of _yyout

Any ideas?

Paul Kienzle
pki...@us...

On Feb 12, 2004, at 10:19 PM, Dirk Eddelbuettel wrote:

> On Thu, Feb 12, 2004 at 01:53:22PM -0600, Dirk Eddelbuettel wrote:
>> On Thu, Feb 12, 2004 at 03:28:39AM -0500, Paul Kienzle wrote:
>>> Tested against octave-2.1.53 and octave-2.1.40.  Many functions will
>>> also work on earlier versions of Octave.  Use make -k to build what
>>> functions can be built and ignore the rest.
>>
>> Cf http://buildd.debian.org/build.php?pkg=octave-forge and see the  
>> build
>> failures for alpha, hppa and ia64 for the Feb 9 snapshot I uploaded  
>> earlier
>> -- all in the same xml area. hppa may have the best compiler warning  
>> in
>> http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.02.09 
>> -1&arch=hppa&stamp=1076389950&file=log&as=raw
>>
>> mkoctfile -DHAVE_OCTAVE_21 -v -c xmlread.cc -o xmlread.o
>> /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.53
>> -I/usr/include/octave-2.1.53/octave -O2 -DHAVE_OCTAVE_21 xmlread.cc -o
>> xmlread.o
>> /usr/bin/gcc -c xmltree_read.c -o xmltree_read.o
>> /usr/bin/gcc -c xmltree.c -o xmltree.o
>> mkoctfile -DHAVE_OCTAVE_21 -v xmlread.o xmltree_read.o xmltree.o -o
>> xmlread.oct
>> /usr/bin/g++ -shared -o xmlread.oct xmlread.o xmltree_read.o xmltree.o
>> /usr/bin/ld: xmltree_read.o: relocation R_PARISC_DPREL21L can not be  
>> used
>> when making a shared object; recompile with -fPIC
>> xmltree_read.o: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> make[3]: *** [xmlread.oct] Error 1
>> make[3]: Leaving directory
>> build/buildd/octave-forge-2004.02.09/main/miscellaneous'
>> make[2]: *** [miscellaneous/] Error 2
>> make[2]: Leaving directory build/buildd/octave-forge-2004.02.09/main'
>> make[1]: *** [main/] Error 2
>> make[1]: Leaving directory build/buildd/octave-forge-2004.02.09'
>> make: *** [build-stamp] Error 2
>> ********************************************************************** 
>> ********
>> Build finished at 20040210-0512
>> FAILED [dpkg-buildpackage died]
>>
>> xmlread is compiled with -fPIC, xmltree isn't. Could someone have a  
>> look at
>> the corresponding Makefile and send a patch?
>>
>> Thanks!
>
> This seems to at least not do harm on i386 where the resulting xmlread  
> still
> appears to work. Well the help comes up, and 'xmlread("/dev/null")'  
> ends
> gracefully.  We'll see what alpha, hppa and ia64 will do.
>
> --- octave-forge-2004.02.12.orig/main/miscellaneous/Makefile
> +++ octave-forge-2004.02.12/main/miscellaneous/Makefile
> @@ -23,7 +23,8 @@
>  	$(MKOCTFILE) -c listencanfork.c
>
>  xmltree.o: xmltree.c xmltree.h
> -	$(CC) -c $< -o $@
> +	$(MKOCTFILE) $(MISCDEFS) -c $<
> +#	$(CC) -c $< -o $@
>
>  ifdef FLEXML
>  xmltree_read.l: xmltree_read.act octave.dtd
> @@ -36,12 +37,15 @@
>  endif
>
>  xmltree_read.o: xmltree_read.c xmltree_read.h
> -	$(CC) -c $< -o $@
> +	$(MKOCTFILE) $(MISCDEFS) -c $<
> +#	$(CC) -c $< -o $@
>
>  xmlread.o: xmlread.cc xmltree_read.h xmltree.h
> -	$(MKOCTFILE) -c $< -o $@
> +	$(MKOCTFILE) $(MISCDEFS) -c $<
> +#	$(MKOCTFILE) -c $< -o $@
>
>  xmlread.oct: xmlread.o xmltree_read.o xmltree.o
> -	$(MKOCTFILE) $^ -o $@
> +	$(MKOCTFILE) $^
> +#	$(MKOCTFILE) $^ -o $@
>
>  clean: ; -$(RM) *.o octave-core core *.oct *~
>
>
>>
>> Dirk
>>
>> -- 
>> The relationship between the computed price and reality is as yet  
>> unknown.
>>                                              -- From the pac(8)  
>> manual page
>
> -- 
> The relationship between the computed price and reality is as yet  
> unknown.
>                                              -- From the pac(8) manual  
> page
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] Re: Three build failures on alpha,hppa,ia64 (Re: octave-forge 2004-02-12 release)

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

On Thu, Feb 12, 2004 at 01:53:22PM -0600, Dirk Eddelbuettel wrote:
> On Thu, Feb 12, 2004 at 03:28:39AM -0500, Paul Kienzle wrote:
> > Tested against octave-2.1.53 and octave-2.1.40.  Many functions will
> > also work on earlier versions of Octave.  Use make -k to build what
> > functions can be built and ignore the rest.
> 
> Cf http://buildd.debian.org/build.php?pkg=octave-forge and see the build
> failures for alpha, hppa and ia64 for the Feb 9 snapshot I uploaded earlier
> -- all in the same xml area. hppa may have the best compiler warning in
> http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.02.09-1&arch=hppa&stamp=1076389950&file=log&as=raw
> 
> mkoctfile -DHAVE_OCTAVE_21 -v -c xmlread.cc -o xmlread.o
> /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.53
> -I/usr/include/octave-2.1.53/octave -O2 -DHAVE_OCTAVE_21 xmlread.cc -o
> xmlread.o
> /usr/bin/gcc -c xmltree_read.c -o xmltree_read.o
> /usr/bin/gcc -c xmltree.c -o xmltree.o
> mkoctfile -DHAVE_OCTAVE_21 -v xmlread.o xmltree_read.o xmltree.o -o
> xmlread.oct
> /usr/bin/g++ -shared -o xmlread.oct xmlread.o xmltree_read.o xmltree.o
> /usr/bin/ld: xmltree_read.o: relocation R_PARISC_DPREL21L can not be used
> when making a shared object; recompile with -fPIC
> xmltree_read.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[3]: *** [xmlread.oct] Error 1
> make[3]: Leaving directory
> build/buildd/octave-forge-2004.02.09/main/miscellaneous'
> make[2]: *** [miscellaneous/] Error 2
> make[2]: Leaving directory build/buildd/octave-forge-2004.02.09/main'
> make[1]: *** [main/] Error 2
> make[1]: Leaving directory build/buildd/octave-forge-2004.02.09'
> make: *** [build-stamp] Error 2
> ******************************************************************************
> Build finished at 20040210-0512
> FAILED [dpkg-buildpackage died]
> 
> xmlread is compiled with -fPIC, xmltree isn't. Could someone have a look at
> the corresponding Makefile and send a patch?
> 
> Thanks!

This seems to at least not do harm on i386 where the resulting xmlread still 
appears to work. Well the help comes up, and 'xmlread("/dev/null")' ends
gracefully.  We'll see what alpha, hppa and ia64 will do.

--- octave-forge-2004.02.12.orig/main/miscellaneous/Makefile
+++ octave-forge-2004.02.12/main/miscellaneous/Makefile
@@ -23,7 +23,8 @@
 	$(MKOCTFILE) -c listencanfork.c
 
 xmltree.o: xmltree.c xmltree.h
-	$(CC) -c $< -o $@
+	$(MKOCTFILE) $(MISCDEFS) -c $<
+#	$(CC) -c $< -o $@
 
 ifdef FLEXML
 xmltree_read.l: xmltree_read.act octave.dtd
@@ -36,12 +37,15 @@
 endif
 
 xmltree_read.o: xmltree_read.c xmltree_read.h
-	$(CC) -c $< -o $@
+	$(MKOCTFILE) $(MISCDEFS) -c $<
+#	$(CC) -c $< -o $@
 
 xmlread.o: xmlread.cc xmltree_read.h xmltree.h
-	$(MKOCTFILE) -c $< -o $@
+	$(MKOCTFILE) $(MISCDEFS) -c $<
+#	$(MKOCTFILE) -c $< -o $@
 
 xmlread.oct: xmlread.o xmltree_read.o xmltree.o
-	$(MKOCTFILE) $^ -o $@
+	$(MKOCTFILE) $^ 
+#	$(MKOCTFILE) $^ -o $@
 
 clean: ; -$(RM) *.o octave-core core *.oct *~


> 
> Dirk
> 
> -- 
> The relationship between the computed price and reality is as yet unknown.  
>                                              -- From the pac(8) manual page

-- 
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[OctDev] Three build failures on alpha,hppa,ia64 (Re: octave-forge 2004-02-12 release)

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

On Thu, Feb 12, 2004 at 03:28:39AM -0500, Paul Kienzle wrote:
> Tested against octave-2.1.53 and octave-2.1.40.  Many functions will
> also work on earlier versions of Octave.  Use make -k to build what
> functions can be built and ignore the rest.

Cf http://buildd.debian.org/build.php?pkg=octave-forge and see the build
failures for alpha, hppa and ia64 for the Feb 9 snapshot I uploaded earlier
-- all in the same xml area. hppa may have the best compiler warning in
http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.02.09-1&arch=hppa&stamp=1076389950&file=log&as=raw

mkoctfile -DHAVE_OCTAVE_21 -v -c xmlread.cc -o xmlread.o
/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.53
-I/usr/include/octave-2.1.53/octave -O2 -DHAVE_OCTAVE_21 xmlread.cc -o
xmlread.o
/usr/bin/gcc -c xmltree_read.c -o xmltree_read.o
/usr/bin/gcc -c xmltree.c -o xmltree.o
mkoctfile -DHAVE_OCTAVE_21 -v xmlread.o xmltree_read.o xmltree.o -o
xmlread.oct
/usr/bin/g++ -shared -o xmlread.oct xmlread.o xmltree_read.o xmltree.o
/usr/bin/ld: xmltree_read.o: relocation R_PARISC_DPREL21L can not be used
when making a shared object; recompile with -fPIC
xmltree_read.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [xmlread.oct] Error 1
make[3]: Leaving directory
build/buildd/octave-forge-2004.02.09/main/miscellaneous'
make[2]: *** [miscellaneous/] Error 2
make[2]: Leaving directory build/buildd/octave-forge-2004.02.09/main'
make[1]: *** [main/] Error 2
make[1]: Leaving directory build/buildd/octave-forge-2004.02.09'
make: *** [build-stamp] Error 2
******************************************************************************
Build finished at 20040210-0512
FAILED [dpkg-buildpackage died]

xmlread is compiled with -fPIC, xmltree isn't. Could someone have a look at
the corresponding Makefile and send a patch?

Thanks!

Dirk

-- 
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[OctDev] octave-forge 2004-02-12 release

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

Tested against octave-2.1.53 and octave-2.1.40.  Many functions will
also work on earlier versions of Octave.  Use make -k to build what
functions can be built and ignore the rest.

*** WARNING *** if installing in a user directory, octave may crash
immediately on startup.  Either install into a system directory, or
remove the comm/PKG_ADD and sparse/PKG_ADD from the install directory
(octave-2.1.49 on RedHat 7.3 exhibits this problem).

See
<a  
href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/octave/octave- 
forge/RELEASE-NOTES?rev=HEAD&content-type=text/plain">RELEASE-NOTES</a>
for a summary  of all releases.

See
<a  
href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/octave/octave- 
forge/ChangeLog?rev=HEAD&content-type=text/plain">ChangeLog</a>
for details of every change.

2004-02-11  
===================================================================

Extends support forward to octave 2.1.53 for all oct-files.  Improved
build environment and better testing.  We still need more tests!  If
you need a function and don't see any test cases in it, add some and
send them our way.  See 'help test' for details.

Changes

   - rand/randn: generates a different random number sequence from  
before.

New functions

   - anovan: analysis of variance
   - append_save: add a variable to a save file
   - assert: now supports structure arrays and cell arrays
   - BFGSMin: alternative to bfgs minimizer
   - conv2nan: 2-D convolution which ignores missing data
   - convhull/convhulln: now allows direct control of qhull parameters
   - csape: support n=3 case --- need to verify it is correct
   - dxfwrite: output plot to DXF format (AutoCAD)
   - fail: checks if code fails with a given error message
   - galois: load/save support
   - gpick: alternative to ginput
   - imread: now supports 16-bit grayscale
   - irsa_*: irregularly sampled data analysis functions
   - map: apply a function across all elements of a cell array
   - mex: initial support for structures
   - pngread/pngwrite: direct access to libpng
   - quadl: improved adaptive quadrature routine
   - rand/randn: faster and now supports for nD arrays
   - sort: fast sort based on python's timsort
   - sprandn: random sparse matrix filled with normally distributed  
values
   - str2double: convert string to double
   - struct: now creates structure arrays
   - toggle_grace_use: use grace plotting package rather than gnuplot
   - xmlwrite: save data to xml format

Plus the usual bug fixes and documentation updates.

Paul Kienzle
pki...@us...

[OctDev] mittag-leffler function

[Rafael <raf...@ic...>]

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

I have implemented the mittag-leffler function (using the Gorenflo, Loutchko
and Luchko algorithm). It is used in fractional calculus. Is there any
intrest in including it in octave-forge?

The function and some tests are attached.

Rafael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAKrBHLlrfGJ8JUHwRAiD+AKCemzVXE5fsAfdEqpgr1IrkYR+zAACfQ7SR
rZVnGnYDYt1e6OuPX9eeFys=
=yLde
-----END PGP SIGNATURE-----

[OctDev] mittag-leffler function

[Rafael <raf...@ic...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have implemented the mittag-leffler function (using the Gorenflo, Loutchk=
o=20
and Luchko algorithm). It is used in fractional calculus. Is there any=20
intrest in including it in octave-forge?

The function and some tests are attached.

Rafael
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAKCX5LlrfGJ8JUHwRAhW7AJ9Rt43ee0L+2XxM1annVnh31ttytACg0FhW
wgqkgff93fljQx4LdjIzXoI=3D
=3DRcDR
=2D----END PGP SIGNATURE-----

[OctDev] octave imaging

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

Hi All

I would like to know what image/matrix format is preferred by Octave.

All the imaging functions seem to be written for images in
[0, 1].  This could be rather confusing, for example:

octave:128> I = imread('lena256.jpg'); % read image
octave:129> colormap(gray(256));       % set colormap to 256 gray scales
octave:130> imshow(I)                  % display lena
octave:131> histeq(I)                  % oops! expected I in [0,1]
error: `n' undefined near line 30 column 16

So imshow does not handle images in [0,1] (it handles only indexed
   images), but the other functions expect images in [0,1]:

octave:140> [p,m] = gray2ind(I/255, 256)

works correctly, while

octave:140> [p,m] = gray2ind(I, 256)

doesn't.

It is, for example, very counterintuitive that the following code
doesn't work:

imshow(imread('image.jpg'))

MATLAB handles the different images with 'classes', but I do not think
Octave has that functionality.

Thanks in advance.

Regards
Stéfan van der Walt

[OctDev] Re: Changes for the geometry package

[Brad B. <br...@sh...>]

At 10:57 AM 2/3/2004, Pedro Tarrafeta wrote:
<clip>

>When I set Qt in the options qh_new_qhull won't give a triangulated hull. As 
>far as I understand your code, qh_triangulate() is called before producing 
>the output, so I should just make a call to qh_triangulate(), is this right?.

Yes, you can call qh_triangulate().    It may be better to fix the underlying problem and create a function (see below) called qh_prepare_output().  

qh_produce_output() includes several housekeeping calls before calling the print functions.   In the next version of qhull, these calls will move to a new function called qh_prepare_output().   Qhull library users should call qh_prepare_output() if qh_new_qhull() succeeds.  The variables qh VORONOI, etc. are set from the option string.  

void qh_prepare_output(void) { 
  if (qh VORONOI) {
    qh_clearcenters (qh_ASvoronoi);
    qh_vertexneighbors();
  }
  if (qh TRIangulate) {
    qh_triangulate(); 
    if (qh VERIFYoutput && !qh CHECKfrequently) 
      qh_checkpolygon (qh facet_list);
  }
  qh_findgood_all (qh facet_list); 
  if (qh GETarea)
    qh_getarea(qh facet_list);
  if (qh KEEParea || qh KEEPmerge || qh KEEPminArea < REALmax/2)
    qh_markkeep (qh facet_list);
}

                                                --Brad

[OctDev] Re: Changes for the geometry package

[Pedro T. <pt...@te...>]

Brad,

Thank you for your comments.


> MATLAB will switch to Qhull 2003.1 for R14.

I've used these libraries too.

> ---------------------------
>   sprintf(flags,"qhull %s",options); //Notice that output options will not
> work.
>
> Missing check for buffer overflow.   flags is char[255],
>
> ----------------------

Right...

>   //  Qt won't work since it
>   // premerges the facets and only afterwards it triangulates.
>
> I noticed some inconsistent usage for Qt/QJ/Q0.  convexn currently uses Q0
> while delaunayn() and voronoin() use merged facets.
>
> I think you should use 'Qt' for convexn() and delaunayn().   If the data
> contains singularities, Qhull 'Q0' may produce garbage results.  For
> example, try rbox 1000 W1e-12 | qhull Q0
>         <clip>
>         qhull precision error: f894 is concave to f1029, since p895 (v153)
> is 5.107e015 above qhull precision error: f1060 is concave to f1115, since
> p826 (v150) is 3.664e-015 above
>
> QJ guarantees a simplicial result but it perturbs the input.   Qt is
> approximately 1000 times more accurate.  You should be able to use it.  The
> end result is a simplicial data structure just like QJ or Q0, but with some
> facets marked "tricoplanar".

When I set Qt in the options qh_new_qhull won't give a triangulated hull. As 
far as I understand your code, qh_triangulate() is called before producing 
the output, so I should just make a call to qh_triangulate(), is this right?.

...
> If 'Qt' is used for voronoin() then non-simplicial Delaunay regions
> generate multiple copies of the corresponding Voronoi vertex:  Compare the
> following Voronoi diagram of the unit cube centered at the origin.
........

In the actual implementation neither delaunayn() nor voronoin() use Qt. I 
think this option could be easily added in delaunayn.m file, once I get Qt 
working. I'm thinking that since the 'triangulate' option is SO important it 
could be passed as a third argument to octave's qhull, especially since Qt 
doesn't affect the qh_new_qhull computations and code must be writtenY to 
control it...

> --------------------------------
>     // Volume calculation. Copy-paste from geom2.c. qh_getarea didn't give
> proper results
>
> Volume computation increases run time by about 10%.  It is not needed for
> most applications.   Should it be optional?

Yes it should. I just added it because Matlab returns it in convhulln().

> I curious why you copy pasted the code.  The original code should work
> fine.  If you copy-paste, then you may miss out on future improvements to
> the original code.

You catched me here... Just because I'm not a very efficient C programmer, I 
took this "assignment" as a practice, and I couldn't make qh_getarea() do 
what I wanted it to. After three hours going nuts, following crazy pointers 
all over the code, I found a "solution". ;)

I'll look into your suggestions. Thanks again,

Pedro

[OctDev] Re: Changes for the geometry package

[Brad B. <br...@sh...>]

Raphael and Pedro,

Thanks Pedro for your reworking of the Qhull interface for Octave.  I noticed a few items.  I'm not an Octave user so I didn't try out the .m files.  Nor am I a MATLAB user.   I agree with you that compatibility between MATLAB and Octave is a good thing.  

MATLAB will switch to Qhull 2003.1 for R14.

                                                --Brad

--------------------------
Raphael, Pedro's compatibility edit shouldn't effect you.  This line was 
removed for 2002.1 and replaced with a macro qh_VERSION.   In 2003.1, qh_version is defined in global.c.
        //qh_version changed in qhull2003. Line removed for compatibility
        //char qh_version[] = "qhull.oct 2004-01-24";

---------------------------
  sprintf(flags,"qhull %s",options); //Notice that output options will not work. 

Missing check for buffer overflow.   flags is char[255],

----------------------
  //  Qt won't work since it
  // premerges the facets and only afterwards it triangulates.

I noticed some inconsistent usage for Qt/QJ/Q0.  convexn currently uses Q0 while delaunayn() and voronoin() use merged facets.
  
I think you should use 'Qt' for convexn() and delaunayn().   If the data contains singularities, Qhull 'Q0' may produce garbage results.  For example, try
        rbox 1000 W1e-12 | qhull Q0
        <clip>
        qhull precision error: f894 is concave to f1029, since p895 (v153) is 5.107e015 above
        qhull precision error: f1060 is concave to f1115, since p826 (v150) is 3.664e-015 above

QJ guarantees a simplicial result but it perturbs the input.   Qt is approximately 1000 times more accurate.  You should be able to use it.  The end result is a simplicial data structure just like QJ or Q0, but with some facets marked "tricoplanar".  

I understand that MATLAB R14 will use 'Qt' for convexn() and delaunayn() and merged facets for voronoin().

If 'Qt' is used for voronoin() then non-simplicial Delaunay regions generate multiple copies of the corresponding Voronoi vertex:  Compare the following Voronoi diagram of the unit cube centered at the origin.  

> rbox c | qhull v p Qz
3
1
     0      0      0

> rbox c | qhull v p Qz QJ
3
12
2.881346095995534e-011 3.615999963933415e-011 0.7499999999619742
-2.783323571620144e-011 0.7500000000345136 6.739575564296274e-011
-4.608868842126412e-011 -3.874200960041208e-011 0.7499999999619742
2.590405667746154e-011 -0.7499999999641777 4.712574774856648e-011
2.860267578341791e-011 0.7500000000345134 1.095989965449462e-011
1.435529473070574e-011 1.742878064092679e-011 -0.749999999962591
0.7499999998980858 1.958799789036902e-011 6.939693264484959e-011
0.7499999998980858 -8.294376296902328e-011 -3.313482821454272e-011
-4.140066067748194e-011 -3.832711925610965e-011 -0.749999999962591
-3.962064010210042e-011 -0.7499999999641775 -1.839872698639056e-011
-0.7500000000187241 2.902783569069811e-011 -4.421357724382347e-011
-0.7500000000187242 -6.90043022721909e-011 5.381861623021678e-011

> rbox c | qhull v p Qz Qt
3
6
     0      0      0
     0      0      0
     0      0      0
     0      0      0
     0      0      0
     0      0      0

--------------------------------
    // Volume calculation. Copy-paste from geom2.c. qh_getarea didn't give proper results

Volume computation increases run time by about 10%.  It is not needed for most applications.   Should it be optional?    

Volume computation is not implemented for Voronoi diagrams.  For option 'FA', Qhull returns the corresponding Delaunay areas.  If used, it needs to be documented.

I curious why you copy pasted the code.  The original code should work fine.  If you copy-paste, then you may miss out on future improvements to the original code.

------------
EOF

At 10:02 AM 2/2/2004, Pedro Tarrafeta wrote:
>Hi,
>
>I've been working lately on the geometry package. I have written a DLD
>function named qhull that is working properly and that can be used as the
>engine for delaunay(n), voronoi(n) and convhull(n) functions. I have also
>written delaunayn.m voronoin.m and convhulln.m so that they use this new
>qhull function.
>
>This new functions are supposed to work like their Matlab counterparts. Now:
>- [ch, v] convhulln(x), returns ch triangulated (thru Q0 option, not Qt) and
>returns the hulls volume on v, just like Matlab.
>- [V, C] voronoin(x) returns the Voronoi vertices including a first vertex at
>infinity, and the vector array C in the same manner as Matlab (if a reference
>to point 1 is found this means the voronoi cell is unbounded).
>
>qhull function returns:
>
>[H, a, vol, N, O, R, V, C, inf] = qhull (p [,opt])
>
>H : an index vector to the points of the enclosing convex hull.
>a : total area of hull
>vol: total volume of hull
>N : normal vector for each facet
>O : offsets of the hyperplanes
>R : a list with the neighbors to each facet.
>V : voronoi vertex. Only usefull if 'd' or 'v' option specifiedj. Otherwise
> it should return the baricentrum of each facet...
>C : voronoi cells. List related to V
>inf: Vector with ones if corresponding voronoi cell is unbounded, 0 otherwise
>
>I think this gives a better control over the geometry package than what we
>have right now. Also it is more Matlab compatible.
>
>I attach the corresponding files.
>
>Regards,
>Pedro
>
>
>
>
>

[OctDev] Changes for the geometry package

[Pedro T. <pt...@te...>]

Hi,

I've been working lately on the geometry package. I have written a DLD
function named qhull that is working properly and that can be used as the
engine for delaunay(n), voronoi(n) and convhull(n) functions. I have also
written delaunayn.m voronoin.m and convhulln.m so that they use this new
qhull function.

This new functions are supposed to work like their Matlab counterparts. Now:
- [ch, v] convhulln(x), returns ch triangulated (thru Q0 option, not Qt) and
returns the hulls volume on v, just like Matlab.
- [V, C] voronoin(x) returns the Voronoi vertices including a first vertex at
infinity, and the vector array C in the same manner as Matlab (if a reference
to point 1 is found this means the voronoi cell is unbounded).

qhull function returns:

[H, a, vol, N, O, R, V, C, inf] = qhull (p [,opt])

H : an index vector to the points of the enclosing convex hull.
a : total area of hull
vol: total volume of hull
N : normal vector for each facet
O : offsets of the hyperplanes
R : a list with the neighbors to each facet.
V : voronoi vertex. Only usefull if 'd' or 'v' option specifiedj. Otherwise
 it should return the baricentrum of each facet...
C : voronoi cells. List related to V
inf: Vector with ones if corresponding voronoi cell is unbounded, 0 otherwise

I think this gives a better control over the geometry package than what we
have right now. Also it is more Matlab compatible.

I attach the corresponding files.

Regards,
Pedro

[OctDev] RELEASE-NOTES

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

Please post any changes to octave-forge/RELEASE-NOTES that
I may have missed.  After I hear back about Debian builds I will
make a new release.

I've compiled successfully on 2.1.53 and 2.1.40.  Most of the
tests ran successfully on both.   This may just reflect the lack
of adequate testing ;-)

A number of tests fail on both because they test for features
that are not yet implemented.  Feel free to post patches, and
new tests.

Let me know what problems are outstanding.  I know of
at least two:  tk_octave no longer compiles and optim/lp.cc
doesn't work with lower bounds.   Also I've heard reports
of qhull based routines not building.  And I would rather
not have two BFGS routines in optim, certainly not without
an explanation of why one should be used and not the
other.  Anyone care to unify the two?

Paul Kienzle
pki...@us...

Re: [OctDev] Build problems for octave-forge with 2.1.53

[Pedro T. <pt...@te...>]

Another build problem...

geometry package with qhull 2003.1.

They changed something with qh_version. Since this is not needed it is 
possible to just comment out the corresponding lines in __voronoi__.cc, 
delaunayn.cc and convhulln.cc. This way they build against 2002.1 and 2003.1

Regards,
Pedro

Re: [OctDev] Build problems for octave-forge with 2.1.53

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

On Wed, Jan 28, 2004 at 02:07:01AM -0500, Paul Kienzle wrote:
> The mex problem should be fixed now in CVS.
> My fix for listen compiles, but I haven't yet tested it or uploaded it.
> 
> There are still numerous tests failing, but that's because I'm testing
> things that haven't been implemented yet.

Thanks so much. I'll try to build a package from it this eve.

Dirk

> 
> Paul Kienzle
> pki...@us...
> 
> On Jan 26, 2004, at 8:16 AM, David Bateman wrote:
> 
> >Here are the list of build problems I have with octave-forge CVS at the
> >moment.
> >
> >extra/mex/mex.cc
> >
> >main/miscellaneous/listen.cc
> 
> 

-- 
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page