what about now?

31 views
Skip to first unread message

Wes

unread,
Nov 26, 2010, 9:43:01 AM11/26/10
to
I'd like to bring up a very old issue for which there has never been a
satisfactory solution presented: "ADD" vs "+"

I went from the HP-28C to the 49g+ and was pleased to see the list
processing features (introduced with the 48G series). On the 28C, I
thought appending was a nice use for overloading +. However, I was
rather dismayed when I discovered that on the 49g+ the + operator
still retained the old append functionality. One has only to do a
quick search in this newsgroup to see how troublesome this decision
turned out to be.

I've gone back and have done a bit of reading through ancient posts
here and have seen some clever work-arounds, and rationals for why +
should append, but frankly, it's hard keep a straight face when
explaining to a student that they can use lists as arguments to
mathematical functions as long as the function doesn't contain a +.

Typical newsgroup responses to this criticism have been:
1) Appending lists is needed more often than processing lists.
2) Assign ADD to the + key.
3) Use ADD in your equations.
4) List processing is not a birthright.
5) It would break compatibility.

My responses:
1) Frequency shouldn't trump logic. (In my own use, processing lists
outnumbers appending lists at least 50:1, but that's just me.)
2) Assigning ADD to the + key helps, but it doesn't help when using a
list as a function argument. Also, key assignments don't work in the
equation editor. (For really quirky behavior, see what happens in the
equation editor when you try to use ADD either from the keyboard or
from CAT.)
3) In calculus, you frequently have to evaluate the first or second
derivative of a function at various points. Even if you use ADD in
your function, taking the derivative converts these back to +.
4) It's not a birthright, but if you're going to put a feature on a
calculator, you might as well do it right. To have it work a certain
way for all operators except the most commonly used one is a little
weird. (Are there any current graphing calculators that DON'T have
list processing?)
5) In a post from 2004, a wise man stated: "It would've been far
better if they had created a list concatenation command rather than
overloading +." An even wiser man replied:

> I vote we change it back. Sure a few userRPL commands may act funny,
> but think about it. If this keeps up in 30 years (if calculators still
> exist that is) everyone will still be asking this question. Why not
> make the change now? it has to be done sometime. Let's make the
> operators consistent for lists.
> TW

The 49g+ would have been a great time to make the switch. But NOW
isn't so bad. Why now? Because now, TW is in a position of influence
to make it happen. :-)

I know that life is short and ROM is full, but if a clever programmer
can find room in a "full" ROM for StreamSmart, then surely there must
a way to swap the names of two commands. Several people have
suggested using a flag to indicate whether you want the compatible
"append" behavior or the consistent "add" behavior of +.

A final question. Even if a ROM change had to wait till a new model
(if that ever actually occurs), in the mean time, is it possible to
write a program to hook into a ROM procedure to change its behavior?

Thanks,
-wes

Andreas Möller

unread,
Nov 26, 2010, 11:01:37 AM11/26/10
to
Hello,

> (if that ever actually occurs), in the mean time, is it possible
> to write a program to hook into a ROM procedure to change
> its behavior?

It is possible *but* it is a lot of work (besides the necessary
knowlege).

And by *a lot* I mean more than what you would most likely imagine ;-)

AFAIK my Language Packs are the only existing software for the 49
series that allows taking over built-in procedures.
As an example, I use it to take over the built-in help and use my own
routines there instead of the ROM-routines.

It took years to develop this and to do it right. And by "right" I
mean circumventing existing problems (As TW does not like them beeing
called "bugs" I rather use the term "problem".) in the ROM without any
speed penalty (the time needed for this is negligible).

Another way would be to directly manipulate the binary of the ROM...
aka patching.

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

John H Meyers

unread,
Nov 27, 2010, 1:50:14 AM11/27/10
to
On 11/26/2010 8:43 AM, Wes wrote:

> I'd like to bring up a very old issue for which there has never been
> a satisfactory solution presented: "ADD" vs "+"

[...]
> It would break compatibility.

Back in 1993, which is about when the 48G/GX came out,
after large numbers of 48S/SX had already been purchased,
if you made any number of applications
(including those which were purchased from vendors
on ROM cards, incapable of any re-programming) all fail,
I think you would have had a lynch mob coming for you.

Since 'a ADD b' can be written as 'a--b'
and then all your complaints vanish,
I think that your proposal
to make innumerable existing programs and libraries fail
(including heaven-knows how many applications on www.hpcalc.org,
most of which can't be re-written without huge efforts)
deserves exactly the same treatment today ;-)

[r->] [OFF]

Wes

unread,
Nov 27, 2010, 2:54:45 PM11/27/10
to
On Nov 27, 9:50 am, John H Meyers <jhmey...@nomail.invalid> wrote:
> Since 'a ADD b' can be written as 'a--b'
> and then all your complaints vanish,

If only that were true.
- Evaluating 1st and 2nd derivatives at multiple values is a very
common task in calculus--the perfect use for lists. But taking
derivatives changes "--" back into "+". Likewise for other algebraic
expression generating operations such as INTVX, ISOL, SOLVE, and
others.
- The equation editor does not allow a--b. It does allow a-(-b), but
at some point you have to admit that this is getting convoluted. As
one of my students said about not being able to use + with lists,
"Well that's dumb." He didn't care about the history of how it got
that way--he just knew that he couldn't do what the other kids in the
class were doing on their TI's.

Yes, there are work-arounds, but instead of fixing the symptoms, let's
cure the disease.

> I think that your proposal
> to make innumerable existing programs and libraries fail
> (including heaven-knows how many applications onwww.hpcalc.org,
> most of which can't be re-written without huge efforts)
> deserves exactly the same treatment today ;-)

I agree IF that were the only possible outcome. But perhaps a change
can be made in such a way that doesn't wreak such havoc.

Please consider the implications of the following example:
The excellent graphing program GeoGebra had a translation issue with
one particular command. Apparently, what Germans call eccentricity is
different than what English speakers call eccentricity. So the
command translated as Eccentricity didn't do what people expected.
In a later version of the program, the name of the original command
was changed from "Eccentricity" to "LinearEccentricity" and a
corrected version of the Eccentricity command was introduced.
Fortunately, since user defined functions in GeoGebra are saved in a
tokenized (compiled) format, old files saved with the earlier version
run just fine in the newer version. When someone using the new
version looks at a function saved with the old version, the user sees
the new name for the old functionality. Old files run as originally
written, new files run as expected. 100% backwards compatibility
while correcting a past mistake.

