49G/49G+/50G BUG - Tagged object in negative form - Hewlett Packard

This is a discussion on 49G/49G+/50G BUG - Tagged object in negative form - Hewlett Packard ; Hi, I found a 49G/49G+/50G bug : :a:1 -> a '-a' EVAL >> >> "EVAL Error: Insufficient memory" A tagged object can't be valuated inside algebraic object in its negative form. It works well in the 48G/GX. -d@nt3. Lima/Peru...

+ Reply to Thread
Results 1 to 5 of 5

Thread: 49G/49G+/50G BUG - Tagged object in negative form

  1. 49G/49G+/50G BUG - Tagged object in negative form

    Hi,

    I found a 49G/49G+/50G bug :

    <<
    :a:1
    -> a
    <<
    '-a' EVAL
    >>
    >>


    "EVAL Error: Insufficient memory"

    A tagged object can't be valuated inside algebraic object in its
    negative form.

    It works well in the 48G/GX.

    -d@nt3.
    Lima/Peru


  2. Re: 49G/49G+/50G BUG - Tagged object in negative form

    On Tue, 01 Apr 2008 12:58:06 -0500:

    > found a 49G/49G+/50G bug :


    > \<< :a:1 \-> a \<< '-a' EVAL \>> \>>"EVAL Error: Insufficient memory"
    >
    > A tagged object can't be evaluated inside algebraic object
    > in its negative form.


    > It works well in the 48G/GX.


    It works if you change EVAL to \->NUM or first set flag -3,
    or if you insert \->LST just before EVAL, which replaces
    CASCOMPEVAL with COMPEVAL (more like the original HP48).

    [r->] [OFF]

  3. Re: 49G/49G+/50G BUG - Tagged object in negative form

    deachp@yahoo.es wrote:
    > Hi,
    >
    > I found a 49G/49G+/50G bug :
    >
    > <<
    > :a:1
    > -> a
    > <<
    > '-a' EVAL
    >>>

    >
    > "EVAL Error: Insufficient memory"
    >
    > A tagged object can't be valuated inside algebraic object in its
    > negative form.


    Works for me on Emu.50G. My program is:

    << :a:1 -> a << '-a' EVAL >> >>

    My flags are { #204010FF4h #0h #8010000002000000h #0h }, ROM version
    HP50-C revision #2.09 and I created the minus sign of -a by entering
    minus rather than +/- and deleted the spaces that the editor puts in.

    There is nothing else much in memory so I'm not sure why you get the
    result that you do. Could you post your flag settings, please, and ROM
    version.

    Purely conjecture but I wonder if your version is somehow confusing the
    'a' of the tag with the 'a' of the local variable. Try changing the tag
    to 'b' (or some letter that is not an existing variable) and see what
    you get.

    Finally, if you do:

    << :a:1 -> a << 'a' EVAL >> >>

    then you get :a:1 back and this is interesting because it seems that
    local variables can store tagged objects whereas globals can't. If you
    store :a:1 into 'X' (where X is a global) then 'X' RCL gives 1 and the
    tag is lost.

    Regards,
    --
    Bruce Horrocks
    Surrey
    England
    (bruce at scorecrow dot com)

  4. Re: 49G/49G+/50G BUG - Tagged object in negative form

    On Thu, 03 Apr 2008 05:49:17 -0500, Bruce Horrocks wrote:

    > Works for me on Emu50G


    > My flags are { #204010FF4h #0h #8010000002000000h #0h }


    That includes flag -3 ("numeric results") being set,
    which bypasses the problem, as previously noted.

    > if you do: \<< :a:1 \-> a \<< 'a' EVAL \>> \>>
    > then you get :a:1 back and this is interesting
    > because it seems that local variables can store tagged objects
    > whereas globals can't. If you store :a:1 into 'X' (where X is a global)
    > then 'X' RCL gives 1 and the tag is lost.


    Yes, that's interesting.

    Maybe that's what catches CASCOMPEVAL by surprise, but it shouldn't
    (after all, COMPEVAL handles it fine, on both HP48 and HP49/50).

    [r->] [OFF]

  5. Re: 49G/49G+/50G BUG - Tagged object in negative form

    John H Meyers wrote:
    > On Thu, 03 Apr 2008 05:49:17 -0500, Bruce Horrocks wrote:
    >
    >> Works for me on Emu50G

    >
    >> My flags are { #204010FF4h #0h #8010000002000000h #0h }

    >
    > That includes flag -3 ("numeric results") being set,
    > which bypasses the problem, as previously noted.


    Doh! Sorry, I'd forgotten that I'd changed that. I must use the calc
    more often. :-(

    Okay, so now I've reproduced the bug, I've tried swapping the 'a' tag
    with 'b' and it makes no difference so that blows that theory out of the
    water.

    Regards,
    --
    Bruce Horrocks
    Surrey
    England
    (bruce at scorecrow dot com)

+ Reply to Thread