octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] Re: [bug #32053] matlab/Octave differences for comp


From: Jaroslav Hajek
Subject: [Octave-bug-tracker] Re: [bug #32053] matlab/Octave differences for complex
Date: Tue, 11 Jan 2011 11:29:33 +0100

On Mon, Jan 10, 2011 at 2:23 AM, Michael Godfrey
<address@hidden> wrote:
>
> Follow-up Comment #8, bug #32053 (project octave):
>
> Jaroslav wrote:
> But making the whole matter even more complex by introducing some rules about
> which expressions are narrowed and which aren't sounds definitely like a bad
> idea to me.
> ============================================
>
> I cannot follow this.  There are rules already: they are what
> the code does.  And, as they are now, they are definitely
> confusing, at least to me.  I have not found anyone who says
> "I would expect some elements of a complex-valued array to be
> other than complex."
>

But the current rules are very simple: if a complex result of a
complex expression happens to be real, it is automatically narrowed to
a real type. The one exception, is explicit complex result from
complex().
Indexing in Octave is nothing more than an expression. It can be
chained, it can be overloaded, it can be applied to a temporary. In
other languages (e.g. C), indexing may be something more distinct; in
Octave it just isn't. Even the syntax is the same as function call.
"I would expect some elements of a complex-valued array to be other
than complex." Yes, so what? The elements are complex. But if you
index the array, the result may be simplified. This is either useful
or at least harmless in 99.99% cases. There could be an extra function
for the remaining 0.01%.



reply via email to

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