Re: About diagonal matrices

[Jaroslav Hajek]

On Sun, Feb 22, 2009 at 12:49 AM, Daniel J Sebald
<address@hidden> wrote:
> Daniel J Sebald wrote:
>>
>> John W. Eaton wrote:
>>
>>> On 20-Feb-2009, Daniel J Sebald wrote:
>>>
>>> | If I'm a user who wants to think in terms of the extended real
>>> | number system, then limits are of interest, i.e., Inf is the limit
>>> | as series x_i becomes positively unbounded (but not negatively
>>> | unbounded).  1/0 is fraught with problems though because it doesn't
>>> | indicate how the limit is approached.  That is, how do we know that
>>> | 1/0 is +Inf and not -Inf?  1/+0 could mean approach zero from the
>>> | left, so 1/+0 = +Inf.  Likewise 1/-0 = -Inf.  Octave agrees with
>>> | that train of thought, e.g.,
>>> | | octave:20> 1/(+0)
>>> | warning: division by zero
>>> | ans = Inf
>>> | octave:21> 1/(-0)
>>> | warning: division by zero
>>> | ans = -Inf
>>> | | But here is where the trouble shows up:
>>> | | octave:22> 1/(+0-0)
>>> | warning: division by zero
>>> | ans = Inf
>>> | octave:23> 1/(-0+0)
>>> | warning: division by zero
>>> | ans = Inf
>>> | | The problem is trying to treat 0 as both a number in the number
>>> system and the notion of a one-sided limit.  (Perhaps what some
>>> mathematician should have done long ago was to define the extended real
>>> number system as R union {+Inf, -Inf, +Zed, -Zed}.  Anyway...)
>>> | | And how about this one, irrespective of the previous comments?
>>> | | octave:42> sqrt(-0)
>>> | ans = -0
>>> | | Shouldn't that be complex 0 + 0i?  That is,
>>> | | octave:44> sqrt(-2)
>>> | ans =  0.00000 + 1.41421i
>>> | octave:45> sqrt(-1)
>>> | ans =  0 + 1i
>>> | octave:46> sqrt(-0.5)
>>> | ans =  0.00000 + 0.70711i
>>> | ...
>>> | sqrt(lim x-> 0 from left) = 0 + 0i.
>>>
>>> We try to do what is right for IEEE floating point.  Maybe sqrt should
>>> be fixed.
>>>
>>> There are a number of other problems with the way we (and every other
>>> language that I know of) handle complex numbers.  For example, since
>>> we don't have pure imaginary values, I think things like i/0 or i*Inf
>>> fail to do the right thing.
>>
>>
>> octave:2> i/0
>> warning: division by zero
>> ans = NaN - NaNi
>> octave:3> i*Inf
>> ans = NaN + Infi
>>
>> That is a bit messy, isn't it?  As a slight fix for consistency, I'd think
>> these two should match, i.e., i/0 = NaN + Infi.
>
> Should "Infi" be allowable syntax?  Otherwise the only way of creating 0 +
> Infi is
>
> octave:16> complex(0,Inf)
> ans =    0 + Infi
>
> Here's a bug:
>
> octave:18> complex(0,Inf) - Inf
> ans = -Inf + Infi
> octave:23> complex(0,-Inf) + Inf
> ans = Inf - Infi
>
> That should be -Inf + NaNi, I'd think.

Why?

> Same sort of thing here:
>
> octave:28> complex(0,-Inf) / 0
> warning: division by zero
> ans = NaN - NaNi
>
> should be NaN - Infi.
>

Not really. The reason is that the zero is converted to complex zero
prior to the division, i.e. there is no actual complex/real operation
implemented in Octave. An implementation using the direct algorithm
would, of course, be superior.

>
> Perhaps there should be some test functions that come along with the
> function "complex", once we figure out (i.e., guess or arbitrarily assign)
> what the answer should actually be.
>
> Dan
>



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