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: Jaroslav Hajek
Subject: Re: unary mapper system redesigned + a few questions
Date: Tue, 17 Nov 2009 20:24:00 +0100



On Tue, Nov 17, 2009 at 7:21 PM, John W. Eaton <address@hidden> wrote:
On 17-Nov-2009, Jaroslav Hajek wrote:

| > It's not only about the construction of -0 imaginary parts.  It's also
| > about preserving the result of a computation that generates a -0
| > imaginary part.
| >
| >
| Understood. But why is that desirable? Can you demonstrate practical needs?

I think 1/(-0) should result in -Inf, not Inf.


Yes. This would be still satisfied.
 
Hey, that's even Matlab compatible (:-), so it seems that Matlab does
store the sign of zero even if it doesn't display it.

Yes.
 
If you preserve the -0 for real values, then I think you should also
preserve them for imaginary values.


This is the "why?" I think you still haven't answered. If we do the auto-narrowing, why do we do it only for positive zeros? Dropping both would actually be more symmetric than the current behavior.
 
| > I'm still not convinced that we should discard -0 when it appears as
| > the imaginary part of a complex number but not -0 when it appears as a
| > real number.
| >
| >
| Why? Signed zero is not a mathematical concept; it's a feature of the IEEE
| 754 standard. I bet lots of Octave don't know anything about signed
| zeros.

Lot's of Octave users don't know much about floating point numbers
generally.


Yeah, and that's a good reason to keep things simple.
 
| I think the real problem here is that we have no pure imaginary type.
| >
| >
| Yes this has been talked about previously but the potential consistency
| advantages are still left to be narrowed down and it would surely complicate
| the existing implementation a lot.

I don't really expect to be able to implement a pure imaginary type
without some support from the implementation language (C++).


You mean like more than the general support for user classes? I guess you can safely forget that. Or do you have any information that this feature is planned?
 
| My suggestion is to avoid unnecessary special cases.

Narrowing is already a special case.

Yes. But we do want the narrowing, right? And if we want it, why not keep it simple?

| What I suggest is to revert back to the plain stupid: let's do the complex
| operation as nature (C++/BLAS) intended them to work, and let's
| automatically simplify purely real complex numbers to true reals.

C++ does not do that.  There is no automatic conversion from complex
to real.

C++ is a statically typed language so nothing of that sort is possible (unless polymorphic types are in question). OTOH, in the Matlab/Octave language automatic conversions are common. It's just different language. Do you suggest dropping the narrowing completely as a third alternative?

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

reply via email to

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