From maintainers-request@octave.org Wed Sep 1 09:32:22 2004 Resent-Date: Wed, 1 Sep 2004 09:31:55 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16693.56626.103348.399610@devzero.bogus.domain> Date: Wed, 1 Sep 2004 10:31:14 -0400 To: Quentin Spencer Cc: maintainers@octave.org Subject: MATLAB load/save changes In-Reply-To: <41236496.5010909@ieee.org> References: <41236496.5010909@ieee.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 18-Aug-2004, Quentin Spencer wrote: | I'm not sure whether to report this as a bug or just as an FYI to the | maintainers, so I'm posting it to both. Back in March, John sent out a | list of new features listed as new in the then-upcoming MATLAB 7. I've | just run into a load/save incompatibility that wasn't in that list. | Trying to load a file saved in MATLAB 7, I got an error. In the | documentation for MATLAB's save function, I found the following: | | By default, MAT-files created with SAVE are compressed and char | arrays are | encoded using Unicode. These MAT-files cannot be loaded into versions of | MATLAB prior to MATLAB 7.0. The -V6 option disables these features and | allows saved MAT-files to load into older versions of MATLAB. To disable | these features by default, modify the settings in the General->MAT-Files | preferences panel, accessible via the File->Preferences menu item. With | compression enabled, saving data that does not compress well takes | longer. In this case, the -V6 option may be preferable. | | The file in question didn't have any char arrays, so I suspect it was | the compression that tripped it up. I looked briefly at the file format | document on their web site: | | http://www.mathworks.com/access/helpdesk/help/pdf_doc/matlab/matfile_format.pdf | It looks like it's all documented--they are using gzip compression on | each variable. Thanks for the pointer. I think Octave should handle the new file format, but it is a low priority project for me right now. If someone else can contribute the code, that would be helpful. Since you apparently have access to Matlab 7.0, can you tell us whether int8(5) / int8(3) returns int8(1) or int8(2)? Thanks, jwe From maintainers-request@octave.org Wed Sep 1 09:51:07 2004 Resent-Date: Wed, 1 Sep 2004 09:51:06 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <3EE2ABBCFEA761449CF76DF1BB73E1C516BAB6@pusehe0o.eh.pweh.com> From: "Hall, Benjamin" To: maintainers@octave.org Cc: "'John W. Eaton'" , Quentin Spencer Subject: RE: MATLAB load/save changes Date: Wed, 1 Sep 2004 10:43:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Scanned-By: MIMEDefang 2.39 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org >> a = int8(5)/int8(3) a = 2 >> whos Name Size Bytes Class a 1x1 1 int8 array ans 1x1 1 int8 array Grand total is 2 elements using 2 bytes -----Original Message----- From: John W. Eaton [mailto:jwe@bevo.che.wisc.edu] Sent: Wednesday, September 01, 2004 10:31 AM To: Quentin Spencer Cc: maintainers@octave.org Subject: MATLAB load/save changes On 18-Aug-2004, Quentin Spencer wrote: | I'm not sure whether to report this as a bug or just as an FYI to the | maintainers, so I'm posting it to both. Back in March, John sent out a | list of new features listed as new in the then-upcoming MATLAB 7. I've | just run into a load/save incompatibility that wasn't in that list. | Trying to load a file saved in MATLAB 7, I got an error. In the | documentation for MATLAB's save function, I found the following: | | By default, MAT-files created with SAVE are compressed and char | arrays are | encoded using Unicode. These MAT-files cannot be loaded into versions of | MATLAB prior to MATLAB 7.0. The -V6 option disables these features and | allows saved MAT-files to load into older versions of MATLAB. To disable | these features by default, modify the settings in the General->MAT-Files | preferences panel, accessible via the File->Preferences menu item. With | compression enabled, saving data that does not compress well takes | longer. In this case, the -V6 option may be preferable. | | The file in question didn't have any char arrays, so I suspect it was | the compression that tripped it up. I looked briefly at the file format | document on their web site: | | http://www.mathworks.com/access/helpdesk/help/pdf_doc/matlab/matfile_format. pdf | It looks like it's all documented--they are using gzip compression on | each variable. Thanks for the pointer. I think Octave should handle the new file format, but it is a low priority project for me right now. If someone else can contribute the code, that would be helpful. Since you apparently have access to Matlab 7.0, can you tell us whether int8(5) / int8(3) returns int8(1) or int8(2)? Thanks, jwe From maintainers-request@octave.org Wed Sep 1 12:31:21 2004 Resent-Date: Wed, 1 Sep 2004 12:31:21 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 1 Sep 2004 13:30:02 -0400 (EDT) Message-Id: <200409011730.NAA74411@jazz.ncnr.nist.gov> From: Przemek Klosowski To: maintainers@octave.org In-reply-to: <20040830140511.GL2518@zfr01-2089.crm.mot.com> (message from David Bateman on Mon, 30 Aug 2004 16:05:11 +0200) Subject: Re: {Spam?} zeros, ones, eye with integer type args... References: <20040830140511.GL2518@zfr01-2089.crm.mot.com> X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HOT_NASTY autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org This is rather off topic, but you may find it amusing. As you can see in the subject, David's recent patch was labeled as spam by our mail server. Specifically, it the HOT_NASTY module gave it a perfect 10.0! I am wondering which words caused it: - kron ? - matrix ? - single ? - commune ? - classes ? :) - XXX FIXME XXX ? Between indecency filters and terrorism filters, one has to watch one's words... :) From maintainers-request@octave.org Wed Sep 1 13:36:19 2004 Resent-Date: Wed, 1 Sep 2004 13:36:13 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16694.5545.420400.350805@devzero.bogus.domain> Date: Wed, 1 Sep 2004 14:32:09 -0400 To: octave maintainers mailing list Subject: integer artithmetic X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org What should we do for things like int16(0) / int16(0) or Inf * int16(0) ? If both arguments are double, these operations genrate NaNs. What should Octave do, given the constraint that the result should be an int16 object (at least I believe that's the rule that we have to follow for compatibility)? Should the result be int16(0)? Can someone who has Matlab R14 say what it does? Thanks, jwe From maintainers-request@octave.org Wed Sep 1 13:57:51 2004 Resent-Date: Wed, 1 Sep 2004 13:57:51 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <3EE2ABBCFEA761449CF76DF1BB73E1C516BABE@pusehe0o.eh.pweh.com> From: "Hall, Benjamin" To: "'John W. Eaton'" , "'octave maintainers mailing list'" Subject: RE: integer artithmetic Date: Wed, 1 Sep 2004 14:42:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Scanned-By: MIMEDefang 2.39 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Here's R14 results: >> a = int16(0)/int16(0) Warning: Divide by zero. a = 0 >> b = Inf*int16(0) b = 0 >> whos Name Size Bytes Class a 1x1 2 int16 array ans 1x1 2 int16 array b 1x1 2 int16 array Grand total is 3 elements using 6 bytes -----Original Message----- From: John W. Eaton [mailto:jwe@bevo.che.wisc.edu] Sent: Wednesday, September 01, 2004 2:32 PM To: octave maintainers mailing list Subject: integer artithmetic What should we do for things like int16(0) / int16(0) or Inf * int16(0) ? If both arguments are double, these operations genrate NaNs. What should Octave do, given the constraint that the result should be an int16 object (at least I believe that's the rule that we have to follow for compatibility)? Should the result be int16(0)? Can someone who has Matlab R14 say what it does? Thanks, jwe From maintainers-request@octave.org Wed Sep 1 14:04:20 2004 Resent-Date: Wed, 1 Sep 2004 14:04:19 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16694.7435.825168.250813@devzero.bogus.domain> Date: Wed, 1 Sep 2004 15:03:39 -0400 To: "Hall, Benjamin" Cc: "'octave maintainers mailing list'" Subject: RE: integer artithmetic In-Reply-To: <3EE2ABBCFEA761449CF76DF1BB73E1C516BABE@pusehe0o.eh.pweh.com> References: <3EE2ABBCFEA761449CF76DF1BB73E1C516BABE@pusehe0o.eh.pweh.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: <4te_MC.A.XqG.z0hNBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 1-Sep-2004, Hall, Benjamin wrote: | Here's R14 results: | | >> a = int16(0)/int16(0) | Warning: Divide by zero. | | a = | | 0 | | >> b = Inf*int16(0) | | b = | | 0 OK, this is what I've done for Octave as well. Thanks, jwe From maintainers-request@octave.org Wed Sep 1 15:01:58 2004 Resent-Date: Wed, 1 Sep 2004 15:01:57 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 1 Sep 2004 21:54:30 +0200 From: David Bateman To: Przemek Klosowski Cc: maintainers@octave.org Subject: Re: {Spam?} zeros, ones, eye with integer type args... Message-ID: <20040901195430.GA5055@zfr01-2089.crm.mot.com> References: <20040830140511.GL2518@zfr01-2089.crm.mot.com> <200409011730.NAA74411@jazz.ncnr.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409011730.NAA74411@jazz.ncnr.nist.gov> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HOT_NASTY autolearn=no version=2.63 Resent-Message-ID: <2XNot.A.AVH.1qiNBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Hey its not often I score a perfect 10.... D. According to Przemek Klosowski (on 09/01/04): > > This is rather off topic, but you may find it amusing. > As you can see in the subject, David's recent patch was labeled > as spam by our mail server. Specifically, it the HOT_NASTY > module gave it a perfect 10.0! I am wondering which words caused it: > > - kron ? > - matrix ? > - single ? > - commune ? > - classes ? :) > - XXX FIXME XXX ? > > Between indecency filters and terrorism filters, one has to watch > one's words... :) -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Thu Sep 2 00:32:24 2004 Resent-Date: Thu, 2 Sep 2004 00:32:22 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16694.45117.495992.854642@devzero.bogus.domain> Date: Thu, 2 Sep 2004 01:31:41 -0400 To: octave maintainers mailing list Subject: Octave 2.1.58 available for ftp X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Octave 2.1.58 is now available for ftp from ftp.octave.org in the directory /pub/octave/bleeding-edge: -rw-r--r-- 1 1005 5446553 Sep 2 04:06 octave-2.1.58.tar.gz -rw-r--r-- 1 1005 4249914 Sep 2 04:06 octave-2.1.58.tar.bz2 -rw-r--r-- 1 1005 285012 Sep 2 04:08 octave-2.1.57-2.1.58.patch.gz -rw-r--r-- 1 1005 225593 Sep 2 04:08 octave-2.1.57-2.1.58.patch.bz2 5952e00626894997443dfb463ed4bd46 octave-2.1.58.tar.gz 769a1ff3a27e411ffe3cf8930ea126c2 octave-2.1.58.tar.bz2 c15c76fd944a99c2354cacd7fbf349db octave-2.1.57-2.1.58.patch.gz dd12e5d39e8d61264661776552592015 octave-2.1.57-2.1.58.patch.bz2 Thanks to David Bateman for all his hard work to get this snapshot ready. This version includes many new features, including integer data types, inline functions, function handles, concatenation of structs, cell arrays and user-defined types, and better compatibility with the leading brand. Although I believe that 2.1.58 will be quite useable, there have been many changes and experience says that any number of unexpected problems could show up just after the tar file hits the ftp site, so 2.1.57 remains the recommended version for now. As always, if your favorite bug is still not fixed, please report it. jwe From maintainers-request@octave.org Thu Sep 2 02:30:38 2004 Resent-Date: Thu, 2 Sep 2004 02:30:33 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 2 Sep 2004 09:26:48 +0200 From: David Bateman To: octave maintainers mailing list Subject: Re: Octave 2.1.58 available for ftp Message-ID: <20040902072648.GE5055@zfr01-2089.crm.mot.com> References: <16694.45117.495992.854642@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16694.45117.495992.854642@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org For those who want to build octave-forge with this, you'll need the octave-forge CVS, particularly for my stuff :-) D. According to John W. Eaton (on 09/02/04): > Octave 2.1.58 is now available for ftp from ftp.octave.org in the > directory /pub/octave/bleeding-edge: > > -rw-r--r-- 1 1005 5446553 Sep 2 04:06 octave-2.1.58.tar.gz > -rw-r--r-- 1 1005 4249914 Sep 2 04:06 octave-2.1.58.tar.bz2 > -rw-r--r-- 1 1005 285012 Sep 2 04:08 octave-2.1.57-2.1.58.patch.gz > -rw-r--r-- 1 1005 225593 Sep 2 04:08 octave-2.1.57-2.1.58.patch.bz2 > > 5952e00626894997443dfb463ed4bd46 octave-2.1.58.tar.gz > 769a1ff3a27e411ffe3cf8930ea126c2 octave-2.1.58.tar.bz2 > c15c76fd944a99c2354cacd7fbf349db octave-2.1.57-2.1.58.patch.gz > dd12e5d39e8d61264661776552592015 octave-2.1.57-2.1.58.patch.bz2 > > Thanks to David Bateman for all his hard work to get this snapshot > ready. > > This version includes many new features, including integer data types, > inline functions, function handles, concatenation of structs, cell > arrays and user-defined types, and better compatibility with the > leading brand. > > Although I believe that 2.1.58 will be quite useable, there have been > many changes and experience says that any number of unexpected problems > could show up just after the tar file hits the ftp site, so 2.1.57 > remains the recommended version for now. > > As always, if your favorite bug is still not fixed, please report it. > > jwe -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Thu Sep 2 14:41:49 2004 Resent-Date: Thu, 2 Sep 2004 14:41:25 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 2 Sep 2004 15:40:07 -0400 (EDT) Message-Id: <200409021940.PAA16722@jazz.ncnr.nist.gov> From: Przemek Klosowski To: octave maintainers mailing list In-reply-to: <20040902072648.GE5055@zfr01-2089.crm.mot.com> (message from David Bateman on Thu, 2 Sep 2004 09:26:48 +0200) Subject: Re: Octave 2.1.58 available for ftp References: <16694.45117.495992.854642@devzero.bogus.domain> <20040902072648.GE5055@zfr01-2089.crm.mot.com> X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org With the latest octave (2.1.58), 'a=1; a(2)=2' returns 'a=1 2', as always; but 'b=int8(1);b(2)=2' results in an error: operator =: no conversion for assignment of 'scalar' to indexed 'int8 scalar' The similar error happens for int16 and int32. From maintainers-request@octave.org Thu Sep 2 21:01:26 2004 Resent-Date: Thu, 2 Sep 2004 21:01:08 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 2 Sep 2004 21:00:19 -0500 From: Dirk Eddelbuettel To: David Bateman Cc: octave maintainers mailing list Subject: Re: Octave 2.1.58 available for ftp Message-ID: <20040903020019.GA27506@sonny.eddelbuettel.com> References: <16694.45117.495992.854642@devzero.bogus.domain> <20040902072648.GE5055@zfr01-2089.crm.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040902072648.GE5055@zfr01-2089.crm.mot.com> User-Agent: Mutt/1.3.28i X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On Thu, Sep 02, 2004 at 09:26:48AM +0200, David Bateman wrote: > > For those who want to build octave-forge with this, you'll need the > octave-forge CVS, particularly for my stuff :-) Is a new octave-forge release planned? Or shall I grab from CVS and call it a Debian release? Dirk, who uploaded 2.1.58 to Debian an hour ago -- Those are my principles, and if you don't like them... well, I have others. -- Groucho Marx From maintainers-request@octave.org Fri Sep 3 05:16:55 2004 Resent-Date: Fri, 3 Sep 2004 05:16:55 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 3 Sep 2004 12:12:55 +0200 From: David Bateman To: Przemek Klosowski Cc: octave maintainers mailing list Subject: Re: Octave 2.1.58 available for ftp Message-ID: <20040903101255.GH15418@zfr01-2089.crm.mot.com> References: <16694.45117.495992.854642@devzero.bogus.domain> <20040902072648.GE5055@zfr01-2089.crm.mot.com> <200409021940.PAA16722@jazz.ncnr.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200409021940.PAA16722@jazz.ncnr.nist.gov> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Yes, my matlab R12 copy works like this... This is a bit of a pain though as the subsasgn function for the integer types is inherited from octave_base_matrix. This means that a new version of subsasgn need to be written for the ov-base-int.cc that check first if the class is double and treat it one way and if not as it is currently treated... D. Daprès Przemek Klosowski (le 02/09/2004): > > With the latest octave (2.1.58), 'a=1; a(2)=2' returns 'a=1 2', as > always; but 'b=int8(1);b(2)=2' results in an error: > > operator =: no conversion for assignment of 'scalar' to indexed 'int8 scalar' > > The similar error happens for int16 and int32. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Fri Sep 3 05:30:25 2004 Resent-Date: Fri, 3 Sep 2004 05:30:25 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 3 Sep 2004 12:28:31 +0200 From: David Bateman To: Dirk Eddelbuettel Cc: David Bateman , octave maintainers mailing list Subject: Re: Octave 2.1.58 available for ftp Message-ID: <20040903102831.GI15418@zfr01-2089.crm.mot.com> References: <16694.45117.495992.854642@devzero.bogus.domain> <20040902072648.GE5055@zfr01-2089.crm.mot.com> <20040903020019.GA27506@sonny.eddelbuettel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040903020019.GA27506@sonny.eddelbuettel.com> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <17A02C.A.M2.BfEOBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Daprès Dirk Eddelbuettel (le 03/09/2004): > On Thu, Sep 02, 2004 at 09:26:48AM +0200, David Bateman wrote: > > > > For those who want to build octave-forge with this, you'll need the > > octave-forge CVS, particularly for my stuff :-) > > Is a new octave-forge release planned? Or shall I grab from CVS and call it > a Debian release? > > Dirk, who uploaded 2.1.58 to Debian an hour ago Paul is talking about it on the octave-forge list... D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Fri Sep 3 10:44:07 2004 Resent-Date: Fri, 3 Sep 2004 10:43:51 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16696.37127.500368.686063@devzero.bogus.domain> Date: Fri, 3 Sep 2004 11:43:03 -0400 To: David Bateman Cc: Przemek Klosowski , octave maintainers mailing list Subject: Re: Octave 2.1.58 available for ftp In-Reply-To: <20040903101255.GH15418@zfr01-2089.crm.mot.com> References: <16694.45117.495992.854642@devzero.bogus.domain> <20040902072648.GE5055@zfr01-2089.crm.mot.com> <200409021940.PAA16722@jazz.ncnr.nist.gov> <20040903101255.GH15418@zfr01-2089.crm.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 3-Sep-2004, David Bateman wrote: | Yes, my matlab R12 copy works like this... This is a bit of a pain | though as the subsasgn function for the integer types is inherited | from octave_base_matrix. This means that a new version of subsasgn | need to be written for the ov-base-int.cc that check first if the | class is double and treat it one way and if not as it is currently | treated... I think it can all be handled by defining appropriate type conversions. Please try the following patch. After applying the patch, here are some tests to run. They should all print "ans = 1" for success. 1; function r = check (x, t) r = strcmp (typeinfo (x), t); endfunction x = i; x(2) = int8(2); check (x, "complex matrix") x = i; x(2:3,2:3) = int8(2); check (x, "complex matrix") x = i; x(2:3,2:3) = eye (2, "int8"); check (x, "complex matrix") x = i * eye(2); x(2) = int8(2); check (x, "complex matrix") x = i * eye(2); x(2:3,2:3) = int8(2); check (x, "complex matrix") x = i * eye(2); x(2:3,2:3) = eye (2, "int8"); check (x, "complex matrix") x = 1; x(2) = int8(2); check (x, "matrix") x = 1; x(2:3,2:3) = int8(2); check (x, "matrix") x = 1; x(2:3,2:3) = eye (2, "int8"); check (x, "matrix") x = eye(2); x(2) = int8(2); check (x, "matrix") x = eye(2); x(2:3,2:3) = int8(2); check (x, "matrix") x = eye(2); x(2:3,2:3) = eye (2, "int8"); check (x, "matrix") x = int8(1); x(2) = 2; check (x, "int8 matrix") x = int8(1); x(2) = i; check (x, "complex matrix") x = int8(1); x(2:3,2:3) = i; check (x, "complex matrix") x = int8(1); x(2:3,2:3) = i * eye (2); check (x, "complex matrix") x = int8(1); x(2) = int16(2); check (x, "int8 matrix") x = int8(1); x(2:3,2:3) = int16(2); check (x, "int8 matrix") x = int8(1); x(2:3,2:3) = eye (2, "int16"); check (x, "int8 matrix") x = int8(1); x(2) = double(2); check (x, "int8 matrix") x = int8(1); x(2:3,2:3) = double(2); check (x, "int8 matrix") x = int8(1); x(2:3,2:3) = eye (2, "double"); check (x, "int8 matrix") x = int8(1); x(2) = 2; check (x, "int8 matrix") x = eye(2, "int8"); x(2) = i; check (x, "complex matrix") x = eye (2, "int8"); x(2:3,2:3) = i; check (x, "complex matrix") x = eye (2, "int8"); x(2:3,2:3) = i * eye (2); check (x, "complex matrix") x = eye (2, "int8"); x(2) = int16(2); check (x, "int8 matrix") x = eye (2, "int8"); x(2:3,2:3) = int16(2); check (x, "int8 matrix") x = eye (2, "int8"); x(2:3,2:3) = eye (2, "int16"); check (x, "int8 matrix") x = eye (2, "int8"); x(2) = double(2); check (x, "int8 matrix") x = eye (2, "int8"); x(2:3,2:3) = double(2); check (x, "int8 matrix") x = eye (2, "int8"); x(2:3,2:3) = eye (2, "double"); check (x, "int8 matrix") Note that things like x = int8(1); x(2) = int16(2); x = int8(1); x(2) = double(2); and convert the wider RHS to the narrower LHS type, but x = int8(1); x(2) = i; converts x to a double precision complex matrix. This happens because Octave has no integer complex types (Matlab does, so it converts X in the above to a complex int8 matrix). I thought it best to convert to complex, even if we can't preserve the int8 attribute. Thanks, jwe liboctave/ChangeLog: 2004-09-03 John W. Eaton * oct-inttypes.h (octave_fit_to_range): Use constructor instead of static_cast for type conversion. 2004-09-03 John W. Eaton * OPERATORS/op-int.h (OCTAVE_MS_INT_OPS): Don't define indexed int matrix = complex scalar assignment ops. (OCTAVE_MS_INT_OPS): Don't define indexed int matrix = complex matrix assignment ops. (OCTAVE_SM_CONV): New macro. (OCTAVE_SM_INT_OPS): Use it to define int scalar -> (int|complex) matrix widening ops. (OCTAVE_RE_INT_ASSIGN_OPS, OCTAVE_CX_INT_ASSIGN_OPS): New macros. (OCTAVE_INT_OPS): Use them here. (OCTAVE_INSTALL_SS_INT_OPS): Install indexed int scalar = scalar and indexed int scalar = complex scalar assignment conversions. (OCTAVE_INSTALL_SM_INT_OPS): Install int scalar -> (int|complex) matrix widening ops. Install indexed int scalar = (int|real|complex) matrix assignment conversions. (OCTAVE_INSTALL_MS_INT_OPS): Install indexed int matrix = complex scalar assignment conversion. (OCTAVE_INSTALL_MM_INT_OPS): Install int matrix -> complex matrix widening op. Install indexed int matrix = complex matrix assignment conversion. (OCTAVE_INSTALL_RE_INT_ASSIGN_OPS, OCTAVE_INSTALL_CX_INT_ASSIGN_OPS): New macros. (OCTAVE_INSTALL_INT_OPS): Use them. * op-int.h: (OCTAVE_INSTALL_SM_INT_ASSIGNCONV): New macro. * OPERATORS/op-i8-i8.cc, OPERATORS/op-i16-i16.cc, OPERATORS/op-i32-i32.cc, OPERATORS/op-i64-i64.cc, OPERATORS/op-ui8-ui8.cc, OPERATORS/op-ui16-ui16.cc, OPERATORS/op-ui32-ui32.cc, OPERATORS/op-ui64-ui64.cc: Use it to define mixed size integer scalar/integer matrix assignment conversions. * ov-intx.h (OCTAVE_VALUE_INT_MATRIX_T::complex_array_value, OCTAVE_VALUE_INT_SCALAR_T::complex_array_vale): New functions. Index: liboctave/oct-inttypes.h =================================================================== RCS file: /usr/local/cvsroot/octave/liboctave/oct-inttypes.h,v retrieving revision 1.10 diff -u -r1.10 oct-inttypes.h --- a/liboctave/oct-inttypes.h 1 Sep 2004 21:10:28 -0000 1.10 +++ b/liboctave/oct-inttypes.h 3 Sep 2004 15:22:02 -0000 @@ -133,7 +133,7 @@ inline T2 octave_int_fit_to_range (const T1& x, const T2& mn, const T2& mx) { - return (x > mx ? mx : (x < mn ? mn : static_cast (x))); + return (x > mx ? mx : (x < mn ? mn : T2 (x))); } // If X is unsigned and the new type is signed, then we only have to Index: src/ov-intx.h =================================================================== RCS file: /usr/local/cvsroot/octave/src/ov-intx.h,v retrieving revision 1.5 diff -u -r1.5 ov-intx.h --- a/src/ov-intx.h 31 Aug 2004 05:30:47 -0000 1.5 +++ b/src/ov-intx.h 3 Sep 2004 15:22:07 -0000 @@ -68,7 +68,17 @@ NDArray retval (matrix.dims ()); int nel = matrix.numel (); for (int i = 0; i < nel; i++) - retval (i) = double (matrix(i)); + retval(i) = double (matrix(i)); + return retval; + } + + ComplexNDArray + complex_array_value (bool = false) const + { + ComplexNDArray retval (matrix.dims ()); + int nel = matrix.numel (); + for (int i = 0; i < nel; i++) + retval(i) = Complex (matrix(i)); return retval; } @@ -123,7 +133,15 @@ array_value (bool = false) const { NDArray retval (dim_vector (1,1)); - retval (0) = double (scalar); + retval(0) = double (scalar); + return retval; + } + + ComplexNDArray + complex_array_value (bool = false) const + { + ComplexNDArray retval (dim_vector (1,1)); + retval(0) = Complex (scalar); return retval; } Index: src/OPERATORS/op-i16-i16.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-i16-i16.cc,v retrieving revision 1.3 diff -u -r1.3 op-i16-i16.cc --- a/src/OPERATORS/op-i16-i16.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-i16-i16.cc 3 Sep 2004 15:22:07 -0000 @@ -88,6 +88,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui32, int16_, uint32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi64, int16_, int64_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui64, int16_, uint64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int16, int8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int16, uint8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int16, uint16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int16, int32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int16, uint32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int16, int64); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int16, uint64); } /* Index: src/OPERATORS/op-i32-i32.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-i32-i32.cc,v retrieving revision 1.3 diff -u -r1.3 op-i32-i32.cc --- a/src/OPERATORS/op-i32-i32.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-i32-i32.cc 3 Sep 2004 15:22:07 -0000 @@ -88,6 +88,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui32, int32_, uint32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi64, int32_, int64_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui64, int32_, uint64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int32, int8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int32, uint8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int32, int16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int32, uint16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int32, uint32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int32, int64); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int32, uint64); } /* Index: src/OPERATORS/op-i64-i64.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-i64-i64.cc,v retrieving revision 1.3 diff -u -r1.3 op-i64-i64.cc --- a/src/OPERATORS/op-i64-i64.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-i64-i64.cc 3 Sep 2004 15:22:07 -0000 @@ -124,6 +124,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi32, int64_, int32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui32, int64_, uint32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui64, int64_, uint64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int64, int8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int64, uint8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int64, int16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int64, uint16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int64, int32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int64, uint32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int64, uint64); } /* Index: src/OPERATORS/op-i8-i8.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-i8-i8.cc,v retrieving revision 1.3 diff -u -r1.3 op-i8-i8.cc --- a/src/OPERATORS/op-i8-i8.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-i8-i8.cc 3 Sep 2004 15:22:07 -0000 @@ -88,6 +88,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui32, int8_, uint32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi64, int8_, int64_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui64, int8_, uint64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int8, uint8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int8, int16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int8, uint16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int8, int32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int8, uint32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int8, int64); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (int8, uint64); } /* Index: src/OPERATORS/op-int.h =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-int.h,v retrieving revision 1.4 diff -u -r1.4 op-int.h --- a/src/OPERATORS/op-int.h 1 Sep 2004 21:10:28 -0000 1.4 +++ b/src/OPERATORS/op-int.h 3 Sep 2004 15:22:08 -0000 @@ -215,6 +215,14 @@ return octave_value (result); \ } +#define OCTAVE_SM_CONV(TS, TM) \ + DEFCONV (TS ## s_ ## TM ## m_conv, TM ## scalar, TM ## matrix) \ + { \ + CAST_CONV_ARG (const octave_ ## TS ## scalar&); \ + \ + return new octave_ ## TM ## matrix (v.TM ## array_value ()); \ + } + #define OCTAVE_SM_INT_OPS(TYPE) \ OCTAVE_SM_POW_OPS (TYPE, TYPE) \ OCTAVE_SM_INT_ARITH_OPS (sm, TYPE ## _, TYPE ## _) \ @@ -223,13 +231,8 @@ OCTAVE_SM_INT_CMP_OPS (xm, , TYPE ## _) \ OCTAVE_SM_INT_BOOL_OPS (sm, TYPE ## _, TYPE ## _) \ OCTAVE_SM_INT_BOOL_OPS (xm, , TYPE ## _) \ - \ - /* DEFCONV (TYPE ## _matrix_conv, TYPE ## _scalar, TYPE ## _matrix) */ \ - /* { */ \ - /* CAST_CONV_ARG (const octave_ ## TYPE ## _scalar&); */ \ - /* */ \ - /* return new octave_ ## TYPE ## _matrix (v.TYPE ## _matrix_value ()); */ \ - /* } */ + OCTAVE_SM_CONV (TYPE ## _, TYPE ## _) \ + OCTAVE_SM_CONV (TYPE ## _, complex_) #define OCTAVE_SM_INT_OPS2(TS, TM) \ OCTAVE_SM_INT_ARITH_OPS (sm, TS, TM) \ @@ -323,8 +326,7 @@ OCTAVE_MS_INT_BOOL_OPS (ms, TYPE ## _, TYPE ## _) \ OCTAVE_MS_INT_BOOL_OPS (mx, TYPE ## _, ) \ OCTAVE_MS_INT_ASSIGN_OPS (ms, TYPE ## _, TYPE ## _, TYPE ## _) \ - OCTAVE_MS_INT_ASSIGN_OPS (mx, TYPE ## _, , ) \ - OCTAVE_MS_INT_ASSIGN_OPS (mc, TYPE ## _, complex_, ) + OCTAVE_MS_INT_ASSIGN_OPS (mx, TYPE ## _, , ) #define OCTAVE_M_INT_UNOPS(TYPE) \ /* matrix unary ops. */ \ @@ -420,20 +422,29 @@ OCTAVE_MM_INT_CMP_OPS (TYPE, TYPE) \ OCTAVE_MM_INT_BOOL_OPS (TYPE, TYPE) \ OCTAVE_MM_INT_ASSIGN_OPS (mm, TYPE ## _, TYPE ## _, TYPE ## _) \ - OCTAVE_MM_INT_ASSIGN_OPS (mmx, TYPE ## _, , ) \ - OCTAVE_MM_INT_ASSIGN_OPS (mmc, TYPE ## _, complex_, ) + OCTAVE_MM_INT_ASSIGN_OPS (mmx, TYPE ## _, , ) #define OCTAVE_MM_INT_OPS2(T1, T2) \ OCTAVE_MM_INT_ARITH_OPS (mm, T1, T2) \ OCTAVE_MM_INT_CMP_OPS (mm, T1, T2) \ OCTAVE_MM_INT_BOOL_OPS (mm, T1, T2) +#define OCTAVE_RE_INT_ASSIGN_OPS(TYPE) \ + DEFNDASSIGNOP_FN (TYPE ## ms_assign, matrix, TYPE ## _scalar, array, assign) \ + DEFNDASSIGNOP_FN (TYPE ## mm_assign, matrix, TYPE ## _matrix, array, assign) + +#define OCTAVE_CX_INT_ASSIGN_OPS(TYPE) \ + DEFNDASSIGNOP_FN (TYPE ## cms_assign, complex_matrix, TYPE ## _scalar, complex_array, assign) \ + DEFNDASSIGNOP_FN (TYPE ## cmm_assign, complex_matrix, TYPE ## _matrix, complex_array, assign) + #define OCTAVE_INT_OPS(TYPE) \ OCTAVE_SS_INT_OPS (TYPE) \ OCTAVE_SM_INT_OPS (TYPE) \ OCTAVE_MS_INT_OPS (TYPE) \ OCTAVE_MM_INT_OPS (TYPE) \ - OCTAVE_CONCAT_FN (TYPE) + OCTAVE_CONCAT_FN (TYPE) \ + OCTAVE_RE_INT_ASSIGN_OPS (TYPE) \ + OCTAVE_CX_INT_ASSIGN_OPS (TYPE) #define OCTAVE_INSTALL_S_INT_UNOPS(TYPE) \ INSTALL_UNOP (op_not, octave_ ## TYPE ## _scalar, s_not); \ @@ -479,7 +490,9 @@ OCTAVE_INSTALL_SS_INT_BOOL_OPS (ss, TYPE ## _, TYPE ## _) \ OCTAVE_INSTALL_SS_INT_BOOL_OPS (sx, TYPE ## _, ) \ OCTAVE_INSTALL_SS_INT_BOOL_OPS (xs, , TYPE ## _) \ - INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _matrix) + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _matrix) \ + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_scalar, octave_ ## TYPE ## _matrix) \ + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_complex_scalar, octave_complex_matrix) #define OCTAVE_INSTALL_SS_INT_OPS2(T1, T2) \ OCTAVE_INSTALL_SS_INT_ARITH_OPS (ss, T1, T2) \ @@ -517,8 +530,11 @@ OCTAVE_INSTALL_SM_INT_CMP_OPS (xm, , TYPE ## _) \ OCTAVE_INSTALL_SM_INT_BOOL_OPS (sm, TYPE ## _, TYPE ## _) \ OCTAVE_INSTALL_SM_INT_BOOL_OPS (xm, , TYPE ## _) \ - /* INSTALL_WIDENOP (octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _matrix, TYPE ## _matrix_conv); */ \ - INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _matrix, octave_ ## TYPE ## _matrix) + INSTALL_WIDENOP (octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _matrix, TYPE ## _matrix_conv) \ + INSTALL_WIDENOP (octave_ ## TYPE ## _scalar, octave_complex_matrix, complex_matrix_conv) \ + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_ ## TYPE ## _matrix, octave_ ## TYPE ## _matrix) \ + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_matrix, octave_ ## TYPE ## _matrix) \ + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _scalar, octave_complex_matrix, octave_complex_matrix) #define OCTAVE_INSTALL_SM_INT_OPS2(T1, T2) \ OCTAVE_INSTALL_SM_INT_ARITH_OPS (sm, T1, T2) \ @@ -562,7 +578,7 @@ OCTAVE_INSTALL_MS_INT_BOOL_OPS (mx, TYPE ## _, ) \ OCTAVE_INSTALL_MS_INT_ASSIGN_OPS (ms, TYPE ## _, TYPE ## _) \ OCTAVE_INSTALL_MS_INT_ASSIGN_OPS (mx, TYPE ## _, ) \ - OCTAVE_INSTALL_MS_INT_ASSIGN_OPS (mc, TYPE ## _, complex_) + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _matrix, octave_complex_scalar, octave_complex_matrix) #define OCTAVE_INSTALL_MS_INT_OPS2(T1, T2) \ OCTAVE_INSTALL_MS_INT_ARITH_OPS (ms, T1, T2) \ @@ -612,23 +628,41 @@ OCTAVE_INSTALL_MM_INT_BOOL_OPS (TYPE, TYPE) \ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mm, TYPE ## _, TYPE ## _) \ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmx, TYPE ## _, ) \ - OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmc, TYPE ## _, complex_) + INSTALL_WIDENOP (octave_ ## TYPE ## _matrix, octave_complex_matrix, complex_matrix_conv) \ + INSTALL_ASSIGNCONV (octave_ ## TYPE ## _matrix, octave_complex_matrix, octave_complex_matrix) #define OCTAVE_INSTALL_MM_INT_OPS2(T1, T2) \ OCTAVE_INSTALL_MM_INT_ARITH_OPS (T1, T2) \ OCTAVE_INSTALL_MM_INT_CMP_OPS (T1, T2) \ OCTAVE_INSTALL_MM_INT_BOOL_OPS (T1, T2) +#define OCTAVE_INSTALL_RE_INT_ASSIGN_OPS(TYPE) \ + INSTALL_ASSIGNOP (op_asn_eq, octave_matrix, octave_ ## TYPE ## _scalar, TYPE ## ms_assign) \ + INSTALL_ASSIGNOP (op_asn_eq, octave_matrix, octave_ ## TYPE ## _matrix, TYPE ## mm_assign) \ + INSTALL_ASSIGNCONV (octave_scalar, octave_ ## TYPE ## _scalar, octave_matrix) \ + INSTALL_ASSIGNCONV (octave_scalar, octave_ ## TYPE ## _matrix, octave_matrix) + +#define OCTAVE_INSTALL_CX_INT_ASSIGN_OPS(TYPE) \ + INSTALL_ASSIGNOP (op_asn_eq, octave_complex_matrix, octave_ ## TYPE ## _scalar, TYPE ## cms_assign) \ + INSTALL_ASSIGNOP (op_asn_eq, octave_complex_matrix, octave_ ## TYPE ## _matrix, TYPE ## cmm_assign) \ + INSTALL_ASSIGNCONV (octave_complex_scalar, octave_ ## TYPE ## _scalar, octave_complex_matrix) \ + INSTALL_ASSIGNCONV (octave_complex_scalar, octave_ ## TYPE ## _matrix, octave_complex_matrix) + #define OCTAVE_INSTALL_INT_OPS(TYPE) \ OCTAVE_INSTALL_SS_INT_OPS (TYPE) \ OCTAVE_INSTALL_SM_INT_OPS (TYPE) \ OCTAVE_INSTALL_MS_INT_OPS (TYPE) \ OCTAVE_INSTALL_MM_INT_OPS (TYPE) \ - OCTAVE_INSTALL_CONCAT_FN (TYPE) + OCTAVE_INSTALL_CONCAT_FN (TYPE) \ + OCTAVE_INSTALL_RE_INT_ASSIGN_OPS (TYPE) \ + OCTAVE_INSTALL_CX_INT_ASSIGN_OPS (TYPE) + +#define OCTAVE_INSTALL_SM_INT_ASSIGNCONV(TLHS, TRHS) \ + INSTALL_ASSIGNCONV (octave_ ## TLHS ## _scalar, octave_ ## TRHS ## _scalar, octave_ ## TLHS ## _matrix) \ + INSTALL_ASSIGNCONV (octave_ ## TLHS ## _scalar, octave_ ## TRHS ## _matrix, octave_ ## TLHS ## _matrix) /* ;;; Local Variables: *** ;;; mode: C++ *** ;;; End: *** */ - Index: src/OPERATORS/op-ui16-ui16.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-ui16-ui16.cc,v retrieving revision 1.3 diff -u -r1.3 op-ui16-ui16.cc --- a/src/OPERATORS/op-ui16-ui16.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-ui16-ui16.cc 3 Sep 2004 15:22:08 -0000 @@ -88,6 +88,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui32, uint16_, uint32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi64, uint16_, int64_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui64, uint16_, uint64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint16, int8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint16, uint8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint16, int16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint16, int32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint16, uint32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint16, int64); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint16, uint64); } /* Index: src/OPERATORS/op-ui32-ui32.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-ui32-ui32.cc,v retrieving revision 1.3 diff -u -r1.3 op-ui32-ui32.cc --- a/src/OPERATORS/op-ui32-ui32.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-ui32-ui32.cc 3 Sep 2004 15:22:08 -0000 @@ -88,6 +88,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi32, uint32_, int32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi64, uint32_, int64_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui64, uint32_, uint64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint32, int8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint32, uint8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint32, int16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint32, uint16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint32, int32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint32, int64); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint32, uint64); } /* Index: src/OPERATORS/op-ui64-ui64.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-ui64-ui64.cc,v retrieving revision 1.3 diff -u -r1.3 op-ui64-ui64.cc --- a/src/OPERATORS/op-ui64-ui64.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-ui64-ui64.cc 3 Sep 2004 15:22:08 -0000 @@ -124,6 +124,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi32, uint64_, int32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui32, uint64_, uint32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi64, uint64_, int64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint64, int8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint64, uint8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint64, int16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint64, uint16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint64, int32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint64, uint32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint64, int64); } /* Index: src/OPERATORS/op-ui8-ui8.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-ui8-ui8.cc,v retrieving revision 1.3 diff -u -r1.3 op-ui8-ui8.cc --- a/src/OPERATORS/op-ui8-ui8.cc 1 Sep 2004 21:10:28 -0000 1.3 +++ b/src/OPERATORS/op-ui8-ui8.cc 3 Sep 2004 15:22:08 -0000 @@ -88,6 +88,14 @@ OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui32, uint8_, uint32_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmi64, uint8_, int64_); OCTAVE_INSTALL_MM_INT_ASSIGN_OPS (mmui64, uint8_, uint64_); + + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint8, int8); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint8, int16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint8, uint16); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint8, int32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint8, uint32); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint8, int64); + OCTAVE_INSTALL_SM_INT_ASSIGNCONV (uint8, uint64); } /* From maintainers-request@octave.org Fri Sep 3 13:25:57 2004 Resent-Date: Fri, 3 Sep 2004 13:25:57 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 3 Sep 2004 14:24:38 -0400 (EDT) Message-Id: <200409031824.OAA60297@jazz.ncnr.nist.gov> From: Przemek Klosowski To: maintainers@octave.org Subject: octave crash report X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Two problems with my brand spanking new octave 2.1.58: f=inline('x'); f(3)++ results in panic: impossible state reached in file 'ov-fcn-handle.h' at line 57 Then, it attempts to save variables to 'octave-core' and fails again: error: octave_base_value::save_binary(): wrong type argument 'inline function' From maintainers-request@octave.org Fri Sep 3 14:48:30 2004 Resent-Date: Fri, 3 Sep 2004 14:48:30 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 3 Sep 2004 21:44:05 +0200 From: David Bateman To: Przemek Klosowski Cc: maintainers@octave.org Subject: Re: octave crash report Message-ID: <20040903194405.GA30442@zfr01-2089.crm.mot.com> References: <200409031824.OAA60297@jazz.ncnr.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409031824.OAA60297@jazz.ncnr.nist.gov> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org According to Przemek Klosowski (on 09/03/04): > Two problems with my brand spanking new octave 2.1.58: > > f=inline('x'); f(3)++ > > results in > panic: impossible state reached in file 'ov-fcn-handle.h' at line 57 This is due to subsref... It seems that subsref is defined both in ov-fcn-handle.h and in ov-fcn-handle.cc. Probably changing octave_value subsref (const std::string&, const std::list&) { panic_impossible (); return octave_value (); } to octave_value subsref (const std::string&, const std::list&); in ov-fcnhandle.h might be sufficient. Can test it as my tree is a mess, as I'm fixing another bug at the momemnt and its not compiling :-) D. > > Then, it attempts to save variables to 'octave-core' and fails again: > > error: octave_base_value::save_binary(): wrong type argument 'inline function' -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Fri Sep 3 14:51:18 2004 Resent-Date: Fri, 3 Sep 2004 14:51:18 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 3 Sep 2004 21:47:29 +0200 From: David Bateman To: Przemek Klosowski Cc: maintainers@octave.org Subject: Re: octave crash report Message-ID: <20040903194729.GB30442@zfr01-2089.crm.mot.com> References: <200409031824.OAA60297@jazz.ncnr.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409031824.OAA60297@jazz.ncnr.nist.gov> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org According to Przemek Klosowski (on 09/03/04): > Then, it attempts to save variables to 'octave-core' and fails again: > > error: octave_base_value::save_binary(): wrong type argument 'inline function' We should we be able to save inline functions? Its possible to do it as all that would be required is to save the string representing the inline function. As for function handles this is harder, anonymous function handles might be saved, but normal function handles might not have the original function available when the ile is re-read. D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Sun Sep 5 16:03:11 2004 Resent-Date: Sun, 5 Sep 2004 16:02:50 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "Randy Gober" To: Subject: Minor MATLAB/Octave logical incompatibility Date: Sun, 5 Sep 2004 15:58:07 -0500 Message-ID: <000001c4938b$0b87c180$0100a8c0@EMACHINEJRG> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C49361.22B1B980" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C49361.22B1B980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looking at the online MATLAB documentation for the logical command, I noticed this tidbit: "Most arithmetic operations remove the logicalness from an array. For example, adding zero to a logical array removes its logical = characteristic. A =3D +A is the easiest way to convert a logical array, A, to a numeric = double array." (From http://www.mathworks.com/access/helpdesk/help/techdoc/ref/logical.html) However, Octave keeps the type as bool in this case, in the just realest 2.1.58, we have: octave:1> A=3Dlogical(eye(3)); octave:2> islogical(A) ans =3D 1 octave:3> A=3D+A; octave:4> islogical(A) ans =3D 1 octave:5> islogical(eye(3)) ans =3D 0 (also verified using 'whos') I am not sure if this is a bug or a feature, but it is different from = the way MATLAB does it. ------=_NextPart_000_0001_01C49361.22B1B980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minor MATLAB/Octave logical incompatibility

