Threaded Mode | Linear Mode

Gilles · 12-08-2014, 12:15 PM

Exact mode :

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

Returns 0. (false)
expected is 1. (true)

Gerald H · (This post was last modified: 12-08-2014 12:50 PM by Gerald H.)

Confirmed. Version 2.10-7

The command "SAME" similarly buggy.

Gerald H · 12-08-2014, 12:57 PM

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..

Gilles · (This post was last modified: 12-08-2014 01:58 PM by Gilles.)

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 } ==

gives the correct answer

Gerald H · 12-08-2014, 02:18 PM

(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 } ==

gives the correct answer

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.

Gilles · (This post was last modified: 12-08-2014 06:26 PM by Gilles.)

(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.

Han · 12-08-2014, 06:42 PM

(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.

Gerald H · 12-09-2014, 11:31 AM

(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?

Han · (This post was last modified: 12-09-2014 06:41 PM by Han.)

(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.

John R. Graham · 12-12-2014, 03:47 PM

(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_
}
@

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

Gerald H · (This post was last modified: 12-12-2014 04:02 PM by Gerald H.)

(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_
}
@
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

I would suggest discounting the likelihood of a bug.

Try decomposing the list entered via the input line & one produced by the MOD calculation.

John R. Graham · 12-12-2014, 04:06 PM

(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

Han · 12-12-2014, 04:11 PM

(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.

Gerald H · 12-12-2014, 04:13 PM

(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.

Gerald H · 12-12-2014, 04:32 PM

(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.

John R. Graham · 12-12-2014, 04:52 PM

(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

Han · 12-12-2014, 04:58 PM

(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.

Claudio L. · 12-12-2014, 06:01 PM

(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

toml_12953 · (This post was last modified: 12-12-2014 06:51 PM by toml_12953.)

(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

Gerald H · 12-12-2014, 07:51 PM

(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.