octave-maintainers
[Top][All Lists]
Advanced

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

Re: unary mapper system redesigned + a few questions


From: John W. Eaton
Subject: Re: unary mapper system redesigned + a few questions
Date: Wed, 18 Nov 2009 02:56:31 -0500

On 18-Nov-2009, Judd Storrs wrote:

| On Wed, Nov 18, 2009 at 1:35 AM, Jaroslav Hajek <address@hidden> wrote:
| > I seriously doubt you need this done for every computation. In fact I'm
| > interested if you have any real-life script that starts producing wrong
| > results after the discussed patch is applied.
| 
| I have a quick question while I'm pondering this to think whether this
| change would affect what I do. Does this demotion behaviour only
| happen for scalars or will the type mangling affect matrices? I assume
| it doesn't affect matrices because it would be a pretty heavy
| operation to check all elements of a matrix.
| 
| I guess my response to the isreal() problem was that it was a bug in
| isreal() not checking the magnitude of the imaginary component. (1,-0)
| and (1,0) are should be real because the imaginary component is zero.
| Personally, I prefer to be explicit when a narrowing is expected e.g.
| use real() when I want it to happen.
| 
| >From a performance tweaking/optimization point of view, I'm not liking
| that type conversions become data-driven rather than programmer driven
| if you know what I mean. Won't it be confusing if some functions runs
| faster or uses more memory on some input data compared to others? If
| you're doing something time critical, how do you know if you've found
| the worst case? It would suck if things crash/fail randomly based on
| data representation of the input as a result.

Octave and Matlab both do this narrowing and it already happens for
complex matrices if the complex part is all 0 (just not -0).  This is
nothing new.

The check typically only happens when a value is stored in a variable,
not at each intermediate step in a calculation inside some built-in
function.

I would guess that the check is also not that slow for most real-world
data since most real-world complex arrays probably have many imaginary
parts that are nonzero.  A bad case would be a very large array with
a single nonzero imaginary part in the very last element...

jwe
<


reply via email to

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