[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
<
- Re: unary mapper system redesigned + a few questions, (continued)
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/17
- Re: unary mapper system redesigned + a few questions, John W. Eaton, 2009/11/17
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/17
- Re: unary mapper system redesigned + a few questions, John W. Eaton, 2009/11/17
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/17
- Re: unary mapper system redesigned + a few questions, John W. Eaton, 2009/11/17
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/17
- Re: unary mapper system redesigned + a few questions, John W. Eaton, 2009/11/17
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/18
- Re: unary mapper system redesigned + a few questions, Judd Storrs, 2009/11/18
- Re: unary mapper system redesigned + a few questions,
John W. Eaton <=
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/18
- Re: unary mapper system redesigned + a few questions, Judd Storrs, 2009/11/18
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/18
- Re: unary mapper system redesigned + a few questions, John W. Eaton, 2009/11/18
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/18
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/18
- Re: unary mapper system redesigned + a few questions, John W. Eaton, 2009/11/18
- Re: unary mapper system redesigned + a few questions, John W. Eaton, 2009/11/12
- Re: unary mapper system redesigned + a few questions, Jaroslav Hajek, 2009/11/13
- Re: unary mapper system redesigned + a few questions, Michael D. Godfrey, 2009/11/13