HP48: algebraic mode?
Joachim Börger
When I buyed my calculator, I wondered about the polnic notation. This
is really uncomfortable. There seem to be only 3 possibilities to get
away from this shit:
1. Using the equation writer. This cost A LOT OF time and I always
have to manually say "go into algebraic mode" and finally press the
EVAL-Button.
2. Using the algebraic mode by pressing the '-Key. This ist fast, but
not more comfortable then the equation-writer: First I have to press
the '-Key, than type in my math. expression, press ENTER and EVAL. Not
comfortable, too.
3. Using a algebraic-simulator. I've found 2 programme: "algebraic
calculator" and "calc III". the algebraic calculator is much to slow,
and with calc III, I can not use "(" or the equation-writer. Calc III
has some bugs, too.
So, anyone has a good suggestion how to use the HP48G as a calculator?
My Ti30X (simple, cheap calculator) is easier to use.
Joachim
Wolfgang Rautenberg
> When I buyed my calculator, I wondered about the polnic notation. This
> is really uncomfortable. There seem to be only 3 possibilities to get
Get a HP49. There you've all possibilities
to get "rid of the shit".
- Wolfgang
PS. I wonder what level has the Technical
University Aachen if students like you
are there immatriculated :-)
Neill McKay
>
> Hi!
>
> When I buyed my calculator, I wondered about the polnic notation. This
> is really uncomfortable. There seem to be only 3 possibilities to get
> away from this shit:
1A. Use the HP for a week, and you'll never go back to algebraic
> 2. Using the algebraic mode by pressing the '-Key. This ist fast, but
> not more comfortable then the equation-writer: First I have to press
> the '-Key, than type in my math. expression, press ENTER and EVAL. Not
> comfortable, too.
You don't need to type ENTER, just EVAL.
> 3. Using a algebraic-simulator.
That would be a bit like buying a top-of-the-line aircraft and
installing a set of WWI-era controls to fly it.
> My Ti30X (simple, cheap calculator) is easier to use.
Then maybe that's what you should be using.
Neill McKay
Caspar Lugtmeier & Eva Skotarczak
Looks like the calc deserves a better user (buyer).......
Caspar
--
"Joachim Börger" <eins...@gmx.net> wrote in message
news:ir78ftk7qh566d085...@4ax.com...
Steen S. Schmidt
> away from this shit:
[!]
> So, anyone has a good suggestion how to use the HP48G as a calculator?
Not anything you could use, obviously.
I've got news for you (probably the only news you'll get talking like that):
The HP48G is an RPN calculator - this is one of its major forces. You should
learn that, and distance yourself from the 13-to-a-dozen guys who use
algebraic calcs. If you can't do that, ditch HP as a brand, and go with the
mainstream (and you better get used to that, it seems).
-
Steen
Heiko Arnemann
habe gerade Steen's message gelesen.
Na dann probier mal schön UPN und berichte der NG, wenn Du von den Jungs noch was
höhren willst. (Der Steen, ist sonst ein ganz ein Netter, Wolfgang ist auch sehr hilfsbereit.)
Es war wohl ein bißchen verletzend, von "shit" zu sprechen, das heißt ja, das die Leute shit lieben
und
gerne benutzen.
Wie wär es mit:
Ok, ok, I tried RPN and I feel much more compfortable with that, as I thougt before.
Let me have some lessons, I will give you some examples.... ;-)
Ich schreib Dir das, weil ich auch etwas unmotiviert in die Runde geplatzt bin, ohne zu
wissen wer da alles mitmischt....
MESZ 18:30h
Gruß
Heiko
Heiko Arnemann
> When I buyed my calculator, I wondered about the polnic notation. This
> is really uncomfortable.
It is more compfortable than alg-mode
> away from this *nice feature: *corrected!
[snip
why getting away from a nice natural feature?
...Heiko
Ricardo Blasco Serrano
Yes, knowing how to use it ;-)
Regards
--
Linux Registered User: 202 170
Kernel 2.4.1
http://xie121.infovia.xtec.es/~rblasco
"Uníos, hermanos linuxeros"
Joachim Börger
>University Aachen if students like you
>are there immatriculated :-)
A high level!!!
Piotr Balcerzak
Wolfgang Rautenberg <ra...@math.fu-berlin.de> wrote in message
news:3AF52037...@math.fu-berlin.de...
> Joachim Börger wrote:
> > When I buyed my calculator, I wondered about the polnic notation. This
> > is really uncomfortable. There seem to be only 3 possibilities to get
> > away from this shit ...
>
> Get a HP49. There you've all possibilities
> to get "rid of the shit".
I'm affraid HP49 would be much more beyond his capabilities.
First, he should try to learn how to use an abacus.
>
> - Wolfgang
>
> PS. I wonder what level has the Technical
> University Aachen if students like you
> are there immatriculated :-)
I can guess: "Business & Management" faculty is pretty strong... ;-)
Sorry I couldn't help myself :-) Once I learned RPN I forgot about
using algebraic notation for entering data. I will never do it again -
slow, ineficient, error-prone relic of stone era.
(I love HP48G which I own for 4 years; I saw HP49G in store
twice but couldn't decide to buy it - I still have mixed feelings
about it...)
Cheers,
Piotr
John H Meyers
> Anyone has a good suggestion how to use the HP48G as a calculator?
> My Ti30X (simple, cheap calculator) is easier to use.
That's like what I said when I tried to go from trike to bike
(by the way, I never made it :)
Here's a temporary crutch:
\<< -55 CF 28 MENU "" { "''" 2 ALG V }
IFERR INPUT THEN 0 MENU DROP2 ELSE 0 MENU
OBJ\-> DUP EVAL END \>> 'ALG' STO
Now press ALG, fill in the expression, press ENTER,
see both your original expression and the answer on the stack.
This is practically as good as an HP49 in ALG mode, anyway,
so think of all the money that has been saved ;)
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Wolfgang Rautenberg
> Wolfgang Rautenberg wrote
> > Get a HP49 ...
To co ja ci radze, o ile posiadasz forcy.
Najtaniey u CYNOX. Nie bediesz zalowac.
Polish Notation (PN) was developed at the begin of
the 20th century in Lwów (Lemberg). At that time
a famous Polish center of mathematics and logic.
Thanks to Stalin and Churchill, Poland lost it.
PN was not invented by Lukasiewicz alone but
was a teamwork of several logicians, to handle
axiomatic investigations in formal calculi of
two- or many-valued logic. RPN, used in several
programming languages (not only by HP) is simply
the reversed or "mirrored" notation. It is totally
simple and natural, easily understood by a 7 year
old child not yet spoiled by the medievian
bracket notation of arithmetical terms.
Why then the bracket notation is still in use? The
ansnwer is simple: Our brain, if not specially
trained, doesn't like reading condensed information
- in contrast to computers. It likes it to be thinned,
similarly to our preference of thinned alcohol over
some 98%-alcohol drinks, say :-)
The bracket notation also goes slightly more conform
with the way of speaking in most natural languages,
although one can imagin other civilizations which
use a bracket-free notation throughout.
Regards Wolfgang
Piotr Balcerzak
> Piotr Balcerzak wrote:
> > Wolfgang Rautenberg wrote
> > > Get a HP49 ...
>
> To co ja ci radze, o ile posiadasz forcy.
> Najtaniey u CYNOX. Nie bediesz zalowac.
Pretty good! Where did you learn Polish?
I've been thinking about extending RAM in
my HP48G. But having 'flash' ROM would
also be nice - that why I still cannot decide
whether to stay with 48 or switch to 49.
49 seems to be more powerfull and much more
featured/sophisticated. It is very frustrating that
49's built quality is so poor.
>
[...]
>
> Why then the bracket notation is still in use? The
> ansnwer is simple: Our brain, if not specially
> trained, doesn't like reading condensed information
> - in contrast to computers. It likes it to be thinned,
> similarly to our preference of thinned alcohol over
> some 98%-alcohol drinks, say :-)
I think you are partailly right. I like 'algebraic' display.
But, despite I'm a human, I much stronger prefer RPN
for entering data. (However, I still prefer beer to 98%
alcohol...)
>
> The bracket notation also goes slightly more conform
> with the way of speaking in most natural languages,
> although one can imagin other civilizations which
> use a bracket-free notation throughout.
Well, my brain melted when I tried to use more than 5
levels of parenthesis. ;-)
'Algebraic' notation only looks 'cool' but for extensive
number crunching is 'a pain in the ass'.
>
> Regards Wolfgang
Best regards,
Piotr
Matthias Paul
> When I buyed my calculator, I wondered about the polnic notation.
> This is really uncomfortable. There seem to be only 3 possibilities
> to get away from this shit:
Autsch...
It seems you have bought the wrong calculator for your needs.
However, even if you´re used to a CAS/AOS calculator, it is very
easy to adapt to HP´s RPL (Reverse Polish Lisp), which is basically
an object oriented approach to RPN (Reverse Polish Notation) aka
UPN (Umgekehrt Polnische Notation). It will come in handy, and
you will soon find it much more natural to use and superior to an
in-line notation.
The original documentation (in particular the rather buggy German
issue) might not be the best place to start with to understand the
basic concepts, if you have never made yourself familiar with
the fundamental stack concepts found in almost any programming
language. Look out for text books on RPL, RPN/UPN, Forth, or Lisp
in the university´s library, and once you understand the idea of objects
on different stack levels, you will soon discover, what a bright
yet simple idea this actually is. I am quite sure this will also
give you a deeper insight into computers and programming as is.
In my opinion, CAS versus RPL is similar to the GUI versus CLI
paradigmn: At the first glance, the first appears to be easier and
more intuitive, but the more advanced you become, the more you
will discover all the unnatural restrictions by concept, and the
more you will miss the power of the latter.
> So, anyone has a good suggestion how to use the HP48G as
> a calculator? My Ti30X (simple, cheap calculator) is easier
> to use.
I also sometimes use simple calculators for trivial maths or
easy hex calcs, but if you are facing non-trivial problems, you
will have a hard time trying to solve them with a non-symbolic,
non-RPL based calculator. It is possible, but...
One of the things you will learn in your studies is that
it is most important to find the right algorithm and data
representation for a given problem. The concepts of RPL
are definitely a very good choice for many problems.
There is an endless lists of things on the plus side, but
only very few things, I miss in or don´t like about the
HP48G(X). And they are minor in nature and have nothing
to do with the underlaying concept, but are just due to the
old hardware technology used in the calculator.
(in no particular order)
- slow user interface response especially when working
with large objects on the stack
(it somehow reminds me of early ZX81 times, where all the
variable areas and even display data was dynamically
assigned and permanently moved around in memory to
allow it to work within just 1 Kb)
- quite huge power consumption in comparison to other
LCD calculators I use or used (TI-54, TI-56, TI-82, Astor 1
and Sharp PC1403H). Using state-of-the-art hardware
technology it could either consume much less power,
or be much faster.
- no native support for the ISO 28601/8601 international
date format ("ccyy-mm-dd")
- no Euro currency in the symbol set - I once suggested to add
this at code point 160 (Anyway, it is very excuseable, as the
symbol was not defined before 1997)
- no advanced interface port for external data devices (except
for slow 3-wire serial communications) and no means to buffer
the internal (rechargeable) batteries by connecting the calculator
to an external power supply.
- by default, no good protection for the display, that is,
no hard case (but see FAQ for solutions)
- no flashable firmware
- For faster typing with less finger force I would prefer a softer
key click similar to the keyboard feeling on my TI calculators.
Otherwise, the HP48 keyboard is very good in quality.
Some of these issues might have been solved with the HP49G
already, but from what I have heard, there was a decrease in
manufacturing quality, so i will happily stick with the HP48GX
for now.
Greetings,
Matthias
------------------------------------------------------------
Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
<Matthi...@post.rwth-aachen.de> <mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html
------------------------------------------------------------
Wolfgang Rautenberg
> I've been thinking about extending RAM in
> my HP48G. But having 'flash' ROM would
> also be nice - that why I still cannot decide
> whether to stay with 48 or switch to 49.
Flash ROM is incomparably more convenient than
any RAM card. Backup HOME is trivial on the HP49,
but needs a lot of manipulation on a HP48G with
RAM cards (mechanical write protection etc).
> 49 seems to be more powerfull and much more
> featured/sophisticated. It is very frustrating that
> 49's built quality is so poor.
I cannot confirm your claim on poor quality. My
1 year old 49 has been buisy over 1200 (!) hours
which would have cost more then 100 expensive
batteries (I use Rayovac rechargeables instead).
Keys operate smooth and relyable. The only traces
of an intensive use are that the coloured imprints
on the DonwArrow and Backspace keys are gone.
If I would have reclaimed warranty in time, CYNOX
might have given me another one. But then I had to
separate from my baby at least 15 days. That's too
much, so I kept it and I love it more than ever.
- Wolfgang
Guenter Schink
ich las von dir:
>On 2001-05-06, Joachim "Einstein" Börger wrote:
>
>> When I buyed my calculator, I wondered about the polnic notation.
>> This is really uncomfortable. There seem to be only 3 possibilities
>> to get away from this shit:
>
>Autsch...
> [ ... and some useful thoughts .... and explanations ... ]
I'd like to add, that for those of us, who have memory cards in their
4xGX, the "Metakernel" available on http://www.hpcalc.org + Erable +
ALG48 add tremendously to the overall performance. A much faster
equation writer, access to character design and some sort of CAS.
If you like to stick with your 48GX and consider to add memory cards,
have a look at http://www.cynox.de, you could buy a 128Kb and a 512Kb
card for about 90.-Euro.
Gruß Günter
Barry
news:1FFJ6.830$h%.307847@news20.bellglobal.com...
>
> 49 seems to be more powerfull and much more
> featured/sophisticated. It is very frustrating that
> 49's built quality is so poor.
I'm not sure I agree with that.
I have a 48 and a 49 and I do agree that the 48 is a much more
solid machine. But if you compare the quality of the 49 with that
of any other calculator it seems pretty solid.
I think the superb construction of the 48 makes the good
construction of the 49 seem kind of poor by comparison.
Barry
Barry
>
> Keys operate smooth and relyable. The only traces
> of an intensive use are that the coloured imprints
> on the DonwArrow and Backspace keys are gone.
I haven't used mine enough to wear off any key symbols yet but I'm
sure that'll come. Maybe we need to start thinking of ways to
replace those when they wear out.
I wonder if any you on the ACO team can give us any information on
what might stick to the keys, or at least give us some information
about the makeup of the keys so we could have that information to
use in search of a paint/plastic/whatever to replace the
characters.
Matthias Paul
> If you like to stick with your 48GX and consider to add memory cards,
> have a look at http://www.cynox.de, you could buy a 128Kb and a 512Kb
> card for about 90.-Euro.
Yes, I am using both, an original Epson/HP 128 Mb card (ca. 50,- DM in
1998) and a 2 Mb memory card (ca. 170,- DM in fall 1999), manufactured
by Mike´s EDV, Aachen, in my HP48GX. Both are very reliable, and I´m
astonished that the 128 Mb card is still working on its first 2016 battery.
Since there would be enough space for it, I only wished the battery clip of
the 2 Mb card would have been designed to hold a larger cell - the tiny
1216 battery in there was drained out after only half a year.
I am now using a 1220 cell, but I still have to wait and see if this will
at least last for the promised 1,5 year period... On the other hand, the
battery clip blade on that card gives a very tight electrical and
mechanical
contact - I have heard that on some other 3rd party cards the clip may
easily loose contact when the calc is exposed to vibrations or shocks.
BTW. The space between the two cards is large enough to hold a set of
replacement cells in a small plastic bag - just in case... A remarkable
cheap source for batteries in Germany is http://www.reichelt.de.
Speaking of batteries, after bad experiences with rechargeable NiMH
batteries from GP (very different measured capacities ranging from 380..
495 mAh even within the same production charge of nominal 500 mAh
cells), I´m now using Varta AccuPlus Ultra 600 mAh NiMH cells for the
calculator itself (measured capacities 595..610 mAh). The only backdraw
with using NiMH cells is that you always need to carry a replacement set
along with the calc, because, if you continue to use it after the battery
alarm goes on, you will not have more than 30 minutes before the
calculator dies...
Well, anyway, Joachim seems to have a HP48G instead of a GX or a G+
and he may easily run into memory shortage problems with just 32 Kb
onboard memory. On the other hand, internal memory expansions are
much cheaper than memory cards, but personally I like to ability to
physically remove the static memory from the calculator.
Greetings,
Matthias
(FWIF, I just saw a typo in my other post: I have a TI-85,
not a TI-82.)
John H Meyers
The only thing more convenient to me is not needing a battery;
the fact that it takes a complete bank erase to move or change
any information in the flash ROM is actually very inconvenient,
and the internal complexities of the OS in handling flash ROM
led to at least two dangerous bugs (now corrected).
Most users don't notice all this, but the programmers at ACO did,
and someone who tries to pack flash ROM quite full may also notice.
I find the removability of RAM cards to be more convenient
than the non-removability of flash ROM; storing into flash
is also more power consuming than storing into RAM.
> Backup HOME is trivial on the HP49,
> but needs a lot of manipulation on a HP48G with
> RAM cards (mechanical write protection etc).
My backups are identical on my 48 or 49 (using simple programs);
a port is a port is a port ...
The Filer is nice, however (and is available for 48GX too!)
Updating the ROM is actually the flashiest benefit
(sayeth an owner of an HP48G, version M, forever condemned
to remain frozen in its early 1993 infantile state :)
[r->] [OFF]
Anonymous
Do you mean [r->] [ON]?
My HP48 has no [OFF] key...
Bill Spence
Picky, picky, picky. I am not sick of John Meyers. His posts are usually
well informed and articulate.
If you are sick of him you have the option, actually the right, not to
read any of the messages he posts to this newsgroup.
I suspect that this might be one of the nicer messages that this thread
will devolve into.
Best wishes to you Joe.
bill spence
John H Meyers
Right on!
"There's no place like home.com" - Joe
Source of the expression "right on":
http://tech-two.mit.edu/Shakespeare/julius_caesar/julius_caesar.3.2.html
"For I have neither wit, nor words, nor worth,
Action, nor utterance, nor the power of speech,
To stir men's blood: I only speak right on;
I tell you that which you yourselves do know."
[Start] -> [Shut Down]
John H Meyers
HP48G Series Quick Start Guide, page 1-3:
"Turning the HP48 On and Off:
Press [ON] to turn the machine on.
Press [r->] [OFF] to turn it off.
The [OFF] key is a shifted version of the [ON] key."
[ON]+[SPC]
Piotr Balcerzak
Barry <bar...@yahoo.com> wrote in message news:3af805e7_1@goliath2...
> "Piotr Balcerzak" <bpio...@yahoo.com> wrote in message
> news:1FFJ6.830$h%.307847@news20.bellglobal.com...
> >
> > 49 seems to be more powerfull and much more
> > featured/sophisticated. It is very frustrating that
> > 49's built quality is so poor.
>
> I'm not sure I agree with that.
>
> I have a 48 and a 49 and I do agree that the 48 is a much more
> solid machine. But if you compare the quality of the 49 with that
> of any other calculator it seems pretty solid.
>
> I think the superb construction of the 48 makes the good
> construction of the 49 seem kind of poor by comparison.
>
> Barry
>
That's exactly what I meant. In the past HP was too good...
The problem is that it is very difficult for me to "downgrade"
my expectations now ;-)
Piotr
Beto
> Speaking of batteries, after bad experiences with rechargeable NiMH
> batteries from GP (very different measured capacities ranging from 380..
> 495 mAh even within the same production charge of nominal 500 mAh
> cells), I´m now using Varta AccuPlus Ultra 600 mAh NiMH cells for the
> calculator itself (measured capacities 595..610 mAh). The only backdraw
> with using NiMH cells is that you always need to carry a replacement set
> along with the calc, because, if you continue to use it after the battery
> alarm goes on, you will not have more than 30 minutes before the
> calculator dies...
Hi,
How many mAh should the batteries give in order to be used with an HP49G?
I'm think of buying a set for my personal use.
Bye!
--
Beto
Dennis Straley
>My HP48 has no [OFF] key..
Funny, mine doesn't even have a [r->] key :)
"A man cannot step into the same river twice, for neither is it the same man
nor the same river" - Heraclitus
"Indeed, he cannot step into it even once" - Some up and coming rabble-rouser
who was listening
Dennis
[a green key that looks very much like a right arrow but clearly has no 'r' on
it] [another key which is marked ON, unless you look very closely above it, it
has a couple of other marks, but you know what I mean by ON anyway...]
Wolfgang Rautenberg
> > Backup HOME is trivial on the HP49,
> > but needs a lot of manipulation on a HP48G with
> > RAM cards (mechanical write protection etc).
>
> My backups are identical on my 48 or 49 (using simple programs);
> a port is a port is a port ...
I mean a s a f e backup, protected against crashes
(clearly a necessity for a SysRPL programmer). Maybe
you've got a Ramcard delux whose write protection can
be controlled via program. I've only a cheap Ramcard
from CYNOX whose write protection can be activated or
deactivated only by opening the HP48GX card box :-)
> The Filer is nice, however (and is available for 48GX too!)
IMHO, a Filer is not needed on the HP48. Or do you have
a 48-Filer which not only reads the contents of a write-
protected RAM card but outwits its write protection for
data exchange?
Regards Wolfgang
John H Meyers
> (clearly a necessity for a SysRPL programmer). Maybe
> you've got a Ramcard delux whose write protection can
> be controlled via program. I've only a cheap Ramcard
> from CYNOX whose write protection can be activated or
> deactivated only by opening the HP48GX card box :-)
Is there write protection on Port 2 in HP49?
I have read in this newsgroup where people have reported
trashing of objects stored in Port 2, regardless of the theory
of how hard this might be to accidentally happen, though
I have not done it myself (not by hangs or TTRMs, anyway).
Conversely, I never lose covered ports ( > 1 ) in my HP48
RAM cards, so I keep write-protect switch on only for Slot 1,
except when I want to protect against my own deliberate
but erroneous purging and storing ;)
I imagine that some people have managed to wipe out a high port,
but does everyone remember Dave or Jim explaining how hard
that would be to do on a 48?
Of course, if you keep a "port-to-port card copier" program
around, and accidentally execute it yourself...
BTW, in Emu49, if you accidentally cause writing
to port 2, then you can't undo it -- it's written
into file rom.e49 -- but you can make that read-only
on the computer, as opposed to being unable
to make it read-only in the actual calculator.
> IMHO, a Filer is not needed on the HP48.
Wasn't there an MK (with a filer) for HP48?
Why do we "need" it on a 49 but less so on a 48?
Aside from the all-important CAS (with its EQW),
and added details like hold/long/double... key assignments,
what's the great difference between a 48 and a 49,
and how does that impact needing/not needing a filer?
> Or do you have a 48-Filer which not only reads the contents
> of a write-protected RAM card but outwits its write protection
> for data exchange?
I don't understand the argument; somehow I manage to treat my
HP48 and 49 exactly the same (with virtually identical programs
on them), including for making backups into high ports,
and I have not heard exactly why it was any more impossible
to unintentionally write into flash than to write into covered HP48
ports (but both impossibilities are reported by some people).
I'd be happy to hear why the previously posted experiences
of others were unrepresentative of reality, if they were.
It even seems to me that flipping a card switch was extremely
easy on a 48, and afforded a more absolute level of write
protection there than a 49 can offer, since even UserRPL
PURGE and STO can not be prevented from acting on port 2
in a 49, but can be prevented (by a proper RAM card)
from acting on ports in a 48.
Somehow I think that you have a different perspective, however,
as we always seem to be on opposite sides of some kind of
wall or curtain -- or maybe it's just the
astrological difference between our time zones
(especially as regards the planet Saturn :)
Caspar Lugtmeier & Eva Skotarczak
Filer and the Matrixwriter (hate that it doesn't have a VEC toggle).
Being a structural engineer I do not care a lot about the Equation Writer,
nor about a CAS.
To me it looks like all these people who are "into" the CAS are mathematics
students?
(or is structural engineering so easy compared to other fields? hmmm.....)
Caspar
--
"Wolfgang Rautenberg" <ra...@math.fu-berlin.de> wrote in message
news:3AF900A7...@math.fu-berlin.de...
Barry
news:4875379A46BDD311824...@epnews.Eaglepoint.com..
.
>
> Hi,
> How many mAh should the batteries give in order to be used with
an HP49G?
>
> I'm think of buying a set for my personal use.
mAh is a measure of how much charge the battery takes. It tells
you something about how long it will hold a charge and also how to
charge it.
You can use any of the AAA batteries in the 49. but the higher
it's mAh capacity, the longer it will go without recharging.
Barry
Mark Richardson
wrote:
>Hi!
>
>When I buyed my calculator, I wondered about the polnic notation. This
>is really uncomfortable. There seem to be only 3 possibilities to get
>away from this shit:
>
>1. Using the equation writer. This cost A LOT OF time and I always
>have to manually say "go into algebraic mode" and finally press the
>EVAL-Button.
>
>2. Using the algebraic mode by pressing the '-Key. This ist fast, but
>not more comfortable then the equation-writer: First I have to press
>the '-Key, than type in my math. expression, press ENTER and EVAL. Not
>comfortable, too.
>
>3. Using a algebraic-simulator. I've found 2 programme: "algebraic
>calculator" and "calc III". the algebraic calculator is much to slow,
>and with calc III, I can not use "(" or the equation-writer. Calc III
>has some bugs, too.
>
>So, anyone has a good suggestion how to use the HP48G as a calculator?
>My Ti30X (simple, cheap calculator) is easier to use.
>
>Joachim
>
4. Learn to use Polish notation!
It really is quite easy and natural once you get the hang of it - I
always make mistakes and strugle when using a non RPN calculator now.
The great thin about RPN on the 48 is you actually see the stack
making it even easier to learn.
Mark
--------------------------------------------
Mark Richardson. m.rich...@utas.edu.au
Member of SMASH
(Sarcastic Middle-aged Atheist with a Sense of Humor)
--------------------------------------------------
Claus Futtrup
> 1 year old 49 has been buisy over 1200 (!) hours
That's amazing since 1200 hours / 8 hours a day = 150 days.
Best regards,
Claus Futtrup
Steen S. Schmidt
> featured/sophisticated. It is very frustrating that
> 49's built quality is so poor.
I think the build quality of the HP49G is at least as good as the HP48. I
have dropped my HP49G twice on the floor, without it even stopping to
calculate. Mine has probably been on for about 1600-2000 hours (got it when
it was released), all keys are still pristine, the screen has no scratches,
the serial port works fine, and nothing is wrong with it.
Regards
Steen
Joachim Börger
> IFERR INPUT THEN 0 MENU DROP2 ELSE 0 MENU
> OBJ\-> DUP EVAL END \>> 'ALG' STO
Hm, that does not work. I hope I used in your code correctly - I typed
in everything except the \.
When I press ALG and type in, for example, 5+8 ENTER, it says:
"Invalud Syntax" :-(
Joachim
Barry
shifted minus sign), not the greater than and less than sign.
Barry
"Joachim Börger" <eins...@gmx.net> wrote in message
news:0fijftovnunou51j5...@4ax.com...
Sean Richards
Appears to work OK on my 48G. Why anyone would want to do it is another matter entirely!
Sean
John H Meyers
> When I press ALG and type in, for example, 5+8 ENTER,
> it says: "Invalud Syntax" :-(
Just to review how programs are represented in these posts
(also known as "Ascii translation mode 3"):
To post "special characters" in ascii text,
special "backslash symbols" are used:
\<< \>> Program delimiters
\-> Right-arrow *character* (not cursor key)
Finally, the second string "''" in the program must be
a string containing *two* single-quote characters
(generated using the ['] key on the HP48).
If you recall the correctly entered program to the stack
(on the HP48, not HP49) and perform the commands BYTES HEX,
the size should be 109 and the checksum should be #C58Eh
When you use the program, the two single-quote characters
should already appear, and what you then type gets inserted
*between* these two characters, automatically creating
an algebraic expression like this: '5+8'
If you left out the quote characters from the program string
(or the number 2 in the list, which initially positions the cursor
during INPUT), then this might not have worked for you.
----- Original message -----
"The HP49 ALG mode simulator for the HP48 (junior edition)"
\<< -55 CF 28 MENU "" { "''" 2 ALG V }
IFERR INPUT THEN 0 MENU DROP2 ELSE 0 MENU
OBJ\-> DUP EVAL END \>> 'ALG' STO
Good luck (and try RPN some time, too!)
David Haguenauer
In a way, yes, since flash chips need a special pin to be activated with
the appropriate voltage to allow write operations. The fact that
erasing/reorganizing a bank is a slow process allows the user to find out
when something goes wrong.
>I have read in this newsgroup where people have reported
>trashing of objects stored in Port 2,
I had such unexplained losses, but they weren't (in my case) subsequent to
SysRPL crashes. I think they were caused by the bug that came with an
early version of the HP49's system. With the latest ROM (at least), I
never lost anything from any port other than port zero, despite a few
crashes (provoked by me, needless to say, although I have some doubts
about EDITG).
>Conversely, I never lose covered ports ( > 1 ) in my HP48
>RAM cards, so I keep write-protect switch on only for Slot 1,
>except when I want to protect against my own deliberate
>but erroneous purging and storing ;)
It happened to me *several times* to lose the contents of a protected RAM
card in port 1 of a HP48GX.
>It even seems to me that flipping a card switch was extremely
>easy on a 48, and afforded a more absolute level of write
>protection there than a 49 can offer, [...]
From my impatient point of view, switching a RAM card ro/rw was extremely
hard, because it required a reboot. In my experience, the HP49's port 2
has been more reliable than a write-protected RAM card in port 0.
David Haguenauer
http://zap.to/hsimpson
Gary Sutherland
manipulation than the TI-89. The real beauty of a CAS is really in writing
equations and algorithms, rather than just solving them.
Gary S.
"Guenter Schink" <g.sc...@tronet.de> wrote in message
news:45gfft4gigp30b81h...@4ax.com...
Heiko Arnemann
"John H Meyers" <jhme...@miu.edu> schrieb:
> Here's a temporary crutch:
>
> \<< -55 CF 28 MENU "" { "''" 2 ALG V }
> IFERR INPUT THEN 0 MENU DROP2 ELSE 0 MENU
> OBJ\-> DUP EVAL END \>> 'ALG' STO
Hallo,
I tried it on HP49G and it fails, because the 2 in the list is interpreted as integer,
while a real number is required.
It would be nice, if INPUT (and may be some other commands) would
exept both: integer and real on HP49G? (Compatibility and ease of use)
regards
Heiko
John H Meyers
| \<< -55 CF 28 MENU "" { "''" 2 ALG V }
| IFERR INPUT THEN 0 MENU DROP2 ELSE 0 MENU
| OBJ\-> DUP EVAL END \>> 'ALG' STO
> I tried it on HP49G and it fails,
> because the 2 in the list is [an integer object type],
> while a real number is required.
The fundamental problem is an incorrect mode during program
transfer, not during its later execution, and this issue
is ultimately too general to be solved by any isolated
adjustments to particular functions such as INPUT.
I.e. the ability of *some* functions to convert *some*
exact integer arguments to approximate reals can not be
extended to make *all* programs give identical results
with arbitrary-type number objects (e.g. consider the TYPE
command itself, or VTYPE, POS, SAME, math operators, etc.,
and of course very different speed results with START, FOR, etc.)
Example: \<< 1 4 / \>>
On the HP48, if this is how the program looks when displayed,
the "1" and "4" can only be real numbers,
and the answer can only be the real number 0.25
On the HP49, if this is how the program looks when displayed,
the "1" and "4" are not real numbers, but are integers,
and the result of the program (if flag -3 is clear)
must be '1/4' (symbolic expression), not 0.25 (real number).
How can the HP49 guess whether the text \<< 1 4 / \>> was originally
an HP48 program or an HP49 program, and interpret it accordingly,
so that it acts the way it was meant to act on its original source?
The answer is: It can't.
It's up to *you* to tell the HP49, in advance, which calculator model
this program was written for or generated by, so that the HP49
can make the proper interpretation of decimal digit strings
into the appropriate object type.
Due to the fact that the "ascii header line" used for
automatic program transfers in text form was not augmented
to be completely automatic at the HP49 end, you must
*manually* set the proper mode in the *receiving* calc
*before* receiving any text program, unless that text program
is completely free of any digit strings without decimal points
attached.
This chart attempts to concisely explain
(view in constant-width font, not pretty font :)
HP48 HP49
Sending realX realN realX realN integer
(examples) 1.23 45 1.23 45. 67
Receive on 48 real real real real real
(or 49 Approx)
Receive on 49 real integer real real integer
(Exact only)
From the above, you can see that to faithfully interpret
an HP48 program, sent as text to an HP49, without risk of
changing the type of some originally real-valued numbers
to exact integer type, the HP49 must be in Approximate mode.
Likewise, to faithfully interpret an HP49 program,
sent as text to another HP49, without risk of
changing the type of some original exact integers
to approximate real-type, the HP49 must be in Exact mode.
"Ay, there's the rub" (Hamlet 3:1)
http://web.uvic.ca/shakespeare/Library/SLTnoframes/literature/texts+1.html
[speaking of alteration during translation :}
When sending an HP49 program as text to an HP48,
any exact integers will inevitably revert to real object type;
other incompatible commands and syntax may also not be understood.
> It would be nice, if INPUT (and maybe some other commands)
> would accept both integer and real on HP49G?
The general automatic conversion of exact integer arguments
to approximate real is localized to very particular
"argument dispatching" functions, and occurs only
when no distinction need ever be made between the types
(also not when the arg is only a component of an expected list arg).
If you're lucky, maybe INPUT is amenable to an easy adjustment,
but in general you must know a user program's true origin,
and tell the HP49 accordingly *before* transfer,
to assure proper compilation and subsequent proper function.
Sometimes you can "get away with" sloppy translation,
perhaps paying only in additional execution time,
but other times you can't, so watch your step!
> Compatibility
That's the whole issue; the extra new object types and their
different *display* conventions on the HP49 vs. the HP48
generate the need to set the interpretation mode *before*
compilation, since correction *after* compilation
is inevitably less possible in many cases.
> and ease of use
The original HP48 program transfer system
used a very complete special "header line"
to tell the receiving calculator's text compiler
*all* of the interpretation modes it had to use
to properly interpret any programs that were conveyed in text form
(so that the receiving calc never needed to be manually set).
E.g. %%HP: T(3)A(D)F(.);
The "Translation mode" specifies whether to output and then
re-interpret "backslash escapes" (e.g. \<< \>>) and whether to
add/strip <cr> at end of lines; the "Angle mode" specifies how
to display and then re-interpret angles in cylindrical/spherical
coordinates, and the "Fraction mark" specifies what character
represents the "decimal point" (which also determines
the "argument separator" in algebraics).
The HP49 added one more mode (Exact/Approximate), which it is
very necessary for the compiler to know to make its proper
interpretation, but there is *no* corresponding addition
to the "header line" to specify it, which leaves you
having to worry about setting it yourself, in the receiving HP49
(or before you manually type the program, which is equivalent).
If any more "letter options" had been inserted *after* %%HP
in this header line, then when the HP49 transmitted programs,
any HP48 would have detected it as an error.
Assuming that HP may not have wanted to make it impossible
to transfer compatible HP49 user programs back to the HP48,
that wouldn't have been a good idea.
However, try copying this to a file and transferring it
to your HP48 *or* HP49 using Kermit:
Greetings! %%HP: T(3)A(D)F(.);
\<< "Hello, world!" \>>
Does the file transfer correctly to your calc, 48 or 49,
without being at all disturbed by the word *before* %%HP ?
If so, then that's where an HP49 could insert something special,
to say "automatically set yourself to Exact mode,"
which is what it should by default say for every file
which it sends in ascii text form, since that is the mode
which the receiving HP49 needs, to guarantee correct interpretation,
as we saw above.
A person editing manually, however, could then specify to use
Approximate mode instead, if posting an HP48 program;
alternatively, the mere presence of the %%HP header
*without* any prefix could also be presumed to be
a signal to interpret the text in Approximate mode,
which would then automatically take care of all 48 -> 49 transfers.
That would have been okay if done before the first units
were commercially released, but now that your HP49 (and mine)
still don't generate any prefix, this would make it difficult
to adopt the above convention, which would then make direct
transfers from *our* unupdated HP49s be treated just like
output from an HP48, and thus be inappropriately compiled
(stick a "Microsoft" label on it, however, and call the
text language "Java," and it would become okay :)
Assuming that the above inserted word before %%HP did not
affect the ability to download the file, we could still
always take the liberty ourselves of inserting "Exact"
or "Approximate" into our manually edited files,
just to give folks a hint of what mode they need to set manually,
and then this question need not come up again :)
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
Heiko Arnemann
> The fundamental problem is an incorrect mode during program
a very large text snipped.
> just to give folks a hint of what mode they need to set manually,
> and then this question need not come up again :)
Sorry, John
I need to work through your detailed mail. Hopefully I will understand.
No, time up to Sunday.
Many thanks.
Best regards
Heiko
John H Meyers
Maybe it should have been shorter:
The text that *represents* user programs (not the programs themselves)
is just slightly incompatible between HP48 and HP49:
To distinguish approximate real number objects
from exact integer objects, the HP49 requires that a decimal point
appear with all approximate real number objects, and requires
that a decimal point *not* appear with exact integer objects
(e.g. 123. is an approximate real, 123 is an exact integer),
and that's how it always displays things.
The HP48 had no such thing as an exact integer object, and it therefore
displayed or compiled real numbers either with or without decimal
points (e.g. 123.456 and 123 are both real number objects on HP48),
treating them all the same.
The above two conventions are clearly incompatible, so if any user
program, when shown as text, contains numbers without decimal points,
and if you are going to send or type the program into an HP49,
you have to decide in advance which way to interpret it:
The HP48 way ("Approximate" mode):
All numbers, with or without decimal points,
are interpreted as "real number" objects (type 0).
The HP49 way ("Exact" mode):
Numbers with decimal points are all approximate real (type 0);
numbers without decimal points are all exact integers (type 28).
Sometimes a program interpreted the "wrong" way works anyway, e.g.
2 MENU and 2. MENU both display the VAR menu.
Other times, a program interpreted the "wrong" way won't work, e.g.
"" { "xx" 2 } INPUT won't work unless "2" is changed to "2."
If you set the HP49 to Approximate mode before sending it this
program text, then the compiler interprets "2" as "2." anyway,
which is what you should do in general before loading or typing
HP48 user programs in text (ascii) form.
If a numeric original command or function argument is *required*
to be a real number, but an exact integer is supplied instead,
an automatic conversion (I->R) conveniently takes place in the HP49,
saving you from worrying about the object type in many cases
(or sparing you from needing to press the decimal point key).
However, this service is offered only at the point where the
*original* stack arguments are being checked for their types --
note here that a list { ... } is a valid type of argument for the
INPUT command; therefore that's the end of argument type checking,
and that's also the end of the "amnesty," where some commands might
tolerate a wrong original type of number as an individual argument.
Therefore, nothing was wrong with the INPUT command;
what was wrong was that a program displayed on (or for) an HP48,
where some real numbers were shown without decimal points,
was loaded into an HP49 in Exact mode, where numbers without
decimal points were compiled into new object type 28, which is
not valid inside the list supplied to the INPUT command.
The needed correction is to set the proper HP49 mode before
transfering ascii programs (or typing them):
For HP48 program text: set Approximate mode before transfer.
For HP49 program text: set Exact mode before transfer.
If you forgot to set approximate mode (HP48 mode), you can correct
the mistake after the fact: just set approximate mode now,
then EDIT the program again -- even though you make no changes,
numbers are re-interpreted when you press ENTER,
and all the numbers become real (type 0) this time.
If you forgot to set Exact mode (HP49 mode) and had typed
the text in by hand, you may be able to change to Exact mode now
and recover the saved original text from the shifted CMD function;
otherwise you'll need to transmit the original text again.
Hmm.. maybe this was not shorter -- but was it any clearer?
Heiko Arnemann
John, thank you for the detailed work through. A lot of important hints.
"John H Meyers" <jhme...@miu.edu> schrieb
> A specific *HP48* program was posted:
> | \<< -55 CF 28 MENU "" { "''" 2 ALG V }
> | IFERR INPUT THEN 0 MENU DROP2 ELSE 0 MENU
> | OBJ\-> DUP EVAL END \>> 'ALG' STO
> The fundamental problem is an incorrect mode during program
> transfer, not during its later execution, and this issue
> is ultimately too general to be solved by any isolated
> adjustments to particular functions such as INPUT.
I understand, that if I need to type in a HP48G-program on the
HP49G, it is recommanded to switch to approx-mode.
> I.e. the ability of *some* functions to convert *some*
> exact integer arguments to approximate reals can not be
> extended to make *all* programs give identical results
> with arbitrary-type number objects (e.g. consider the TYPE
> command itself, or VTYPE, POS, SAME, math operators, etc.,
> and of course very different speed results with START, FOR, etc.)
Yes, but I expected that the INPUT command would accept the integer
in the list, like + and - accept complex numbers. In the AUG it is clearly stated
that a real is required.
> From the above, you can see that to faithfully interpret
> an HP48 program, sent as text to an HP49, without risk of
> changing the type of some originally real-valued numbers
> to exact integer type, the HP49 must be in Approximate mode.
Great job, they have thougt about the problem.
> Greetings! %%HP: T(3)A(D)F(.);
> \<< "Hello, world!" \>>
I tried it with my HP49G, it nice experience to see what happens,
and to have the knowledge to avoid typing it (if posted correctly
in the NG). Up to now I did not take care about the ascii convention
when I have posted here (e.g. << instead of more correct \<<).
Ok, let us keep in mind that there is a new object in the HP49G, the
integer and misuse could become a trap ;-)
Best regards
Heiko
Heiko Arnemann
> *original* stack arguments are being checked for their types --
> note here that a list { ... } is a valid type of argument for the
> INPUT command; therefore that's the end of argument type checking,
> and that's also the end of the "amnesty," where some commands might
> tolerate a wrong original type of number as an individual argument.
A very short passage snipped ;-)
> Hmm.. maybe this was not shorter -- but was it any clearer?
Wunderfull, completly clear.
Thanks again, and sorry for my delayed answer, I was on travel.
...Heiko