From: Virgil on
In article
<a3ea4d6e-d39c-45ae-970d-aaafdd753728(a)z26g2000yqm.googlegroups.com>,
HM <hans.milton(a)telia.com> wrote:

> On 11 Feb, 00:20, "hgab...(a)xmission.com" <hgab...(a)xmission.com> wrote:
> >
> > I don't think you understand. �Please read again what I posted. �Try
> > graphing 'RE(V(X))', V being the square root symbol. �What do you get
> > for X<0? �Undefined? �That's what's wrong.
> >
> > This has nothing to do with arrays, by the way.
>
> Graphing this program in RPN mode works OK:
>
> << X 0.5 ^ RE >>

Just another reason to avoid using algebraic mode.
From: HM on
On 11 Feb, 10:54, Virgil <Vir...(a)home.esc> wrote:
>
> Just another reason to avoid using algebraic mode.

Well, it turns out that, as long as the function is
in the form of a program, it can be graphed also
with the calc in algebraic mode.
Algebraic mode version, where V is the radical symbol:

<< RE( V(X) ) >>

From: Dave Hayden on
On Feb 11, 7:16 am, HM <hans.mil...(a)telia.com> wrote:
> On 11 Feb, 10:54, Virgil <Vir...(a)home.esc> wrote:
>
>
>
> > Just another reason to avoid using algebraic mode.
>
> Well, it turns out that, as long as the function is
> in the form of a program, it can be graphed also
> with the calc in algebraic mode.
> Algebraic mode version, where V is the radical symbol:
>
> << RE( V(X) ) >>

Looking at the root of the original problem, I think hgabert really
has found a bug. In RPN mode with calculator set to "exact" and
"complex" enter "1 +/- SQRT IM" The result is 0 which is clearly
wrong. You get the same thing with Real/exact. If approximate mode
is on, you get the right answer.

Sure you could press EVAL before IM and get the right answer, but that
just works around the erroneous result. The calculator should either
evaluate the expression correctly and return 1, or it should leave it
as a symbolic IM(SQRT(-1))
From: hgabert on
On Feb 11, 6:18 am, Dave Hayden <d...(a)larou.com> wrote:
> On Feb 11, 7:16 am, HM <hans.mil...(a)telia.com> wrote:
>
> > On 11 Feb, 10:54, Virgil <Vir...(a)home.esc> wrote:
>
> > > Just another reason to avoid using algebraic mode.
>
> > Well, it turns out that, as long as the function is
> > in the form of a program, it can be graphed also
> > with the calc in algebraic mode.
> > Algebraic mode version, where V is the radical symbol:
>
> > << RE( V(X) ) >>
>
> Looking at the root of the original problem, I think hgabert really
> has found a bug.  In RPN mode with calculator set to "exact" and
> "complex" enter "1 +/- SQRT IM"  The result is 0 which is clearly
> wrong.  You get the same thing with Real/exact.  If approximate mode
> is on, you get the right answer.
>
> Sure you could press EVAL before IM and get the right answer, but that
> just works around the erroneous result.  The calculator should either
> evaluate the expression correctly and return 1, or it should leave it
> as a symbolic IM(SQRT(-1))

Yes, this is exactly the problem.

'RE(sqrt(X))' EVAL returns sqrt(X), clearly wrong for X<0

'IM(sqrt(X)' EVAL returns 0, clearly wrong for X<0.

What to do? This appears to be a glitch in the CAS. I hope the
"powers that be" can fix it in a future ROM update.

From: HM on
On Feb 11, 4:29 pm, "hgab...(a)xmission.com" <hgab...(a)xmission.com>
wrote:

>
> What to do?  This appears to be a glitch in the CAS.  I hope the
> "powers that be" can fix it in a future ROM update.- Hide quoted text -
>
> - Show quoted text -

Whith all respect, does a bug or glitch really exist?
To decompose a complex number into its real and
imaginary components (assuming RPN mode):

1. Input: 3+SQRT(-5)
2. On stack: 3+SQRT(-1)*SQRT(5)
3. EVAL
4. On stack: 3+i*SQRT(5)
5. ENTER (to duplicate)
6. RE: 3 on stack
7. SWAP
8. IM: SQRT(5) on stack

Rather exact!

Regards
Hans