Questions if the HP49G is *not* real
Zak Smith
The question in my mind is this: given that the perpetrators of this
joke are HP48 users, fanatics, etc - *why* would they do this given
that it can only hurt HP & HP calculators? The overwhelming response
in this newsgroup so far has been disgust, which might push people to
give up on future HP calcs altogether.
[0] I might be proven wrong by an announcement on hp.com, but I doubt
it. Here's why:
a. the "Alleged HP49" (AHP49)'s LCD is flush with the top of the
unit, *unlike* all other handheld HP products I know of
(including the Logic Dart)
b. in http://bofh.via.ecp.fr/~sam/openhp/006.jpg, it looks like
one has the "old-style" HP48 LCD and one has the "new-style" HP48
LCD (ie, one is more black, and one is more blue). Supposedly
on the HP48 they changed for a reason, why try both in the new
one?
c. Why would it use the same LCD as the one engineered 10 years
ago? Hello?
d. In every HP-designed calculator, the numeric keys have had the
same position relative to the basic operation keys (+-/*). This
is not the case on the AHP49. (eg, / is not next to 9).
e. Having left-shifted functions (ie, blue) on the Fn keys
conflicts with the ability to have left-shifted commands in the
CST menu.
f. In 1990, it was reasonable to design new Si for a calculator -
perhaps the right low-power CPU didn't exist. There's *no*
reason for this now, there are lots of low-power, fast, CPUs
available.
g. In http://bofh.via.ecp.fr/~sam/openhp/009.jpg, it appears as
if the bottom half of the case's top corners are not as rounded
as the top half of the case's top corners (ie, by the top of the
LCD). Why are these pictures so fuzzy - I can take better with a
$7 disposable Kodak.
h. in http://home.nordnet.fr/~bdarcy/mag/hp49.jpg, it appears as
if in the HP logo, the "tail of the p" angles too sharply, ie, it
goes too "left".
-z
--
# Zak Smith, MScEE, Unix Geek, INTJ. z...@computer.org http://apollo.demigod.org
# Ft Collins, CO. More laws are *not* the answer.
Freedom
>
>[0] I might be proven wrong by an announcement on hp.com, but I doubt
>it. Here's why:
You will be, more than likely.
>
> a. the "Alleged HP49" (AHP49)'s LCD is flush with the top of the
> unit, *unlike* all other handheld HP products I know of
> (including the Logic Dart)
I am not seeing this.
>
> b. in http://bofh.via.ecp.fr/~sam/openhp/006.jpg, it looks like
> one has the "old-style" HP48 LCD and one has the "new-style" HP48
> LCD (ie, one is more black, and one is more blue). Supposedly
> on the HP48 they changed for a reason, why try both in the new
> one?
This has already been explained.
> c. Why would it use the same LCD as the one engineered 10 years
> ago? Hello?
Again, see a previous post.
> d. In every HP-designed calculator, the numeric keys have had the
> same position relative to the basic operation keys (+-/*). This
> is not the case on the AHP49. (eg, / is not next to 9).
Obviously they changed some things!
> e. Having left-shifted functions (ie, blue) on the Fn keys
> conflicts with the ability to have left-shifted commands in the
> CST menu.
They may have changed the menu you are referring to.
> f. In 1990, it was reasonable to design new Si for a calculator -
> perhaps the right low-power CPU didn't exist. There's *no*
> reason for this now, there are lots of low-power, fast, CPUs
> available.
HP's mistake.
>
> g. In http://bofh.via.ecp.fr/~sam/openhp/009.jpg, it appears as
> if the bottom half of the case's top corners are not as rounded
> as the top half of the case's top corners (ie, by the top of the
> LCD). Why are these pictures so fuzzy - I can take better with a
> $7 disposable Kodak.
Give me a break! You can't tell that nor your next comment from a
picture! The person who took the pictures is not a professional
photographer, and the lighting conditions were not perfect.
>
> h. in http://home.nordnet.fr/~bdarcy/mag/hp49.jpg, it appears as
> if in the HP logo, the "tail of the p" angles too sharply, ie, it
> goes too "left".
That's just nit-picking.
Samuel Hocevar
>At this point in time, I am convinced that the HP49G is a hoax[0].
>
>The question in my mind is this: given that the perpetrators of this
>joke are HP48 users, fanatics, etc - *why* would they do this given
>that it can only hurt HP & HP calculators?
Then perhaps it's not a hoax...
>[0] I might be proven wrong by an announcement on hp.com, but I doubt
>it. Here's why:
>
> a. the "Alleged HP49" (AHP49)'s LCD is flush with the top of the
> unit, *unlike* all other handheld HP products I know of
> (including the Logic Dart)
True.
> b. in http://bofh.via.ecp.fr/~sam/openhp/006.jpg, it looks like
> one has the "old-style" HP48 LCD and one has the "new-style" HP48
> LCD (ie, one is more black, and one is more blue). Supposedly
> on the HP48 they changed for a reason, why try both in the new
> one?
The one on the left was a quite older prototype. The one on the right
has the new, more contrasted display. I took this picture to show the
difference between the two LCDs (I didn't have my 48gx within reach).
> c. Why would it use the same LCD as the one engineered 10 years
> ago? Hello?
Well it actually uses a newer one (see b.). And are you aware the G
series already had an improved screen over the S ?
> d. In every HP-designed calculator, the numeric keys have had the
> same position relative to the basic operation keys (+-/*). This
> is not the case on the AHP49. (eg, / is not next to 9).
Yes. This kinda sucks for people used to HP's product. But for
those used to other calculators and who would like to buy a new,
more powerful one, this will be less disturbing.
I guess the new mapping was a compromise between RPL and Standard modes.
> e. Having left-shifted functions (ie, blue) on the Fn keys
> conflicts with the ability to have left-shifted commands in the
> CST menu.
I tried it, and actually those blue labels on top of the Fn keys
only work in plot mode (a reminder for when the menu disappears).
> f. In 1990, it was reasonable to design new Si for a calculator -
> perhaps the right low-power CPU didn't exist. There's *no*
> reason for this now, there are lots of low-power, fast, CPUs
> available.
Agreed. But HP's calculators department was closed for a few years.
Developping a rom doesn't take one week.
> g. In http://bofh.via.ecp.fr/~sam/openhp/009.jpg, it appears as
> if the bottom half of the case's top corners are not as rounded
> as the top half of the case's top corners (ie, by the top of the
> LCD).
This is a light effect because of the flash. The top and the bottom
actually don't have the same color and reflexiveness (sp?), thus
the apparent difference.
> Why are these pictures so fuzzy - I can take better with a
> $7 disposable Kodak.
Will you buy me a better digital camera then ? :)
I agree the light is pretty crap, and I forgot to put macro mode
on. Sorry for that. Perhaps people currently beta-testing the beast
have the time to take better pictures ?
> h. in http://home.nordnet.fr/~bdarcy/mag/hp49.jpg, it appears as
> if in the HP logo, the "tail of the p" angles too sharply, ie, it
> goes too "left".
Oh gosh. Didn't see that. Then, it's definitely a fake.
Sam.
--
:wq!
Keith Farmer
> [0] I might be proven wrong by an announcement on hp.com, but I doubt
> a. the "Alleged HP49" (AHP49)'s LCD is flush with the top of the
http://bofh.via.ecp.fr/~sam/openhp/014.jpg
The LCD isn't flush -- there's a shadow. on the right hand side.
> b. in http://bofh.via.ecp.fr/~sam/openhp/006.jpg, it looks like
Fro a development model, I would expect this. My father once purchased
by pieces an Atari 1450 XLD (remember that?). The case was a
re-engineered case from a 1200. I wouldn't blink to see variance in the
parts, purely for demonstration purposes.
> c. Why would it use the same LCD as the one engineered 10 years
*THAT* is a good question. Look at the space shuttle's computer systems.
> d. In every HP-designed calculator, the numeric keys have had the
Very un-aesthetic, by my standards. It's just Evil and Wrong. I would
really dislike HP for doing something like this.
> e. Having left-shifted functions (ie, blue) on the Fn keys
Perhaps. You're assuming the same functionality in any CST menu.
> g. In http://bofh.via.ecp.fr/~sam/openhp/009.jpg, it appears as
Irrelevent. Form does not determine existance.
Considering this whole style is uncharacteristic of HP, we can't use odd
style in a particular area to say it's not for real.
> h. in http://home.nordnet.fr/~bdarcy/mag/hp49.jpg, it appears as
Ref my response to (g)
Zak Smith
>> c. Why would it use the same LCD as the one engineered 10 years
>
>*THAT* is a good question. Look at the space shuttle's computer systems.
Uhh. I hope the S.S. example isn't supposed to be relevant, because it's not.
>> e. Having left-shifted functions (ie, blue) on the Fn keys
>
>Perhaps. You're assuming the same functionality in any CST menu.
Yes, I was assuming user-level code would work just the same.
Zak Smith
imply that the HP49G is a hoax, just that the combination of all of
them convince me it's a hoax, until further information comes out (eg,
hp.com).
On 21 May 1999 23:20:38 GMT, Samuel Hocevar <s...@via.ecp.fr> wrote:
>> c. Why would it use the same LCD as the one engineered 10 years
>> ago? Hello?
>
>Well it actually uses a newer one (see b.). And are you aware the G
>series already had an improved screen over the S ?
Yes, that's what I was referring to and why I can't believe they'd
use the *same one* as the 48G.
>> f. In 1990, it was reasonable to design new Si for a calculator -
>> perhaps the right low-power CPU didn't exist. There's *no*
>> reason for this now, there are lots of low-power, fast, CPUs
>> available.
>
>Agreed. But HP's calculators department was closed for a few years.
>Developping a rom doesn't take one week.
I didn't *say that*. Even for "micro-architectual" changes (eg, 48S
-> 48G), I'm sure the code/ROM must be re-worked to some extent.
Given the low performance (and probable large die size) for the
Saturn, and the desire to leapfrog competing technology, why not use
one of the new high-power embdedded processors?
>Oh gosh. Didn't see that. Then, it's definitely a fake.
See my comment at the top.
Keith Farmer
Zak Smith wrote:
> Uhh. I hope the S.S. example isn't supposed to be relevant, because it's not.
Actually, it is. 70's tech in an 80's release. Scary, I know.
Jemfinch02
an established user base and desert its current market in order to chase a
market *dominated* by another calculator company? Anyone here knows that HP
stands no chance of even putting a dent in TI's control of the educational
market. HP would know this too. So why would HP chase this market around?
A bird in the hand is better than two in the bush, and HP knows this. I do not
think they would make such a bad business decision.
And, continue to notice that there has been no OFFICIAL word from HP or it's
representatitives in this NG (regardless of the fact that they don't speak for
HP when they post here :-))
I want proof. Put an AHP49 in my hand or have HP tell me itself that it is
true.
Jeremy
------------------------------------
If i ever forget to capitalize a proper noun, forgive me. i have ee cummings
in my ancestry.
My ICQ # is 28153190. My AIM/AOL name is either jemfinch02 or Cassius80.
Have a good day, and good luck in your endeavors!
Barry Marks
> same to me.
Not to me. The logo of the supposed 49G has the upright on the h at a
different angle than the tail of the p. On a real HP logo they're parallel.
I have to agree that this isn't proof of anything. The pictures aren't
clear. They seem clear enough to show this but we can't be completely sure.
Also, HP might have modified the logo. Not likely but possible.
Barry
Tony Peterson
for the Air Force. I still use HP products today that are 20+ years old, and HP has
never departed drastically from its appearance, feel, or functionality except for
improvements. For Hewlett-Packard to make such a large departure from the hugely
successful HP48G/GX would require a complete change of management. Their track
record says so. Has anyone checked their business statistics lately? Is their stock
plummeting, requiring big changes in their competitiveness, or are they holding
steady? How big of an impact would the debut of an inferior calculator have on the
company? Just how smart is HP? My experience with them for the last 22 years is
that HP is extremely capable of producing top-of-the-line communications
electronics products, some products with possibly no rival (maybe the HP48 too?).
I've also known of HP's customer loyalty and their desire to uphold the reliability
of their products. Most of the fears I've read here so far do not follow along with
HP's history. In today's world markets, many things can upset the balance of a
company forcing them to change drastically and even fold up. I think that HP is
still rock solid. I can't prove it, but I speak knowing of their ties with the
technical world. The military seems to be still "in tight" with HP because of all
the support contracts for the HP electronics they own. No, that does not address
calculators, but do we think that HP is suffering? Do they need to put out a
competitive calculator that few of us loyal HP48 users would buy? Do they care
about reputation? Is it important to them? I really think that we should give HP a
little more credit. Besides, the pictures I saw look like someone just edited a KML
file to make it look like whatever they wanted. This is a lot easier to believe
than what some are thinking.
Zak Smith wrote:
> At this point in time, I am convinced that the HP49G is a hoax[0].
>
> The question in my mind is this: given that the perpetrators of this
> joke are HP48 users, fanatics, etc - *why* would they do this given
> that it can only hurt HP & HP calculators? The overwhelming response
> in this newsgroup so far has been disgust, which might push people to
> give up on future HP calcs altogether.
>
> [0] I might be proven wrong by an announcement on hp.com, but I doubt
> it. Here's why:
>
> a. the "Alleged HP49" (AHP49)'s LCD is flush with the top of the
> unit, *unlike* all other handheld HP products I know of
> (including the Logic Dart)
>
> b. in http://bofh.via.ecp.fr/~sam/openhp/006.jpg, it looks like
> one has the "old-style" HP48 LCD and one has the "new-style" HP48
> LCD (ie, one is more black, and one is more blue). Supposedly
> on the HP48 they changed for a reason, why try both in the new
> one?
>
> c. Why would it use the same LCD as the one engineered 10 years
> ago? Hello?
>
> d. In every HP-designed calculator, the numeric keys have had the
> same position relative to the basic operation keys (+-/*). This
> is not the case on the AHP49. (eg, / is not next to 9).
>
> e. Having left-shifted functions (ie, blue) on the Fn keys
> conflicts with the ability to have left-shifted commands in the
> CST menu.
>
> f. In 1990, it was reasonable to design new Si for a calculator -
> perhaps the right low-power CPU didn't exist. There's *no*
> reason for this now, there are lots of low-power, fast, CPUs
> available.
>
> g. In http://bofh.via.ecp.fr/~sam/openhp/009.jpg, it appears as
> if the bottom half of the case's top corners are not as rounded
> as the top half of the case's top corners (ie, by the top of the
> LCD). Why are these pictures so fuzzy - I can take better with a
> $7 disposable Kodak.
>
> h. in http://home.nordnet.fr/~bdarcy/mag/hp49.jpg, it appears as
> if in the HP logo, the "tail of the p" angles too sharply, ie, it
> goes too "left".
>
g...@my-dejanews.com
If this is a hoax then it must be the most elaborate one I have ever
seen. I think most of the post hear are just upset, its not what they
were looking for. Like one of the post said, HP is looking for a
different market, more education, and less professionals. By the way,
what is wrong with the old 48G and GX?
Thanks Gary
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Zak Smith
Fine. The Space Shuttle has requirements that the HP48 does not:
. Verification/certification of systems must be rigorous enough
to ensure system will not fail - it is mission-critical
. must interact with other systems in a 3/5-redundant system
(if I remember correctly).
. must be rad-hard
. I'm sure there is lots of red-tape involved in upgrading
those systems
Consumer systems don't have these requirements. Would you be
satisfied if you had to use a PC with a 286 with 640x480 16-color VGA?
Of course not.
TinyWanda
> if in the HP logo, the "tail of the p" angles too sharply, ie, it
> goes too "left".
---------------------------:: o
on the contrary, it's a major confirmation that the 49 is a fake, so that the
hoaxers could claim--in their own minds, not in a court of law--that the logo
was not a real Hewlett Packard logo...
----------- :: o
.---..-..-..-..-..-..-. . .-. .-. .-..-..-.. .-.
`| |'| || .` | > / \ \/ \/ / / \ | .` || | ) / \
`-' `-'`-'`-' `-' `. ^ .' `--^--'`-'`-'`-'' `--^--'
The Essence Of Life Is Being Aware That We Are Robots.
TinyWanda
pictures so fuzzy - I can take better with a $7 disposable Kodak.
it would appear from the 'inpromptu' 'photographs' of the 49 that they were:
a) 49 was computer generated with 3D software
b) collaged to real photographs
c) 'fuzzied' to conceal pasting flaws
it also seems that the 49 has the same screen resolution to make it easier to
paste 48 images to the 49...
Freedom
wrote:
>on the contrary, it's a major confirmation that the 49 is a fake
Did you compare it with the HP logo from www.hp.com? It looks the same
to me.
Giles Todd
> At this point in time, I am convinced that the HP49G is a hoax[0].
>
> The question in my mind is this: given that the perpetrators of this
> joke are HP48 users, fanatics, etc - *why* would they do this given
> that it can only hurt HP & HP calculators? The overwhelming response
> in this newsgroup so far has been disgust, which might push people to
> give up on future HP calcs altogether.
I'm about to break my promise not to comment further on this subject.
Hey ho.
If (and only if) the HP49 is a hoax then I can see a very clear
motivation for such a hoax. That being the extreme prejudice shown by
some English monolinguals against posts being made in other languages
in this newsgroup.
If this matter does turn out to be a hoax and, further, the motivation
is what I suspect it may be then the perpetrators will get lasting
applause from me. Nice one.
If I am wrong then I will look like a twit. Nothing new in that.
Giles.
--
Saxo cere comminuit brum.
Zak Smith
>If this matter does turn out to be a hoax and, further, the motivation
>is what I suspect it may be then the perpetrators will get lasting
>applause from me. Nice one.
My point was that perhaps the repercussions will have an impact outside
this apparent "us vs. them" feud, hurting HP48 enthusiasts in general --
including both sides.
Zak Smith
wrote:
> If this is a hoax then it must be the most elaborate one I have ever
>seen. I think most of the post hear are just upset, its not what they
>were looking for.
I think that's part of it, but I think there's also a lots of things
that aren't "just right" in how this whole thing has gone on that
makes us suspicious. I mean, for example, what business reason would
HP have to publicize a new product before its release? Tried and true
HP differentiators being thrown by the wayside (ex, enter key, IR,
etc)? Lack of features "expected" for so long?
If it ends up being true, then I guess lots of us will still wait,
hoping this is another "HP38" and they are still working on a new
scientific, engineering calculator.
>Like one of the post said, HP is looking for a different market, more
>education, and less professionals. By the way, what is wrong with the
>old 48G and GX?
I'm still using my SX, actually. If I could magically change my SX,
I'd probably just do the following with a wave of the magic wand:
. N times faster
. better resolution, backlight display
. M times more memory
. physically smaller & more durable, but with the same keyboard
usability
. more battery life
. more data types
. perl interpreter (*just kidding*)
The problem I have with the 48SX/GX is technological and practical
obsolescence: first, if designed now, many of my above wishes would
be fulfilled just by the technology available now, and second,
support, parts (replacements), and software will be increasingly hard
to find, besides marking the end of the focussed scientific
engineering calculator ("The market of *my needs* doesn't exist
anymore.").
Joseph K. Horn
>
> d. In every HP-designed calculator, the numeric keys have had the
> same position relative to the basic operation keys (+-/*).
No, that's not true. We oldtimers used to poke fun at HP all the
time for seemingly being unable to make up their minds about where
to put those keys. They kept switching sides and order for no
apparent reason. They finally seemed to settle on "+" being in a
bottom corner (like the old-fashioned adding machines) since the
"+" operation is used the most and bottom-corner keys are the best
place to put the most-often used keys. As such, it actually would
make sense to put ENTER there... but that's a whole 'nother topic.
If you'd like to see all the keyboard layouts for all HP calculators
ever made, check out Craig Finseth's "HP Database" at
http://www.finseth.com/~fin/hpdata.html
-Joe-
--
Joseph K. Horn - http://www.jps.net/joehorn/
John H Meyers
> In every HP-designed calculator, the numeric keys have had the
> same position relative to the basic operation keys ( + - / * )
All generalizations are false :)
See <http://www.hpmuseum.org/35first.jpg> [and several other models]
There are plausible reasons why this original HP key layout might
have been more efficient to operate than the subsequent style which
HP later bowed to, making theirs just like the rest of the industry.
If it so happens that HP once again goes with what the majority
of students and teachers have voted for with their pocketbooks,
instead of with a more enlightened appreciation of HP's earlier
most ingenious human factors design and engineering, which heard
a different drummer and marched to the music which it heard in its
own head, then it's the inevitable result of a democratic society.
If you wanted to force higher values you already appreciate upon them,
you should have put HP engineers in charge of technical education
a very long time ago, and increased school taxes to pay for it :)
I have bought several HP models (even my trusty HP48) without
even looking hard at them, so confident that they always turn out
a very fine product, even if it takes me a while to discover the
reasons behind all the fundamental design decisions that they made,
and many capabilities that I hadn't even anticipated to be available.
They have always lived up overall to that expectation and experience,
and I suspect that they will continue to do so again.
BTW, the contents of the above site (including HP manuals) are
available on two CD's, at a price comparable to what Eric asks per CD;
is anyone disturbed by the fact that the contents are all
contributed by HP, but the CD-ROMS are sold by someone else?
Well, HP evidently doesn't mind, so why should we?
-------------------------------------------------------
Establish world peace now: <http://www.kosovopeace.org>
<http://www.natural-law.org>
John H Meyers
Even years ago, I heard of such things as electronic toilets
in Japan; it's scary as heck to think that I'm still using
the same technology as my Grandmother did :)
Bruce Horrocks
>
>
> The LCD isn't flush -- there's a shadow. on the right hand side.
Look at 006.jpg as well. The reflection/glare on the screen suggests a
recessed LCD with a flush cover. Looks like they listened to all the
comments in this group over the years about how easy it is to crack the
LCD.
Regards,
--
Bruce Horrocks (...speaking for myself)
EASAMS Ltd, Waters Edge, Riverside Way (Watchmoor Park)
Camberley, Surrey GU15 3PD.
Email: Bruce.H...@gecm.com GNET: 832 3032
Tel: 01276 686777 Fax: 01276 686623
Tim Bradshaw
> For
> Hewlett-Packard to make such a large departure from the hugely
> successful HP48G/GX would require a complete change of
> management. Their track record says so. Has anyone checked their
> business statistics lately? Is their stock plummeting, requiring big
> changes in their competitiveness, or are they holding steady?
They're in the process of splitting into two companies, and the
calculator division will go with the computer/printer bit and not the
test equipment bit (which will not be called HP and has no name as far
as I know at present).
I guess that's quite a major change for the company...
> I think that HP is still rock solid. I can't prove it, but I speak
> knowing of their ties with the technical world. The military seems
> to be still "in tight" with HP because of all the support contracts
> for the HP electronics they own.
Almost all of this is for the test equipment bit I suspect -- not the
computer bit.
--tim
Monique Pulluard
John H Meyers wrote:
> I have bought several HP models (even my trusty HP48) without
> even looking hard at them, so confident that they always turn out
> a very fine product, even if it takes me a while to discover the
> reasons behind all the fundamental design decisions that they made,
> and many capabilities that I hadn't even anticipated to be available.
>
> They have always lived up overall to that expectation and experience,
> and I suspect that they will continue to do so again.
I used to do the same. I have in my drawers something labelled "HP38G". It's
supposed to be an HP calculator. I'm now convinced it was all a hoax all
along...
Bob Pulluard
(btw I posted a few replies earlier on and have just realised that they
weren't properly signed Hope this doesn't inconvenience anybody... Sorry)
Tom Lake
It's
> supposed to be an HP calculator. I'm now convinced it was all a hoax all
> along...
I've heard of people being close to their calculators but keeping one in
your drawers!?! Doesn't that make it difficult to get your pants on?
Tom Lake
ICQ #25589135
Monique Pulluard
Zak Smith wrote:
> The problem I have with the 48SX/GX is technological and practical
> obsolescence: first, if designed now, many of my above wishes would
> be fulfilled just by the technology available now, and second,
> support, parts (replacements), and software will be increasingly hard
> to find, besides marking the end of the focussed scientific
> engineering calculator ("The market of *my needs* doesn't exist
> anymore.").
About software obsolescence : there are still programs being written and published
for the HP-41C/CV/CX... today.
Bob Pulluard.
Giles Todd
> My point was that perhaps the repercussions will have an impact outside
> this apparent "us vs. them" feud, hurting HP48 enthusiasts in general --
> including both sides.
Yes, you may well be right. That's the kind of thing which happens
when apparent differences are exploited to "prove" a point. At all
levels.
Giles Todd
> Even years ago, I heard of such things as electronic toilets
> in Japan; it's scary as heck to think that I'm still using
> the same technology as my Grandmother did :)
In my favourite Chinese Restaurant in Amsterdam, there is an
electronic toilet. It is a scary beast. Wave your hands around
anywhere, even inadvertantly, and seats start going up and down, tanks
start to flush, taps run...
<*SHUDDER*>
Sometimes, old technology is best.
gts...@my-dejanews.com
Think about the 14x14 matrix Real
Time 3D plotting thingy...: that would want:
14*14=196 points:
196*6=1176 points/sec
which means , if we were to just plot the POINTS
of the graph, we would want 1176 points/sec
i don't think it can be done...
set aside we need a number of ( even integer)
multiplications.
even for *2D* rotation, we need:
(x',y')=(x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
=4 multiplications, 2 additions and if we consider that
the mults take MORE, MUCH MORE time that additions,
we need more than: 1176*6=7056 integer oerations per second
... no way, NO FUCKIN' WAY!!!
--------
:-| serious work here. no smileys.
TinyWanda
(x',y')=(x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
=4 multiplications, 2 additions and if we consider that
the mults take MORE, MUCH MORE time that additions,
we need more than: 1176*6=7056 integer oerations per second
-----------------------:: o
one would think that SIN and COS are already optimised on the 48, and they're
very slow...!
UNLESS...they're doing something 'tricky' or 'cheating' when they're rotating
the figure...
there's a do-dad for the 48 in ML that rotates a large number of points as
randomly plotted on a globe, just for nothing...and it's very fast, really real
time fast...!
so maybe it could be done...and PLUS, what do they mean by 'real time'...???
real time for a Frenchman might be pretty pokey for a actual homosapien-sapien.
Samuel Hocevar
>real time for a Frenchman might be pretty pokey for a actual
>homosapien-sapien.
Sorry, this is the last time I read your nonsense bullshit. You are
now very deep in my usenet killfile.
--
Sam.
Samuel Hocevar
gts...@my-dejanews.com <gts...@my-dejanews.com> wrote:
>Think about the 14x14 matrix Real
>Time 3D plotting thingy...: that would want:
>14*14=196 points:
>196*6=1176 points/sec
>which means , if we were to just plot the POINTS
>of the graph, we would want 1176 points/sec
>i don't think it can be done...
>set aside we need a number of ( even integer)
>multiplications.
>(x',y')=(x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
>=4 multiplications, 2 additions and if we consider that
>the mults take MORE, MUCH MORE time that additions,
>we need more than: 1176*6=7056 integer oerations per second
Do you really know how fast the Saturn works ? Seems not.
Let's say these integer operations are done with 5 nibbles precision,
which is quite enough given the screen resolution. I believe sin()
and cos() are computed using tables, thus only additions and byte
shifts are done (anyway, multiplications are done this way too), let's
see how many of them can be done.
The Saturn runs at about 4MHz, that is, 4 million cycles per second.
A 5 nibble addition is 8 cycles, a nibble shift is 8 cycles, a bit
shift is less than 15 cycles, and reading/writing 5 nibbles takes
about 20 cycles. Let's say (x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
takes 1000 cycles in the worst case (there's a way to compute y*cos(f)
and x*cos(f) at the same time to improve speed, for example).
So 1176 points are calculated in 1000*1176 cycles = 1176000 cycles.
You then have almost 3 million cycles left to plot the points, and
draw the lines. Seems quite enough to me.
--
Sam.
Aaron Wallace
On 24 May 1999, TinyWanda wrote:
> ...r *2D* rotation, we need:
> (x',y')=(x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
> =4 multiplications, 2 additions and if we consider that
> the mults take MORE, MUCH MORE time that additions,
> we need more than: 1176*6=7056 integer oerations per second
> ... no way, NO [Fawking]' WAY!!!
> -----------------------:: o
> one would think that SIN and COS are already optimised on the 48, and they're
> very slow...!
> UNLESS...they're doing something 'tricky' or 'cheating' when they're rotating
> the figure...
> there's a do-dad for the 48 in ML that rotates a large number of points as
> randomly plotted on a globe, just for nothing...and it's very fast, really real
> time fast...!
I was told a while back (by J-Y) that the HP uses the CORDIC algoithm (it
has been a while, so I hope this is accurate). I was also told that the
TI calcs (not sure about the latest models) use the CORDIC algo. I'm not
sure here, but if I remember, the major speed difference is that some trig
functions answers are _looked up_ and some calculators actually make the
calculation. The HP48 is one such calculator.
Can anyone confirm/infirm this?
--
Aaron.
Jemfinch02
>So 1176 points are calculated in 1000*1176 cycles = 1176000 cycles.
>
>You then have almost 3 million cycles left to plot the points, and
>draw the lines. Seems quite enough to me.
Yes, it seems *adequate* to me...but why not make the saturn run at 8mhz? Or
12, or 20? Imagine the speed then!
Jeremy
------------------------------------
If i ever forget to capitalize a proper noun, forgive me. i have ee cummings
in my ancestry.
My ICQ # is 28153190. My AIM/AOL name is either jemfinch02 or Cassius80.
Have a good day, and good luck in your endeavors!
TinyWanda
>homosapien-sapien.
deep in my usenet killfile.
--
---------------------------------:: o
i would like to remind everyone, and this applies not only to MY posts, but
everyones posts, and that is; Independant Verifiability.
if it sounds like BullHockey, then it might very well be BullHockey...
it it can be independeantly verified and used in a functional manner, then use
it...
but i urge everyone to read everything on the Usenet with a grain of salt
perched precaiously on the tip of your nose...(???)
and as a technical note; it's not Nonsense Bullsh*t, it's Dada Bullsh*t.
Marchel
>
> Do you really know how fast the Saturn works ? Seems not.
>
> Let's say these integer operations are done with 5 nibbles precision,
> which is quite enough given the screen resolution. I believe sin()
> and cos() are computed using tables, thus only additions and byte
> shifts are done (anyway, multiplications are done this way too), let's
> see how many of them can be done.
>
> shift is less than 15 cycles, and reading/writing 5 nibbles takes
> about 20 cycles. Let's say (x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
> takes 1000 cycles in the worst case (there's a way to compute y*cos(f)
> and x*cos(f) at the same time to improve speed, for example).
>
>
> You then have almost 3 million cycles left to plot the points, and
> draw the lines. Seems quite enough to me.
> Sam.
My God ! Motorola 68000 within that number of cycles loads,
does several multiplication of full 32 bit registers and
manages to store the outcome into the memory !!!
Jack
Cyrille de Brebisson
ok, let's have a closer analysis of this.
> Think about the 14x14 matrix Real
> Time 3D plotting thingy...: that would want:
> 14*14=196 points:
> 196*6=1176 points/sec
1176 points per second, so we have to 'manipulate' one point in 3400 machine
cycle.
per point, we must perform:
- 1 rotation (just compute the X and Y)
- Draw 2 lines. for a 14*14 matrix displayed on a 64*64 visible area,
this means drawing 2 lines of ~ 5 pixels
On this particular case, a rotation can be performed using 2
multiplications. On a SATURN cpu, a multiplication can be performed in 280
cycles. That's 560 cycles.
A 5 pixel line can be easily drawn in 1100 machine cycles. That's 2200
machine cycles for two of them.
So, we need 2760 cycles per point, for the crucial operations, let's add 700
cycles for management, loops, tests, read and write of the data ..., and we
have 3400 cycles.
After deeper analysis, it seems technicaly possible.
But again, I am only a French guy, so I can be wrong :-)
--
A+ Cyrille de Brebisson
Le Meilleur moment pour planter un arbre etait il y a 20 ans. Le Deuxieme
meilleur moment est maintenant
The Best Time to plant a tree was 20 years ago. The second best moment is
now.
http://hpmad.zoy.org
<gts...@my-dejanews.com> wrote in message
news:7ib562$l4f$1...@nnrp1.deja.com...
> reply to gts...@yahoo.com
>
> Think about the 14x14 matrix Real
> Time 3D plotting thingy...: that would want:
> 14*14=196 points:
> 196*6=1176 points/sec
> which means , if we were to just plot the POINTS
> of the graph, we would want 1176 points/sec
> i don't think it can be done...
> set aside we need a number of ( even integer)
> multiplications.
> even for *2D* rotation, we need:
> (x',y')=(x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
> =4 multiplications, 2 additions and if we consider that
> the mults take MORE, MUCH MORE time that additions,
> we need more than: 1176*6=7056 integer oerations per second
> ... no way, NO FUCKIN' WAY!!!
Samuel Hocevar
>Samuel Hocevar wrote:
>> So 1176 points are calculated in 1000*1176 cycles = 1176000 cycles.
>>
>> You then have almost 3 million cycles left to plot the points, and
>> draw the lines. Seems quite enough to me.
>
>does several multiplication of full 32 bit registers and
>manages to store the outcome into the memory !!!
I don't think you can compare two different architectures this way.
Besides, the Saturn has 64 bits registers, and I thought the M68000
was 16 bits ?
--
Sam.
gts...@my-dejanews.com
s...@via.ecp.fr wrote:
> On Mon, 24 May 1999 09:12:34 GMT,
> gts...@my-dejanews.com <gts...@my-dejanews.com> wrote:
> >Time 3D plotting thingy...: that would want:
> >14*14=196 points:
> >196*6=1176 points/sec
> >which means , if we were to just plot the POINTS
> >of the graph, we would want 1176 points/sec
> >i don't think it can be done...
> >set aside we need a number of ( even integer)
> >multiplications.
> >even for *2D* rotation, we need:
> >(x',y')=(x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
> >=4 multiplications, 2 additions and if we consider that
> >the mults take MORE, MUCH MORE time that additions,
> >we need more than: 1176*6=7056 integer oerations per second
> >... no way, NO FUCKIN' WAY!!!
>
>
> Let's say these integer operations are done with 5 nibbles precision,
> which is quite enough given the screen resolution. I believe sin()
> and cos() are computed using tables, thus only additions and byte
> shifts are done (anyway, multiplications are done this way too), let's
> see how many of them can be done.
>
> The Saturn runs at about 4MHz, that is, 4 million cycles per second.
> A 5 nibble addition is 8 cycles, a nibble shift is 8 cycles, a bit
> shift is less than 15 cycles, and reading/writing 5 nibbles takes
> about 20 cycles. Let's say (x*sin(f)+y*cos(f),x*cos(f)-y*sin(f))
> takes 1000 cycles in the worst case (there's a way to compute y*cos(f)
> and x*cos(f) at the same time to improve speed, for example).
>
>
> You then have almost 3 million cycles left to plot the points, and
> draw the lines. Seems quite enough to me.
> Sam.
>
>
( left everything in its place although you should read most of this sub
thread)
stop judging me and *think* if it is possible.
speed=3.75Mhz or ~3.9Mhz ( mine is 3.75 :(
that is 4M cycles per second , which suites you fine.
ok.
given that cos(f) & sin(f) are computed once and are constants,
we need only :
read each point's coordinates, ('a' cycles)
multiply with cos(f) & sin(f), ('b' cycles)
add the corresponding terms, ('c' cycles)
write the coordinates ( probably *not* doing perspective) ('d' cycles)
write the (14-1)*14*2=364 line segments ('e' cycles)
let's say that the CPU works only for this program( no interrupts etc)
if you can squeeze all a+b+c+d+e cycles in 1/6 of a second,
i declare you master of assembly.
especially for the line drawing thingy
but : think:
364 line segments, 6 frames/sec --> 2184 lines/sec.
the fastest line drawing algo i've experienced is
the one by detlef mueller , which might be lightning flash,
but cannot possibly do 2184 lines/sec...
if you think that they ( the ACO ) did something faster
on a machine that is not capable of 690 mults/sec, u need
something white and tight =]
maybe a trick , because for 6-7 pixel long line segments
we might not need to draw a *line*, maybe something other :/
p.s.: *anything* insulting/offending is provided for amusement ONLY
no offence is meant, and i'm sorry i used the "f" word in the
beginning.son of a bitch , i'm good!!!
Samuel Hocevar
gts...@my-dejanews.com <gts...@my-dejanews.com> wrote:
>stop judging me and *think* if it is possible.
Well.. I *saw* it, so I'm afraid I have to believe it...
>speed=3.75Mhz or ~3.9Mhz ( mine is 3.75 :(
>that is 4M cycles per second , which suites you fine.
>ok.
>given that cos(f) & sin(f) are computed once and are constants,
>we need only :
>read each point's coordinates, ('a' cycles)
>multiply with cos(f) & sin(f), ('b' cycles)
>add the corresponding terms, ('c' cycles)
>write the coordinates ( probably *not* doing perspective) ('d' cycles)
>write the (14-1)*14*2=364 line segments ('e' cycles)
I think we both agree that 'a', 'c' and 'd' are negligible. Correct
me if I'm wrong.
A rough supposition would be 1 million cycles for 'b', 2 millions
for 'e', and the remaining ones for 'a', 'c' and 'e'.
>let's say that the CPU works only for this program( no interrupts etc)
>if you can squeeze all a+b+c+d+e cycles in 1/6 of a second,
>i declare you master of assembly.
>especially for the line drawing thingy
I wished I had the time to try ...
>but : think:
>364 line segments, 6 frames/sec --> 2184 lines/sec.
>the fastest line drawing algo i've experienced is
>the one by detlef mueller , which might be lightning flash,
>but cannot possibly do 2184 lines/sec...
2184 lines in 2 millions cycles leaves 1000 cycles to draw a line.
It can be done.
>if you think that they ( the ACO ) did something faster
>on a machine that is not capable of 690 mults/sec, u need
>something white and tight =]
I'm pretty sure it can do 690 mults/sec, and much more. We don't
need 12 digits precision to draw on a 131x64 screen..
>maybe a trick , because for 6-7 pixel long line segments
>we might not need to draw a *line*, maybe something other :/
Perhaps. What's sure is that there's a way to do several multiplications
in parallel, for instance.
--
Sam.
Keith Farmer
Samuel Hocevar wrote:
>
> On Tue, 25 May 1999 07:03:47 GMT,
> gts...@my-dejanews.com <gts...@my-dejanews.com> wrote:
> >stop judging me and *think* if it is possible.
>
> Well.. I *saw* it, so I'm afraid I have to believe it...
A couple of us already tried telling him about the emulator, last night
on IRC. He refuses to believe it exists. I'm afraid this one will deny
the existance of the machine until he owns one (and even then, I suspect
he'll crack the case to look inside).
Marchel
>
> I don't think you can compare two different architectures this way.
> Besides, the Saturn has 64 bits registers, and I thought the M68000
> was 16 bits ?
Motorola has all registers (8 address and 8 data) full 32 bit.
It's arithmetic unit is 16 bit wide.
It's data but is 16 bit wide.
It's adress bus is 32 bit wide (altough model 68000 uses only 24 bits)
but the memory is flat and continuous without bank switching.
Now those are some example timings:
Multiplication of two 32 bit into two-register wide 64 bit: 74 cycles
Division of two register long 64 bit by 32 bit register: 144 cycles
Addition of two 32 bit registers: 10 cycles
Comparison of two 32 bit registers: 10 cycles
Clearing 32 bit register: 10 cycles
Negation 32 nit register: 10 cycles
Branch taken 16 bit 18 cycles
Branch not taken 16 bit 20 cycles
Jump 32 bit 16 cycles
Subroutine call 32 bit 32 cycles
Load or store 32 bit register from/to absolute address 8 cycles
Load or store 32 bit register from indexed or rel. addres 16 cycles
We are talking here about 32 bit (8 BCD digits) timing.
> --
> Sam.
Jack
Bruce Horrocks
> Yes, it seems *adequate* to me...but why not make the saturn run at 8mhz? Or
> 12, or 20? Imagine the speed then!
Yes, I'm imagining.... and now I've had to stop because the batteries
have run out.
Jean-Yves Avenard
I thought that the m68K BCD mode works only in 8 bits ????
Like the Intel x86 by the way ....
So all your values are wrong in your example..
Especially, because on the TI89/92/92+/92II they are always working in BCD,
and the Motorola is not really good for BCD calculation...
Also, there are only two instructions for BCD operations: ABCD (Add in BCD)
and SBCD (substract in BCD).
These two instructions work on a byte only, and need 10 cycles.
The Saturn CPU can work on BCD on 64 bits and need 20 cycles only for
additions, substractions etc... (6 cycles on 8bits value).
There is also a multiplication in BCD.
The Saturn CPU running at 4Mhz is MUCH faster than the Motorola 68K running
at 10MHZ on BCD operations... The Saturn has been designed for BCD
computations and there is a real BCD mode not only two instructions that can
work in BCD...
This can explain the poor performance of the TI calculators for some trivial
operations like the calculation of 300!.
The HP49G is nearly twice faster to calculate it.
Also, if it's true that it has 8 register for addresses (A0 to A7) A7 is
used as the stack pointer (SP)...
However, for anything but math. The M68K is clearly superior when correctly
used (e.g games, graphic applications :) )
Jean-Yves
Who worked more on a M68K when he had a Ataris 512ST than on the Saturn
CPU...
Marchel <mar...@eaglequest.com> wrote in message
news:374B2D71...@eaglequest.com...
dren...@mail.dotcom.fr
hpcalc.org?
http://www.hpcalc.org/pc/pictures/hp49g.jpg
rgds
John H Meyers
My boss has just decided to overclock all our CPUs,
and he expects us therefore to turn out
twice as much code per day!!!
Ossi Vaananen
z...@apollo.priv (Zak Smith) writes:
> At this point in time, I am convinced that the HP49G is a hoax[0].
> (etc etc)
well, at least the firm that is going to import those machines
to Finland already knew the price of the thing...
Fine fine, I can't wait until I get one into my hands...
=) ,
Ossi
Ossi Väänänen os...@noshit.cc.hut.fi tel 040-704 952 ham radio OH6HAY
http://hila.sgo.fi
- Hyvästi, kettu sanoi. Nyt saat salaisuuteni. Se on hyvin
yksinkertainen: Ainoastaan sydämellään näkee hyvin. Tärkeimpiä
asioita ei näe silmillä.
Antoine de Saint-Exupery: Pikku prinssi
Marchel
>
> Hummm....
>
> I thought that the m68K BCD mode works only in 8 bits ????
> Like the Intel x86 by the way ....
>
> So all your values are wrong in your example..
> Especially, because on the TI89/92/92+/92II they are always working in BCD,
> and the Motorola is not really good for BCD calculation...
You are perfectly right. That is why TI, which had choosen BCD coding
for it's floating point did that by pure insanity. On the other hand
TI integers are coded in binary, so the timing is perfectly correct
for the integers. Also screen addressing, keyboard scan, memory
managment etc. are done in binary. I'm sorry to say but only an
idiot (and TI) uses BCD for internal math unless he/she is forced by
ancient CPU.
Jack
John H Meyers
> only an idiot (and TI) [and HP!] uses BCD for internal math
> unless he/she is forced by an ancient CPU.
The Saturn could, I believe, just as well do binary FP math,
inasmuch as it switches modes at any time, via SETHEX or SETDEC
(influencing how the 64-bit registers are treated)
[multiplication is also done by subroutine rather than by FPU,
which is not too bad for a calculator].
Besides eliminating the added burden of constantly converting for
input and display, however, one reason for BCD math is to guarantee
absolute precision (of final results) when expected, whereas
doing 1/5 etc. as a binary fraction produces a little bit
of either truncation or roundoff each time.
E.g. 1E499 6 MOD gives the absolutely correct result, 4,
on any HP calc which has a MOD function; you could never get
any sensible answer at all to such a calculation using binary FP.
"There's method to his madness" - Shakespeare
-------------------------------------------------------
Establish world peace now: <http://www.kosovopeace.org>
<http://www.natural-law.org>
Consciousness-based education: <http://www.mum.edu>
Dan Dever
I have read with interest the descriptions of the HP49G
calculator, and I have some questions and suggestions to make.
I know that you might not have time to respond to the questions,
and that there must be information that you are not yet willing
to reveal, but I do hope that you take the time to read this.
I have no more knowledge of the HP49G than the picture that was
posted at http://www.hpcalc.org/hp49g.html and that which you
wrote in a couple of your posts to comp.sys.hp48, so some of my
suggestions may not be appropriate. All suggestions are made in
the hope that what may be my next calculator will be improved.
Of course, since you've used flash ROM, you can always implement
any of the software-related suggestions (should you find any
that you like) at a later date if you lack the time now.
(1) Comments on the key layout.
When the calculator is switched into RPN mode, do any of the key
definitions change? In RPN mode, I want SWAP as a primary
(non-shifted) key function whether or not there is a command
line, for example, and I wouldn't know what to do with ANS.
A suggestion: Perhaps the first function (not shifted) of
one of the keys could be to insert parentheses in algebraic
mode while serving as the SWAP key in RPN mode. The same
key shifted inserts parentheses in RPN mode and does
something else in algebraic mode (ANS?). This would correct
what I perceive as two deficiencies in the keyboard layout:
the lack of a first press SWAP function in RPN mode mode*,
and the lack of first press parentheses insertion in
algebraic mode. This SWAP/PAREN key should be near the
numeric keypad and consistent with the location of the other
keys which insert delimiters.
* Unless, of course, there already is such a key that's
simply not labeled.
I consider the lack of a first press SWAP button to be one
of the deficiencies in the HP48SX keyboard as well. I often
have a command line present when I wish to use SWAP. On the
48 my solution was to define SWAP to the DEL key, and I can
find a similar solution on the 49. However, it would be
nice to have it as a default. The CAT function seems to be
one that could be sacrificed down to a shifted function to
make room for SWAP/PAREN. If CAT is a huge alphabetical
listing of all functions, then it will presumably take many
keystrokes to navigate, what's one more? Of course, the
current location of CAT is not appropriate for SWAP/PAREN,
so this change would require some thoughtful rearrangement
of keys.
I should add that there is much that I really like about the key
layout. No, it's stronger than that. You've done a really good
job.
You have preserved six scientific functions in first press
positions -- good job! (If 1/X didn't have such a position, I
don't think I'd buy the calc.) I can't imagine going through
college with the TI-89 which has all these functions shifted
(save y^x).
I commend your courage in shrinking the ENTER key. I've long
thought that the only key (if any) that deserves to be double
sized is the + key (that's surely the most often pressed key).
I just never thought you'd actually shrink it: the public
outrage at the break in tradition was predictable. I don't like
the location, though (because it belongs to the + key). I think
shifting the operator keys down and putting ENTER above the
divide key would be preferable, except that that would isolate Z
from the other alpha keys.
You've done an outstanding job in placing the alpha keys. And
their printing on the keys is attractive.
(2) Do BASIC programs have access to the stack in RPN mode? If
not, it would be nice to have some PUSH() and POP() functions.
In algebraic mode, perhaps POP() recalls values from the ANS
variable history (is there such a history, or is ANS simply the
name of a variable that holds one value?) and PUSH() displays
its argument and stores it to ANS -- see below.
(3) What will this RPL program do if run in algebraic mode?
<< + >>
A suggestion: If the behavior of RPL programs in algebraic
mode has not already been defined in some more elegant way,
perhaps it could add the last two values of the ANS
variable, display the result and store it as the new value
of the ANS variable.
(4) Does the new calculator handle fractions? My only comment
here is that I know this is an important feature (could make or
break a buying decision) for at least one high school math
teacher that I know. I think the method used by the HP32SII for
the entry of fractions is particularly elegant; you should adopt
it if you aren't sure you can top it.
(5) List operations. It's my understanding that the 48GX has
expanded list processing over my 48SX - allowing lists to be
treated as groups of numbers by the arithmetic operators.
However, since + had been defined to perform list concatenation
on the SX, this behavior was preserved on the GX and a separate
function ADD was created to perform addition on lists. Perhaps
now is the time to make + consistent with the other list
arithmetic operators. (If user code compatibility is so
important that this cannot be done, could it be made a
configurable option?)
(6) Have you considered molding the right-shifted alpha
keyboard, RPN mode key reassignments, and/or other useful
information into the inside of the slide cover?
Make the sides of the slide cover so that they will serve well
as straight edges. Mold centimeter markings along one side and
inch markings along the other. These markings double as grips
to assist in pulling the cover off the calculator.
(7) You have claimed that "you can customize EVERYTHING" on this
calculator. Could I, for example, reverse the positions of EQW
and ' on my user keyboard? It would be useful to have this
capability. I don't know how I could assign the equation writer
to another key on my 48SX. (Although, admittedly, I haven't
looked hard since I don't use the equation writer on the SX.
It's just that I can't think of a command that invokes the
equation writer -- it just seems to be a keyboard function
only.) The same thing goes for EDIT and the matrix writer.
(8) One complaint that I have always had with the 48SX is that
STO does not work as well for number crunching as it did on my
old 15C. It works almost as well with a properly defined CST
menu, but I sometimes find myself in some other menu (such as
PROB or STAT) and then I lose the ability to store numbers with
only 2 keystrokes. With a shifted ' key, the 49G appears to be
even worse. In any case, I really miss the STO arithmetic of
the 15C (the store arithmetic functions on the 48SX are fine for
programming, but not for interactive use).
My suggestion: Provide a new STO function (I'll call it
STO15 here, but it would need a better name). When STO15 is
executed, it waits for a keypress. If a key with one of the
alpha characters A-Y is pressed, then the object in level
one of the stack (or the contents of the command line if one
is present) is stored into a variable with a single
character name corresponding to the key pressed. If a key
with one of the /, *, -, + operators is pressed, then STO15
continues to wait for another key press which must now be
one of the alpha keys A-Y and performs the appropriate store
arithmetic on the specified variable.
STO15 is to be well documented in the manual, but does not
need to be given a place on the keyboard. Those of us who
really want it can put it on our user keyboard (or custom
menu). I'd be willing to replace STO on my user keyboard
with STO15 and simply type STO for those relatively rarer
cases when I would need it.
(9) The 49G is not my dream calculator. My dream calculator is
smaller. I had hoped for a face the height and width of the
32SII with the thickness of a Palm Pilot (or just a little
thicker if needed to accommodate the buttons). Can the 49
screen and all those buttons (maybe slightly smaller) be crammed
into such a space? If the LCD is recessed it might be possible
to overlap the keyboard with the edge of the LCD connections.
It may be too late now, and maybe the cost would be prohibitive,
but I figure it can't hurt to ask. I'd love to see "pocket" be
put back into "pocket calculator."
If that's just not possible or practical, can the 49G be made
thinner? Since it lacks slots for expansion cards I would hope
for something less than 2.9 cm.
(10) On the display of numbers in scientific notation (or
engineering notation). I find this display mode difficult to
read on the 48SX. The problem is that the E blends too much
with the digits. I would greatly prefer the reduced height E
used in the 32SII and the 42S displays, which is much more
readable.
(11) I can't help but wonder what hides behind the APPS and TOOL
buttons.
One thing that I would like to see, and which could potentially
make this calculator a hit in some non-traditional markets, is a
feet and inches mode. Feet and inches, since they are not
decimal, are difficult to handle as real numbers on a
calculator. I wrote a program for my 48SX, and I have a copy of
Joe Horn's program, but neither of these is completely
satisfactory. The chief problem is one of data entry. I would
like to be able to enter feet and inches as easily as fractions
are entered on the HP32SII. For example: 10 feet, 7 and 3/4
inches could be entered as 10.7.3.4 and displayed as 10' 7-3/4".
The calculator should round the display to the nearest
appropriate fraction (1, 1/2, 1/4, 1/8, 1/16, 1/32, 1/64) with
the maximum denominator as a customizable option. On data
entry, the denominator would default to the maximum if not
explicitly specified. (So, if the maximum denominator was
specified to be 16, 10.7.3 would be interpreted as 10' 7-3/16"
and 10.7.4 would be displayed as 10' 7-1/4".) Internally, the
calculator would keep precise values (probably decimal inches,
since it would be impossible to represent 1 inch exactly in
decimal feet), there should be a function to round this value to
the displayed value (like the RND function on the HP32SII in
fraction display mode).
I'm not talking about creating unit objects here, just a method
of entering and displaying numbers.
Such a feet and inches mode would be really useful here in the
US, and I imagine in the UK as well (officially metrified or
not).
Now, I can't imagine that you'd hold up the release of this
calculator to provide a feet and inches mode, but -- with the
flash ROM -- you could provide it in a future release (perhaps
only with those calculators shipped with an English manual or a
USA warranty) and provide it for download on your website for
the owners of earlier versions.
(12) Speaking of downloadable expansion options, how about a
scheduler that synchronizes with Microsoft Outlook? I imagine
that most of the software would live on the PC side.
I am now required to keep my schedule in Outlook, which makes my
availability visible to coworkers. However, unlike the days
when I could use a small paper datebook, I no longer have my own
availability with me when I attend meetings. Many people use
PDAs to solve this problem, but PDAs have a couple of
disadvantages: good ones are expensive: generally $400-$500, and
the built-in calculators are inadequate. What I mean about the
calculators is that they are usually business-style calculators
which are less appropriate for technical work (a problem that
can be remedied through third-party software) and that
touch-screen calculators are not as pleasant to use as
calculators with buttons. Most of the people I know with PDAs
use traditional calculators when they are in their offices and
not in meetings.
Such an application might help push sales in the non-student
technical market. (Well, maybe not but I'm trying to get you to
do it!)
(13) Speaking again of downloadable expansion options, how about
the equation library (with the periodic table restored)? Most
of the work should already be done.
(14) About rubber keys. Many people have expressed concern
about their feel. My concern is about their durability. When
you say "rubber," do you mean real, latex-based rubber? It
seems to me that rubber doesn't last long. It gets brittle and
crumbly with age. It is my hope that when you say "rubber" you
mean some durable substance that happens to feel like rubber.
If not, please return to plastic.
(15) Allow me to make a plug for a really good manual.
(16) If you have read this far and given this any consideration,
I am most appreciative. I apologize for the length of this
note, but as Mark Twain put it, "I lacked the time to make it
short." And if your patience on the next topic has been
exhausted, I will understand -- you need read no further. But I
would like to raise my own objection to the color.
First of all, do not feel bad about my complaints on the color.
If I didn't want the calculator I wouldn't bother to complain
about the color.
I don't find the color tasteful. What more can I say? I don't
have the marketing expertise to give advice as to whether the
calculator's success will be helped or hindered by the color
scheme -- all I have is my own sense of aesthetics.
I do not like plastic when an attempt is made to make it look
like wood, metal, or marble. If you want a device's cover to
look metallic, use metal -- I like the looks of the Compaq Aero
2100 and of the Palm V, for example. If metal is too expensive,
then by all means use plastic, but allow it to look like
plastic. I like the looks of the plastic computer keyboard that
I am typing on. I like the looks of the plastic back to my
48SX.
It seems to me that while bright colors may attract some people,
they repel others. Just consider the number of people who have
objected to the color of the 49G; do you think anyone (even
those who would prefer the blue) would have complained about a
nice, tasteful, textured gray?
I'll conclude with one final observation. I recently signed up
for cellular phone service and purchased a cellular phone.
While going through the process, the phone company
representative told me which brand and model phone he was
offering. I looked into that model and discovered that it was
available in all sorts of bright colors. When I next spoke to
the representative, I specifically asked for a black phone. His
response was this: "Don't worry, we only carry the black model.
It's the one everyone wants."
-- Dan
Peter Karp
congratulations on your well thought suggestions :-)
I hope you don't mind me adding my thoughts here.
>(1) Comments on the key layout.
> A suggestion: Perhaps the first function (not shifted) of
> one of the keys could be to insert parentheses in algebraic
> mode while serving as the SWAP key in RPN mode.
Great idea I think. The right-arrow serves as a non-shifted SWAP in
RPN mode. I don't know it it has a meaning in algebraic mode.
> The CAT function seems to be
> one that could be sacrificed down to a shifted function to
> make room for SWAP/PAREN. If CAT is a huge alphabetical
> listing of all functions, then it will presumably take many
> keystrokes to navigate, what's one more? Of course, the
> current location of CAT is not appropriate for SWAP/PAREN,
> so this change would require some thoughtful rearrangement
> of keys.
At the moment I can't see how I will work with global vars like we
were used to on the 48. I often need the ' (tick mark) and would want
that to be a one key press function, but I'm not sure if the memory
managment (not in the filer, but for the use with the softmenu's) has
another/nicer solution on the HP49. I can't see it at the moment.
If the ' tick mark really needs to be accessed as often as on an 48 I
would prefer to have ' as a one press key. While you're right that a
CAT function will need several keypresses anyway and one additional
might be o.k. anyway.
>I should add that there is much that I really like about the key
>layout. No, it's stronger than that. You've done a really good
>job.
I also think that the keyboard is very well thought. (the free arrow
keys help to save many keystrokes while editing :-)
But it seems a little bit like the keyboard is very much improved for
newbies. This is really good in one way. But without labeling the
RightArrow-Key as SWAP I guess that very few who will be new to HP
will find out how great RPN is in daily use.
Sure it's not possible (or good!) to clutter up the keyboard with too
many words. So it's not possible to have *everything*
I also wonder why a precious one key press is used for the MODES. I
personally don't change the modes too often. For those special
settings I change very often I have asssigned tiny program *switches*
to a user key.
I miss the CST-key and I'm not sure if some of the new keys (APPS,
TOOL, SYMB) will serve for this purpose.
I consider a one keypress CST-key (or something similar) as a very
important key.
BTW, when I had my HP48 for a while and didn't knew what this needless
CST-key was for I just looked up in the manual and began to love the
CST-menus soon :-)
A very very minor note is that I think it would be natural to have
the TRIG functions on the 3-key and the matrices on the 4-key, BASE on
the 2-key, but that doesn't make a real difference.
>I commend your courage in shrinking the ENTER key.
After thinking about the new place a little bit I think we will get
used to it very soon. BTW, it's near the SPACE-key which can be nice
also.
>(4) Does the new calculator handle fractions? I think the method used by the HP32SII for
>the entry of fractions is particularly elegant; you should adopt
>it if you aren't sure you can top it.
That would defintely a plus. The HP32SII has a very clever way to
handle fractions!
[+ in lists like other commands]
this would help not to confuse newbies, but would confuse *old*
programs :-/
I think that doesn't make a real difference.
>(6) Have you considered molding the right-shifted alpha
>keyboard, RPN mode key reassignments, and/or other useful
>information into the inside of the slide cover?
>
>Make the sides of the slide cover so that they will serve well
>as straight edges. Mold centimeter markings along one side and
>inch markings along the other. These markings double as grips
>to assist in pulling the cover off the calculator.
Nice ideas :-) Do you plan to join the ACO? ;-)
>(7) You have claimed that "you can customize EVERYTHING" on this
>calculator. Could I, for example, reverse the positions of EQW
>and ' on my user keyboard? It would be useful to have this
>capability. I don't know how I could assign the equation writer
>to another key on my 48SX.
As far as I know this is only possible with the help of KEYOB or
similar programs which fetch the meaning of keys.
I'd like to add that it would be great if the OS would allow to make
mode sensitive key-assignments without the help of additional
programs.
Didn't knew that the HP15 used this way. Nice idea on a small calc,
but I personally wouldn't use this option on a calc like the HP48/49.
But if you want to have this function it shouldn't be difficult to
write a program for this, which you can assign to the STO key if you
want to.
If you don't know how to do this, just ask in the NG for help.
>(9) My dream calculator is
>smaller. I had hoped for a face the height and width of the
>32SII with the thickness of a Palm Pilot
would be nice if possible
>(11) I can't help but wonder what hides behind the APPS and TOOL
>buttons.
I'd like to know that too! As far as I have understand TOOL will serve
as a mode sensitive key and will present appropriate commands. This
could become a real time saver soon!
>(13) Speaking again of downloadable expansion options, how about
>the equation library (with the periodic table restored)? Most
>of the work should already be done.
This would be a plus. I already have wondered if the HP49 will have an
equation manager? I'm sure that many of us store really many (maybe
hundreds) of equations into the calc. There are some programs out
which help with this task, but I use none of them, as every of them
has a major disadvantage IMO.
It would be a cool application and a great help, when one could set up
a directory with all the formulas in it. This directory could have as
many subdirs as neccessary. The equations could be stored as single
objects, or if one prefers one could add a GROB, a string or other
equations (for MES).
The objects could just be collected in a single list (with no special
order) and this list could be stored in a global var.
Then one should be able to browse through the EQ's and just to take a
look on them, or to load them into the SOLVR, or to view the
accompanying text or GROB.
BTW, the library from Matt Willis (when I remember right) is almost
like this, but doesn't offer the use of subdirs :-(
Ah, I forgot to mention: J-Y told that ANS will serve as a LASTARG key
in RPN mode :-)
Have I really written such a long post after unsubscribing the news
some days ago? Blame on me ;-)
Greetings from Cologne
Peter
E-Mail: karpfe...@gmx.de
_______________________________
Do you know the great Frequently Asked Questions?
http://www.engr.uvic.ca/~aschoorl/faq/
and the superb HP48 Software Archive?
http://www.hpcalc.org
to look for *old* HP48 postings see
http://www.deja.com
John King
must have worked really hard to make it that slow.
Marchel wrote in message <374C776A...@eaglequest.com>...
>Jean-Yves Avenard wrote:
>>
>> Hummm....
>>
>> I thought that the m68K BCD mode works only in 8 bits ????
>> Like the Intel x86 by the way ....
>>
>> So all your values are wrong in your example..
>> Especially, because on the TI89/92/92+/92II they are always working in
BCD,
>> and the Motorola is not really good for BCD calculation...
>
>You are perfectly right. That is why TI, which had choosen BCD coding
>for it's floating point did that by pure insanity. On the other hand
>TI integers are coded in binary, so the timing is perfectly correct
>for the integers. Also screen addressing, keyboard scan, memory
>managment etc. are done in binary. I'm sorry to say but only an
>idiot (and TI) uses BCD for internal math unless he/she is forced by
>ancient CPU.
>
>Jack
Jean-Yves Avenard
If it's true that binary (hex use) is much faster than BCD on most of the
processor, it simply can't be used for an handled calculator..
The big advantage of BCD, is that you can get the EXACT representation of
the number your want...
If you were working in HEXA, it would be impossible when you do:
1.3 + 1.7 = 3 ... You will always get (if you don't want to lose some
accuracy) 2.999999
Simply because in a HEXA base, you can get the correct and exact
representation of 1.3
The other problem is speed of display...
On a handled device, the speed needed to display a result is (unfortunately)
more important than the time to perform the calculation...
If you need to perform everytime you want to display a number to convert it
from base 16 to base 10, then the overall impression you get when using the
calculator:
Bueahh , it's bloody slow..
The HP49 is working entirely in BCD.... To display a result it's extremely
fast... When this product will come out you will be able to compare the
speed easily..
Everytime you handle big number (and big integer) usually the TI89/92 need
the same time to compute, but the HP49 is 3 to 4 times faster to display the
result.
So you get the impression that the TI89 is slow.
I won't talk here about the implementation of the display which is even
worth, since it appears that the recalculate teh base conversion everytime
the redisplay an object...
So the stack gets slower and slower...
To conclude, I think that to use a BCD math library for a calculator can be
easily justified.... and usually needed.
Just need to pick the right CPU :)
Jean-Yves
Jean-Yves Avenard
Thank you for this extremely interesting remarks and comments... This was
very constructive by opposition to many posts I've seen here.
I will try to answer directly to you as soon as possible I promiss.
Jean-Yves
Dan Dever <de...@ad.enet.dec.com> wrote in message
news:374CF5CB...@ad.enet.dec.com...
> Jean-Yves Avenard and others at the ACO,
>
> I have read with interest the descriptions of the HP49G
> calculator, and I have some questions and suggestions to make.
> I know that you might not have time to respond to the questions,
> and that there must be information that you are not yet willing
> to reveal, but I do hope that you take the time to read this.
>
> I have no more knowledge of the HP49G than the picture that was
> posted at http://www.hpcalc.org/hp49g.html and that which you
> wrote in a couple of your posts to comp.sys.hp48, so some of my
> suggestions may not be appropriate. All suggestions are made in
> the hope that what may be my next calculator will be improved.
>
> Of course, since you've used flash ROM, you can always implement
> any of the software-related suggestions (should you find any
> that you like) at a later date if you lack the time now.
>
> (1) Comments on the key layout.
....
Marchel
>
> Jacek Marchel <mar...@eaglequest.com>:
>
> > only an idiot (and TI) [and HP!] uses BCD for internal math
> > unless he/she is forced by an ancient CPU.
>
> The Saturn could, I believe, just as well do binary FP math,
> inasmuch as it switches modes at any time, via SETHEX or SETDEC
> (influencing how the 64-bit registers are treated)
> [multiplication is also done by subroutine rather than by FPU,
> which is not too bad for a calculator].
Motorola 68000 does not have FPU either (altough 68020 and later does).
Using BCD for 64 register renders 1844 less accurate answer than using
binary for the same register.
> Besides eliminating the added burden of constantly converting for
> input and display, however, one reason for BCD math is to guarantee
> absolute precision (of final results) when expected, whereas
> doing 1/5 etc. as a binary fraction produces a little bit
> of either truncation or roundoff each time.
Not true. Only when you use exponent of power of 2 in binary floating
point (which is preferred) the accuracy is different than BCD.
There is nothing that prevents you to use exponent 10 (still coded
in binary) to actually get exactly the same accuracy (actually due
to the better coding accuracy will be much higher for the binary than
BCD). 64 bit BCD is incapable to accurately represent the following:
9999,9999,9999,9999 + 2
where binary has no problem using the same register.
> E.g. 1E499 6 MOD gives the absolutely correct result, 4,
> on any HP calc which has a MOD function; you could never get
> any sensible answer at all to such a calculation using binary FP.
>
> "There's method to his madness" - Shakespeare
>
> -------------------------------------------------------
> Establish world peace now: <http://www.kosovopeace.org>
> <http://www.natural-law.org>
> Consciousness-based education: <http://www.mum.edu>
--
+-------------------------------------------------------+
| Anna i Jacek Marchel |
| |
| e-mail: mar...@eaglequest.com |
| WWW: http://www.eaglequest.com/~marchel |
+-------------------------------------------------------+
Marchel
>
> Way off topic, but do you remember the speed of BASIC on a TI 99? Man they
> must have worked really hard to make it that slow.
There is no disagreement here. TI did really bad job with the software
and abused great CPU. But TI has potential that HP just run out of.
I'm now in the process of writting small K&R C compiler that will fit into
TI92 using all binary math for myself. That would outrun 49 in numerical
speed several times.
Jack
Marchel
>
> The big advantage of BCD, is that you can get the EXACT representation of
> the number your want...
> If you were working in HEXA, it would be impossible when you do:
> 1.3 + 1.7 = 3 ... You will always get (if you don't want to lose some
> accuracy) 2.999999
Nope. You are blinded by the traditional floating point representation
used in computers, where floating point uses exponent of power of 2
(it is preferred because of speed). There is nothing that prevent you
to use binary mantissa and binary exponent that represent power of 10.
Your exapmle would be coded as:
00001101 E 11111111 as 1.3 and 00010001 E 11111111 as 17
(aasuming one byte for mantissa and one for exponent)
Adding such would render:
00011110 E 11111111 which is exactly 3.0 no matter how coded.
Such representation is actually 1844 times more accurate for 64 bit
mantissa that 64 bit BCD coded mantissa.
Even using power of 2 as an exponent still gives four extra digits
in mantissa of accuracy and it is only a matter of using let's say
two of them to round off for display gives much better answer
(accurate more by two decimal digits) than BCD coding within the same
size register.
> Simply because in a HEXA base, you can get the correct and exact
> representation of 1.3
Not true as shown above. Mantissa: 1101 Exponent: 1111
using one nybble to represent mantissa and second nybble exponent
of power of 10.
> The other problem is speed of display...
I belive that was a factor 20 years ago :-)
Computers based on Motorola 68000 running at 7 MHz had no problems to
refresh 640 x 400 screen using 8 pixel font full of decimal floating
point numbers within several screen frames ( and that including
sending masive font bitmaps to the screen itself and running
graphical interface).
> On a handled device, the speed needed to display a result is (unfortunately)
> more important than the time to perform the calculation...
Why then HP48 stinks comparing to the speed of TI display ?
I belive, you guys fixed that with ML on 49 running BCD to the
4 times smaller screen. TI had no problems converting
200 bytes long binary coded integers into 4 times bigger screen decimal
display within "blink of an eye". Just try 200! on TI. It is binary coded.
> If you need to perform everytime you want to display a number to convert it
> from base 16 to base 10, then the overall impression you get when using the
> calculator:
> Bueahh , it's bloody slow..
No way. Just use modern CPU :-)
> The HP49 is working entirely in BCD.... To display a result it's extremely
> fast... When this product will come out you will be able to compare the
> speed easily..
> Everytime you handle big number (and big integer) usually the TI89/92 need
> the same time to compute, but the HP49 is 3 to 4 times faster to display the
> result.
> So you get the impression that the TI89 is slow.
My impression is, that actually it is HP48 that is about 60 times
slower displaying numbers on it's screen than TI, and all it is when
TI has really poor software.
> I won't talk here about the implementation of the display which is even
> worth, since it appears that the recalculate teh base conversion everytime
> the redisplay an object...
> So the stack gets slower and slower...
To display 4 lines of stack it doesn't take much ccomputing power
no matter what :-)
> To conclude, I think that to use a BCD math library for a calculator can be
> easily justified.... and usually needed.
To the contrary. Advanced calculators that are rarely used to calculate
2+2 but rather are running long complicated programs to display short
answer at the end, are actually loosing big time when done on the poor
CPU and using ineffective BCD coding. They waste CPU cycles, memory and
compromise accuracy. It is simply long usless tradition, dinosaur from
the 4004 Intel calculator CPU era :-)
> Just need to pick the right CPU :)
15-20 years old :)
> Jean-Yves
>
Jack
Russell W. Schmidt
>Jean-Yves Avenard wrote:
>>
>> To conclude, I think that to use a BCD math library for a calculator can be
>> easily justified.... and usually needed.
>
>To the contrary. Advanced calculators that are rarely used to calculate
>2+2 but rather are running long complicated programs to display short
>answer at the end, are actually loosing big time when done on the poor
>CPU and using ineffective BCD coding. They waste CPU cycles, memory and
>compromise accuracy. It is simply long usless tradition, dinosaur from
>the 4004 Intel calculator CPU era :-)
>
In the 8 1/2 years I have had my HP48SX the vast majority of calculation I
have used it for have been much closer to "2+2" than "long complicated
programs". If I have a long, complicated program I will put it on the computer
(Excel, Mathcad, or Fortran, as appropriate). The most complicated program I
use routinely is under 40 lines of user RPL, and I have probably used the
symbolic capabilities less than a half-dozen times. I use the 48 instead of
a 32SII because of the built-in units, constants, and periodic table (I have
the equation lib card in my SX); because I like the 4-line stack view; because
I can write and store programs on my PC and transfer them to the calculator;
because I can store more programs on the 48; and especially because the
soft-menu keys combined with CST and directories make it extremely easy to
access the programs and data I keep in the calculator.
I'm sure other folks have very different patterns of use, but I think it is an
unsupportable generalization to imply that even the most advanced calculators
are rarely used for simple calculations.
--
Russ Schmidt (i...@ornl.gov)
Lockheed Martin Energy Systems, Inc.
Oak Ridge, Tennessee 37831-2009
Stéphane Gourichon
John H Meyers wrote:
> E.g. 1E499 6 MOD gives the absolutely correct result, 4,
"1E499 (represented with floating point) modulo 6" has no correct
answer, because floating point is an approximation and 1E499 doesn't
represent a unique integer number.
> on any HP calc which has a MOD function; you could never get
> any sensible answer at all to such a calculation using binary FP.
Any number between, say, 0.999999999999999E499 and 1.000000000000001E499
is represented by the same 1E499, and there are 10^484 integer in this
set, so why choose one particularly ? If 1E499 is the result of some
previous calculation, the exact result (which is unknown) it can be any
of these!
Actually, the only sensible answer from a calculator (that doesn't have
infinite precision integer calculation) for such an operation is "I
don't know, I'm not precise enough", but who would sell a calculator
that admits this ? :-)
--
Stéphane Gourichon
( Working on DM48, a Dungeon Master clone for the HP48 series
http://www.chez.com/sgourichon/hp48/dm48 )
Stéphane Gourichon
Stéphane Gourichon
John H Meyers wrote:
> E.g. 1E499 6 MOD gives the absolutely correct result, 4,
"1E499 (represented with floating point) modulo 6" has no correct answer,
because floating point is an approximation and 1E499 doesn't represent a
unique integer number.
> on any HP calc which has a MOD function; you could never get
> any sensible answer at all to such a calculation using binary FP.
Any (mathematical) number between, say, 0.999999999999999E499 and
1.000000000000001E499 is represented by the same (machine representation)
1E499, and there are 10^484 integer in this set, so why choose one
particularly to calculate a mod ? If 1E499 is the result of some previous
Samuel Hocevar
Stéphane Gourichon <stephane....@poleia.lip6.fr> wrote:
>John H Meyers wrote:
>> E.g. 1E499 6 MOD gives the absolutely correct result, 4,
>
>"1E499 (represented with floating point) modulo 6" has no correct
>answer, because floating point is an approximation and 1E499 doesn't
>represent a unique integer number.
I'm afraid I don't agree with you.
>> on any HP calc which has a MOD function; you could never get
>> any sensible answer at all to such a calculation using binary FP.
>
>Any number between, say, 0.999999999999999E499 and 1.000000000000001E499
>is represented by the same 1E499, and there are 10^484 integer in this
>set, so why choose one particularly ? If 1E499 is the result of some
>previous calculation, the exact result (which is unknown) it can be any
>of these!
So what is the 'correct answer' to "2-2" ? Is it 0 ? 0E-50 ? -0E-30 ?
--
Sam.
Virgil
=?iso-8859-1?Q?St=E9phane_Gourichon?= <gour...@poleia.lip6.fr> wrote:
>"1E499 (represented with floating point) modulo 6" has no correct answer,
>because floating point is an approximation and 1E499 doesn't represent a
>unique integer number.
Until the origin of the expression 1E499 is known, one may not conclude
that it is not exactly correct.
1E499 represents a unique integer which is the correct integer roundoff to
12 significant digits for a host of numbers, not all integral, due to the
limited precision of the HP48.
The integer formed by 1 followed by 499 zeroes may reasonable be
abbreviated as 1E499.
If the 500 digit integer value is intended, then '1E499 MOD 6' is a
perfectly reasonable formula with a perfectly reasonable integer result.
--
Virgil
vm...@frii.com
Stéphane Gourichon
Virgil wrote:
> >"1E499 (represented with floating point) modulo 6" has no correct answer,
> >because floating point is an approximation and 1E499 doesn't represent a
> >unique integer number.
>
> Until the origin of the expression 1E499 is known, one may not conclude
> that it is not exactly correct.
Yes. You've put the finger on the problem.
> 1E499 represents a unique integer which is the correct integer roundoff to
> 12 significant digits for a host of numbers, not all integral, due to the
> limited precision of the HP48.
>
> The integer formed by 1 followed by 499 zeroes may reasonable be
> abbreviated as 1E499.
>
> If the 500 digit integer value is intended, then '1E499 MOD 6' is a
> perfectly reasonable formula with a perfectly reasonable integer result.
You may consider it to be exactly this.
Let's consider a number, so big that the mantissa is too short and "1 +"
won't alter the internal representation of the number. Then what I claim
is that the MOD function loses exact meaning on this number, at least
because MOD and << SWAP 1 + SWAP MOD >> give the same answer!
Mathematical example:
if f(n)=(n! modulo 6)
f(0)=1
f(1)=1
f(2)=2
f(n)=0 if n>=3 (everybody agrees that 6 divides n! with n>3)
HP48 version:
<< 1 50 FOR A
A ! 6 MOD
A ->TAG NEXT >>
For 3<A<18 it gives zeroes, which is correct. When A is big (18 and
later), the MOD functions gives, as expected, wrong results, due to
limited precision.
No real surprise here. For big enough numbers, the MOD function loses
meanings but the human user doesn't use MOD on big numbers for useful
calculations, only to test his machine and argue with peoples on the
news ;-)
So, in the sense that the user of the calculator is a human who thinks
with base 10, 1E499 is more likely meant to be the integer "1 followed
by 499 zeroes", and the human is satisfied with it calculator telling
him that "1E499 modulo 6 = 4".
This is not absolute, only a human choice.
Samuel Hocevar wrote:
> So what is the 'correct answer' to "2-2" ? Is it 0 ? 0E-50 ? -0E-30 ?
Here, the machine cannot give an answer more reasonable than exact 0.
If uncertainties about the results are useful (physical experiments, for
example), the human user can switch to other representations of numbers
which include imprecision.
(2 +- 1E-5) - (2 +- 1E-3) would give 0 +- 1.01E-3
But in the case of MOD, ...
(1E499 +- 1E484) modulo 6 would give something like 0 +- 1E484 ??
Problem.
The set of real numbers is too big for us.
The only important thing is that for useful calculations an engineer
gets
right enough answers, and machines help them build bridges and buildings
that don't fall too quickly, and send rockets into space with reasonable
security (oops ;)
--
Stéphane Gourichon
Joseph K. Horn
> Everybody agrees that 6 divides n! with n>3
>
> HP48 version:
> << 1 50 FOR A
> A ! 6 MOD
> A ->TAG NEXT >>
>
> For 3<A<18 it gives zeroes, which is correct. When A is big (18 and
> later), the MOD functions gives, as expected, wrong results, due to
> limited precision.
It may be obvious, but please note that the inaccuracy is due to the
factorial function, not the MOD function.
The HP48 gives 6402373705730000 for 18!, which is 2000 too big. But if
you take the HP result MOD 6, you get the *correct* answer for *that*.
So MOD is fine; it's the factorial function that gets the wrong
results.
-Joe-
--
Joseph K. Horn - http://www.jps.net/joehorn/
Stéphane Gourichon
> It may be obvious, but please note that the inaccuracy is due to the
> factorial function, not the MOD function.
>
> The HP48 gives 6402373705730000 for 18!, which is 2000 too big. But if
> you take the HP result MOD 6, you get the *correct* answer for *that*.
> So MOD is fine; it's the factorial function that gets the wrong
> results.
Ok, I've caught your point. MOD assumes that the number ends with all
zeroes and after all, this choice help it choose a unique answer.
I'm only disturbed by the fact that
MOD and
<< SWAP 1 + SWAP MOD >>
give the same result for those big numbers, hence my previous post.
Thank you for making things clear.
--
Stéphane Gourichon
Marchel
> In the 8 1/2 years I have had my HP48SX the vast majority of calculation I
> have used it for have been much closer to "2+2" than "long complicated
> programs". If I have a long, complicated program I will put it on the computer
You have been ripped off by HP. You should buy $10 "scientific"
calculator in that case.
Jack
Marchel
>
> So what is the 'correct answer' to "2-2" ? Is it 0 ? 0E-50 ? -0E-30 ?
> Sam.
Sam, do you think
1 7 / 7 * should be 1.0 or 0.99999.... as HP claims ?
Jack
Jemfinch02
>
>1 7 / 7 * should be 1.0 or 0.99999.... as HP claims ?
>
>Jack
I don't have a TI handy, so you might need to try this for me:
1 7 / .01 + .01 - 7 *
I suspect that your TI will return the same result as the HP. The only reason
I think it returned the proper answer (1, rather than .9999) is that the answer
was remember symbolically as 1/7 rather than a floating point approximation.
Jeremy
------------------------------------
If i ever forget to capitalize a proper noun, forgive me. i'm a big fan of ee
cummings
My ICQ # is 28153190. My AIM/AOL name is either jemfinch02 or Cassius80.
Have a good day, and good luck in your endeavors!
Marchel
>
> 1 7 / .01 + .01 - 7 *
>
> I suspect that your TI will return the same result as the HP. The only reason
> I think it returned the proper answer (1, rather than .9999) is that the answer
> was remember symbolically as 1/7 rather than a floating point approximation.
Nope. I executed 1/7 as "diamond" "enter" which forces division to take
place and store the number in floating point format.
Once it is floating point, multiplying by 7 does calculations
in floating point. TI92 anyway returned 1.0 not 0.999999... as HP does.
Your example didn't changed anything. The return still is 1.0 :-)
> Jeremy
Jack
Joseph K. Horn
>
> Sam, do you think
>
> 1 7 / 7 * should be 1.0 or 0.99999.... as HP claims ?
How many times do we have to explain this?
1/7 =
0.142857142857142857142857....
The closest 12-digit number to that repeating decimal is
0.142857142857
and since that's the best possible answer, that's what the HP48 gives.
Now, multiply *that* by 7, and you get EXACTLY
0.999999999999
Since that's the best possible answer, that's what the HP48 gives.
Just because *you* think that the machine should lie, and round up
trailing 9's, the HP philosophy disagrees. HP says: Always give the
best possible answer for each calculation, and let the user decide
what it means.
Now, suppose a calculator used 18 digits of precision. Then:
1/7 --> 0.142857142857142857 exactly (rounded to 18 digits).
7*ANS --> 0.999999999999999999 exactly.
What should that calculator display? TI LIES TO YOU by getting the
answer shown above, but showing it as 1! You may prefer being lied to.
HP users do not.
Werner Huysegoms
"Joseph K. Horn" <joe...@jps.net> wrote:
> How many times do we have to explain this?
>
> 1/7 =
> 0.142857142857142857142857....
>
> The closest 12-digit number to that repeating decimal is
> 0.142857142857
> and since that's the best possible answer, that's what the HP48 gives.
>
> Now, multiply *that* by 7, and you get EXACTLY
> 0.999999999999
> Since that's the best possible answer, that's what the HP48 gives.
>
> Just because *you* think that the machine should lie, and round up
> trailing 9's, the HP philosophy disagrees. HP says: Always give the
> best possible answer for each calculation, and let the user decide
> what it means.
>
> Now, suppose a calculator used 18 digits of precision. Then:
>
> 1/7 --> 0.142857142857142857 exactly (rounded to 18 digits).
> 7*ANS --> 0.999999999999999999 exactly.
>
> What should that calculator display? TI LIES TO YOU by getting the
> answer shown above, but showing it as 1! You may prefer being lied
to.
> HP users do not.
>
Does it use 18 digits of precision? or 18 internally/15 shown
(like the 48's 15/12)
In that case:
1/7 = 0.142857142857143 (rounded to 15 digits)
7*ANS -> 1.000000000000001 exactly or 1.0 rounded to 15 digits.
Never seen a 92 - just guessing.
Anyway - even with 15, 18 or who-cares-how-may digits of precision,
there will always be numbers so that (1/x)*x is NOT equal to
1.0. Those are the limitations of floating point arithmetic.
( (1/3)*3 should NEVER be 1.0, for instance.. - except in 'exact mode')
--
Best Regards,
Werner Huysegoms
Reply-To: werner.h...@dgx11.cec.be
remove the x before replying
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
sasq...@hotmail.com
You are wrong.
The TI92 retruns 1. in the history because the 14 digits result is
rounded to 12 digits when it is displaid in the history.
When you recalled the result in the command line it is:
.99999999999998
> Jack
Jean-Yves Avenard
1 = 3 * ( 1/3 ) = 3 * 0.3333333333333.... = 0.99999999999..... = 1
So what's the problem :)
At least the HP48 gives exactly what it has calculated, and do not truncate
the value in order to come back to 1...
1 / 7 is approximately .142857142857
This multiply by 7 is not 1 but .999999999999
Which is perfectly normal... HP48 doesn't cheat.
Jean-Yves
Marchel <mar...@eaglequest.com> wrote in message
news:375707B9...@eaglequest.com...
> Jemfinch02 wrote:
> >
> > 1 7 / .01 + .01 - 7 *
> >
> > I suspect that your TI will return the same result as the HP. The only
reason
> > I think it returned the proper answer (1, rather than .9999) is that the
answer
> > was remember symbolically as 1/7 rather than a floating point
approximation.
>
> Nope. I executed 1/7 as "diamond" "enter" which forces division to take
> place and store the number in floating point format.
> Once it is floating point, multiplying by 7 does calculations
> in floating point. TI92 anyway returned 1.0 not 0.999999... as HP does.
>
> Your example didn't changed anything. The return still is 1.0 :-)
>
> > Jeremy
>
> Jack
John H Meyers
> In the 8 1/2 years I have had my HP48SX the vast majority of
> calculation I have used it for have been much closer to "2+2"
> than "long complicated programs".
> If I have a long, complicated program I will put it on the computer
Another "JM" then wrote:
> You have been ripped off by HP.
> You should buy $10 "scientific" calculator in that case.
Well, in the past few years since I bought my last automobile,
I find that the vast majority of trips I have made in it
have been from one side of this campus to the other.
I wonder whether I have actually been ripped off by General Motors,
because I should have bought a bicycle instead?
All the same, whenever I want to take a 500-mile trip,
rather than just across campus, this car also gets me there
(and even back :)
Come to think of it, this whole fancy computer does little more,
most of the time, then merely edit a few paragraphs of text
(just like this post);
hmm... I think I want my money back from Dell :)
This all reminds me, once again, of the story about a statistician
who drowned in a pond whose *average* depth was only six inches :)
VeryNiceGuy (Pacific)
...> "1E499 (represented with floating point) modulo 6" has no correct
> answer, because floating point is an approximation and 1E499 doesn't
> represent a unique integer number.
i just verified using my number-theoretic algorithms that 10^499 mod 6
is 4. the suit calculates inverse powers also. if you guys are
interested, i can posted them here. meanwhile ...
*yawn* i need some sleep.
--
Very Nice Guy (Pacific Version)
Singapore
--------------------------------------------------
Your personal power (the pay, the respect, the
treatment, the friends you get) is inversely
proportional to the availability of the people
who can replace you.
--------------------------------------------------
sad, harsh reality observed by the Very Nice Guy
VeryNiceGuy (Pacific)
...> Mathematical example:
> if f(n)=(n! modulo 6)
> f(0)=1
> f(1)=1
> f(2)=2
>
> HP48 version:
> << 1 50 FOR A
> A ! 6 MOD
> A ->TAG NEXT >>
it's possible to use modulo versions of *, +, -, ^, / operations.
i have the algorithms.
John H Meyers
> Sam, do you think
> 1 7 / 7 * should be 1.0 or 0.99999.... as HP claims ?
I asked JM to try a couple of things on his TI92 for me,
and the answers that he reported back, by email, were:
8.E10 / 9 - 8888888888 ==> .8889 (why not .88888888 ?)
1 / 7 * 7 - 1 ==> 1.E-14 (why not closer to 1.E-18 ?)
If said TI92 actually keeps 18 digits in every mantissa,
then why did we not get the results indicated in parentheses?
From the above (albeit scant) results, I am beginning to suspect
that said TI92 computes internal results to 18 digits, and then
*rounds* to 14 digits, much as the HP48 computes internal results
to 15 digits, and then rounds to 12.
The HP48, however, *allows* you to display *all* the remaining
digits in its truncated/rounded 12-digit final mantissa, revealing
the *inevitable* effect of such truncation or rounding, while said
TI92 *disallows* you to display all 14 digits of its actual result
for 1 / 7 * 7, which likewise is not exactly equal to 1, either.
To get the same effect on your HP48, just set display mode 9 SCI;
now 1 / 7 * 7 comes out to "exactly" 1, just as it does on TI92!
As Joe Horn pointed out, even if 18 digits were retained,
the final answer would still not be exactly 1, although the extra
digits retained would of course accordingly reduce the percentage
error inherent in each truncation or rounding.
To explore a bit more deeply, why does any calculator add a few
extra "guard digits" to the number of accurate digits it expects
to be able to deliver in final answers? This is done because,
in computing more complex functions (e.g. log, trig) using
fixed-width registers, the final few digits tend to become
unreliable. One approach, taken by some calculators
(e.g. older Casio, etc.), is to leave the "guard digits"
attached to all answers, but to only *display* a rounded answer.
If we do only this, then one slightly unfortunate tendency
in the results of repeated loops, such as square-root
followed by squaring, or SIN followed by ASIN, or many
other consecutive calculations, each of which tends to
*truncate* the result *downward* a little bit, is that
the results tend to keep *drifting* off in *one*direction*
from the "true" answer.
An alternate approach to this perpetual truncation is to consider
that if the "guard digits" tend to be inherently unreliable,
then keeping them is not really doing anything for us
(except letting us kid ourselves about how many accurate digits
there are in each function's answer). What if we instead *round*
each function result to just the number of digits which we believe
we can be *sure*of* in each result?
In any case where the true result should have been exact, but due to
some truncation was lowered, then this restores the exact result.
In any case, the procedure of "unbiased rounding" (used in HP calcs)
is said to be good for developing the most likely correct end results,
and it also generally stabilizes any of the above repeated loops,
so that the values after even a billion iterations will not
have tended to "drift off" in one direction. One more benefit
to *rounding* results to only the number of *accurate* digits
is that one need not use as much memory for their storage,
eliminating the wasted storing of *inaccurate* digits.
If the above results (and my hasty conclusion) for TI92 are correct;
then even the TI92 may be trying to do the very same thing, by
taking 18-digit "raw" results and then rounding them to only 14 digits;
the TI92 then only *displays* up to 12 of those digits, *rounding*
once again in the display, just as you can force your HP48 to do
by setting a display mode such as 9 SCI, in which case most all of the
HP48's unavoidable rounding errors will also similarly seem to vanish.
JM says that some engineering calculations really need extraordinary
precision to get accurate final results (such as matrix math, in which
HP48G* already keeps 15 digits in all intermediate results); if so,
then we see that TI92 does keep at least two more *rounded* mantissa
digits than HP, and so we must grant that it can deliver final results
to two more significant places, all other accuracy factors being equal.
On the same CPU, longer numbers of digits will require more calculation
time, possibly rising at a more than linear rate (for multiplication
and similar operations), and of course it requires correspondingly
more storage, so there is of course a trade-off. At what point
the precision is enough for your purposes depends on what sort of
work you are doing; my friend JM seems to have more demanding work
to do, so perhaps he needs those 14 digits, while others of us don't.
Does any of the above relate to the issue of BCD vs. binary in the
representation of floating-point (mantissa & exponent) quantities?
Well, by using BCD, one simplifies the human interface, where the
human always inputs decimal (BCD) values and likewise wants to see
decimal (BCD) results. Additionally, most exact decimal fractions
(e.g. $0.12) can not be precisely represented in binary, because
1/5 or 1/10 is an infinite repeating sequence in base 2, just as is
1/3 in base 10 (or base 2), so the inevitable truncation to a finite
length mantissa begins to make such values slightly inaccurate.
Although we do not generally think of it this way, financial
balances, based on dollars and cents (or other essentially
"decimal" currencies) can be *exactly* represented only in base 10.
If, for example, we subtract $1,234,567,890 from $1,234,567,890.12
then we expect to get $0.12 as an absolutely exact answer, and not
$0.11999553 as an "approximate" answer. Computer databases generally
acknowledge this essentially "fixed-point" nature of accounting
calculations by having a special data type such as "fixed" or
"currency" for such data, in which there is a given number of digits
reserved, and a precisely fixed location of the decimal point
(say just before the last two digits, for dollars and cents).
In a calculator, however, we generally unthinkingly employ the
same "scientific" or "floating-point" number type, both for
values whose precision need be only "relative" and for
values whose precision must really remain "absolute"
(e.g. a financial balance should be to the exact penny,
rather than approximate). This particular desire, to make
calculations that are *exact* when performed in base 10
always remain exact, can be easily accomplished by using
base 10 internally, which means to use decimal digits (BCD),
rather than converting to a binary-based "floating" format.
Of course, there are some advantages to performing internal
calculations in binary, rather than in decimal; for one thing,
given CPU registers having 64 bits, these could be used for
a sign bit and 63 more binary bits, for a total range of about
[+/-] 9E18, or (as in the Saturn) there could be a sign digit and
15 more decimal digits, for a total range of [+/-] 1E15; thus,
for a given register size, the ultimate precision is greater
when using a binary mantissa. In some processor architectures
it is also much faster to perform binary math than decimal math,
although in the Saturn CPU used by HP48, which is specially
designed for HP calculators, decimal math is just about as fast
as binary math, so in HP calculators this factor is somewhat moot.
The price for gaining some more effective precision using binary,
however, is that you must convert between binary and decimal for
all input data and display values, you must always round
output values to "hide" any truncation/rounding of original decimal
input caused by using binary in place of decimal, and you must also
watch for problems with "step" functions such as IP (integer part),
which could get an answer suddenly reduced by 1 if the *binary*
result of some operations is even the slightest bit less than
the *decimal* result. For example, 1/5 in hexadecimal is the
fraction .3333333333333 etc, or .0101010101010101 etc. in binary;
for any register size which is a multiple of 4 bits, if we then
multiply this result by 5, the answer is .FFFFFFFFFFFFF etc.
rather than 1.0000000000, so, what if our next operation is IP?
Well, to avoid the surprising result that IP (1/5 * 5) = 0,
we would have to be sure to first round this result somewhat,
which would take some extra care. Of course, you may say that
IP (1/3 * 3) comes out to zero, in binary *or* decimal, but since
people have some prejudices about what operations can be relied
upon to come out *exact* in decimal base, having the calculator
"use the same language as" its student and teacher users,
and even financial users, may make it slightly more
acceptable to them, whereas engineering users by themselves
might not have the same sort of objections.
JM tells me that binary FP is the only modern system used now
in computers (which means that Unix "dc" and "bc" are not modern,
since their internal base is actually 100 :) -- and also that
various databases which maintain a "fixed" or "currency" data type
are also slightly less than modern). What JM wants of course
is a small calculator which is actually a computer, since he says
that there exist current palmtop computers with much more display
and memory and speed than the latest HP calcs,
but which are about the same price.
The only thing missing, then, is the all brand new design of a brand
new series of calculator, probably incompatible with previous calcs;
what we are getting, however, is just the next logical step for
the existing calc product line, rather than a brand new start.
Well, that's reasonable enough for HP, I would say.
I think that JM acknowledges that BCD better suits the Saturn;
however, it was a crime for TI to keep using BCD in the TI92,
that being based on a standard Motorola CPU, for which BCD
is so much slower and more difficult than binary.
Well, fine, at least TI are the bad guys -- not only don't they
really seem to keep any 18-digit results around, but they also
do it all in inefficient decimal. Well, all I gotta say is,
less power to them :)
Christian Meland
John H Meyers <jhme...@miu.edu> wrote in message
news:3757C7...@miu.edu...
> There goes "JM" again:
>
> > Sam, do you think
> > 1 7 / 7 * should be 1.0 or 0.99999.... as HP claims ?
>
> I asked JM to try a couple of things on his TI92 for me,
> and the answers that he reported back, by email, were:
>
> 8.E10 / 9 - 8888888888 ==> .8889 (why not .88888888 ?)
>
> 1 / 7 * 7 - 1 ==> 1.E-14 (why not closer to 1.E-18 ?)
>
My ti89 gives -2E-14. I thought it would give the same as the 92(?) (yes, I
do have a ti89, but only to prove that the hp48/49 are better ;-)
Chr
Tom Lake
> >
>
> do have a ti89, but only to prove that the hp48/49 are better ;-)
My 89 gives 0 for 1/7*7-1. How do you have your MODE settings? I have Float 12
and Exact/Approx set to Auto.
Tom Lake
ICQ #25589135
John H Meyers
> 1E499 6 MOD gives the absolutely correct result, 4.
Stéphane Gourichon <stephane....@poleia.lip6.fr> commented:
> "1E499 (represented with floating point) modulo 6" has no correct
> answer, because floating point is an approximation and 1E499
> doesn't represent a unique integer number.
It *may* be an approximation, but it does not *have* to be!
[Thanks, Virgil :]
If I perform 5.00000000000 IP, would you tell me that the answer
might as well be "either 5 or 4, because 5.00000000000 is only
a floating-point approximation, and if the true value is
slightly less, then its integer part might be 4" ???
Floating point is an approximation only if it is a result which the
user has cause to know a priori to be inexact, e.g. it might have
been either measured to a limited accuracy or computed to a limited
accuracy, or be impossible to represent exactly in some given format.
However, if I want to pick up a TI89 and type in a numeral 1
followed by 499 zeros, and then to perform 6 MOD on that,
I could do so, obtaining (hopefully for TI :) the precise answer 6;
if I want to get that same result with my HP48, the HP48
will perform the operation precisely, developing all 499 or so
quotient digits along the way (and discarding them) until the
final remainder of 6 is left, getting the same (right) answer.
BTW, I could readily use this ability of an HP48 to obtain a precise
remainder for an arbitrarily long integer (or decimal string)
divided by any other 12-digit or shorter integer (or decimal string);
you do not have to use this ability if you have no personal use for
it,
but it was built into the HP48 (and earlier calcs, e.g. HP18C,19B)
so that whoever wants this ability can make use of it.
If you go to a store and purchase something for 59 U.S. cents,
is it correct to say that because the next nearest possible
price is either 58 or 60 cents, the number .59 does not really
represent an exact price, that it really represents a price
anywhere between 58 and 60 cents, so that the price of 100 of
these items is really somewhat indeterminate? Likewise, the sum of
money, possibly added up from a balance sheet, of $1,234,567,890.12
is not "approximate" if it was a correct digitally added total
of many individual smaller balances; in fact, there was a case
of someone who believed that no one would ever notice if he
"rounded down" a few million account balances by a half cent
or less and deposited the sum to his own account; much to his
dismay, the courts disagreed, and convicted him of embezzlement
for this "fuzzy logic" :)
There exist values which *can* be expressed *exactly* in decimal
(or in whatever base I might be using), and if I want to make use
of this fact to calculate something exactly, for my purposes,
and if the HP48 was designed to make it possible, then it is
an advantage for me to be able to use that ability.
Once such example of how the "extra mile" to which HP has gone
to make calculations as accurate as possible can be of benefit is
in the DIGI24 routines on Goodies Disk #9; these programs allow
the HP48 to quickly do arithmetic to *double*precision* floating-point
accuracy (24 significant digits), but the programs will not work on
any calculator which treats floating-point math more casually
than does the HP48; in fact, it appears that HP calcs are the
*only* ones made on which this can be done, basically because
*only* HP performs consistent "unbiased rounding" of every
result, whereas other calculators are content to only toss
a couple of extra "guard digits" into every saved value, but still
perform one-sided *truncation* internally, every time, producing
a tendency for a long chain of calculations (e.g. square root
alternating with squaring, SIN alternating with ASIN, etc.)
to keep decreasing in value, whereas it tends to stabilize in
HP calcs, no matter how may times this loop may be repeated
(even millions of times).
For a slight digression into just how far the commitment to
this principle goes, in latter-day HP calcs, note these results:
1.E24 500,000,000,000. - ==> 1.E24
1.E24 500,000,000,001. - ==> 9.99999999999E23
A close analysis of the above distinction might lead us to conclude
that the subtraction is carried out so as to consider *25*digits*
before the final rounding is applied, e.g.:
1,000,000,000,000,000,000,000,000
- 500,000,000,001 <== last digit makes a difference!
---------------------------------
999,999,999,999,499,999,999,999 <== (or just 1 count higher)
This is the sort of "attention to detail" (and as a consequence
the ability use such things as DIGI24 for correct double-precision)
which HP has built into its products. Sometimes a fine product
falls into the hands of someone who doesn't appreciate it,
e.g. a kid might scribble with magic marker over the face of
the Mona Lisa, if it were not protected from such abuse,
but sometimes a fine product falls into the hands of someone
who can use and value what its maker put into it, and that's
the kind of better audience that the better artist created it for.
But what the heck, today you can probably sell a large crystal
of cut quartz for more than a small diamond, at least to many
mass-market customers :)
> Any number between,
> say, 0.999999999999999E499 and 1.000000000000001E499
> is represented by the same 1E499, and there are 10^484 integer
> in this set, so why choose one particularly ? If 1E499 is the result
> of some previous calculation, the exact result (which is unknown)
> it can be any of these!
You made assumptions: *if* it is the result of some *previous*
(and *inexact* calculation)...; the given range of values
each *could* have been rounded to the same 1E499, but it's
also possible that no other value was the intended value.
If you are married, then just consider that your spouse *could*
have married anyone else in about half the world's population,
so why choose you, particularly? (S)he might as well spend
each day (and night) with anyone else then, no?
> Actually, the only sensible answer from a calculator (that doesn't
> have infinite precision integer calculation) for such an operation
> is "I don't know, I'm not precise enough", but who would sell
> a calculator that admits this ? :-)
Let's see who would sell a calculator which took a simpler approach
to the problem; here's a UserRPL program to compute MOD exactly
according to the definition of MOD:
\<< DUP2 / FLOOR * - \>>
For common small integers (or decimals), this will give the
exact same result as the built-in MOD function.
Now, let's try it on some other values:
UserRPL True MOD
1E13 13 ==> 0 10
1E13 7 ==> 10 3
1E499 57 ==> 1E487 13
Now, isn't it supposed to be the case that the result of MOD is
not supposed to be greater in magnitude than the divisor?
So what kind of answer is 10, when the divisor is only 7?
What kind of answer is 1E487, when the divisor is only 57?
And what kind of answer is 0, when the argument is
not really a multiple of the divisor?
What kind of "look at the stupid buggy answers" posting would
we be seeing here if that kind of answer were returned?
In accordance with its design philosophy, what the HP actually
does is return the most accurate possible answer for the given
precise input. If the user has input values that can be
precisely expressed, then the answer is correct, right down
to the last digit, for most functions (with rare exceptions).
It is up to the user to determine the error bounds if his
input may not be precise, but the calc will not *assume*
imprecision and thus render *any* calculation useless.
For example, sin (3.14159265359 radians) returns the
result -2.06761537357E-13 in the HP48; this value
is correct to the last significant digit,
based upon the precise value of pi (to 25 significant digits)
being 3.141592653589793238462643 (just subtract the above
argument from pi to get the correct result).
You can't get more precise output from less precise input,
but one more principle that HP calcs have delivered is that you
also can't get any less precise output from perfectly precise input!
Hey, I heard that the French were the ones who really appreciated
all this fine stuff; if you don't, send back your HP48, and
while you're at it, wrap up and send along the Mona Lisa, too :)
VeryNiceGuy (Pacific)
>
...
it is a fact that errors will accumlate through a chain of calculations.
why not this:
have the calculator report the error with the result e.g.
0.999999999 +/- 0.000000000001
just like the IERR in the numerical integration.
Stéphane Gourichon
reading it.
(But that's what are news for, aren't they ? :-)
John H Meyers wrote:
> It *may* be an approximation, but it does not *have* to be!
I hesitated to post again today to same about the same thing.
I thought that there are two points of view.
Either you consider that the numbers you work with are approximations
(like I did in the post you commented), and it is consistent (I think)
but incompatible with the other point of view.
Or you consider that the machine only has to give the most precise
possible answer, not trying to guess that the given number may be an
approximation but assuming that they are what they are, and are exact
(like you explained).
(snip)
> 1.E24 500,000,000,000. - ==> 1.E24
>
> 1.E24 500,000,000,001. - ==> 9.99999999999E23
Pretty interesting (I haven't checked)
> This is the sort of "attention to detail" (and as a consequence
I like attention to detail. If you look at the game I'm programming
(DM48), I paid great attention to the way I coded datas to fit in a very
small memory footprint, and being fast and bug-free. I don't like dirty
tricks that just work here but you don't know how it work and if it is
reliable. DM48 takes 18kb for now with two levels, many objects, a
monster and all, but I'm sure it would have taken far more without this
attention. Take a look at it ( http://www.chez.com/sgourichon/hp48/dm48
) if you have time and will. I appreciate all feedback.
> but sometimes a fine product falls into the hands of someone
> who can use and value what its maker put into it, and that's
> the kind of better audience that the better artist created it for.
>
> But what the heck, today you can probably sell a large crystal
> of cut quartz for more than a small diamond, at least to many
> mass-market customers :)
Is this an innuendo (is this the right word) about software industry and
the PC ? ;-)
> > Any number between,
> > say, 0.999999999999999E499 and 1.000000000000001E499
> > is represented by the same 1E499, and there are 10^484 integer
> > in this set, so why choose one particularly ? If 1E499 is the result
> > of some previous calculation, the exact result (which is unknown)
> > it can be any of these!
>
> You made assumptions: *if* it is the result of some *previous*
> (and *inexact* calculation)...;
I try to always make my assumptions clear. It helps writing clean code.
> the given range of values
> each *could* have been rounded to the same 1E499, but it's
> also possible that no other value was the intended value.
>
> If you are married, then just consider that your spouse *could*
> have married anyone else in about half the world's population,
> so why choose you, particularly? (S)he might as well spend
> each day (and night) with anyone else then, no?
I'm the guy that precisely ends with the 484 zeroes, so she couldn't
miss me and go with another "1E+499 guy" anyway ;-)
> > Actually, the only sensible answer from a calculator (that doesn't
> > have infinite precision integer calculation) for such an operation
> > is "I don't know, I'm not precise enough", but who would sell
> > a calculator that admits this ? :-)
Do you agree that this answer is consistent with the first point of view
?
(Of course it does not fit the second)
> Let's see who would sell a calculator which took a simpler approach
(snip)
> not really a multiple of the divisor?
In a way, the Casio way of calculating looks like the first point of
view, but not exactly.
I remember some experiments about precision of calculations, designed a
function that (on most calculators) returns an approximate number of
significant digits, and other experiments.
You get also *interesting* things when zooming *really* close to a
regular curve (sine for example) on a HP48. I don't know if anyone
already discussed this.
> What kind of "look at the stupid buggy answers" posting would
> we be seeing here if that kind of answer were returned?
At first sight, << pi sin >> returning something non-zero might seem
disappointing if the rules are not clear. (I said might, because it is
actually with this kind of example that I got a feeling about the spirit
of what a HP does. But it was never as clear as before your post.)
> In accordance with its design philosophy, what the HP actually
> does is return the most accurate possible answer for the given
> precise input. If the user has input values that can be
> precisely expressed, then the answer is correct, right down
> to the last digit, for most functions (with rare exceptions).
I wondered if the subject was still OK, because we don't talk about BCD
here.
But yes, it is, because the way numbers are coded influences the way
they are rounded up, and the result of other calculations (MOD for
example).
Notice that there are as many "instances" of the HP philosophy as they
are ways of storing floats in the machine. If real numbers were coded in
binary form, binary zeroes would be assumed at the end of what (in base
10) we call 1E499, putting a mess between what is displayed and what is
inside. Just think about 2^450 stored as mantissa=1, exponent=450. What
should the diplay say, because a decimal display with limited number of
digits cannot represent exactly this number, which is precisely
represented in binary form with a short mantissa).
I understand better now the choice HP did for BCD coding.
> It is up to the user to determine the error bounds if his
> input may not be precise, but the calc will not *assume*
> imprecision and thus render *any* calculation useless.
That makes things clear.
> For example, sin (3.14159265359 radians) returns the
> result -2.06761537357E-13 in the HP48; this value
> is correct to the last significant digit,
> based upon the precise value of pi (to 25 significant digits)
> being 3.141592653589793238462643 (just subtract the above
> argument from pi to get the correct result).
BTW, I noticed the kind of things like Jean-Yves said recently
1 3 / 3 * gives 0.999...
whereas on a Casio FX it gives 1
and I also thought that the HP doesn't lie about the result,
admitting the limitation of calculating with floating points, no more,
no less.
> You can't get more precise output from less precise input,
> but one more principle that HP calcs have delivered is that you
> also can't get any less precise output from perfectly precise input!
That makes things clear.
> Hey, I heard that the French were the ones who really appreciated
> all this fine stuff;
Not all french people do even know such fine stuff exist, unfortunately.
I'm glad to see that some american (notice that I assume you are
american) have a sense of precision. Thank you for this interesting
post.
> if you don't, send back your HP48,
Oh, never! I own a HP48S (since 1993) and a 48GX (late 1994). The 48S
still works, though one day a component emitted smoke when I opened it,
and had to invert batteries 'cause it didn't want to wake up again. The
48GX still works also, and it's really a fellow device, 'cause I took it
with me in a *lot* of places, trains, planes, etc... and it works
perfectly.
Just to give you an idea, I even skydived with a coupled of friends with
the 48GX in hand, and we took photographs. I've scanned them and will
put them on my web page if anyone is interested to see them.
> and
> while you're at it, wrap up and send along the Mona Lisa, too :)
That's ok, Mona Lisa is fine where she is. But what if you came to Paris
and see, instead ? Then I'll invite you to visit the lab where I work.
Bye and "bon week-end" as we say...
--
Stéphane Gourichon
Marchel
>
> Well, in the past few years since I bought my last automobile,
> I find that the vast majority of trips I have made in it
> have been from one side of this campus to the other.
>
> I wonder whether I have actually been ripped off by General Motors,
> because I should have bought a bicycle instead?
> All the same, whenever I want to take a 500-mile trip,
> rather than just across campus, this car also gets me there
> (and even back :)
John, do you really need $50,000 Cadillac Escalade to drive around the
campus, only because it will be handy for one time 500 miles trip ?
> Come to think of it, this whole fancy computer does little more,
> most of the time, then merely edit a few paragraphs of text
> (just like this post);
> hmm... I think I want my money back from Dell :)
If you use it for text, most magazines already suggest to buy AMD
$1000 machines :-)
> This all reminds me, once again, of the story about a statistician
> who drowned in a pond whose *average* depth was only six inches :)
>
> -------------------------------------------------------
> Establish world peace now: <http://www.kosovopeace.org>
> <http://www.natural-law.org>
> Consciousness-based education: <http://www.mum.edu>
Jack
Jemfinch02
>>
>> Well, in the past few years since I bought my last automobile,
>> I find that the vast majority of trips I have made in it
>> have been from one side of this campus to the other.
>>
>> I wonder whether I have actually been ripped off by General Motors,
>> because I should have bought a bicycle instead?
>
>> All the same, whenever I want to take a 500-mile trip,
>> rather than just across campus, this car also gets me there
>> (and even back :)
>
>John, do you really need $50,000 Cadillac Escalade to drive around the
>campus, only because it will be handy for one time 500 miles trip ?
>
>> Come to think of it, this whole fancy computer does little more,
>> most of the time, then merely edit a few paragraphs of text
>> (just like this post);
>> hmm... I think I want my money back from Dell :)
>
>If you use it for text, most magazines already suggest to buy AMD
>$1000 machines :-)
>
>> This all reminds me, once again, of the story about a statistician
>> who drowned in a pond whose *average* depth was only six inches :)
[snip]
>
>Jack
What was the point of this?
Christian Meland
news:dFQ53.768$Qc....@newsfeed.slurp.net...
> > > 1 / 7 * 7 - 1 ==> 1.E-14 (why not closer to 1.E-18 ?)
> > >
> >
(yes, I
> > do have a ti89, but only to prove that the hp48/49 are better ;-)
>
> My 89 gives 0 for 1/7*7-1. How do you have your MODE settings? I have
Float 12
> and Exact/Approx set to Auto.
Try approx mode, not Auto.
Chr
>
> Tom Lake
> ICQ #25589135
>
>
>
Tom Lake
> Float 12
> > and Exact/Approx set to Auto.
>
> Try approx mode, not Auto.
>
Tom Lake
ICQ #25589135
Christian Meland
Why should you use your calc. when you may do the caclulation 'by hand'? We
were discussing the internal accuracy when working with real numbers.
Christian
>
> Tom Lake
> ICQ #25589135
>
>
Jean-Yves Avenard
1/7*7-1 in exact mode.
If you could trace the execution you would get:
1/7 -> 1/7 (stay in exact mode)
*7 = 1/7*7 (you still are in exact mode)
-1 = 0
You would get the same answer on ANY machine that can perform opeartion in
exact mode (including the HP49)
The thread was talking about numerical approximation..
In AUTO mode (on the TI89) if you do:
1/7*7-1 you will get 0
Because on the expression, the TI89 will perform the whole operation in
exact mode, and at no time it had used a numerical operation)
However if you do:
1./7. ENTER -> .142857 (Or 1/7 Diamond ENTER to get an approximation)
And now:
Ans(1)*7-1 = -2.E-14
Actually, that's what worries me the most: most of the TI89/92 users have no
idea of what is going on internally, and simply follow (and trust)
completely what the machine is saying... Too bad, since you've missed the
whole purpose of a CAS included in a calculator: a learning tool, not a
machine that will perform every step of thinking for you..
Jean-Yves
Tom Lake <tom...@slic.com> wrote in message
news:SqN63.2720$9J.1...@newsfeed.slurp.net...
> > > My 89 gives 0 for 1/7*7-1. How do you have your MODE settings? I
have
> > Float 12
> > > and Exact/Approx set to Auto.
> >
> > Try approx mode, not Auto.
> >
> Why should I use Approx. mode when Auto gives the correct answer, 0?
>
> Tom Lake
> ICQ #25589135
>
>
Marchel
> > > > 1 / 7 * 7 - 1 ==> 1.E-14 (why not closer to 1.E-18 ?)
> > > >
> > >
> (yes, I
> > > do have a ti89, but only to prove that the hp48/49 are better ;-)
> >
> Float 12
> > and Exact/Approx set to Auto.
>
> Try approx mode, not Auto.
It doesn't matter what mode is "ON".
What should be done is after entering 1/7 press DIAMOND ENTER
because it forces TI to convert perfect fraction into floating point
approxiamtion. You can also enter 1./7 or 1/7. to achieve the
same result. After that enter
ANS(1)*7-1 and you will not get 1.0 but something in a range of
1E-14
Jack
--
+-------------------------------------------------------+
| Anna i Jacek Marchel |
| |
| e-mail: mar...@eaglequest.com |
| WWW: http://www.eaglequest.com/~marchel |
+-------------------------------------------------------+