octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isreal benchmarking


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]