Looking at the online MATLAB = documentation for the logical command, I noticed this tidbit:


"Most arithmetic operations remove = the logicalness from an array. For example, adding zero to a logical = array removes its logical characteristic. A =3D +A is the easiest way to = convert a logical array, A, to a numeric double array."

(From http://www.mathworks.com/access/helpdesk/help/techdoc/ref/= logical.html)

However, Octave keeps the type as bool = in this case, in the just realest 2.1.58, we have:

octave:1> = A=3Dlogical(eye(3));
octave:2> islogical(A)
ans =3D 1
octave:3> A=3D+A;
octave:4> islogical(A)
ans =3D 1
octave:5> islogical(eye(3))
ans =3D 0

(also verified using 'whos')

I am not sure if this is a bug or a = feature, but it is different from the way MATLAB does it.




------=_NextPart_000_0001_01C49361.22B1B980-- From maintainers-request@octave.org Mon Sep 6 06:41:16 2004 Resent-Date: Mon, 6 Sep 2004 06:41:14 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Mon, 06 Sep 2004 13:36:19 +0200 From: Michael Creel Subject: class reference web page updated To: octave maintainers mailing list , octave-dev@lists.sourceforge.net Message-id: <200409061336.19726.michael.creel@uab.es> Organization: UAB MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org http://pareto.uab.es/mcreel/OctaveClassReference/html/index.html has been updated for version 2.1.58 Michael From maintainers-request@octave.org Mon Sep 6 08:58:05 2004 Resent-Date: Mon, 6 Sep 2004 08:58:00 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.27837.370069.822078@devzero.bogus.domain> Date: Mon, 6 Sep 2004 09:57:17 -0400 To: "Randy Gober" Cc: Subject: Minor MATLAB/Octave logical incompatibility In-Reply-To: <000001c4938b$0b87c180$0100a8c0@EMACHINEJRG> References: <000001c4938b$0b87c180$0100a8c0@EMACHINEJRG> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 5-Sep-2004, Randy Gober wrote: | Looking at the online MATLAB documentation for the logical command, I | noticed this tidbit: | | | "Most arithmetic operations remove the logicalness from an array. For | example, adding zero to a logical array removes its logical characteristic. | A = +A is the easiest way to convert a logical array, A, to a numeric double | array." | (From | http://www.mathworks.com/access/helpdesk/help/techdoc/ref/logical.html) | | However, Octave keeps the type as bool in this case, in the just realest | 2.1.58, we have: | | octave:1> A=logical(eye(3)); | octave:2> islogical(A) | ans = 1 | octave:3> A=+A; | octave:4> islogical(A) | ans = 1 | octave:5> islogical(eye(3)) | ans = 0 | | (also verified using 'whos') | | I am not sure if this is a bug or a feature, but it is different from the | way MATLAB does it. Currently, Octave treats unary plus as a no-op in the parser. Should we change this? It would mean that instead of having the parser convert the unary plus to a no-op, a function to handle the unary plus operation would have to be defined for every octave_value class that needs unary plus. Hmm. I guess this may be needed anyway if we want to support classes at the scripting language level which can overload unary plus. jwe From maintainers-request@octave.org Mon Sep 6 15:20:18 2004 Resent-Date: Mon, 6 Sep 2004 15:20:17 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.50772.443842.778400@devzero.bogus.domain> Date: Mon, 6 Sep 2004 16:19:32 -0400 To: "Randy Gober" Cc: maintainers@octave.org Subject: Minor MATLAB/Octave logical incompatibility In-Reply-To: <16700.27837.370069.822078@devzero.bogus.domain> References: <000001c4938b$0b87c180$0100a8c0@EMACHINEJRG> <16700.27837.370069.822078@devzero.bogus.domain> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 6-Sep-2004, John W. Eaton wrote: | Currently, Octave treats unary plus as a no-op in the parser. Should | we change this? It would mean that instead of having the parser | convert the unary plus to a no-op, a function to handle the unary plus | operation would have to be defined for every octave_value class that | needs unary plus. Hmm. I guess this may be needed anyway if we want | to support classes at the scripting language level which can overload | unary plus. Here are the changes required to make unary + work as you expect. Note that this means unary + will no longer work for other user-defined data types until they are similarly updated. jwe src/ChangeLog: 2004-09-06 John W. Eaton * version.h (OCTAVE_API_VERSION): Now api-v10. * OPERATORS/op-b-b.cc, OPERATORS/op-bm-bm.cc: Define and install unary plus and unary minus operators. * OPERATORS/op-int.h, OPERATORS/op-cm-cm.cc, OPERATORS/op-cs-cs.cc, OPERATORS/op-m-m.cc, OPERATORS/op-range.cc: Define and install unary plus operator. * ov.cc (unary_op_as_string): Handle op_uplus too. * parse.y (prefix_expr): Build unary plus op here instead of converting to no-op. (make_prefix_op): Accept op_uplus. Index: src/ov.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/ov.cc,v retrieving revision 1.113 diff -u -r1.113 ov.cc --- a/src/ov.cc 31 Aug 2004 05:30:47 -0000 1.113 +++ b/src/ov.cc 6 Sep 2004 15:42:50 -0000 @@ -134,6 +134,10 @@ retval = "!"; break; + case op_uplus: + retval = "+"; + break; + case op_uminus: retval = "-"; break; Index: src/ov.h =================================================================== RCS file: /usr/local/cvsroot/octave/src/ov.h,v retrieving revision 1.110 diff -u -r1.110 ov.h --- a/src/ov.h 1 Sep 2004 21:24:54 -0000 1.110 +++ b/src/ov.h 6 Sep 2004 15:42:50 -0000 @@ -100,6 +100,7 @@ enum unary_op { op_not, + op_uplus, op_uminus, op_transpose, op_hermitian, Index: src/parse.y =================================================================== RCS file: /usr/local/cvsroot/octave/src/parse.y,v retrieving revision 1.221 diff -u -r1.221 parse.y --- a/src/parse.y 6 Aug 2004 03:17:13 -0000 1.221 +++ b/src/parse.y 6 Sep 2004 15:42:50 -0000 @@ -804,7 +804,7 @@ | EXPR_NOT prefix_expr %prec UNARY { $$ = make_prefix_op (EXPR_NOT, $2, $1); } | '+' prefix_expr %prec UNARY - { $$ = $2; } + { $$ = make_prefix_op ('+', $2, $1); } | '-' prefix_expr %prec UNARY { $$ = make_prefix_op ('-', $2, $1); } ; @@ -2217,6 +2217,10 @@ t = octave_value::op_not; break; + case '+': + t = octave_value::op_uplus; + break; + case '-': t = octave_value::op_uminus; break; Index: src/version.h =================================================================== RCS file: /usr/local/cvsroot/octave/src/version.h,v retrieving revision 1.70 diff -u -r1.70 version.h --- a/src/version.h 2 Sep 2004 01:28:09 -0000 1.70 +++ b/src/version.h 6 Sep 2004 15:42:50 -0000 @@ -25,7 +25,7 @@ #define OCTAVE_VERSION "2.1.58" -#define OCTAVE_API_VERSION "api-v9" +#define OCTAVE_API_VERSION "api-v10" #define OCTAVE_COPYRIGHT \ "Copyright (C) 2004 John W. Eaton." Index: src/OPERATORS/op-b-b.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-b-b.cc,v retrieving revision 1.11 diff -u -r1.11 op-b-b.cc --- a/src/OPERATORS/op-b-b.cc 4 Sep 2004 01:16:28 -0000 1.11 +++ b/src/OPERATORS/op-b-b.cc 6 Sep 2004 15:42:51 -0000 @@ -45,6 +45,19 @@ // scalar unary ops. DEFUNOP_OP (not, bool, !) + +UNOPDECL (uplus, a) +{ + CAST_UNOP_ARG (const octave_bool&); + return octave_value (v.double_value ()); +} + +UNOPDECL (uminus, a) +{ + CAST_UNOP_ARG (const octave_bool&); + return octave_value (- v.double_value ()); +} + DEFUNOP_OP (transpose, bool, /* no-op */) DEFUNOP_OP (hermitian, bool, /* no-op */) @@ -63,6 +76,8 @@ install_b_b_ops (void) { INSTALL_UNOP (op_not, octave_bool, not); + INSTALL_UNOP (op_uplus, octave_bool, uplus); + INSTALL_UNOP (op_uminus, octave_bool, uminus); INSTALL_UNOP (op_transpose, octave_bool, transpose); INSTALL_UNOP (op_hermitian, octave_bool, hermitian); Index: src/OPERATORS/op-bm-bm.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-bm-bm.cc,v retrieving revision 1.15 diff -u -r1.15 op-bm-bm.cc --- a/src/OPERATORS/op-bm-bm.cc 4 Sep 2004 01:16:28 -0000 1.15 +++ b/src/OPERATORS/op-bm-bm.cc 6 Sep 2004 15:42:51 -0000 @@ -41,6 +41,8 @@ // unary bool matrix ops. DEFNDUNOP_OP (not, bool_matrix, bool_array, !) +DEFNDUNOP_OP (uplus, bool_matrix, array, +) +DEFNDUNOP_OP (uminus, bool_matrix, array, -) DEFUNOP (transpose, bool_matrix) { @@ -76,6 +78,8 @@ install_bm_bm_ops (void) { INSTALL_UNOP (op_not, octave_bool_matrix, not); + INSTALL_UNOP (op_uplus, octave_bool_matrix, uplus); + INSTALL_UNOP (op_uminus, octave_bool_matrix, uminus); INSTALL_UNOP (op_transpose, octave_bool_matrix, transpose); INSTALL_UNOP (op_hermitian, octave_bool_matrix, transpose); Index: src/OPERATORS/op-cm-cm.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-cm-cm.cc,v retrieving revision 1.12 diff -u -r1.12 op-cm-cm.cc --- a/src/OPERATORS/op-cm-cm.cc 23 Jul 2004 19:01:23 -0000 1.12 +++ b/src/OPERATORS/op-cm-cm.cc 6 Sep 2004 15:42:51 -0000 @@ -40,6 +40,7 @@ // unary complex matrix ops. DEFNDUNOP_OP (not, complex_matrix, complex_array, !) +DEFNDUNOP_OP (uplus, complex_matrix, complex_array, /* no-op */) DEFNDUNOP_OP (uminus, complex_matrix, complex_array, -) DEFUNOP (transpose, complex_matrix) @@ -116,6 +117,7 @@ install_cm_cm_ops (void) { INSTALL_UNOP (op_not, octave_complex_matrix, not); + INSTALL_UNOP (op_uplus, octave_complex_matrix, uplus); INSTALL_UNOP (op_uminus, octave_complex_matrix, uminus); INSTALL_UNOP (op_transpose, octave_complex_matrix, transpose); INSTALL_UNOP (op_hermitian, octave_complex_matrix, hermitian); Index: src/OPERATORS/op-cs-cs.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-cs-cs.cc,v retrieving revision 1.10 diff -u -r1.10 op-cs-cs.cc --- a/src/OPERATORS/op-cs-cs.cc 23 Jul 2004 19:01:23 -0000 1.10 +++ b/src/OPERATORS/op-cs-cs.cc 6 Sep 2004 15:42:51 -0000 @@ -47,6 +47,7 @@ return octave_value (v.complex_value () == 0.0); } +DEFUNOP_OP (uplus, complex, /* no-op */) DEFUNOP_OP (uminus, complex, -) DEFUNOP_OP (transpose, complex, /* no-op */) @@ -182,6 +183,7 @@ install_cs_cs_ops (void) { INSTALL_UNOP (op_not, octave_complex, not); + INSTALL_UNOP (op_uplus, octave_complex, uplus); INSTALL_UNOP (op_uminus, octave_complex, uminus); INSTALL_UNOP (op_transpose, octave_complex, transpose); INSTALL_UNOP (op_hermitian, octave_complex, hermitian); Index: src/OPERATORS/op-int.h =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-int.h,v retrieving revision 1.6 diff -u -r1.6 op-int.h --- a/src/OPERATORS/op-int.h 4 Sep 2004 01:16:28 -0000 1.6 +++ b/src/OPERATORS/op-int.h 6 Sep 2004 15:42:51 -0000 @@ -38,6 +38,7 @@ /* scalar unary ops. */ \ \ DEFUNOP_OP (s_not, TYPE ## _scalar, !) \ + DEFUNOP_OP (s_uplus, TYPE ## _scalar, /* no-op */) \ DEFUNOP_OP (s_uminus, TYPE ## _scalar, -) \ DEFUNOP_OP (s_transpose, TYPE ## _scalar, /* no-op */) \ DEFUNOP_OP (s_hermitian, TYPE ## _scalar, /* no-op */) \ @@ -346,6 +347,7 @@ /* matrix unary ops. */ \ \ DEFNDUNOP_OP (m_not, TYPE ## _matrix, TYPE ## _array, !) \ + DEFNDUNOP_OP (m_uplus, TYPE ## _matrix, TYPE ## _array, /* no-op */) \ DEFNDUNOP_OP (m_uminus, TYPE ## _matrix, TYPE ## _array, -) \ \ DEFUNOP (m_transpose, TYPE ## _matrix) \ @@ -473,6 +475,7 @@ #define OCTAVE_INSTALL_S_INT_UNOPS(TYPE) \ INSTALL_UNOP (op_not, octave_ ## TYPE ## _scalar, s_not); \ + INSTALL_UNOP (op_uplus, octave_ ## TYPE ## _scalar, s_uplus); \ INSTALL_UNOP (op_uminus, octave_ ## TYPE ## _scalar, s_uminus); \ INSTALL_UNOP (op_transpose, octave_ ## TYPE ## _scalar, s_transpose); \ INSTALL_UNOP (op_hermitian, octave_ ## TYPE ## _scalar, s_hermitian); \ @@ -616,6 +619,7 @@ #define OCTAVE_INSTALL_M_INT_UNOPS(TYPE) \ INSTALL_UNOP (op_not, octave_ ## TYPE ## _matrix, m_not); \ + INSTALL_UNOP (op_uplus, octave_ ## TYPE ## _matrix, m_uplus); \ INSTALL_UNOP (op_uminus, octave_ ## TYPE ## _matrix, m_uminus); \ INSTALL_UNOP (op_transpose, octave_ ## TYPE ## _matrix, m_transpose); \ INSTALL_UNOP (op_hermitian, octave_ ## TYPE ## _matrix, m_transpose); \ Index: src/OPERATORS/op-m-m.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-m-m.cc,v retrieving revision 1.16 diff -u -r1.16 op-m-m.cc --- a/src/OPERATORS/op-m-m.cc 23 Jul 2004 19:01:23 -0000 1.16 +++ b/src/OPERATORS/op-m-m.cc 6 Sep 2004 15:42:51 -0000 @@ -40,6 +40,7 @@ // matrix unary ops. DEFNDUNOP_OP (not, matrix, array, !) +DEFNDUNOP_OP (uplus, matrix, array, /* no-op */) DEFNDUNOP_OP (uminus, matrix, array, -) DEFUNOP (transpose, matrix) @@ -103,6 +104,7 @@ install_m_m_ops (void) { INSTALL_UNOP (op_not, octave_matrix, not); + INSTALL_UNOP (op_uplus, octave_matrix, uplus); INSTALL_UNOP (op_uminus, octave_matrix, uminus); INSTALL_UNOP (op_transpose, octave_matrix, transpose); INSTALL_UNOP (op_hermitian, octave_matrix, transpose); Index: src/OPERATORS/op-range.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-range.cc,v retrieving revision 1.7 diff -u -r1.7 op-range.cc --- a/src/OPERATORS/op-range.cc 23 Jul 2004 19:01:23 -0000 1.7 +++ b/src/OPERATORS/op-range.cc 6 Sep 2004 15:42:51 -0000 @@ -51,6 +51,7 @@ return octave_value (! v.matrix_value()); } +DEFUNOP_OP (uplus, range, /* no-op */) DEFUNOP_OP (uminus, range, -) DEFUNOP (transpose, range) @@ -80,6 +81,7 @@ install_range_ops (void) { INSTALL_UNOP (op_not, octave_range, not); + INSTALL_UNOP (op_uplus, octave_range, uplus); INSTALL_UNOP (op_uminus, octave_range, uminus); INSTALL_UNOP (op_transpose, octave_range, transpose); INSTALL_UNOP (op_hermitian, octave_range, transpose); Index: src/OPERATORS/op-s-s.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/OPERATORS/op-s-s.cc,v retrieving revision 1.11 diff -u -r1.11 op-s-s.cc --- a/src/OPERATORS/op-s-s.cc 23 Jul 2004 19:01:23 -0000 1.11 +++ b/src/OPERATORS/op-s-s.cc 6 Sep 2004 15:42:51 -0000 @@ -41,6 +41,7 @@ // scalar unary ops. DEFUNOP_OP (not, scalar, !) +DEFUNOP_OP (uplus, scalar, /* no-op */) DEFUNOP_OP (uminus, scalar, -) DEFUNOP_OP (transpose, scalar, /* no-op */) DEFUNOP_OP (hermitian, scalar, /* no-op */) From maintainers-request@octave.org Wed Sep 8 04:08:28 2004 Resent-Date: Wed, 8 Sep 2004 04:08:08 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <413ECBEB.6020807@cs.uu.nl> Date: Wed, 08 Sep 2004 11:07:55 +0200 From: Rob Vermaas User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040830) X-Accept-Language: en-us, en MIME-Version: 1.0 To: octave maintainers mailing list Subject: Octave compiler Content-Type: multipart/mixed; boundary="------------000508070107060302060405" X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: * X-Spam-Status: No, hits=1.9 required=5.0 tests=WEIRD_PORT autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org This is a multi-part message in MIME format. --------------000508070107060302060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi there, In our group we are currently working on a compiler for Octave. The compiler translates Octave code to C++ code. The compiler is implemented mostly in Stratego (see www.stratego.org). It consists of the following packages: - octave-front, the front-end, containing parser etc. - octave-opt, the optimizer - octave-tc, the type checker/inferencer - octave2c, back-end We are hoping to have a first release at the end of this month. This release will have quite some limitations though, among others - variables should not change types - no eval/feval - limited support for built-in functions - no lists - no streamoffs - no int8/16/... etc. (as we based the compiler on octave-2.1.57) - lots of bugs ;-) If you are interested and want to check out what exactly we are doing, it is possible to access the compiler packages at https://svn.cs.uu.nl:12443/repos/octave/trunk/octave-top/. That said, I have a small feature-request (sorry if this is the wrong list to post this on). We are using mkoctfile in the back-end of the compiler. At the moment I'm patching mkoctfile manually to allow .oct files to be passed as object files when compiling a stand-alone application. I was wondering if it is possible to add this to the mkoctfile in Octave itself, or are there any objections to this? I have attached a patch to this email. greetings, Rob Vermaas --------------000508070107060302060405 Content-Type: text/x-patch; name="mkoctfile.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mkoctfile.patch" --- octave-2.1.58/mkoctfile.in 2004-09-02 03:28:49.000000000 +0200 +++ octave/mkoctfile.in 2004-09-08 10:37:02.000000000 +0200 @@ -106,6 +106,10 @@ file=$1 objfiles="$objfiles $file" ;; + *.oct) + file=$1 + objfiles="$objfiles $file" + ;; -d | --debug | -v | --verbose) dbg=echo ;; @@ -172,6 +176,7 @@ .f Fortran source .F Fortran source .o object file + .oct object file EOF exit 0 --------------000508070107060302060405-- From maintainers-request@octave.org Wed Sep 8 10:17:00 2004 Resent-Date: Wed, 8 Sep 2004 10:16:53 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16703.8756.119519.996883@devzero.bogus.domain> Date: Wed, 8 Sep 2004 11:16:04 -0400 To: Rob Vermaas Cc: octave maintainers mailing list Subject: Octave compiler In-Reply-To: <413ECBEB.6020807@cs.uu.nl> References: <413ECBEB.6020807@cs.uu.nl> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 8-Sep-2004, Rob Vermaas wrote: | That said, I have a small feature-request (sorry if this is the wrong | list to post this on). We are using mkoctfile in the back-end of the | compiler. At the moment I'm patching mkoctfile manually to allow .oct | files to be passed as object files when compiling a stand-alone | application. I was wondering if it is possible to add this to the | mkoctfile in Octave itself, or are there any objections to this? I have | attached a patch to this email. Why is this needed? A .oct file is not an object file. It is usually a shared library object, and it is intended to be loaded by dlopen (or a similar mechanism). If you want to link in the code for a .oct file directly to an application, wouldn't it make more sense to do something like mkoctfile -c my_oct_file.cc mkoctfile [other options and files] my_oct_file.o ? jwe From maintainers-request@octave.org Wed Sep 8 10:28:30 2004 Resent-Date: Wed, 8 Sep 2004 10:28:30 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16703.9459.113718.362299@devzero.bogus.domain> Date: Wed, 8 Sep 2004 11:27:47 -0400 To: Rob Vermaas Cc: octave maintainers mailing list Subject: Octave compiler In-Reply-To: <413ECBEB.6020807@cs.uu.nl> References: <413ECBEB.6020807@cs.uu.nl> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,WEIRD_PORT autolearn=no version=2.63 Resent-Message-ID: <2WOku.A.QFE.eUyPBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 8-Sep-2004, Rob Vermaas wrote: | In our group we are currently working on a compiler for Octave. The | compiler translates Octave code to C++ code. The compiler is implemented | mostly in Stratego (see www.stratego.org). | | It consists of the following packages: | - octave-front, the front-end, containing parser etc. | - octave-opt, the optimizer | - octave-tc, the type checker/inferencer | - octave2c, back-end | | We are hoping to have a first release at the end of this month. This | release will have quite some limitations though, among others | - variables should not change types | - no eval/feval | - limited support for built-in functions | - no lists | - no streamoffs | - no int8/16/... etc. (as we based the compiler on octave-2.1.57) | - lots of bugs ;-) | | If you are interested and want to check out what exactly we are doing, | it is possible to access the compiler packages at | https://svn.cs.uu.nl:12443/repos/octave/trunk/octave-top/. What are the problems you face when supporting built-in functions? The code for those functions already exists, so shouldn't you be able to link to liboctinterp/liboctave and have nearly all of them work? I looked at the parser, and it seems you have adapted Octave's lexer and parser. I think this is a good idea, as it makes little sense to develop a separate parser from scratch. However, the code in Octave is likely to change, so if you fork your own version, you are likely to have a maintenance problem in the future. Would you like to help introduce changes to Octave's parser so that it would be easier to generate what you need without having to rewrite the actions part of the paresr? It migth be possible to do that now, without any changes to Octave, by writing a new new class based on Octave's tree_walker class (in src/pt-walk.h) that can take Octave's tree representation of the input and emit whatever you need for your front end. That way, any changes to Octave's language in the parser/lexer would require fewer changes to your code. The front end appears to have a list of built-in functions and variables. How do you generate this list? Would you like to contribute or help write patches to Octave's build system so that you can generate this information automatically for new versions of Octave? Are you aware of other efforts to write compilers for Octave? It might be good to work together rather than have multiple projects. jwe From maintainers-request@octave.org Wed Sep 8 10:36:56 2004 Resent-Date: Wed, 8 Sep 2004 10:36:56 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <413F26EA.9010004@cs.uu.nl> Date: Wed, 08 Sep 2004 17:36:10 +0200 From: Rob Vermaas User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040830) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John W. Eaton" Cc: octave maintainers mailing list Subject: Re: Octave compiler References: <413ECBEB.6020807@cs.uu.nl> <16703.8756.119519.996883@devzero.bogus.domain> In-Reply-To: <16703.8756.119519.996883@devzero.bogus.domain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Hi John, John W. Eaton wrote: >On 8-Sep-2004, Rob Vermaas wrote: > >| That said, I have a small feature-request (sorry if this is the wrong >| list to post this on). We are using mkoctfile in the back-end of the >| compiler. At the moment I'm patching mkoctfile manually to allow .oct >| files to be passed as object files when compiling a stand-alone >| application. I was wondering if it is possible to add this to the >| mkoctfile in Octave itself, or are there any objections to this? I have >| attached a patch to this email. > >Why is this needed? A .oct file is not an object file. It is usually >a shared library object, and it is intended to be loaded by dlopen (or >a similar mechanism). > >If you want to link in the code for a .oct file directly to an >application, wouldn't it make more sense to do something like > > mkoctfile -c my_oct_file.cc > mkoctfile [other options and files] my_oct_file.o > > > The issue was that I wanted to be able to use existing dld-function/.oct files (e.g. the ones from octave, or any other in the path) without having to recompile them, basically. And as I was able to use them to link the compiled program against, I have chosen this option. What would be the advantages of loading them dynamically instead? greetings, Rob Vermaas From maintainers-request@octave.org Wed Sep 8 10:46:19 2004 Resent-Date: Wed, 8 Sep 2004 10:46:18 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16703.10325.871201.908208@devzero.bogus.domain> Date: Wed, 8 Sep 2004 11:42:13 -0400 To: Rob Vermaas Cc: octave maintainers mailing list Subject: Re: Octave compiler In-Reply-To: <413F26EA.9010004@cs.uu.nl> References: <413ECBEB.6020807@cs.uu.nl> <16703.8756.119519.996883@devzero.bogus.domain> <413F26EA.9010004@cs.uu.nl> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 8-Sep-2004, Rob Vermaas wrote: | The issue was that I wanted to be able to use existing dld-function/.oct | files (e.g. the ones from octave, or any other in the path) without | having to recompile them, basically. And as I was able to use them to | link the compiled program against, I have chosen this option. What would | be the advantages of loading them dynamically instead? Does it always work on all systems? For example, can you link directly to a .oct file on an OS-X or HP/UX system? jwe From maintainers-request@octave.org Wed Sep 8 11:17:08 2004 Resent-Date: Wed, 8 Sep 2004 11:17:07 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f In-Reply-To: <16703.10325.871201.908208@devzero.bogus.domain> References: <413ECBEB.6020807@cs.uu.nl> <16703.8756.119519.996883@devzero.bogus.domain> <413F26EA.9010004@cs.uu.nl> <16703.10325.871201.908208@devzero.bogus.domain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D69F7D4-01B2-11D9-9D16-000A95D8B52C@mac.com> Content-Transfer-Encoding: 7bit Cc: octave-maintainers@bevo.che.wisc.edu From: Per Persson Subject: Re: Octave compiler Date: Wed, 8 Sep 2004 18:16:23 +0200 To: John Eaton X-Mailer: Apple Mail (2.619) X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On Sep 8, 2004, at 17:42, John W. Eaton wrote: > On 8-Sep-2004, Rob Vermaas wrote: > > | The issue was that I wanted to be able to use existing > dld-function/.oct > | files (e.g. the ones from octave, or any other in the path) without > | having to recompile them, basically. And as I was able to use them to > | link the compiled program against, I have chosen this option. What > would > | be the advantages of loading them dynamically instead? > > Does it always work on all systems? For example, can you link > directly to a .oct file on an OS-X or HP/UX system? Nope, at least on OS X you can't use .oct files as shared libs. /Per -------- Per Persson, Ph.D. Applied Signal Processing Resume, contact info and more: http://homepage.mac.com/persquare From maintainers-request@octave.org Fri Sep 10 04:40:55 2004 Resent-Date: Fri, 10 Sep 2004 04:40:33 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 10 Sep 2004 11:35:59 +0200 From: Michael Creel Subject: poisson_rnd is broken in 2.1.58 To: octave-maintainers@bevo.che.wisc.edu Message-id: <200409101135.59560.michael.creel@uab.es> Organization: UAB MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Hello, The poisson_rnd function should return a matrix of the same size as the input, when one argument is passed. This worked in 2.1.57. I could probably make a patch, but perhaps someone who knows the origin of the bug would prefer to do that? Michael octave:2> poisson_rnd(ones(10,2)) error: operator -: nonconformant arguments (op1 is 15x1, op2 is 1x15) error: evaluating binary operator `-' near line 104, column 23 error: evaluating assignment expression near line 103, column 20 error: evaluating if command near line 102, column 2 error: evaluating while command near line 100, column 7 error: evaluating if command near line 96, column 5 error: evaluating if command near line 67, column 3 error: called from `poisson_rnd' in file `/home/mcreel/octave/share/octave/2.1.58/m/statistics/distributions/poisson_rnd.m' octave:2> From maintainers-request@octave.org Fri Sep 10 07:01:37 2004 Resent-Date: Fri, 10 Sep 2004 07:01:27 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 10 Sep 2004 13:57:34 +0200 From: David Bateman To: Michael Creel Cc: octave-maintainers@bevo.che.wisc.edu Subject: Re: poisson_rnd is broken in 2.1.58 Message-ID: <20040910115734.GC4621@zfr01-2089.crm.mot.com> References: <200409101135.59560.michael.creel@uab.es> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: <200409101135.59560.michael.creel@uab.es> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I converted all of the statistical toolbox to work with ND arrays, so if you are using the statisical toolbox it would be good if you give it a torture test. In any case here is a fix for the problem you found and the binomial_rnd function as well. D. According to Michael Creel (on 09/10/04): > Hello, > The poisson_rnd function should return a matrix of the same size as the input, > when one argument is passed. This worked in 2.1.57. I could probably make a > patch, but perhaps someone who knows the origin of the bug would prefer to do > that? > > Michael > > > octave:2> poisson_rnd(ones(10,2)) > error: operator -: nonconformant arguments (op1 is 15x1, op2 is 1x15) > error: evaluating binary operator `-' near line 104, column 23 > error: evaluating assignment expression near line 103, column 20 > error: evaluating if command near line 102, column 2 > error: evaluating while command near line 100, column 7 > error: evaluating if command near line 96, column 5 > error: evaluating if command near line 67, column 3 > error: called from `poisson_rnd' in file > `/home/mcreel/octave/share/octave/2.1.58/m/statistics/distributions/poisson_rnd.m' > octave:2> > -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=changelog-stat 2004-09-10 David Bateman * statistics/distributions/binomial_rnd.m: Fix error for scale n and p with n > 1, and fix for matrix n and p with n == 1 * statistics/distributions/poisson_rnd.m: Fix for matrix length, due to row vs column vector operations. --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.stat" *** ./scripts/statistics/distributions/poisson_rnd.m.orig3 2004-04-09 12:11:07.000000000 +0200 --- ./scripts/statistics/distributions/poisson_rnd.m 2004-09-10 13:52:03.000000000 +0200 *************** *** 101,107 **** ind = find (sum < 1); if (any (ind)) sum(ind) = (sum(ind) ! - log (1 - rand (1, length (ind))) ./ l(ind)); num(ind) = num(ind) + 1; else break; --- 101,107 ---- ind = find (sum < 1); if (any (ind)) sum(ind) = (sum(ind) ! - log (1 - rand (length (ind), 1)) ./ l(ind)); num(ind) = num(ind) + 1; else break; *** ./scripts/statistics/distributions/binomial_rnd.m.orig3 2004-04-17 00:21:10.000000000 +0200 --- ./scripts/statistics/distributions/binomial_rnd.m 2004-09-10 13:46:46.000000000 +0200 *************** *** 82,88 **** else nel = prod (sz); tmp = rand (n, nel); ! rnd = tmp < ones (n, nel) * p; rnd = reshape(rnd, sz); endif else --- 82,88 ---- else nel = prod (sz); tmp = rand (n, nel); ! rnd = sum(tmp < ones (n, nel) * p, 1); rnd = reshape(rnd, sz); endif else *************** *** 101,107 **** tmp = rand (N, L); ind = (1 : N)' * ones (1, L); rnd(k) = sum ((tmp < ones (N, 1) * p(k)(:)') & ! (ind <= ones (N, 1) * n(k)(:)')); endif endif --- 101,107 ---- tmp = rand (N, L); ind = (1 : N)' * ones (1, L); rnd(k) = sum ((tmp < ones (N, 1) * p(k)(:)') & ! (ind <= ones (N, 1) * n(k)(:)'),1); endif endif --LpQ9ahxlCli8rRTG-- From maintainers-request@octave.org Fri Sep 10 08:54:42 2004 Resent-Date: Fri, 10 Sep 2004 08:54:36 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16705.45551.784698.62587@devzero.bogus.domain> Date: Fri, 10 Sep 2004 09:53:51 -0400 To: David Bateman Cc: Michael Creel , octave-maintainers@bevo.che.wisc.edu Subject: Re: poisson_rnd is broken in 2.1.58 In-Reply-To: <20040910115734.GC4621@zfr01-2089.crm.mot.com> References: <200409101135.59560.michael.creel@uab.es> <20040910115734.GC4621@zfr01-2089.crm.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 10-Sep-2004, David Bateman wrote: | I converted all of the statistical toolbox to work with ND arrays, so if | you are using the statisical toolbox it would be good if you give it a | torture test. | | In any case here is a fix for the problem you found and the binomial_rnd | function as well. I applied these changes. Thanks, jwe From maintainers-request@octave.org Mon Sep 13 11:12:15 2004 Resent-Date: Mon, 13 Sep 2004 11:12:00 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <4145C6C4.9030904@wanadoo.fr> Date: Mon, 13 Sep 2004 18:11:48 +0200 From: Paul Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: octave maintainers mailing list Subject: octave API and present octave classes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Having circulated a draft of my article on dynamically linked functions to some of you, I am moved to go on-list to explore one of the points that has come up: In essence, there is a question as to whether it is worthwhile documenting the octave classes whilst (i) a potential API or a stable mex library might be in the wings; and (ii) the underlying representation of octave classes might change? My reaction to (i) is that it seems to me that the first layer of octave derived classes, such as matrix, ColumnVector, Cell and all the others, together with octave_value and octave_value_list, form a rather good API that needs documenting. The corollary to this responds to (ii). It is that derived classes, like Array, idx_vector and so on should, not be considered to be part of the API (except implicitly through fortran_vec(), for example) , in order that they can be modified in the future. Is this not the strength of implementing octave in C++? The example of the use of a transpose flag, rather than a physical transpose was mentioned. It would still be natural to have a Matrix::transpose(), either inherited or as a class member, would it not? Regards Paul T From maintainers-request@octave.org Tue Sep 14 16:10:40 2004 Resent-Date: Tue, 14 Sep 2004 16:10:40 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Tue, 14 Sep 2004 23:09:50 +0200 From: David Bateman To: maintainers@octave.org Cc: Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" Message-ID: <20040914210950.GD27214@zfr01-2089.crm.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Moving this discusson to maintainers as it seems to go a bit beyond help :-) > Although Octave doesn't support classes in the same way as Matlab, I > think we should probably fix sort to handle cell arrays in a > compatible way, even if that means we have to add another case to > Fsort. I thought this was a bit crufty as a solution. However, given that the basic sorting code is written as a template it would be relatively painless to add sorting of cell arrays of strings as well. Should probably clean up sort.cc in any case since the NDArray, complexNDArray and charNDArray stuff might also be written as a template. In any case, looking at http://www.mathworks.com/access/helpdesk/help/techdoc/ref/sort.html it seems that matlab has also added a "mode" flag that can define ascending or descending sorted order. Which again is relatively easy to add, but again more work :-( However, if we are going to this level of compatiability, maybe we should also revisit the complex sorting code and the decision to do the sorting only on the absolute value rather than in a matlab compatiable way. Then again maybe not as sorting non ordinate values doesn't make much sense in any case. >What about structs? Does Matlab also have a special sort method for >those? Matlab doesn't seem to sort structs... D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Tue Sep 14 16:27:10 2004 Resent-Date: Tue, 14 Sep 2004 16:27:05 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16711.25079.152574.465546@devzero.bogus.domain> Date: Tue, 14 Sep 2004 17:26:15 -0400 To: David Bateman Cc: maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" In-Reply-To: <20040914210950.GD27214@zfr01-2089.crm.mot.com> References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 14-Sep-2004, David Bateman wrote: | I thought this was a bit crufty as a solution. However, given that the | basic sorting code is written as a template it would be relatively | painless to add sorting of cell arrays of strings as well. Should | probably clean up sort.cc in any case since the NDArray, complexNDArray | and charNDArray stuff might also be written as a template. Yes, I noticed that there is now a lot of duplicated code in sort.cc. | http://www.mathworks.com/access/helpdesk/help/techdoc/ref/sort.html | | it seems that matlab has also added a "mode" flag that can define | ascending or descending sorted order. Which again is relatively easy | to add, but again more work :-( The price of aiming at a moving target. | However, if we are going to this level of compatiability, maybe we | should also revisit the complex sorting code and the decision to do | the sorting only on the absolute value rather than in a matlab | compatiable way. Then again maybe not as sorting non ordinate values | doesn't make much sense in any case. We might as well be compatible if it is not too difficult. In the old days, I think they only said that complex elements X were sorted by ABS(X), so I believe Octave was doing the compatible thing at some point. But now they say that matches are further sorted by ANGLE(X). I would think that it should not be too hard to add that to the complex comparison function. jwe From maintainers-request@octave.org Wed Sep 15 08:07:30 2004 Resent-Date: Wed, 15 Sep 2004 08:07:29 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 15 Sep 2004 15:02:58 +0200 From: Michael Creel Subject: install location of Octave libraries in .debs To: edd@debian.org, octave-maintainers@bevo.che.wisc.edu Message-id: <200409151502.58902.michael.creel@uab.es> Organization: UAB MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Hello Dirk and others, In the packages for Debian Linux, the symbolic links liboctave.so, libcruft.so, and liboctinterp.so are created in the directory /usr/lib/octave-2.1.58 (or whatever the latest version is) rather than /usr/lib/octave. When linking against these, you need to know which is the latest version installed. I'm wondering if the links can be made in /usr/lib/octave, or using the /etc/alternatives framework, so that one can write a makefile that will work without knowing the last installed version. Or, if someone has an easy alternative solution, what is it please? Regards, Michael From maintainers-request@octave.org Wed Sep 15 08:26:09 2004 Resent-Date: Wed, 15 Sep 2004 08:26:09 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 15 Sep 2004 08:25:17 -0500 From: Dirk Eddelbuettel To: Michael Creel Cc: edd@debian.org, octave-maintainers@bevo.che.wisc.edu Subject: Re: install location of Octave libraries in .debs Message-ID: <20040915132517.GA26133@sonny.eddelbuettel.com> References: <200409151502.58902.michael.creel@uab.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409151502.58902.michael.creel@uab.es> User-Agent: Mutt/1.3.28i X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On Wed, Sep 15, 2004 at 03:02:58PM +0200, Michael Creel wrote: > Hello Dirk and others, > In the packages for Debian Linux, the symbolic links liboctave.so, > libcruft.so, and liboctinterp.so are created in the > directory /usr/lib/octave-2.1.58 (or whatever the latest version is) rather > than /usr/lib/octave. > > When linking against these, you need to know which is the latest version > installed. I'm wondering if the links can be made in /usr/lib/octave, or > using the /etc/alternatives framework, so that one can write a makefile that > will work without knowing the last installed version. > > Or, if someone has an easy alternative solution, what is it please? There is one: $ man octave-config which is used for example in all the build scripts I use: edd@homebud:~> head -16 debian/Octave/octave-forge-2004.09.09/debian/rules #!/usr/bin/make -f # -*- makefile -*- # debian.rules file for the Debian/GNU Linux octave-forge package # Copyright 2000 - 2004 by Dirk Eddelbuettel package = octave-forge altname = octave-forge-alternatives debtmp := $(CURDIR)/debian/tmp debdoc := $(debtmp)/usr/share/doc/$(package) octdir := $(shell octave-config --oct-site-dir) mdir := $(shell octave-config --m-site-dir) altoctdir := $(shell octave-config --oct-site-dir)/$(altname) altmdir := $(shell octave-config --m-site-dir | \ sed -e +"s,/m$$,,")/$(altname)/m octbin := $(shell octave-config -p LOCALVERARCHLIBDIR) The real problem is that we need to rebuild all packages containing .oct code for every new version. But then that is a price worth paying for new features -- and there were tons of them lately -- which is somewhat difficult with a frozen API. That said, in an ideal world (where John, David, Paul, ... can all code 36 hrs/day :) it would be nice to undo the version-numnered paths for, say, a new stable version octave 3.0. Dirk -- Those are my principles, and if you don't like them... well, I have others. -- Groucho Marx From maintainers-request@octave.org Wed Sep 15 10:00:26 2004 Resent-Date: Wed, 15 Sep 2004 10:00:26 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 15 Sep 2004 16:52:14 +0200 From: Michael Creel Subject: Re: install location of Octave libraries in .debs In-reply-to: <20040915132517.GA26133@sonny.eddelbuettel.com> To: maintainers@octave.org Cc: Dirk Eddelbuettel , octave-maintainers@bevo.che.wisc.edu Message-id: <200409151652.14253.michael.creel@uab.es> Organization: UAB MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <200409151502.58902.michael.creel@uab.es> <20040915132517.GA26133@sonny.eddelbuettel.com> X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Thanks, octave-config -p OCTINCLUDEDIR gives me just what I wanted. Michael On Wednesday 15 September 2004 15:25, Dirk Eddelbuettel wrote: > On Wed, Sep 15, 2004 at 03:02:58PM +0200, Michael Creel wrote: > > Hello Dirk and others, > > In the packages for Debian Linux, the symbolic links liboctave.so, > > libcruft.so, and liboctinterp.so are created in the > > directory /usr/lib/octave-2.1.58 (or whatever the latest version is) > > rather than /usr/lib/octave. > > > > When linking against these, you need to know which is the latest version > > installed. I'm wondering if the links can be made in /usr/lib/octave, or > > using the /etc/alternatives framework, so that one can write a makefile > > that will work without knowing the last installed version. > > > > Or, if someone has an easy alternative solution, what is it please? > > There is one: > > $ man octave-config > > which is used for example in all the build scripts I use: > edd@homebud:~> head -16 debian/Octave/octave-forge-2004.09.09/debian/rules > #!/usr/bin/make -f > # -*- makefile -*- > # debian.rules file for the Debian/GNU Linux octave-forge package > # Copyright 2000 - 2004 by Dirk Eddelbuettel > > package = octave-forge > altname = octave-forge-alternatives > debtmp := $(CURDIR)/debian/tmp > debdoc := $(debtmp)/usr/share/doc/$(package) > octdir := $(shell octave-config --oct-site-dir) > mdir := $(shell octave-config --m-site-dir) > altoctdir := $(shell octave-config --oct-site-dir)/$(altname) > altmdir := $(shell octave-config --m-site-dir | \ > sed -e +"s,/m$$,,")/$(altname)/m > octbin := $(shell octave-config -p LOCALVERARCHLIBDIR) > > > The real problem is that we need to rebuild all packages containing .oct > code for every new version. But then that is a price worth paying for new > features -- and there were tons of them lately -- which is somewhat > difficult with a frozen API. That said, in an ideal world (where John, > David, Paul, ... can all code 36 hrs/day :) it would be nice to undo the > version-numnered paths for, say, a new stable version octave 3.0. > > Dirk From maintainers-request@octave.org Wed Sep 15 11:10:24 2004 Resent-Date: Wed, 15 Sep 2004 11:10:22 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 15 Sep 2004 18:06:19 +0200 From: David Bateman To: "John W. Eaton" Cc: David Bateman , maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" Message-ID: <20040915160619.GA12502@zfr01-2089.crm.mot.com> References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16711.25079.152574.465546@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <-qFZRB.A.I4H.ulGSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org According to John W. Eaton (on 09/14/04): > On 14-Sep-2004, David Bateman wrote: > > | I thought this was a bit crufty as a solution. However, given that the > | basic sorting code is written as a template it would be relatively > | painless to add sorting of cell arrays of strings as well. Should > | probably clean up sort.cc in any case since the NDArray, complexNDArray > | and charNDArray stuff might also be written as a template. > > Yes, I noticed that there is now a lot of duplicated code in sort.cc. Well I've converted it all to use templates, and included sorting of cell arrays of strings. However, ... > | http://www.mathworks.com/access/helpdesk/help/techdoc/ref/sort.html > | > | it seems that matlab has also added a "mode" flag that can define > | ascending or descending sorted order. Which again is relatively easy > | to add, but again more work :-( > > The price of aiming at a moving target. I have a problem in implementing the "descend" flag. Where are the NaN's sorted? As this was introduced in R14, which I don't have access to.. So I need some one to run the example x = [Inf, NaN, -Inf, 3, 2, 1]; [a, ai] = sort (x, "ascend") [a, ai] = sort (x, "descend") x = [Inf, NaN, -Inf, 3, 2, 1I]; [a, ai] = sort (x, "ascend") [a, ai] = sort (x, "descend") > | However, if we are going to this level of compatiability, maybe we > | should also revisit the complex sorting code and the decision to do > | the sorting only on the absolute value rather than in a matlab > | compatiable way. Then again maybe not as sorting non ordinate values > | doesn't make much sense in any case. > > We might as well be compatible if it is not too difficult. In the old > days, I think they only said that complex elements X were sorted by > ABS(X), so I believe Octave was doing the compatible thing at some > point. But now they say that matches are further sorted by ANGLE(X). > I would think that it should not be too hard to add that to the > complex comparison function. Ok, as I have most of this stuff implemented, I'll do this at the same time. At least I will when I get feedback on the above question D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Wed Sep 15 11:27:24 2004 Resent-Date: Wed, 15 Sep 2004 11:27:24 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <41486CA7.1060502@ieee.org> Date: Wed, 15 Sep 2004 11:24:07 -0500 From: Quentin Spencer User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Bateman CC: "John W. Eaton" , maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> <20040915160619.GA12502@zfr01-2089.crm.mot.com> In-Reply-To: <20040915160619.GA12502@zfr01-2089.crm.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org David Bateman wrote: > I have a problem in implementing the "descend" flag. Where are the > >NaN's sorted? As this was introduced in R14, which I don't have access >to.. So I need some one to run the example > >x = [Inf, NaN, -Inf, 3, 2, 1]; >[a, ai] = sort (x, "ascend") >[a, ai] = sort (x, "descend") >x = [Inf, NaN, -Inf, 3, 2, 1I]; >[a, ai] = sort (x, "ascend") >[a, ai] = sort (x, "descend") > > Output from MATLAB R14: >> x = [Inf, NaN, -Inf, 3, 2, 1]; >> [a, ai] = sort (x, 'ascend') a = -Inf 1 2 3 Inf NaN ai = 3 6 5 4 1 2 >> [a, ai] = sort (x, 'descend') a = NaN Inf 3 2 1 -Inf ai = 2 1 4 5 6 3 /home/qspencer> mat Warning: Could not query OpenGL. Warning: OpenGL appears to be installed incorrectly. < M A T L A B > Copyright 1984-2004 The MathWorks, Inc. Version 7.0.0.19901 (R14) May 06, 2004 To get started, type one of these: helpwin, helpdesk, or demo. For product information, visit www.mathworks.com. >> x = [Inf, NaN, -Inf, 3, 2, 1]; >> [a, ai] = sort (x, 'ascend') a = -Inf 1 2 3 Inf NaN ai = 3 6 5 4 1 2 >> [a, ai] = sort (x, 'descend') a = NaN Inf 3 2 1 -Inf ai = 2 1 4 5 6 3 >> x = [Inf, NaN, -Inf, 3, 2, 1i]; >> [a, ai] = sort (x, 'ascend') a = Columns 1 through 4 0 + 1.0000i 2.0000 3.0000 Inf Columns 5 through 6 -Inf NaN ai = 6 5 4 1 3 2 >> [a, ai] = sort (x, 'descend') a = Columns 1 through 4 NaN -Inf Inf 3.0000 Columns 5 through 6 2.0000 0 + 1.0000i ai = 2 3 1 4 5 6 From maintainers-request@octave.org Wed Sep 15 11:51:08 2004 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Resent-From: jwe@bevo.che.wisc.edu Resent-Message-ID: <16712.29179.638151.746052@devzero.bogus.domain> Resent-Date: Wed, 15 Sep 2004 12:46:51 -0400 Resent-To: octave maintainers mailing list X-Authentication-Warning: bevo.che.wisc.edu: list set sender to listman using -f X-From_: kwgoodman@gmail.com Wed Sep 15 11:34:28 2004 Old-Date: Wed, 15 Sep 2004 09:32:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CAE-MailScanner: Found to be clean (errol), Found to be clean (errol) Old-X-Envelope-To: octave-maintainers Subject: Vectorizing strcmp From: Keith Goodman Reply-To: Keith Goodman To: maintainers@octave.org Date: Wed, 15 Sep 2004 11:34:29 -0500 Message-ID: X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On the one hand, it's nice that strcmp is a user-defined function---it's easy to look at the code to see what it does. On the other hand, the reason I'm looking at the code is that it is slow. I'm using strcmp(s1,s2) where s1 is a cell array of strings (around 1000X1) and s2 is a string. Currently, in 2.1.58, strcmp does n = length(t1); for i = 1:n retval(i,:) = strcmp (t1{i}, s2); endfor which recursively calls strcmp for two strings and where t1 is s1(:). The for loop is slow. Short of making strcmp a built-in function, one way to speed it up is to replace the for loop with a repmat like this c1 = char(t1); [rc1, cc1] = size(c1); ns2 = size(s2,2); blank = ' '; ms2 = repmat([s2 repmat(blank,1,max(cc1 - ns2, 0))], rc1, 1); mc1 = [c1 repmat(blank,1,max(ns2 - cc1, 0))]; retval2 = sum(mc1==ms2, 2)==size(mc1, 2); The blank is to pad the strings if char(s1) and s2 are different widths. The second code fragment is about 10 times faster than the first for length(s1)==1000. For length(s1)==10 the speed is about the same. And for length(s1) < 10 the first approach is faster. For me the added complexity in the code is more than offset by the gain in speed. From maintainers-request@octave.org Wed Sep 15 11:51:32 2004 Resent-Date: Wed, 15 Sep 2004 11:51:32 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 15 Sep 2004 18:47:12 +0200 From: David Bateman To: Quentin Spencer Cc: "John W. Eaton" , maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" Message-ID: <20040915164712.GB12502@zfr01-2089.crm.mot.com> References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> <20040915160619.GA12502@zfr01-2089.crm.mot.com> <41486CA7.1060502@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41486CA7.1060502@ieee.org> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org According to Quentin Spencer (on 09/15/04): > > Output from MATLAB R14: > > > > >> x = [Inf, NaN, -Inf, 3, 2, 1]; > >> [a, ai] = sort (x, 'ascend') > > a = > > -Inf 1 2 3 Inf NaN > > > ai = > > 3 6 5 4 1 2 > > >> [a, ai] = sort (x, 'descend') > > a = > > NaN Inf 3 2 1 -Inf > > > ai = > > 2 1 4 5 6 3 Now this isn't what I would have expected. I'd assumed that the NaN's were always sorted to the end. It seems that matlab always does an ascending sort and then a flip(lr|ud) or whatever... It might in fact be faster this way, but the advantage of always sorting the NaN's to the end would be that it is easier to drop them... For compatiability we shoudl probably do the same thing... Thanks D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Wed Sep 15 12:19:15 2004 Resent-Date: Wed, 15 Sep 2004 12:19:09 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16712.31061.779251.232503@devzero.bogus.domain> Date: Wed, 15 Sep 2004 13:18:13 -0400 To: Keith Goodman Cc: maintainers@octave.org Subject: Vectorizing strcmp In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 15-Sep-2004, Keith Goodman wrote: | On the one hand, it's nice that strcmp is a user-defined | function---it's easy to look at the code to see what it does. Perhaps it is easier because it is a user-defined function, but with Octave, unlike the other leading brand, you can always look at all of the source code for any of the functions. | On the other hand, the reason I'm looking at the code is that it is slow. | | I'm using strcmp(s1,s2) where s1 is a cell array of strings (around | 1000X1) and s2 is a string. | | Currently, in 2.1.58, strcmp does | | n = length(t1); | for i = 1:n | retval(i,:) = strcmp (t1{i}, s2); | endfor | | which recursively calls strcmp for two strings and where t1 is s1(:). | The for loop is slow. | | Short of making strcmp a built-in function, one way to speed it up is | to replace the for loop with a repmat like this | | c1 = char(t1); | [rc1, cc1] = size(c1); | ns2 = size(s2,2); | blank = ' '; | ms2 = repmat([s2 repmat(blank,1,max(cc1 - ns2, 0))], rc1, 1); | mc1 = [c1 repmat(blank,1,max(ns2 - cc1, 0))]; | retval2 = sum(mc1==ms2, 2)==size(mc1, 2); Wouldn't all (mc1 == ms2, 2) be better here? | The second code fragment is about 10 times faster than the first for | length(s1)==1000. For length(s1)==10 the speed is about the same. And | for length(s1) < 10 the first approach is faster. | | For me the added complexity in the code is more than offset by the | gain in speed. I think we need to be careful about using repmat in this way. If your cell array is large and the comparison string is fairly long, it could easily generate a matrix many megabytes in size. Following that with code that generates additional temporary arrays could cause trouble. Maybe it could be done in blocks rather than all at once? Or, perhaps it should be a builtin function. jwe From maintainers-request@octave.org Wed Sep 15 12:25:00 2004 Resent-Date: Wed, 15 Sep 2004 12:24:59 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <4148796F.6010808@tugraz.at> Date: Wed, 15 Sep 2004 19:18:39 +0200 From: Alois Schloegl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Bateman CC: Quentin Spencer , "John W. Eaton" , maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> <20040915160619.GA12502@zfr01-2089.crm.mot.com> <41486CA7.1060502@ieee.org> <20040915164712.GB12502@zfr01-2089.crm.mot.com> In-Reply-To: <20040915164712.GB12502@zfr01-2089.crm.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org David Bateman wrote: >According to Quentin Spencer (on 09/15/04): > > >>Output from MATLAB R14: >> >> >> >> >> >>>>x = [Inf, NaN, -Inf, 3, 2, 1]; >>>>[a, ai] = sort (x, 'ascend') >>>> >>>> >>a = >> >> -Inf 1 2 3 Inf NaN >> >> >>ai = >> >> 3 6 5 4 1 2 >> >> >> >>>>[a, ai] = sort (x, 'descend') >>>> >>>> >>a = >> >> NaN Inf 3 2 1 -Inf >> >> >>ai = >> >> 2 1 4 5 6 3 >> >> > > >Now this isn't what I would have expected. I'd assumed that the NaN's >were always sorted to the end. It seems that matlab always does an >ascending sort and then a flip(lr|ud) or whatever... It might in fact >be faster this way, but the advantage of always sorting the NaN's >to the end would be that it is easier to drop them... > >For compatiability we shoudl probably do the same thing... > > In this case, compatibility is not a "must". The result might differ already in the next version of matlab. If the position of NaN is important, its recommended doing explicit checks for NaN's - and if only for the sake of readibility of the code. - just my 2c - Alois From maintainers-request@octave.org Wed Sep 15 12:51:10 2004 Resent-Date: Wed, 15 Sep 2004 12:51:09 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16712.32784.482797.451725@devzero.bogus.domain> Date: Wed, 15 Sep 2004 13:46:56 -0400 To: Alois Schloegl Cc: David Bateman , Quentin Spencer , "John W. Eaton" , maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" In-Reply-To: <4148796F.6010808@tugraz.at> References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> <20040915160619.GA12502@zfr01-2089.crm.mot.com> <41486CA7.1060502@ieee.org> <20040915164712.GB12502@zfr01-2089.crm.mot.com> <4148796F.6010808@tugraz.at> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 15-Sep-2004, Alois Schloegl wrote: | In this case, compatibility is not a "must". The result might differ | already in the next version of matlab. That could be said for any Matlab feature. Why is this one different from any of the others? jwe From maintainers-request@octave.org Wed Sep 15 13:17:26 2004 Resent-Date: Wed, 15 Sep 2004 13:17:26 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: Date: Wed, 15 Sep 2004 11:16:22 -0700 From: Keith Goodman Reply-To: Keith Goodman To: "John W. Eaton" Subject: Re: Vectorizing strcmp Cc: maintainers@octave.org In-Reply-To: <16712.31061.779251.232503@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16712.31061.779251.232503@devzero.bogus.domain> X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Good point. How about this: The for loop is part of the problem. Another part is that the recursive call to strcmp needs three or four if statements to determine that we are asking for a strcmp between two strings. But we already know that they are strings since we are creating the strings from the cell. So we could replace for i = 1:n retval(i,:) = strcmp (t1{i}, s2); endfor with for i = 1:n retval(i,:) = isequal (t1 {i}, s2); endfor for a small but easy speed up. On Wed, 15 Sep 2004 13:18:13 -0400, John W. Eaton wrote: > On 15-Sep-2004, Keith Goodman wrote: > > | On the one hand, it's nice that strcmp is a user-defined > | function---it's easy to look at the code to see what it does. > > Perhaps it is easier because it is a user-defined function, but with > Octave, unlike the other leading brand, you can always look at all of > the source code for any of the functions. > > | On the other hand, the reason I'm looking at the code is that it is slow. > | > | I'm using strcmp(s1,s2) where s1 is a cell array of strings (around > | 1000X1) and s2 is a string. > | > | Currently, in 2.1.58, strcmp does > | > | n = length(t1); > | for i = 1:n > | retval(i,:) = strcmp (t1{i}, s2); > | endfor > | > | which recursively calls strcmp for two strings and where t1 is s1(:). > | The for loop is slow. > | > | Short of making strcmp a built-in function, one way to speed it up is > | to replace the for loop with a repmat like this > | > | c1 = char(t1); > | [rc1, cc1] = size(c1); > | ns2 = size(s2,2); > | blank = ' '; > | ms2 = repmat([s2 repmat(blank,1,max(cc1 - ns2, 0))], rc1, 1); > | mc1 = [c1 repmat(blank,1,max(ns2 - cc1, 0))]; > > | retval2 = sum(mc1==ms2, 2)==size(mc1, 2); > > Wouldn't > > all (mc1 == ms2, 2) > > be better here? > > | The second code fragment is about 10 times faster than the first for > | length(s1)==1000. For length(s1)==10 the speed is about the same. And > | for length(s1) < 10 the first approach is faster. > | > | For me the added complexity in the code is more than offset by the > | gain in speed. > > I think we need to be careful about using repmat in this way. If your > cell array is large and the comparison string is fairly long, it could > easily generate a matrix many megabytes in size. Following that with > code that generates additional temporary arrays could cause trouble. > Maybe it could be done in blocks rather than all at once? > > Or, perhaps it should be a builtin function. > > jwe > > From maintainers-request@octave.org Wed Sep 15 14:41:41 2004 Resent-Date: Wed, 15 Sep 2004 14:41:30 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 15 Sep 2004 21:40:31 +0200 From: David Bateman To: maintainers@octave.org Subject: Re: Cell arrays of strings in "sort" and "unique" Message-ID: <20040915194030.GC12502@zfr01-2089.crm.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org > If the position of NaN is important, its recommended doing explicit > checks for NaN's - and if only for the sake of readibility of the code. You've not read sort.cc lately :-) ... If floating format is IEEE754, doubles are cast as "long long unsigned int" and with a bit of magic the NaN's are sorted correctly, where the operator < alone won't do it. This little trick gains a speed factor of 2.5 is sort, but readable it is not. Cheers David -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Wed Sep 15 14:44:35 2004 Resent-Date: Wed, 15 Sep 2004 14:44:34 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 15 Sep 2004 21:43:49 +0200 From: David Bateman To: "John W. Eaton" Cc: maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" Message-ID: <20040915194349.GD12502@zfr01-2089.crm.mot.com> References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <16711.25079.152574.465546@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HOT_NASTY autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ok, then how about this patch to sort to that uses templates where possible, sorts on cell arrays of strings, makes sorting of complex values matlab compatiable, and adds a mode flag to define the direction of the sort. Patch is against the CVS (or rather against an older CVS with my previous sort patch applied), so it should apply cleanly. Cheers David -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=changelog-save-2 2004-09-15 David Bateman * oct-sort.h (void octave_sort::set_compare (bool (*comp) (T,T))): New function to set the comparison function for the sort. 2004-09-15 David Bateman * ov.cc (octave_value::octave_value (const ArrayN&, bool)): New Constructor . * ov.h (octave_value::octave_value (const ArrayN&, bool)): Declaration. * DLD-FUNCTIONS/sort.cc (sortmode): New enum to define direction of sort. (template class vec_index): New class to contain values and index for indexed sorts, replacing all previous struct versions. Instantiate for double, Complex, char and octave_value. (template static octave_value_list mx_sort (ArrayN &, int, sortmode)): New templated version of mx_sort replacing all previous versions, but specific to non indexed sorts. Instantiate for char and double if not IEEE754. (template <> static octave_value_list mx_sort (ArrayN &, int, sortmode)): Specialized function of mx_sort of IEEE754. (template static octave_value_list mx_sort_indexed (ArrayN &, int, sortmode)): New templated version of mx_sort for indexed sorts. Instantiate for double, Complex, char and octave_value. (ascending_compare, descending_compare): Comparison functions for double, char, vec_index *, vec_index *, vec_index *, vec_index. Fix Complex comparison operator to sort by arg of values if absolute values are equal. (Fsort): Update docs for new mode argument and for sorting of strings and cell arrays of strings. Implement mode argument to define ascending and descending sorts. Include sorting of cell arrays of strings. Adapt for new templated versions of the mx_sort function. --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.sort-2" *** ./liboctave/oct-sort.h.orig2 2004-09-15 00:22:12.000000000 +0200 --- ./liboctave/oct-sort.h 2004-09-15 11:10:39.000000000 +0200 *************** *** 116,121 **** --- 116,123 ---- ~octave_sort (void) { merge_freemem ( ); } + void set_compare (bool (*comp) (T, T)) { compare = comp; } + void sort (T *v, int elements); private: *** ./src/DLD-FUNCTIONS/sort.cc.orig2 2004-09-14 23:14:19.000000000 +0200 --- ./src/DLD-FUNCTIONS/sort.cc 2004-09-15 21:05:35.000000000 +0200 *************** *** 35,42 **** --- 35,200 ---- #include "lo-ieee.h" #include "data-conv.h" #include "ov-cx-mat.h" + #include "ov-cell.h" #include "oct-sort.cc" + enum sortmode {UNDEFINED, ASCENDING, DESCENDING}; + + template + class + vec_index + { + public: + T vec; + int indx; + }; + + template + static octave_value_list + mx_sort (ArrayN &m, int dim, sortmode mode = UNDEFINED) + { + octave_value_list retval; + + if (m.length () < 1) + return retval; + + dim_vector dv = m.dims (); + unsigned int ns = dv (dim); + unsigned int iter = dv.numel () / ns; + unsigned int stride = 1; + for (unsigned int i = 0; i < (unsigned int)dim; i++) + stride *= dv(i); + + T *v = m.fortran_vec (); + octave_sort sort; + + if (mode == ASCENDING) + sort.set_compare (ascending_compare); + else if (mode == DESCENDING) + sort.set_compare (descending_compare); + + if (stride == 1) + for (unsigned int j = 0; j < iter; j++) + { + sort.sort (v, ns); + v += ns; + } + else + { + OCTAVE_LOCAL_BUFFER (T, vi, ns); + for (unsigned int j = 0; j < iter; j++) + { + unsigned int offset = j; + unsigned int offset2 = 0; + while (offset >= stride) + { + offset -= stride; + offset2++; + } + offset += offset2 * stride * ns; + + for (unsigned int i = 0; i < ns; i++) + vi[i] = v[i*stride + offset]; + + sort.sort (vi, ns); + + for (unsigned int i = 0; i < ns; i++) + v[i*stride + offset] = vi[i]; + } + } + + retval (0) = octave_value (m); + return retval; + } + + template + static octave_value_list + mx_sort_indexed (ArrayN &m, int dim, sortmode mode = UNDEFINED) + { + octave_value_list retval; + + if (m.length () < 1) + return retval; + + dim_vector dv = m.dims (); + unsigned int ns = dv (dim); + unsigned int iter = dv.numel () / ns; + unsigned int stride = 1; + for (unsigned int i = 0; i < (unsigned int)dim; i++) + stride *= dv(i); + + T *v = m.fortran_vec (); + octave_sort *> indexed_sort; + + if (mode == ASCENDING) + indexed_sort.set_compare (ascending_compare); + else if (mode == DESCENDING) + indexed_sort.set_compare (descending_compare); + + OCTAVE_LOCAL_BUFFER (vec_index *, vi, ns); + OCTAVE_LOCAL_BUFFER (vec_index, vix, ns); + + for (unsigned int i = 0; i < ns; i++) + vi[i] = &vix[i]; + + NDArray idx (dv); + + if (stride == 1) + { + for (unsigned int j = 0; j < iter; j++) + { + unsigned int offset = j * ns; + + for (unsigned int i = 0; i < ns; i++) + { + vi[i]->vec = v[i]; + vi[i]->indx = i + 1; + } + + indexed_sort.sort (vi, ns); + + for (unsigned int i = 0; i < ns; i++) + { + v[i] = vi[i]->vec; + idx(i + offset) = vi[i]->indx; + } + v += ns; + } + } + else + { + for (unsigned int j = 0; j < iter; j++) + { + unsigned int offset = j; + unsigned int offset2 = 0; + while (offset >= stride) + { + offset -= stride; + offset2++; + } + offset += offset2 * stride * ns; + + for (unsigned int i = 0; i < ns; i++) + { + vi[i]->vec = v[i*stride + offset]; + vi[i]->indx = i + 1; + } + + indexed_sort.sort (vi, ns); + + for (unsigned int i = 0; i < ns; i++) + { + v[i*stride+offset] = vi[i]->vec; + idx(i*stride+offset) = vi[i]->indx; + } + } + } + + retval (1) = idx; + retval (0) = octave_value (m); + return retval; + } + // If we have IEEE 754 data format, then we can use the trick of // casting doubles as unsigned eight byte integers, and with a little // bit of magic we can automatically sort the NaN's correctly. *************** *** 56,114 **** return f ^ mask; } - struct vec_index - { - unsigned EIGHT_BYTE_INT vec; - int indx; - }; - bool ! ieee754_compare (vec_index *a, vec_index *b) { ! return (a->vec < b->vec); } - template class octave_sort; - template class octave_sort; - #else - struct vec_index - { - double vec; - int indx; - }; - bool ! double_compare (double a, double b) { ! return (xisnan(b) || (a < b)); } bool ! double_compare (vec_index *a, vec_index *b) { ! return (xisnan(b->vec) || (a->vec < b->vec)); } - template class octave_sort; - template class octave_sort; - #endif - - struct complex_vec_index - { - Complex vec; - int indx; - }; - bool ! complex_compare (complex_vec_index *a, complex_vec_index *b) { ! return (xisnan(b->vec) || (abs(a->vec) < abs(b->vec))); } ! template class octave_sort; static octave_value_list ! mx_sort (NDArray &m, bool return_idx, int dim) { octave_value_list retval; --- 214,254 ---- return f ^ mask; } bool ! ascending_compare (unsigned EIGHT_BYTE_INT a, ! unsigned EIGHT_BYTE_INT b) { ! return (a < b); } bool ! ascending_compare (vec_index *a, ! vec_index *b) { ! return (a->vec < b->vec); } bool ! descending_compare (unsigned EIGHT_BYTE_INT a, ! unsigned EIGHT_BYTE_INT b) { ! return (a > b); } bool ! descending_compare (vec_index *a, ! vec_index *b) { ! return (a->vec > b->vec); } ! template class octave_sort; ! template class vec_index; ! template class octave_sort *>; + template <> static octave_value_list ! mx_sort (ArrayN &m, int dim, sortmode mode) { octave_value_list retval; *************** *** 122,397 **** for (unsigned int i = 0; i < (unsigned int)dim; i++) stride *= dv(i); - #if defined (HAVE_IEEE754_DATA_FORMAT) && defined (EIGHT_BYTE_INT) double *v = m.fortran_vec (); unsigned EIGHT_BYTE_INT *p = (unsigned EIGHT_BYTE_INT *)v; ! if (return_idx) ! { ! octave_sort indexed_ieee754_sort (ieee754_compare); ! OCTAVE_LOCAL_BUFFER (vec_index *, vi, ns); ! OCTAVE_LOCAL_BUFFER (vec_index, vix, ns); ! ! for (unsigned int i = 0; i < ns; i++) ! vi[i] = &vix[i]; ! NDArray idx (dv); ! for (unsigned int j = 0; j < iter; j++) { - unsigned int offset = j; - unsigned int offset2 = 0; - while (offset >= stride) - { - offset -= stride; - offset2++; - } - offset += offset2 * stride * ns; - // Flip the data in the vector so that int compares on // IEEE754 give the correct ordering. for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = FloatFlip (p[i*stride + offset]); ! vi[i]->indx = i + 1; ! } ! ! indexed_ieee754_sort.sort (vi, ns); ! // Flip the data out of the vector so that int compares on ! // IEEE754 give the correct ordering for (unsigned int i = 0; i < ns; i++) ! { ! p[i*stride + offset] = IFloatFlip (vi[i]->vec); ! idx(i*stride + offset) = vi[i]->indx; ! } ! // There are two representations of NaN. One will be sorted ! // to the beginning of the vector and the other to the end. ! // If it will be sorted to the beginning, fix things up. ! if (lo_ieee_signbit (octave_NaN)) { unsigned int i = 0; ! while (xisnan(v[i++*stride+offset]) && i < ns); ! OCTAVE_LOCAL_BUFFER (double, itmp, i - 1); ! for (unsigned int l = 0; l < i -1; l++) ! itmp[l] = idx(l*stride + offset); for (unsigned int l = 0; l < ns - i + 1; l++) ! { ! v[l*stride + offset] = v[(l+i-1)*stride + offset]; ! idx(l*stride + offset) = idx((l+i-1)*stride + offset); ! } ! for (unsigned int k = 0, l = ns - i + 1; l < ns; l++, k++) ! { ! v[l*stride + offset] = octave_NaN; ! idx(l*stride + offset) = itmp[k]; ! } } } - retval (1) = idx; } else { ! octave_sort ieee754_sort; ! ! if (stride == 1) ! { ! for (unsigned int j = 0; j < iter; j++) ! { ! // Flip the data in the vector so that int compares on ! // IEEE754 give the correct ordering. ! ! for (unsigned int i = 0; i < ns; i++) ! p[i] = FloatFlip (p[i]); ! ! ieee754_sort.sort (p, ns); ! ! // Flip the data out of the vector so that int compares ! // on IEEE754 give the correct ordering. ! ! for (unsigned int i = 0; i < ns; i++) ! p[i] = IFloatFlip (p[i]); ! ! // There are two representations of NaN. One will be ! // sorted to the beginning of the vector and the other ! // to the end. If it will be sorted to the beginning, ! // fix things up. ! ! if (lo_ieee_signbit (octave_NaN)) ! { ! unsigned int i = 0; ! double *vtmp = (double *)p; ! while (xisnan(vtmp[i++]) && i < ns); ! for (unsigned int l = 0; l < ns - i + 1; l++) ! vtmp[l] = vtmp[l+i-1]; ! for (unsigned int l = ns - i + 1; l < ns; l++) ! vtmp[l] = octave_NaN; ! } ! ! p += ns; ! } ! } ! else { ! OCTAVE_LOCAL_BUFFER (unsigned EIGHT_BYTE_INT, vi, ns); ! ! for (unsigned int j = 0; j < iter; j++) { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) ! { ! offset -= stride; ! offset2++; ! } ! offset += offset2 * stride * ns; ! ! // Flip the data in the vector so that int compares on ! // IEEE754 give the correct ordering. ! ! for (unsigned int i = 0; i < ns; i++) ! vi[i] = FloatFlip (p[i*stride + offset]); ! ! ieee754_sort.sort (vi, ns); ! ! // Flip the data out of the vector so that int compares ! // on IEEE754 give the correct ordering. ! ! for (unsigned int i = 0; i < ns; i++) ! p[i*stride + offset] = IFloatFlip (vi[i]); ! ! // There are two representations of NaN. One will be ! // sorted to the beginning of the vector and the other ! // to the end. If it will be sorted to the beginning, ! // fix things up. ! ! if (lo_ieee_signbit (octave_NaN)) ! { ! unsigned int i = 0; ! while (xisnan(v[i++*stride + offset]) && i < ns); ! for (unsigned int l = 0; l < ns - i + 1; l++) ! v[l*stride + offset] = v[(l+i-1)*stride + offset]; ! for (unsigned int l = ns - i + 1; l < ns; l++) ! v[l*stride + offset] = octave_NaN; ! } } ! } ! } ! #else ! if (return_idx) ! { ! double *v = m.fortran_vec (); ! octave_sort indexed_double_sort (double_compare); ! OCTAVE_LOCAL_BUFFER (vec_index *, vi, ns); ! OCTAVE_LOCAL_BUFFER (vec_index, vix, ns); ! for (unsigned int i = 0; i < ns; i++) ! vi[i] = &vix[i]; ! NDArray idx (dv); ! ! if (stride == 1) ! { ! for (unsigned int j = 0; j < iter; j++) ! { ! unsigned int offset = j * ns; ! for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = v[i]; ! vi[i]->indx = i + 1; ! } ! indexed_double_sort.sort (vi, ns); ! ! for (unsigned int i = 0; i < ns; i++) ! { ! v[i] = vi[i]->vec; ! idx(i + offset) = vi[i]->indx; ! } ! v += ns; ! } ! } ! else ! { ! for (unsigned int j = 0; j < iter; j++) ! { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) ! { ! offset -= stride; ! offset2++; ! } ! offset += offset2 * stride * ns; ! for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = v[i*stride + offset]; ! vi[i]->indx = i + 1; ! } ! indexed_double_sort.sort (vi, ns); ! ! for (unsigned int i = 0; i < ns; i++) ! { ! v[i*stride+offset] = vi[i]->vec; ! idx(i*stride+offset) = vi[i]->indx; ! } ! } ! } ! retval (1) = idx; ! } ! else ! { ! double *v = m.fortran_vec (); ! octave_sort double_sort (double_compare); ! ! if (stride == 1) ! for (unsigned int j = 0; j < iter; j++) ! { ! double_sort.sort (v, ns); ! v += ns; ! } ! else ! { ! OCTAVE_LOCAL_BUFFER (double, vi, ns); ! for (unsigned int j = 0; j < iter; j++) { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) ! { ! offset -= stride; ! offset2++; ! } ! offset += offset2 * stride * ns; ! ! for (unsigned int i = 0; i < ns; i++) ! vi[i] = v[i*stride + offset]; ! ! double_sort.sort (vi, ns); ! ! for (unsigned int i = 0; i < ns; i++) ! v[i*stride + offset] = vi[i]; } } } ! #endif retval(0) = m; return retval; } static octave_value_list ! mx_sort (ComplexNDArray &m, bool return_idx, int dim) { octave_value_list retval; --- 262,371 ---- for (unsigned int i = 0; i < (unsigned int)dim; i++) stride *= dv(i); double *v = m.fortran_vec (); unsigned EIGHT_BYTE_INT *p = (unsigned EIGHT_BYTE_INT *)v; ! octave_sort sort; ! if (mode == ASCENDING) ! sort.set_compare (ascending_compare); ! else if (mode == DESCENDING) ! sort.set_compare (descending_compare); ! if (stride == 1) ! { for (unsigned int j = 0; j < iter; j++) { // Flip the data in the vector so that int compares on // IEEE754 give the correct ordering. for (unsigned int i = 0; i < ns; i++) ! p[i] = FloatFlip (p[i]); ! ! sort.sort (p, ns); ! // Flip the data out of the vector so that int compares ! // on IEEE754 give the correct ordering. for (unsigned int i = 0; i < ns; i++) ! p[i] = IFloatFlip (p[i]); ! // There are two representations of NaN. One will be ! // sorted to the beginning of the vector and the other ! // to the end. If it will be sorted to the beginning, ! // fix things up. ! if ((lo_ieee_signbit (octave_NaN) && (mode == ASCENDING)) || ! (! lo_ieee_signbit (octave_NaN) && (mode == DESCENDING))) { unsigned int i = 0; ! double *vtmp = (double *)p; ! while (xisnan(vtmp[i++]) && i < ns); for (unsigned int l = 0; l < ns - i + 1; l++) ! vtmp[l] = vtmp[l+i-1]; ! for (unsigned int l = ns - i + 1; l < ns; l++) ! vtmp[l] = octave_NaN; } + + p += ns; } } else { ! OCTAVE_LOCAL_BUFFER (unsigned EIGHT_BYTE_INT, vi, ns); ! for (unsigned int j = 0; j < iter; j++) { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) { ! offset -= stride; ! offset2++; } ! offset += offset2 * stride * ns; ! // Flip the data in the vector so that int compares on ! // IEEE754 give the correct ordering. ! for (unsigned int i = 0; i < ns; i++) ! vi[i] = FloatFlip (p[i*stride + offset]); ! sort.sort (vi, ns); ! // Flip the data out of the vector so that int compares ! // on IEEE754 give the correct ordering. ! for (unsigned int i = 0; i < ns; i++) ! p[i*stride + offset] = IFloatFlip (vi[i]); ! // There are two representations of NaN. One will be ! // sorted to the beginning of the vector and the other ! // to the end. If it will be sorted to the beginning, ! // fix things up. ! if ((lo_ieee_signbit (octave_NaN) && (mode == ASCENDING)) || ! (! lo_ieee_signbit (octave_NaN) && (mode == DESCENDING))) { ! unsigned int i = 0; ! while (xisnan(v[i++*stride + offset]) && i < ns); ! for (unsigned int l = 0; l < ns - i + 1; l++) ! v[l*stride + offset] = v[(l+i-1)*stride + offset]; ! for (unsigned int l = ns - i + 1; l < ns; l++) ! v[l*stride + offset] = octave_NaN; } } } ! retval(0) = m; return retval; } + template <> static octave_value_list ! mx_sort_indexed (ArrayN &m, int dim, sortmode mode) { octave_value_list retval; *************** *** 405,636 **** for (unsigned int i = 0; i < (unsigned int)dim; i++) stride *= dv(i); ! octave_sort indexed_double_sort (complex_compare); ! Complex *v = m.fortran_vec (); ! OCTAVE_LOCAL_BUFFER (complex_vec_index *, vi, ns); ! OCTAVE_LOCAL_BUFFER (complex_vec_index, vix, ns); for (unsigned int i = 0; i < ns; i++) vi[i] = &vix[i]; NDArray idx (dv); ! ! if (stride == 1) { ! for (unsigned int j = 0; j < iter; j++) { ! unsigned int offset = j * ns; ! for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = v[i]; ! vi[i]->indx = i + 1; ! } ! ! indexed_double_sort.sort (vi, ns); ! ! if (return_idx) ! { ! for (unsigned int i = 0; i < ns; i++) ! { ! v[i] = vi[i]->vec; ! idx(i + offset) = vi[i]->indx; ! } ! } ! else ! { ! for (unsigned int i = 0; i < ns; i++) ! v[i] = vi[i]->vec; ! } ! v += ns; } ! } ! else ! { ! for (unsigned int j = 0; j < iter; j++) { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) ! { ! offset -= stride; ! offset2++; ! } ! offset += offset2 * stride * ns; ! for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = v[i*stride + offset]; ! vi[i]->indx = i + 1; ! } ! ! indexed_double_sort.sort (vi, ns); ! ! if (return_idx) { ! for (unsigned int i = 0; i < ns; i++) ! { ! v[i*stride + offset] = vi[i]->vec; ! idx(i*stride + offset) = vi[i]->indx; ! } } ! else { ! for (unsigned int i = 0; i < ns; i++) ! v[i*stride + offset] = vi[i]->vec; } } } ! if (return_idx) ! retval (1) = idx; ! ! retval(0) = m; ! return retval; } ! struct char_vec_index { ! char vec; ! int indx; ! }; bool ! char_compare (char_vec_index *a, char_vec_index *b) { ! return (a->vec < b->vec); } ! template class octave_sort; ! template class octave_sort; static octave_value_list ! mx_sort (charNDArray &m, bool return_idx, int dim) { ! octave_value_list retval; ! if (m.length () < 1) ! return retval; ! dim_vector dv = m.dims (); ! unsigned int ns = dv (dim); ! unsigned int iter = dv.numel () / ns; ! unsigned int stride = 1; ! for (unsigned int i = 0; i < (unsigned int)dim; i++) ! stride *= dv(i); ! if (return_idx) ! { ! char *v = m.fortran_vec (); ! octave_sort indexed_char_sort (char_compare); ! OCTAVE_LOCAL_BUFFER (char_vec_index *, vi, ns); ! OCTAVE_LOCAL_BUFFER (char_vec_index, vix, ns); ! for (unsigned int i = 0; i < ns; i++) ! vi[i] = &vix[i]; ! NDArray idx (dv); ! ! if (stride == 1) ! { ! for (unsigned int j = 0; j < iter; j++) ! { ! unsigned int offset = j * ns; ! for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = v[i]; ! vi[i]->indx = i + 1; ! } ! indexed_char_sort.sort (vi, ns); ! ! for (unsigned int i = 0; i < ns; i++) ! { ! v[i] = vi[i]->vec; ! idx(i + offset) = vi[i]->indx; ! } ! v += ns; ! } ! } ! else ! { ! for (unsigned int j = 0; j < iter; j++) ! { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) ! { ! offset -= stride; ! offset2++; ! } ! offset += offset2 * stride * ns; ! ! for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = v[i*stride + offset]; ! vi[i]->indx = i + 1; ! } ! indexed_char_sort.sort (vi, ns); ! ! for (unsigned int i = 0; i < ns; i++) ! { ! v[i*stride+offset] = vi[i]->vec; ! idx(i*stride+offset) = vi[i]->indx; ! } ! } ! } ! retval (1) = idx; ! } ! else ! { ! char *v = m.fortran_vec (); ! octave_sort char_sort; ! if (stride == 1) ! for (unsigned int j = 0; j < iter; j++) ! { ! char_sort.sort (v, ns); ! v += ns; ! } ! else ! { ! OCTAVE_LOCAL_BUFFER (char, vi, ns); ! for (unsigned int j = 0; j < iter; j++) ! { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) ! { ! offset -= stride; ! offset2++; ! } ! offset += offset2 * stride * ns; ! for (unsigned int i = 0; i < ns; i++) ! vi[i] = v[i*stride + offset]; ! char_sort.sort (vi, ns); ! ! for (unsigned int i = 0; i < ns; i++) ! v[i*stride + offset] = vi[i]; ! } ! } ! } ! retval(0) = octave_value (m, true); ! return retval; } DEFUN_DLD (sort, args, nargout, "-*- texinfo -*-\n\ @deftypefn {Loadable Function} {[@var{s}, @var{i}] =} sort (@var{x})\n\ @deftypefnx {Loadable Function} {[@var{s}, @var{i}] =} sort (@var{x}, @var{dim})\n\ Return a copy of @var{x} with the elements elements arranged in\n\ increasing order. For matrices, @code{sort} orders the elements in each\n\ column.\n\ --- 379,593 ---- for (unsigned int i = 0; i < (unsigned int)dim; i++) stride *= dv(i); ! double *v = m.fortran_vec (); ! ! unsigned EIGHT_BYTE_INT *p = (unsigned EIGHT_BYTE_INT *)v; ! octave_sort *> indexed_sort; ! if (mode == ASCENDING) ! indexed_sort.set_compare (ascending_compare); ! else if (mode == DESCENDING) ! indexed_sort.set_compare (descending_compare); + OCTAVE_LOCAL_BUFFER (vec_index *, vi, ns); + OCTAVE_LOCAL_BUFFER (vec_index, vix, ns); + for (unsigned int i = 0; i < ns; i++) vi[i] = &vix[i]; NDArray idx (dv); ! ! for (unsigned int j = 0; j < iter; j++) { ! unsigned int offset = j; ! unsigned int offset2 = 0; ! while (offset >= stride) { ! offset -= stride; ! offset2++; ! } ! offset += offset2 * stride * ns; ! // Flip the data in the vector so that int compares on ! // IEEE754 give the correct ordering. ! ! for (unsigned int i = 0; i < ns; i++) ! { ! vi[i]->vec = FloatFlip (p[i*stride + offset]); ! vi[i]->indx = i + 1; } ! ! indexed_sort.sort (vi, ns); ! ! // Flip the data out of the vector so that int compares on ! // IEEE754 give the correct ordering ! ! for (unsigned int i = 0; i < ns; i++) { ! p[i*stride + offset] = IFloatFlip (vi[i]->vec); ! idx(i*stride + offset) = vi[i]->indx; ! } ! // There are two representations of NaN. One will be sorted ! // to the beginning of the vector and the other to the end. ! // If it will be sorted to the beginning, fix things up. ! ! if ((lo_ieee_signbit (octave_NaN) && (mode == ASCENDING)) || ! (! lo_ieee_signbit (octave_NaN) && (mode == DESCENDING))) ! { ! unsigned int i = 0; ! while (xisnan(v[i++*stride+offset]) && i < ns); ! OCTAVE_LOCAL_BUFFER (double, itmp, i - 1); ! for (unsigned int l = 0; l < i -1; l++) ! itmp[l] = idx(l*stride + offset); ! for (unsigned int l = 0; l < ns - i + 1; l++) { ! v[l*stride + offset] = v[(l+i-1)*stride + offset]; ! idx(l*stride + offset) = idx((l+i-1)*stride + offset); } ! for (unsigned int k = 0, l = ns - i + 1; l < ns; l++, k++) { ! v[l*stride + offset] = octave_NaN; ! idx(l*stride + offset) = itmp[k]; } } } ! retval (1) = idx; ! retval (0) = m; return retval; } ! #else ! ! bool ! ascending_compare (double a, double b) { ! return (xisnan(b) || (a < b)); ! } bool ! ascending_compare (vec_index *a, vec_index *b) { ! return (xisnan(b->vec) || (a->vec < b->vec)); } ! bool ! descending_compare (double a, double b) ! { ! return (xisnan(a) || (a > b)); ! } + bool + descending_compare (vec_index *a, vec_index *b) + { + return (xisnan(a->vec) || (a->vec > b->vec)); + } + + template class octave_sort; + template class vec_index; + template class octave_sort *>; + + #if !defined (CXX_NEW_FRIEND_TEMPLATE_DECL) static octave_value_list ! mx_sort (ArrayN &m, int dim, sortmode mode); ! ! static octave_value_list ! mx_sort_indexed (ArrayN &m, int dim, sortmode mode); ! #endif ! #endif ! ! // std::abs(Inf) returns NaN!! ! static inline double ! xabs (const Complex& x) { ! return (xisinf (x.real ()) || xisinf (x.imag ())) ? octave_Inf : abs (x); ! } ! bool ! ascending_compare (vec_index *a, vec_index *b) ! { ! return (xisnan(b->vec) || (xabs(a->vec) < xabs(b->vec)) || ! ((xabs(a->vec) == xabs(b->vec)) && (arg(a->vec) < arg(b->vec)))); ! } ! bool ! descending_compare (vec_index *a, vec_index *b) ! { ! return (xisnan(a->vec) || (xabs(a->vec) > xabs(b->vec)) || ! ((xabs(a->vec) == xabs(b->vec)) && (arg(a->vec) > arg(b->vec)))); ! } ! template class vec_index; ! template class octave_sort *>; ! #if !defined (CXX_NEW_FRIEND_TEMPLATE_DECL) ! static octave_value_list ! mx_sort_indexed (ArrayN &m, int dim, sortmode mode); ! #endif ! bool ! ascending_compare (char a, char b) ! { ! return (a < b); ! } ! bool ! ascending_compare (vec_index *a, vec_index *b) ! { ! return (a->vec < b->vec); ! } ! bool ! descending_compare (char a, char b) ! { ! return (a > b); ! } ! bool ! descending_compare (vec_index *a, vec_index *b) ! { ! return (a->vec > b->vec); ! } ! template class octave_sort; ! template class vec_index; ! template class octave_sort *>; ! #if !defined (CXX_NEW_FRIEND_TEMPLATE_DECL) ! static octave_value_list ! mx_sort (ArrayN &m, int dim, sortmode mode); ! static octave_value_list ! mx_sort_indexed (ArrayN &m, int dim, sortmode mode); ! #endif ! bool ! ascending_compare (vec_index *a, vec_index *b) ! { ! return (a->vec.string_value () < b->vec.string_value ()); ! } ! bool ! descending_compare (vec_index *a, vec_index *b) ! { ! return (a->vec.string_value () > b->vec.string_value ()); } + template class vec_index; + template class octave_sort *>; + + #if !defined (CXX_NEW_FRIEND_TEMPLATE_DECL) + static octave_value_list + mx_sort_indexed (ArrayN &m, int dim, sortmode mode); + #endif + DEFUN_DLD (sort, args, nargout, "-*- texinfo -*-\n\ @deftypefn {Loadable Function} {[@var{s}, @var{i}] =} sort (@var{x})\n\ @deftypefnx {Loadable Function} {[@var{s}, @var{i}] =} sort (@var{x}, @var{dim})\n\ + @deftypefnx {Loadable Function} {[@var{s}, @var{i}] =} sort (@dots{}, @var{mode})\n\ Return a copy of @var{x} with the elements elements arranged in\n\ increasing order. For matrices, @code{sort} orders the elements in each\n\ column.\n\ *************** *** 663,673 **** @end example\n\ \n\ If the optional argument @var{dim} is given, then the matrix is sorted\n\ ! along the dimension defined by @var{dim}.\n\ \n\ For equal elements, the indices are such that the equal elements are listed\n\ in the order that appeared in the original list.\n\ \n\ The algorithm used in @code{sort} is optimized for the sorting of partially\n\ ordered lists.\n\ @end deftypefn") --- 620,635 ---- @end example\n\ \n\ If the optional argument @var{dim} is given, then the matrix is sorted\n\ ! along the dimension defined by @var{dim}. The optional argument @code{mode}\n\ ! defines the order in which the values will be sorted. Valid values of\n\ ! @code{mode} are `ascend' or `descend'.\n\ \n\ For equal elements, the indices are such that the equal elements are listed\n\ in the order that appeared in the original list.\n\ \n\ + The @code{sort} function may also be used to sort strings and cell arrays\n\ + of strings, it which case the dictionary order of the strings is used.\n\ + \n\ The algorithm used in @code{sort} is optimized for the sorting of partially\n\ ordered lists.\n\ @end deftypefn") *************** *** 675,682 **** octave_value_list retval; int nargin = args.length (); ! if (nargin != 1 && nargin != 2) { print_usage ("sort"); return retval; --- 637,645 ---- octave_value_list retval; int nargin = args.length (); + sortmode smode = ASCENDING; ! if (nargin < 1 && nargin > 3) { print_usage ("sort"); return retval; *************** *** 687,694 **** octave_value arg = args(0); int dim = 0; ! if (nargin == 2) ! dim = args(1).nint_value () - 1; dim_vector dv = ((const octave_complex_matrix&) arg) .dims (); if (error_state) --- 650,698 ---- octave_value arg = args(0); int dim = 0; ! if (nargin > 1) ! { ! if (args(1).is_string ()) ! { ! std::string mode = args(1).string_value(); ! if (mode == "ascend") ! smode = ASCENDING; ! else if (mode == "descend") ! smode = DESCENDING; ! else ! { ! error ("sort: mode must be either `ascend' or `descend'"); ! return retval; ! } ! } ! else ! dim = args(1).nint_value () - 1; ! } ! ! if (nargin > 2) ! { ! if (args(1).is_string ()) ! { ! print_usage ("sort"); ! return retval; ! } ! ! if (! args(2).is_string ()) ! { ! error ("sort: mode must be a string"); ! return retval; ! } ! std::string mode = args(2).string_value(); ! if (mode == "ascend") ! smode = ASCENDING; ! else if (mode == "descend") ! smode = DESCENDING; ! else ! { ! error ("sort: mode must be either `ascend' or `descend'"); ! return retval; ! } ! } dim_vector dv = ((const octave_complex_matrix&) arg) .dims (); if (error_state) *************** *** 696,702 **** gripe_wrong_type_arg ("sort", arg); return retval; } ! if (nargin != 2) { // Find first non singleton dimension for (int i = 0; i < dv.length (); i++) --- 700,706 ---- gripe_wrong_type_arg ("sort", arg); return retval; } ! if (nargin == 1 || args(1).is_string ()) { // Find first non singleton dimension for (int i = 0; i < dv.length (); i++) *************** *** 720,740 **** NDArray m = arg.array_value (); if (! error_state) ! retval = mx_sort (m, return_idx, dim); } else if (arg.is_complex_type ()) { ComplexNDArray cm = arg.complex_array_value (); if (! error_state) ! retval = mx_sort (cm, return_idx, dim); } else if (arg.is_string ()) { charNDArray chm = arg.char_array_value (); if (! error_state) ! retval = mx_sort (chm, return_idx, dim); } else gripe_wrong_type_arg ("sort", arg); --- 724,790 ---- NDArray m = arg.array_value (); if (! error_state) ! { ! #ifdef HAVE_IEEE754_DATA_FORMAT ! // As operator > gives the right result, can special case here ! if (! return_idx && smode == ASCENDING) ! retval = mx_sort (m, dim); ! else ! #endif ! { ! if (return_idx) ! retval = mx_sort_indexed (m, dim, smode); ! else ! retval = mx_sort (m, dim, smode); ! } ! } } else if (arg.is_complex_type ()) { ComplexNDArray cm = arg.complex_array_value (); + // Don't have unindexed version as no ">" operator if (! error_state) ! retval = mx_sort_indexed (cm, dim, smode); } else if (arg.is_string ()) { charNDArray chm = arg.char_array_value (); if (! error_state) ! { ! // As operator > gives the right result, can special case here ! if (! return_idx && smode == ASCENDING) ! retval = mx_sort (chm, dim); ! else ! { ! if (return_idx) ! retval = mx_sort_indexed (chm, dim, smode); ! else ! retval = mx_sort (chm, dim, smode); ! } ! ! // XXX FIXME XXX It would have been better to call ! // "octave_value(m, true)" but how can that be done ! // within the template ! retval(0) = retval(0).convert_to_str (false, true); ! } ! } ! else if (arg.is_cell ()) ! { ! Cell cellm = arg.cell_value (); ! ! // Need to check that all elements are strings ! for (int i = 0; i < cellm.numel (); i++) ! if (! cellm(i).is_string ()) ! { ! gripe_wrong_type_arg ("sort", arg); ! break; ! } ! ! // Don't have unindexed version as ">" operator doesn't return bool ! if (!error_state) ! retval = mx_sort_indexed (cellm, dim, smode); } else gripe_wrong_type_arg ("sort", arg); *** ./src/ov.h.orig2 2004-09-15 14:27:15.000000000 +0200 --- ./src/ov.h 2004-09-15 14:27:07.000000000 +0200 *************** *** 217,222 **** --- 217,223 ---- octave_value (const string_vector& s); octave_value (const charMatrix& chm, bool is_string = false); octave_value (const charNDArray& chnda, bool is_string = false); + octave_value (const ArrayN& chnda, bool is_string = false); octave_value (const octave_int8& i); octave_value (const octave_int16& i); octave_value (const octave_int32& i); *** ./src/ov.cc.orig2 2004-09-15 14:27:19.000000000 +0200 --- ./src/ov.cc 2004-09-15 14:27:06.000000000 +0200 *************** *** 597,602 **** --- 597,611 ---- maybe_mutate (); } + octave_value::octave_value (const ArrayN& chm, bool is_str) + : rep (is_str + ? new octave_char_matrix_str (chm) + : new octave_char_matrix (chm)) + { + rep->count = 1; + maybe_mutate (); + } + octave_value::octave_value (const octave_int8& i) : rep (new octave_int8_scalar (i)) { --pf9I7BMVVzbSWLtt-- From maintainers-request@octave.org Wed Sep 15 16:47:57 2004 Resent-Date: Wed, 15 Sep 2004 16:47:53 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Subject: double(true) not implemented From: Josep =?ISO-8859-1?Q?Mon=E9s?= i Teixidor To: maintainers@octave.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IJOMZCHVt4zhtVQuRMUS" Message-Id: <1095284779.21696.85.camel@ottoana.fakedomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 23:46:21 +0200 Sender: =?iso-8859-1?Q?Josep_Mon=E9s_i_Teixidor?= X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at aprop.net X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org --=-IJOMZCHVt4zhtVQuRMUS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Perhaps this is being worked on but in case nobody noticed explicit conversion from logical to double fails (although implicit conversion works as a workaround by now): octave:1> double(true) error: invalid conversion from bool to scalar octave:1> true+0 ans =3D 1 Regards, --=20 Josep Mon=E9s i Teixidor Clau GnuPG: gpg --recv-keys 80E85CC4 --=-IJOMZCHVt4zhtVQuRMUS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBSLgpMVjIwYDoXMQRAs6TAJ9t+CizAiC6hasuKVh5H2hx4CLgSQCfY+FS gsXYY0QiwDma6/OGuHL6Nfc= =A+mS -----END PGP SIGNATURE----- --=-IJOMZCHVt4zhtVQuRMUS-- From maintainers-request@octave.org Wed Sep 15 20:11:05 2004 Resent-Date: Wed, 15 Sep 2004 20:11:04 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16712.59380.550293.893905@devzero.bogus.domain> Date: Wed, 15 Sep 2004 21:10:12 -0400 To: Josep =?ISO-8859-1?Q?Mon=E9s?= i Teixidor Cc: maintainers@octave.org Subject: double(true) not implemented In-Reply-To: <1095284779.21696.85.camel@ottoana.fakedomain> References: <1095284779.21696.85.camel@ottoana.fakedomain> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 15-Sep-2004, Josep Mon=E9s i Teixidor wrote: | Perhaps this is being worked on but in case nobody noticed explicit | conversion from logical to double fails (although implicit conversion= | works as a workaround by now): |=20 | octave:1> double(true) | error: invalid conversion from bool to scalar | octave:1> true+0 | ans =3D 1 Please try the following patch. This will also make things like int32 (true) work. Thanks, jwe src/ChangeLog: 2004-09-15 John W. Eaton =09* OPERATORS/op-int-conv.cc: Define and install bool to int =09conversions. =09* OPERATORS/op-double-conv.cc: Define and install bool to double =09conversions. =20 Index: src/OPERATORS/op-double-conv.cc =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: /usr/local/cvsroot/octave/src/OPERATORS/op-double-conv.cc,v retrieving revision 1.1 diff -u -r1.1 op-double-conv.cc --- a/src/OPERATORS/op-double-conv.cc=0914 Jun 2004 18:33:02 -0000=091.= 1 +++ b/src/OPERATORS/op-double-conv.cc=0916 Sep 2004 01:05:26 -0000 @@ -39,6 +39,8 @@ #include "ov-uint16.h" #include "ov-uint32.h" #include "ov-uint64.h" +#include "ov-bool.h" +#include "ov-bool-mat.h" #include "ov-scalar.h" #include "ov-re-mat.h" #include "ov-typeinfo.h" @@ -66,6 +68,9 @@ DEFDBLCONVFN (uint32=5Fscalar=5Fto=5Fdouble=5Fmatrix, uint32=5Fscalar,= uint32=5Farray) DEFDBLCONVFN (uint64=5Fscalar=5Fto=5Fdouble=5Fmatrix, uint64=5Fscalar,= uint64=5Farray) =20 +DEFDBLCONVFN (bool=5Fmatrix=5Fto=5Fdouble=5Fmatrix, bool=5Fmatrix, boo= l=5Farray) +DEFDBLCONVFN (bool=5Fscalar=5Fto=5Fdouble=5Fmatrix, bool, bool=5Farray= ) + DEFDBLCONVFN (double=5Fscalar=5Fto=5Fdouble=5Fmatrix, scalar, array) =20 void @@ -91,6 +96,9 @@ INSTALL=5FCONVOP (octave=5Fuint32=5Fscalar, octave=5Fmatrix, uint32=5F= scalar=5Fto=5Fdouble=5Fmatrix); INSTALL=5FCONVOP (octave=5Fuint64=5Fscalar, octave=5Fmatrix, uint64=5F= scalar=5Fto=5Fdouble=5Fmatrix); =20 + INSTALL=5FCONVOP (octave=5Fbool=5Fmatrix, octave=5Fmatrix, bool=5Fma= trix=5Fto=5Fdouble=5Fmatrix); + INSTALL=5FCONVOP (octave=5Fbool, octave=5Fmatrix, bool=5Fscalar=5Fto= =5Fdouble=5Fmatrix); + INSTALL=5FCONVOP (octave=5Fscalar, octave=5Fmatrix, double=5Fscalar=5F= to=5Fdouble=5Fmatrix); } =20 @@ -98,4 +106,4 @@ ;;; Local Variables: *** ;;; mode: C++ *** ;;; End: *** -*/ +p*/ Index: src/OPERATORS/op-int-conv.cc =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: /usr/local/cvsroot/octave/src/OPERATORS/op-int-conv.cc,v retrieving revision 1.3 diff -u -r1.3 op-int-conv.cc --- a/src/OPERATORS/op-int-conv.cc=091 Sep 2004 00:49:06 -0000=091.3 +++ b/src/OPERATORS/op-int-conv.cc=0916 Sep 2004 01:05:26 -0000 @@ -40,6 +40,8 @@ #include "ov-uint32.h" #include "ov-uint64.h" #include "ov-range.h" +#include "ov-bool.h" +#include "ov-bool-mat.h" #include "ov-scalar.h" #include "ov-re-mat.h" #include "ov-typeinfo.h" @@ -67,6 +69,26 @@ DEFCONVFN (matrix=5Fto=5Fuint32, matrix, uint32) DEFCONVFN (matrix=5Fto=5Fuint64, matrix, uint64) =20 +DEFCONVFN (bool=5Fto=5Fint8, bool, int8) +DEFCONVFN (bool=5Fto=5Fint16, bool, int16) +DEFCONVFN (bool=5Fto=5Fint32, bool, int32) +DEFCONVFN (bool=5Fto=5Fint64, bool, int64) + +DEFCONVFN (bool=5Fto=5Fuint8, bool, uint8) +DEFCONVFN (bool=5Fto=5Fuint16, bool, uint16) +DEFCONVFN (bool=5Fto=5Fuint32, bool, uint32) +DEFCONVFN (bool=5Fto=5Fuint64, bool, uint64) + +DEFCONVFN (bool=5Fmatrix=5Fto=5Fint8, bool=5Fmatrix, int8) +DEFCONVFN (bool=5Fmatrix=5Fto=5Fint16, bool=5Fmatrix, int16) +DEFCONVFN (bool=5Fmatrix=5Fto=5Fint32, bool=5Fmatrix, int32) +DEFCONVFN (bool=5Fmatrix=5Fto=5Fint64, bool=5Fmatrix, int64) + +DEFCONVFN (bool=5Fmatrix=5Fto=5Fuint8, bool=5Fmatrix, uint8) +DEFCONVFN (bool=5Fmatrix=5Fto=5Fuint16, bool=5Fmatrix, uint16) +DEFCONVFN (bool=5Fmatrix=5Fto=5Fuint32, bool=5Fmatrix, uint32) +DEFCONVFN (bool=5Fmatrix=5Fto=5Fuint64, bool=5Fmatrix, uint64) + DEFCONVFN (range=5Fto=5Fint8, range, int8) DEFCONVFN (range=5Fto=5Fint16, range, int16) DEFCONVFN (range=5Fto=5Fint32, range, int32) @@ -145,6 +167,8 @@ { INSTALL=5FCONVOPS (scalar) INSTALL=5FCONVOPS (matrix) + INSTALL=5FCONVOPS (bool) + INSTALL=5FCONVOPS (bool=5Fmatrix) INSTALL=5FCONVOPS (range) =20 INSTALL=5FINT=5FCONV=5FFUNCTIONS (int8) From maintainers-request@octave.org Wed Sep 15 20:14:49 2004 Resent-Date: Wed, 15 Sep 2004 20:14:48 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16712.59404.271411.595215@devzero.bogus.domain> Date: Wed, 15 Sep 2004 21:10:36 -0400 To: David Bateman Cc: maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" In-Reply-To: <20040915194349.GD12502@zfr01-2089.crm.mot.com> References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> <20040915194349.GD12502@zfr01-2089.crm.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 15-Sep-2004, David Bateman wrote: | Ok, then how about this patch to sort to that uses templates where | possible, sorts on cell arrays of strings, makes sorting of | complex values matlab compatiable, and adds a mode flag to define | the direction of the sort. | | Patch is against the CVS (or rather against an older CVS with my | previous sort patch applied), so it should apply cleanly. I applied this set of changes. Thanks, jwe From maintainers-request@octave.org Thu Sep 16 01:55:09 2004 Resent-Date: Thu, 16 Sep 2004 01:55:04 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <4149374D.3090701@tugraz.at> Date: Thu, 16 Sep 2004 08:48:45 +0200 From: Alois Schloegl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John W. Eaton" CC: David Bateman , Quentin Spencer , maintainers@octave.org, Keith Goodman Subject: Re: Cell arrays of strings in "sort" and "unique" References: <20040914210950.GD27214@zfr01-2089.crm.mot.com> <16711.25079.152574.465546@devzero.bogus.domain> <20040915160619.GA12502@zfr01-2089.crm.mot.com> <41486CA7.1060502@ieee.org> <20040915164712.GB12502@zfr01-2089.crm.mot.com> <4148796F.6010808@tugraz.at> <16712.32784.482797.451725@devzero.bogus.domain> In-Reply-To: <16712.32784.482797.451725@devzero.bogus.domain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org John W. Eaton wrote: >On 15-Sep-2004, Alois Schloegl wrote: > >| In this case, compatibility is not a "must". The result might differ >| already in the next version of matlab. > >That could be said for any Matlab feature. Why is this one different >from any of the others? > >jwe > Ok, the above answer can be made more impartial using the following critiria, (a) does the "purpose" of a function suggest a certain solution (b) which solution is more powerful, i.e. which solution can be used in a wider range of applications (c) efficiency of the implementation, which solution provides a higher performance ? (d) ... ? With respect to the question whether NaNs should be sorted to which end, criteria (a) and (b) do not suggest any preferred solution. Therefore, only criteria (c) should be applied. Alois From maintainers-request@octave.org Thu Sep 16 03:02:02 2004 Resent-Date: Thu, 16 Sep 2004 03:01:51 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <41494702.6000307@tugraz.at> Date: Thu, 16 Sep 2004 09:55:46 +0200 From: Alois Schloegl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Bateman CC: maintainers@octave.org Subject: Re: Cell arrays of strings in "sort" and "unique" References: <20040915194030.GC12502@zfr01-2089.crm.mot.com> In-Reply-To: <20040915194030.GC12502@zfr01-2089.crm.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: <0AUAMC.A.X3.uhUSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org David Bateman wrote: >>If the position of NaN is important, its recommended doing explicit >>checks for NaN's - and if only for the sake of readibility of the code. >> >> > >You've not read sort.cc lately :-) ... If floating format is IEEE754, >doubles are cast as "long long unsigned int" and with a bit of magic >the NaN's are sorted correctly, where the operator < alone won't do >it. This little trick gains a speed factor of 2.5 is sort, but readable >it is not. > >Cheers >David > > In the statement above, I was refering to readability in user space m-files, not to readability within sort.cc. I'm aware that the bit of "magic" works very well and provides an very efficient implementation of SORT. From the implementation point of view - using the bit of "magic" and considering IEEE754 - it is reasonable to put NaN's at the same end of the sequence than +INF. With the following example, I'll try to clarify the "user-point-of-view" (point of view in the m-domain). If somebody needs to sort a sequence x, like mode = 'ascend'; % or mode='descend'; [y,i]=sort(x,'mode') % x contains nan's and if the position of NaNs in y is important (if not, who cares), than the user should explicitly check for NaNs using isnan(y). For example y(isnan(y)) = [] or alternatively y = y(~isnan(y)), would remove all NaN's. The code in m-files becomes better readable, because one becomes aware that NaNs are important and have been considered. This means, from a users-point-of-view, SORT can put NaNs in the beginning or at the end - it does not really matter. If you provide just the most efficient implementation of SORT, that's fine :-) Alois From maintainers-request@octave.org Thu Sep 16 09:10:36 2004 Resent-Date: Thu, 16 Sep 2004 09:10:32 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.40605.22886.42054@devzero.bogus.domain> Date: Thu, 16 Sep 2004 10:09:33 -0400 To: Alois Schloegl Cc: David Bateman , maintainers@octave.org Subject: Re: Cell arrays of strings in "sort" and "unique" In-Reply-To: <41494702.6000307@tugraz.at> References: <20040915194030.GC12502@zfr01-2089.crm.mot.com> <41494702.6000307@tugraz.at> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, Alois Schloegl wrote: | This means, from a users-point-of-view, SORT can put NaNs in the | beginning or at the end - it does not really matter. If it does not really matter where they go, then they might as well be placed in a way that is compatible with the other leading brand. That way, people can expect consistent results when they move their code to Octave. jwe From maintainers-request@octave.org Thu Sep 16 09:28:38 2004 Resent-Date: Thu, 16 Sep 2004 09:28:38 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 17:21:03 +0300 From: Teemu Ikonen To: maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040916142103.GE46675@pcu.helsinki.fi> References: <20040915143237.GD46675@pcu.helsinki.fi> <16712.42623.235837.118702@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16712.42623.235837.118702@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 15/09/04 16:30, John W. Eaton wrote: > On 15-Sep-2004, Teemu Ikonen wrote: > | While trying to achieve lambda-like functionality with inline, I ran into > | this crasher: > Please try the following patch. Thanks for the quick reply. Now, an obligatory stupid question: Since Octave already seems to have functions as first-class objects, would it be hard to implement real closures? I'm not asking for someone to actually do this any time soon, I'd just like to know. Also, I'm wondering about the difference between inline functions and user defined functions defined on the command line with the function keyword. Inline functions are listed as variables in the who output and can be saved at least in the octave binary format. Are there any deeper differences? Is there any way of saving functions defined by the function keyword? Teemu From maintainers-request@octave.org Thu Sep 16 09:42:32 2004 Resent-Date: Thu, 16 Sep 2004 09:42:31 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 17:34:56 +0300 From: Teemu Ikonen To: maintainers@octave.org Subject: more on inline Message-ID: <20040916143456.GF46675@pcu.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <-7h19C.A.AMH.XZaSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Hi, I tried function valued parameters with Matlab R13, and found that Octave is not fully compatible, although it does the right thing: octave:16> ff = inline("f(x)", "f", "x") ff = f(f, x) = f(x) octave:17> ff(@sin, 1) ans = 0.84147 Matlab: >> ff = inline('f(x)', 'f', 'x') ff = Inline function: ff(f,x) = f(x) >> ff(@sin, 1) ans = @sin >> version ans = 6.5.0.180913a (R13) I'm not sure if this still the behaviour of R14, but this might be one case where bug for bug compatibility is not a good idea. Teemu From maintainers-request@octave.org Thu Sep 16 09:58:40 2004 Resent-Date: Thu, 16 Sep 2004 09:58:40 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 16:54:52 +0200 From: David Bateman To: Teemu Ikonen Cc: maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040916145451.GB20370@zfr01-2089.crm.mot.com> References: <20040915143237.GD46675@pcu.helsinki.fi> <16712.42623.235837.118702@devzero.bogus.domain> <20040916142103.GE46675@pcu.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916142103.GE46675@pcu.helsinki.fi> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org > Also, I'm wondering about the difference between inline functions and user > defined functions defined on the command line with the function keyword. An inline function deosn't appear in the fbi_sym_tab. Apart from that not much different. A function handle however has a subtle difference, for example octave:1> fcn = @not octave:2> function y = not (x), y = x; endfunction octave:3> fcn(1), not(1) ans = 0 ans = 1 This happens due to the fact that the function handle saves the octave_function in the original symbol table before it was replaced.. However, this is not true for inline functions, for example octave:1> fcn = inline('not(x)') fcn = f(x) = not(x) octave:2> not = inline('x') not = f(x) = x octave:3> fcn(1), not(1) ans = 0 ans = 0 Err, in fact this seems to be a compatiability problem with matlab, as it seems matlab save a copy of the current symbol table for inline functions, since in matlab the above example gives >> fcn = inline('not(x)') fcn = Inline function: fcn(x) = not(x) >> not = inline('x') not = Inline function: not(x) = x >> fcn(1), not(1) ans = 0 ans = 1 This probably also points to a deeper compatiability issue with function handles as functions called by the original function might also change in the current symbol table... > Inline functions are listed as variables in the who output and can be saved > at least in the octave binary format. Are there any deeper differences? Is > there any way of saving functions defined by the function keyword? You are upto date, that was only in the CVS a couple of days ago... Function handles and inline functions can be saved in hdf5, octave binary and ascii formats. I don't think it makes sense to save user functions, since when saving all variables you'd effective resave all of your script files. Perhaps functions that were entered interactively should be flagged and saved in this case. Regards D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Thu Sep 16 10:02:09 2004 Resent-Date: Thu, 16 Sep 2004 10:02:09 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.43707.829932.898717@devzero.bogus.domain> Date: Thu, 16 Sep 2004 11:01:15 -0400 To: Teemu Ikonen Cc: maintainers@octave.org Subject: Re: Crash with inline In-Reply-To: <20040916142103.GE46675@pcu.helsinki.fi> References: <20040915143237.GD46675@pcu.helsinki.fi> <16712.42623.235837.118702@devzero.bogus.domain> <20040916142103.GE46675@pcu.helsinki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <6uZhy.A.acH.wraSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, Teemu Ikonen wrote: | Now, an obligatory stupid question: Since Octave already seems to have | functions as first-class objects, They are not really first-class objects, are they? If you write function f ... end g = f; then g is not a function, but the result of calling the function. Similarly, if you write f you don't see the definition of the function (or some other message saying, "f is a function") but instead, the function is called. So you can't directly pass functions around like any other data object. Rather than fix this by saying "if you want to call a function, you have to use "f (...)"; otherwise, you are referring to the function object itself", the developers of the other leading brand decided to invent "function handles". | would it be hard to implement real closures? I'm not sure. How would this work within the current language? | Also, I'm wondering about the difference between inline functions and user | defined functions defined on the command line with the function keyword. | Inline functions are listed as variables in the who output and can be saved | at least in the octave binary format. Are there any deeper differences? Is | there any way of saving functions defined by the function keyword? We also have anonymous function handles. Given those, it seems like inline functions are not really necessary. In Octave, inline functions are a special kind of function handle. If you want to save a function that you've defined at the command line, you can do this: function foo ... end f = fopen ("foo.m", "w"); fprintf (f, "%s", type ("foo")); fclose (f); If you've saved it somewhere in Octave's LOADPATH, then you can just call it to reload it. Or, you can do source ("foo.m") or you can write f = fopen ("foo.m", "r"); t = setstr (fread (f)'); fclose (f); eval (t); jwe From maintainers-request@octave.org Thu Sep 16 10:16:28 2004 Resent-Date: Thu, 16 Sep 2004 10:16:28 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.44565.80665.588721@devzero.bogus.domain> Date: Thu, 16 Sep 2004 11:15:33 -0400 To: Teemu Ikonen Cc: maintainers@octave.org Subject: more on inline In-Reply-To: <20040916143456.GF46675@pcu.helsinki.fi> References: <20040916143456.GF46675@pcu.helsinki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, Teemu Ikonen wrote: | Matlab: | >> ff = inline('f(x)', 'f', 'x') | ff = | Inline function: | ff(f,x) = f(x) | >> ff(@sin, 1) | ans = | @sin | >> version | ans = | 6.5.0.180913a (R13) I think this has changed. In R13, function handles were an array type, so indexing them picked an element from the array. In R14, they made them a scalar type only, so indexing them performs a function call. So in the above, you are selecting the first element of the function handle array stored in f. Try ff (@sin, 2) and see if you don't get a different result (range error on the index). With the new behavior, I would expect Matlab to be compatible with the current Octave behavior and call the sin function through the function handle with the argument 1. jwe From maintainers-request@octave.org Thu Sep 16 10:33:39 2004 Resent-Date: Thu, 16 Sep 2004 10:33:39 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 18:26:05 +0300 From: Teemu Ikonen To: maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040916152605.GH46675@pcu.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16/09/04 11:01, John W. Eaton wrote: > | functions as first-class objects, > They are not really first-class objects, are they? If you write Oops, indeed I mistook the function handles returned by inline as functions. > | would it be hard to implement real closures? > I'm not sure. How would this work within the current language? Well, functions defined in the command line either by inline or function keyword would find undefined variables from the top-level environment (if they exist) and store their value. Something like: > a = 1; > f = inline("x + a", "x"); > f(1) ans = 2 > a = pi; > f(1) ans = 2 Looks straightforward, but there might be all kinds of subtleties I'm not aware of... Teemu From maintainers-request@octave.org Thu Sep 16 11:37:49 2004 Resent-Date: Thu, 16 Sep 2004 11:37:44 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 18:33:50 +0200 From: David Bateman To: Teemu Ikonen Cc: maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040916163350.GB1811@zfr01-2089.crm.mot.com> References: <20040916152605.GH46675@pcu.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916152605.GH46675@pcu.helsinki.fi> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org According to Teemu Ikonen (on 09/16/04): > On 16/09/04 11:01, John W. Eaton wrote: > > | functions as first-class objects, > > They are not really first-class objects, are they? If you write > > Oops, indeed I mistook the function handles returned by inline as functions. > > > | would it be hard to implement real closures? > > I'm not sure. How would this work within the current language? > > Well, functions defined in the command line either by inline or function > keyword would find undefined variables from the top-level environment (if > they exist) and store their value. Something like: > > > a = 1; > > f = inline("x + a", "x"); > > f(1) > ans = 2 > > a = pi; > > f(1) > ans = 2 > > Looks straightforward, but there might be all kinds of subtleties I'm not > aware of... Basically to do this we'd need a copy constructor for symbol_table and make a copy of curr_sym_tab when creating the function handle. As inline functions are just specialized function handles and inherit the methods of function handles no special treatment would be needed. The problem then arises in a case where for example you have a function on the loadpath, create a function handle that depends on this function, and then change directories. If the function hasn't already been parsed when the copy of curr_sym_tab is made, and a different version of this function exists in the need directory, then which version is called. So you also need to save the loadpath. Ok, lets get even more paranoid. With the same case as above without changing directories. However, the function that the function handle depends on is edited... Should the function handle still use the old definition or the new one. So the question is exactly how much of the context is saved when creating a function handle.. If it is everything, creating a function handle might be a very very expensive operation... I haven't checked how matlab does this, but I'd thing a reasonable solution would be to save curr_sym_tab, fbi_sym_tab and the loadpath. However, it would be good to hear if others have other ideas.. D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Thu Sep 16 11:48:46 2004 Resent-Date: Thu, 16 Sep 2004 11:48:45 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 18:44:56 +0200 From: David Bateman To: David Bateman Cc: Teemu Ikonen , maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040916164456.GC20370@zfr01-2089.crm.mot.com> References: <20040916152605.GH46675@pcu.helsinki.fi> <20040916163350.GB1811@zfr01-2089.crm.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916163350.GB1811@zfr01-2089.crm.mot.com> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org This made me check how matlab/octave handle different versions of the function when changing directory. Consider the matlab example >> test(1); >> which test /home/dbateman/tmp/test.m >> cd .. >> which test /home/dbateman/test.m Doing the same in octave gives octaveL1> test(1); octave:2> which test test is the user-defined function from the file /home/dbateman/tmp/test.m octave:3> cd .. octave:4> which test test is the user-defined function from the file /home/dbateman/tmp/test.m So it seems that octave keeps the compiled version from its symbol table even after the directory change, while matlab picks up the fact that there is a new version in the loadpath. What I suspect that matlab does is that when doing a cd it invalidates all of the functions in its symbol table that are located elsewhere it its loadpath after the directory change... Should octave do the same thing? Regards David -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Thu Sep 16 12:00:36 2004 Resent-Date: Thu, 16 Sep 2004 12:00:35 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.50814.288893.320143@devzero.bogus.domain> Date: Thu, 16 Sep 2004 12:59:42 -0400 To: Teemu Ikonen Cc: maintainers@octave.org Subject: Re: Crash with inline In-Reply-To: <20040916152605.GH46675@pcu.helsinki.fi> References: <20040916152605.GH46675@pcu.helsinki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, Teemu Ikonen wrote: | Well, functions defined in the command line either by inline or function | keyword would find undefined variables from the top-level environment (if | they exist) and store their value. Something like: | | > a = 1; | > f = inline("x + a", "x"); | > f(1) | ans = 2 | > a = pi; | > f(1) | ans = 2 | | Looks straightforward, but there might be all kinds of subtleties I'm not | aware of... I'm not sure it is a good idea to modify the scoping rules this way. Why should inline functions or functions defined at the command line behave differently from functions defined in a file? Seems messy to me. jwe From maintainers-request@octave.org Thu Sep 16 12:01:26 2004 Resent-Date: Thu, 16 Sep 2004 12:01:26 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.50660.105595.808544@devzero.bogus.domain> Date: Thu, 16 Sep 2004 12:57:08 -0400 To: David Bateman Cc: Teemu Ikonen , maintainers@octave.org Subject: Re: Crash with inline In-Reply-To: <20040916164456.GC20370@zfr01-2089.crm.mot.com> References: <20040916152605.GH46675@pcu.helsinki.fi> <20040916163350.GB1811@zfr01-2089.crm.mot.com> <20040916164456.GC20370@zfr01-2089.crm.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <3epJc.A.AKC.mbcSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, David Bateman wrote: | So it seems that octave keeps the compiled version from its symbol | table even after the directory change, while matlab picks up the | fact that there is a new version in the loadpath. What I suspect | that matlab does is that when doing a cd it invalidates all of the | functions in its symbol table that are located elsewhere it its | loadpath after the directory change... I'd guess that CD is not doing anything special. Instead, WHICH is probably looking up what symbol should be found, and instead of assuming that a symbol in memory must be the correct one, is looking at the load path. If we decide to fix this in Octave, then I think we need to change the way symbol_out_of_data works. Instead of just checking symbol timestamps, we need to see if the function found in the path is different from the one found in the current symbol table. Then the which command may also need to be changed to check for out of date symbols (probably instead of duplicating any code or logic, it needs to use the same method of looking up a symbol that the interpreter uses when attempting to evaluate a symbol). Now, what to do about functions with the same name defined on the command line? Should those always be favored over what is found in the load path? jwe From maintainers-request@octave.org Thu Sep 16 12:29:16 2004 Resent-Date: Thu, 16 Sep 2004 12:29:11 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Subject: Re: double(true) not implemented From: Josep =?ISO-8859-1?Q?Mon=E9s?= i Teixidor To: octave maintainers mailing list In-Reply-To: <16712.59380.550293.893905@devzero.bogus.domain> References: <1095284779.21696.85.camel@ottoana.fakedomain> <16712.59380.550293.893905@devzero.bogus.domain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fg/ocLPyH4RIxt7t1BsW" Message-Id: <1095355666.1945.5.camel@ottoana.fakedomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 19:27:47 +0200 Sender: =?iso-8859-1?Q?Josep_Mon=E9s_i_Teixidor?= X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at aprop.net X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org --=-fg/ocLPyH4RIxt7t1BsW Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On dj, 2004-09-16 at 03:10, John W. Eaton wrote: >=20 > Please try the following patch. >=20 That was fast! It works perfectly. Thanks. > This will also make things like >=20 > int32 (true) It works too. >=20 > work. >=20 > Thanks, >=20 > jwe >=20 Thanks --=20 Josep Mon=E9s i Teixidor Clau GnuPG: gpg --recv-keys 80E85CC4 --=-fg/ocLPyH4RIxt7t1BsW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBSc0SMVjIwYDoXMQRAlk2AJ4wPN9tgab6KYV3W4ILvxeTFcl/+QCfV4Yf xaicaeXUgIlX2XrARS3Zlec= =BqdW -----END PGP SIGNATURE----- --=-fg/ocLPyH4RIxt7t1BsW-- From maintainers-request@octave.org Thu Sep 16 12:38:13 2004 Resent-Date: Thu, 16 Sep 2004 12:38:12 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16713.53070.987198.386782@devzero.bogus.domain> Date: Thu, 16 Sep 2004 13:37:18 -0400 To: Josep =?ISO-8859-1?Q?Mon=E9s?= i Teixidor Cc: octave maintainers mailing list Subject: Re: double(true) not implemented In-Reply-To: <1095355666.1945.5.camel@ottoana.fakedomain> References: <1095284779.21696.85.camel@ottoana.fakedomain> <16712.59380.550293.893905@devzero.bogus.domain> <1095355666.1945.5.camel@ottoana.fakedomain> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, Josep Mon=E9s i Teixidor wrote: | On dj, 2004-09-16 at 03:10, John W. Eaton wrote: |=20 | > Please try the following patch. |=20 | That was fast! It works perfectly. Thanks. |=20 | > This will also make things like | >=20 | > int32 (true) |=20 | It works too. |=20 | Thanks If you find Octave useful and appreciate the level of support you receive, please consider contributing to the project, either by helping with its development directly or by providing funding. http://www.octave.org/help-wanted.html http://www.octave.org/funding.html Thanks, jwe From maintainers-request@octave.org Thu Sep 16 13:54:30 2004 Resent-Date: Thu, 16 Sep 2004 13:54:29 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.57641.949428.539099@devzero.bogus.domain> Date: Thu, 16 Sep 2004 14:53:29 -0400 To: David Bateman Cc: Teemu Ikonen , maintainers@octave.org Subject: Re: Crash with inline In-Reply-To: <16713.50660.105595.808544@devzero.bogus.domain> References: <20040916152605.GH46675@pcu.helsinki.fi> <20040916163350.GB1811@zfr01-2089.crm.mot.com> <20040916164456.GC20370@zfr01-2089.crm.mot.com> <16713.50660.105595.808544@devzero.bogus.domain> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <46WoZC.A.e6D.lFeSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, I wrote: | I'd guess that CD is not doing anything special. Instead, WHICH | is probably looking up what symbol should be found, and instead of | assuming that a symbol in memory must be the correct one, is looking | at the load path. If we decide to fix this in Octave, then I think we | need to change the way symbol_out_of_data works. Instead of just | checking symbol timestamps, we need to see if the function found in | the path is different from the one found in the current symbol table. I think the following patch will make Octave work in a compatible way. | Then the which command may also need to be changed to check for out of | date symbols (probably instead of duplicating any code or logic, it | needs to use the same method of looking up a symbol that the | interpreter uses when attempting to evaluate a symbol). This part was already done. | Now, what to do about functions with the same name defined on the | command line? Should those always be favored over what is found in | the load path? Currently we will always favor the function defined on the command line. Doing something like octave:1> function foo () ... end and then which foo or cd some-directory-with-a-foo.m-file which foo will tell you that foo is a user defined function. BTW, it would be nice if in this case WHICH would till us that it has no corresponding file. Likewise, for built-in functions, it would be nice to have it say in what file it was originally defined. jwe 2004-09-16 John W. Eaton * variables.cc (symbol_out_of_date): Always look in LOADPATH. Index: src/variables.cc =================================================================== RCS file: /usr/local/cvsroot/octave/src/variables.cc,v retrieving revision 1.260 diff -u -r1.260 variables.cc --- a/src/variables.cc 11 Sep 2004 13:05:39 -0000 1.260 +++ b/src/variables.cc 16 Sep 2004 18:41:17 -0000 @@ -772,19 +772,28 @@ { time_t tp = tmp->time_parsed (); - std::string fname; + std::string nm = tmp->name (); - if (tmp->is_dld_function ()) - fname = ff; - else - fname = fcn_file_in_path (ff); + string_vector names (2); - tmp->mark_fcn_file_up_to_date (octave_time ()); + names[0] = nm + ".oct"; + names[1] = nm + ".m"; - file_stat fs (fname); + std::string file = octave_env::make_absolute + (Vload_path_dir_path.find_first_of (names), + octave_env::getcwd ()); - if (fs && fs.is_newer (tp)) + if (file != ff) retval = true; + else + { + tmp->mark_fcn_file_up_to_date (octave_time ()); + + file_stat fs (ff); + + if (fs && fs.is_newer (tp)) + retval = true; + } } } } From maintainers-request@octave.org Thu Sep 16 15:15:57 2004 Resent-Date: Thu, 16 Sep 2004 15:15:57 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 22:12:08 +0200 From: David Bateman To: "John W. Eaton" Cc: Teemu Ikonen , maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040916201208.GD20370@zfr01-2089.crm.mot.com> References: <20040916152605.GH46675@pcu.helsinki.fi> <20040916163350.GB1811@zfr01-2089.crm.mot.com> <20040916164456.GC20370@zfr01-2089.crm.mot.com> <16713.50660.105595.808544@devzero.bogus.domain> <16713.57641.949428.539099@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16713.57641.949428.539099@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <_FePN.A.daG.8RfSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Ok this patch made the function that was picked up change after a CD, but WHICH still identifies the incorrect function, even after it is reparsed (ie. used). On another point what about the issue raised in http://www.octave.org/mailing-lists/octave-maintainers/2004/701 for inline functions. Should octave be saving the curr_sym_tab, fbi_sym_tab, loadpath as context for the function handles? Can I implement copy functions for symbol_table, which would be needed for this? Or is there a reason why such a copy function should be avoided? Regards David According to John W. Eaton (on 09/16/04): > On 16-Sep-2004, I wrote: > > | I'd guess that CD is not doing anything special. Instead, WHICH > | is probably looking up what symbol should be found, and instead of > | assuming that a symbol in memory must be the correct one, is looking > | at the load path. If we decide to fix this in Octave, then I think we > | need to change the way symbol_out_of_data works. Instead of just > | checking symbol timestamps, we need to see if the function found in > | the path is different from the one found in the current symbol table. > > I think the following patch will make Octave work in a compatible way. > > | Then the which command may also need to be changed to check for out of > | date symbols (probably instead of duplicating any code or logic, it > | needs to use the same method of looking up a symbol that the > | interpreter uses when attempting to evaluate a symbol). > > This part was already done. > > | Now, what to do about functions with the same name defined on the > | command line? Should those always be favored over what is found in > | the load path? > > Currently we will always favor the function defined on the command > line. Doing something like > > octave:1> function foo () ... end > > and then > > which foo > > or > > cd some-directory-with-a-foo.m-file > which foo > > will tell you that foo is a user defined function. > > BTW, it would be nice if in this case WHICH would till us that it has > no corresponding file. Likewise, for built-in functions, it would be > nice to have it say in what file it was originally defined. > > jwe > > > 2004-09-16 John W. Eaton > > * variables.cc (symbol_out_of_date): Always look in LOADPATH. > > > Index: src/variables.cc > =================================================================== > RCS file: /usr/local/cvsroot/octave/src/variables.cc,v > retrieving revision 1.260 > diff -u -r1.260 variables.cc > --- a/src/variables.cc 11 Sep 2004 13:05:39 -0000 1.260 > +++ b/src/variables.cc 16 Sep 2004 18:41:17 -0000 > @@ -772,19 +772,28 @@ > { > time_t tp = tmp->time_parsed (); > > - std::string fname; > + std::string nm = tmp->name (); > > - if (tmp->is_dld_function ()) > - fname = ff; > - else > - fname = fcn_file_in_path (ff); > + string_vector names (2); > > - tmp->mark_fcn_file_up_to_date (octave_time ()); > + names[0] = nm + ".oct"; > + names[1] = nm + ".m"; > > - file_stat fs (fname); > + std::string file = octave_env::make_absolute > + (Vload_path_dir_path.find_first_of (names), > + octave_env::getcwd ()); > > - if (fs && fs.is_newer (tp)) > + if (file != ff) > retval = true; > + else > + { > + tmp->mark_fcn_file_up_to_date (octave_time ()); > + > + file_stat fs (ff); > + > + if (fs && fs.is_newer (tp)) > + retval = true; > + } > } > } > } -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Thu Sep 16 15:24:07 2004 Resent-Date: Thu, 16 Sep 2004 15:24:07 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.63012.175692.956782@devzero.bogus.domain> Date: Thu, 16 Sep 2004 16:23:00 -0400 To: David Bateman Cc: Teemu Ikonen , maintainers@octave.org Subject: Re: Crash with inline In-Reply-To: <20040916201208.GD20370@zfr01-2089.crm.mot.com> References: <20040916152605.GH46675@pcu.helsinki.fi> <20040916163350.GB1811@zfr01-2089.crm.mot.com> <20040916164456.GC20370@zfr01-2089.crm.mot.com> <16713.50660.105595.808544@devzero.bogus.domain> <16713.57641.949428.539099@devzero.bogus.domain> <20040916201208.GD20370@zfr01-2089.crm.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, David Bateman wrote: | Ok this patch made the function that was picked up change after a CD, | but WHICH still identifies the incorrect function, even after it is | reparsed (ie. used). Can you show precisely what the problem is? Here is what I see: octave:1> foo ans = 1 octave:2> which foo foo is the user-defined function from the file /scratch/jwe/build/octave/foo.m octave:3> cd .. octave:4> which foo foo is the user-defined function from the file /scratch/jwe/build/foo.m octave:5> foo ans = 2 octave:6> cd octave octave:7> which foo foo is the user-defined function from the file /scratch/jwe/build/octave/foo.m octave:8> foo ans = 1 In this example, there are two functions. One in /scratch/jwe/build/octave/foo.m that returns 1, and another in /scratch/jwe/build/foo.m that returns 2. I'm starting out in /scratch/jwe/build/octave. It seems that WHICH finds the correct one in each case, as does the function lookup code. The following also appears to me to be working correctly: octave:1> foo ans = 1 octave:2> cd .. octave:3> foo ans = 2 octave:4> which foo foo is the user-defined function from the file /scratch/jwe/build/foo.m octave:5> cd octave octave:6> foo ans = 1 octave:7> which foo foo is the user-defined function from the file /scratch/jwe/build/octave/foo.m (evaluating before calling WHICH). At least I think this is the right behavior. If not, please explain what is going wrong here, as I don't see it. | On another point what about the issue raised in | | http://www.octave.org/mailing-lists/octave-maintainers/2004/701 | | for inline functions. Should octave be saving the curr_sym_tab, fbi_sym_tab, | loadpath as context for the function handles? Can I implement copy functions | for symbol_table, which would be needed for this? Or is there a reason why | such a copy function should be avoided? I suspect that copying the symbol tables is not actually necessary, but I haven't had time to look at the problem in detail yet. jwe From maintainers-request@octave.org Thu Sep 16 16:01:24 2004 Resent-Date: Thu, 16 Sep 2004 16:01:23 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 16 Sep 2004 23:00:38 +0200 From: David Bateman To: maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040916210038.GE20370@zfr01-2089.crm.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org > Can you show precisely what the problem is? Here is what I see: Err my fault... My second test function was an empty file... You're right it works with which as well.... Which means that a script file (not a function) in the current scope also takes precedence. That is, if one of your foo.m contains function y = foo () y = 1; endfunction and the other contains 1; disp("foo"); then you get octave:1> foo ans = 1 octave:2> cd .. octave:3> foo foo octave:4> which foo foo is the user-defined function from the file /home/dbateman/tmp/foo.m octave:5> cd tmp octave:6> which foo foo is the user-defined function from the file /home/dbateman/tmp/foo.m I'd expect the first which to say which: `foo' is the script file /home/dbateman/foo.m D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Thu Sep 16 22:01:34 2004 Resent-Date: Thu, 16 Sep 2004 22:01:33 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16714.21334.808697.745066@devzero.bogus.domain> Date: Thu, 16 Sep 2004 23:00:38 -0400 To: David Bateman Cc: Teemu Ikonen , maintainers@octave.org Subject: Re: Crash with inline In-Reply-To: <20040916145451.GB20370@zfr01-2089.crm.mot.com> References: <20040915143237.GD46675@pcu.helsinki.fi> <16712.42623.235837.118702@devzero.bogus.domain> <20040916142103.GE46675@pcu.helsinki.fi> <20040916145451.GB20370@zfr01-2089.crm.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 16-Sep-2004, David Bateman wrote: | > Also, I'm wondering about the difference between inline functions and user | > defined functions defined on the command line with the function keyword. | | An inline function deosn't appear in the fbi_sym_tab. Apart from that | not much different. A function handle however has a subtle difference, | for example | | octave:1> fcn = @not | octave:2> function y = not (x), y = x; endfunction | octave:3> fcn(1), not(1) | ans = 0 | ans = 1 | | This happens due to the fact that the function handle saves the | octave_function in the original symbol table before it was replaced.. | However, this is not true for inline functions, for example | | octave:1> fcn = inline('not(x)') | fcn = | | f(x) = not(x) | | octave:2> not = inline('x') | not = | | f(x) = x | | octave:3> fcn(1), not(1) | ans = 0 | ans = 0 | | Err, in fact this seems to be a compatiability problem with matlab, | as it seems matlab save a copy of the current symbol table for inline | functions, since in matlab the above example gives | | >> fcn = inline('not(x)') | | fcn = | | Inline function: | fcn(x) = not(x) | | >> not = inline('x') | | not = | | Inline function: | not(x) = x | | >> fcn(1), not(1) | | ans = | | 0 | | | ans = | | 1 Please try the following patch. I've checked this in, but unfortunately, the anonymous CVS archive is down at the moment and probably won't be back until sometime tomorrow (after around 9AM USA central time). jwe src/ChangeLog: 2004-09-16 John W. Eaton * parse.y (frob_function): Clear id_name from curr_sym_tab, not top_level_sym_tab. Index: src/parse.y =================================================================== RCS file: /usr/local/cvsroot/octave/src/parse.y,v retrieving revision 1.222 diff -u -r1.222 parse.y --- a/src/parse.y 6 Sep 2004 20:19:57 -0000 1.222 +++ b/src/parse.y 17 Sep 2004 02:51:23 -0000 @@ -2715,7 +2715,21 @@ fcn->stash_function_name (id_name); - top_level_sym_tab->clear (id_name); + // Enter the new function in fbi_sym_tab. If there is already a + // variable of the same name in the current symbol table, we won't + // find the new function when we try to call it, so we need to clear + // the old symbol from the current symbol table. Note that this + // means that for things like + // + // function f () eval ("function g () 1, end"); end + // g = 13; + // f (); + // g + // + // G will still refer to the variable G (with value 13) rather + // than the function G, until the variable G is cleared. + + curr_sym_tab->clear (id_name); symbol_record *sr = fbi_sym_tab->lookup (id_name, true); From maintainers-request@octave.org Fri Sep 17 03:09:43 2004 Resent-Date: Fri, 17 Sep 2004 03:09:42 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 17 Sep 2004 10:05:44 +0200 From: David Bateman To: "John W. Eaton" Cc: David Bateman , Teemu Ikonen , maintainers@octave.org Subject: Re: Crash with inline Message-ID: <20040917080544.GG20370@zfr01-2089.crm.mot.com> References: <20040915143237.GD46675@pcu.helsinki.fi> <16712.42623.235837.118702@devzero.bogus.domain> <20040916142103.GE46675@pcu.helsinki.fi> <20040916145451.GB20370@zfr01-2089.crm.mot.com> <16714.21334.808697.745066@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16714.21334.808697.745066@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org According to John W. Eaton (on 09/17/04): > Please try the following patch. > > I've checked this in, but unfortunately, the anonymous CVS archive is > down at the moment and probably won't be back until sometime tomorrow > (after around 9AM USA central time). > Ok, this seems to work.. D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Fri Sep 17 03:30:49 2004 Resent-Date: Fri, 17 Sep 2004 03:30:49 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 17 Sep 2004 10:27:46 +0200 From: Bart Vandewoestyne To: maintainers@octave.org Subject: Matlab's rand function Message-ID: <20040917082745.GA7824@forsythe> Mail-Followup-To: maintainers@octave.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: Bart Vandewoestyne X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: <0zLfDB.A.zfC.5CqSBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org I think we can be pretty sure that the m-file implementation at http://www.mathworks.com/moler/ncm/randtx.m really describes the built in rand function of Matlab R13 (I can only test up until that release here at work): >> version ans = 6.5.0.180913a (R13) >> any(any(rand(100)-randtx(100))) ans = 0 Now the only thing I would like to know for sure is on what paper this implementation is based. The only information I have up until now is the 'Random Thoughts' paper from Cleve Moler... Concerning the license issues: if we have enough theoretical information on the generator used in Matlab, maybe we don't really need to look at randtx.m and can try to implement it ourselves, based on the papers describing the algorithm? Regards, Bart -- !!!!!!!!!!!!!!!!!!! email change !!!!!!!!!!!!!!!!!!!!!!! My email address is now Bart.Vandewoestyne AT telenet.be Please update your addressbook! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From maintainers-request@octave.org Fri Sep 17 08:27:44 2004 Resent-Date: Fri, 17 Sep 2004 08:27:42 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16714.58901.408120.958150@devzero.bogus.domain> Date: Fri, 17 Sep 2004 09:26:45 -0400 To: octave maintainers mailing list Subject: [cell_array{:}] = foo () syntax and semantics X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Octave currently does not handle things like [cell_array{:}] = foo () I've given this some thought in the past, and even started working on it once, but had to give up when it became fairly complicated and I ran out of time. I plan to work on this again soon, but before I start, I'd like to get some feedback. For functions that are wrappers around others (like inline or anonymous function handles) it would be swell if we could write something as simple as (for example) function varargout = foo (varargin) [varargout{:}] = svd (varargin{:}); endfunction and have it work in all cases: foo ([1,2;3,4]); sigma = foo ([1,2;3,4]); [u, s, v] = foo ([1,2;3,4]); Can someone tell me whether this will work in Matlab R14? In R13 it fails for the nargout == 0 case with an error about the subscript count of the cell array being zero, and also for the nargout > 0 cases because varargout is not preallocated automatically based on the value of nargout, so you have to write the wrapper as function varargout = foo (varargin) if (nargout == 0) svd (varargin{:}); else varargout = cell (nargout, 1); [varargout{:}] = svd (varargin{:}); end But even this is not quite right as ans (in the nargout == 0 case) is not propagated to varargout. So really, you have to write function varargout = foo (varargin) if (nargout == 0) svd (varargin{:}); varagout = ans; else varargout = cell (nargout, 1); [varargout{:}] = svd (varargin{:}); end Hmm. Although in the svd case, the behavior is identical for the nargout == 0 and nargout == 1 cases, that may not always be the case. So we can't write function varargout = foo (varargin) n = nargout; if (nargout == 0) n = 1; end varargout = cell (n, 1); [varargout{:}] = svd (varargin{:}); But, *could* we make function varargout = foo (varargin) [varargout{:}] = svd (varargin{:}); endfunction do this automatically? I think we would only have to do the following (in addition to making the [x{:}] = foo (...) syntax work to begin with): * Preallocate varargout based on the value of nargout. * Allow retval = {}; [retval{:}] = fcn (...); to work such that nargout is set to 0 for fcn, but if fcn returns any values, retval is reallocated to a one-element cell array to hold toe first returned value. Would these special cases cause trouble anywhere else (i.e., change the behavior of currently valid code)? jwe From maintainers-request@octave.org Fri Sep 17 10:59:54 2004 Resent-Date: Fri, 17 Sep 2004 10:59:53 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: Date: Fri, 17 Sep 2004 08:58:17 -0700 From: Keith Goodman Reply-To: Keith Goodman To: "John W. Eaton" Subject: Re: [cell_array{:}] = foo () syntax and semantics Cc: octave maintainers mailing list In-Reply-To: <16714.58901.408120.958150@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16714.58901.408120.958150@devzero.bogus.domain> X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org None of the cases work in R14. It chokes on the square brackets and spits out: ??? The left hand side has varargout{:} inside brackets, which requires that varargout be defined, so that the number of expected results can be computed. Changing the function to function varargout = foo (varargin) varargout{:} = svd (varargin{:}); gives >> foo([1,2;3,4]) ans = 5.4650 0.3660 >> sigma = foo ([1,2;3,4]) sigma = 5.4650 0.3660 >> [u, s, v] = foo ([1,2;3,4]) ??? Error using ==> foo Too many output arguments. Error in ==> foo at 2 [varargout{:}] = svd (varargin{:}); I'm using ------------------------------------------------------------------------------------- MATLAB Version 7.0.0.19901 (R14) MATLAB License Number: XXXXXX Operating System: Darwin 7.5.0 Darwin Kernel Version 7.5.0: Thu Aug 5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC Power Macintosh Java VM Version: Java 1.4.2_05 with "Apple Computer ------------------------------------------------------------------------------------- On Fri, 17 Sep 2004 09:26:45 -0400, John W. Eaton wrote: > Octave currently does not handle things like > > [cell_array{:}] = foo () > > I've given this some thought in the past, and even started working on > it once, but had to give up when it became fairly complicated and I > ran out of time. I plan to work on this again soon, but before I > start, I'd like to get some feedback. > > For functions that are wrappers around others (like inline or > anonymous function handles) it would be swell if we could write > something as simple as (for example) > > function varargout = foo (varargin) > [varargout{:}] = svd (varargin{:}); > endfunction > > and have it work in all cases: > > foo ([1,2;3,4]); > sigma = foo ([1,2;3,4]); > [u, s, v] = foo ([1,2;3,4]); > > Can someone tell me whether this will work in Matlab R14? In R13 it > fails for the nargout == 0 case with an error about the subscript > count of the cell array being zero, and also for the nargout > 0 cases > because varargout is not preallocated automatically based on the value > of nargout, so you have to write the wrapper as > > function varargout = foo (varargin) > if (nargout == 0) > svd (varargin{:}); > else > varargout = cell (nargout, 1); > [varargout{:}] = svd (varargin{:}); > end > > But even this is not quite right as ans (in the nargout == 0 case) is > not propagated to varargout. So really, you have to write > > function varargout = foo (varargin) > if (nargout == 0) > svd (varargin{:}); > varagout = ans; > else > varargout = cell (nargout, 1); > [varargout{:}] = svd (varargin{:}); > end > > Hmm. Although in the svd case, the behavior is identical for the > nargout == 0 and nargout == 1 cases, that may not always be the case. > So we can't write > > function varargout = foo (varargin) > n = nargout; > if (nargout == 0) > n = 1; > end > varargout = cell (n, 1); > [varargout{:}] = svd (varargin{:}); > > But, *could* we make > > function varargout = foo (varargin) > [varargout{:}] = svd (varargin{:}); > endfunction > > do this automatically? I think we would only have to do the > following (in addition to making the [x{:}] = foo (...) syntax work to > begin with): > > * Preallocate varargout based on the value of nargout. > > * Allow > > retval = {}; > [retval{:}] = fcn (...); > > to work such that nargout is set to 0 for fcn, but if fcn returns > any values, retval is reallocated to a one-element cell array to > hold toe first returned value. > > Would these special cases cause trouble anywhere else (i.e., change > the behavior of currently valid code)? > > jwe > > From maintainers-request@octave.org Fri Sep 17 11:04:27 2004 Resent-Date: Fri, 17 Sep 2004 11:04:26 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: Date: Fri, 17 Sep 2004 09:03:19 -0700 From: Keith Goodman Reply-To: Keith Goodman To: "John W. Eaton" Subject: Re: [cell_array{:}] = foo () syntax and semantics Cc: octave maintainers mailing list In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16714.58901.408120.958150@devzero.bogus.domain> X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Sorry. The last error message in the previous post goes wth the first one: ??? The left hand side has varargout{:} inside brackets, which requires that varargout be defined, so that the number of expected results can be computed. Error in ==> foo at 2 [varargout{:}] = svd (varargin{:}); On Fri, 17 Sep 2004 08:58:17 -0700, Keith Goodman wrote: > None of the cases work in R14. It chokes on the square brackets and spits out: > > ??? The left hand side has varargout{:} inside brackets, which > requires that varargout be defined, > so that the number of expected results can be computed. > > Changing the function to > > function varargout = foo (varargin) > varargout{:} = svd (varargin{:}); > > gives > > >> foo([1,2;3,4]) > ans = > 5.4650 > 0.3660 > >> sigma = foo ([1,2;3,4]) > sigma = > 5.4650 > 0.3660 > >> [u, s, v] = foo ([1,2;3,4]) > ??? Error using ==> foo > Too many output arguments. > > Error in ==> foo at 2 > [varargout{:}] = svd (varargin{:}); > > I'm using > > ------------------------------------------------------------------------------------- > MATLAB Version 7.0.0.19901 (R14) > MATLAB License Number: XXXXXX > Operating System: Darwin 7.5.0 Darwin Kernel Version 7.5.0: Thu Aug 5 > 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC Power > Macintosh > Java VM Version: Java 1.4.2_05 with "Apple Computer > ------------------------------------------------------------------------------------- > > > > > On Fri, 17 Sep 2004 09:26:45 -0400, John W. Eaton wrote: > > Octave currently does not handle things like > > > > [cell_array{:}] = foo () > > > > I've given this some thought in the past, and even started working on > > it once, but had to give up when it became fairly complicated and I > > ran out of time. I plan to work on this again soon, but before I > > start, I'd like to get some feedback. > > > > For functions that are wrappers around others (like inline or > > anonymous function handles) it would be swell if we could write > > something as simple as (for example) > > > > function varargout = foo (varargin) > > [varargout{:}] = svd (varargin{:}); > > endfunction > > > > and have it work in all cases: > > > > foo ([1,2;3,4]); > > sigma = foo ([1,2;3,4]); > > [u, s, v] = foo ([1,2;3,4]); > > > > Can someone tell me whether this will work in Matlab R14? In R13 it > > fails for the nargout == 0 case with an error about the subscript > > count of the cell array being zero, and also for the nargout > 0 cases > > because varargout is not preallocated automatically based on the value > > of nargout, so you have to write the wrapper as > > > > function varargout = foo (varargin) > > if (nargout == 0) > > svd (varargin{:}); > > else > > varargout = cell (nargout, 1); > > [varargout{:}] = svd (varargin{:}); > > end > > > > But even this is not quite right as ans (in the nargout == 0 case) is > > not propagated to varargout. So really, you have to write > > > > function varargout = foo (varargin) > > if (nargout == 0) > > svd (varargin{:}); > > varagout = ans; > > else > > varargout = cell (nargout, 1); > > [varargout{:}] = svd (varargin{:}); > > end > > > > Hmm. Although in the svd case, the behavior is identical for the > > nargout == 0 and nargout == 1 cases, that may not always be the case. > > So we can't write > > > > function varargout = foo (varargin) > > n = nargout; > > if (nargout == 0) > > n = 1; > > end > > varargout = cell (n, 1); > > [varargout{:}] = svd (varargin{:}); > > > > But, *could* we make > > > > function varargout = foo (varargin) > > [varargout{:}] = svd (varargin{:}); > > endfunction > > > > do this automatically? I think we would only have to do the > > following (in addition to making the [x{:}] = foo (...) syntax work to > > begin with): > > > > * Preallocate varargout based on the value of nargout. > > > > * Allow > > > > retval = {}; > > [retval{:}] = fcn (...); > > > > to work such that nargout is set to 0 for fcn, but if fcn returns > > any values, retval is reallocated to a one-element cell array to > > hold toe first returned value. > > > > Would these special cases cause trouble anywhere else (i.e., change > > the behavior of currently valid code)? > > > > jwe > > > > > From maintainers-request@octave.org Fri Sep 17 11:06:30 2004 Resent-Date: Fri, 17 Sep 2004 11:06:29 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 17 Sep 2004 18:07:18 +0200 From: Bart Vandewoestyne To: maintainers@octave.org Subject: Matlab's random number generator Message-ID: <20040917160718.GA8662@forsythe> Mail-Followup-To: maintainers@octave.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: Bart Vandewoestyne X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Hello all, I've taken a look at the randtx.m file, and i think i understand most of it. Just to get to know Octave-non-m-file-programming, i would like to try to implement this as a built-in Octave function and see if i can get the same random numbers as Matlab R13. Since this would be the first time i write non-m-file-code for Octave, i would like to know what is the place to start for me? Where should the code i write for randtx hook in? What documentation/other code can i best take a look at to see some examples on how to do this? In the first place, this is my very own personal experimental project, but if I succeed, i might as well send you the source code. I cannot garantuee that i succed though ;-) Regards, Bart -- !!!!!!!!!!!!!!!!!!! email change !!!!!!!!!!!!!!!!!!!!!!! My email address is now Bart.Vandewoestyne AT telenet.be Please update your addressbook! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From maintainers-request@octave.org Fri Sep 17 13:26:25 2004 Resent-Date: Fri, 17 Sep 2004 13:26:11 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: Date: Fri, 17 Sep 2004 11:24:30 -0700 From: Keith Goodman Reply-To: Keith Goodman To: octave maintainers mailing list Subject: Searching for strings Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: <0TJsMB.A.ULF.CxySBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org I often need to find all of the m files that call a given function. Would a glorified version of the following function be useful to Octave users? function matches = filefind(findstring) command = ['find . -name "*.m" -print0 | xargs -r -0 grep -l ' findstring]; [matches,status] = system(command); I stole the find command from its info page. In general, I think a lot of the GUI utilities provided by Matlab can be converted into text versions in Octave. I'd like to see text-based menu-driven utlities for administering the Octave path, for setting up the user environment (prompt, paging, suppress_verbose_help_message, etc.), and perhaps for searching. Any interest? From maintainers-request@octave.org Mon Sep 20 04:22:49 2004 Resent-Date: Mon, 20 Sep 2004 04:22:38 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <414E9FF4.7010401@tugraz.at> Date: Mon, 20 Sep 2004 11:16:36 +0200 From: Alois Schloegl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John W. Eaton" CC: David Bateman , maintainers@octave.org Subject: Re: Cell arrays of strings in "sort" and "unique" References: <20040915194030.GC12502@zfr01-2089.crm.mot.com> <41494702.6000307@tugraz.at> <16713.40605.22886.42054@devzero.bogus.domain> In-Reply-To: <16713.40605.22886.42054@devzero.bogus.domain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org John W. Eaton wrote: >On 16-Sep-2004, Alois Schloegl wrote: > >| This means, from a users-point-of-view, SORT can put NaNs in the >| beginning or at the end - it does not really matter. > >If it does not really matter where they go, then they might as well be >placed in a way that is compatible with the other leading brand. That >way, people can expect consistent results when they move their code to >Octave. > >jwe > > Yes, of course. I tried only to constitute a reasing that does not require any reference to the "other leading brand". IMHO, the outcome of such kind of reasoning should be the basis for the decision. Alois From maintainers-request@octave.org Wed Sep 22 00:19:54 2004 Resent-Date: Wed, 22 Sep 2004 00:19:53 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16721.2671.299591.529682@devzero.bogus.domain> Date: Wed, 22 Sep 2004 01:15:27 -0400 To: octave maintainers mailing list Subject: Octave 2.1.59 available for ftp X-Mailer: VM 7.17 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Octave 2.1.59 is now available for ftp from ftp.octave.org in the directory /pub/octave/bleeding-edge: -rw-r--r-- 1 1005 5486102 Sep 21 22:39 octave-2.1.59.tar.gz -rw-r--r-- 1 1005 4288120 Sep 21 22:39 octave-2.1.59.tar.bz2 -rw-r--r-- 1 1005 139085 Sep 21 23:08 octave-2.1.58-2.1.59.patch.gz -rw-r--r-- 1 1005 101953 Sep 21 23:08 octave-2.1.58-2.1.59.patch.bz2 89713907e98035f7d894eec05f77dc0f octave-2.1.59.tar.gz 0012b93b07347cb5094555c0a7aba5e5 octave-2.1.59.tar.bz2 030b91f58e1a251fe799fb7e9444323e octave-2.1.58-2.1.59.patch.gz 32247415055b28c42d9c67f5ec2ef017 octave-2.1.58-2.1.59.patch.bz2 Thanks to David Bateman for all his hard work to get this snapshot ready. This version includes many new features, including integer data types, inline functions, function handles, concatenation of structs, cell arrays and user-defined types, and better compatibility with the leading brand. Although I believe that 2.1.59 will be quite useable, there have been many changes and experience says that any number of unexpected problems could show up just after the tar file hits the ftp site, so 2.1.57 remains the recommended version for now. As always, if your favorite bug is still not fixed, please report it. jwe From maintainers-request@octave.org Wed Sep 22 11:30:11 2004 Resent-Date: Wed, 22 Sep 2004 11:30:05 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16721.46714.721512.56087@devzero.bogus.domain> Date: Wed, 22 Sep 2004 13:29:30 -0400 To: octave maintainers mailing list Subject: inline functions in Matlab R14 X-Mailer: VM 7.18 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Can someone who has Matlab R14 say what it does in the following cases? inline ('p_1+1') inline ('p+q') inline ('abc+xyz') Thanks, jwe From maintainers-request@octave.org Wed Sep 22 11:40:07 2004 Resent-Date: Wed, 22 Sep 2004 11:40:07 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Wed, 22 Sep 2004 18:36:15 +0200 From: David Bateman To: "John W. Eaton" Cc: octave maintainers mailing list Subject: Re: inline functions in Matlab R14 Message-ID: <20040922163615.GB25671@zfr01-2089.crm.mot.com> References: <16721.46714.721512.56087@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16721.46714.721512.56087@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <6kQRiC.A.cYB.mraUBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org According to John W. Eaton (on 09/22/04): > Can someone who has Matlab R14 say what it does in the following > cases? > > inline ('p_1+1') > > inline ('p+q') > > inline ('abc+xyz') Could I also suggest the case inline ('Abc+xyZ') as the documentation is seems to imply special treatment for upper and lower case characters... D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Wed Sep 22 11:49:41 2004 Resent-Date: Wed, 22 Sep 2004 11:49:41 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <3EE2ABBCFEA761449CF76DF1BB73E1C5916256@pusehe0o.eh.pweh.com> From: "Hall, Benjamin" To: "'John W. Eaton'" , octave maintainers mailing list Subject: RE: inline functions in Matlab R14 Date: Wed, 22 Sep 2004 12:41:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Scanned-By: MIMEDefang 2.39 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org >> inline('p_1+1') ans = Inline function: ans(p_1) = p_1+1 >> inline('p+q') ans = Inline function: ans(p,q) = p+q >> inline('abc+xyz') ans = Inline function: ans(abc,xyz) = abc+xyz -----Original Message----- From: John W. Eaton [mailto:jwe@bevo.che.wisc.edu] Sent: Wednesday, September 22, 2004 1:30 PM To: octave maintainers mailing list Subject: inline functions in Matlab R14 Can someone who has Matlab R14 say what it does in the following cases? inline ('p_1+1') inline ('p+q') inline ('abc+xyz') Thanks, jwe From maintainers-request@octave.org Wed Sep 22 11:51:21 2004 Resent-Date: Wed, 22 Sep 2004 11:51:21 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <3EE2ABBCFEA761449CF76DF1BB73E1C5916257@pusehe0o.eh.pweh.com> From: "Hall, Benjamin" To: "'David Bateman'" , "John W. Eaton" Cc: octave maintainers mailing list Subject: RE: inline functions in Matlab R14 Date: Wed, 22 Sep 2004 12:43:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Scanned-By: MIMEDefang 2.39 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Still seems to get it right. Matlab indicates they're using a function called "symvar" to figure out what are the variables. >> inline('Abc+xyZ') ans = Inline function: ans(Abc,xyZ) = Abc+xyZ -----Original Message----- From: David Bateman [mailto:David.Bateman@motorola.com] Sent: Wednesday, September 22, 2004 12:36 PM To: John W. Eaton Cc: octave maintainers mailing list Subject: Re: inline functions in Matlab R14 According to John W. Eaton (on 09/22/04): > Can someone who has Matlab R14 say what it does in the following > cases? > > inline ('p_1+1') > > inline ('p+q') > > inline ('abc+xyz') Could I also suggest the case inline ('Abc+xyZ') as the documentation is seems to imply special treatment for upper and lower case characters... D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From maintainers-request@octave.org Wed Sep 22 11:53:05 2004 Resent-Date: Wed, 22 Sep 2004 11:53:04 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <4151AD28.7000900@ieee.org> Date: Wed, 22 Sep 2004 11:49:44 -0500 From: Quentin Spencer User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Bateman CC: "John W. Eaton" , octave maintainers mailing list Subject: Re: inline functions in Matlab R14 References: <16721.46714.721512.56087@devzero.bogus.domain> <20040922163615.GB25671@zfr01-2089.crm.mot.com> In-Reply-To: <20040922163615.GB25671@zfr01-2089.crm.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Here's the output I get: < M A T L A B > Copyright 1984-2004 The MathWorks, Inc. Version 7.0.0.19901 (R14) May 06, 2004 To get started, type one of these: helpwin, helpdesk, or demo. For product information, visit www.mathworks.com. >> >> inline ('p_1+1') ans = Inline function: ans(p_1) = p_1+1 >> inline ('p+q') ans = Inline function: ans(p,q) = p+q >> inline ('abc+xyz') ans = Inline function: ans(abc,xyz) = abc+xyz >> inline ('Abc+xyZ') ans = Inline function: ans(Abc,xyZ) = Abc+xyZ David Bateman wrote: >According to John W. Eaton (on 09/22/04): > > >>Can someone who has Matlab R14 say what it does in the following >>cases? >> >> inline ('p_1+1') >> >> inline ('p+q') >> >> inline ('abc+xyz') >> >> > >Could I also suggest the case > > > inline ('Abc+xyZ') > >as the documentation is seems to imply special treatment for upper and >lower case characters... > >D. > > > From maintainers-request@octave.org Wed Sep 22 11:54:20 2004 Resent-Date: Wed, 22 Sep 2004 11:54:19 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16721.48169.904632.3721@devzero.bogus.domain> Date: Wed, 22 Sep 2004 13:53:45 -0400 To: "Hall, Benjamin" Cc: "'David Bateman'" , octave maintainers mailing list Subject: RE: inline functions in Matlab R14 In-Reply-To: <3EE2ABBCFEA761449CF76DF1BB73E1C5916257@pusehe0o.eh.pweh.com> References: <3EE2ABBCFEA761449CF76DF1BB73E1C5916257@pusehe0o.eh.pweh.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 22-Sep-2004, Hall, Benjamin wrote: | Still seems to get it right. For some value of "right". The observed behavior does not seem to match my reading of the docs. jwe From maintainers-request@octave.org Wed Sep 22 11:54:28 2004 Resent-Date: Wed, 22 Sep 2004 11:54:28 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <4151AC73.6080602@kcl.ac.uk> Date: Wed, 22 Sep 2004 17:46:43 +0100 From: "Philipp.Batchelor" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, zh-cn MIME-Version: 1.0 CC: octave maintainers mailing list Subject: Re: inline functions in Matlab R14 References: <16721.46714.721512.56087@devzero.bogus.domain> In-Reply-To: <16721.46714.721512.56087@devzero.bogus.domain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-KCLSpamScore: 0 X-KCLRealSpamScore: -0.0 X-KCLZStatus: 0 X-KCLSpamReport: BAYES_44=-0.001 X-KCL-MailScanner: Found to be clean X-MailScanner-From: philipp.batchelor@kcl.ac.uk X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Resent-Message-ID: To: maintainers@octave.org Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org John W. Eaton wrote: > Can someone who has Matlab R14 say what it does in the following > cases? > > inline ('p_1+1') > > inline ('p+q') > > inline ('abc+xyz') > > Thanks, > > jwe > Here is what I get:(seems meaningful): I removed some empty lines: 'p_1+1' is a function of one variable, others of two variables (complains with 1 input). ------------------------------- >> version ans = 7.0.0.19901 (R14) >> inline ('p_1+1') ans = Inline function: ans(p_1) = p_1+1 >> inline ('p+q') ans = Inline function: ans(p,q) = p+q >> inline ('abc+xyz') ans = Inline function: ans(abc,xyz) = abc+xyz % and testing: >> g = inline ('p_1+1') g = Inline function: g(p_1) = p_1+1 >> g(1) ans = 2 >> g(2) ans = 3 >> k = inline ('p+q') k = Inline function: k(p,q) = p+q >> k(1,1), k(pi,exp(1)) ans = 2 ans = 5.8599 >> h = inline ('abc+xyz') h = Inline function: h(abc,xyz) = abc+xyz >> h(1,1) ans = 2 >> h(1,2) ans = 3 >> l = inline ('Abc+xyZ') l = Inline function: l(Abc,xyZ) = Abc+xyZ >> l(1,pi) ans = 4.1416 % and for vector inputs: >> g([1,1]) ans = 2 2 >> l([1,1],2) ans = 3 3 From maintainers-request@octave.org Thu Sep 23 07:28:56 2004 Resent-Date: Thu, 23 Sep 2004 07:28:45 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Thu, 23 Sep 2004 14:24:38 +0200 From: David Bateman To: Quentin Spencer Cc: "John W. Eaton" , octave maintainers mailing list Subject: Re: inline functions in Matlab R14 Message-ID: <20040923122438.GD28376@zfr01-2089.crm.mot.com> References: <16721.46714.721512.56087@devzero.bogus.domain> <20040922163615.GB25671@zfr01-2089.crm.mot.com> <4151AD28.7000900@ieee.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <4151AD28.7000900@ieee.org> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Even worse, what do inline('sin (x)') and inline('y (x)') give.. I suspect they give ans = Inline function: f(x) = sin (x) and ans = Inline function: f(x) = y (x) since how can you tell if "sin" and "y" are functions or not. Even if they aren't when you define the inline function they might be afterwards... Another ambiguity is inline('x+i'), inline('x+j'), inline('x+I'), inline('x+J') the first two should have i and j ignored. But matlab doesn't define I and J. Also what about the octave built in constants "e" and "E"? Should they also be ignored... I also noticed that matlab sorts the arguments in ascii order. So that inline('a+Y') -> f = Inline function: f(Y,a) = a+Y Grrr, this is a case where matlabs documentation doesn't even closely resemble what they actually do. The attached patch tries to do something similar to the matlab behaviour. I ignore the octave builtin constants "I", "J", "e" and "E"... John, its up to you if you also want to drop these as potential inline function arguments... D. 2004-09-23 David Bateman * ov-fcn-inline.cc (Finline): Do what the other brand actually does, rather than what they say they do. According to Quentin Spencer (on 09/22/04): > Here's the output I get: > > < M A T L A B > > Copyright 1984-2004 The MathWorks, Inc. > Version 7.0.0.19901 (R14) > May 06, 2004 > > > To get started, type one of these: helpwin, helpdesk, or demo. > For product information, visit www.mathworks.com. > > >> > >> inline ('p_1+1') > ans = > Inline function: > ans(p_1) = p_1+1 > >> inline ('p+q') > ans = > Inline function: > ans(p,q) = p+q > >> inline ('abc+xyz') > ans = > Inline function: > ans(abc,xyz) = abc+xyz > >> inline ('Abc+xyZ') > ans = > Inline function: > ans(Abc,xyZ) = Abc+xyZ > > > > > David Bateman wrote: > > >According to John W. Eaton (on 09/22/04): > > > > > >>Can someone who has Matlab R14 say what it does in the following > >>cases? > >> > >> inline ('p_1+1') > >> > >> inline ('p+q') > >> > >> inline ('abc+xyz') > >> > >> > > > >Could I also suggest the case > > > > > > inline ('Abc+xyZ') > > > >as the documentation is seems to imply special treatment for upper and > >lower case characters... > > > >D. > > > > > > -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.sort20040923" *** src/ov-fcn-inline.cc.orig2 2004-09-23 13:24:34.000000000 +0200 --- src/ov-fcn-inline.cc 2004-09-23 14:21:19.000000000 +0200 *************** *** 574,584 **** @deftypefnx {Built-in Function} {} inline (@var{str}, @var{arg1}, ...)\n\ @deftypefnx {Built-in Function} {} inline (@var{str}, @var{n})\n\ Create an inline function from the character string @var{str}.\n\ ! If called with a single argument, the generated function is\n\ ! assumed to have a single argument and will be defined as the\n\ ! isolated lower case character, except i or j, that is closest\n\ ! to x. If more than argument is the same distance from x, the\n\ ! one later in the alphabet is chosen.\n\ \n\ If the second and subsequent arguments are character strings,\n\ they are the names of the arguments of the function.\n\ --- 574,586 ---- @deftypefnx {Built-in Function} {} inline (@var{str}, @var{arg1}, ...)\n\ @deftypefnx {Built-in Function} {} inline (@var{str}, @var{n})\n\ Create an inline function from the character string @var{str}.\n\ ! If called with a single argument, the arguments of the generated\n\ ! function are extracted from the function itself. The generated\n\ ! function arguments will then be in alphabetical order. It should\n\ ! be noted that i, and j are ignored as arguments due to the\n\ ! ambiguity between their use as a variable or their use as an inbuilt\n\ ! constant. All arguments followed by a parentheses are considered\n\ ! to be functions.\n\ \n\ If the second and subsequent arguments are character strings,\n\ they are the names of the arguments of the function.\n\ *************** *** 602,635 **** if (nargin == 1) { ! int dist = -1; ! char c = '\0'; ! ! fargs.resize (1); ! fargs(0) = "x"; ! ! int fun_len = fun.length (); ! ! for (int i = 0; i < fun_len; i++) { ! char new_c = fun[i]; ! if (new_c != 'i' && new_c != 'j' ! && islower (new_c) ! && (i == 0 || ! islower (fun[i-1])) ! && (i == fun_len || ! islower (fun[i+1]))) { ! int new_dist = std::abs (new_c - 'x'); ! if (dist == -1 || new_dist < dist ! || (new_dist == dist && c < new_c)) { ! fargs(0) = new_c; ! dist = new_dist; ! c = new_c; } } } } else if (nargin == 2 && args(1).is_numeric_type ()) { --- 604,673 ---- if (nargin == 1) { ! bool is_arg = false; ! std::string tmp_arg; ! size_t i = 0; ! ! while (i < fun.length ()) { ! char c = fun[i++]; ! if (! isalpha (c) || c == '_') ! if (! is_arg) ! continue; ! else if (isdigit (c)) ! tmp_arg.append (1, c); ! else ! { ! bool have_arg = false; ! ! // Before we do anything remove trailing whitespaces ! while (i < fun.length () && isspace (c)) ! c = fun[i++]; ! ! // Do we have a variable or a function? ! if (c != '(') ! { ! for (int j = 0; j < fargs.length (); j++) ! if (tmp_arg == fargs (j)) ! { ! have_arg = true; ! break; ! } ! ! // "i" and "j" aren't valid arguments ! if (! have_arg && tmp_arg != "i" && tmp_arg != "j") ! fargs.append (tmp_arg); ! } ! ! tmp_arg = std::string (); ! is_arg = false; ! } ! else { ! tmp_arg.append (1, c); ! is_arg = true; ! if (i == fun.length ()) { ! bool have_arg = false; ! ! for (int j = 0; j < fargs.length (); j++) ! if (tmp_arg == fargs (j)) ! { ! have_arg = true; ! break; ! } ! ! if (! have_arg && tmp_arg != "i" && tmp_arg != "j") ! fargs.append (tmp_arg); } } } + + // Sort the arguments into ascii order + fargs.qsort (); + } else if (nargin == 2 && args(1).is_numeric_type ()) { --8t9RHnE3ZwKMSgU+-- From maintainers-request@octave.org Fri Sep 24 08:53:32 2004 Resent-Date: Fri, 24 Sep 2004 08:53:32 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16724.9912.907986.403087@devzero.bogus.domain> Date: Fri, 24 Sep 2004 09:52:56 -0400 To: David Bateman Cc: Quentin Spencer , octave maintainers mailing list Subject: Re: inline functions in Matlab R14 In-Reply-To: <20040923122438.GD28376@zfr01-2089.crm.mot.com> References: <16721.46714.721512.56087@devzero.bogus.domain> <20040922163615.GB25671@zfr01-2089.crm.mot.com> <4151AD28.7000900@ieee.org> <20040923122438.GD28376@zfr01-2089.crm.mot.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 23-Sep-2004, David Bateman wrote: | Even worse, what do | | inline('sin (x)') | | and | | inline('y (x)') | | give.. I suspect they give | | ans = | | Inline function: | f(x) = sin (x) | | and | | ans = | | Inline function: | f(x) = y (x) | | since how can you tell if "sin" and "y" are functions or not. Even if they | aren't when you define the inline function they might be afterwards... In Matlab, that is not possible because all functions are either built-in or defined in a .m file somewhere in your path. Although I suppose you could modify the path later and a new function would be available. In that case, I don't think it would go back and alter the affected inline functions, but if you used the same inline again, this time with the external function(s) available, I would expect it to change the meaning. Once again, bad design. Is it surprising? | Another ambiguity is | | inline('x+i'), inline('x+j'), inline('x+I'), inline('x+J') | | the first two should have i and j ignored. But matlab doesn't define | I and J. Also what about the octave built in constants "e" and "E"? | Should they also be ignored... Ugh. | The attached patch tries to do something similar to the matlab behaviour. | I ignore the octave builtin constants "I", "J", "e" and "E"... John, its | up to you if you also want to drop these as potential inline function | arguments... OK, I applied the patch (sorry I missed it yesterday). Unfortunately, it does not really recognize functions correctly. What if you do inline ('array_variable(2)') (i.e., you are defining a function to extract elements from an array). The current version of inline does this: octave:1> inline ('array_variable (2)') ans = f(array) = array_variable (2) octave:2> inline ('arrayvar (2)') ans = f() = arrayvar (2) In both cases, Matlab apparently does f(x) = arrayvar (2) which also seems wrong. I have no function called arrayvar defined, so it should be recognized as an argument to the function. So even Matlab is not actually looking at what functions are available. It is just using some lame half-parsing rules. I don't think that can possibly work in all cases. BTW, it appears that your code will recognize variable names inside character strings. Also, what about functions that do not expect arguments. In Matlab, you are not allowed to write eye () to call a function, so you must write the name alone. In that case, you might write a wrapper function as inline like this: inline ('eye + 3') but again, the current version of inline recognizes 'eye" as a variable here. Oh well, Matlab seems to do the same. So the only real "bugs" that I see in the current code are: * It doesn't recognize "_" in symbol names. Matlab R13 does not recognize leading underscores, but does recognize embedded underscores. Perhaps that is a bug? * It doesn't handle things like inline ('foo (''bar baz'', x, y, z)') correctly -- the only args should be x, y, and z. * It doesn't use "x" as the default variable name, passed when no other variables are recognized (why it does this, I have no idea). Finally, fixing these things is not all that important to me. I'd file this in the category of bug-for-bug compatibility. I think the only safe thing to do is always specify the arguments explicitly. jwe From maintainers-request@octave.org Fri Sep 24 09:56:19 2004 Resent-Date: Fri, 24 Sep 2004 09:56:13 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Date: Fri, 24 Sep 2004 16:52:02 +0200 From: David Bateman To: "John W. Eaton" Cc: Quentin Spencer , octave maintainers mailing list Subject: Re: inline functions in Matlab R14 Message-ID: <20040924145202.GC1640@zfr01-2089.crm.mot.com> References: <16721.46714.721512.56087@devzero.bogus.domain> <20040922163615.GB25671@zfr01-2089.crm.mot.com> <4151AD28.7000900@ieee.org> <20040923122438.GD28376@zfr01-2089.crm.mot.com> <16724.9912.907986.403087@devzero.bogus.domain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: <16724.9912.907986.403087@devzero.bogus.domain> User-Agent: Mutt/1.4.1i X-Organization: Centre de Recherche de Motorola - Paris X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline According to John W. Eaton (on 09/24/04): > | since how can you tell if "sin" and "y" are functions or not. Even if they > | aren't when you define the inline function they might be afterwards... > > In Matlab, that is not possible because all functions are either > built-in or defined in a .m file somewhere in your path. Although I > suppose you could modify the path later and a new function would be > available. In that case, I don't think it would go back and alter the > affected inline functions, but if you used the same inline again, this > time with the external function(s) available, I would expect it to > change the meaning. Once again, bad design. Is it surprising? Agreed.. > | Another ambiguity is > | > | inline('x+i'), inline('x+j'), inline('x+I'), inline('x+J') > | > | the first two should have i and j ignored. But matlab doesn't define > | I and J. Also what about the octave built in constants "e" and "E"? > | Should they also be ignored... > > Ugh. Completely agreed, so should we also ignore [IJeE] ? > | The attached patch tries to do something similar to the matlab behaviour. > | I ignore the octave builtin constants "I", "J", "e" and "E"... John, its > | up to you if you also want to drop these as potential inline function > | arguments... > > OK, I applied the patch (sorry I missed it yesterday). Unfortunately, > it does not really recognize functions correctly. What if you do > > inline ('array_variable(2)') Yes, that is what I was trying to get at with inline('x(y)'), where matlab returns ans = Inline function: f(x) = y (x) It seems that in fact even the inline version in R12 returns the same behaviour as R14, so it is unforgivable that Matlab's doc are so out of date for inline. In any case, matlab assumes that [_a-zA-Z][_a-zA-Z0-9]*[\S]*( is a function always... It doesn't seem to check the symbol table at all For example >> x = [1:3]; >> f = inline('x(y)') f = Inline function: f(y) = x(y) >> f(1) ??? Error using ==> inlineeval Error in inline expression ==> x(y) ??? Undefined function or variable 'x'. Error in ==> /crm/pacome/Matlab6.1/toolbox/matlab/funfun/@inline/subsref.m On line 25 ==> INLINE_OUT_ = inlineeval(INLINE_INPUTS_, INLINE_OBJ_.inputExpr, INLINE_OBJ_.expr); > (i.e., you are defining a function to extract elements from an > array). The current version of inline does this: > > octave:1> inline ('array_variable (2)') > ans = > > f(array) = array_variable (2) > > octave:2> inline ('arrayvar (2)') > ans = > > f() = arrayvar (2) > > In both cases, Matlab apparently does > > f(x) = arrayvar (2) > > which also seems wrong. I have no function called arrayvar defined, > so it should be recognized as an argument to the function. So even > Matlab is not actually looking at what functions are available. It is > just using some lame half-parsing rules. I don't think that can > possibly work in all cases. BTW, it appears that your code will > recognize variable names inside character strings. If arrayvar isn't available in the inline function, then it can't be evaluated with subsref in any case, so it has to be passed as an argument for this to make sense. Yes f() = arrayvar (2) is a bug however, but pretty stupid as it means there are no args to the inline function... > Also, what about functions that do not expect arguments. In Matlab, > you are not allowed to write > > eye () > > to call a function, so you must write the name alone. In that case, > you might write a wrapper function as inline like this: > > inline ('eye + 3') > > but again, the current version of inline recognizes 'eye" as a > variable here. Oh well, Matlab seems to do the same. > > So the only real "bugs" that I see in the current code are: > > * It doesn't recognize "_" in symbol names. Matlab R13 does not > recognize leading underscores, but does recognize embedded > underscores. Perhaps that is a bug? ok, this is a bug.. if (! isalpha (c) || c == '_') should read if (! isalpha (c) && c != '_') I also missed a trailing digit on the last arg, so that inline('a+x1') wouldn't work either... > * It doesn't handle things like > > inline ('foo (''bar baz'', x, y, z)') > > correctly -- the only args should be x, y, and z. Didn't think of that one... Grrrr... Ok, think for that and the aboved attached. > * It doesn't use "x" as the default variable name, passed when no > other variables are recognized (why it does this, I have no idea). Yes I thought about, this but then thought it wasn't worth treating as if there are no args, whats the point of defining an arbitrary one.. > Finally, fixing these things is not all that important to me. I'd > file this in the category of bug-for-bug compatibility. I think > the only safe thing to do is always specify the arguments explicitly. I promise I'll leave it alone after this.. Its taken way too much time... D. -- David Bateman David.Bateman@motorola.com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.sort20040924" *** src/ov-fcn-inline.cc~ 2004-09-23 14:21:19.000000000 +0200 --- src/ov-fcn-inline.cc 2004-09-24 16:48:58.000000000 +0200 *************** *** 605,667 **** if (nargin == 1) { bool is_arg = false; std::string tmp_arg; size_t i = 0; while (i < fun.length ()) { char c = fun[i++]; ! if (! isalpha (c) || c == '_') if (! is_arg) continue; else if (isdigit (c)) ! tmp_arg.append (1, c); else { - bool have_arg = false; - // Before we do anything remove trailing whitespaces while (i < fun.length () && isspace (c)) c = fun[i++]; ! // Do we have a variable or a function? if (c != '(') { ! for (int j = 0; j < fargs.length (); j++) ! if (tmp_arg == fargs (j)) ! { ! have_arg = true; ! break; ! } ! ! // "i" and "j" aren't valid arguments ! if (! have_arg && tmp_arg != "i" && tmp_arg != "j") ! fargs.append (tmp_arg); } - - tmp_arg = std::string (); - is_arg = false; } else { tmp_arg.append (1, c); is_arg = true; ! if (i == fun.length ()) ! { ! bool have_arg = false; ! ! for (int j = 0; j < fargs.length (); j++) ! if (tmp_arg == fargs (j)) ! { ! have_arg = true; ! break; ! } ! if (! have_arg && tmp_arg != "i" && tmp_arg != "j") ! fargs.append (tmp_arg); ! } } } --- 605,672 ---- if (nargin == 1) { bool is_arg = false; + bool in_string = false; std::string tmp_arg; size_t i = 0; while (i < fun.length ()) { + bool terminate_arg = false; char c = fun[i++]; ! if (in_string) ! { ! if (c == '\'' || c == '\"') ! in_string = false; ! } ! else if (c == '\'' || c == '\"') ! { ! in_string = true; ! if (is_arg) ! terminate_arg = true; ! } ! else if (! isalpha (c) && c != '_') if (! is_arg) continue; else if (isdigit (c)) ! tmp_arg.append (1, c); else { // Before we do anything remove trailing whitespaces while (i < fun.length () && isspace (c)) c = fun[i++]; ! // Do we have a variable or a function? if (c != '(') + terminate_arg = true; + else { ! tmp_arg = std::string (); ! is_arg = false; } } else { tmp_arg.append (1, c); is_arg = true; + } ! if (terminate_arg || (i == fun.length () && is_arg)) ! { ! bool have_arg = false; ! ! for (int j = 0; j < fargs.length (); j++) ! if (tmp_arg == fargs (j)) ! { ! have_arg = true; ! break; ! } ! if (! have_arg && tmp_arg != "i" && tmp_arg != "j") ! fargs.append (tmp_arg); ! ! tmp_arg = std::string (); ! is_arg = false; } } --/WwmFnJnmDyWGHa4-- From maintainers-request@octave.org Fri Sep 24 10:05:28 2004 Resent-Date: Fri, 24 Sep 2004 10:05:28 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16724.14226.942915.491292@devzero.bogus.domain> Date: Fri, 24 Sep 2004 11:04:50 -0400 To: David Bateman Cc: Quentin Spencer , octave maintainers mailing list Subject: Re: inline functions in Matlab R14 In-Reply-To: <20040924145202.GC1640@zfr01-2089.crm.mot.com> References: <16721.46714.721512.56087@devzero.bogus.domain> <20040922163615.GB25671@zfr01-2089.crm.mot.com> <4151AD28.7000900@ieee.org> <20040923122438.GD28376@zfr01-2089.crm.mot.com> <16724.9912.907986.403087@devzero.bogus.domain> <20040924145202.GC1640@zfr01-2089.crm.mot.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: <3P5Ov.A.5EF.3eDVBB@bevo> Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org On 24-Sep-2004, David Bateman wrote: | Completely agreed, so should we also ignore [IJeE] ? I'd say let's not bother. | I promise I'll leave it alone after this.. Its taken way too much time... OK. Thanks for the patch. I've applied it. I'll be making the 2.1.60 snapshot soon, so if there are any other problems, please let me know as soon as possible. jwe From maintainers-request@octave.org Fri Sep 24 14:20:42 2004 Resent-Date: Fri, 24 Sep 2004 14:20:40 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16724.29542.788692.764216@devzero.bogus.domain> Date: Fri, 24 Sep 2004 15:20:06 -0400 To: octave maintainers mailing list Subject: Octave 2.1.60 available for ftp X-Mailer: VM 7.18 under Emacs 21.3.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Octave 2.1.60 is now available for ftp from ftp.octave.org in the directory /pub/octave/bleeding-edge: -rw-r--r-- 1 1005 5490701 Sep 24 13:02 octave-2.1.60.tar.gz -rw-r--r-- 1 1005 4293888 Sep 24 13:02 octave-2.1.60.tar.bz2 -rw-r--r-- 1 1005 24836 Sep 24 13:03 octave-2.1.59-2.1.60.patch.gz -rw-r--r-- 1 1005 18645 Sep 24 13:03 octave-2.1.59-2.1.60.patch.bz2 8f012a500d834bf5633cd9173b64565b octave-2.1.60.tar.gz d332151ada009a14e4e4e37521a4ccfa octave-2.1.60.tar.bz2 0f8e707490efcfde87f98fdf88aa170c octave-2.1.59-2.1.60.patch.gz eb23d22b9f09bd42e97796e0c956115a octave-2.1.59-2.1.60.patch.bz2 Thanks again to David Bateman for all his hard work to get this snapshot ready. This version includes many new features, including integer data types, inline functions, function handles, concatenation of structs, cell arrays and user-defined types, and better compatibility with the leading brand. Although I believe that 2.1.60 will be quite useable, there have been many changes and experience says that any number of unexpected problems could show up just after the tar file hits the ftp site, so 2.1.57 remains the recommended version for now. As always, if your favorite bug is still not fixed, please report it. jwe From maintainers-request@octave.org Mon Sep 27 07:18:34 2004 Resent-Date: Mon, 27 Sep 2004 07:18:17 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <41580545.8080509@cs.uu.nl> Date: Mon, 27 Sep 2004 14:19:17 +0200 From: Rob Vermaas User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040830) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John W. Eaton" Cc: octave maintainers mailing list Subject: Re: Octave compiler References: <413ECBEB.6020807@cs.uu.nl> <16703.9459.113718.362299@devzero.bogus.domain> In-Reply-To: <16703.9459.113718.362299@devzero.bogus.domain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (pigwidgeon) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.63 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org Hi, Sorry for the late response, but I've been quite busy in the meanwhile, as I found some of your remarks a good excuse to do some cleaning up and rewriting of the code of the compiler. >What are the problems you face when supporting built-in functions? >The code for those functions already exists, so shouldn't you be able >to link to liboctinterp/liboctave and have nearly all of them work? > > You are right that nearly all builtin function work. So mainly builtin functions that depend on the interpreter related things do not work completely. >I looked at the parser, and it seems you have adapted Octave's lexer >and parser. I think this is a good idea, as it makes little sense to >develop a separate parser from scratch. However, the code in Octave >is likely to change, so if you fork your own version, you are likely >to have a maintenance problem in the future. Would you like to help >introduce changes to Octave's parser so that it would be easier to >generate what you need without having to rewrite the actions part of >the paresr? It migth be possible to do that now, without any changes >to Octave, by writing a new new class based on Octave's tree_walker >class (in src/pt-walk.h) that can take Octave's tree representation of >the input and emit whatever you need for your front end. That way, >any changes to Octave's language in the parser/lexer would require >fewer changes to your code. > > I have followed your advise on writing a tree_walker implementation. It is nearly finished and works well. >The front end appears to have a list of built-in functions and >variables. How do you generate this list? Would you like to >contribute or help write patches to Octave's build system so that you >can generate this information automatically for new versions of Octave? > > As I changed to using more of the internals of Octave, these lists have become redundant, therefore it is not necessary for us to generate them. greetings, Rob Vermaas From maintainers-request@octave.org Tue Sep 28 10:22:17 2004 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Resent-From: jwe@bevo.che.wisc.edu Resent-Message-ID: <16729.33155.63661.304577@devzero.bogus.domain> Resent-Date: Tue, 28 Sep 2004 10:21:39 -0500 Resent-To: octave maintainers mailing list X-Authentication-Warning: bevo.che.wisc.edu: list set sender to listman using -f X-From_: Daniel.Heiserer@bmw.de Tue Sep 28 03:38:48 2004 Old-Date: Tue, 28 Sep 2004 10:36:20 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030212 X-Accept-Language: en-us, en References: <415819A3.70704@bmw.de> <16728.7226.129905.358270@devzero.bogus.domain> In-Reply-To: <16728.7226.129905.358270@devzero.bogus.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (errol) Old-X-Envelope-To: octave-maintainers Subject: file size limit From: Daniel Heiserer To: maintainers@octave.org CC: jwe@bevo.che.wisc.edu Date: Tue, 28 Sep 2004 03:38:48 -0500 Message-Id: <41592284.7060709@bmw.de> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org referring to http://www.octave.org/mailing-lists/octave-maintainers/2003/380 However if we implement a int64_t as the file positioning and take care of the mapping betweeWith gcc 3.4, streamoff and streampos are classes that hold 64-bit ints (either long long or int64_t). But they are not simple typedefs for either of these types, so it is still not possible to write something like streampos pos = ...; long long ftell_retval = (long long) pos; because there is no way to cast a streampos or streamoff type to an integer. For portability, we can't assume that these types are any particular integer value. Different systems are free to implement streamoff and streampos (or fpos_t if you are using C) in any way they choose (provided that they meet the rather limited constraints of the respective standards). Note that the MathWorks is going to face similar problems if they wish to support large files in Matlab. ----------------------------------------------------------------- my comments: If these are classes they should have an interface to set and get the value. If an int64_t is used as the positioning it should last for another 15 years. http://www.cplusplus.com/ref/iostream/streampos.html states: streampos cplusplus.com (stream position type) Type to express absolute positions within streams. This type describes a class to contain all the information needed to restore an arbitrary file-position indicator within a stream. It can be constructed from or casted to an integer offset value (streamoff). See also. iostream library For me that means that if octave uses a std::vector it will always be capable of positioning a file. All is needed is a forward and backward translation of the file position. -- daniel ----------------------------------------------------------------- > | I try to load a file with 8GB into octave. > | > | Unfortunately it immediately crashes once it hits the 2GB barrier: > | ----------------------------------------------------- > | octave:1> load ftn51.mat > | panic: Segmentation fault -- stopping myself... > | attempting to save variables to `octave-core'... > | save to `octave-core' complete > | Segmentation fault > | ----------------------------------------------------- > | My machine has 24GB main memory. > | The file has 8GB: > | 8153243903 Sep 27 14:22 ftn51.mat > | > | > | I used octave 2.1.44 on Itanium2, Linux 2.4.22-11.msc-smp ia64 > | However I will try 2.1.57 now. > > It won't help. This is a known problem, with no quick fix. However, > there have been some discussions about how to start fixing it (see the > maintainers list). So far, no one has started to do the work in a way > that will be likely to be included in a new snapshot or release. From maintainers-request@octave.org Wed Sep 29 14:47:19 2004 Resent-Date: Wed, 29 Sep 2004 14:47:03 -0500 X-Authentication-Warning: bevo.che.wisc.edu: list set sender to maintainers-request@octave.org using -f Message-ID: <415B10B5.6000407@ieee.org> Date: Wed, 29 Sep 2004 19:44:53 +0000 From: Quentin Spencer User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: octave maintainers mailing list Subject: More MATLAB Silliness Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (hedwig) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on bevo.che.wisc.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.64 Resent-Message-ID: Resent-From: maintainers@octave.org X-Mailing-List: X-Loop: maintainers@octave.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: maintainers-request@octave.org For anyone tracking weird things that MATLAB lets you do that somebody might ask for in octave someday, how about this: >> a=ones(2,1); >> b(1,:)=ones(2,1); >> whos Name Size Bytes Class a 2x1 16 double array b 1x2 16 double array I'm always unintentionally doing things like this in my code (assign a column vector to a row of a matrix), and in the past both Octave and MATLAB would give you an error, and I would fix it. Release 14 appears to have changed this to automatically detect what you meant to do and take care of it for you. A nice thought, I suppose, but I wonder what unintended consequences this could cause for an unsuspecting user. Are there any reasons other than convenience why this behavior is good? Any guesses on how many releases until they remove this feature? Quentin