Half O.T.(Keypad Functions On Sharp)  Hewlett Packard
This is a discussion on Half O.T.(Keypad Functions On Sharp)  Hewlett Packard ; I sat,
after class,
with a cup and my stuff,
on a sunny bench.
Lay before me on my bag
was the Sharp EL506W.
First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,
the functions ...

Half O.T.(Keypad Functions On Sharp)
I sat,
after class,
with a cup and my stuff,
on a sunny bench.
Lay before me on my bag
was the Sharp EL506W.
First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,
the functions y^x, x^2, and x^3, with overlegends of
x(Root), (Sqrt), and 3rd(Root).
Um, Y^x, and x(root) would solve any values the others offer..
Why waste Space on the keypad?
Second, I noted the base functions commonly found there too;
>HEX, >BIN, >DEC, >OCT, and >PEN .
Again, Um, a function >N(base) would solve any number,
and why waste space on the keys again?
Even HP does the extra "Power Keys", and yes, the "bases" also.
Anyone know why these funcs aren't addressed more efficently?
just musing, sitting on my bench, avoiding my literature book..

Re: Half O.T.(Keypad Functions On Sharp)
On Mar 6, 11:09*am, Publicly Anonomous Use
wrote:
> First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,
> the functions y^x, x^2, and x^3, with overlegends of
> x(Root), (Sqrt), and 3rd(Root).
>
> Um, Y^x, and x(root) would solve any values the others offer..
> Why waste Space on the keypad?
>
> Second, I noted the base functions commonly found there too;
> >HEX, >BIN, >DEC, >OCT, and >PEN .
>
> Again, Um, a function >N(base) would solve any number,
> and why waste space on the keys again?
>
> Even HP does the extra "Power Keys", and yes, the "bases" also.
> Anyone know why these funcs aren't addressed more efficently?
>
> just musing, sitting on my bench, avoiding my literature book..
Probably just for convenience. The square, cube, square root, and cube
root are used more often than other powers or roots. Similarly, the
bases 2, 8, 10, and 16 are the most common (and will be as long as we
use binary computers). This can save a few keystrokes when doing
common calculations (Similarly, one can argue the redundancy of having
both common log and natural log keys).
It might also be because of public ignorance of the relationship
between the functions. Texas Instruments tried leaving everything out
except for a single "Y^X" key (represented by a carat) on the TI89
and high school students complained about the lack of an XROOT key.
They just didn't know that x^(p/q) is equal to the qth root of x^p.
S.C.

Re: Half O.T.(Keypad Functions On Sharp)
sc_usenet@hotmail.com wrote in news:8a8b1e0d71e74667b2a9727f9b7f1c91
@y77g2000hsy.googlegroups.com:
> On Mar 6, 11:09*am, Publicly Anonomous Use
> wrote:
>> First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,
>> the functions y^x, x^2, and x^3, with overlegends of
>> x(Root), (Sqrt), and 3rd(Root).
>>
>> Um, Y^x, and x(root) would solve any values the others offer..
>> Why waste Space on the keypad?
>>
>> Second, I noted the base functions commonly found there too;
>> >HEX, >BIN, >DEC, >OCT, and >PEN .
>>
>> Again, Um, a function >N(base) would solve any number,
>> and why waste space on the keys again?
>>
>> Even HP does the extra "Power Keys", and yes, the "bases" also.
>> Anyone know why these funcs aren't addressed more efficently?
>>
>> just musing, sitting on my bench, avoiding my literature book..
>
> Probably just for convenience. The square, cube, square root, and cube
> root are used more often than other powers or roots. Similarly, the
> bases 2, 8, 10, and 16 are the most common (and will be as long as we
> use binary computers). This can save a few keystrokes when doing
> common calculations (Similarly, one can argue the redundancy of having
> both common log and natural log keys).
>
> It might also be because of public ignorance of the relationship
> between the functions. Texas Instruments tried leaving everything out
> except for a single "Y^X" key (represented by a carat) on the TI89
> and high school students complained about the lack of an XROOT key.
> They just didn't know that x^(p/q) is equal to the qth root of x^p.
>
> S.C.
>
So it saves some "Rigor"...
I don't take my 48 outside much.(too rare,too curious) and
my 35s is currently behind my desk. If there were more steel in the
thing, I could retreive it with a magnet. But I'll get it back soon.
RPN just rocks, and I miss it.
The Sharp, is a fairly solid, unremarkable, inexpensive unit with some
very convienent continous memory features. It needs more CAS function.
Although, everything needs more CAS functions in my mind.

Re: Half O.T.(Keypad Functions On Sharp)
On Thu, 06 Mar 2008 18:09:47 0600, S.C. wrote:
> Texas Instruments tried leaving everything out
> except for a single "Y^X" key (represented by a carat) on the TI89
> and high school students complained about the lack of an XROOT key.
> They just didn't know that x^(p/q) is equal to the qth root of x^p.
On various Casio and HP,
"Xroot" is a bit more than just "1/X power,"
because odd integer roots of negative real values
produce negative real results,
rather than the errors (or complex results)
that "1/X power" would produce.
My Casio calcs also "fudge" many results to simulate
greater accuracy for special values (e.g. integers)
than the general functions actually have over their full range.
[ ]