I'd guess that nearly all existing 50g programs and libraries are
distributed in compiled binary form. Leave the current code for xADD
and x+ at their current addresses. Old compiled programs and
libraries would run exactly as before. The needed change could be
implemented at the RPL compiler level. Based on a system flag, the
compiler could be set to either compile/decompile as before (default,
for compiling old source code), or with addresses reversed (for
expected behavior). There could even be a synonym (ala lim and
LIMIT), such as CONCAT, to avoid confusion. Old programs run as
originally written, new programs (and interactive use) behave as
expected. 100% backwards compatibility while correcting a past
mistake.

I know that this is probably a case of "Ye know not what ye ask" but
aren't we tired of the elephant in the room?

Respectfully,
-wes

John H Meyers

unread,
Nov 28, 2010, 7:13:12 PM11/28/10
to
On 11/27/2010 1:54 PM, Wes wrote:

> I'd guess that nearly all existing 50g programs and libraries are
> distributed in compiled binary form. Leave the current code for xADD
> and x+ at their current addresses. Old compiled programs and
> libraries would run exactly as before. The needed change could be
> implemented at the RPL compiler level. Based on a system flag, the
> compiler could be set to either compile/decompile as before (default,
> for compiling old source code), or with addresses reversed (for
> expected behavior). There could even be a synonym (ala lim and
> LIMIT), such as CONCAT, to avoid confusion. Old programs run as
> originally written, new programs (and interactive use) behave as
> expected. 100% backwards compatibility while correcting a past
> mistake.

There was no "past mistake" to begin with,
while with your "correction" of a non-mistake,
the compilation/editing of many old programs
would change them into non-working new programs,
which would instead be a new (major) mistake.

Members of the calculator series whose ROMs
are not replaceable could also not participate,
and of course would not even be able to compile
any programs substituting any new command.

Here are several simple ways, however,
to use "+" (ADD) with lists,
without any ROM modification at all,
and without introducing any incompatibility at all,
to any calculator at all.

The first method can be applied in HP48G[X][+]
as well as in all HP49/50 series calculators:

'(X ADD 1)^2' 'X' DERIV
Result: '2*(X+1)'

Continue with:
WHILE { '&A+&B' '&A ADD &B' } \|^MATCH REPEAT END
Result: '2*(X ADD 1)'

In other words, ADD itself can be differentiated,
and all "+" in any algebraic expression
can be replaced again by ADD using a simple program.

An alternate method to replace "+" by "NEG -":
WHILE { '&A+&B' '&A-NEG(&B)' } \|^MATCH REPEAT END

Start with: '2*(X+1)'
Get equivalent: '2*(X--1)'

The following alternate approach can be used
in any version of all HP49/50 series calculators:

In: { 'X' 'X^2' 'X^3' } AXL { 1 2 3 } AXL + AXL
Out: { 'X+1' 'X^2+2' 'X^3+3' }

In: [ 'X' 'X^2' 'X^3' ] [ 1 2 3 ] +
Out: [ 'X+1' 'X^2+2' 'X^3+3' ]

In other words, the "+" operator still means only
normal element-by-element addition (not concatenation)
for "lists" of type 29 (Symbolic Matrix),
which you can already use in all HP49/50 series calculators.

So, for those few people interested in storing lists
into variables used in algebraic formulae,
there are simple solutions, not "breaking" anything,
and there is no need for replacing any existing commands
nor for creating any new commands, flags, etc. in ROM,
just for you, at the expense of everyone else.

--

Wes

unread,
Nov 29, 2010, 9:54:48 AM11/29/10
to
On Nov 29, 3:13 am, John H Meyers <jhmey...@nomail.invalid> wrote:
>> 100% backwards compatibility while correcting a past mistake.
>
> There was no "past mistake" to begin with,

A better word choice on my part might have been "inconsistency."
Whether or not you consider it a mistake, I think most would agree
that having a calculator behave a certain way for all arithmetic
operators except one is at least "inconsistent."

> while with your "correction" of a non-mistake,
> the compilation/editing of many old programs
> would change them into non-working new programs,
> which would instead be a new (major) mistake.

Perhaps I didn't communicate my idea properly, but what I was trying
to suggest allows all old programs to work, even after editing/
compiling.

Case 1. system flag set to +=concatenate setting (clear)
+ = 39B58 (code that concatenates)
ADD = ROMPTR AB 5C (code that does arithmetic addition)
Editor decompiles/compiles RPL programs exactly as current editor
does.

Case 2. system flag set to +=addition setting (set)
ADD = 39B58 (code that concatenates) (or synonym like CONCAT)
+ = ROMPTR AB 5C (code that does arithmetic addition)
Editor decompiles old programs into new names. These new names would
recompile back into the same original code.

In either case, old code could be edited and recompiled and you'd get
back the exact same binary. IMHO, this would be the best of both
worlds.


> Members of the calculator series whose ROMs
> are not replaceable could also not participate,
> and of course would not even be able to compile
> any programs substituting any new command.

Every new calculator has some incompatibilities with older models.
This change would have virtually no impact as anybody who wanted to
share source code for older models could simply clear the flag before
editing (case 1).

The main benefit of all this is to improve the consistency of
interactive use while maintaining full compatibility with old
programs. If someone doesn't want this behavior, they simply don't
set the flag.


> Here are several simple ways, however,
> to use "+" (ADD) with lists,

These are good work-arounds. I assign AXL to a key for just that
reason. I thought the use of ^MATCH was clever.

My own method that I've been using to evaluate an expression at a
value or list of values is simply

<< SWAP MAP << EVAL >> MAP >>

