My wish list for an improved 50g  Hewlett Packard
This is a discussion on My wish list for an improved 50g  Hewlett Packard ; Hardware

1. Large ENTER key, just like in the older models (and the HP35s).
2. Tactile keys like those on the HP35s with the same key shape.
Software

1. Digit separators in Standard display mode (like the HP35s).
...

My wish list for an improved 50g
Hardware

1. Large ENTER key, just like in the older models (and the HP35s).
2. Tactile keys like those on the HP35s with the same key shape.
Software

1. Digit separators in Standard display mode (like the HP35s).
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 HP20b keys? Why
did HP take a step backward when they are capable of producing a
decent keypad like the one on the HP35s? 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 ,
John Nguyen wrote:
> Hardware
> 
> 1. Large ENTER key, just like in the older models (and the HP35s).
> 2. Tactile keys like those on the HP35s with the same key shape.
>
> Software
> 
> 1. Digit separators in Standard display mode (like the HP35s).
> 2. A B>I function (yes, I can use B>R and then R>I, but why not
> just combine them).
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
\>>
\>>
>
> 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 HP20b keys? Why
> did HP take a step backward when they are capable of producing a
> decent keypad like the one on the HP35s? 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
"Virgil" wrote in message
news:VirgilB9E348.01433021082008@comcast.dca.giganews.com...
> In article ,
> John Nguyen wrote:
X
> 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
> \>>
> \>>
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, "VeliPekka Nousiainen"
wrote:
> "Virgil" wrote in message
>
> news:VirgilB9E348.01433021082008@comcast.dca.giganews.com...
>
> > In article ,
> > John Nguyen wrote:
> X
> > 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.
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
VeliPekka Nousiainen kirjutas:
> "Virgil" wrote in message
> news:VirgilB9E348.01433021082008@comcast.dca.giganews.com...
>> In article ,
>> John Nguyen wrote:
> X
>> 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
>> \>>
>> \>>
> 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
>
>
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 wrote:
> In article ,
> John Nguyen wrote:
>
> > Hardware
> > 
> > 1. Large ENTER key, just like in the older models (and the HP35s).
> > 2. Tactile keys like those on the HP35s with the same key shape.
> >
> > Software
> > 
> > 1. Digit separators in Standard display mode (like the HP35s).
> > 2. A B>I function (yes, I can use B>R and then R>I, but why not
> > just combine them).
>
> 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
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:
> Digit separators in Standard display mode (like the HP35s).
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 recompile,
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.
> a B>I function (yes, I can use B>R and then R>I
> but why not just combine them)
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 simplerlooking 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^641) output, indicating no "range" errors.
"Exact mode" must be set before compiling the above; otherwise
18446744073709551615 will be misinterpreted as a "real" number.
> Why is HP having so much issues
> with fundamentals like keys on a calculator?
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:
> How about string processing?
> B\>I
> \<< PUSH DEC \>STR 3. OVER SIZE 1.  SUB OBJ\> POP \>>
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)
> I\>B
> \<< "# " SWAP + "d" + OBJ\> \>>
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