Re: Half O.T.(Keypad Functions On Sharp)
On Mar 7, 6:47*pm, "John H Meyers" wrote:
> On various Casio and HP,
> "Xroot" is a bit more than just "1/X power,"
> because odd integer roots of negative real values
> produce negative real results,
> rather than the errors (or complex results)
> that "1/X power" would produce.
In Exact mode, 8 3 XROOT on the 50g automatically switches to complex
mode and returns 1+i\sqrt{3}. In approx mode however, it returns 2.
> My Casio calcs also "fudge" many results to simulate
> greater accuracy for special values (e.g. integers)
> than the general functions actually have over their full range.
>
> [ ]
You mean that the Casio "snaps" to integers; i.e. if the calculated
result is 8.99999999 it will return 9?
S.C.

Re: Half O.T.(Keypad Functions On Sharp)
On Fri, 07 Mar 2008 20:09:08 0600, S.C. wrote:
> In Exact mode, 8 3 XROOT on the 50g automatically switches to complex
> mode and returns 1+i\sqrt{3}. In approx mode however, it returns 2.
8. 3. XROOT does result in 2.
8. 3. INV ^ results, however, in (1.,1.73205080757)
On my older Casios ("real" mode), the former gives the same result,
and the latter produces an error message.
That's why XROOT is not quite the same as "reciprocal, then power"
> You mean that the Casio "snaps" to integers; i.e. if the calculated
> result is 8.99999999 it will return 9?
Sort of. For full details (re older calculators), see:
http://groups.google.com/group/comp....5b0aec9c4918c2
Even some HP calcs do the same thing:
http://groups.google.com/group/comp....464ea257f530ee
The above thread also speculates that the calculator mentioned
is actually using *binary* internal floating point,
instead of decimal floating point, which introduces further complications,
especially when it comes to "splitting hairs"
at an "exactly halfway" rounding situation
(note that dividing by 5 is absolutely exact in base 10,
but leads to an infinitely long "fractional part" in base 2,
requiring either truncation or rounding  what to do when
converting the result back to decimal?)
[r>] [OFF]

Re: Half O.T.(Keypad Functions On Sharp)
On Mar 8, 6:21*pm, "John H Meyers" wrote:
> > You mean that the Casio "snaps" to integers; i.e. if the calculated
> > result is 8.99999999 it will return 9?
>
> Sort of. *For full details (re older calculators), see:http://groups.google.com/group/comp....5b0aec9c4918c2
>
> Even some HP calcs do the same thing:http://groups.google.com/group/comp....ead/thread/e54...
>
My 12digit Casio fx260 can't decide when to round and when to
truncate in the display. It truncates whenever result<1 and rounds
otherwise. For example, when I try 2/3 on it, it displays:
0.666666666
Then I add 1 to the answer and it shows:
1.666666667
Subtracting 1 returns back to the 0.666666666 earlier.
Similarly, pi returns 3.141592654, but subtracting 3 from that leaves
0.141592653.
However, my Casio does not appear to fudge calculations. Performing 9
SIN COS TAN ATAN ACOS ASIN returns 9.000015685(47), not exactly 9. It
does appear to truncate intermediate calculations though, since pi LN
LN LN EXP EXP EXP pi  returns 5e11.
Anyway, I agree with you in that Casio makes good, inexpensive
calculations with much better keyboards than those on TI's.
S.C.

Re: Half O.T.(Keypad Functions On Sharp) [rounding by Casio vs. HP]
On Sat, 08 Mar 2008 18:26:29 0600, S.C. wrote:
> My 12digit Casio fx260 can't decide when to round and when to
> truncate in the display. It truncates whenever result<1
> and rounds otherwise.
Is that the only explanation?
> For example, when I try 2/3 on it, it displays:
>
> 0.666666666
>
> Then I add 1 to the answer and it shows:
>
> 1.666666667
>
> Subtracting 1 returns back to the 0.666666666 earlier.
>
> Similarly, pi returns 3.141592654, but subtracting 3 from that leaves
> 0.141592653
What you are expecting is "round in the display,
to the number of significant digits actually displayed"
(as the HP48/49/50 series generally does),
but it appears that your Casio first rounds an internal
12digit result to a constant 10digits,
and then displays as much of that as it can,
dropping off the last digit when "0." is prefixed as an afterthought.
Thus, 2/3 when rounded to ten mantissa digits is .6666666667
but if prefixing "0." pushes the last digit off the display,
then you would see only 0.666666666
However, 2/3 plus 1, rounded to ten digits, would display 1.666666667
pi minus 3, when rounded to ten digits, is .1415926536
but if prefixing "0." pushes the last digit off the display,
then you would see only 0.141592653
But pi itself, rounded to 10 digits, is 3.141592654
(calculators using 11digit internal mantissas
tend to use 3.1415926536 as an internal value for pi,
or 3.14159265359 for 12digit internal mantissas).
The HP48/49/50 series calculators display pi as 3.14159265359
but there is a lot more to what goes on internally,
not only because they internally calculate every numerical function
to 15 digits (with 5digit exponent) and then deliver the rounded
12digit result (with 3digit exponent) to be stored, rounding *that* again,
for display purposes only, if fewer digits are actually shown,
but also because they analyze functions a bit more deeply,
to deliver more accurate results than most common 12digit calculators.
For example, in the HP48/49/50 series, RAD 3.14159265359 SIN
results in 2.06761537357E13, adding which to the original argument
(on paper, to get the exact sum) yields
3.141592653589793238462643, which is the accurate value of pi
to 25 significant digits  any calculator which can do that
is effectively using an internal value of at least that precision for pi
(what does your Casio get?)
The thread "HP4x internal digi accuracy" (March 2124,2007)
suggests that doing the above in SysRPL produces pi to 31 digits,
and other cases illustrating more careful and thorough numerical workmanship:
http://groups.google.com/group/comp....a6ddfb49e34eb/
[r>] [OFF]

