From octave-maintainers-request@bevo.che.wisc.edu Fri Dec 1 10:42:25 2000 Resent-Date: Fri, 1 Dec 2000 10:42:25 -0600 (CST) Message-ID: From: "Lippert, Ross A." To: "'octave-maintainers@octave.org'" Subject: set patch Date: Fri, 1 Dec 2000 11:41:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C05BB5.955DB14C" Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C05BB5.955DB14C Content-Type: text/plain; charset="iso-8859-1" Faster intersection and complement. Aesthetically more pleasing (well to me anyway) create_set. Here is the diff -c -r <> ------_=_NextPart_000_01C05BB5.955DB14C Content-Type: application/octet-stream; name="setpatch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="setpatch" ? octave/scripts/set/Makefile Index: octave/scripts/set/complement.m =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/octave/scripts/set/complement.m,v retrieving revision 1.12 diff -c -r1.12 complement.m *** octave/scripts/set/complement.m 2000/01/13 08:40:21 1.12 --- octave/scripts/set/complement.m 2000/12/01 16:39:12 *************** *** 32,37 **** --- 32,38 ---- ## @seealso{create_set, union, and intersection} =20 ## Author: jwe + ## Modified: Ross Lippert =20 function y =3D complement (a, b) =20 *************** *** 40,59 **** endif =20 if (isempty (a)) ! y =3D create_set(b); elseif (isempty (b)) y =3D []; else a =3D create_set (a); b =3D create_set (b); ! yindex =3D 1; ! y =3D zeros (1, length (b)); ! for index =3D 1:length (b) ! if (all (a !=3D b (index))) ! y(yindex++) =3D b(index); ! endif ! endfor ! y =3D y(1:(yindex-1)); endif =20 endfunction --- 41,64 ---- endif =20 if (isempty (a)) ! y =3D create_set (b); elseif (isempty (b)) y =3D []; else + ## why can't we just assume a and b are already sets? Why can't + ## that be a requirement of intersection? -Ross a =3D create_set (a); b =3D create_set (b); !=20 ! # Is doubling up on a here the right idea or just a shameful hack? -R ! y =3D sort([a a b]); ! c =3D find([nan y]!=3D[y nan]); ! y =3D y( c( find( diff( c)=3D=3D1) ) ); endif =20 endfunction +=20 +=20 +=20 +=20 +=20 Index: octave/scripts/set/create_set.m =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/octave/scripts/set/create_set.m,v retrieving revision 1.16 diff -c -r1.16 create_set.m *** octave/scripts/set/create_set.m 2000/10/31 02:08:49 1.16 --- octave/scripts/set/create_set.m 2000/12/01 16:39:12 *************** *** 20,26 **** ## -*- texinfo -*- ## @deftypefn {Function File} {} create_set (@var{x}) ## Return a row vector containing the unique values in @var{x}, = sorted in ! ## ascending order. For example, ## ## @example ## @group --- 20,27 ---- ## -*- texinfo -*- ## @deftypefn {Function File} {} create_set (@var{x}) ## Return a row vector containing the unique values in @var{x}, = sorted in ! ## ascending order. Returns a row vector containing the frequencies = of ! ## those values in @var{x} in a second argument. For example, ## ## @example ## @group *************** *** 32,37 **** --- 33,39 ---- ## @seealso{union, intersection, and complement} =20 ## Author: jwe + ## Modified: Ross Lippert =20 function y =3D create_set(x) =20 *************** *** 45,56 **** [nrx, ncx] =3D size (x); nelx =3D nrx * ncx; y =3D sort (reshape (x, 1, nelx)); ! els =3D find (y(1:nelx-1) !=3D y(2:nelx)); ! if (isempty (els)); ! y =3D y(1); ! else ! y =3D y([1, els+1]); ! endif endif =20 endfunction --- 47,58 ---- [nrx, ncx] =3D size (x); nelx =3D nrx * ncx; y =3D sort (reshape (x, 1, nelx)); ! c =3D find([nan y]!=3D[y nan]); ! y =3D y(c(1:length(c)-1)); endif =20 endfunction +=20 +=20 +=20 +=20 Index: octave/scripts/set/intersection.m =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/octave/scripts/set/intersection.m,v retrieving revision 1.11 diff -c -r1.11 intersection.m *** octave/scripts/set/intersection.m 2000/01/13 08:40:22 1.11 --- octave/scripts/set/intersection.m 2000/12/01 16:39:12 *************** *** 32,37 **** --- 32,38 ---- ## @seealso{create_set, union, and complement} =20 ## Author: jwe + ## Modified: Ross Lippert =20 function y =3D intersection(a,b) =20 *************** *** 44,70 **** return; endif =20 a =3D create_set(a); b =3D create_set(b); =20 ! if(length(a) < length(b)) ! yindex =3D 1; ! y =3D zeros(1,length(a)); ! for index =3D 1:length(a) ! if(any(b =3D=3D a(index))) ! y(yindex++) =3D a(index); ! endif ! endfor ! else ! yindex =3D 1; ! y =3D zeros(1,length(b)); ! for index =3D 1:length(b) ! if(any(a =3D=3D b(index))) ! y(yindex++) =3D b(index); ! endif ! endfor ! endif !=20 ! y =3D y(1:(yindex-1)); =20 endfunction --- 45,58 ---- return; endif =20 + ## why can't we just assume a and b are already sets? Why can't + ## that be a requirement of intersection? -Ross a =3D create_set(a); b =3D create_set(b); =20 ! y =3D sort([a b]); ! c =3D find([nan y]!=3D[y nan]); ! y =3D y( c( find( diff( c)=3D=3D2) ) ); =20 endfunction +=20 ------_=_NextPart_000_01C05BB5.955DB14C-- From octave-maintainers-request@bevo.che.wisc.edu Thu Dec 7 13:36:14 2000 Resent-Date: Thu, 7 Dec 2000 13:36:14 -0600 (CST) Date: Thu, 7 Dec 2000 13:36:01 -0600 Message-Id: <200012071936.eB7Ja1w10318@foobar.bogus.domain> From: "John W. Eaton" To: bug-octave@bevo.che.wisc.edu, octave-maintainers@bevo.che.wisc.edu Subject: The future of Octave Resent-Message-ID: <7qz2AViXCgP.A.7lF.ua-L6@bahaha.che.wisc.edu> Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu [My apologies if you receive duplicate copies of this message. I realized that a number of people on these lists may not be reading the help-octave list too. --jwe] I've now worked on Octave for almost nine years. During most of that time, I have enjoyed the challenge of working on a relatively large project. In the beginning, I wasn't at all sure that I could manage it (and maybe that is even more true now!). Watching Octave grow to become a widely used and reasonably successful contribution to the free software community has also been rewarding, and I am grateful to all those who have helped with its development. But now I believe that it may be time for me to move on and do something else for a while. I'm not yet sure what that will be. It may involve a similar system for numerical computing, or it may be something completely different, but I do feel that I am no longer able to maintain my current level of involvement with Octave's development. I did not arrive at this decision hastily, nor is it in direct response to any messages that were posted in the last few days. Making a change like this is something that I have been considering for quite some time now. What will happen to Octave? Because Octave is free software, it will continue to be available. By sometime early next year (perhaps by Octave's ninth birthday, February 20, 2001) I will release a new "stable" version (based on the 2.1.x sources), which I will continue to maintain to the extent of fixing serious bugs. I don't plan to work on any new features, though I may accept well-written patches that include documentation and ChangeLog entries. Although I plan to continue fixing serious bugs in Octave, if someone (or perhaps a small group) is interested in taking over maintenance of Octave, you should contact me so we can discuss it. Why are you considering leaving? There are a number of reasons, but one of the most important is that working on Octave is no longer the challenge for me that it once was. Much of what I set out to do with Octave has been done. I am pleased with what we have accomplished so far, but ready to take on something new. I never intended Octave to be a Matlab clone, nor am I really interested in creating such a thing, but that seems to be what many users of Octave want. It is not very interesting to me to simply reimplement all the features/bugs of Matlab. I am finding it too constraining to try to maintain almost any level of compatibility with a proprietary product for which there is no standard. It stifles any creativity by the threat of future incompatibility. I see this is as a real problem, not just an imagined one. Free software needs a vision beyond reimplementation of existing proprietary tools. Those of us who are interested in free software tools must become leaders rather than followers, and I am optimistic that this can happen for numerical software. But I don't believe it can happen if Octave continues down its current path. What will you do? I believe that we (users of numerical software tools) could benefit greatly from a freely available, high quality, high level language for solving numerical (and possibly symbolic) problems. Octave has been an interesting experiment, and has shown that, within the free software community, it is possible to do a lot with limited resources. I think now is a good time to step back, examine what we have done, and decide what is the best course for the future. I'm looking forward to helping to define and implement the next generation of free software tools for numerical problems. jwe From octave-maintainers-request@bevo.che.wisc.edu Fri Dec 8 17:54:21 2000 Resent-Date: Fri, 8 Dec 2000 17:54:21 -0600 (CST) From: "Julian A. de Marchi, Ph.D" To: "John W. Eaton" Cc: , "Help-Octave" Subject: Octave & Matlab Date: Fri, 8 Dec 2000 18:54:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001208185558.G16905@gallium.icp.inpg.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu I'd like to expound tersely upon my earlier email. I think it's fine that Octave continue developing without using Matlab as a frame of reference. Its strength as an independent, community-owned (and it seems, often much improved) numerical processing tool shouldn't be fettered by concerns of compatibility with a flashier, but not necessarily superior, de-facto commercial tool as Matlab basically is. I also think it must be possible to produce compatibility with Matlab at an interface level without too much compromise in terms of either performance or fundamental principles (be they scientific or philosophical). This seems especially true since Octave is as yet still a hard-core numerical engine, without a graphical user interface. I hope that Octave contributors maintain their awareness of Matlab interface compatibility when possible and in those instances when it does not compromise performance or usability. However, I also agree that it needn't be the driving factor in new design and extension of Octave features. Rather than forking Octave, for better or worse, to satisfy both parties in the debate, I hope that some enterprising contributors (those who are interested, myself included), can toil together to maintain and improve Octave compatibility with Matlab in the form of an abstraction layer or babel fish. Rather than argue about the two options, perhaps we can, as a community, agree upon an API or interpreter interface which facilitates this option while freeing Octave from the fetters of selective low-level compatibility. I'm not even sure that such an interface need specify anything further than full functional compatibility, as most of the differences between the two languages are merely syntactic at worst. And this of course makes further argument on the topic rather moot. Why not simply drop the case and work on a Matlab-compatible layer, that uses Octave as the driving engine? This would, I believe, encourage more intelligent folks to get into Octave and help the project grow, and obviate the need for further argumentation on the merits or pitfalls of one course exclusively over the other. Cheers, Julian From octave-maintainers-request@bevo.che.wisc.edu Fri Dec 8 18:24:40 2000 Resent-Date: Fri, 8 Dec 2000 18:24:40 -0600 (CST) Date: Sat, 9 Dec 2000 00:23:50 +0000 (GMT) From: John Smith To: octave-maintainers@bevo.che.wisc.edu Subject: gperf: compiling Octave from CVS sources Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <6muX1N8fx_P.A.J4E.IvXM6@bahaha.che.wisc.edu> Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu Hello again, I have collected Octave from CVS on 8 December 2000. The ./configure is complaining about my gperf, and ultimately c++ complains about lex.cc in a way which looks related. I have installed a new gperf; it says bash:> gperf --version GNU gperf 2.7.2 ./configure is saying checking for gperf... gperf configure: warning: I found gperf, but it does not support all of the following options: -t -C -D -E -G -L ANSI-C -H -N; you need gperf 2.7 or a more recent version I have started to search out an explanation: I think ./configure is doing something like: #! /bin/sh echo "%{ %} %% " | /usr/local/bin/gperf -t -C -D -E -G -L ANSI-C -H octave_kw_hash -N octave_kw_lookup which is giving the error message Empty input key is not allowed. To recognize an empty input key, your code should check for len == 0 before calling the gperf generated lookup function. Can you give any advice? Thanks, John From octave-maintainers-request@bevo.che.wisc.edu Fri Dec 8 18:24:42 2000 Resent-Date: Fri, 8 Dec 2000 18:24:42 -0600 (CST) Date: Sat, 9 Dec 2000 00:10:15 +0000 (GMT) From: John Smith To: octave-maintainers@bevo.che.wisc.edu Subject: strptime? compiling CVS sources problem... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu Hello, Compiling a CVS octave collected today, I generate this error message gcc -c -I. -I../../octave/liboctave -I.. -I../liboctave -I../src -I../libcruft/misc -I../../octave -I../../octave/liboctave -I../../octave/src -I../../octave/libcruft/misc -I../../octave/glob -I../glob -DHAVE_CONFIG_H -mieee-fp -g -O2 -Wall ../../octave/liboctave/strptime.c -o strptime.o ../../octave/liboctave/strptime.c: In function `strptime_internal': ../../octave/liboctave/strptime.c:576: warning: implicit declaration of function `localtime_r' ../../octave/liboctave/strptime.c:576: warning: comparison between pointer and integer ../../octave/liboctave/strptime.c: In function `strptime': ../../octave/liboctave/strptime.c:863: argument `buf' doesn't match prototype /usr/include/time.h:92: prototype declaration Warning at 576: The function localtime_r in /usr/include/time.h is protected by #if defined(_POSIX_THREAD_SAFE_FUNCTIONS) || defined(_REENTRANT) extern char* asctime_r __P((__const struct tm *, char *)); extern char* ctime_r __P((__const time_t *, char *)); extern struct tm* gmtime_r __P((__const time_t *, struct tm *)); extern struct tm* localtime_r __P((__const time_t *, struct tm *)); #endif and doesn't get declared. But config.h does set HAVE_LOCALTIME_R to 1. I don't suppose it really matters... Error at 863: The strptime in /usr/include/time.h is declared extern char * strptime __P ((char * __s, __const char * __fmt, struct tm * __tm)); whereas in liboctave/strptime.c it appears as char * strptime (buf, format, tm) const char *buf; const char *format; struct tm *tm; which is enough different to trigger the error at line 863. The config.h contains /* Define if you have the strptime function. */ #define HAVE_STRPTIME 1 Is this supposed to have any effect, in the sense of only declaring strptime if it doesn't already exist? I have a fairly ancient Linux system. Perhaps I should simply be told to upgrade it. John Smith From octave-maintainers-request@bevo.che.wisc.edu Sat Dec 9 01:28:27 2000 Resent-Date: Sat, 9 Dec 2000 01:28:27 -0600 (CST) From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14897.57104.786549.208295@foobar.bogus.domain> Date: Sat, 9 Dec 2000 01:28:16 -0600 To: John Smith Cc: octave-maintainers@bevo.che.wisc.edu Subject: gperf: compiling Octave from CVS sources In-Reply-To: References: X-Mailer: VM 6.85 under Emacs 20.7.2 Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu On 9-Dec-2000, John Smith wrote: | I have collected Octave from CVS on 8 December 2000. | | The ./configure is complaining about my gperf, and ultimately c++ complains | about lex.cc in a way which looks related. | | I have installed a new gperf; it says | | bash:> gperf --version | GNU gperf 2.7.2 | | ./configure is saying | | checking for gperf... gperf | configure: warning: I found gperf, but it does not support all of | the following options: -t -C -D -E -G -L ANSI-C -H -N; | you need gperf 2.7 or a more recent version | | | I have started to search out an explanation: I think ./configure is | doing something like: | | #! /bin/sh | | echo "%{ | %} | %% | " | /usr/local/bin/gperf -t -C -D -E -G -L ANSI-C -H octave_kw_hash -N octave_kw_lookup | | which is giving the error message | | Empty input key is not allowed. | To recognize an empty input key, your code should check for | len == 0 before calling the gperf generated lookup function. | | Can you give any advice? Please try the following patch. It sends %{ %} %% foo to gperf. You'll need to rerun autoconf, remove config.cache, run configure again, and probably also remove any incorrect version of src/oct-gperf.h that you may have generated. Thanks, jwe 2000-12-09 John W. Eaton * aclocal.m4: Give gperf a keyword, to avoid complaints from newer versions. Index: aclocal.m4 =================================================================== RCS file: /usr/local/cvsroot/octave/aclocal.m4,v retrieving revision 1.49 diff -u -r1.49 aclocal.m4 --- aclocal.m4 2000/10/31 20:03:19 1.49 +++ aclocal.m4 2000/12/09 07:26:04 @@ -875,7 +875,7 @@ if echo "%{ %} %% -" | $GPERF -t -C -D -E -G -L ANSI-C -H octave_kw_hash -N octave_kw_lookup > /dev/null 2>&1; then +foo" | $GPERF -t -C -D -E -G -L ANSI-C -H octave_kw_hash -N octave_kw_lookup > /dev/null 2>&1; then true else GPERF="" From octave-maintainers-request@bevo.che.wisc.edu Sat Dec 9 01:33:01 2000 Resent-Date: Sat, 9 Dec 2000 01:33:01 -0600 (CST) From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14897.57377.775076.295405@foobar.bogus.domain> Date: Sat, 9 Dec 2000 01:32:49 -0600 To: John Smith Cc: octave-maintainers@bevo.che.wisc.edu Subject: strptime? compiling CVS sources problem... In-Reply-To: References: X-Mailer: VM 6.85 under Emacs 20.7.2 Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu On 9-Dec-2000, John Smith wrote: | Hello, | | Compiling a CVS octave collected today, I generate this error | message | | gcc -c -I. -I../../octave/liboctave -I.. -I../liboctave -I../src | -I../libcruft/misc -I../../octave -I../../octave/liboctave | -I../../octave/src -I../../octave/libcruft/misc -I../../octave/glob | -I../glob -DHAVE_CONFIG_H -mieee-fp -g -O2 -Wall | ../../octave/liboctave/strptime.c -o strptime.o | ../../octave/liboctave/strptime.c: In function `strptime_internal': | ../../octave/liboctave/strptime.c:576: warning: implicit declaration of | function `localtime_r' | ../../octave/liboctave/strptime.c:576: warning: comparison between pointer | and integer | ../../octave/liboctave/strptime.c: In function `strptime': | ../../octave/liboctave/strptime.c:863: argument `buf' doesn't match | prototype | /usr/include/time.h:92: prototype declaration | | | Warning at 576: | The function localtime_r in /usr/include/time.h is protected by | | #if defined(_POSIX_THREAD_SAFE_FUNCTIONS) || defined(_REENTRANT) | | extern char* asctime_r __P((__const struct tm *, char *)); | extern char* ctime_r __P((__const time_t *, char *)); | extern struct tm* gmtime_r __P((__const time_t *, struct tm *)); | extern struct tm* localtime_r __P((__const time_t *, struct tm *)); | | #endif | and doesn't get declared. But config.h does set HAVE_LOCALTIME_R to 1. | I don't suppose it really matters... | | Error at 863: | The strptime in /usr/include/time.h is declared | | extern char * strptime __P ((char * __s, __const char * __fmt, | struct tm * __tm)); | | whereas in liboctave/strptime.c it appears as | | char * | strptime (buf, format, tm) | const char *buf; | const char *format; | struct tm *tm; | | which is enough different to trigger the error at line 863. | | The config.h contains | /* Define if you have the strptime function. */ | #define HAVE_STRPTIME 1 | | Is this supposed to have any effect, in the sense of only declaring | strptime if it doesn't already exist? | | I have a fairly ancient Linux system. Perhaps I should simply be told | to upgrade it. Perhaps. Please try the following patch and let me know if it solves the problem. Thanks, jwe 2000-12-09 John W. Eaton * strptime.c: Surround everything after including config.h in #ifndef HAVE_STRPTIME ... #endif. Index: strptime.c =================================================================== RCS file: /usr/local/cvsroot/octave/liboctave/strptime.c,v retrieving revision 1.3 diff -u -r1.3 strptime.c --- strptime.c 2000/02/01 10:07:26 1.3 +++ strptime.c 2000/12/09 07:32:13 @@ -27,6 +27,8 @@ # include #endif +#ifndef HAVE_STRPTIME + #include #ifdef _LIBC # include @@ -869,3 +871,5 @@ #endif return strptime_internal (buf, format, tm, &decided); } + +#endif From octave-maintainers-request@bevo.che.wisc.edu Sat Dec 9 07:58:21 2000 Resent-Date: Sat, 9 Dec 2000 07:58:21 -0600 (CST) Date: Sat, 9 Dec 2000 13:57:37 +0000 (GMT) From: John Smith To: "John W. Eaton" cc: octave-maintainers@bevo.che.wisc.edu Subject: Re: strptime? compiling CVS sources problem... In-Reply-To: <14897.57377.775076.295405@foobar.bogus.domain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <38PieoYUluO.A.wbF.9pjM6@bahaha.che.wisc.edu> Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu Thanks for the patch. Yes, it does solve the problem. And the other patch to aclocal.m4 to allow for newer versions of gperf also works for me. The whole CVS octave seems to have compiled cleanly, except for a bit of Latex/metafont magic, and I am fairly certain my system is broken there. John On Sat, 9 Dec 2000, John W. Eaton wrote: > On 9-Dec-2000, John Smith wrote: > > | Hello, > | > | Compiling a CVS octave collected today, I generate this error > | message > | > | gcc -c -I. -I../../octave/liboctave -I.. -I../liboctave -I../src > | -I../libcruft/misc -I../../octave -I../../octave/liboctave > | -I../../octave/src -I../../octave/libcruft/misc -I../../octave/glob > | -I../glob -DHAVE_CONFIG_H -mieee-fp -g -O2 -Wall > | ../../octave/liboctave/strptime.c -o strptime.o > | ../../octave/liboctave/strptime.c: In function `strptime_internal': > | ../../octave/liboctave/strptime.c:576: warning: implicit declaration of > | function `localtime_r' > | ../../octave/liboctave/strptime.c:576: warning: comparison between pointer > | and integer > | ../../octave/liboctave/strptime.c: In function `strptime': > | ../../octave/liboctave/strptime.c:863: argument `buf' doesn't match > | prototype > | /usr/include/time.h:92: prototype declaration > | > | > | Warning at 576: > | The function localtime_r in /usr/include/time.h is protected by > | > | #if defined(_POSIX_THREAD_SAFE_FUNCTIONS) || defined(_REENTRANT) > | > | extern char* asctime_r __P((__const struct tm *, char *)); > | extern char* ctime_r __P((__const time_t *, char *)); > | extern struct tm* gmtime_r __P((__const time_t *, struct tm *)); > | extern struct tm* localtime_r __P((__const time_t *, struct tm *)); > | > | #endif > | and doesn't get declared. But config.h does set HAVE_LOCALTIME_R to 1. > | I don't suppose it really matters... > | > | Error at 863: > | The strptime in /usr/include/time.h is declared > | > | extern char * strptime __P ((char * __s, __const char * __fmt, > | struct tm * __tm)); > | > | whereas in liboctave/strptime.c it appears as > | > | char * > | strptime (buf, format, tm) > | const char *buf; > | const char *format; > | struct tm *tm; > | > | which is enough different to trigger the error at line 863. > | > | The config.h contains > | /* Define if you have the strptime function. */ > | #define HAVE_STRPTIME 1 > | > | Is this supposed to have any effect, in the sense of only declaring > | strptime if it doesn't already exist? > | > | I have a fairly ancient Linux system. Perhaps I should simply be told > | to upgrade it. > > Perhaps. > > Please try the following patch and let me know if it solves the > problem. > > Thanks, > > jwe > > > 2000-12-09 John W. Eaton > > * strptime.c: Surround everything after including config.h in > #ifndef HAVE_STRPTIME ... #endif. > > > Index: strptime.c > =================================================================== > RCS file: /usr/local/cvsroot/octave/liboctave/strptime.c,v > retrieving revision 1.3 > diff -u -r1.3 strptime.c > --- strptime.c 2000/02/01 10:07:26 1.3 > +++ strptime.c 2000/12/09 07:32:13 > @@ -27,6 +27,8 @@ > # include > #endif > > +#ifndef HAVE_STRPTIME > + > #include > #ifdef _LIBC > # include > @@ -869,3 +871,5 @@ > #endif > return strptime_internal (buf, format, tm, &decided); > } > + > +#endif > From octave-maintainers-request@bevo.che.wisc.edu Sun Dec 10 00:01:23 2000 Resent-Date: Sun, 10 Dec 2000 00:01:23 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14899.7213.942613.229129@foobar.bogus.domain> Date: Sun, 10 Dec 2000 00:01:17 -0600 From: "John W. Eaton" To: octave-maintainers@bevo.che.wisc.edu Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu Subject: Unidentified subject! X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu On 17-May-2000, I wrote: | | On 17-May-2000, emil@gollum.fri.uni-lj.si wrote: | | | Hello! | | | | What is the MAIN reason that 1.8:0.05:1.9 produces [1.8000 1.8500] | | and not [1.8000 1.8500 1.9000]? | | I am using 2.0.14 version of Octave. | | Thank you for your answer. | | Best regards, | | Emil Zagar | | I'd guess that the MAIN reason is that there is a bug in the way | Octave is trying (very hard) to compute the correct number of elements | for ranges. If you're in a debugging mood, the code to look at is in | the Range::nelem_internal and related functions in liboctave/Range.cc. Here is a patch (against the 2.1.x sources, but it should be obvious how to apply it to the older sources as well) that should fix this problem. With it, here is what I see: GNU Octave, version 2.1.32 (i686-pc-linux-gnu). Copyright (C) 1996, 1997, 1998, 1999, 2000 John W. Eaton. This is free software with ABSOLUTELY NO WARRANTY. For details, type `warranty'. octave:1> 1.8:0.05:1.9 ans = 1.8000 1.8500 1.9000 octave:2> 1.0008:0.00005:1.0009 ans = 1.0008 1.0009 1.0009 It is a more than a little bit embarrassing to me that this bug has been in Octave for so long. Thanks, jwe 2000-12-09 John W. Eaton * Range.cc (Range::nelem_internal): Call round here, not tfloor. Rename n_intervals to be n_elt. Index: Range.cc =================================================================== RCS file: /usr/local/cvsroot/octave/liboctave/Range.cc,v retrieving revision 1.24 diff -u -r1.24 Range.cc --- Range.cc 2000/02/01 10:06:59 1.24 +++ Range.cc 2000/12/10 05:44:16 @@ -235,11 +235,11 @@ { double ct = 3.0 * DBL_EPSILON; - double tmp = tfloor ((rng_limit - rng_base + rng_inc) / rng_inc, ct); + double tmp = round ((rng_limit - rng_base + rng_inc) / rng_inc, ct); - int n_intervals = (tmp > 0.0 ? static_cast (tmp) : 0); + int n_elt = (tmp > 0.0 ? static_cast (tmp) : 0); - return (n_intervals >= INT_MAX - 1) ? -1 : n_intervals; + return (n_elt >= INT_MAX - 1) ? -1 : n_elt; } /* From octave-maintainers-request@bevo.che.wisc.edu Sun Dec 10 03:18:21 2000 Resent-Date: Sun, 10 Dec 2000 03:18:21 -0600 (CST) Date: Sat, 9 Dec 2000 20:59:23 GMT From: john Message-Id: <200012092059.UAA26577@arrows.demon.co.uk> To: octave-maintainers@bevo.che.wisc.edu Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu Subject: Unidentified subject! X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu To: octave-maintainers@bevo.che.wisc.edu Cc: Subject: Octave from Recent CVS: Segmentation fault Bug report for Octave 2.1.31 configured for %OCTAVE_CANONICAL_HOST_TYPE% (CVS 9 December 2000) Description: ----------- The following not at all useful code causes a Segmentation fault: arrow2 [544] octave GNU Octave, version 2.1.31 (i586-pc-linux-gnulibc1). Copyright (C) 1996, 1997, 1998, 1999, 2000 John W. Eaton. This is free software with ABSOLUTELY NO WARRANTY. For details, type `warranty'. *** This is a development version of Octave. Development releases *** are provided for people who want to help test, debug, and improve *** Octave. *** *** If you want a stable, well-tested version of Octave, you should be *** using one of the stable releases (when this development release *** was made, the latest stable version was 2.0.16). INFO_FILE = /usr/local/info/octave.info octave:1> xx = linspace(-3,10)'; octave:2> xx / (pi+xx) panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Segmentation fault Fix --- Not yet known... Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux arrows 2.0.36 #1 Sat Nov 20 20:52:52 GMT 1999 i586 configure opts: --prefix=/part2/gcc/install-3 Fortran compiler: g77 FFLAGS: -O F2C: F2CFLAGS: FLIBS: -lg2c -lm -L/part2/gcc/install-3/lib/gcc-lib/i586-pc-linux-gnulibc1/2.95.2 -L/part2/gcc/install-3/i586-pc-linux-gnulibc1/lib -L/part2/gcc/install-3/lib -lm CPPFLAGS: INCFLAGS: -I. -I../octave -I. -I./liboctave -I./src -I./libcruft/misc -I../octave -I../octave/liboctave -I../octave/src -I../octave/libcruft/misc -I../octave/glob -I./glob C compiler: gcc, version 2.95.2 19991024 (release) CFLAGS: -g -O2 -Wall CPICFLAG: -fPIC C++ compiler: c++, version 2.95.2 19991024 (release) CXXFLAGS: -g -O2 -Wall CXXPICFLAG: -fPIC LDFLAGS: -g LIBFLAGS: -L. RLD_FLAG: -Xlinker -rpath -Xlinker /part2/gcc/install-3/lib/octave-2.1.31 TERMLIBS: -lncurses LIBS: -ldl -lz -lm LEXLIB: LIBPLPLOT: LIBDLFCN: LIBGLOB: ./glob/glob.o ./glob/fnmatch.o DEFS: -DOCTAVE_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -DUSE_READLINE=1 -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DHAVE_LIBM=1 -DHAVE_LIBZ=1 -DF77_APPEND_UNDERSCORE=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_GLOB_H=1 -DHAVE_GRP_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NAN_H=1 -DHAVE_PWD_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_TERMIO_H=1 -DHAVE_UNISTD_H=1 -DHAVE_VARARGS_H=1 -DHAVE_ATEXIT=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWNAM=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_PUTENV=1 -DHAVE_READLINK=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DWITH_DL=1 -DWITH_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_ST_BLOCKS=1 -DHAVE_ST_RDEV=1 -DHAVE_TZNAME=1 -DHAVE_GR_PASSWD=1 -DRETSIGTYPE=void -DSYS_SIGLIST_DECLARED=1 -DHAVE_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DGNUPLOT_HAS_MULTIPLOT=1 -DGNUPLOT_HAS_FRAMES=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = "emacs" EXEC_PATH = ":/part2/gcc/install-3/bin:/usr/local/bin:/bin:/usr/bin:/usr/texmf/bin:/usr/bin/X11:/usr/net/bin:/usr/games/bin:/home/john/mach4/bin:/usr/local/pgsql/bin/:.:/home/john/brlcad/linux/usr/brlcad/bin:/usr/local/samba/bin" IMAGEPATH = ".:/part2/gcc/install-3/share/octave/2.1.31/imagelib//" INFO_FILE = "/usr/local/info/octave.info" INFO_PROGRAM = "info" LOADPATH = ":" PAGER = "less -e" PS1 = "\\s:\\#> " PS2 = "> " PS4 = "+ " automatic_replot = 0 beep_on_error = 0 completion_append_char = " " default_eval_print_flag = 1 # default_global_variable_value = default_return_value = [] default_save_format = "ascii" define_all_return_values = 0 do_fortran_indexing = 0 echo_executing_commands = 0 empty_list_elements_ok = "warn" fixed_point_format = 0 gnuplot_binary = "gnuplot" gnuplot_command_end = "\n" gnuplot_command_plot = "pl" gnuplot_command_replot = "rep" gnuplot_command_splot = "sp" gnuplot_command_title = "t" gnuplot_command_using = "u" gnuplot_command_with = "w" gnuplot_has_frames = 1 gnuplot_has_multiplot = 1 history_file = "/home/john/.octave_hist" history_size = 1024 ignore_function_time_stamp = "system" implicit_num_to_str_ok = 0 implicit_str_to_num_ok = 0 initialize_global_variables = 0 max_recursion_depth = 256 ok_to_lose_imaginary_part = "warn" output_max_field_width = 10 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 prefer_column_vectors = 1 print_answer_id_name = 1 print_empty_dimensions = 1 print_rhs_assign_val = 0 propagate_empty_matrices = 1 resize_on_range_error = 1 return_last_computed_value = 0 save_precision = 15 saving_history = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = " " struct_levels_to_print = 2 suppress_verbose_help_message = 0 treat_neg_dim_as_zero = 0 warn_assign_as_truth_value = 1 warn_divide_by_zero = 1 warn_function_name_clash = 1 warn_future_time_stamp = 1 warn_missing_semicolon = 0 warn_variable_switch_label = 0 whitespace_in_literal_matrix = From octave-maintainers-request@bevo.che.wisc.edu Thu Dec 14 01:56:06 2000 Resent-Date: Thu, 14 Dec 2000 01:56:06 -0600 (CST) From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14904.32008.262436.667778@foobar.bogus.domain> Date: Thu, 14 Dec 2000 01:55:52 -0600 To: john Cc: octave-maintainers@bevo.che.wisc.edu Subject: Unidentified subject! In-Reply-To: <200012092059.UAA26577@arrows.demon.co.uk> References: <200012092059.UAA26577@arrows.demon.co.uk> X-Mailer: VM 6.85 under Emacs 20.7.2 Resent-Message-ID: <6Cjq2MeBBP.A.0UC.W0HO6@bahaha.che.wisc.edu> Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu On 9-Dec-2000, john wrote: | To: octave-maintainers@bevo.che.wisc.edu | Cc: | Subject: Octave from Recent CVS: Segmentation fault | | Bug report for Octave 2.1.31 configured for %OCTAVE_CANONICAL_HOST_TYPE% | (CVS 9 December 2000) | | Description: | ----------- | | The following not at all useful code causes a Segmentation fault: | | arrow2 [544] octave | GNU Octave, version 2.1.31 (i586-pc-linux-gnulibc1). | Copyright (C) 1996, 1997, 1998, 1999, 2000 John W. Eaton. | This is free software with ABSOLUTELY NO WARRANTY. | For details, type `warranty'. | | *** This is a development version of Octave. Development releases | *** are provided for people who want to help test, debug, and improve | *** Octave. | *** | *** If you want a stable, well-tested version of Octave, you should be | *** using one of the stable releases (when this development release | *** was made, the latest stable version was 2.0.16). | | INFO_FILE = /usr/local/info/octave.info | octave:1> xx = linspace(-3,10)'; | octave:2> xx / (pi+xx) | panic: Segmentation fault -- stopping myself... | attempting to save variables to `octave-core'... | save to `octave-core' complete | Segmentation fault For cases like this, Octave eventually calls dgelss from Lapack. The crash was happening inside dgemm, but it looks like a bug in Lapack that can cause the bounds of a work array to be exceeded. I checked netlib and the development version of Octave seems to have the latest Lapack routines, so I don't think this problem has been fixed in the Lapack code that is currently being distributed netlib. Anyway, my best guess at a fix is appended. Thanks, jwe 2000-12-14 John W. Eaton * lapack/dgelss.f (DGELSS): Use correct leading dimension for workspace array passed to dgemm and dlacpy. (ZGELSS): Likewise, for calls to zgemm and zlacpy. Index: dgelss.f =================================================================== RCS file: /usr/local/cvsroot/octave/libcruft/lapack/dgelss.f,v retrieving revision 1.3 diff -u -r1.3 dgelss.f --- dgelss.f 2000/02/10 09:26:48 1.3 +++ dgelss.f 2000/12/14 07:45:56 @@ -491,8 +491,8 @@ DO 40 I = 1, NRHS, CHUNK BL = MIN( NRHS-I+1, CHUNK ) CALL DGEMM( 'T', 'N', M, BL, M, ONE, WORK( IL ), LDWORK, - $ B( 1, I ), LDB, ZERO, WORK( IWORK ), N ) - CALL DLACPY( 'G', M, BL, WORK( IWORK ), N, B( 1, I ), + $ B( 1, I ), LDB, ZERO, WORK( IWORK ), M ) + CALL DLACPY( 'G', M, BL, WORK( IWORK ), M, B( 1, I ), $ LDB ) 40 CONTINUE ELSE Index: zgelss.f =================================================================== RCS file: /usr/local/cvsroot/octave/libcruft/lapack/zgelss.f,v retrieving revision 1.3 diff -u -r1.3 zgelss.f --- zgelss.f 2000/02/10 09:26:50 1.3 +++ zgelss.f 2000/12/14 07:46:02 @@ -512,8 +512,8 @@ DO 40 I = 1, NRHS, CHUNK BL = MIN( NRHS-I+1, CHUNK ) CALL ZGEMM( 'C', 'N', M, BL, M, CONE, WORK( IL ), LDWORK, - $ B( 1, I ), LDB, CZERO, WORK( IWORK ), N ) - CALL ZLACPY( 'G', M, BL, WORK( IWORK ), N, B( 1, I ), + $ B( 1, I ), LDB, CZERO, WORK( IWORK ), M ) + CALL ZLACPY( 'G', M, BL, WORK( IWORK ), M, B( 1, I ), $ LDB ) 40 CONTINUE ELSE From octave-maintainers-request@bevo.che.wisc.edu Sun Dec 17 05:34:29 2000 Resent-Date: Sun, 17 Dec 2000 05:34:29 -0600 (CST) From: Etienne Grossmann To: octave-sources@bevo.che.wisc.edu, octave-maintainers@bevo.che.wisc.edu Subject: patch : [...] = leval(name, list) CC: etienne@isr.ist.utl.pt Reply-to: etienne@isr.ist.utl.pt User-Agent: WEMI/1.13.7 (Shimada) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386-debian-linux-gnu) (with unibyte mode) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: multipart/mixed; boundary="Multipart_Sun_Dec_17_11:40:13_2000-1" Message-Id: Date: Sun, 17 Dec 2000 11:40:14 +0000 Resent-Message-ID: Resent-From: octave-maintainers@bevo.che.wisc.edu X-Mailing-List: X-Loop: octave-maintainers@bevo.che.wisc.edu Precedence: list Resent-Sender: octave-maintainers-request@bevo.che.wisc.edu Sender: octave-maintainers-request@bevo.che.wisc.edu --Multipart_Sun_Dec_17_11:40:13_2000-1 Content-Type: text/plain; charset=US-ASCII Hello, I got convinced that a function [...] = leval(name, list) offers more flexibility than [...] = feval(name, arg1,...,argn). For example, such a function is useful for minimization of a function that takes many arguments. I first implemented it as a leval.m which works fine, but puts an overhead of ~4ms (PII,350MHz), which I think is too much (there may be hundreds of calls to it). It turns out that "leval" is very simple to implement as a built-in: see the patch (against 2.1.32) below. It works fine : I append a test script too. Run it after setting "verbose=1". Does that patch meet the coding standards? Etienne ====================================================================== --Multipart_Sun_Dec_17_11:40:13_2000-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="parse.leval.patch" Content-Transfer-Encoding: 7bit --- parse.cc.orig Sun Dec 17 10:45:13 2000 +++ parse.cc Sun Dec 17 10:47:15 2000 @@ -4836,6 +4836,50 @@ return retval; } + +DEFUN (leval, args, nargout, + "-*- texinfo -*-\n\ +@deftypefn {Built-in Function} {} leval (@var{name}, @var{list})\n\ +Evaluate the function named @var{name}. All the elements in @var{list}\n\ +are passed on to the named function. For example,\n\ +\n\ +@example\n\ +leval (\"acos\", list (-1))\n\ + @result{} 3.1416\n\ +@end example\n\ +\n\ +@noindent\n\ +calls the function @code{acos} with the argument @samp{-1}.\n\ +\n\ +The function @code{leval} provides provides more flexibility than\n\ +@code{feval} since arguments need not be hard-wired in the calling \n\ +code. @seealso{feval and eval}\n\ +@end deftypefn") +{ + octave_value_list retval; + + int nargin = args.length (); + + if (nargin == 2) + { + std::string name = args(0).string_value (); + if (error_state) + error ("leval: first argument must be a string"); + + octave_value_list lst = args(1).list_value (); + if (error_state) + error ("leval: second argument must be a list"); + + retval = feval (name, lst, nargout); + + } + else + print_usage ("leval"); + + return retval; +} + + octave_value_list eval_string (const std::string& s, bool silent, int& parse_status, int nargout) { --Multipart_Sun_Dec_17_11:40:13_2000-1 Content-Type: text/plain; charset=US-ASCII ====================================================================== --Multipart_Sun_Dec_17_11:40:13_2000-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="test_leval.m" Content-Transfer-Encoding: 7bit ok = 1; if !exist ("verbose"), verbose = 0; end function [a,b,c] = f(x,y), a=1; b=x; c=y; end l = list (2,3); [a,b,c] = leval ("f",l); if a!=1 || b!=2 || c!=3, if verbose, printf ("test_leval : not ok\n"); end ok = 0; else if verbose, printf ("test_leval : ok\n"); end end [a,b] = leval ("f",l); if a!=1 || b!=2, if verbose, printf ("test_leval : not ok\n"); end ok = 0; else if verbose, printf ("test_leval : ok\n"); end end a = leval ("f",l); if a!=1, if verbose, printf ("test_leval : not ok\n"); end ok = 0; else if verbose, printf ("test_leval : ok\n"); end end if ok && verbose, ntest = 1000; printf ("For %i function calls\n",ntest); mytic (); for i = 1:ntest, [a,b,c] = f(2,3); end t1 = mytic (); mytic (); for i = 1:ntest, [a,b,c] = leval ("f",l); end t2 = mytic (); mytic (); for i = 1:ntest, [a,b,c] = feval ("f",2,3); end t3 = mytic (); printf ("time : plain : %8.3g, leval : %8.3g, feval : %8.3g (sec)\n",\ t1,t2,t3); printf ("overhead for leval : %8.3g seconds per call\n",(t2-t1)/ntest); printf ("overhead for feval : %8.3g seconds per call\n",(t3-t1)/ntest); end --Multipart_Sun_Dec_17_11:40:13_2000-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Sun_Dec_17_11:40:13_2000-1--