My wish list for an improved 50g

Hardware

--------

1. Large ENTER key, just like in the older models (and the HP-35s).

2. Tactile keys like those on the HP-35s with the same key shape.

Software

--------

1. Digit separators in Standard display mode (like the HP-35s).

2. A B->I function (yes, I can use B->R and then R->I, but why not

just combine them).

The software should be relatively easy to implement. I won't hold

my breath for the hardware changes, but it would be nice.

On another note, what is the deal with the mushy HP-20b keys? Why

did HP take a step backward when they are capable of producing a

decent keypad like the one on the HP-35s? Why is HP having so much

issues with fundamentals like keys on a calculator?

Thanks for reading.

John

Re: My wish list for an improved 50g

In article <Pk7rk.14047$De7.11495@bignews7.bellsouth.net>,

John Nguyen <jdn502REMOVE@MEbellsouth.net> wrote:

[color=blue]

> Hardware

> --------

> 1. Large ENTER key, just like in the older models (and the HP-35s).

> 2. Tactile keys like those on the HP-35s with the same key shape.

>

> Software

> --------

> 1. Digit separators in Standard display mode (like the HP-35s).

> 2. A B->I function (yes, I can use B->R and then R->I, but why not

> just combine them).[/color]

Actually there are binaries that would have to convert to integers of

more than 12 significant decimal digits, so they get rounded off to 12

significant digits by the B->R command. Like the binary for 2^64 -1.

To get the full 64 bit binary numbers converted exactly to integer

format is possible on an hp49/hp50, but not by the sequence B->R R->I.

E.g., when compiled in in exact mode, this user program seems to work:

\<< 0 1 \-> x y

\<< WHILE DUP # 0h >

REPEAT

IF DUP # 1H AND # OH >

THEN 'X' Y STO+

END

'Y' 2 STO* SR

END

DROP X

\>>

\>>[color=blue]

>

> The software should be relatively easy to implement. I won't hold

> my breath for the hardware changes, but it would be nice.

>

> On another note, what is the deal with the mushy HP-20b keys? Why

> did HP take a step backward when they are capable of producing a

> decent keypad like the one on the HP-35s? Why is HP having so much

> issues with fundamentals like keys on a calculator?

>

> Thanks for reading.

>

> John[/color]

Re: My wish list for an improved 50g

"Virgil" <Virgil@gmale.com> wrote in message

news:Virgil-B9E348.01433021082008@comcast.dca.giganews.com...[color=blue]

> In article <Pk7rk.14047$De7.11495@bignews7.bellsouth.net>,

> John Nguyen <jdn502REMOVE@MEbellsouth.net> wrote:[/color]

X[color=blue]

> Actually there are binaries that would have to convert to integers of

> more than 12 significant decimal digits, so they get rounded off to 12

> significant digits by the B->R command. Like the binary for 2^64 -1.

>

> To get the full 64 bit binary numbers converted exactly to integer

> format is possible on an hp49/hp50, but not by the sequence B->R R->I.

>

> E.g., when compiled in in exact mode, this user program seems to work:

>

> \<< 0 1 \-> x y

> \<< WHILE DUP # 0h >

> REPEAT

> IF DUP # 1H AND # OH >

> THEN 'X' Y STO+

> END

> 'Y' 2 STO* SR

> END

> DROP X

> \>>

> \>>[/color]

X

slight modifications:

\<< \-> b @ use as a function

\<< b 0 1 \-> x y

\<< WHILE DUP # 999999999999d >

REPEAT @ no need to loop smaller

IF DUP # 1h AND # 0h > @ corrected OH

THEN 'x' y STO+

END

'y' y STO+ SR @ + faster than *

END

B\->R R\->I y * x +

\>> b DROP @ save LASTARG

\>> @

\>> @ note small letters usage

Re: My wish list for an improved 50g

On Aug 21, 1:00*pm, "Veli-Pekka Nousiainen"

<velipekka.nousiai...@saunalahti.fi> wrote:[color=blue]

> "Virgil" <Vir...@gmale.com> wrote in message

>

> news:Virgil-B9E348.01433021082008@comcast.dca.giganews.com...

>[color=green]

> > In article <Pk7rk.14047$De7.11...@bignews7.bellsouth.net>,

> > John Nguyen <jdn502REM...@MEbellsouth.net> wrote:[/color]

> X[color=green]

> > Actually there are binaries that would have to convert to integers of

> > more than 12 significant decimal digits, so they get rounded off to 12

> > significant digits by the B->R command. Like the binary for 2^64 -1.[/color]

>[color=green]

> > To get the full 64 bit binary numbers converted exactly to integer

> > format is possible on an hp49/hp50, but not by the sequence B->R R->I.[/color][/color]

How about string processing?

B\->I

\<< PUSH DEC \->STR 3. OVER SIZE 1. - SUB OBJ\-> POP \>>

I\->B

\<< "# " SWAP + "d" + OBJ\-> \>>

-wes

Re: My wish list for an improved 50g

Veli-Pekka Nousiainen kirjutas:[color=blue]

> "Virgil" <Virgil@gmale.com> wrote in message

> news:Virgil-B9E348.01433021082008@comcast.dca.giganews.com...[color=green]

>> In article <Pk7rk.14047$De7.11495@bignews7.bellsouth.net>,

>> John Nguyen <jdn502REMOVE@MEbellsouth.net> wrote:[/color]

> X[color=green]

>> Actually there are binaries that would have to convert to integers of

>> more than 12 significant decimal digits, so they get rounded off to 12

>> significant digits by the B->R command. Like the binary for 2^64 -1.

>>

>> To get the full 64 bit binary numbers converted exactly to integer

>> format is possible on an hp49/hp50, but not by the sequence B->R R->I.

>>

>> E.g., when compiled in in exact mode, this user program seems to work:

>>

>> \<< 0 1 \-> x y

>> \<< WHILE DUP # 0h >

>> REPEAT

>> IF DUP # 1H AND # OH >

>> THEN 'X' Y STO+

>> END

>> 'Y' 2 STO* SR

>> END

>> DROP X

>> \>>

>> \>>[/color]

> X

> slight modifications:

> \<< \-> b @ use as a function

> \<< b 0 1 \-> x y

> \<< WHILE DUP # 999999999999d >

> REPEAT @ no need to loop smaller

> IF DUP # 1h AND # 0h > @ corrected OH

> THEN 'x' y STO+

> END

> 'y' y STO+ SR @ + faster than *

> END

> B\->R R\->I y * x +

> \>> b DROP @ save LASTARG

> \>> @

> \>> @ note small letters usage

>

>[/color]

The first one is 148.5 bytes and over 1s with #FFFFFFFFFFFFFFFh, the

other one 191 bytes and 400ms with the same input.

What about:

\<< \-> n

\<< RCLF DEC -105 CF

n \->STR DUP SIZE 1 - 3 SWAP SUB STR\->

SWAP STOF

\>>

\>>

68.5 bytes and 60ms with the same input as above.

Results are different, because first two programs assume user binary

integers to be signed I assume :)

Best wishes,

Robert Tiismus

Re: My wish list for an improved 50g

In article <Virgil-B9E348.01433021082008@comcast.dca.giganews.com>,

Virgil <Virgil@gmale.com> wrote:

[color=blue]

> In article <Pk7rk.14047$De7.11495@bignews7.bellsouth.net>,

> John Nguyen <jdn502REMOVE@MEbellsouth.net> wrote:

>[color=green]

> > Hardware

> > --------

> > 1. Large ENTER key, just like in the older models (and the HP-35s).

> > 2. Tactile keys like those on the HP-35s with the same key shape.

> >

> > Software

> > --------

> > 1. Digit separators in Standard display mode (like the HP-35s).

> > 2. A B->I function (yes, I can use B->R and then R->I, but why not

> > just combine them).[/color]

>

> Actually there are binaries that would have to convert to integers of

> more than 12 significant decimal digits, so they get rounded off to 12

> significant digits by the B->R command. Like the binary for 2^64 -1.

>

> To get the full 64 bit binary numbers converted exactly to integer

> format is possible on an hp49/hp50, but not by the sequence B->R R->I.

>

> E.g., when compiled in in exact mode, this user program seems to work:

>

> \<< 0 1 \-> x y

> \<< WHILE DUP # 0h >

> REPEAT

> IF DUP # 1H AND # OH >

> THEN 'X' Y STO+

> END

> 'Y' 2 STO* SR

> END

> DROP X[/color]

A much better program is (again compiled in exact mode)

\<<

4294967296 @ equals 2^32