Re: Half O.T.(Keypad Functions On Sharp) [Casio behaviors]
On Sat, 08 Mar 2008 18:26:29 0600, S.C. wrote:
> my [12digit] Casio does not appear to fudge calculations. Performing
> 9 SIN COS TAN ATAN ACOS ASIN returns 9.000015685(47), not exactly 9.
> It does appear to truncate intermediate calculations though,
> since pi LN LN LN EXP EXP EXP pi  returns 5e11.
Take the numeric square roots of many nonsquare real integers (e.g. 7),
then square those, and compare with the same on HP48/49/50;
do the same with taking reciprocals twice (e.g. 7 INV INV).
If the Casio gets more "exact" results than HP (also 12digit calc),
then it is either keeping results of more than 12 mantissa digits
or it is artifically improving the results.
Calculators using 80bit binary floating point can be more accurate,
since 2^80 exceeds 10^24 (effectively nearly 24digit decimal precision,
if done properly); even 64bit mantissas represent 19digit precision,
56bit mantissas represent 16digit precision, Etc.  "overkill"
in mantissa size can give unsophisticated algorithms a wider berth,
after rounding, like cosmetic makeup, hides some of their flaws.
[r>] [OFF]

Re: Half O.T.(Keypad Functions On Sharp) [rounding by Casio vs. HP]
On Mar 9, 2:41*am, "John H Meyers" wrote:
> For example, in the HP48/49/50 series, RAD 3.14159265359 SIN
> results in 2.06761537357E13, adding which to the original argument
> (on paper, to get the exact sum) yields
> 3.141592653589793238462643, which is the accurate value of pi
> to 25 significant digits  any calculator which can do that
> is effectively using an internal value of at least that precision for pi
> (what does your Casio get?)
>
My Casio stores pi to 11 digits, so consequently RAD 3.141592653 SIN
returns 6e10. (it's one of those old oneline scientifics, so it runs
in pseudoRPN mode with a 2level stack)
Anyway, this is much better than the cheap TI scientifics that return
garbage. The TI30Xa stores pi to 12 digits (3.14159265359), but RAD
3.141592653 SIN returns 5.93411945678e10, of which only the first
digit is correct and the second is rounded. It's better to get no
digits than to get wrong digits.
S.C.

Re: Half O.T.(Keypad Functions On Sharp) [Casio behaviors]
On Mar 9, 3:16*am, "John H Meyers" wrote:
> On Sat, 08 Mar 2008 18:26:29 0600, S.C. wrote:
> > my [12digit] Casio does not appear to fudge calculations. Performing
> > 9 SIN COS TAN ATAN ACOS ASIN returns 9.000015685(47), not exactly 9.
> > It does appear to truncate intermediate calculations though,
> > since pi LN LN LN EXP EXP EXP pi  returns 5e11.
>
> Take the numeric square roots of many nonsquare real integers (e.g. 7),
> then square those, and compare with the same on HP48/49/50;
> do the same with taking reciprocals twice (e.g. 7 INV INV).
>
> If the Casio gets more "exact" results than HP (also 12digit calc),
> then it is either keeping results of more than 12 mantissa digits
> or it is artifically improving the results.
>
> Calculators using 80bit binary floating point can be more accurate,
> since 2^80 exceeds 10^24 (effectively nearly 24digit decimal precision,
> if done properly); even 64bit mantissas represent 19digit precision,
> 56bit mantissas represent 16digit precision, Etc.  "overkill"
> in mantissa size can give unsophisticated algorithms a wider berth,
> after rounding, like cosmetic makeup, hides some of their flaws.
>
> [r>] [OFF]
The LongFloat library on hpcalc.org seems to have good algorithms even
at high precision. For example, running the 9 SIN COS TAN ATAN ACOS
ASIN operation with 25 digits results in 9.000000000000000000249569,
showing that no "fudging" is going on.
The library also uses Chudnovsky to calculate pi to as many digits as
you would like, since storing pi to arbitrary precision would be a
waste of memory.
S.C.