|
From: | Daniel J Sebald |
Subject: | Re: isreal benchmarking |
Date: | Wed, 12 Sep 2012 14:24:08 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 09/12/2012 02:54 AM, John W. Eaton wrote:
On 11-Sep-2012, Daniel J Sebald wrote: | In Octave, exp(), log(), sqrt() all end up doing narrowing, which is | consistent with the math-op theme. (It would happen naturally if these | were script files using basic arithmetic, but I tested because they are | internal operations.) It's not that those functions do anything special to get the narrowing behavior. That happens by default any time a new octave_value object is created. You have to do something special to NOT get the narrowing behavior, by carefully constructing the octave_value object so that the narrowing is not performed. As far as I know that only happens in one place, and that is in the complex(re,im) function.
That's fine.As far as the narrowing involving syntax that isn't an arithmetic operation, I don't know. It certainly isn't a change to make shortly before a release given how many tests for isreal() (and iscomplex()) are in the m-scripts.
I do think though that before any possible change to the innards a change in the documentation is called for. Something that better describes isreal() and states that the isreal(x) is not the same as all(all(imag(x)==0)). I wouldn't object to deprecating iscomplex() either, or make its documentation the following: "iscomplex() is the complement of isreal(). See documentation for isreal()."
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |