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 EL-506W.

First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,

the functions y^x, x^2, and x^3, with over-legends 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

<Public_Email@No_Public_Email.254> wrote:[color=blue]

> First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,

> the functions y^x, x^2, and x^3, with over-legends 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..[/color]

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 TI-89

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 q-th root of x^p.

S.C.

Re: Half O.T.(Keypad Functions On Sharp)

[email]sc_usenet@hotmail.com[/email] wrote in news:8a8b1e0d-71e7-4667-b2a9-727f9b7f1c91

@y77g2000hsy.googlegroups.com:

[color=blue]

> On Mar 6, 11:09*am, Publicly Anonomous Use

> <Public_Email@No_Public_Email.254> wrote:[color=green]

>> First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,

>> the functions y^x, x^2, and x^3, with over-legends 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..[/color]

>

> 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 TI-89

> 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 q-th root of x^p.

>

> S.C.

>[/color]

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:

[color=blue]

> Texas Instruments tried leaving everything out

> except for a single "Y^X" key (represented by a carat) on the TI-89

> 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 q-th root of x^p.[/color]

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" <jhmey...@nomail.invalid> wrote:[color=blue]

> 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.[/color]

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.

[color=blue]

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

>

> -[ ]-[/color]

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:

[color=blue]

> 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.[/color]

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

[color=blue]

> You mean that the Casio "snaps" to integers; i.e. if the calculated

> result is 8.99999999 it will return 9?[/color]

Sort of. For full details (re older calculators), see:

[url]http://groups.google.com/group/comp.sys.hp48/msg/1f5b0aec9c4918c2[/url]

Even some HP calcs do the same thing:

[url]http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/e5464ea257f530ee[/url]

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" <jhmey...@nomail.invalid> wrote:[color=blue][color=green]

> > You mean that the Casio "snaps" to integers; i.e. if the calculated

> > result is 8.99999999 it will return 9?[/color]

>

> Sort of. *For full details (re older calculators), see:[url]http://groups.google.com/group/comp.sys.hp48/msg/1f5b0aec9c4918c2[/url]

>

> Even some HP calcs do the same thing:[url]http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/e54[/url]...

>[/color]

My 12-digit Casio fx-260 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 -5e-11.

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:

[color=blue]

> My 12-digit Casio fx-260 can't decide when to round and when to

> truncate in the display. It truncates whenever |result|<1

> and rounds otherwise.[/color]

Is that the only explanation?

[color=blue]

> 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[/color]

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

12-digit result to a constant 10-digits,

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 11-digit internal mantissas

tend to use 3.1415926536 as an internal value for pi,

or 3.14159265359 for 12-digit 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 5-digit exponent) and then deliver the rounded

12-digit result (with 3-digit 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 12-digit calculators.

For example, in the HP48/49/50 series, RAD 3.14159265359 SIN

results in -2.06761537357E-13, 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 21-24,2007)

suggests that doing the above in SysRPL produces pi to 31 digits,

and other cases illustrating more careful and thorough numerical workmanship:

[url]http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/16ea6ddfb49e34eb/[/url]

[r->] [OFF]

Re: Half O.T.(Keypad Functions On Sharp) [Casio behaviors]

On Sat, 08 Mar 2008 18:26:29 -0600, S.C. wrote:

[color=blue]

> my [12-digit] 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 -5e-11.[/color]

Take the numeric square roots of many non-square 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 12-digit calc),

then it is either keeping results of more than 12 mantissa digits

or it is artifically improving the results.

Calculators using 80-bit binary floating point can be more accurate,

since 2^80 exceeds 10^24 (effectively nearly 24-digit decimal precision,

if done properly); even 64-bit mantissas represent 19-digit precision,

56-bit mantissas represent 16-digit precision, Etc. -- "overkill"

in mantissa size can give unsophisticated algorithms a wider berth,

after rounding, like cosmetic make-up, 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" <jhmey...@nomail.invalid> wrote:[color=blue]

> For example, in the HP48/49/50 series, RAD 3.14159265359 SIN

> results in -2.06761537357E-13, 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?)

>[/color]

My Casio stores pi to 11 digits, so consequently RAD 3.141592653 SIN

returns 6e-10. (it's one of those old one-line scientifics, so it runs

in pseudo-RPN mode with a 2-level stack)

Anyway, this is much better than the cheap TI scientifics that return

garbage. The TI-30Xa stores pi to 12 digits (3.14159265359), but RAD

3.141592653 SIN returns 5.93411945678e-10, 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" <jhmey...@nomail.invalid> wrote:[color=blue]

> On Sat, 08 Mar 2008 18:26:29 -0600, S.C. wrote:[color=green]

> > my [12-digit] 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 -5e-11.[/color]

>

> Take the numeric square roots of many non-square 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 12-digit calc),

> then it is either keeping results of more than 12 mantissa digits

> or it is artifically improving the results.

>

> Calculators using 80-bit binary floating point can be more accurate,

> since 2^80 exceeds 10^24 (effectively nearly 24-digit decimal precision,

> if done properly); even 64-bit mantissas represent 19-digit precision,

> 56-bit mantissas represent 16-digit precision, Etc. -- "overkill"

> in mantissa size can give unsophisticated algorithms a wider berth,

> after rounding, like cosmetic make-up, hides some of their flaws.

>

> [r->] [OFF][/color]

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.