Hello,

My name is Karan and i'm back to the news group after about 8 years.
I'm back to studying maths so i did some archeology and resurected my
HP48GX.
I wanted to ask you 3 small things:

1- For two days the row if keys {.,2,5,8,EEX,SQRT,<-,VAR,D} was not
working at all. I found that strange and i couldn't find a reason for
such a symetric misfunction. However through time all the keys but the
2 key became Ok. The 2 key only works if i keep it pressed for some
secs. Which means there is no a mechanical issue. I don't know if any
of you guys have seen such a thing before.
I have assingned number 2 to another key (SPC) in order to be able to
use such an important number. But i hope its just some after coma
sleep effects and will be Ok.

Most amazing is that all the libraries i had in my RAM cards are still
there.

2- At the time i was using my calc there were not USB ports. My
computer has only USB. I wonder if there is any way to conect the calc
to the computer.

3- Is it worth to shift to the HP50g? My calc has a MK rom card and
ALG48 + all the cool stuff... Someway i dont like the idea of using an
machine that simulates Saturn instead of a real Saturn one.

Thank you so much and I'm glad to be with you again.
I will try to update myself to the news group in the coming weeks.

On Jul 11, 9:18=A0am, Karan <aryaka...@gmail.com> wrote:
> Hello,
>
> My name is Karan and i'm back to the news group after about 8 years.
> I'm back to studying maths so i did some archeology and resurected my
> HP48GX.  I wanted to ask you 3 small things:

The HP48GX is such a beautiful calculator - I can understand why you
want to stay with it.  Anyway:

1.  The key problem you describe happened with some of the HP49G+
calculators.  The users here said that they fixed it by moving the
keys back and forth with lots of pressure.  That sounds like a contact
oxidation problem or something like it.

2.  There are serial-to-USB converters widely available.  Perhaps
someone here could recommend a brand name.

3.  Advantages to the HP49G+/50G :

- Despite the emulator, it's 3-5 times faster than a 48.
- The flash memory is not affected by crashes and never needs
batteries.
- The SD card is perfect for backing up everything you have and it's
great for transfers to the PC.
- If you use SysRPL at all, the basic commands and compiler are built
right in.
- The cursor keys are separate, so you don't have to go in and out of
alpha mode.
- The new screen is 80 pixels in height.
- USB transfers are much better than the serial port method.

Those are just a few that came to mind and I'm sure there are many
more.

Bill

On Jul 11, 4:10=A0pm, Bill Markwick <bd...@torfree.net> wrote:
> On Jul 11, 9:18=A0am, Karan <aryaka...@gmail.com> wrote:
>
> > Hello,
>
> > My name is Karan and i'm back to the news group after about 8 years.
> > I'm back to studying maths so i did some archeology and resurected my
> > HP48GX. =A0I wanted to ask you 3 small things:
>
> The HP48GX is such a beautiful calculator - I can understand why you
> want to stay with it. =A0Anyway:
>
> 1. =A0The key problem you describe happened with some of the HP49G+
> calculators. =A0The users here said that they fixed it by moving the
> keys back and forth with lots of pressure. =A0That sounds like a contact
> oxidation problem or something like it.
>
> 2. =A0There are serial-to-USB converters widely available. =A0Perhaps
> someone here could recommend a brand name.
>
> 3. =A0Advantages to the HP49G+/50G :
>
> - Despite the emulator, it's 3-5 times faster than a 48.
> - The flash memory is not affected by crashes and never needs
> batteries.
> - The SD card is perfect for backing up everything you have and it's
> great for transfers to the PC.
> - If you use SysRPL at all, the basic commands and compiler are built
> right in.
> - The cursor keys are separate, so you don't have to go in and out of
> alpha mode.
> - The new screen is 80 pixels in height.
> - USB transfers are much better than the serial port method.
>
> Those are just a few that came to mind and I'm sure there are many
> more.
>
> Bill

Thank you so much Bill.

It did work by pressing hard.
Certainly the HP50 looks much better stuff than the 49. Still i wonder
if one day they will produce another RPN processor, or if any is still
produced nowadays in the world.
I have the old 48 fully back to operating capabilies, anyways i will
consider an HP50 to make my life easier.

"Karan" <aryakaran@gmail.com> schrieb im Newsbeitrag 
news:98b7dfc8-ea92-4e2e-accc-0622187038d6@j12g2000vbl.googlegroups.com...
On Jul 11, 4:10 pm, Bill Markwick <bd...@torfree.net> wrote:
> [..]
> I have the old 48 fully back to operating capabilies,
> anyways i willconsider an HP50 to make my life easier.
>
Meanwhile, you could try SpeedUI for the HP-48GX,
which will accelerate and enhance all UI components,
including Choose boxes and input forms,
and add some features which were
not available on the HP-48 before,
neither built-in nor with the old MK.

SpeedUI is available on www.hpcalc.org

HTH

Raymond

On Sat, 11 Jul 2009 08:18:28 -0500, Karan wrote:

> Is it worth to shift to the HP50g? My calc has a MK rom card and
> ALG48 + all the cool stuff... Someway i dont like the idea of using
> a machine that simulates Saturn instead of a real Saturn one.

Being already familiar with MK etc. will be a head start with HP50G,
which has it all built in, along with much more free memory for yourself.

The Saturn emulator is running the original ROM code from the HP48,
for almost all of the original calculations and functions,
and thus is obtaining the identical results -- most of us
can not actually get inside any on-board chip
and see any difference between the results of the individual instructions
when executed inside a custom CPU chip originally manufactured by HP,
vs. the absolutely identical results of the same instructions,
when carried out by an exact emulator of that chip,
no matter what platform it runs on.

For example, I use the EMU48 program to emulate either an HP48GX
or an HP50G on my PC under Windows -- despite the fact that
there is no actual Saturn processor on my PC motherboard,
every operation and every result is identical to the original hardware,
because this emulator uses the same original ROMs as those calculators,
giving identical end results, except for being many times as fast.

[r->] [OFF]

