This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(10) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
(4) |
Mar
|
Apr
(3) |
May
(13) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(8) |
Dec
|
2002 |
Jan
|
Feb
|
Mar
(19) |
Apr
(8) |
May
(8) |
Jun
(8) |
Jul
(4) |
Aug
(8) |
Sep
(19) |
Oct
(13) |
Nov
(37) |
Dec
(2) |
2003 |
Jan
(7) |
Feb
(23) |
Mar
(16) |
Apr
(4) |
May
(18) |
Jun
(9) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(39) |
Dec
(57) |
2004 |
Jan
(21) |
Feb
(15) |
Mar
(17) |
Apr
(9) |
May
(17) |
Jun
(65) |
Jul
(33) |
Aug
(48) |
Sep
(93) |
Oct
(35) |
Nov
(18) |
Dec
(4) |
2005 |
Jan
(20) |
Feb
(59) |
Mar
(17) |
Apr
(59) |
May
(77) |
Jun
(32) |
Jul
(34) |
Aug
(8) |
Sep
(34) |
Oct
(26) |
Nov
(65) |
Dec
(66) |
2006 |
Jan
(45) |
Feb
(37) |
Mar
(50) |
Apr
(32) |
May
(48) |
Jun
(42) |
Jul
(12) |
Aug
(53) |
Sep
(51) |
Oct
(79) |
Nov
(46) |
Dec
(25) |
2007 |
Jan
(120) |
Feb
(78) |
Mar
(45) |
Apr
(91) |
May
(155) |
Jun
(66) |
Jul
(96) |
Aug
(110) |
Sep
(145) |
Oct
(189) |
Nov
(68) |
Dec
(160) |
2008 |
Jan
(163) |
Feb
(212) |
Mar
(209) |
Apr
(157) |
May
(216) |
Jun
(120) |
Jul
(80) |
Aug
(83) |
Sep
(98) |
Oct
(120) |
Nov
(80) |
Dec
(129) |
2009 |
Jan
(45) |
Feb
(80) |
Mar
(174) |
Apr
(142) |
May
(133) |
Jun
(191) |
Jul
(183) |
Aug
(138) |
Sep
(77) |
Oct
(141) |
Nov
(209) |
Dec
(131) |
2010 |
Jan
(85) |
Feb
(213) |
Mar
(245) |
Apr
(222) |
May
(168) |
Jun
(82) |
Jul
(50) |
Aug
(144) |
Sep
(92) |
Oct
(80) |
Nov
(64) |
Dec
(78) |
2011 |
Jan
(58) |
Feb
(98) |
Mar
(112) |
Apr
(98) |
May
(64) |
Jun
(150) |
Jul
(126) |
Aug
(59) |
Sep
(271) |
Oct
(154) |
Nov
(321) |
Dec
(183) |
2012 |
Jan
(146) |
Feb
(217) |
Mar
(426) |
Apr
(208) |
May
(206) |
Jun
(230) |
Jul
(158) |
Aug
(170) |
Sep
(237) |
Oct
(260) |
Nov
(178) |
Dec
|
From: John W. E. <jw...@be...> - 2002-10-24 15:06:54
|
On 23-Oct-2002, Dirk Eddelbuettel <ed...@de...> wrote: | Thanks -- I am currently uploading 2.1.37, incl the small mkopt.pl patch, to | Debian. | | But even with the patch, building octave-forge fails: | | /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.37 | -I/usr/include/octave-2.1.37/octave -I/usr/include -mieee-fp | -fno-implicit-templates -O2 -DHAVE_OCTAVE_21 getfield.cc -o getfield.o | getfield.cc: In function class octave_value_list Fgetfield(const | octave_value_list &, int)': | getfield.cc:40: no matching function for call to | octave_value::do_struct_elt_index_op (string &, bool)' | make[3]: *** [getfield.oct] Error 1 | make[3]: Leaving directory | /home/edd/src/debian/octave-forge-2002.05.09/main/struct' | make[2]: *** [struct/] Error 2 | make[2]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09/main' | make[1]: *** [main/] Error 2 | make[1]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09' | make: *** [build-stamp] Error 2 | | This is using the 2002.05.09 release of octave-forge. Is there something I | need from CVS to deal with this? There have been a lot of changes to the parts of Octave that handle indexing and indexed assignment. I'd like to include this functionality in Octave, but it should probably wait until structure arrays can be multidimensional. For now, I think the following patch should make getfield.cc compile and prevent setfield from creating invalid structures. jwe --- getfield.cc~ 2002-10-24 09:48:30.000000000 -0500 +++ getfield.cc 2002-10-24 09:53:29.000000000 -0500 @@ -36,12 +36,14 @@ for (int i = 1; i<nargin; i++) { if (args(i).is_string ()) { - std::string s = args(i).string_value (); - octave_value tmp = args(0).do_struct_elt_index_op (s, true); + octave_value tmp = args(0).subsref (".", args(i)); if (tmp.is_defined ()) retval(i-1) = tmp; - else error ("structure has no member `%s'", s.c_str ()); + else { + std::string s = args(i).string_value (); + error ("structure has no member `%s'", s.c_str ()); + } } else error ("argument number %i is not a string",i+1); --- setfield.cc~ 2002-10-24 09:51:26.000000000 -0500 +++ setfield.cc 2002-10-24 10:02:29.000000000 -0500 @@ -57,7 +57,7 @@ if (args(i).is_string ()) { std::string s = args(i).string_value (); - tmp [s] = args(i+1); + tmp.assign (s, args(i+1)); } else error ("argument number %i is not a string",i+1); } |
From: Paul K. <pki...@rr...> - 2002-10-24 15:00:19
|
On Wed, Oct 23, 2002 at 10:49:04PM +0100, Etienne Grossmann wrote: > > Hello, > > I have just installed 2.1.37, but compilation of octave-forge ends > with : > > ====================================================================== > mkoctfile -DHAVE_OCTAVE_21 -v fsolve.cc > g++ -c -fPIC -I/usr/local/include/octave-2.1.37 -I/usr/local/include/octave-2.1.37/octave -I/usr/local/include -mieee-fp -fno-implicit-templates -g -O2 -Wall -DHAVE_OCTAVE_21 fsolve.cc -o fsolve.o > fsolve.cc: In function `class octave_value_list Ffsolve(const octave_value_list &, int)': > fsolve.cc:211: no matching function for call to `NLEqn::set_options (NLEqn_options &)' > make[1]: *** [fsolve.oct] Error 1 > make[1]: Leaving directory `/home/cdisk/etienne/prog/octave/octave-forge/octave-forge/FIXES' > make: *** [FIXES/] Error 2 > ====================================================================== > > I would like to check whether the backward compatibility problem > with is_XXX() still exists, and if it does, transform all relevant > sourceforge files. > > Since this is a big step, I guess the procedure is transform, test > and send a patch for people to check, and then commit? I say commit directly. If anything really serious goes wrong we can always back out. Are we abandoning support for 2.1.36? - Paul |
From: Dirk E. <ed...@de...> - 2002-10-24 11:23:11
|
I think I sent that to a bad list address last night, having omitted the "lists." part. Any pointers or help would be appreciated. Dirk ----- Forwarded message from Dirk Eddelbuettel <edd> ----- From: Dirk Eddelbuettel <edd> To: "John W. Eaton" <jw...@be...> Cc: octave-maintainers mailing list <oct...@be...>, oct...@so... Subject: Re: Octave 2.1.37 available for ftp Thanks -- I am currently uploading 2.1.37, incl the small mkopt.pl patch, to Debian. But even with the patch, building octave-forge fails: /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.37 -I/usr/include/octave-2.1.37/octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -DHAVE_OCTAVE_21 getfield.cc -o getfield.o getfield.cc: In function class octave_value_list Fgetfield(const octave_value_list &, int)': getfield.cc:40: no matching function for call to octave_value::do_struct_elt_index_op (string &, bool)' make[3]: *** [getfield.oct] Error 1 make[3]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09/main/struct' make[2]: *** [struct/] Error 2 make[2]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09/main' make[1]: *** [main/] Error 2 make[1]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09' make: *** [build-stamp] Error 2 This is using the 2002.05.09 release of octave-forge. Is there something I need from CVS to deal with this? Thanks, Dirk -- Good judgement comes from experience; experience comes from bad judgement. -- Fred Brooks ----- End forwarded message ----- -- Good judgement comes from experience; experience comes from bad judgement. -- Fred Brooks |
From: Dirk E. <ed...@de...> - 2002-10-24 03:44:38
|
Thanks -- I am currently uploading 2.1.37, incl the small mkopt.pl patch, to Debian. But even with the patch, building octave-forge fails: /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.37 -I/usr/include/octave-2.1.37/octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -DHAVE_OCTAVE_21 getfield.cc -o getfield.o getfield.cc: In function class octave_value_list Fgetfield(const octave_value_list &, int)': getfield.cc:40: no matching function for call to octave_value::do_struct_elt_index_op (string &, bool)' make[3]: *** [getfield.oct] Error 1 make[3]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09/main/struct' make[2]: *** [struct/] Error 2 make[2]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09/main' make[1]: *** [main/] Error 2 make[1]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09' make: *** [build-stamp] Error 2 This is using the 2002.05.09 release of octave-forge. Is there something I need from CVS to deal with this? Thanks, Dirk -- Good judgement comes from experience; experience comes from bad judgement. -- Fred Brooks |
From: John W. E. <jw...@be...> - 2002-10-23 22:04:05
|
On 23-Oct-2002, Etienne Grossmann <et...@is...> wrote: | I have just installed 2.1.37, but compilation of octave-forge ends | with : | | ====================================================================== | mkoctfile -DHAVE_OCTAVE_21 -v fsolve.cc | g++ -c -fPIC -I/usr/local/include/octave-2.1.37 -I/usr/local/include/octave-2.1.37/octave -I/usr/local/include -mieee-fp -fno-implicit-templates -g -O2 -Wall -DHAVE_OCTAVE_21 fsolve.cc -o fsolve.o | fsolve.cc: In function `class octave_value_list Ffsolve(const octave_value_list &, int)': | fsolve.cc:211: no matching function for call to `NLEqn::set_options (NLEqn_options &)' | make[1]: *** [fsolve.oct] Error 1 | make[1]: Leaving directory `/home/cdisk/etienne/prog/octave/octave-forge/octave-forge/FIXES' | make: *** [FIXES/] Error 2 | ====================================================================== Change "set_options" to "copy" or try the follwoing patch for Octave. Thanks, jwe 2002-10-23 John W. Eaton <jw...@be...> * mk-opts.pl (emit_opt_class_header): Make set_options another name for copy. Index: mk-opts.pl =================================================================== RCS file: /usr/local/cvsroot/octave/mk-opts.pl,v retrieving revision 1.8 diff -u -r1.8 mk-opts.pl --- mk-opts.pl 17 Aug 2002 02:18:18 -0000 1.8 +++ mk-opts.pl 23 Oct 2002 22:01:57 -0000 @@ -406,6 +406,11 @@ print " reset = opt.reset; }\n"; + ## For backward compatibility and because set_options is probably + ## a better name in some contexts: + + print "\n void set_options (const ${class_name}& opt) { copy (opt); }\n"; + print "\n void set_default_options (void) { init (); }\n"; for ($i = 0; $i < $opt_num; $i++) |
From: Etienne G. <et...@is...> - 2002-10-23 21:39:56
|
Hello, I have just installed 2.1.37, but compilation of octave-forge ends with : ====================================================================== mkoctfile -DHAVE_OCTAVE_21 -v fsolve.cc g++ -c -fPIC -I/usr/local/include/octave-2.1.37 -I/usr/local/include/octave-2.1.37/octave -I/usr/local/include -mieee-fp -fno-implicit-templates -g -O2 -Wall -DHAVE_OCTAVE_21 fsolve.cc -o fsolve.o fsolve.cc: In function `class octave_value_list Ffsolve(const octave_value_list &, int)': fsolve.cc:211: no matching function for call to `NLEqn::set_options (NLEqn_options &)' make[1]: *** [fsolve.oct] Error 1 make[1]: Leaving directory `/home/cdisk/etienne/prog/octave/octave-forge/octave-forge/FIXES' make: *** [FIXES/] Error 2 ====================================================================== I would like to check whether the backward compatibility problem with is_XXX() still exists, and if it does, transform all relevant sourceforge files. Since this is a big step, I guess the procedure is transform, test and send a patch for people to check, and then commit? Cheers, Etienne On Wed, Oct 23, 2002 at 02:30:50PM -0500, John W. Eaton wrote: # Octave 2.1.37 is now available for ftp from ftp.octave.org in the # directory /pub/octave/bleeding-edge: # # -rw-r--r-- 1 ftpadm ftp 4858297 Oct 23 13:29 octave-2.1.37.tar.gz # -rw-r--r-- 1 ftpadm ftp 3802708 Oct 23 13:29 octave-2.1.37.tar.bz2 # # There are no diffs this time because they are quite large. # # If your favorite bug is still not fixed, please let me know about it. # # Thanks, # # jwe # # # -- Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne |
From: Jeff O. <jj...@cs...> - 2002-10-23 16:40:23
|
Oops! I'm sorry I forgot to include the function "MakeShears" in my imrotate broadcast. It is needed by imrotate. Thanks, Paul, for your feedback. Jeff |
From: Jeff O. <jj...@cs...> - 2002-10-22 23:26:54
|
I have implemented some image processing routines for graylevel images. There is no RGB-smart wrapper yet... just routines that operate on float matrices. They are all .m scripts, so they are not optimized. They also make heavy use of the fft routines. imtranslate uses the Fourier shift theorem to apply a translation using Fourier resampling. imshear also used the Fourier shift theorem. imrotate is am implementation of the shearing method of Paeth to apply rotations using Fourier resampling. This routine uses imtranslate, imshear, and rot90. Feedback? Jeff |
From: Paul K. <pki...@ja...> - 2002-09-29 01:26:06
|
On Sat, Sep 28, 2002 at 02:05:38PM -0500, Matthew W. Roberts wrote: > I was checking the home page and found that one of our links is bad: > > Da Coda Al Fine: Pushing Octave's Limits > http://www.hammersmith-consulting.com/octave/coda/coda.html > > Either they've been hacked, or have started a completely new line of > business. I'm taking the link down. Anyone know a good link? He stopped his consulting business. > > Also, it seems there was talk about putting the web page into the > CVS tree. Was that ever done? If not, I can do it -- where would > be the best place to put it? IIRC we are permitted to put up his documents. Put them in the doc directory. Make a subdirectory if appropriate. Documentation for each toolbox should be in the toolbox directory itself, reserving the doc directory for documents about octave generally or the octave-forge project as a whole. Of course, doing this means writing documentation for each toolbox . . . > > One more question -- I thought I had seen a SourceForge project for > an octave GUI. Anyone else heard of such a thing? There is GOctave which is a GTK front end. It hasn't been touched in over a year though. I've looked at it but can't say that I buy into it. Since I want to be able to write GUI numerical applications, the GUI support which we can use with octave should be powerful enough that the GUI interface is just an example script. Since reinventing tcl/tk inside octave seems silly, I propose instead a hybrid solution, with tcl providing the GUI and octave the numerics. I hope to be able to release what I've been working with sometime in the next couple of weeks, but it will be probably be several months before I can "put up or shut up" with an octave console written in tcl. - Paul |
From: Matthew W. R. <rob...@uw...> - 2002-09-28 19:05:38
|
I was checking the home page and found that one of our links is bad: Da Coda Al Fine: Pushing Octave's Limits http://www.hammersmith-consulting.com/octave/coda/coda.html Either they've been hacked, or have started a completely new line of business. I'm taking the link down. Anyone know a good link? Also, it seems there was talk about putting the web page into the CVS tree. Was that ever done? If not, I can do it -- where would be the best place to put it? One more question -- I thought I had seen a SourceForge project for an octave GUI. Anyone else heard of such a thing? Thanks, Matt |
From: Etienne G. <et...@is...> - 2002-09-20 16:37:08
|
Hello, On Fri, Sep 20, 2002 at 11:51:00AM -0400, Paul Kienzle wrote: # On Fri, Sep 20, 2002 at 04:43:53PM +0100, Etienne Grossmann wrote: # > # > Hi all # > # > On Thu, Sep 19, 2002 at 11:37:56PM -0400, Paul Kienzle wrote: # > # Hi all, # > # # > [snip] # > # # > # Off the top of my head, struct/*.cc and FIXES/fsolve.cc are broken. A more # > ^^ # > In 2.1.37, you mean? # # Perhaps. I've built from CVS so it's not clear what version I'm working with. Iirc, CVS says 2.1.37. When I used it, it broke more things than I was willing to fix (I needed a working octave to do some work), so I put 2.1.36 back. [snip] # # Okay, so 2.1.37 is not a show stopper for this release, but 2.1.36 issues # are. No reason not to try supporting 2.1.37 if like me you are building My hope is that 2.1.37 will break less things than CVS. I prefer focus on debugging and smoothing corners in octave-forge+octave-2.1.36 first; also because I cannot spend too much time on octave-forge. Sorry for not being of more help. Etienne PS : However, I can take care of changing all the is_XXX into isXXX. # from CVS since it will have to be done eventually. # # - Paul # # -- Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne |
From: Paul K. <pki...@ja...> - 2002-09-20 15:51:05
|
On Fri, Sep 20, 2002 at 04:43:53PM +0100, Etienne Grossmann wrote: > > Hi all > > On Thu, Sep 19, 2002 at 11:37:56PM -0400, Paul Kienzle wrote: > # Hi all, > # > [snip] > # > # Off the top of my head, struct/*.cc and FIXES/fsolve.cc are broken. A more > ^^ > In 2.1.37, you mean? Perhaps. I've built from CVS so it's not clear what version I'm working with. > > # > # Unfortunately m-files will also have to change: > # * replace ... with varargin/varargout > # * replace all_va_args with varargin{:} > # * for [v,k]=struct ... end now sets v to a list rather than a value > # * anything else? > # > # We could use version tests in our code. > > ^^ > Can that do 'function foo (x,...)' and 'function foo (x,varargin)' Good point. Preprocessor it is. [snip] > # Anything else? > > What about supporting 2.1.36, and the day 2.1.37 comes out, we fix > things (duration : a few weeks) and release a new octave-forge when > it's done. No worries until 2.1.37, none one month after it comes > either. Or am I over-optimistic? Okay, so 2.1.37 is not a show stopper for this release, but 2.1.36 issues are. No reason not to try supporting 2.1.37 if like me you are building from CVS since it will have to be done eventually. - Paul |
From: Etienne G. <et...@is...> - 2002-09-20 15:34:59
|
Hi all On Thu, Sep 19, 2002 at 11:37:56PM -0400, Paul Kienzle wrote: # Hi all, # [snip] # # Off the top of my head, struct/*.cc and FIXES/fsolve.cc are broken. A more ^^ In 2.1.37, you mean? # difficult problem is that lo-sstream.h is missing from the octave installation # so a lot more things look broken than really are. I suppose we could # keep our own copy somewhere (e.g., in FIXES) and use -I$(TOPDIR)/FIXES if # octave version is 2.1.36. Or we could just document the problem. # # Unfortunately m-files will also have to change: # * replace ... with varargin/varargout # * replace all_va_args with varargin{:} # * for [v,k]=struct ... end now sets v to a list rather than a value # * anything else? # # We could use version tests in our code. ^^ Can that do 'function foo (x,...)' and 'function foo (x,varargin)' # We could use a preprocessor and set up make to convert file.m.in to file.m. # We could have file.m-2.1.35 for example for versions up to and including # 2.1.35 and file.m for later versions. # # I'm in favour of using a preprocessor because I'm not very good at fixing I prefer the preprocessor option too. [snip] # Anything else? What about supporting 2.1.36, and the day 2.1.37 comes out, we fix things (duration : a few weeks) and release a new octave-forge when it's done. No worries until 2.1.37, none one month after it comes either. Or am I over-optimistic? Cheers, Etienne # Paul Kienzle # pki...@us... |
From: Paul K. <pki...@ja...> - 2002-09-20 13:24:54
|
On Fri, Sep 20, 2002 at 02:01:23PM +0200, Quentin Spencer wrote: > Hello All, > > I have written a function that approximates the functionality of the > Matlab waitbar function, which shows a progress bar for lengthy > calculations. I would like to submit it for inclusion in octave-forge, > but first I have a couple of questions. First is licensing--is there a > preferred or required license to use? Scripts must be freely redistributable with modifications. Either GPL, BSD or public domain is fine. For oct-files, the portion which interfaces with octave must be GPL (because the octave support routines are GPL) and the rest must be compatible with the GPL (because they are called by a GPL program). > > My second question has to do with the function itself. It is written in > C, to make it as fast and unobtrusive (CPU-wise) as possible, and has > similar syntax to the Matlab version, but with some differences because > it is text, rather than graphics based. Originally I used a row of ASCII > "#" characters across the terminal (which will look familiar to Linux > users who have used the rpm -ivh command), however I have since modified > the function to use reverse-video spaces using color-changing commands > such as "\033[7m" in the printf command. I like the look of it better, > but this raises the question of whether it will work in all > environments. If this is to be made available to a wide audience, it > needs to work in all possible environments. Are these commands > universally recognized by all terminal programs in use today? Is there a > better way to implement this that uses libraries already linked to by > Octave? Is there a way to detect whether smart terminals are available > at compile time? You might find something in the curses library (man ncurses on my box). You are going to need some configuration information in the form of a configure.add and Makeconf.add. You can model them after the ones in image for detecting the jpeg library. Check for both curses and ncurses, and if neither exist fall back to '#'. Note that octave already checks for these because readline needs them, but readline can also fall back to termio or termios which are no good to you. > > regards, > Quentin Spencer > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev |
From: Quentin S. <qsp...@ie...> - 2002-09-20 12:01:27
|
Hello All, I have written a function that approximates the functionality of the Matlab waitbar function, which shows a progress bar for lengthy calculations. I would like to submit it for inclusion in octave-forge, but first I have a couple of questions. First is licensing--is there a preferred or required license to use? My second question has to do with the function itself. It is written in C, to make it as fast and unobtrusive (CPU-wise) as possible, and has similar syntax to the Matlab version, but with some differences because it is text, rather than graphics based. Originally I used a row of ASCII "#" characters across the terminal (which will look familiar to Linux users who have used the rpm -ivh command), however I have since modified the function to use reverse-video spaces using color-changing commands such as "\033[7m" in the printf command. I like the look of it better, but this raises the question of whether it will work in all environments. If this is to be made available to a wide audience, it needs to work in all possible environments. Are these commands universally recognized by all terminal programs in use today? Is there a better way to implement this that uses libraries already linked to by Octave? Is there a way to detect whether smart terminals are available at compile time? regards, Quentin Spencer |
From: Rafael L. <lab...@mp...> - 2002-09-20 10:14:22
|
I do not now if there is already something similar to this in octave-forge, but the script attached below might be a good contribution. Sometimes, I need to now which files have been loaded by a given Octave script, like in cases I need to send teh script to someone else and it calls some functions not available to the recipient. The Perl script below do that. Better explaining with an exemple: $ cat testfun.m function x=testfun;x=0;endfunction $ cat testscript.m is_scalar(testfun) $ octave-which testscript.m /usr/share/octave/2.1.36/m/general/is_scalar.m /home/rafael/octave/testfun.m It also accepts input from stdin: $ octave-which < testscript.m /usr/share/octave/2.1.36/m/general/is_scalar.m /home/rafael/octave/testfun.m If another octave command is needed, use a second argument: $ octave-which testscript.m octave-2.0.17 /usr/share/octave/2.0.17/m/general/is_scalar.m /home/rafael/octave/testfun.m If stdin is desired along with an alternate octave command, use '-' as the script name: $ cat testscript.m | octave-which - octave-2.1.36 /usr/share/octave/2.1.36/m/general/is_scalar.m /home/rafael/octave/testfun.m At any rate: $ octave-which --help Usage: octave-which [script [octave-command] octave-which runs the Octave script specified as the first argument and print a list of paths for the user defined functions loaded in the script. If no argument is given, the Octave commands are read from stdin. An alternative Octave executable can be given as second argument. If stdin is wanted in this case, use '-' at the place of the script filename. Comments/enhacements are welcome. -- Rafael Laboissiere |
From: Paul K. <pki...@ja...> - 2002-09-20 03:38:12
|
Hi all, I've been thinking about what we need for our semi-annual release of octave-forge. Clean support for 2.1.36 and the upcoming 2.1.37 are definite show-stoppers. I'm not comfortable abandoning the older versions though. The changes required for .cc files we could do through configure by testing for certain functions which changed since 2.1.35. The alternative is to test against specific octave version numbers in the code. E.g., #define _VERSION(a,b,c) (((a)<<16) + ((b)<<8) + (c)) #define OCTAVE_VERSION _VERSION(OCTAVE_MAJOR,OCTAVE_MINOR,OCTAVE_PATCHLEVEL) #if (OCTAVE_VERSION > _VERSION(2,1,35) ... #else /* OCTAVE_VERSION <= 2.1.35 */ ... #endif I'm in favour of the latter because it will be easier to implement. Off the top of my head, struct/*.cc and FIXES/fsolve.cc are broken. A more difficult problem is that lo-sstream.h is missing from the octave installation so a lot more things look broken than really are. I suppose we could keep our own copy somewhere (e.g., in FIXES) and use -I$(TOPDIR)/FIXES if octave version is 2.1.36. Or we could just document the problem. Unfortunately m-files will also have to change: * replace ... with varargin/varargout * replace all_va_args with varargin{:} * for [v,k]=struct ... end now sets v to a list rather than a value * anything else? We could use version tests in our code. We could use a preprocessor and set up make to convert file.m.in to file.m. We could have file.m-2.1.35 for example for versions up to and including 2.1.35 and file.m for later versions. I'm in favour of using a preprocessor because I'm not very good at fixing the same bug in multiple files, and since I do not want the overhead of run time version checks. The preprocessor could either strip the conditional code that isn't used or it could comment it out. I prefer stripping it entirely as a way of reducing the cruft we present to the user. Anyone want to write this? Or could we use something like the C preprocessor or M4 directly? Note that a preprocessor will also be useful to those who are trying to support both octave and matlab from the same codebase (e.g., ode and tsa) --- you might want to consider this in the design. A number of functions from octave-forge have been incorporated into octave. We need to conditionally ignore them during build and install. Adding test support to the makefiles for all the directories and running all the existing tests during make check is a worthy goal, but I doubt I will get to it this time round. Anything else? Paul Kienzle pki...@us... |
From: Paul K. <pki...@ja...> - 2002-09-20 02:19:45
|
Hi all, I would like to do a semi-annual octave-forge release in November. I've started by sorting the changelog for my stuff into categories which I think our users will be interested in: * new functions and extensions are for advertising what things we've added * changed interfaces are warnings about things users may need to change * internal changes include bug fixes and enhancements which don't require or allow the user to call the function differently Could you please update it with your own changes which I may have missed or misrepresented. Particularly TSA (Alois), optimization (Etienne) and the symbolic toolbox (Ben). Marc, if you are listening, I don't know how the ODE toolbox changed between v1.06 and v1.14. Paul Kienzle pki...@us... |
From: D. G. <de...@gl...> - 2002-09-18 20:24:38
|
hello i would like to contribute to the statistics repository, this GPLed norminv.m, which (with the aid of normal_inv.m), completelty replicates matlab's norminv.m. I have tested every possible case (there are lots of easy-to-miss possibilities, will go into details if you like). I am not on the mailing-list yet, so please Cc me on any follow-up. # Copyright (C) 1995, 1996, 1997 Kurt Hornik, ## Copyright (C) 2002 Elliott Wave International, Inc. ## Author(s): Deepak Goel, Kurt Hornik. ## This file is derived from (and also calls) normal_niv.m, and hence ## GPLed. This function seeks to mirror matlab's norminv.m, so that ## one ## can run Kanzler's bdssig.m tests. ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by ## the Free Software Foundation; either version 2, or (at your option) ## any later version. ## ## This program is distributed in the hope that it will be useful, but ## WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ## General Public License for more details. ## ## You should have received a copy of the GNU General Public License ## along with this file. If not, write to the Free Software Foundation, ## 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. ## -*- texinfo -*- ## @deftypefn {Function File} {} normal_inv (@var{x}, @var{m}, ## @var{sig}) ## For each element of @var{x}, compute the quantile (the inverse of ## the ## CDF) at @var{x} of the normal distribution with mean @var{m} and ## variance @var{sig}. ## ## Default values are @var{m} = 0, @var{sig} = 1. ## @end deftypefn ## Author: KH <Kur...@ci...> ## Description: Quantile function of the normal distribution function inv = norminv (x, m, sig) if (! ((nargin == 1) || (nargin == 2) || (nargin == 3))) usage ("normal_inv (x, m, sig)"); endif if (nargin == 2) sig = 1; endif if (nargin == 1) m = 0; sig = 1; endif numrows= rows (sig); numcols = columns(sig); var=sig.^2; ## If var was negative or 0, that's an absurdity, so matlab returns ## NaN.. So, make sig absurd (-1) in that case.. for i=1:numrows for j=1:numcols if (sig(i,j) <= 0); var(i,j) = -1; endif end end ### if (sig <= 0) ### inv = NaN; ### elseif ### inv = normal_inv (x, m, sig.^2); ### endif inv = normal_inv (x, m, var); endfunction |
From: Etienne G. <et...@is...> - 2002-09-12 07:47:24
|
Hello, On Wed, Sep 11, 2002 at 03:52:18PM -0400, Paul Kienzle wrote: # > # 2) How does the interface compare to the matlab VR toolkit? Is there any # > # > Less fancy and free. # > # > # point to trying to match their interface? # > # > I am not trying to match it. I don't know it but for a short # > interaction a few years ago. # # Is there any point in trying to match it? I don't know. Do many people use it? Not around me. A few people played with it a little bit and that's it. Iirc, it was slowish. # > # > # 3) Are there alternative VR's to VRML? # > ^ # > What's? # # Virtual Reality [Engines] Vrml is not an engine. It is mostly a descriptive language that specifies 3D geometry, a little bit like latex, but with less computation capabilities still. Some browsers also allow scripting, so that computations can be done, using java or perl. # I was trying to answer two questions for myself: is there any difference from # the octave users perspective between VRML and a 3D plot widget that supports The basic functionalities are the same : display and examine. There certainly are more sophisticated 3D visualization tool, e.g. for examining clouds of points, functions of 3 parameters etc. Vrml may be more adapted to build objects. I use it to display results of 3D computer vision algorithms. # changing view points and lighting, and are there any alternatives to VRML # that might want the same interface for the octave user, but use a different # modelling language underneath. I know there exist other, but I don't know whether they use open formats. Iirc, some ray tracers have a quick renderer which should do more or less the same thing as a browser. # The only reason I would care is that it would affect how things get installed # in the future, and so it might affect where we install things now. For the # moment, how about you put it under main/vrml, and worry about conflicts when # things are more developed. # # - Paul Cheers, Etienne -- Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne |
From: Etienne G. <et...@is...> - 2002-09-11 17:49:09
|
Hello On Wed, Sep 11, 2002 at 01:21:04PM -0400, Paul Kienzle wrote: # Some questions: # # 1) What does the vrml interface require that is not needed by other 3D # visualization functions? Is it possible that you would want something like Needed externally : FreeWRL. Internally, lots of vrml-generating functions, since what is displayed is an assemblage of shapes described in vrml. Also, some functions to speak to freewrl are needed. # the plplot setup, where you are replacing the graph viewer but using the # usual interface to manipulate it? Here, your interaction with the browser through the octave command line is minimal. You tell it 'Start!', 'Stop!', 'Display this, please' and eventually ask it what objects the user clicked upon. For changing the viewpoint and doing snapshots or films, you use the browser's interface. # 2) How does the interface compare to the matlab VR toolkit? Is there any Less fancy and free. # point to trying to match their interface? I am not trying to match it. I don't know it but for a short interaction a few years ago. # 3) Are there alternative VR's to VRML? ^ What's? Cheers, Etienne -- Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne |
From: Paul K. <pki...@ja...> - 2002-09-11 17:21:08
|
Some questions: 1) What does the vrml interface require that is not needed by other 3D visualization functions? Is it possible that you would want something like the plplot setup, where you are replacing the graph viewer but using the usual interface to manipulate it? 2) How does the interface compare to the matlab VR toolkit? Is there any point to trying to match their interface? 3) Are there alternative VR's to VRML? I would put it in main/vrml or maybe main/vr or extra/vrml. - Paul On Tue, Sep 10, 2002 at 08:49:14PM +0100, Etienne Grossmann wrote: > > Hello, > > I'm working again on 3D visualization tools. Most conspicuous are > the functions : > > vmesh (x,y,z) : Somewhat like mesh(), but uses a VRML browser for > display. Allows to examine the function and save > snapshots. > > > sel = select_3D_points (x) : View a set of 3D points and select > some of them by using the mouse. > > There are functions for doing lines, polyhedra and various other 3D > objects. > > This is derived from the vrml toolbox on my homepage + some > improvements and a mini-howto that I'm writing. > > Anyone interested to have this, e.g. in main/vrml or > main/3Dvisualization or wherever? > > Cheers, > > Etienne > > PS : Requires FreeWRL (http://www.crc.ca/FreeWRL) to do the > visualization. There's at least a Debian package of it. > > -- > Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev |
From: Paul K. <pki...@ja...> - 2002-09-11 15:57:48
|
On Wed, Sep 11, 2002 at 08:40:55AM +0100, Etienne Grossmann wrote: > Hello > > On Tue, Sep 10, 2002 at 06:34:19PM -0400, Paul Kienzle wrote: > # Etienne, > # > # I would model this on fplot, which does this for functions of one variable. E.g., > # > # fmesh('fn') - plots the bivariate function or expression. It is a function > # if it is a single identifier otherwise it is an expression. > > I prefer having the building of data and plotting separate. Reasons: > there are many plotting methods (gnuplot ...); it is easy to call the > data-building function from within a plotting function. Of course, > fmesh() can be called from any other plotting function, but still I'd > rather keep code for plotting separate. > > Otoh, since you propose many calling methods (below), the code for > determing the boundaries, the size of the grid etc would have to be > repeated in the plotting and in the data-building function (and > repetition of code isn't fun). So one function could be better in that > respect. The idea is to get a simple view of a 2D expression with the minimum of hassle. The single plotting function called [mesh(x,y,z)] will hopefully be called the same no matter whether you are using gnuplot, plplot, or (when I get off my duff and start writing it) BLT. If users want fancy surfaces, or more control over the look and feel of the plot, they can easily grab the return values and call their own function just like they would have to do if no simple plotting were provided. > > # fmesh(x,y,'fn') - use the given x and y grid spacing > # > # fmesh(...,[xmin xmax ymin ymax]) - use the given axis limits > # > # fmesh(...,n) - use the given number of steps in each dimension x, y > # > # z = fmesh(...) - return the mesh rather than plotting > # > # [x,y,z] = fmesh(...) - return the mesh and the mesh spacing > # > # fmesh(...,'loop') - don't vectorize the expression, but instead evaluate > # it once for each point in x cross y. > > Other question: 'loop' by default, or not? Looping will be excruciatingly slow. The vectorized variety should be easier to invoke since it will be the most frequently used. > Also, the user may want to provide an already vectorized expression. Which is why I need to strip the ".." after vectorizing. The alternative is to write vectorize so that it doesn't vectorize an expression which is already vectorized: function expr = vectorize(expr) if isempty(regexp("[.][*/^]",expr)) expr = strrep(expr,'*','.*'); expr = strrep(expr,'/','./'); # I forgot this one before. expr = strrep(expr,'^','.^'); endif endfunction > I did not provide an auto-vectorize feature, but let the user put the '.'. I'm not very happy with the idea of auto-vectorize either, but it mostly does the right thing. It's unfortunate for loops are so slow that we have to go to great lengths to avoid them. > I thought there may be some cases where there are some matrix products that > shouldn't be .-prefixed. Hard to imagine: you are evaluating on an indeterminate grid without any access to local variables. Does it really make sense to say something like: fmesh("y + (x*x')") or fmesh("exp(x+y)/norm(x'*y)") Maybe. At least with auto-vectorize it will fail with something like: error: product: nonconformant arguments (op1 is 1x3, op2 is 3x1) so the user will know that something has gone wrong. This is after all a function to make common things more simple, not a replacement for meshgrid. > > [snip] > # To distinguish between expression and function use: > # > # if all(isalnum(expr)), z=feval(expr,x,y); else eval(["z=",expr,";"]); end > > Should check for "x" and "y" too. Yeah, that would be easy enough. > > # To vectorize we will need a function which converts bare ^ and * to .^ and .*. > # This would be something like: > # > # expr = strrep(expr,'*','.*'); > # expr = strrep(expr,'^','.^'); > # expr = strrep(expr,'..','.'); > > Beware of trailing "..." This is moot if we only vectorize expressions that don't have any .*, ./ or .^ operators. > > [snip] > # I would put it in main/plot. > # > # What do you think? > > Don't know, there's no rush so I'll let the question rest. > > Cheers, > > Etienne > > -- > Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne > > > ------------------------------------------------------- > In remembrance > www.osdn.com/911/ > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev |
From: Etienne G. <et...@is...> - 2002-09-11 07:32:12
|
Hello On Tue, Sep 10, 2002 at 06:34:19PM -0400, Paul Kienzle wrote: # Etienne, # # I would model this on fplot, which does this for functions of one variable. E.g., # # fmesh('fn') - plots the bivariate function or expression. It is a function # if it is a single identifier otherwise it is an expression. I prefer having the building of data and plotting separate. Reasons: there are many plotting methods (gnuplot ...); it is easy to call the data-building function from within a plotting function. Of course, fmesh() can be called from any other plotting function, but still I'd rather keep code for plotting separate. Otoh, since you propose many calling methods (below), the code for determing the boundaries, the size of the grid etc would have to be repeated in the plotting and in the data-building function (and repetition of code isn't fun). So one function could be better in that respect. # fmesh(x,y,'fn') - use the given x and y grid spacing # # fmesh(...,[xmin xmax ymin ymax]) - use the given axis limits # # fmesh(...,n) - use the given number of steps in each dimension x, y # # z = fmesh(...) - return the mesh rather than plotting # # [x,y,z] = fmesh(...) - return the mesh and the mesh spacing # # fmesh(...,'loop') - don't vectorize the expression, but instead evaluate # it once for each point in x cross y. Other question: 'loop' by default, or not? Also, the user may want to provide an already vectorized expression. I did not provide an auto-vectorize feature, but let the user put the '.'. I thought there may be some cases where there are some matrix products that shouldn't be .-prefixed. [snip] # To distinguish between expression and function use: # # if all(isalnum(expr)), z=feval(expr,x,y); else eval(["z=",expr,";"]); end Should check for "x" and "y" too. # To vectorize we will need a function which converts bare ^ and * to .^ and .*. # This would be something like: # # expr = strrep(expr,'*','.*'); # expr = strrep(expr,'^','.^'); # expr = strrep(expr,'..','.'); Beware of trailing "..." [snip] # I would put it in main/plot. # # What do you think? Don't know, there's no rush so I'll let the question rest. Cheers, Etienne -- Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne |
From: Paul K. <pki...@ja...> - 2002-09-10 22:34:22
|
Etienne, I would model this on fplot, which does this for functions of one variable. E.g., fmesh('fn') - plots the bivariate function or expression. It is a function if it is a single identifier otherwise it is an expression. fmesh(x,y,'fn') - use the given x and y grid spacing fmesh(...,[xmin xmax ymin ymax]) - use the given axis limits fmesh(...,n) - use the given number of steps in each dimension x, y z = fmesh(...) - return the mesh rather than plotting [x,y,z] = fmesh(...) - return the mesh and the mesh spacing fmesh(...,'loop') - don't vectorize the expression, but instead evaluate it once for each point in x cross y. E.g., sombrero = fmesh('sinc(x^2+y^2)',[-8 8 -8 8]) To distinguish between expression and function use: if all(isalnum(expr)), z=feval(expr,x,y); else eval(["z=",expr,";"]); end To vectorize we will need a function which converts bare ^ and * to .^ and .*. This would be something like: expr = strrep(expr,'*','.*'); expr = strrep(expr,'^','.^'); expr = strrep(expr,'..','.'); It may be faster to do things directly rather than using strrep: # insert a '.' before each * and ^ idx = expr=="*" | expr== "^"; n = length(expr); target = [1:n] + cumsum(idx); vec = repmat('.',1,target(n)); vec(target) = expr; # remove duplicate '..' n = length(vec); idx = find(vec(1:n-1)=='.' & vec(2:n)=='.'); vec(idx) = []; I would put it in main/plot. What do you think? - Paul On Tue, Sep 10, 2002 at 08:37:40PM +0100, Etienne Grossmann wrote: > > Hello, > > what about a function like this (in main/miscellaneous)? For people > too lazy to call linspace() and meshgrid(). > > Cheers, > > Etienne > > ====================================================================== > ## z = formula2mat (f, ...) - Fill matrix 'z' with values of formula 'f' > ## > ## INPUT ------ > ## f :string: A formula written in octave code. > ## > ## OPTIONS ---- > ## bndx : 2x1 : Boundary of x in which f is evaluated (overrides bnd) > ## bndy : 2x1 : Boundary of y in which f is evaluated (overrides bnd) > ## bnd : 2x2 : bnd = [bndx; bndy] Boundary in which f is evaluated > ## Default = [-1,1;-1,1] > ## > ## sz : 2x1 : Number of x and y values at which f is evaluated > ## Default = [11,11] > ## > ## x : vec : Values of x at which f is evaluated (overrides bndX and szX) > ## y : vec : Values of y at which f is evaluated (overrides bndY and szY) > ## > ## vec : bool: If true, assume that z can be obtained by evaluating f when > ## x and y are matrices, rather than scalars. > ## > ## OUTPUT ----- > ## z : sz-sized matrix containing the values of f. > ## > ## EXAMPLES --- > ## ## Fills a matrix z containing the values > ## ## "x^2 - y^2" for x and y varying in > ## ## [-1,1] by intervals of 0.2. > ## z = formula2mat ("x^2 - y^2"); > ## > ## ## Same thing, quicker. > ## z = formula2mat ("x.^2 + y.^2","vec",1); > ## > function zz = formula2mat (f, ...) > > op1 = " x y bndx bndy bnd sz szx szy vec "; > > default = struct ("x", nan,\ > "y", nan,\ > "bnd",[-1,1;-1,1],\ > "bndx",nan,\ > "bndy",nan,\ > "sz",[11,11],\ > "szx",nan,\ > "szy",nan,\ > "vec",0); > > if nargin > 1, > opts = read_options (list (all_va_args), "default", default, \ > "op1", op1); > else opts = default; > end > > [x,y,bnd, bndx, bndy, sz, szx, szy, vec] = \ > getfield (opts, "x","y","bnd" ,"bndx", "bndy", "sz", "szx", "szy", "vec"); > > ## szx overwrites sz (same for szy) > if ! isnan (szx), sz(1) = szx; end > if ! isnan (szy), sz(2) = szy; end > > if length (sz) != 2 > error ("length of sz should be 2, not %i\n", length (sz)); > end > bnd > ## bndx overwrites bnd > if ! isnan (bndx(1)), bnd(1,1) = bndx(1); end > if length (bndx)>1 && ! isnan (bndx(2)), bnd(1,2) = bndy(2); end > if ! isnan (bndy(1)), bnd(2,1) = bndy(1); end > if length (bndy)>1 && ! isnan (bndy(2)), bnd(2,2) = bndy(2); end > bnd > if any (size (bnd) != [2,2]) > error ("size of bnd should be [2,2], not [%i,%i]\n", size (bnd)); > end > > ## If x or y are not def'd, define them now > if isnan (x), x = linspace (bnd(1,1),bnd(1,2),sz(1)); end > if isnan (y), y = linspace (bnd(2,1),bnd(2,2),sz(2)); end > > > [xx,yy] = meshgrid (x,y); > > > ## x and y will become scalar variables below > > > if ! vec > zz = zeros (sz); > eval (sprintf (["for ii = 1:sz(1),\n",\ > " for jj = 1:sz(2),\n",\ > " x = xx(ii,jj); y = yy(ii,jj);\n",\ > " zz(ii,jj) = %s;\n",\ > " end;\n",\ > "end;\n"],\ > f)); > else > x = xx; > y = yy; > eval (["zz = ",f,";"]); > end > > -- > Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev |