HP50G bug ?
12-08-2014, 12:15 PM
Post: #1
 Gilles Member Posts: 165 Joined: Oct 2014
HP50G bug ?
Exact mode :

{ 1 2 3 4 5 } 2 MOD
{ 1 0 1 0 1 } ==

Returns 0. (false)
expected is 1. (true)
12-08-2014, 12:41 PM (This post was last modified: 12-08-2014 12:50 PM by Gerald H.)
Post: #2
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
Confirmed. Version 2.10-7

The command "SAME" similarly buggy.
12-08-2014, 12:57 PM
Post: #3
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
Fortunately for Version 1.19-6 on the 49G

{ 1 2 3 4 5 } 2 MOD -> { 1. 0. 1. 0. 1. }

which is visibly different from { 1 0 1 0 1 }.

== still returns 0..
12-08-2014, 01:31 PM (This post was last modified: 12-08-2014 01:58 PM by Gilles.)
Post: #4
 Gilles Member Posts: 165 Joined: Oct 2014
RE: HP50G bug ?
On my 50G exact mode

{1 2 3 4 5} 2 MOD

gives

{1 0 1 0 1}

1 <<TYPE>> DOSUBS

gives

{ 28. 28. 28. 28. 28.}

All seems OK but it is not ...

{ 1 2 3 4 5 } 2 MOD R->I
{ 1 0 1 0 1 } ==

12-08-2014, 02:18 PM
Post: #5
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
(12-08-2014 01:31 PM)Gilles Wrote:  On my 50G exact mode

{1 2 3 4 5} 2 MOD

gives

{1 0 1 0 1}

1 <<TYPE>> DOSUBS

gives

{ 28. 28. 28. 28. 28.}

All seems OK but it is not ...

{ 1 2 3 4 5 } 2 MOD R->I
{ 1 0 1 0 1 } ==

If you want to know WHY the two lists, produced in two different ways, give different results, apply the command ->S2 to each of the lists & you should see a difference in the two resultant strings.
12-08-2014, 06:25 PM (This post was last modified: 12-08-2014 06:26 PM by Gilles.)
Post: #6
 Gilles Member Posts: 165 Joined: Oct 2014
RE: HP50G bug ?
(12-08-2014 02:18 PM)Gerald H Wrote:  If you want to know WHY the two lists, produced in two different ways, give different results, apply the command ->S2 to each of the lists & you should see a difference in the two resultant strings.

Both returns :

Code:
!NO CODE !RPL {   ZINT 1   ZINT 0   ZINT 1 } @

(Version 2.09)
Looks like a very strange bug...

Code:
 { 1 2 3 4 5 } 2 MOD { 1 0 1 0 1 } == returns 0. { 1 2 3 4 5 } 2 MOD ->S2 { 1 0 1 0 1 } ->S2 == returns 1.
12-08-2014, 06:42 PM
Post: #7
 Han Senior Member Posts: 1,820 Joined: Dec 2013
RE: HP50G bug ?
(12-08-2014 06:25 PM)Gilles Wrote:
(12-08-2014 02:18 PM)Gerald H Wrote:  If you want to know WHY the two lists, produced in two different ways, give different results, apply the command ->S2 to each of the lists & you should see a difference in the two resultant strings.

Both returns :

Code:
!NO CODE !RPL {   ZINT 1   ZINT 0   ZINT 1 } @

(Version 2.09)
Looks like a very strange bug...

Code:
 { 1 2 3 4 5 } 2 MOD { 1 0 1 0 1 } == returns 0. { 1 2 3 4 5 } 2 MOD ->S2 { 1 0 1 0 1 } ->S2 == returns 1.

I am running 2.15 and { 1 0 1 0 1 } ->S2 produces
!NO CODE
!RPL
{
Z1_
Z0_
Z1_
Z0_
Z1_
}
@

Basically, the MOD function returns an actual ZINT object as the result whereas the command line parser will parse 0 as the built-in integer 0 whose address is defined as Z0_. I'm not sure why ->S2 on version 2.09 doesn't produce different source code...

This is also confirmed using Jazz for the 50G.

Graph 3D | QPI | SolveSys
12-09-2014, 11:31 AM
Post: #8
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
(12-08-2014 06:42 PM)Han Wrote:
(12-08-2014 06:25 PM)Gilles Wrote:  Both returns :

Code:
!NO CODE !RPL {   ZINT 1   ZINT 0   ZINT 1 } @

(Version 2.09)
Looks like a very strange bug...

Code:
 { 1 2 3 4 5 } 2 MOD { 1 0 1 0 1 } == returns 0. { 1 2 3 4 5 } 2 MOD ->S2 { 1 0 1 0 1 } ->S2 == returns 1.