On Jul 11, 7:51=A0pm, "John H Meyers" <jhmey...@nomail.invalid> wrote:
> On Sat, 11 Jul 2009 08:18:28 -0500, Karan wrote:
> > Is it worth to shift to the HP50g? My calc has a MK rom card and
> > ALG48 + all the cool stuff... Someway i dont like the idea of using
> > a machine that simulates Saturn instead of a real Saturn one.
>
> Being already familiar with MK etc. will be a head start with HP50G,
> which has it all built in, along with much more free memory for yourself.
>
> The Saturn emulator is running the original ROM code from the HP48,
> for almost all of the original calculations and functions,
> and thus is obtaining the identical results -- most of us
> can not actually get inside any on-board chip
> and see any difference between the results of the individual instructions
> when executed inside a custom CPU chip originally manufactured by HP,
> vs. the absolutely identical results of the same instructions,
> when carried out by an exact emulator of that chip,
> no matter what platform it runs on.
>
> For example, I use the EMU48 program to emulate either an HP48GX
> or an HP50G on my PC under Windows -- despite the fact that
> there is no actual Saturn processor on my PC motherboard,
> every operation and every result is identical to the original hardware,
> because this emulator uses the same original ROMs as those calculators,
> giving identical end results, except for being many times as fast.
>
> [r->] [OFF]

Thank you all guys. Im getting my old monster fit again and I will
consider to get one HP50G soon.

On Jul 11, 3:15=A0pm, Karan <aryaka...@gmail.com> wrote:
>
> Thank you all guys. Im getting my old monster fit again and I will
> consider to get one HP50G soon.

The 50g is certainly a nice machine, and probably the most capable
calculator on the market right now. However, the 48G/S beat it hands
down in terms of usability. The obvious difference is the keyboard
stiffness - the 50g is nowhere near as bad as the 49g, mind you, but
there's definitely a different feel to it compared to a 48. The arrow
keys are particularly stiff. Furthermore, the intuitiveness of the
keyboard and menu layouts on the 50g isn't even close to the 48
series. Whoever decided that CST should be a shifted function needs to
be restaffed in the facilities maintenance division! Likewise to the
bright individual that hid the old stat/plot/IO/lib/etc. soft key
menus so that you have to do weird user key bindings or custom menu
entries to pull them up...

That being said, the software on the 50g is extremely capable, and
programs run MUCH faster than on the 48. But for interactive number
crunching, I find the 48 to be much more pleasurable to use. In short,
they're both great, but you'll have to decide which one better fits
your priorities.

-Dave Britten

On 11 jul, 21:28, Dave <davidbr...@gmail.com> wrote:
> On Jul 11, 3:15=A0pm, Karan <aryaka...@gmail.com> wrote:
>
>
>
> > Thank you all guys. Im getting my old monster fit again and I will
> > consider to get one HP50G soon.


And some of you has something to say about the programs for 48G.?
There will be any reazon to not use it in the 50G?

Xtian

On Sat, 11 Jul 2009 20:28:22 -0500, Dave Britten wrote:

> Whoever decided that CST should be a shifted function
> needs to be restaffed in the facilities maintenance division!

> Likewise to the bright individual that hid the old stat/plot/IO/lib/etc.
> soft key menus so that you have to do weird user key bindings
> or custom menu entries to pull them up...

All valid, for those who care enough to read their manuals
(and the originals, for the original series),
to find out and appreciate the immensely well thought out original features
which enable one to get the most out of these marvelous products,
but it is remotely possible
that there are ever fewer of those people
(even when considering their teachers)
actually in the current market,
leaving most of the original knowledge to be expressed,
if at all, only by those of the earlier generation
who provided all the ready-made software that you can just download,
rather than take the initiative to create.

-[ ]-

Anyways I'm so glad HP is doing nice calculators again. The HP35s also
looks quite decent.
I hope to see new models even better in the coming years.

On Jul 12, 6:20=A0am, Karan <aryaka...@gmail.com> wrote:
> Anyways I'm so glad HP is doing nice calculators again. The HP35s also
> looks quite decent.
> I hope to see new models even better in the coming years.

The 35s is pretty good, overall. It's got a few software bugs that may
or may not cause issues for you - certain trig functions lose
precision for values very close to 90 or 0 (only 6 significant figures
for 1E-7, according to this data from the 33s:
http://www.thimet.de/CalcCollection/Calculators/HP-33S/Contents.htm),
and it's possible to write a program that gets the calculator stuck in
an infinite loop, forcing you to pop the batteries and lose all
memory. Number bases are a pain to work with, as you have to add the
appropriate base suffix (b, h, o) for anything that isn't a decimal
number, adding 3 extra keystrokes for every non-decimal number you
enter. It's perfectly functional, but irritating.

My main gripes are display-related. Numbers with a 12-digit mantissa,
and a 2-digit exponent don't fit completely on the display, and you
have to scroll right to read the complete exponent. You can prevent
this by using FIX/SCI/ENG with an appropriate precision. The screen
could also use a few physical improvements. The bezel comes to a very
pronounced corner, about 1mm out from the screen surface, and blocks
the lower portion of the display when viewed at a sharp angle, i.e. on
a desk. The Pioneer models had a nice, shallow bevel around the screen
to prevent this. Note that this isn't an issue when held in a hand, or
otherwise viewed more straight-on. Also, the glossy screen of the 35s
tends to scratch rather easily.

But in spite of those issues, the 35s has probably the nicest-feeling
keyboard HP has produced in the past 10 or 15 years, in my opinion. As
far as I'm concerned, they keyboard alone makes it worth owning. The
layout is pretty good, too, although Swap and Roll-Down could stand to
be closer to Enter and the numeric keys, and R/S should go where Sigma
+ is. Fairly minor points of contention, of course.

-Dave Britten

On Jul 12, 8:16=A0pm, Dave <davidbr...@gmail.com> wrote:
> On Jul 12, 6:20=A0am, Karan <aryaka...@gmail.com> wrote:
>
> > Anyways I'm so glad HP is doing nice calculators again. The HP35s also
> > looks quite decent.
> > I hope to see new models even better in the coming years.
>
> The 35s is pretty good, overall. It's got a few software bugs that may
> or may not cause issues for you - certain trig functions lose
> precision for values very close to 90 or 0 (only 6 significant figures
> for 1E-7, according to this data from the 33s:http://www.thimet.de/CalcCo=
llection/Calculators/HP-33S/Contents.htm),
> and it's possible to write a program that gets the calculator stuck in
> an infinite loop, forcing you to pop the batteries and lose all
> memory. Number bases are a pain to work with, as you have to add the
> appropriate base suffix (b, h, o) for anything that isn't a decimal
> number, adding 3 extra keystrokes for every non-decimal number you
> enter. It's perfectly functional, but irritating.
>
> My main gripes are display-related. Numbers with a 12-digit mantissa,
> and a 2-digit exponent don't fit completely on the display, and you
> have to scroll right to read the complete exponent. You can prevent
> this by using FIX/SCI/ENG with an appropriate precision. The screen
> could also use a few physical improvements. The bezel comes to a very
> pronounced corner, about 1mm out from the screen surface, and blocks
> the lower portion of the display when viewed at a sharp angle, i.e. on
> a desk. The Pioneer models had a nice, shallow bevel around the screen
> to prevent this. Note that this isn't an issue when held in a hand, or
> otherwise viewed more straight-on. Also, the glossy screen of the 35s
> tends to scratch rather easily.
>
> But in spite of those issues, the 35s has probably the nicest-feeling
> keyboard HP has produced in the past 10 or 15 years, in my opinion. As
> far as I'm concerned, they keyboard alone makes it worth owning. The
> layout is pretty good, too, although Swap and Roll-Down could stand to
> be closer to Enter and the numeric keys, and R/S should go where Sigma
> + is. Fairly minor points of contention, of course.
>
> -Dave Britten

well, maybe again i should stick to my old HP32sii, which looks quite
scratched but works fine

On 11 Jul., 19:51, "John H Meyers" <jhmey...@nomail.invalid> wrote:
> On Sat, 11 Jul 2009 08:18:28 -0500, Karan wrote:
> > Is it worth to shift to the HP50g? My calc has a MK rom card and
> > ALG48 + all the cool stuff... Someway i dont like the idea of using
> > a machine that simulates Saturn instead of a real Saturn one.
>
> Being already familiar with MK etc. will be a head start with HP50G,
> which has it all built in, along with much more free memory for yourself.
>
> The Saturn emulator is running the original ROM code from the HP48,
> for almost all of the original calculations and functions,
> and thus is obtaining the identical results -- most of us
> can not actually get inside any on-board chip
> and see any difference between the results of the individual instructions
> when executed inside a custom CPU chip originally manufactured by HP,
> vs. the absolutely identical results of the same instructions,
> when carried out by an exact emulator of that chip,
> no matter what platform it runs on.
>
> For example, I use the EMU48 program to emulate either an HP48GX
> or an HP50G on my PC under Windows -- despite the fact that
> there is no actual Saturn processor on my PC motherboard,
> every operation and every result is identical to the original hardware,
> because this emulator uses the same original ROMs as those calculators,
> giving identical end results, except for being many times as fast.
>
> [r->] [OFF]

Hello John,

unfortunately the truth is a little bit more complicated ;-)

I can assure you that the state of the carry flag (inside the
processor) is not always the same as in EMU48 and the Saturnator of
the 49G+/50G.

Take the following code snipplet for example (which is used in my
TreeBrowser to accelerate LAM access from inside machine code and runs
as a PCO from the reserved RAM which is not used by the system at that
time)

        LC(5)   =3DTEMPENV
        CD0EX
        A=3DDAT0  A
        D0=3D(5)  _DnA % address of the LAM
        GOTO    GetlamEVAL

Now the GOTO jump to GetlamEVAL fetches the LAM and executes it. If
you only need to make a short jump (which is the case here) and if you
know the state of the carry flag one could use a GONC instead of a
GOTO. The result is shorter code (1 nibble less because a GONC/GOC is
encoded with 3 nibbles, a GOTO with 4 nibbles) and faster code.

However this only works on EMU48 because in EMU48 it is assured that
under all circumstance the carry flag is always clear.
But if I run the same code on a real 49G+ it does not work so it has
to be assumed that the state of the carry flag is not always the same
as on the Saturnator and EMU48.

I do not know which version is right (Saturnator or EMU48) but if I
want to run my software on a real 49G+ / 50G I have to respect this
=93characteristic feature=94.

Probably CdB and/or JYA and/or Christoph Giesselink could bring some
light into this.

 > every operation  > and every result is identical
 > to the original hardware, because this emulator
 > uses the same original ROMs
I do not know if the technique/trick described above is used in the
ROM (and it would take a lot of time to assure this) but be warned
that the state of the carry flag is not always the same on the
Saturnator and EMU48 !

Conclusion: Be careful using the carry flag on a 49G+ / 50G.

Regards,
Andreas
http://www.software49g.gmxhome.de

On Tue, 14 Jul 2009 07:28:42 -0500, Andreas Moeller wrote:

> I can assure you that the state of the carry flag (inside the processor)
> is not always the same as in EMU48 and the Saturnator of the 49G+/50G.

[...]

> If you only need to make a short jump (which is the case here)
> and if you know the state of the carry flag one could use a GONC
> instead of a GOTO. The result is shorter code
> (1 nibble less because a GONC/GOC is encoded with 3 nibbles,
> a GOTO with 4 nibbles) and faster code.

> However this only works on EMU48 because in EMU48 it is assured
> that under all circumstances the carry flag is always clear.

> But if I run the same code on a real 49G+ it does not work so it has
> to be assumed that the state of the carry flag is not always the same
> as on the Saturnator and EMU48.

[...]

> Be careful using the carry flag on a 49G+ / 50G.

Surely it is not "assured that under all circumstances
the carry flag is always clear," because then
no tests involving the carry flag would ever work :)

Should the warning actually be more like
"don't assume what the carry flag will be,
if you have not performed any recent instructions
which are supposed to either set or clear it"?

"Skating on thin ice" to save a byte is always slightly risky,
and "defensive programming" to guarantee perfect performance
under all conditions is worth considering, isn't it?

Thanks for your innumerable software contributions,
and your enlightening articles.

[r->] [OFF]

Hello,

 > Should the warning actually be more like
 > "don't assume what the carry flag will be,
 > if you have not performed any recent instructions
 > which are supposed to either set or clear it"?

Considering that English is not my native language I=B4ll try another
approach:
On EMU48 the actions that are happening always result in a clear carry
at the time I=B4ll test it whereas this is not the case on the
Saturnator.

IIRC the hardware bug of the original Saturn is not emulated in the
Saturnator. I do not know if there is software that uses this
"feature" of the original Saturn but it would surely result in
something different.

I just wanted to point out that if the software produces identical
results does not mean that the emulation works perfect or in other
words: original Saturn <> Saturnator.

 > Thanks for your innumerable software contributions,
 > and your enlightening articles.
You are welcome.

Regards,
Andreas
http://www.software49g.gmxhome.de

"John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
news:op.uw2h8qernn735j@miu.edu...
> "Skating on thin ice" to save a byte is always slightly risky,
> and "defensive programming" to guarantee perfect performance
> under all conditions is worth considering, isn't it?

Actually most contemporary guidelines specifically recommend AGAINST 
"defensive" programming: It's far better to figure out what the *core* problem 
is (i.e., do the simulators incorrectly deal with the carry flag?  Or is 
Andreas using bad documentation of its behavior or not reading it correctly?) 
and address it rather than "trying" to always do the right thing.

Defensive programming does make sense if the ships have sailed so far there's 
no chance the core problem can be fixed, of course.  (E.g., applications that 
have to run on slightly-buggy OSes that are widely deployed but never going to 
be fixed...)

On Tue, 14 Jul 2009 12:28:09 -0500, Andreas Moeller wrote:

> IIRC the hardware bug of the original Saturn
> is not emulated in the Saturnator.

This could bring up a philosophical discussion,
of whether it is wise to lock into other software
a dependency upon a bug, or is it better to ensure
that software will always work, no matter what,
whether on a buggy or fixed processor
(including on any emulator
which might follow the specs of the processor,
even if there was any hardware version which had a bug).

Fortunately, software which depends upon said bug
must be so rare that in all the programs I have ever used,
or heard of others using, obtainable from www.hpcalc.org,
it is mighty hard to find any which don't work the same
on all platforms, including those involving emulators.

In fact, it must be all but impossible for that to occur,
in any software which doesn't have sections that are
written externally in ML, by a risk-taking programmer,
rather than all in SysRPL and/or UserRPL,
which use only ML that is already embedded in ROM.

There is always the danger, when raising doubts of this sort,
of a "Chicken Little" effect, wherein something extremely unlikely
to ever be encountered causes fear of using anything at all.

On the other hand, "WR" was always so obsessed with
"shortest possible programs" that he even used
non-supported entry point addresses, with wild abandon,
and sure enough, some of his libraries crashed on later ROM versions,
perhaps clouding the value of whatever the earlier savings had been,
much like the current crashed economy, after having sailed off
into quick profits at high risk, with no regard for reliability and safety.

[r->] [OFF]

Hello,

 > In fact, it must be all but impossible for that to occur,
 > in any software which doesn't have sections that are
 > written externally in ML, by a risk-taking programmer,
 > rather than all in SysRPL and/or UserRPL,
 > which use only ML that is already embedded in ROM.
IIRC humans are working at HP, so it could happen that they make a
mistake :-)
And as a matter of fact there are still bugs in the ROM. (And for some
work-a-rounds that I programmed ML is/was absolutely necessary.)
And without ML there is no SysRPL and without SysRPL there is no
UserRPL.
q.e.d.

A quote from "An Introduction to HP 48 System RPL and Assembly
Language Programming" by James Donnelly:
"There are times in application development when System-RPL simply
won=92t do the job or is too inefficient, so you want to write some code
in assembly language."

So there are plenty of situations where a programmer has to decide
wether or not to code in ML or not.

By the way, what happend to Wolfgang ? He has been not around for
quite some time.

Regards,
Andreas
http://www.software49g.gmxhome.de

On Tue, 14 Jul 2009 12:39:46 -0500, Joel Koltner wrote:

> Actually most contemporary guidelines specifically recommend AGAINST
> "defensive" programming: It's far better to figure out what the *core* problem
> is (i.e., do the simulators incorrectly deal with the carry flag?...)
> and address it rather than "trying" to always do the right thing.

"Contemporary guidelines" for what?  By whom?  With whose interests in mind?

Do you mean like "contemporary guidelines"
for eliminating all regulation and oversight of the financial industry?

Only if within one single project, "all under one roof" (and complete control),
otherwise a disastrous prospect, IMO.

Even then, it invites disaster not to act defensively,
when there is even a modest likelihood
of less than perfect communications between different elements
of a large project, as so well described in this classic lecture,
by the CEO of a major U. S. Defense contractor:

"Yes, But Will It Work in Theory?" [1996] by Norman R. Augustine,
Chairman and Chief Executive Officer, Lockheed Martin Corporation
http://web.archive.org/web/19970705234218/www.me.gatech.edu/me/publicat/AugTranscript.htm
http://sunnyday.mit.edu/16.355/Augustine.htm
http://www.me.gatech.edu/docs/transcripts-96.pdf

> Defensive programming does make sense if the ships have sailed so far
> there's no chance the core problem can be fixed, of course.
> (E.g., applications that have to run on slightly-buggy OSes
> that are widely deployed but never going to be fixed...)

Unless you can predict all of the conditions that will always prevail,
despite the likelihood of future or concurrent developments,
an independent software writer would be well advised
not to depend upon bugs, nor upon anything risky at all.

Even the fact that new programs are assuming a screen length of 80 pixels,
rather than testing the actual screen height, seems unfortunate to me,
particularly since there is even a member of the current HP graphing series
which still has a screen height of 64 pixels:

http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/215348-215348-64232-30821-215351-384712.html
http://h10010.www1.hp.com/wwpc/pscmisc/vac/us/product_pdfs/HP_48gII_Calculator_datasheet_hi-res.pdf

Any well done job is likely to involve just a little more care and thoughtfulness,
which is rewarded by being infallibly problem-free,
IMO worth it whenever one is not compelled by great pressure,
although acceptable and necessary when having to develop a program
to plot an escape route while under fire on a battlefield  ;-)

[r->] [OFF]

On Tue, 14 Jul 2009 15:44:14 -0500, Andreas wrote:

[that some programming needs ML]

I didn't say otherwise, but was trying to make two points:

o That SysRPL and UserRPL programs are never affected.

o That ML, when used, needn't be taking risks to save one byte.


> By the way, what happend to Wolfgang [Rautenberg]?
> He has been not around for quite some time.

Might he have been erased by a TTRM, after some interim ROM update?  ;-)


[r->] [OFF]

Hi John,

"John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
news:op.uw2tded3nn735j@miu.edu...
> "Contemporary guidelines" for what?

Software programming.

> By whom?  With whose interests in mind?

"C++ in Action" by Milewski has a good rant about it.

> Even then, it invites disaster not to act defensively,
> when there is even a modest likelihood
> of less than perfect communications between different elements
> of a large project, as so well described in this classic lecture,
> by the CEO of a major U. S. Defense contractor:

The idea is that more disasters are caused by defensively-programmed software 
"trying" to do the right thing even though they know they've been given 
"slightly" incorrect results or the API they called didn't "quite" work than 
just insisting that the real problem gets fixed in the first place.  Most of 
this should be happening as software is developed -- I'm sure we'd agree that 
it becomes nearly impossible to get everyone to upgrade/patch their software 
once it's in the wild.

Also note that the "offensive" style of programming I'm advocating here is 
meant to be offensive to *other bits of buggy software* but in *no way* 
towards the end-user: If it's an auto-pilot control system or the nuclear 
reactor management program, it makes sense to try to "do the right thing" even 
when it's clearly something is very broken, but the software should absolutely 
be raising as big of a stink as possible that something isn't working right. 
Silent failures in software are the cause of a lot of data corruption in this 
world.

I agree that perfect communication doesn't exist in large projects, but I'm 
convinced that improving communication requires less overall effort than 
everyone programming defensively.  At least when the project is still "active" 
and most everyone is still available -- as I mentioned, there's no point in 
trying to get, e.g., Microsoft to fix the remaining bugs in Windows 2000 (much 
less Win98 or Win95).

> Unless you can predict all of the conditions that will always prevail,
> despite the likelihood of future or concurrent developments,
> an independent software writer would be well advised
> not to depend upon bugs, nor upon anything risky at all.

Well, in the particular case at hand here, it's not clear to me whether it's a 
bug or not.  It does seem to fall into the category of just being 
undocumented?  ...in that case I certainly wouldn't rely on it either.  If it 
is a documented bug, though, then I'd say an emulator should emulate the bug 
as well -- or at least have an option for doing so, if there's a performance 
hit to implementing it; otherwise it really is a buggy emulator.

> Even the fact that new programs are assuming a screen length of 80 pixels,
> rather than testing the actual screen height, seems unfortunate to me,
> particularly since there is even a member of the current HP graphing series
> which still has a screen height of 64 pixels:

Anyone assuming the screen length is 80 pixels should be checking to make sure 
they're running on a 50g or 49g+ and aborting if that's not the case.

I wouldn't really fault anyone for writing 50g/49g+ specific software though 
(i.e., ignoring the 48GII and earlier machines), since I expect the number of 
people who would ever start loading 3rd-party applications onto their 
calculators but just couldn't afford a 50g or 49g+ is very, very small.

---Joel

On Tue, 14 Jul 2009 17:46:53 -0500, Joel Koltner wrote:

> "C++ in Action" by Milewski has a good rant about it.

> The idea is that more disasters are caused by defensively-programmed software
> "trying" to do the right thing even though they know they've been given
> "slightly" incorrect results or the API they called didn't "quite" work than
> just insisting that the real problem gets fixed in the first place.

> Well, in the particular case at hand here, it's not clear to me whether it's a
> bug or not.  It does seem to fall into the category of just being
> undocumented?  ...in that case I certainly wouldn't rely on it either.

The particular thing that we started talking about,
as Andreas mentioned, is that he tried to count on
the state of the processor carry flag being cleared,
without recently having performed anything
that would be expected to have set or cleared that flag,
which he definitely attributed to a processor bug,
to save one byte and a few machine cycles.

The "defensive programming" that I am, in this regard, suggesting,
is to use a normal GOTO (rather than GONC),
which absolutely can not fail, and which will not change,
in the slightest perceptible degree, the user experience or response time,
rather than trying to count on a processor bug being emulated,
to "save" nothing that means anything to anyone else;
do you see some fault with that idea?

I think that this is so far removed from the above software scenario
that there is no connection in meanings whatsoever.

I _always_ program "defensively," in this regard;
for example, this simplest little program to import UserRPL source,
either copied from postings or transferred on SD cards:

@ 7-bit ascii string -> calc object
\<< \->STR 3 TRANSIO RCLF SIZE 3 >
#2F34Dh #3016Bh IFTE SYSEVAL + STR\-> \>> 'IN' STO

The first "defensive" programming in the above
is to start off with \->STR, even though the user
is "supposed to have read the directions"
and supplied a string object -- otherwise,
there might well be a hang or crash,
which this one extra \->STR absolutely prevents.

But heck, every UserRPL command is equally "defensive,"
in that it checks for valid arguments -- is that a bad practice?

The second "defensive" programming in the above
is that it will work on every HP48/49/50 calculator to date --
a few extra bytes, but absolutely goof-proof,
even for owners of HP48[S/G], who seem to be
still appreciating and using them,
as recent posting activity seems to reveal.

Is this the "bad programming practice"
which may actually promote disasters, to which you refer above?

Note that there never was any "real problem to fix in the first place,"
as regards this thread, except the problem of a very smart (but not very safe)
"programming cowboy," driving as fast as possible, without a seat belt,
while chatting on a cell phone, just to see what he might get away with,
to save that meaningless one byte and a few microseconds,
at what turned out to be the expense of not working on one series of hardware  ;-)

In its own very small way, it is not unlike the "greed gone mad"
imbalance of values which perpetuates world-wide catastrophe,
rationalized by nearly brain dead political mouthpieces,
yet accepted by what must be equally brain dead voters,
with "brain" meant to include all the dimensions of awareness
of which human beings are capable, much of which is disabled
by accumulated fatigue and stress.

---

My simple programming example above, in case it happens to be of interest,
comes from this complete post, in which is developed a complete system,
starting from the simplest of all the programs,
which can be used to "import" all the rest, directly into the calculator:

Ascii Import/Export for SD card and Emulator
http://groups.google.com/group/comp.sys.hp48/msg/4e7ed90b3cf11c42

[r->] [OFF]

On Tue, 14 Jul 2009 15:44:14 -0500:

> By the way, what happend to Wolfgang ?

http://www.math.fu-berlin.de/groups/ag-logik/members/rautenberg.html [em=
eritus?]
http://page.mi.fu-berlin.de/raut/ [with HP calc links, none recent]

More significant than calculators
http://www.amazon.com/s/ref=3Dntt_at_ep_srch&search-alias=3Dbooks&field-=
author=3DWolfgang+Rautenberg

-[ ]-

Hello,


 > Note that there never was any "real problem to fix in the first
place,"
 > as regards this thread, except the problem of a very smart (but not
very safe)
 > "programming cowboy," driving as fast as possible, without a seat
belt,
 > while chatting on a cell phone, just to see what he might get away
with,
I always buckle up when I drive but I also like to drive as efficient
as possible.

 > to save that meaningless one byte and a few microseconds,
 > at what turned out to be the expense of not working on one series
of hardware  ;-)
If it runs in a loop (which is here the particular case) every cycle
counts and the GONC/GOC trick is very nice if short jumps are made. To
bad that there is no GOTO for 3 nibbles as an equivalent to the GONC/
GOC trick.

The most important drawback IMHO is that you can=B4t rely on the tests
done on EMU48 and you can=B4t look as easy into the processor of a real
machine as with debug4x...

Regards,
Andreas
http://www.software49g.gmxhome.de

On Tue, 14 Jul 2009 19:40:12 -0500, Andreas wrote:

> The most important drawback IMHO is that you can't rely on the tests
> done on EMU48 and you can�t look as easily into the processor of a real
> machine as with debug4x...

Is there a comparison or summary of differences
between Emu48 and Debug4x?

Thanks.

[r->] [OFF]

Hello,

> Is there a comparison or summary of differences
> between Emu48 and Debug4x?
Not that I am aware of. But since Emu48 is included in Debug4x we
would need something like a comparision of a real Saturn, Emu48 and
Saturnator.

Regards,
Andreas
http://www.software49g.gmxhome.de

In article <yV77m.280524$2p1.61484@en-nntp-08.dc1.easynews.com>,
Joel Koltner <zapwireDASHgroups@yahoo.com> wrote:
>Hi John,
>
>"John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
>news:op.uw2tded3nn735j@miu.edu...
>> "Contemporary guidelines" for what?
>
>Software programming.
>
>> By whom?  With whose interests in mind?
>
>"C++ in Action" by Milewski has a good rant about it.
>
>> Even then, it invites disaster not to act defensively,
>> when there is even a modest likelihood
>> of less than perfect communications between different elements
>> of a large project, as so well described in this classic lecture,
>> by the CEO of a major U. S. Defense contractor:
>
>The idea is that more disasters are caused by defensively-programmed software 
>"trying" to do the right thing even though they know they've been given 
>"slightly" incorrect results or the API they called didn't "quite" work than 
>just insisting that the real problem gets fixed in the first place.  Most of 
>this should be happening as software is developed -- I'm sure we'd agree that 
>it becomes nearly impossible to get everyone to upgrade/patch their software 
>once it's in the wild.

This works only so long as the offending/defending software are two
part of the same system being developed in coordination.  It fails
when the two parts are decoupled.

99.999...% of the time, the parts are decoupled.

>Also note that the "offensive" style of programming I'm advocating here is 
>meant to be offensive to *other bits of buggy software* but in *no way* 
>towards the end-user: If it's an auto-pilot control system or the nuclear 
>reactor management program, it makes sense to try to "do the right thing" even 
>when it's clearly something is very broken, but the software should absolutely 
>be raising as big of a stink as possible that something isn't working right. 
>Silent failures in software are the cause of a lot of data corruption in this 
>world.

Nope.  You can't have it both ways.  If defensive programming is bad,
it is especially bad when things get serious.

Craig

Hi John,

"John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
news:op.uw21kioxnn735j@miu.edu...
> I _always_ program "defensively," in this regard;
> for example, this simplest little program to import UserRPL source,
> either copied from postings or transferred on SD cards:
>
> @ 7-bit ascii string -> calc object
> \<< \->STR 3 TRANSIO RCLF SIZE 3 >
> #2F34Dh #3016Bh IFTE SYSEVAL + STR\-> \>> 'IN' STO
>
> The first "defensive" programming in the above
> is to start off with \->STR, even though the user
> is "supposed to have read the directions"
> and supplied a string object -- otherwise,
> there might well be a hang or crash,
> which this one extra \->STR absolutely prevents.

I'd say it's better to not claim the user is supposed to supply a string 
object then in the first place.  If the user really *is* supposed to provide a 
string, it'd be better to check the object type, and if it's not already a 
string, generate an error.  In other words, you should document what you 
really expect to happen and then have code that does what you've documented.

> But heck, every UserRPL command is equally "defensive,"
> in that it checks for valid arguments -- is that a bad practice?

Nope, not at all.  "Defensive" programming, in the way I'm referring to it 
here, is the part where your program tries to "fix" problems it shouldn't have 
to -- checking for valid arguments and then generating an appropriate error 
message is "offensive" programming, and very much the thing I'm promoting.

> The second "defensive" programming in the above
> is that it will work on every HP48/49/50 calculator to date --
> a few extra bytes, but absolutely goof-proof,
> even for owners of HP48[S/G], who seem to be
> still appreciating and using them,
> as recent posting activity seems to reveal.
>
> Is this the "bad programming practice"
> which may actually promote disasters, to which you refer above?

Nope, that's just robust programming, which is a good thing.

I think we're actually largely in agreement about these things, it's just the 
terminology and a few corner cases that's somewhat unclear.

---Joel

Hi Craig,

"Craig A. Finseth" <news@finseth.com> wrote in message 
news:lNqdnUD6XNOrU8DXnZ2dnUVZ_sGdnZ2d@posted.visi...
> This works only so long as the offending/defending software are two
> part of the same system being developed in coordination.  It fails
> when the two parts are decoupled.

Sure, I'd agree with you there... although I think in many cases projects can 
be much more tightly coupled than is often seen in practice without any 
significant increases in development time -- and possibly even decreases: Time 
that's currently spent debugging problems when everything is finally glued 
together could instead be spend performing more thorough testing of individual 
and small handfuls of pieces.

> 99.999...% of the time, the parts are decoupled.

Well, see above... that may well be, but it doesn't have to be: Even if you're 
developing something as "free standing" as an operating system, there are 
almost always guys working on application development at the same time.

Clearly HP won't be going back and fixing any bugs in the Saturn CPU and 
issuing new calculators to everyone, so at this point those certainly need to 
be lived with. :-)  Heck, they won't even fix some of the really bad bugs in 
the 35s, which is very, very poor in my opinion.

> Nope.  You can't have it both ways.  If defensive programming is bad,
> it is especially bad when things get serious.

It is especially bad, but jets falling out of the sky, nuclear power plants 
melting down, and corrupting peoples' data files is even worse.  But there is 
a fundamental difference: "Defensive" programming strives to "do the right 
thing" and just keeps going (until the entire system potentially falls over 
dead, usually with little indication as to why), whereas "offensive" 
programming immediately throws up an alert that something is wrong, and then 
provides options (when possible) for a graceful shutdown/re-start/etc.

---Joel

On Wed, 15 Jul 2009 11:39:31 -0500, Joel Koltner wrote:

>> @ 7-bit ascii string -> calc object
>> \<< \->STR 3 TRANSIO RCLF SIZE 3 >
>> #2F34Dh #3016Bh IFTE SYSEVAL + STR\-> \>> 'IN' STO

>> The first "defensive" programming in the above
>> is to start off with \->STR, even though the user
>> is "supposed to have read the directions"
>> and supplied a string object -- otherwise,
>> there might well be a hang or crash,
>> which this one extra \->STR absolutely prevents.

> I'd say it's better to not claim the user is supposed to supply a string
> object then in the first place.  If the user really *is* supposed to provide a
> string, it'd be better to check the object type, and if it's not already a
> string, generate an error.  In other words, you should document what you
> really expect to happen and then have code that does what you've documented.

I'd say it was better here, in UserRPL, just to start off with \->STR,
because it's a shorter, easier program to enter, even manually,
which is a particular virtue which this version was meant to have,
while it's also still bullet-proof.

Programs which unnecessarily go to great lengths just to tell you that
you didn't do exactly what they said -- even though there was
no need to be so demanding, nor to return the whole shipment
for another penny "postage due" -- only annoy me,
just like similar personalities in people :)

[r->] [OFF]

On Wed, 15 Jul 2009 11:54:24 -0500, Joel Koltner wrote:

> "Defensive" programming strives to "do the right thing"
> and just keeps going (until the entire system potentially falls over
> dead, usually with little indication as to why), whereas "offensive"
> programming immediately throws up an alert that something is wrong, and then
> provides options (when possible) for a graceful shutdown/re-start/etc.

Although we're not entirely rationally
comparing little independent calculator programs,
meant for personal entry by novice users,
to large operating system projects,
here's yet another comparison to something else, in Windows:

In Windows version 3 (for those few old enough to have heard of it :)
I could at any time create any "shortcut" for starting a program,
intended to be put on someone else's desktop, and then either
mail it to them or access their computer remotely
and just put it there for them.

If, in creating the shortcut, I need to specify either a program path
or a working directory which exists on the other user's computer
but not on my own, Windows 3 gives a warning that the path
doesn't exist (on my computer), but if I say OK,
then it creates the shortcut anyway,
having duly alerted me for my own protection, should I need it,
which allows me to complete the job of creating it for the other user,
for whom the paths all do exist when they actually use that shortcut.

Windows 2000 and XP, however, not only complain about the paths not existing,
but they absolutely refuse to exit from adjusting the shortcut
until the paths are made valid for _me_,
even if that means that it's impossible for me to make them valid
for the _other_ user.  Even worse, if an existing shortcut happens
to be read-only, it becomes impossible even to switch to the
"tab" of the shortcut properties which would allow it
to be changed to read/write and then change it,
the result of which is that one gets locked into a steel trap,
out of which one can not escape to get the necessary job done at all.

Now, that is what I call "offensive," where narrow-minded programmers or system
designers who have no perspective or imagination, as to the variety of work
which must be done, create a cage in which one can not work at all.

I find this to be very typical of a lot of Microsoft stuff --
perhaps their entire "corporate culture" is based
on being pedantic twits, whereas the most creative and flexible systems
more commonly arise from groups of people whose entire personality
is at an opposite end of the psychological spectrum,
with whom and with whose products it gives one a feeling of joy to be working.

[r->] [OFF]

"John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
news:op.uw4dn8ipnn735j@miu.edu...
> Programs which unnecessarily go to great lengths just to tell you that
> you didn't do exactly what they said -- even though there was
> no need to be so demanding, nor to return the whole shipment
> for another penny "postage due" -- only annoy me,
> just like similar personalities in people :)

Such programs are not robust, and they suck.

They usually come about from low-skilled programmers who are programming to 
some rigidly written spec and don't actually understand what the entire 
program or system does.  I see a lot of this from, e.g., contract firms 
operating out of the far east...

"John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
news:op.uw4fflgcnn735j@miu.edu...
> Windows 2000 and XP, however, not only complain about the paths not 
> existing,
> but they absolutely refuse to exit from adjusting the shortcut
> until the paths are made valid for _me_,
> even if that means that it's impossible for me to make them valid
> for the _other_ user.

As Windows has "evolved" (if you can call it that...), the target demographic 
has shifted towards lesser and lesser skilled users.  You're thinking of the 
Windows desktop as a "general purpose shortcut creation tool" whereas 
Microsoft shifted it towards a much more targeted tool to eliminate all 
possibility of error, even though it makes it less powerful in the process. 
It's not something I want, but I can understand where they're coming from 
(since, you see, unfortunately a lot of people would answer "yes" to the 
Windows 3 prompt about "This doesn't appear to be a valid path... are you sure 
it's what you mean?" and then still complain that it doesn't work. :-( ).

> Now, that is what I call "offensive," where narrow-minded programmers or 
> system
> designers who have no perspective or imagination, as to the variety of work
> which must be done, create a cage in which one can not work at all.

It's offensive to users, which is Bad.  "Offensive programming," as such, is 
about being offensive to bad programmers. :-)

You might prefer Linux?  Different desktop managers for different people is 
very much encouraged, whereas -- while it is possible with Windows -- it's 
generally frowned upon?

---Joel

On Wed, 15 Jul 2009 13:51:28 -0500, Joel Koltner wrote:

> As Windows has "evolved" (if you can call it that...), the target demographic
> has shifted towards lesser and lesser skilled users.

"Home" versions have, but Microsoft also makes things called "Domain Controllers"
and "Active Directory," aiming at being scalable all the way up to
very large enterprises.

Such enterprises necessarily must have System Administrators,
whose tasks include the very sort of things I was saying.

I had pointed out how stubbornly Windows resists making a shortcut
whose current full path does not exist.  However, should one have
a shortcut whose path existed when created, but does not exist now,
then Windows will become all to eager to suggest ridiculous
other programs or paths that it thinks you might have meant,
completely forgetting that it would have been impossible
to do that in the first place, as already pointed out.

Finally, it will let you say "yes" to that without a moment's hesitation,
so the whole thing is a bit schizophrenic,
just like most of the rest of the world :)

-[ ]-

On Jul 12, 3:28=A0am, Dave <davidbr...@gmail.com> wrote:

> The 50g is certainly a nice machine, and probably the most capable
> calculator on the market right now. However, the 48G/S beat it hands
> down in terms of usability. The obvious difference is the keyboard
> stiffness...

As I'm already owning an HP48GX and an HP32sii i think i will stick to
them finally. Even so the "2" key is still giving some problems.
Sometimes works sometimes don't. Funny.
The think is that i was considering, and this may sound like a
blasphemy on this newsgroup, to get a TI. I'm an RPN fanatic but still
i can use my old machines for crunching numbers and matrix, while i
use for graphing and so a faster machine with longer battery life than
the HP50g.
I wonder how many of you have a foot on the dark side and own both, HP
and TI calculators. I was considering to get the TI89 titanium, or
voyage 200 or the Nspire.

On Jul 17, 12:58=A0pm, Karan <aryaka...@gmail.com> wrote:
> The think is that i was considering, and this may sound like a
> blasphemy on this newsgroup, to get a TI. I'm an RPN fanatic but still
> i can use my old machines for crunching numbers and matrix, while i
> use for graphing and so a faster machine with longer battery life than
> the HP50g.

If you're looking for fast, general-purpose graphing, get a Casio
fx-9860g. That thing absolutely smokes everything else I've ever used.

Now, if you've got some kind of very specific situation where setting
up the graphs you need takes a great deal of effort, then a machine
with greater customization flexibility will potentially have the
advantage, giving you results in a shorter amount of time, even if the
actual production of the graph takes longer. For example, I've got a
few programs on my 48 that reduce some trend analysis to just a few
keystrokes, including graphed output and printed reports. The
programming capabilities of the Casio are much clumsier by comparison,
and wouldn't give the seamless integration I can achieve on the HP.

> I wonder how many of you have a foot on the dark side and own both, HP
> and TI calculators. I was considering to get the TI89 titanium, or
> voyage 200 or the Nspire.

If HP is the light side, and TI is the dark side, where does that put
Casio? :) Personally, I think the keyboard layout of the TI-89 family
is just awful. The OS was originally designed heavily around the
assumption that the user would have the TI-92's QWERTY keyboard
available at all times, and a lot of concessions had to be made to fit
the bare minimum of functions onto vastly fewer keys. Now the TI-92+
or Voyage 200 on the other hand are excellent machines to work with,
and actually have a great deal more programming capabilities than the
TI-8X units. I've heard the Nspire has very little programming
capability, so I've steered clear of that one.

Off the top of my head, my stash (the graphers only) looks something
like this:

HP 48GX (bought new around 1998)
HP 49G (bought new around 2000)
HP 50G (bought new around 2006)
HP 48G (bought at a flea market for $5 - in rough shape, so I use it
for an alarm clock)
HP 28C (bought used around 2007)
HP 9G (bought new around 2007, just for the hell of it)
HP 28S (bought used a few months ago - needs some repair)
HP 48SX (bought used a few months ago)
HP 38G (bought used a few months ago)

TI-82 (bought new around 1995)
TI-92 (bought new around 1997, upgraded with Plus Module a couple
years later)
TI-86 (bought new around 1997, later sold for some reason, but picked
up another one used about a year ago)
TI-81 (got a few free from high school, maybe around 1998)
TI-83 (bought new around 1998)

Casio fx-7000g (the first handheld graphing calculator - got free from
high school's math dept. around 2000)
Casio fx-9860g Slim (bought new a few months ago)

Sharp EL-9200C (bought new around 1993)

It's a good thing I prefer to collect small handheld computers and
calculators rather than old desktops!

-Dave Britten