which I assign to key 23.31 (vertical bar). It does what I want for
expressions (like 'X+SIN(X)'), but for functions (like << -> X 'X
+SIN(X)'>>) it still takes the extra step of evaluating the function
at X first.

One of the great efficiencies of RPL and soft-menus is the ability to
put a value on the stack and press the function's soft-key to get a
result in a single keystroke. We're tantalizingly close to being able
to do that with lists. (It's like the meat hanging down in Old
Yeller.)


> just for you, at the expense of everyone else.

Come on now, we need to be able to make recommendations without
getting jumped on. As a HP RPN guy since '82, I'm not HP bashing.
Based on past posts, I hardly think I would be the sole beneficiary.
I suspect that the education market is a significant portion of 50g
sales. I've been teaching math and physics for a number of years and
I think this suggested feature would be something students, and
others, would consider a plus. :-)

-wes

Veli-Pekka.Nousiainen

unread,
Nov 29, 2010, 3:53:36 PM11/29/10
to
Wes wrote:
>> > just for you, at the expense of everyone else.
> Come on now, we need to be able to make recommendations without
> getting jumped on. As a HP RPN guy since '82, I'm not HP bashing.
> Based on past posts, I hardly think I would be the sole beneficiary.

Now there are two persons
That means that John H Meyers is now the
"just for you" -person
How about that John?!
See now what happens when YOU think that YOU are GOD !!

John H Meyers

unread,
Nov 29, 2010, 6:44:26 PM11/29/10
to
On 11/29/2010 8:54 AM, Wes wrote:

> Case 1. system flag set to +=concatenate setting (clear)

> Case 2. system flag set to +=addition setting (set)

> [to change the compiling/decompiling of existing commands,
> if I understand correctly]

What system flag?

You seem now to be suggesting something that would
re-compile so as to change all "+" to ADD and all ADD to "+"
(which a trivial program has already been supplied to do,
quite easily, without any such drastic global compilation change)

What would you do for a program which needs to use both "+" and "ADD"
upon lists, in the same program -- which way would automatically handle that,
aside from continuing to use "+" and ADD exactly as we do now,
where each applies? (reversing both would not make the distinction
any less necessary)

If you're going to plan for a new ROM in the same series,
incompatible with existing (and unmodifiable) ROMs in HP48Gii, say,
how about fixing other "inconsistencies" at the same time,
such as those which have been causing grief to all variable-length
list processing programs?

In particular, DOLIST, DOSUBS and SEQ all refuse to accept empty lists,
and also, if their final result should be an empty list,
then they return _nothing_ to the stack,
which there is no way to test for -- e.g. no extra True/False result,
like KEY or CHOOSE or INFORM , to say whether they did or did not
return any other data, other than the T/F indicator itself,
which is very vital to know when using a data stack.

This has required "contortions" in many of my own programs
to deal with, as I have written about some time ago.

There is actually a very easy way to "fix" the latter,
via a slight change to a common endpoint of those functions,
but doing so would also break all older programs which happen
to already _rely_ on the quirk -- so perhaps find just one more
system flag, and compile new commands, depending on that flag?

What about programs which compile other strings while executing
the program itself? The very action of SEQ, for example,
actually invokes the compiler internally,
so it would be affected by anything which alters the action
of compiling. What if programs already also set flags to
built-in values -- what would automatically change those values
to adjust to newly invented additional system flags?

If you invent a new command (e.g. CONCAT),
how would ROMs which you can not update
decompile and display that command,
no less be able to compile it?

In an earlier post, your justification of a need
for what you suggested was basically that
if you differentiate an algebraic expression with ADD,
then you get "+" operators again -- well,
have you also realized that by the same token,
you'll need to revise the CAS so that _all CAS operations_
likewise change all resulting "+" operators to ADD,
depending on the very same proposed new system flag?

Of course, we've already provided a trivial one-line UserRPL
program that you can use on any expression to do this yourself,
so I just think that to continue suggesting ROM revisions
which still do break all sorts of examples (above)
rather than use a trivial one-line RPL program,
is to head towards swatting a fly on one's nose
with a sledgehammer, only causing many far more serious issues.

The very least damage would occur if your proposed "system flag"
only changed the _run-time_ interpretation of "+" to ADD,
and left it to people who need to concatenate lists
to make sure that the flag is off, whenever doing concatenation;
this would leave in the dust anyone with non-updatable ROMs
(e.g. HP48Gii or 49G), and no longer allow the same programs
to keep working across the entire series (48/49/50),
which you can already do by invoking a one-line RPL program
on any algebraic expression which you plan to use on lists.

And this is for whom? For people who apply algebraic expressions
to variables containing lists, and who wouldn't use a one-line
UserRPL program to take care of it anyway, with no need
for anything new to be introduced, still maintaining
programs which can continue working on all 48/49/50 series calculators?

The current readership of this list may not represent a global census,
but just to get the crudest idea,
how many of today's readers do that?

And how many of those would find a one-line RPL program
more of a bother than having to keep track of a new system flag
(which in its least desirable form would
change the compiling/decompiling of many programs,
rather than just alter a run-time behavior?)

As to programming that doesn't involve algebraic expressions
with variables which happen to contain lists,
the mere advice to use the ADD command for addition of lists
is all that's needed, and has sufficed for all needs to date,
so why not wait for a new series before putting at any risk
all the accrued reliable programs for this series,
which work across every model of this series
(and even the previous series, in many cases)?

Meanwhile, there are many far more urgent needs to fix in ROM,
such as various remaining CAS bugs, and to remove the ghastly need
to delete all variables named 'X' (or whatever name RCLVX produces)
from the current and all higher directories, to perform various
CAS commands, and to automatically restore flags that the CAS
forces to be changed, etc. -- don't these things affect
a large percentage of all users, whereas how many are affected
by having to apply derivatives of algebraic expressions
to variables containing lists, who couldn't just as well
use a one-line program to take care of that,
on all models of the series -- even 48Gii and old 49G?

[r->] [OFF]

Wes

unread,
Nov 30, 2010, 12:48:59 PM11/30/10
to
On Nov 30, 2:44 am, John H Meyers <jhmey...@nomail.invalid> wrote:
> On 11/29/2010 8:54 AM, Wes wrote:
>
> > Case 1. system flag set to +=concatenate setting (clear)
> > Case 2. system flag set to +=addition setting (set)
> > [to change the compiling/decompiling of existing commands,
> > if I understand correctly]
>
> What system flag?

Could be any currently unused flag (if there are any left) or a
designated variable.

> You seem now to be suggesting something that would
> re-compile so as to change all "+" to ADD and all ADD to "+"

I'm not suggesting searching and replacing "+" with ADD and ADD with
"+". I'm suggesting that the text names associated with the binary
code be changed.

Perhaps I'm misunderstanding how 50g binary programs are stored. Let
me know if the following is correct:
Say a simple program was originally written as

<< + ADD >>

My understanding was that this is compiled and saved with the code
portion being

39B58
ROMPTR AB 5C

When a program is edited, it is decompiled back to

<< + ADD >>

Is this a correct understanding?

If so, now let's say someone opens the same program with my
hypothetical updated compiler which is set to reverse the names.
39B58 is decompiled as ADD while ROMPTR AB 5C is decompiled as "+".
So the editor shows

<< ADD + >>

When enter is pressed, it recompiles ADD to 39B58 and "+" to ROMPTR AB
5C

39B58
ROMPTR AB 5C

The binary program is identical to the original and can be shared with
anyone regardless of whether or not they have the new compiler. If
they need to share the source code as text, or if they just don't like
this option, the editor can simply be opened the old way.

As a rough analogy, let's say you have written an 80x86 program in
assembly using Intel syntax. Somebody else disassembles and re-saves
it using AT&T syntax. Even though the source code may look different,
the same binary is produced.


I'm not saying that my suggestion should take priority over the
numerous other bugs and suggestions you listed. But I am far less
bothered by quirks when I program. I may have to resort to
"contortions" as you say, but once the program is written, I don't
have to deal with them each time I run the program. With interactive
use, we have to go through the "contortions" each time we use that
feature. I'd gladly trade away some interactive quirks for some
programming quirks.

> If you invent a new command (e.g. CONCAT),
> how would ROMs which you can not update
> decompile and display that command,
> no less be able to compile it?

Not a new command, but possibly a synonym that would compile to the
same code as "the code formerly known as +". Older ROMs would run the
code same as before. Actually, this synonym thing is a side note; not
really necessary to accomplish what I was suggesting. (Not that I
haven't regularly wished in hindsight that the 28c had had a CONCAT
command instead of using "+" in the first place.)


> have you also realized that by the same token,
> you'll need to revise the CAS so that _all CAS operations_
> likewise change all resulting "+" operators to ADD,
> depending on the very same proposed new system flag?

You are right. I've wondered how the CAS does its thing. Are the
commands that it generates table based such that two table entries
could be swapped? Or are they hard coded into the CAS code. If the
latter, then what I'm suggesting is likely not feasible.


> The very least damage would occur if your proposed "system flag"
> only changed the _run-time_ interpretation of "+" to ADD,

I'm not picky. If that would do the trick, then that would be great.
I've even wondered about the possibility of having the run-time
behavior depend on whether a program was running or whether the
calculator was being used interactively. (probably not a good idea)

> so why not wait for a new series before putting at any risk
> all the accrued reliable programs for this series,
> which work across every model of this series

A new series with fixes, that would be great!

I brought up the topic at this time after reading through some old
posts in which Tim expressed a desire to have the operators consistent
for lists. If I understand correctly, Tim is now in some position of
influence. So I thought I'd bring it up again with hopes of
reawakening that thought.

Maybe everything I've suggested is totally infeasible. If it's not
possible, then okay. But it's okay to wish, it's okay to explore
ideas, and it's okay to want to improve our beloved product.


> I think this suggested feature would be something students, and
> others, would consider a plus. :-)

get it? a "plus" (hee hee)

-wes

Veli-Pekka.Nousiainen

unread,
Dec 1, 2010, 12:57:13 AM12/1/10
to

One problem is
that one needs to have & to do the list concatenation

Another is
that old program should somehow have to "know"
that you intended { lists } on your stack to be concatenated
and another time
that you stack was consisting of something else to be added
=> programs are broken anyway you try it
because if "+" now all of a sudden add items in a list
instead of concatenating lists
then your programs work diffrently
or
can someone explain this?

John H Meyers

unread,
Dec 1, 2010, 12:31:15 PM12/1/10
to
On 11/30/2010 11:48 AM, Wes wrote:

> Say a simple program was originally written as
>
> << + ADD >>

[...]

> If so, now let's say someone opens the same program with my
> hypothetical updated compiler which is set to reverse the names.
> 39B58 is decompiled as ADD while ROMPTR AB 5C is decompiled as "+".
> So the editor shows
>
> << ADD + >>

> The binary program is identical to the original and can be shared with


> anyone regardless of whether or not they have the new compiler.

But the source program is no longer valid, and can not be shared.

In addition, if the same user, of the same calculator,
flips his new hypothetical system flag at some point and then
re-compiles the now reversed source program on his own calculator,
he will even get in trouble himself.

Human readers might also be among those who could no longer
unambiguously understand source programs, particularly since
they don't even have system flags that can be set in their brains,
to remember whose programs should be interpreted in which way,
nor how to publish specific versions of their source programs
for specific different classes of users.

You will remember that even in the HP48 series,
text-based programs, when exported from the calculator,
were supplied with a "mode line" such as "%%HP: T(3)A(D)F(.);"
so that the interpretation of the same source program
by any other calculator would automatically set those same modes
(for symbol "translation," angle interpretation,
and "radix" point/separator interpretation),
to thus assure an unambiguously correct interpretation of the text,
when re-compiled on any other calculator, at any time.

In the light of that example, creating new differences in interpretation
that are not accompanied by automatic mode-setting in any compiling calculator
would remove all such assurances, particularly on unmodified calculators
which could not even have the ability to set any such new mode.

In addition, compilation sometimes occurs even within programs,
and, as you agreed, every command that can output symbolic expressions
would still need a dynamic re-interpretation during the subsequent evaluation
of those expressions (i.e. run-time alteration of the evaluation of "+"
would seem to be an inescapable necessity anyway, at the same time
as it would render unnecessary any other approach involving compilation).

We've begun to see that it requires an ever-widening conspiracy
to try to catch all the loopholes and pitfalls
of a "compiler-based" approach,
so I think it would open a large can of seriously
digestion-disturbing worms to take any such approach.

Even if still considering a run-time approach,
a bit of thought might also need to be cast in the direction of
SysRPL programs, to see whether any other internal points in ROM
might also need to be trapped.

For yourself, perhaps you might just patch your own ROM,
so that "+" would always perform "ADD," while for most people,
this entire topic never comes up, because variables which they
evaluate using algebraic expressions never take lists as their value.

Finally, as we illustrated earlier, for anyone anticipating
directly assigning lists as the values of variables,
without using DOLIST etc. to handle elements one at a time,
there are still simple one-line UserRPL phrases
which can replace all "+" by either "ADD" or "NEG -"
in any algebraic expression, just before evaluation,
which will then be completely amenable
to be used upon lists as their arguments.

This makes it completely unnecessary, in my own opinion,
to amend the original system design at this end-stage
of the product line, which thus far has preserved
the maximum degree of compatibility and reliability
in a large base of working software,
across all models in one or two complete series of calculators,
which I'm somewhat afraid of upsetting at this time,
if anyone goes about splitting off a variant of ROM,
available to only some subset of the product line and its users,
which no longer "supports" all of the original UserRPL.

I just can't see any justification to making such incompatible
internal ROM modifications to alter standard and common UserRPL,
which could only be done on one model of the entire series,
for something that very few people use,
when simple programming can already achieve the same thing,
and can also be applied identically on every single model
across two entire "G" series of calculators:

@ Replace all "+" in any expression by an algebraic equivalent:
\<< WHILE { '&A+&B' '&A-NEG(&B)' } \|^MATCH REPEAT END \>>
@ or
\<< WHILE { '&A+&B' '&A ADD &B' } \|^MATCH REPEAT END \>>


[r->] [OFF]

Wes

unread,
Dec 1, 2010, 4:32:38 PM12/1/10
to
On Dec 1, 8:31 pm, John H Meyers <jhmey...@nomail.invalid> wrote:

> But the source program is no longer valid, and can not be shared.

Open it with the flag set appropriately and you're ready to share.

> In addition, if the same user, of the same calculator,
> flips his new hypothetical system flag at some point and then
> re-compiles the now reversed source program on his own calculator,
> he will even get in trouble himself.

If you mean re-compiling by opening and resaving a program on the
calculator, then regardless of how the flag is set, the editor would
always compile the same way it decompiles. The binary would be
unchanged.

If you mean re-compiling from old source text copied and pasted into
the editor, then yes, you'd need to make sure the flag was set
appropriately, in the same way that we currently have to make sure the
exact/approx mode is set appropriately when editing.

> Human readers might also be among those who could no longer
> unambiguously understand source programs,

Which is why I was suggesting a CONCAT synonym for clarity.

> You will remember that even in the HP48 series,
> text-based programs, when exported from the calculator,
> were supplied with a "mode line" such as "%%HP: T(3)A(D)F(.);"
> so that the interpretation of the same source program
> by any other calculator would automatically set those same modes
> (for symbol "translation," angle interpretation,
> and "radix" point/separator interpretation),
> to thus assure an unambiguously correct interpretation of the text,
> when re-compiled on any other calculator, at any time.

Yet there's no such mode line indicator to tell whether a program was
written in approximate mode or the exact mode that was introduced at
some point. This can introduce some changes in the program, even when
opened by the same calculator if the mode flags are not set the same,
but we've learned to live with it. I suspect that if my hypothetical
editor ever existed, it would be common practice to always share
source code with the editor flag set in the compatible mode.

> In addition, compilation sometimes occurs even within programs,

Good point. Such programs would have to be run in the mode they were
written for. Anybody wanting to use the new command names could set
the mode within the program. Older programs that use run-time
compiling of "+" or "ADD" with lists would have to be run in
compatible mode. (I wonder how often that occurs.)

> We've begun to see that it requires an ever-widening conspiracy
> to try to catch all the loopholes and pitfalls
> of a "compiler-based" approach,

I'm sure I'm not seeing everything that a more knowledgeable person
like yourself sees, but so far, the only big snag I see is the CAS.
Depending on how the CAS generates code, it could be feasible or
completely impossible.

> Even if still considering a run-time approach,
> a bit of thought might also need to be cast in the direction of
> SysRPL programs, to see whether any other internal points in ROM
> might also need to be trapped.

Frankly, I don't see how a run-time approach could work. It would be
even messier yet.

> For yourself, perhaps you might just patch your own ROM,
> so that "+" would always perform "ADD,"

Are such tools available to end users?

> while for most people,
> this entire topic never comes up, because variables which they
> evaluate using algebraic expressions never take lists as their value.

Considering how much care was taken to make list processing work on
nearly every algebraic operation and mathematical function, it appears
that the original programmers expected people to use it. I doubt if
I'm the only user who finds this feature quite useful.

-wes

Andreas Möller

unread,
Dec 1, 2010, 4:46:36 PM12/1/10
to
Hello,

> Are such tools available to end users?

all you need is
1. a binary of the ROM
2. Python
3. some knowledge

All of this is freely available although one or another point might
mean that one has to invest (or pay in) time.

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

Wes

unread,
Dec 4, 2010, 2:39:54 AM12/4/10
to
On Dec 1, 8:57 am, "Veli-Pekka.Nousiainen"

<velipekka.nousiai...@saunalahti.fi> wrote:
> One problem is
> that one needs to have & to do the list concatenation

Are you suggesting using "&" for concatenation? It might be too
confusing with "AND".

> Another is
> that old program should somehow have to "know"
> that you intended { lists } on your stack to be concatenated
> and another time
> that you stack was consisting of something else to be added
> => programs are broken anyway you try it
> because if "+" now all of a sudden add items in a list
> instead of concatenating lists
> then your programs work diffrently
> or
> can someone explain this?

What I was suggesting would not affect old programs at all. Old
binaries would run exactly as before. My suggestion was an optional
compile-time change rather than a run-time change.

-wes

Wes

unread,
Dec 4, 2010, 10:33:52 AM12/4/10
to
On Dec 2, 12:46 am, Andreas Möller <andreas_moellerNOS...@gmx.de>
wrote:

>  > Are such tools available to end users?
>
> all you need is
> 1. a binary of the ROM
> 2. Python
> 3. some knowledge
>
> All of this is freely available although one or another point might
> mean that one has to invest (or pay in) time.

I guess two out of three just won't cut it. :-)

-wes

John H Meyers

unread,
Dec 7, 2010, 10:15:11 AM12/7/10
to
On 12/1/2010 3:32 PM, Wes wrote:

>> But the source program is no longer valid, and can not be shared.

> Open it with the flag set appropriately and you're ready to share.

You posted TWO programs which show COMMANDS REVERSED in one of them.

Logic would suggest that both versions should not compile the same,
hence they either can not both be correct,
or else one of them is impossible to compile correctly,
under any circumstances at all, except possibly
for someone living in the alternate universe in the "Fringe" TV series :)

> If you mean re-compiling by opening and re-saving a program on the


> calculator, then regardless of how the flag is set, the editor would
> always compile the same way it decompiles. The binary would be
> unchanged.

Apparently I can not get across the idea that the problem
is that if one person posts a REVERSED version from his calculator,
then _a different person_ whose calculator isn't "doctored"
can not compile it correctly.

>> Human readers might also be among those who could no longer
>> unambiguously understand source programs,

> Which is why I was suggesting a CONCAT synonym for clarity.

And I've pointed out that this will not be able to compile at all
on any non-doctored, already-existing calculators,
which would again break series-wide compatibility.

>> You will remember that even in the HP48 series,
>> text-based programs, when exported from the calculator,
>> were supplied with a "mode line" such as "%%HP: T(3)A(D)F(.);"
>> so that the interpretation of the same source program
>> by any other calculator would automatically set those same modes
>> (for symbol "translation," angle interpretation,
>> and "radix" point/separator interpretation),
>> to thus assure an unambiguously correct interpretation of the text,
>> when re-compiled on any other calculator, at any time.

> Yet there's no such mode line indicator to tell whether a program was
> written in approximate mode or the exact mode that was introduced at
> some point. This can introduce some changes in the program, even when
> opened by the same calculator if the mode flags are not set the same,
> but we've learned to live with it.

This is a completely invalid comparison, because it does not
change any commands into some other commands,
it never "reverses" the meaning of any two commands or operators,
it has no impact whatsoever upon the sharing of source programs,
with unambiguous meaning, across the entire 49/50 series of calculators,
and no source program whatsoever that was output by an HP49 calculator
is ever backwards incompatible with an HP48 calculator,
unless it requires either commands or objects
that don't exist at all on HP48 calculators.

By the way, during development of the HP49G (first new series calculator),
JYA once said that he was going to introduce an element into the "%%HP" header
to account even for Exact/Approximate mode -- this would have been technically possible,
including backwards compatibility (ignoring on HP48 series),
by inserting it even before "%%HP" but it was just never done.

> I suspect that if my hypothetical editor ever existed,
> it would be common practice to always share source code
> with the editor flag set in the compatible mode.

You might as well assume that seat belts would always be fastened :)

>> In addition, compilation sometimes occurs even within programs,

> Good point. Such programs would have to be run in the mode they were
> written for. Anybody wanting to use the new command names could set
> the mode within the program. Older programs that use run-time
> compiling of "+" or "ADD" with lists would have to be run in
> compatible mode. (I wonder how often that occurs.)

Just as I'm wondering how often
algebraic expressions, generated at run-time
(since compile-time is taken care of by just writing the operator that you mean),
are evaluated with lists having been stored into its variables?

That's the only time that your original motivation for this exercise
ever actually comes up in real life, as far as I can see.

>> We've begun to see that it requires an ever-widening conspiracy
>> to try to catch all the loopholes and pitfalls
>> of a "compiler-based" approach,

> I'm sure I'm not seeing everything that a more knowledgeable person
> like yourself sees, but so far, the only big snag I see is the CAS.
> Depending on how the CAS generates code, it could be feasible or
> completely impossible.

Take a poll on that ;-)

>> Even if still considering a run-time approach,
>> a bit of thought might also need to be cast in the direction of
>> SysRPL programs, to see whether any other internal points in ROM
>> might also need to be trapped.

> Frankly, I don't see how a run-time approach could work.
> It would be even messier yet.

This sounds like modern political rhetoric,
unaccompanied by analysis,
while often accompanied by the most absurdly contorted
and incongruous legislative bills slapped together,
for no necessary reasons,
other than disharmonious facts of political life.

"Set a new flag whenever you want the + operator
to perform ADD during execution"

Tell me how much "messier" that would be than
"set a flag to reverse the meaning of ADD vs +
in both compiling and decompiling,
which also needs to be done for every result in the CAS,
and remember that you have to avoid publishing
any such "reversed source" output for anyone else to use,
but can only use it on your own calculator,
and even then only while the new flag is set."

Even the first of the last two paragraphs
would spoil the series-wide compatibility,
but it would require the least of all internal machinations in ROM,
as well as least of all external limitations to sharing programs
(other than being applicable to only one model
out of two series of formerly compatible calculators).

The second approach, on the other hand,
would introduce serious new risks and complications
(particularly the new risk of changing original source code)
even for programs (and data) that never involved any lists being
used as arguments/variables while evaluating algebraic expressions,
which have never had any issue in the first place.

By the way, you would also have to publish
two checksums per source program -- one for
"if new flag is set" and another for
"if new flag is cleared"

In no case would a run-time-only flag
increase complications for any program
needing + to perform both concatenation and addition (of lists)
at different points in the program, while retaining the meaning that
ADD always means addition -- it strikes me that anything else
that would _sometimes_ (unpredictably) make ADD mean concatenation
and + mean addition even for lists
is much more of a "bad thing" than you say it is
for + to have _always_ (never unpredictably) meant concatenation (of lists)
and ADD (or NEG -) having _always_ meant element-wise addition,
if only that it is far easier to deal with and manage predictable results
than with unpredictable outcomes, even in tough times :)

>> while for most people,
>> this entire topic never comes up, because variables which they
>> evaluate using algebraic expressions never take lists as their value.

> Considering how much care was taken to make list processing work on
> nearly every algebraic operation and mathematical function, it appears
> that the original programmers expected people to use it. I doubt if
> I'm the only user who finds this feature quite useful.

Two things have always existed, even in the HP48 series,
to make this entire discussion completely moot,
even as applies to the relatively rare evaluation
of algebraics generated during run-time,
into whose variables lists have been stored,
which, because of the very things about to be mentioned,
is the only case requiring any extra attention at all,
aside from writing correct programs (and formulas)
in the first place, which you can always do:

(a) The ADD command was introduced to unambiguously mean, for lists,
an element-wise addition. This is certainly applicable, at no effort,
to every non-algebraic program, across all HP48G/49G/50G series calculators,
and can even be used within algebraic objects, as also can -NEG(x) in algebraics
or NEG - in RPL, not even bothering to require an ADD command, so that
even the ADD command is just an added convenience that was never actually essential
(except, to be even more picky, if applying algebraics to lists of strings :)

This has always made everything absolutely unambiguous --
"+" always means one thing, and "ADD" or "NEG -" always means another,
with both meanings happening to coincide
for any arguments other than lists or strings (anything else?),
and that very fact has, before the threat of these new suggestions,
been absolutely reliable, which has a great inherent value,
whose destruction should be weighed against so small and rare a gain,
which "gain" can even be produced more easily via another way anyway.

So, other than for formulas dynamically generated at run time,
there is no need whatsoever for a "solution" to a non-existent problem;
just write programs using the command or operator that means what you want!

(b) The MATCH commands can be applied, at run-time, to any algebraic object
produced at run-time (even by the CAS, say) to eliminate +
from any formula that's produced at run-time;
this is no more complex than any other algebraic transformation command,
requires introducing no new flag, is compatible across all HP49G/50G series
_and_ HP48G series calculators at the same time,
and could neatly eliminate the entire issue via one tiny program,
so who needs to upset everything else so drastically,
and with great impact to general HP4xG* compatibility across the board,
just to avoid using such a simple thing instead?

In addition, in the HP49/50 series, the alternate "list" type 29
(a/k/a "Symbolic Matrix") works fine with "+" as element-wise addition anyway.

In case you are still determined to pursue either your original thought,
involving both run-time and compile-time makeovers, or even just
a run-time makeover of one command, here's yet another detail to consider
(illustrating the need to think designs completely through
before building an expensive bridge which soon collapses):

Besides the previously cited run-time compiling action of SEQ,
and the run-time algebraic result-producing action of all CAS commands,
as well as some non-CAS commands,
what about the additional STO+ command?

{ 1 2 } 'X' SWAP OVER STO 3 STO+ @ 'X' now contains { 1 2 3 }

Lesson from history: November 7, 1940
http://www.youtube.com/watch?v=P0Fi1VcbpAI
http://www.youtube.com/watch?v=j-zczJXSxnw
http://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge

Why can't you just "learn to live with" (as you said yourself above)
the fact of how this series of calculators has evolved,
with the meaning of "+" for lists established from the outset by precedent,
as they say in the U.S. Supreme Court, with one viable alternative
(NEG -) always existing anyway, another (ADD) also provided,
to accommodate later developments, plus a trivial program available
for run-time adjustment of any algebraic (using either NEG - or ADD),
and wait for an essentially new product to be launched,
before drastically rocking that well-established boat
(with its accompanying treasure of well-established software)?

A 1955 classic:
http://www.youtube.com/watch?v=o7kzsZreG0o
http://en.wikipedia.org/wiki/Guys_and_Dolls_(film)

[r->] [OFF]

Wes

unread,
Dec 8, 2010, 2:28:57 PM12/8/10
to
On Dec 7, 6:15 pm, John H Meyers <jhmey...@nomail.invalid> wrote:
> You posted TWO programs which show COMMANDS REVERSED in one of them.
>
> Logic would suggest that both versions should not compile the same,
> hence they either can not both be correct,
> or else one of them is impossible to compile correctly,
> under any circumstances at all, except possibly
> for someone living in the alternate universe in the "Fringe" TV series :)

Well, that or someone who set the suggested compatibility flag
appropriately.

> Apparently I can not get across the idea that the problem
> is that if one person posts a REVERSED version from his calculator,
> then _a different person_ whose calculator isn't "doctored"
> can not compile it correctly.

Of course, which is why anybody posting code should post the code with
the editor flag set appropriately.

> > Which is why I was suggesting a CONCAT synonym for clarity.
>
> And I've pointed out that this will not be able to compile at all
> on any non-doctored, already-existing calculators,
> which would again break series-wide compatibility.

Again, code should be shared in compatibility mode.

> This is a completely invalid comparison, because it does not
> change any commands into some other commands,
> it never "reverses" the meaning of any two commands or operators,
> it has no impact whatsoever upon the sharing of source programs,
> with unambiguous meaning, across the entire 49/50 series of calculators,

Sure it can impact. << 123456 SIZE >> gives two different answers on
the same 50 depending on the mode at compile time.

> > I suspect that if my hypothetical editor ever existed,
> > it would be common practice to always share source code
> > with the editor flag set in the compatible mode.
>
> You might as well assume that seat belts would always be fastened :)

By making the flag default to the compatible mode, most won't even
know they are wearing a seat belt. Only those that care to change the
setting would do so, and those that did would know how to change it
back.

(It's a learned behavior. When I was a kid, we never wore seat belts,
but it's been 30+ years since the last time I didn't wear one,
probably due to either high school physics or those films in driver's
ed.)

> Just as I'm wondering how often
> algebraic expressions, generated at run-time
> (since compile-time is taken care of by just writing the operator that you mean),
> are evaluated with lists having been stored into its variables?

I don't know that I ever need to evaluate algebraics with lists stored
in global variables, but I should would use algebraic functions that
allowed list arguments (local variables).


> "Set a new flag whenever you want the + operator
> to perform ADD during execution"
>
> Tell me how much "messier" that would be than
> "set a flag to reverse the meaning of ADD vs +
> in both compiling and decompiling,

The difference being that the compile time idea allows a user to use
the calculator interactively with consistent operator behavior while
still being able to use old programs.

If I had to switch flags every time I wanted to run an old program,
well, even _I_ wouldn't be willing to do that.


> By the way, you would also have to publish
> two checksums per source program -- one for
> "if new flag is set" and another for
> "if new flag is cleared"

I think just the compatible one would be the common practice.

> what about the additional STO+ command?

I'd be happy to leave the STO+ command as it is. I use this command
in programs, but rarely in interactive use.

> Why can't you just "learn to live with" (as you said yourself above)
> the fact of how this series of calculators has evolved,
> with the meaning of "+" for lists established from the outset by precedent,

