Re: unary mapper system redesigned + a few questions

[Judd Storrs]

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.

--judd