I am running 2.15 and { 1 0 1 0 1 } ->S2 produces
!NO CODE
!RPL
{
Z1_
Z0_
Z1_
Z0_
Z1_
}
@

Basically, the MOD function returns an actual ZINT object as the result whereas the command line parser will parse 0 as the built-in integer 0 whose address is defined as Z0_. I'm not sure why ->S2 on version 2.09 doesn't produce different source code...

This is also confirmed using Jazz for the 50G.

Very good, we now know WHY this bug crops up, it's indisputably a bug, accordingly HP will shortly produce a rectified OS for the 50G.

What about the poor 49G users, left abandoned in a bug-warp, doomed to ingenious work-arounds?
12-09-2014, 06:40 PM (This post was last modified: 12-09-2014 06:41 PM by Han.)
Post: #9
 Han Senior Member Posts: 1,820 Joined: Dec 2013
RE: HP50G bug ?
(12-09-2014 11:31 AM)Gerald H Wrote:  Very good, we now know WHY this bug crops up, it's indisputably a bug, accordingly HP will shortly produce a rectified OS for the 50G.

What about the poor 49G users, left abandoned in a bug-warp, doomed to ingenious work-arounds?

Yes, pretty much. At least there are workarounds, though not always. (In this particular case, a DOLIST can be used.)

Sadly, this is the case of pretty much all calculators (including HP) that are no longer in production. Likewise for abandoned software. An exception, however, is that the HP50G is still being sold... so why they don't make bug-fixes is beyond me:

Bugs for the HP50G and related family

HP 42S COMB bug (bad one) also explained here (though mistyped as COMP)

HP 48 Bugs (scroll to bottom)

I don't know about the HP 42S, but I do recall HP having an exchange program for the HP48 at one point.

Graph 3D | QPI | SolveSys
12-12-2014, 03:47 PM
Post: #10
 John R. Graham Member Posts: 76 Joined: Dec 2013
RE: HP50G bug ?
(12-08-2014 06:42 PM)Han Wrote:  I am running 2.15 and { 1 0 1 0 1 } ->S2 produces
!NO CODE
!RPL
{
Z1_
Z0_
Z1_
Z0_
Z1_
}
@
Code:
{ 1 0 1 0 1 } ->S2
produces
Code:
!NO CODE !RPL {   ZINT 1   ZINT 0   ZINT 1   ZINT 0   ZINT 1 } @
which is different from what you're seeing. Nevertheless, the comparison fails for me, too.

- John
12-12-2014, 04:00 PM (This post was last modified: 12-12-2014 04:02 PM by Gerald H.)
Post: #11
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
(12-12-2014 03:47 PM)John R. Graham Wrote:
(12-08-2014 06:42 PM)Han Wrote:  I am running 2.15 and { 1 0 1 0 1 } ->S2 produces
!NO CODE
!RPL
{
Z1_
Z0_
Z1_
Z0_
Z1_
}
@
Code:
{ 1 0 1 0 1 } ->S2
produces
Code:
!NO CODE !RPL {   ZINT 1   ZINT 0   ZINT 1   ZINT 0   ZINT 1 } @
which is different from what you're seeing. Nevertheless, the comparison fails for me, too.

- John

I would suggest discounting the likelihood of a bug.

Try decomposing the list entered via the input line & one produced by the MOD calculation.
12-12-2014, 04:06 PM
Post: #12
 John R. Graham Member Posts: 76 Joined: Dec 2013
RE: HP50G bug ?
(12-12-2014 04:00 PM)Gerald H Wrote:  I would suggest discounting the likelihood of a bug.
...
I guess I don't understand what you're saying here. You're the one that confirmed the bug. Decomposing the two lists result in identical stack contents for both.

- John
12-12-2014, 04:11 PM
Post: #13
 Han Senior Member Posts: 1,820 Joined: Dec 2013
RE: HP50G bug ?
(12-12-2014 03:47 PM)John R. Graham Wrote:  There's something really strange about this bug. I'm also running #2.15 but
Code:
{ 1 0 1 0 1 } ->S2
produces
Code:
!NO CODE !RPL {   ZINT 1   ZINT 0   ZINT 1   ZINT 0   ZINT 1 } @
which is different from what you're seeing. Nevertheless, the comparison fails for me, too.

- John

This is just a hunch (don't have my 50G here with me), but my guess would be that you do not have the extable library installed. This library basically gives names to entry points. Without it, ->S2 only decompiles into generic source. Additionally, I am using a modified version of extable which includes names that are not officially supported (hence the trailing underscore). There may be flags (I don't recall off the top of my head) that affect whether or not ->S2 follows pointers or leaves them as is.