I likely will have no choice, but that doesn't stop me from aspiring
for improvements. I understand the history of + from my 28C days.
But I suspect the vast majority of new users don't know (or care)
about this history.

I think our points boil down to "I think it would be worth it if ..."
vs. "I don't think it would be worth it if ..."

My intention was to raise the issue to anybody who might be in a
position to affect change. If nothing can be done, then so be it, but
my hope is that the idea would at least be considered.

-wes

John H Meyers

unread,
Dec 8, 2010, 10:24:30 PM12/8/10
to
On 12/8/2010 1:28 PM, Wes wrote:

> << 123456 SIZE >> gives two different answers on
> the same 50 depending on the mode at compile time.

Are you trying to justify breaking
the existing entire series compatibility with an example
of the only "straw grab" that can be made -- that the only
compile-time influence you can have is to decide to interpret
"whole" numbers as real numbers -- a setting basically
making it possible to import all HP48 series programs
in a completely compatible manner, not needed for anything else,
which is also compatible across all calculators of the 49/50 series,
so that you can leave a calculator permanently in "Exact" mode
for any other use than compiling HP48 series programs?

This is nothing like interpreting all "+" as ADD and all ADD as "+"
(depending on a new flag) in a "new ROM"
which could exist only for one new model calculator.

The present decompiler, after STD 64 STWS for numeric display modes
(which is set automatically by the on-calculator editor,
or by calling internal function EDITDECOMP$),
can output only one, absolutely unambiguous version of a program,
and any member of the series, in Exact mode,
can compile that in only one way,
and that's what you would be breaking with your scheme.

> The difference being that the compile time idea allows a user to use
> the calculator interactively with consistent operator behavior while
> still being able to use old programs.

"Interactively" -- that's the key to everything you want,
and I'll get to that before this post ends.

Meanwhile, I'm obliged to point out, again,
that no algebraic result of any operation
has anything to do with the compiler, so let even a single
"+" sign appear in any algebraic formula (or even press the "+" key
to interactively act on stack objects), and now you also need
a RUN TIME modification to change its interpretation with lists.

If this is not yet understood after several postings,
I apologize for my inability to get it across.

> If I had to switch flags every time I wanted to run an old program,
> well, even _I_ wouldn't be willing to do that.

You are responding here to it having been pointed out
that compiler/decompiler modification ideas alone are insufficient
to accomplish what you want (see above), hence that
RUN TIME modifications would also be necessary
(actually, run-time modifications alone would be nearly sufficient),
and that these would HAVE TO be dependent
on the same new flag which you propose.

That being established as the context of this hypothetical case,
did you know that you can insert flag-setting commands into programs
(or even into "wrappers" that call other programs),
so that you don't have to do that manually before running them?

If what you said were even true,
then you still could not use old binary programs,
as you formerly claimed you could,
because wherever they have "+" operations,
and you want to use those with lists in your new way,
they would still not work that way, unless you had
RUN TIME modifications to re-interpret those operations.

If you say that oops, you mean that you can re-compile
the old source programs, rather than run their binaries,
remember that if a program contains some "+"
that are supposed to mean concatenation,
and other "+" that are supposed to mean addition,
your "compiler modification" scheme can not handle
having BOTH needs within any single program,
which is why you then had to invent a new "CONCAT" command,
which you would have to substitute for some of the "+" in old programs,
and CONCAT would not be compatible with any older member of the series,
as often happens when one starts playing "musical chairs"
with never enough chairs to accommodate everyone at the same time :)

Meanwhile, with your compiler/decompiler idea, I would actually have to keep
flipping your new flag every time I wanted to EDIT an "old" program,
so your own scheme has exactly the same issue as you just objected to,
just at a different time.

> I don't know that I ever need to evaluate algebraics with lists stored
> in global variables, but I should would use algebraic functions that
> allowed list arguments (local variables).

It's basically the same idea -- the only time that the issue you raise
comes up is when you evaluate algebraic expressions containing "+"
in which _lists_ have been stored into some of their variables
("local" vs. "global" variables is not a significant distinction).

For this case, all you need do is use ADD (or NEG -) in place of "+"
in the expression embedded within the procedure.

A dynamically generated expression would not be in any such function,
because you have to compile such functions in advance,
so you can ALWAYS personally decide to use ADD for addition in those functions,
unless avoiding those extra keystrokes are worth all the other trouble
that the stated proposal would stir up,
if made part of any future ROM update in this calculator series.

> I'd be happy to leave the STO+ command as it is.
> I use this command in programs, but rarely in interactive use.

I see -- you want a ROM modification to suit your own personal _interactive_ use,
because you don't feel like writing ADD (or NEG -) in your own static formulas,
nor are you willing to use a MATCH command (or call a program to do it)
after producing new formulas dynamically, and if other areas
(e.g. the entire CAS, and STO+, perhaps elsewhere that we've forgotten)
would still need major work to make the idea consistent, including at run time,
and if older models of the series would be unable to handle new programs, etc.,
then no need to care about all that, as long as it doesn't affect you?

This is all completely fine, as long as you make a personal,
customized ROM for yourself, for your personal, interactive use,
and do not propose it as an official product for general use.

By the way, the "Vectored ENTER" feature was designed to give you
your own customized, interactive environment to do all these things --
with this feature, you can automatically modify
anything you produce using the on-board editor
before it gets compiled (e.g. replace all "+" with " ADD "),
and/or you can also automatically modify any stack results
(e.g. to similarly eliminate "+" from any dynamically produced formulas).

For intercepting direct interactive use of the "+" key to add things,
the additional built-in calculator-customizing feature for this
(which no compiler/decompiler modifications could ever achieve)
is called a "user key assignment," as you know,
and the ADD command is what you could assign to that key.

So, instead of looking in the direction
of extremely difficult modifications to ROM,
each of which brings along the need to modify even more things,
breaks compatibility, etc., why don't you employ the effective
interactive environment customizing features,
which were put in the calculator for just these purposes,
to accomplish all that you want,
with no impact to the community of all other users, of all other models,
by using already built-in abilities, immediately and effortlessly?

[r->] [OFF]

Reply all
Reply to author
Forward
0 new messages