DUP2 / B\->I OVER *

UNROT 1 - R\->B AND

B\->R R\->I +

\>>

Note that 4294967296 can actually be any integer between 2^32 and

10^12 inclusive.

Re: My wish list for an improved 50g

On Thu, 21 Aug 2008 00:52:51 -0500, John Nguyen wrote:

[color=blue]

> Digit separators in Standard display mode (like the HP-35s).[/color]

It would have to done, however, without affecting \->STR

(currently both the STD mode stack display and \->STR

share one common decompiler function);

otherwise \->STR would produce strings

which STR\-> could not re-compile,

which might "break" lots of existing software.

Doing the above also expands the maximum length

of the display string by three characters:

"-8,888,888,888.88"

In some other calculators, each display digit

includes the annunciators for "." and ","

so that no string expansion is required to show decimals

and separators, but note that in the HP48/49/50 series,

every character occupies its own position.

You could easily create your own function, however,

for displaying numbers exactly as you desire

(just remove trailing zeros from normal FIX mode display);

in the HP49/50 series you can even

automatically "overlay" this display on stack level 1,

whenever there is a real number on that level.

[color=blue]

> a B->I function (yes, I can use B->R and then R->I

> but why not just combine them)[/color]

The combination of the two existing functions is not even adequate,

because the range of both "user binary" and "integer" data types

exceeds the range of uniquely representable "real" integers

(which are limited to twelve significant digits), e.g.

#123456789012345d B\->R R\->I produces 123456789012000

Therefore, B\->I and I\->B ought to have been suggested

during HP49G development or early deployment, but no one did

(I must myself have been taking a nap at the time :)

Although much simpler-looking programs than the following

can be constructed to operate on one value at a time,

the following are not only faster,

but also accommodate input lists:

\<< 8. SQ STWS DUP B\->R R\->I DUP R\->B ROT - 8. ALOG

SWAP OVER R\->B ADD B\->R SWAP - R\->I - \>> 'B\->I' STO

\<< 8. SQ STWS 0 MAX 18446744073709551615 MIN DUP R\->B DUP B\->R

R\->I ROT - I\->R 8. ALOG SWAP OVER ADD SWAP R\->B - - \>> 'I\->B' STO

Notes:

These don't restore any smaller original "binary word size"

(which is "good form" to do, but can also make results look wrong).

In keeping with R\->B, I\->B has the same minimum (zero)

and maximum (2^64-1) output, indicating no "range" errors.

"Exact mode" must be set before compiling the above; otherwise

18446744073709551615 will be misinterpreted as a "real" number.

[color=blue]

> Why is HP having so much issues

> with fundamentals like keys on a calculator?[/color]

These are fundamentally difficult times :)

"Back to basics," I say

(but not "Back to BASIC" :)

[r->] [OFF]

Re: My wish list for an improved 50g

On Thu, 21 Aug 2008 10:14:06 -0500, Wes wrote:

[color=blue]

> How about string processing?[/color]

[color=blue]

> B\->I

> \<< PUSH DEC \->STR 3. OVER SIZE 1. - SUB OBJ\-> POP \>>[/color]

You must also make sure to get into "Exact" mode before OBJ\->

or else the result will be a "real" type,

which might not even represent exactly the same value

(although it would be the same as produced by I\->R)

[color=blue]

> I\->B

> \<< "# " SWAP + "d" + OBJ\-> \>>[/color]

Watch out for inputs which are either too large or negative.

The above methods employ the internal compiler,

which is often slower than using just calculation.

Avoidance of using the internal compiler is in fact

why perfectly valid numeric "port tags" (e.g. :2.0:X STO)

which would have worked fine in the HP48S[X]/G[X] series

do not work in the HP49/50 series -- the earlier series

first compiled any port tag and checked for a real result,

while the later series, concerned about execution time

even for relatively infrequent port operations,

recognizes only :2:X and :2.:X

(this can "break" some programs when in FIX or SCI display mode,

for example).

Even :2.:X was originally not recognized in early HP49G ROMs,

but the necessity of allowing this was eventually conceded :)

[r->] [OFF]

Re: My wish list for an improved 50g

I wish HP or BP can make an HP49/50 ROM that could work with

delimiters (thousands, millions, etc) when working WITH UNITS. Now

its just impossible, when you set any kind of unit the commas are

cleared.

Daniel