Graph 3D | QPI | SolveSys
12-12-2014, 04:13 PM
Post: #14
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
(12-12-2014 04:06 PM)John R. Graham Wrote:
(12-12-2014 04:00 PM)Gerald H Wrote:  I would suggest discounting the likelihood of a bug.
...
I guess I don't understand what you're saying here. You're the one that confirmed the bug. Decomposing the two lists result in identical stack contents for both.

- John

The bug Gilles reported is genuine & is not produced by ->S2.

Applying ->S2 to the two lists produced via two different methods will produce different results, as in Han's posting.

What I deny is a bug in ->S2 producing two identical decompositions.
12-12-2014, 04:32 PM
Post: #15
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
(12-12-2014 04:11 PM)Han Wrote:
(12-12-2014 03:47 PM)John R. Graham Wrote:  There's something really strange about this bug. I'm also running #2.15 but
Code:
{ 1 0 1 0 1 } ->S2
produces
Code:
!NO CODE !RPL {   ZINT 1   ZINT 0   ZINT 1   ZINT 0   ZINT 1 } @
which is different from what you're seeing. Nevertheless, the comparison fails for me, too.

- John

This is just a hunch (don't have my 50G here with me), but my guess would be that you do not have the extable library installed. This library basically gives names to entry points. Without it, ->S2 only decompiles into generic source. Additionally, I am using a modified version of extable which includes names that are not officially supported (hence the trailing underscore). There may be flags (I don't recall off the top of my head) that affect whether or not ->S2 follows pointers or leaves them as is.

I doubt it.

Try applying ->H to the two lists & you should see the difference.
12-12-2014, 04:52 PM
Post: #16
 John R. Graham Member Posts: 76 Joined: Dec 2013
RE: HP50G bug ?
(12-12-2014 04:13 PM)Gerald H Wrote:  Applying ->S2 to the two lists produced via two different methods will produce different results, as in Han's posting.

What I deny is a bug in ->S2 producing two identical decompositions.
Okay, I understand what you're saying, and I didn't mean to imply that there was a bug in ->S2. Nevertheless, your first statement turns out not to be the case on my 50g running the firmware version I reported. Running ->S2 on the both lists produces visually identical results.

- John
12-12-2014, 04:58 PM
Post: #17
 Han Senior Member Posts: 1,820 Joined: Dec 2013
RE: HP50G bug ?
(12-12-2014 04:32 PM)Gerald H Wrote:  I doubt it.

Try applying ->H to the two lists & you should see the difference.

Your ->H explanation only confirms what I wrote regarding ->S2 with and without extable installed.

Graph 3D | QPI | SolveSys
12-12-2014, 06:01 PM
Post: #18
 Claudio L. Senior Member Posts: 1,696 Joined: Dec 2013
RE: HP50G bug ?
(12-09-2014 11:31 AM)Gerald H Wrote:  ... accordingly HP will shortly produce a rectified OS for the 50G.

I doubt that's possible without relatively important changes to basic internal routines. The compiler, in its effort to save bytes, puts ROM pointers inside the list.

Comparison of lists is done by comparing the list object as a whole, and technically those two lists are different, even though they are displayed the same. What you want is a comparison done by using == to each element.
This is fundamentally different, so it cannot be fixed easily in ROM and I don't think it will ever be fixed.

To achieve proper list comparison you'd need to use:

Code:
 <<  << == >> DOLIST << AND >> STREAM >>

Claudio
12-12-2014, 06:47 PM (This post was last modified: 12-12-2014 06:51 PM by toml_12953.)
Post: #19
 toml_12953 Senior Member Posts: 1,455 Joined: Dec 2013
RE: HP50G bug ?
(12-09-2014 11:31 AM)Gerald H Wrote:  Very good, we now know WHY this bug crops up, it's indisputably a bug, accordingly HP will shortly produce a rectified OS for the 50G.

Are you sure about HP producing an updated OS for a discontinued product? I'd like to think so but I highly doubt it.

Tom L

Tom L
If you buy a drink for someone in order to congratulate them,
is it a Mazel Tov cocktail?
12-12-2014, 07:51 PM
Post: #20
 Gerald H Senior Member Posts: 1,448 Joined: May 2014
RE: HP50G bug ?
(12-12-2014 06:47 PM)toml_12953 Wrote:
(12-09-2014 11:31 AM)Gerald H Wrote:  Very good, we now know WHY this bug crops up, it's indisputably a bug, accordingly HP will shortly produce a rectified OS for the 50G.

Are you sure about HP producing an updated OS for a discontinued product? I'd like to think so but I highly doubt it.

Tom L

Discontinued? Still available here in Vienna.
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)