On Tue, Oct 9, 2012 at 8:45 PM, Daniel J Sebald
<address@hidden> wrote:
On 10/09/2012 10:03 PM, Michael D. Godfrey wrote:
On 10/09/2012 08:55 PM, Daniel J Sebald wrote:
[snip]
========================
But, of course, nothing can be done with x as complex
that does not explicitly modify its imaginary part.
I know.
It would be really nice to have useful limit/supremum representation, and it probably can be done but at a cost of extra CPU for something that may not find a great deal of use. Perhaps a mode that has more robust limit checking or something. The +0, -0 really only makes sense for limits, otherwise it is just zero. For example, this sort of thing
octave-cli:14> x = -0
x = -0
octave-cli:15> x
x = -0
in most cases should just produce zero. The problem is that if some routine wants to set the value of a variable to -0 meaning the limit or supremum, it is the same _expression_ as "- 0". Maybe if it were +Z, 0, and -Z. Or actually, the following syntax might work (this isn't actual output, I'm just hypothesizing)
oct> x = -0
x = 0
oct> x = (-0)
x = -0
oct> x = (+0)
x = +0
but there is no IEEE 754 representation for +0. Because of that, one can't devise any system that uses the underlying math libraries without imposing some first pass on the data that causes a performance hit.
Dan