[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About -0 and type complex
From: |
Daniel J Sebald |
Subject: |
Re: About -0 and type complex |
Date: |
Tue, 09 Oct 2012 22:45:41 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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
- About -0 and type complex, Michael D. Godfrey, 2012/10/09
- Re: About -0 and type complex, Daniel J Sebald, 2012/10/09
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: About -0 and type complex,
Daniel J Sebald <=