61 views

Skip to first unread message

Oct 25, 2002, 7:24:32 PM10/25/02

to

While compiling a collection of User RPL trivia, the following

questions arose and stumped me. Anybody out there know the answers to

any of these, or know where a pointer is to the answer(s)?

questions arose and stumped me. Anybody out there know the answers to

any of these, or know where a pointer is to the answer(s)?

(1) The 49G's XSERV command accepts "l" (a *lower-case* L, not a "1")

as an input command. What does "l" do?

(2) What companies other than HP *ever* made RPN calculators?

(3) Is the 49G's MAP command the same as DOLIST? They seem identical.

(4) How is the 49G's DRAW3DMATRIX command and/or plotter mode used?

(5) On the 49G, XLIB 2 392 has no name, and when its contents are

recalled to the stack, it is "displayed" as an invisible object which

disassembles into System RPL as "xCMDAPPLY". Is this command really

"User RPL"? If so, what does it do and how is it used?

Thanx in advance!

-Joe-

Oct 25, 2002, 8:28:49 PM10/25/02

to

In article <1050661f.02102...@posting.google.com>, joe...@jps.net

(Joseph K. Horn) writes:

(Joseph K. Horn) writes:

>(2) What companies other than HP *ever* made RPN calculators?

>

Sinclair sold an RPN pocket calculator. Pi was printed on the case, as well as

a factor for Deg to radians. This calculator was even sold in kit form for a

while. I still have mine around somewhere if you need the details.

Also, if you want to go back even further, the old Friden mechanical

calculators were RPN of sorts. You put in one operand, you put in the other

operand on another keyboard, and you press multiply. BTW, Friden had a

mechanical calculator that could do square roots. My favorite was a Monroe

calculator, where you had to manually shift the carriage with a knob at the

bottom of the calculator for both the multiplies and the divides.

Bill

alternate E-dress wtst...@ieee.org.no.spam.please

(Use the obvious)

Oct 25, 2002, 8:32:32 PM10/25/02

to

Joseph K. Horn <joe...@jps.net> wrote:

> (2) What companies other than HP *ever* made RPN calculators?

> (2) What companies other than HP *ever* made RPN calculators?

While not 'true' RPN (4 level stack, etc.), National Semiconductor made

the Mathbox series in the late '70s that worked via postfix. Their

calculator operation later went by the "Novus" name.

Jim Horn

Oct 25, 2002, 9:18:31 PM10/25/02

to

> A jurk ?

Who know RPN or RPL or what, better than the lines in "his" ( not her )

right hand?

"James Horn" <jim...@svn.net> wrote in message

news:3db9...@news.svn.net...

Oct 26, 2002, 12:48:56 AM10/26/02

to

Asked:

> What companies other than HP *ever* made RPN calculators?

All the mechanical calculators that I can recall

(including Curta) -- number entry always had to

precede turning the crank (or other "operation" activator)!

http://www.geocities.com/oldcalculators

http://www.geocities.com/oldcalculators/contex.html

http://vcalc.net/cu.htm

Also, all the early electronic calculators that I ever saw,

prior to TI's Datamath (2500), the first I ever saw which

had a key containing no other symbol than [=]:

http://www.datamath.org and http://www.datamath.org/Album_Basic.htm

All calcs of my earlier experience

required number entry *before* the [+=] or [-=] key,

which then immediately performed addition or subtraction,

although most were a little bit "hybrid,"

in that [*] or [/] were "infix" rather than "postfix"

with the [+=] or [-=] key completing the operation

and also then accumulating results in a postfix fashion:

http://www.classiccmp.org/calcmuseum/EarlySharp.htm

In fact, here it is asserted that "All calcs were once RPN!":

http://groups.google.com/groups?selm=59dcb4%2499t%40news.iastate.edu

[r->] [OFF]

.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----

http://www.newsfeeds.com - The #1 Newsgroup Service in the World!

-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Oct 26, 2002, 1:10:08 AM10/26/02

to

Oct 26, 2002, 3:03:06 AM10/26/02

to

Asked:

> On the 49G, XLIB 2 392 has no name, and when its contents are

> recalled to the stack, it is "displayed" as an invisible object

> which disassembles into System RPL as "xCMDAPPLY".

> Is this command really "User RPL"?

> If so, what does it do and how is it used?

`R\->C(A,B)`

Decompiles to:

::

xEVAL>

::

ID A

ID B

SYMBOL

xR\->C

;

# 2

xCMDAPPLY

;

;

Somewhat analogous to this:

'MYFCN(X,Y)'

Decompiles to:

SYMBOL

ID X

ID Y

SYMBOL

ID MYFCN

;

BINT2

xFCNAPPLY

;

Notice how the first example produces # 2 instead of BINT2?

Okay, WR, better rewrite that ROM code for JYA to save 2.5 bytes!

[r->] [OFF]

Oct 26, 2002, 5:29:11 AM10/26/02

to

John H Meyers wrote:

> Okay, WR, better rewrite that ROM code for JYA to save 2.5 bytes!

> Okay, WR, better rewrite that ROM code for JYA to save 2.5 bytes!

Theoretically, I could do this and I guarantee

that the rewritten ROM would be 25% smaller than

the present one, without loss in functionality

and speed. That would save about 250 KB, that is

to mean 2 flashbanks! Unfortunately, such a project

would need about 5 years work, day and night :-)

- Wolfgang

Oct 26, 2002, 6:41:53 AM10/26/02

to

Asked:

> Is the 49G's MAP command the same as DOLIST? They seem identical.

My mother and her sister seemed identical [twins] to everyone else,

but not to me ;-)

Why do CASCMD and HELP say that MAP

"Executes a program on the elem. of a list"

when this is only an accidental consequence

of "automatic list processing,"

plus a liberal attitude to what arg type

(any!) is acceptable on level 2?

Let's compare results:

1 { 2 3 } 1 \<< + \>> DOLIST ==> 6

1 { 2 3 } \<< + \>> MAP ==> Error: Too Few Arguments

{ 2 3 } 1 \<< DUP \>> DOLIST ==> { 2 2 3 3 }

{ 2 3 } \<< DUP \>> MAP ==> { { 2 2 } { 3 3 } }

{ 2 3 } 1 \<< DROP \>> DOLIST ==> Empty stack

{ 2 3 } \<< DROP \>> MAP ==> { NOVAL NOVAL }

DEG { 30. } \<< SIN \>> DOLIST ==> { .5 }

DEG { 30. } \<< SIN \>> MAP ==> { -.988031624093 }

By the way, does DOLIST force you to change modes

and delete your current variable?

I thought that MAP (Matrix APply) was really intended

to operate on the elements of an *array*

(a built-in version of Teach: APLY from the 48G):

[ 2 3 ] \<< SQ \>> MAP ==> [ 4 9 ]

[ 2 3 ] 1 \<< SQ \>> DOLIST ==> Error: Bad Argument Type

That HELP was probably written late on the night of the 49G's

"coming out party" in France -- what were they drinking? ;-)

Oct 26, 2002, 7:21:17 AM10/26/02

to

Huh..

DOLIST must be the most complicated RPL command.

DOLIST must be the most complicated RPL command.

My list of complicated RPLs:

-DOLIST

-SEQ

-STREAM

-DOSUBS

-(pile_up)MATCH

"John H Meyers" <jhme...@miu.edu> wrote in message

news:3DBA7171...@miu.edu...

Oct 26, 2002, 8:03:41 AM10/26/02

to

Per Blomqvist wrote:

> DOLIST must be the most complicated RPL command.

> My list of complicated RPLs:

> -DOLIST -SEQ -STREAM -DOSUBS -MATCH> DOLIST must be the most complicated RPL command.

> My list of complicated RPLs:

Complicated? Apart from the last one the

others are perfectly described in the HP48

docs (i.e., in ENGLISH, not in FRANGLAIS,

hardly readable at least for a German :-)

If you do not know what is complicated then

learn SysRPL. There you meet commands (like

ParOuterLoop) which are really complicated.

- Wolfgang

PS. I've the feeling that precision and care in

language gradually declines. Consider only the

perfect description of Dave Arnett in

http://groups.google.com/groups?selm=4olc27%24104%40hpcvsnz.cv.hp.com

This was more or less the standard a couple of

years ago. Clearly, one cannot expect a perfect

english text from a Frenchman or a German, but

IMHO, these (and others) should concentrate as

much as possible before going to write something

in English.

- Wolfgang

Oct 26, 2002, 9:08:45 AM10/26/02

to

"Wolfgang Rautenberg" <ra...@math.fu-berlin.de> wrote in message

news:3DBA849D...@math.fu-berlin.de...

> Per Blomqvist wrote:

> > DOLIST must be the most complicated RPL command.

> > My list of complicated RPLs:

> > -DOLIST -SEQ -STREAM -DOSUBS -MATCH

>

> Complicated? Apart from the last one the

> others are perfectly described in the HP48

> docs (i.e., in ENGLISH, not in FRANGLAIS,

> hardly readable at least for a German :-)

>

> If you do not know what is complicated then

> learn SysRPL. There you meet commands (like

> ParOuterLoop) which are really complicated.

Oooh.. hard nutcase.

I can't find "ParOuterLoop" in my sysRPL-reference.

> - Wolfgang

>

> PS. I've the feeling that precision and care in

> language gradually declines. Consider only the

> perfect description of Dave Arnett in

> http://groups.google.com/groups?selm=4olc27%24104%40hpcvsnz.cv.hp.com

> This was more or less the standard a couple of

> years ago. Clearly, one cannot expect a perfect

> english text from a Frenchman or a German, but

> IMHO, these (and others) should concentrate as

> much as possible before going to write something

> in English.

>

> - Wolfgang

PS. I'm Swedish non Schroder sucker. We do not DUB movies for television, as

Germans/French does ( no offense ).

Oct 26, 2002, 10:59:40 AM10/26/02

to

John H Meyers wrote:

> { 2 3 } 1 \<< DROP \>> DOLIST ==> Empty stack

> { 2 3 } \<< DROP \>> MAP ==> { NOVAL NOVAL }

> { 2 3 } 1 \<< DROP \>> DOLIST ==> Empty stack

> { 2 3 } \<< DROP \>> MAP ==> { NOVAL NOVAL }

That <<DROP>> DOLIST yields no output seems to be

not very intuitive. The {NOVAL NOVAL} looks slightly

better, but the most natural output seems to be the

empty list. At least, the DOL command from OT49 and

the DOL command from OT48 do it this way. That avoids

unpleasant treatment of special cases in programming.

For a SysRPL-programmer, DOLIST is an inacceptable

command. It is awfull slow and not well programmed.

For instance, it writes first a list of 3 nulllams,

then a list of 2 nulllams and performs the sedate

&COMP command before binding 5 nulllams. :-)

> That HELP was probably written late on the night of the 49G's

> "coming out party" in France -- what were they drinking? ;-)

Interesting question. It seems to me that also DOLIST

was written late on the night of the 48G's "coming out

party" in Corvallis (what were they drinking there? ;-)

Seriously, I believe that the Corvallis team thaught

on using list and other user commands like VARS in

simple UsrRPL-programs only. Hence, they didn't pay

too much attention on speed. But the 49 has a larger

memory base and is more ambitious in general. Hence,

DOLIST should have been rewritten. The same concerns

painful slow rompointers like RCLKEYS, STOKEYS etc.

Both the OT48 DOL and the OT49 DOL are much faster than

DOLIST. The OT48-DOL uses CACHE. But this is nearly as

powerful as the Virtual stack used for the OT49-DOL

because one may call nulllams from the cached stack

ad libitum. Thus, a programmer can define his nulllams

above the three ones used by the DOL program itself.

- Wolfgang

Oct 26, 2002, 2:01:51 PM10/26/02

to

Thanks, everybody! You're the best!

-jkh-

Oct 26, 2002, 3:41:37 PM10/26/02

to

joe...@jps.net (Joseph K. Horn) wrote in message news:<1050661f.02102...@posting.google.com>...

hi!

> (2) What companies other than HP *ever* made RPN calculators?

i got an MK61 and an MK52 (their names sound like a rifle). they are russian.

> -Joe-

regards

Oct 27, 2002, 7:13:06 AM10/27/02

to

Why not let a desktop computer to do the search & replace?!

VPNnews:3DBA6067...@math.fu-berlin.de...

VPNnews:3DBA6067...@math.fu-berlin.de...

Oct 28, 2002, 5:25:56 PM10/28/02

to

On Sat, 26 Oct 2002 13:08:45 GMT, Per Blomqvist <per.bl...@telia.com> wrote:

>

>PS. I'm Swedish non Schroder sucker. We do not DUB movies for television, as

>Germans/French does ( no offense ).

>

>PS. I'm Swedish non Schroder sucker. We do not DUB movies for television, as

>Germans/French does ( no offense ).

Do you watch many films which help you learn the English required for

writing calculator manuals?

A bientot

Paul

--

Paul Floyd http://paulf.free.fr (for what it's worth)

What happens if you have lead in your pants as well as lead in your pencil?

Oct 29, 2002, 5:20:18 AM10/29/02

to

Paul Floyd wrote:

>

> On Sat, 26 Oct 2002 13:08:45 GMT, Per Blomqvist <per.bl...@telia.com> wrote:

> >

> >PS. I'm Swedish non Schroder sucker. We do not DUB movies for television, as

> >Germans/French does ( no offense ).

>

> Do you watch many films which help you learn the English required for

> writing calculator manuals?

>

> On Sat, 26 Oct 2002 13:08:45 GMT, Per Blomqvist <per.bl...@telia.com> wrote:

> >

> >PS. I'm Swedish non Schroder sucker. We do not DUB movies for television, as

> >Germans/French does ( no offense ).

>

> Do you watch many films which help you learn the English required for

> writing calculator manuals?

You can laugh about it, but it does help!

When I hear a german or Frenchman speak English I have to pay quite a

lot of

attention to understand what they are saying. (Not as much as with

Indians, Chinese

or Nigerians though). When I hear the Danish speak English it is like

listening to an Englishman, no problem whatsoever.

Us non-dubbing countries all learn the american language very well from

movies

and other american TV. In the Netherlands people learn French, English

and german in

highschool but only the English language is really spoken by everybody.

My hypothesis

is that this is due to the american movies and TV

--

ir. P.F.Geelhoed

Delft University of Technology

Laboratory for Aero & Hydrodynamics

Leeghwaterstraat 21, 2628 CA Delft, The Netherlands

+31-15-2786656 / +31-15-2782947 (fax)

Oct 29, 2002, 5:40:37 AM10/29/02

to

rc...@eng.morgan.edu (rcobo) wrote in message news:<639cb51.02102...@posting.google.com>...

Wow! Where did you get them? Since years and years I am looking for

the MK90 or MK98 but in vain. Do you know any

shop/man/women/alien/Greek that sells MK calculators?

Look:

MK90 -> http://www.taswegian.com/MOSCOW/mk-90.html

MK98 -> http://www.taswegian.com/MOSCOW/mk-98.html

Greetings,

Nick.

Oct 29, 2002, 10:33:31 AM10/29/02

to

> John H Meyers wrote:

> > Okay, WR, better rewrite that ROM code for JYA to save 2.5 bytes!

> > Okay, WR, better rewrite that ROM code for JYA to save 2.5 bytes!

John, you probably wouldn't comment it this way if

Mika Heiskanen were the ROM-author. But also this

greatest master of RPN-programming did not always

find the optiomal program. Here an example, the

famous UP from his HACK-lib which returns to the

correct page of the parents directory. By the way,

I wonder that ACO didn't use this UPDIR version which

is *obviously much better* than the ordinary UPDIR

(excuse with backward compatibility doesn't count)

Here Mika's program, 80.5 bytes:

::

CKO

CONTEXT@

UPDIR

CONTEXT@

2DUPEQ

case2DROP

LastNonNull (get first object in parents dir)

NotcaseDROP

MINUSONE

UNROT

BEGIN (begin search of the just left dir)

ROT#1+ROT (in the vars of the parents dir)

2DUPEQ

ITE

DROPFALSE

PrevNonNull

NOT_UNTIL

DROP (DROP left dir and find correct page)

SIX

#/

SWAPDROP

UNCOERCE

%1

%OF (take 1% of the real)

% 2.01

%+ (correct page code computed)

InitMenu%

;

Now my version, 72.5 bytes, 8 bytes saved)

::

CKO

CONTEXT@

UPDIR

CONTEXT@

2DUPEQ

case2DROP

LastNonNull (get first object)

DROPZERO (parents dir is not empty and I start)

UNROT (counting with ZERO, not MINUSONE)

BEGIN

ROT#1+ROT

2DUPEQ

ITE

DROPFALSE

PrevNonNull

NOT_UNTIL

DROP#1- (DROP and correct the count)

SIX

#/

#1+ (enlarge the result somewhat)

UNCOERCE

%1

%OF

%2

%+

InitMenu%

DROP

;

In addition, I use DROP, not SWAPDROP, which

saves time: DROP lasts 0.03_ms, SWAPDROP 0.06_ms,

mearure on the HP48 under normal conditions.

The essential difference is that I use the pointer

%2 instead of the real % 2.01. It should be mentioned

that invoking either these or the other makes no

difference. Both need 0.05_ms according to Mika's TIM.

My UPDIR-version will be a key assignment choice in

the mext edition of the 49 Keyman coming out soon.

- Wolfgang

Oct 29, 2002, 12:50:30 PM10/29/02

to

Wolfgang Rautenberg wrote:

>

> > John H Meyers wrote:

> > > Okay, WR, better rewrite that ROM code for JYA to save 2.5 bytes!

>

> John, you probably wouldn't comment it this way if

> Mika Heiskanen were the ROM-author.

>

> > John H Meyers wrote:

> > > Okay, WR, better rewrite that ROM code for JYA to save 2.5 bytes!

>

> John, you probably wouldn't comment it this way if

> Mika Heiskanen were the ROM-author.

I think you misunderstand; it wasn't a stab at JYA

Oct 29, 2002, 2:12:16 PM10/29/02

to

Peter Geelhoed wrote:

> I think you misunderstand; it wasn't a stab at JYA

> I think you misunderstand; it wasn't a stab at JYA

I don't remember to have claimed that. By the way,

could you sent me

1. the flashbank 0 of ROM 19-6 (has less than

128 KB), as a BZ-file please, to have a short

downloading time with XMODEM. I'll save it

port 2, please determmine the name for it.

2. A tool which switches two different flashbanks 0.

The one presently used with the other one which

should be a backup in port 2. Clearly, the tool

should be for the real 49, not for an emulator.

If unavoidable, the switching process may last some

minutes but should be as short as possible. It may

well be that in future the user will have a certain

choice not only on the entire ROM but also on a

particular flashbank 0.

- Wolfgang

Oct 29, 2002, 8:11:01 PM10/29/02

to

Seen:

> { 2 3 } 1 \<< DROP \>> DOLIST ==> Empty stack

> { 2 3 } \<< DROP \>> MAP ==> { NOVAL NOVAL }

> That <<DROP>> DOLIST yields no output seems to be

> not very intuitive. The {NOVAL NOVAL} looks slightly

> better, but the most natural output seems to be

> the empty list.

Yes, had I been employed in the 48G development team in Corvallis,

I certainly would have tried to have the "no results" case for

DOLIST return an empty list, because the lack of returning anything

at all creates a significant flaw in the RPL scheme of things,

violating that most sacred Commandment of RPL --

"thou shalt not leave the programmer with no clue at all

as to how many objects might have been returned on the stack!"

In this case, the command can return as its result

either one object (a list) or no object at all,

but it leaves no indicator of which way it turned out!

This would have been pretty darned easy to fix, also,

requiring only the most minor adjustment to what looked like

a common ending point for DOLIST, DOSUBS, and even the SEQ command,

all of which are blighted by violating said Commandment.

I can understand what may have motivated you-know-who

to not bother returning an empty list -- sometimes you might

employ DOLIST etc. to, well, perhaps purge each one of a list of

variables (using either PURGE or PGDIR according to its type), say.

By having DOLIST "drop the useless empty return list for you,"

why, you could save one whole extra command (a final DROP),

which really sounds like a big convenience, right?

The only flaw to this "corner-cutting" is that many valuable

uses for the DOLIST family of commands involve testing

each list item, and then returning something or not,

independently for each item (example: return a list

of items that are common to a pair of original lists).

In all such more interesting programs, the user now must

perform contortions to get a possibly correct empty list as output,

because of how DOLIST etc. won't return an empty list by itself,

and gives you no clue at all when it decides not to; fixing this

flaw then usually takes much more effort than adding one single

DROP command to what otherwise would have been much simpler tasks.

Treating an empty input list as an error seemed also to be

unfortunate; there is a reason why SigmaLIST, PiLIST and STREAM

are logically unable to accept empty input lists,

but why impose that same handicap on DOLIST etc.?

(note that SORT, TAIL, and REVLIST don't choke on empty lists!)

As to less than optimal coding of some internal ROM functions, well,

of course there is! "Life is short, and even if ROM wasn't full,

there was plenty that was more important to get done!"

A more valuable target for optimizing might be MS operating systems :)

But I already said all of this before:

"Normalizing DOLIST & DOSUBS" 1996/05/27

http://groups.google.com/groups?threadm=4objjg%24cq5%40news.iastate.edu

http://groups.google.com/groups?selm=4oavin%246vr%40news.iastate.edu

http://groups.google.com/groups?selm=4oelu5%248an%40news.iastate.edu

Surprises about SEQ (plus "coding fix" for the end of DOLIST etc.):

http://groups.google.com/groups?selm=6f7r50%24qdq%241%40news.iastate.edu

By the way, it may also be noted that SigmaLIST and PiLIST

(sum and product of list elements) won't even accept

a list of *one* element! (Error: Invalid Dimension!)

Man, isn't it frustrating enough to have to deal every day

with the equally skewed mindset of the folks at MS?

And likewise, a mindset of similarly ineffective ways of dealing

with the entire world, from most of those who live on it.

"Everyone on board our Spaceship Earth can live abundantly

and successfully... Humanity has the option to make it.

We must choose it before it expires..."

"Whether it is to be Utopia or Oblivion will be

a touch-and-go relay race right up to the final moment."

- Buckminster Fuller 1980

"When I was born, humanity was 95 per cent illiterate.

Since I've been born, the population has doubled and that total

population is now 65 per cent literate. That's a gain of 130-fold

of the literacy. When humanity is primarily illiterate,

it needs leaders to understand and get the information

and deal with it. When we are at the point where

the majority of humans themselves are literate,

able to get the information, we're in an entirely new relationship

to the Universe. We are at the point where

the integrity of the individual counts,

and not what the political leadership

or the religious leadership says to do."

"It's a matter now of humanity getting to the point where it's now

qualifying to make some of its own decisions in relation to its own

information. That's why we've come to a new moment of integrity."

http://www.bfi.org

http://www.bfi.org/operating_manual.htm

http://www.mum.edu

Oct 29, 2002, 9:17:24 PM10/29/02

to

Hello

"Peter Geelhoed" <pe...@dutw1479.wbmt.tudelft.nl> wrote in message

news:3DBECA66...@dutw1479.wbmt.tudelft.nl...

> I think you misunderstand; it wasn't a stab at JYA

>

And I do not take offence whatsoever as the code is generated by the

algebraic compiler (pure ML) and this was made by Gerald Squelart :)

Sometimes, time is the most important issue, didn't have too much time to

optimized UPDIR so it would save 8 bytes and save .05ms ...

Jean-Yves

Oct 30, 2002, 5:04:52 AM10/30/02

to

I knew you could do it!

Saving 8 bytes per day can mount up to 2922 bytes saved

per (average) year, which will save 128K (one whole flash bank)

in only 44.857 years!

Oct 30, 2002, 6:07:09 AM10/30/02

to

Squelch squealing on Squelart for squandering!

Oct 30, 2002, 6:45:01 AM10/30/02

to

> By the way, it may also be noted that SigmaLIST and PiLIST

> (sum and product of list elements) won't even accept

> a list of *one* element! (Error: Invalid Dimension!)

> (sum and product of list elements) won't even accept

> a list of *one* element! (Error: Invalid Dimension!)

Easy.

0 + SigmaLIST

1 + PiLIST

Nick.

Oct 30, 2002, 7:55:33 AM10/30/02

to

NK:

[re summing 1-element lists]

> 0 + SigmaLIST

> 1 + PiLIST

Valid only if you know in advance that you are restricting input

only to lists of *numbers* (see below).

In that case, how about these, for possible empty lists as well:

0 + 0 + SigmaLIST

1 + 1 + PiLIST

But let's take a closer look:

{ 1 2 3 } SigmaLIST = 6

{ 1 2 } SigmaLIST = 3

{ 1 } SigmaLIST = 1 But this errors!

{ } SigmaLIST = 0 ? Also errors.

{ [1] [2] [3] } SigmaLIST = [6]

{ [1] [2] } SigmaLIST = [3]

{ [1] } SigmaLIST = [1] But this errors!

{ } SigmaLIST = [0] ? Also errors.

{ "1" "2" "3" } SigmaLIST = "123"

{ "1" "2" } SigmaLIST = "12"

{ "1" } SigmaLIST = "1" But this errors!

{ } SigmaLIST = "" ? Also errors.

Note that to handle more general one-element lists,

the simplest, more general work-around might be:

\<< IF DUP SIZE 1. == THEN 1. GET ELSE SigmaLIST END \>>

However, note that this doesn't trap { \<< program \>> }

as invalid input, which might have been the original 48G

rationale for the slightly lazy rejection by ROM coding

of summing (or taking the product of) any 1-element lists at all;

in fact, these are implemented essentially identically to the

STREAM command, which also balks on empty or single-element lists.

There is *no* way to properly handle the general case of

"summing" an empty list, as can be seen by the fact that

each of the above three examples of { } SigmaLIST

seems to suggest a different answer!

In other words, with an empty list, the unanswerable question

remains: an empty list of what "null-value object" ?

Or, "what is the sound of nothing clapping?" ;-)

Oct 30, 2002, 2:38:49 PM10/30/02

to

"John H Meyers" <jhme...@miu.edu> wrote in message

news:3DBFD6C5...@miu.edu...X

> There is *no* way to properly handle the general case of

> "summing" an empty list, as can be seen by the fact that

> each of the above three examples of { } SigmaLIST

> seems to suggest a different answer!

>

> In other words, with an empty list, the unanswerable question

> remains: an empty list of what "null-value object" ?

NOVAL

?

Veli-Pekka

Oct 30, 2002, 2:50:39 PM10/30/02

to

BUT

when LGPL license applies in 2003

the OS will go "Linux" and we will have a brand new ROM

in a couple of weeks and everything is compressed into one bank

(sans the uncompressor, which takes about 15 banks)

VPN

PS: OR - we will have several different ROMs, which are all incompatible

with each other, including a Greek one (which will be self-incompatible)

;-)news:3DBFAEC4...@miu.edu...

when LGPL license applies in 2003

the OS will go "Linux" and we will have a brand new ROM

in a couple of weeks and everything is compressed into one bank

(sans the uncompressor, which takes about 15 banks)

VPN

PS: OR - we will have several different ROMs, which are all incompatible

with each other, including a Greek one (which will be self-incompatible)

;-)news:3DBFAEC4...@miu.edu...

Oct 31, 2002, 5:45:09 AM10/31/02

to

Nick Karagiaouroglou wrote:

> > sum and product of list elements) won't even accept

> > a list of *one* element! (Error: Invalid Dimension!)

> > sum and product of list elements) won't even accept

> > a list of *one* element! (Error: Invalid Dimension!)

> Easy.

> 0 + SigmaLIST

> 1 + PiLIST

What a mathematician!

You completely neglect the generality of SigmaLIST.

Since this has already been discussed in detail by

JHM, I add only some comments.

IMHO, the simplest way to treat at least 1-element

lists is a reprogramming of SigmaL as follows:

<< PTR 19443 (CheckList on the 48, PTR 3F3C1 on the 49)

IFFERR xSigmaList THEN xHEAD >>

Yes, without the xEND, it's not required. And in the

present case, the UsrRPL IFFERR is better then the

SysRPL command ERRSET. Mathematicians go up the wall

if seeing that Sigmalist does not treat 1-element lists

at least. Precisely speaking, SigmaLIST is an operator

defined on the set of finite sequences of elements of an

arbitrary additive semigroup (need not be commutative).

And { x } Sigmalist always equals x, where x denotes

any member of the semigroup.

Whether SigmaLIST can reasonably be defined on the empty

sequence depends on whether the semigroup has a Zero

(a neutral element) or not. If it has, {} SigmalLIST should

equal Zero. E.g., in the semigroups of character strings,

the Zero is the empty string, in the semigroup of real or

complex numbers, the Zero is the number 0. In the semigroup

of reals with respect to multiplication, it is the real 1.

Sometimes it may be useful to let {} SigmaLIST undefined,

like 0^0, for instance.

- Wolfgang

Oct 31, 2002, 6:34:08 AM10/31/02

to

John H Meyers <jhme...@miu.edu> wrote in message news:<3DBFD6C5...@miu.edu>...

> NK:

>

> [re summing 1-element lists]

>

> > 0 + SigmaLIST

> > 1 + PiLIST

>

> Valid only if you know in advance that you are restricting input

> only to lists of *numbers* (see below).

>

> In that case, how about these, for possible empty lists as well:

>

> 0 + 0 + SigmaLIST

> 1 + 1 + PiLIST

>

> NK:

>

> [re summing 1-element lists]

>

> > 0 + SigmaLIST

> > 1 + PiLIST

>

> Valid only if you know in advance that you are restricting input

> only to lists of *numbers* (see below).

>

> In that case, how about these, for possible empty lists as well:

>

> 0 + 0 + SigmaLIST

> 1 + 1 + PiLIST

>

Indeed, even better. But....

> But let's take a closer look:

>

> { 1 2 3 } SigmaLIST = 6

> { 1 2 } SigmaLIST = 3

> { 1 } SigmaLIST = 1 But this errors!

> { } SigmaLIST = 0 ? Also errors.

>

> { [1] [2] [3] } SigmaLIST = [6]

> { [1] [2] } SigmaLIST = [3]

> { [1] } SigmaLIST = [1] But this errors!

> { } SigmaLIST = [0] ? Also errors.

>

> { "1" "2" "3" } SigmaLIST = "123"

> { "1" "2" } SigmaLIST = "12"

> { "1" } SigmaLIST = "1" But this errors!

> { } SigmaLIST = "" ? Also errors.

>

> Note that to handle more general one-element lists,

> the simplest, more general work-around might be:

>

> \<< IF DUP SIZE 1. == THEN 1. GET ELSE SigmaLIST END \>>

HEAD would also do in case of 1 element.

> However, note that this doesn't trap { \<< program \>> }

> as invalid input, which might have been the original 48G

> rationale for the slightly lazy rejection by ROM coding

> of summing (or taking the product of) any 1-element lists at all;

> in fact, these are implemented essentially identically to the

> STREAM command, which also balks on empty or single-element lists.

>

> There is *no* way to properly handle the general case of

> "summing" an empty list, as can be seen by the fact that

> each of the above three examples of { } SigmaLIST

> seems to suggest a different answer!

Notion: { set / operation } for algebraic.

{ element } for set

There is no general way to extend the algebraic structure

{{elements}/operation} for the case of the operation acting upon zero

elements. In case of one element one can "assume" that the "missing"

element is the neutral element of the structure. This by "deducing"

that it can't be any different thing because the operation itself is

defined over the special kind of elements of the structure itself.

When there are no elements at all, this "assumption" is not very

reasonable as there is no way to predict what kind of objects the

elements will be that the operation acts upon.

So for the example {{numbers}/addition} 0 0 + can be done only when

it is already known that \gSLIST will operate with a list of numbers.

This can be checked if there is at least one element in the list. But

if there is nada, then go figure out what the list would/should

contain.

In the special case of the HP49G, the structure {elements/addition has

some additional "properties" resulting out of overloading the

operation + for handling different object types. The kind of object

whose type "survives" any addition with any other object kind is the

list itself. Add anything with a list to get a list again. This

additional property might suggest to widen the definition to "If nada

elements -> assume lists as elements to add with each other". So {

{}/addition} could be set equivalent to { {{ }}/addition } which then

can use the "predicting procedure" to assume that {{}} \gSLIST means

{{}{}} \gSLIST and return an empty list.

But this is also not very general. What about the "algebraic

structure" {{numbers,vectors} multiplication}? What is the neutral

emement of this structure? Is it 1.? If the "missing" element is the

vector there is no way of guessing its absence out of { 1 } \gPLIST

which according to the above would be widened to { 1 1 } \gPLIST.

Which spits out a number instead of a vector. Possible exit: Cripple

\gPLIST to accept only lists with a single type of objects. It is

*then* that the assumption of "survival of the strongest element

types" can be made without the above problem. But then the engineering

population starts complaining again, singing the boring song "why

can't this be done, the good old days of HP, why did they change that,

blah blah, blah blah, blah blah."

> In other words, with an empty list, the unanswerable question

> remains: an empty list of what "null-value object" ?

>

An empty list of nothing. Null set, nema, nada, nix. (Only if the

above "assumptions" are made.)

BTW. MAP has also its usefulness. Try it with nested lists in

comparison to DOSUBS.

>Or, "what is the sound of nothing clapping?" ;-)

If silence is in the set of sounds, then silence.

Nick.

Oct 31, 2002, 6:40:01 AM10/31/02

to

"Veli-Pekka Nousiainen" <DROP...@welho.com> wrote in message news:<yLWv9.22$gd1....@reader1.news.jippii.net>...

> BUT

> when LGPL license applies in 2003

> the OS will go "Linux" and we will have a brand new ROM

> in a couple of weeks and everything is compressed into one bank

> (sans the uncompressor, which takes about 15 banks)

> VPN

> PS: OR - we will have several different ROMs, which are all incompatible

> with each other, including a Greek one (which will be self-incompatible)

> BUT

> when LGPL license applies in 2003

> the OS will go "Linux" and we will have a brand new ROM

> in a couple of weeks and everything is compressed into one bank

> (sans the uncompressor, which takes about 15 banks)

> VPN

> PS: OR - we will have several different ROMs, which are all incompatible

> with each other, including a Greek one (which will be self-incompatible)

ROTFL! :-)

Anti-ROM. The only ROM which is able to answer the question about

reciprocal-exclusons. Objects that are anything else than themselves.

(Has Douglas been in Greece??;-))

Oct 31, 2002, 9:00:31 AM10/31/02

to

After reading WR and NK,

I *think* that we all agree that the sum (or product)

of the elements in an empty HP 48/49 list has to remain undefined,

but with so much legal-speak and math-speak, it's hard to tell :-)

Summarizing in my dumb Merkinese:

The "sum" (or "product")

of an empty list of "I don't know what object type(s)"

has to be "I don't know" (Error: Invalid Dimension is close enough :)

Like [as] I've been trying to say for six years :)

Oct 31, 2002, 9:02:37 AM10/31/02

to

Jean-Yves Avenard wrote:

> Sometimes, time is the most important issue, didn't have too much time to

> optimized UPDIR so it would save 8 bytes and save .05ms ...

> Sometimes, time is the most important issue, didn't have too much time to

> optimized UPDIR so it would save 8 bytes and save .05ms ...

Jean-Yves, neither saving some bytes nor some milliseconds

really count. What counts - besides beauty and elegance

in programming - is IMHO that the user gets maximal profit

from a tool. As you see, it cost only 70 bytes to reprogram

UPDIR in such a way that one returns with it always to the

menu page you were starting from. I really recommend this

for the next ROM. OK, you introduced the new SysRPL-name

MYRAMROMPAIR (why not MONRAMROMPAIR ?:-) but it is not

very helpful for the above task.

Since MYRAMROMPAIR is not documented by CD & EK, here

it's stack diagram:

rrp -> rrp' TRUE (rrp' = parents dir of rrp)

rrp -> FALSE (provided rrp is HOME)

- Wolfgang

Oct 31, 2002, 9:19:46 AM10/31/02

to

>>>>> "WR" == Wolfgang Rautenberg <ra...@math.fu-berlin.de> writes:

WR> Since MYRAMROMPAIR is not documented by CD & EK, here

WR> it's stack diagram:

WR> rrp -> rrp' TRUE (rrp' = parents dir of rrp)

WR> rrp -> FALSE (provided rrp is HOME)

Thanks, but it is already in the database.

- Carsten

Oct 31, 2002, 5:38:47 PM10/31/02

to

Seen:

> reprogram UPDIR in such a way that it always returns to the

> menu page [containing the label for the current directory]

But that's not backward compatible with the HP48,

which is of course the most important thing :)

And Joe Horn already supplied a little "UP" program

which anyone can use for that purpose, if they wish

(and so did I offer another -- in UserRPL of course :)

Other users might also possibly *not* want this change,

so are we ready to supply an "OLDUPDIR" program for them?

And lastly, look at any "My Computer" window in any version

of that "most popular computer OS in the world";

when you click the "updir" tool button in the toolbar,

does it "go back to" (i.e. select, or show a "dashed line" around)

the folder that you just came from?

No, of course not! -- it goes all the way back to the

very first item in the parent directory, always,

so that you can start all over again, scrolling all the way

back down again to where you were -- so if this is the

way the whole world wants its computers to function

(and MS is never wrong in deciding what's good for users :)

then why should a mere calculator do things any differently?

Bah!, Humbug!, and a Spooky Halloween to everyone!

Nov 1, 2002, 1:41:04 AM11/1/02

to

John H Meyers wrote:

> But that's not backward compatible with the HP48,

> which is of course the most important thing :)

> But that's not backward compatible with the HP48,

> which is of course the most important thing :)

Hi John, do you not sleep anymore? Or can you explain

to me what a good functionality of UPDIR has to do

with backward compatibility? :-)

- Wolfgang

PS. IMHO simulating fast parts of the operating system

in UsrRPL seems to be a kind of a useless game :-)

Nov 1, 2002, 2:20:42 AM11/1/02

to

> what ... UPDIR has to do with backward compatibility?

UPDIR is backward, DOWNDIR is forward :)

I'm not quite sure which way Down Under is, however.

-[30]-

Nov 1, 2002, 11:55:15 AM11/1/02

to

I thought that you wanted a BACKMENU command

which would keep a history of 10 last menus

and go back and forth in that history

or should be settle for three and use MENUROT

???

VPN

which would keep a history of 10 last menus

and go back and forth in that history

or should be settle for three and use MENUROT

???

VPN

"John H Meyers" <jhme...@miu.edu> wrote in message

news:3DC22B4A...@miu.edu...

Nov 1, 2002, 1:44:36 PM11/1/02

to

John H Meyers wrote:

>

> And lastly, look at any "My Computer" window in any version

> of that "most popular computer OS in the world";

> when you click the "updir" tool button in the toolbar,

> does it "go back to" (i.e. select, or show a "dashed line" around)

> the folder that you just came from?

>

> No, of course not! -- it goes all the way back to the

> very first item in the parent directory, always,

> so that you can start all over again, scrolling all the way

> back down again to where you were ...>

> And lastly, look at any "My Computer" window in any version

> of that "most popular computer OS in the world";

> when you click the "updir" tool button in the toolbar,

> does it "go back to" (i.e. select, or show a "dashed line" around)

> the folder that you just came from?

>

> No, of course not! -- it goes all the way back to the

> very first item in the parent directory, always,

> so that you can start all over again, scrolling all the way

Yes and no. Yes, that's the case when you set Windows to use the same

window when you open a folder, BUT that's NOT the case if you set Windows to

open a *new* window when you open a folder. In that case, you "go back to

where you were" by closing the window, and voila! the folder you clicked on

will still be highlighted.

Furthermore, you can get the best of both worlds by leaving Windows in "use

same window" mode, BUT any time you want to get back to a folder that you

open, open it not by double-clicking it but by right-clicking it and

selecting "Explore from here".

Or just use the DOS Norton Commander, which does UPDIR correctly. If you

are condemned to using Windows, use the Windows "Norton Commander" clone

called 2xExplorer, http://netez.com/2xExplorer/ Great stuff! Freeware

(voluntary contributions are happily accepted). Try it; you'll love the way

it does UPDIR the way God intended, and you'll learn how to open a beer

bottle with your socks and other nifty things.

-Joe-

Nov 4, 2002, 3:40:25 AM11/4/02

to

Wolfgang Rautenberg <ra...@math.fu-berlin.de> wrote in message news:<3DC109B5...@math.fu-berlin.de>...

> Nick Karagiaouroglou wrote:

> > > sum and product of list elements) won't even accept

> > > a list of *one* element! (Error: Invalid Dimension!)

>

> > Easy.

> > 0 + SigmaLIST

> > 1 + PiLIST

>

> What a mathematician!

> You completely neglect the generality of SigmaLIST.

> Nick Karagiaouroglou wrote:

> > > sum and product of list elements) won't even accept

> > > a list of *one* element! (Error: Invalid Dimension!)

>

> > Easy.

> > 0 + SigmaLIST

> > 1 + PiLIST

>

> What a mathematician!

> You completely neglect the generality of SigmaLIST.

Only because many of the posted questions are related to numbers in lists.

Nick.

Nov 4, 2002, 3:46:45 AM11/4/02

to

John H Meyers <jhme...@miu.edu> wrote in message news:<3DC1377F...@miu.edu>...

> After reading WR and NK,

>

> I *think* that we all agree that the sum (or product)

> of the elements in an empty HP 48/49 list has to remain undefined,

> but with so much legal-speak and math-speak, it's hard to tell :-)

>

It's not hard to tell. Either error out or return an empty list if we

assume lists to be the "most general" object types that can be summed.

Second option could/will cause other problems?

> After reading WR and NK,

>

> I *think* that we all agree that the sum (or product)

> of the elements in an empty HP 48/49 list has to remain undefined,

> but with so much legal-speak and math-speak, it's hard to tell :-)

>

assume lists to be the "most general" object types that can be summed.

Second option could/will cause other problems?

Nick.

Nov 4, 2002, 1:06:18 PM11/4/02

to

[re the "sum" of an empty list, using SigmaLIST]

> Either error out or return an empty list

Returning an empty list would be just like returning zero;

it presumes to know what type of objects would have been

in the list if it hadn't been empty, because

only the "sum" of a list of lists would be a list,

just as only the sum of a list of numbers would be a number,

only the sum of a list of arrays would be an array,

and only the sum of a list of strings would be a string,

at least if all the objects are of the same type.

But the calculator itself can't know what type of object(s)

an empty list would have been a list *of*, so a general

built-in HP calculator function like SigmaLIST

ought only to error in this general, indeterminate case

(which it already does, so leave it be!)

Users who have specific applications in mind

can, of course, create their own special cases

for the type of object they have in mind.

By the way, if list elements are of mixed types,

then the "sum" can be a bit strange, e.g.:

{ 2 3 4 "5" 6 7 8 } \GSLIST ==> "95678"

{ 2 3 4 { 5 6 } 7 8 } \GSLIST ==> { 9 5 6 7 8 }

Neither of the above lists is acceptable to SORT

(which would error out), but \GSLIST and \PILIST

will swallow anything that they are fed :)

[r->] [OFF]

Nov 5, 2002, 7:36:07 AM11/5/02

to

John H Meyers <jhme...@miu.edu> wrote in message news:<3DC6B71A...@miu.edu>...

> [re the "sum" of an empty list, using SigmaLIST]

>

> > Either error out or return an empty list

>

> Returning an empty list would be just like returning zero;

> it presumes to know what type of objects would have been

> in the list if it hadn't been empty, because

> only the "sum" of a list of lists would be a list,

> just as only the sum of a list of numbers would be a number,

> only the sum of a list of arrays would be an array,

> and only the sum of a list of strings would be a string,

> at least if all the objects are of the same type.

> [re the "sum" of an empty list, using SigmaLIST]

>

> > Either error out or return an empty list

>

> Returning an empty list would be just like returning zero;

> it presumes to know what type of objects would have been

> in the list if it hadn't been empty, because

> only the "sum" of a list of lists would be a list,

> just as only the sum of a list of numbers would be a number,

> only the sum of a list of arrays would be an array,

> and only the sum of a list of strings would be a string,

> at least if all the objects are of the same type.

Mmm, not really... Lists "survive" any addition. List + AnyObject =

List. It is only this reason for which I think that they are the most

general type of object that can be used as operand of +. And so,

according to this questionable criterion, I thought that if something

has to be returned in this case, then the most general object of all

that can be added, the list.

> But the calculator itself can't know what type of object(s)

> an empty list would have been a list *of*, so a general

> built-in HP calculator function like SigmaLIST

> ought only to error in this general, indeterminate case

> (which it already does, so leave it be!)

That's right, the calc (thanks heavens) still doesn't know what kind

of objects we didn't give it to add. No wish to change the existing

behavior, only wondering what if..

Mathematica for example allows to define functions using default

values in case they are used without arguments.

> Users who have specific applications in mind

> can, of course, create their own special cases

> for the type of object they have in mind.

Yep.

> By the way, if list elements are of mixed types,

> then the "sum" can be a bit strange, e.g.:

>

> { 2 3 4 "5" 6 7 8 } \GSLIST ==> "95678"

>

> { 2 3 4 { 5 6 } 7 8 } \GSLIST ==> { 9 5 6 7 8 }

Why strange?

Number + String = String

Number + List = List

\GSLIST complies "pairwise" to the rules of + in this cases.

Or should it return "2345678" and {2 3 4 5 6 7 8 }?

> Neither of the above lists is acceptable to SORT

> (which would error out), but \GSLIST and \PILIST

> will swallow anything that they are fed :)

>

{ 2 3 4 "5" 6 7 8 } \PILIST errors, OK the HP49G doesn't know how to

multiply strings with numbers and we are not allowed to easily change

the built-in definitions.

But { 2 3 4 { 5 6 } 7 8 } also errors, while according to the same

"pairwise compliance" it could return { 6720 8064 } (??)

Well, as long as we can << * >> STREAM, be it that way and let \GSLIST

and \PILIST eat, digest and **** what they want. :)

Nick.

Nov 5, 2002, 10:05:24 AM11/5/02

to

I wrote:

> Returning an empty list would be just like returning zero;

> it presumes to know what type of objects would have been

> in the list if it hadn't been empty, because

> only the "sum" of a list of lists would be a list,

> just as only the sum of a list of numbers would be a number,

> only the sum of a list of arrays would be an array,

> and only the sum of a list of strings would be a string,

> at least if all the objects are of the same type.

NK wrote:

> Mmm, not really... Lists "survive" any addition.

> List + AnyObject = List.

Did I not say above,

"at least if all the objects are of the same type"?

(then I illustrated what mixed types can produce,

which is more weird than mere rearrangement).

Listen, you send me a blank check (the sum of an empty set of words),

and I'll fill in what I feel like writing, too ;-)

> It is only this reason for which I think that they are the most

> general type of object that can be used as operand of +. And so,

> according to this questionable criterion, ...

Questionable indeed; I'll "second" that!

> I thought that if something has to be returned in this case..

Does a drink vending machine *have* to give me something

if I neither put anything in nor even choose a flavor?

> then the most general object of all that can be added, the list.

So hey, the most general type of "number" that can be returned

is a complex-valued number, which can be added to any other

type of number, so in the same spirit, I propose that all

results of arithmetic (especially if zero) should be returned

as a complex number object! Now we're talkin' "real math" !!!

> Mathematica for example allows to define functions using default

> values in case they are used without arguments.

Who defines it -- the vendor hard-codes it into the product,

or *allows* you to make your *own* definition?

(same logic applies to what I was saying)

> > By the way, if list elements are of mixed types,

> > then the "sum" can be a bit strange, e.g.:

> >

> > { 2 3 4 "5" 6 7 8 } \GSLIST ==> "95678"

> >

> > { 2 3 4 { 5 6 } 7 8 } \GSLIST ==> { 9 5 6 7 8 }

> Why strange?

Although it is the inevitable result of using STREAM

(and of going left to right), the fact remains:

Elements preceding the "odd object" get combined into one item,

while elements following the odd object are preserved;

this is a bit more non-commutativity than normal,

and I would regard it as just as reasonable for the

calc to error out, if it wanted to, just as it does for SORT

(or you *could* liberalize SORT to allow sorting anything, too;

perhaps return an empty list to represent the total generality

of not having any idea what the answer should be :)

> Well, as long as we can << * >> STREAM, be it that way and let \GSLIST

> and \PILIST eat, digest and **** what they want. :)

Yes, and let { } \GSLIST return the same as { } \<< + \>> STREAM,

which it does, thank heaven for this bit of sanity ;-)

[r->] [OFF]

.

Nov 6, 2002, 6:52:00 AM11/6/02

to

John H Meyers <jhme...@miu.edu> wrote in message news:<aq8mo9$7mi$1...@newsreader.mailgate.org>...

> I wrote:

>

> > Returning an empty list would be just like returning zero;

> > it presumes to know what type of objects would have been

> > in the list if it hadn't been empty, because

> > only the "sum" of a list of lists would be a list,

> > just as only the sum of a list of numbers would be a number,

> > only the sum of a list of arrays would be an array,

> > and only the sum of a list of strings would be a string,

> > at least if all the objects are of the same type.

>

> NK wrote:

>

> > Mmm, not really... Lists "survive" any addition.

> > List + AnyObject = List.

>

> Did I not say above,

> "at least if all the objects are of the same type"?

> (then I illustrated what mixed types can produce,

> which is more weird than mere rearrangement).

> I wrote:

>

> > Returning an empty list would be just like returning zero;

> > it presumes to know what type of objects would have been

> > in the list if it hadn't been empty, because

> > only the "sum" of a list of lists would be a list,

> > just as only the sum of a list of numbers would be a number,

> > only the sum of a list of arrays would be an array,

> > and only the sum of a list of strings would be a string,

> > at least if all the objects are of the same type.

>

> NK wrote:

>

> > Mmm, not really... Lists "survive" any addition.

> > List + AnyObject = List.

>

> Did I not say above,

> "at least if all the objects are of the same type"?

> (then I illustrated what mixed types can produce,

> which is more weird than mere rearrangement).

If we consider \GSLIST to be an automation of the built-in + for

adding any objects in a list that the HP can add, then we follow the

"rules" which + "knows" for adding objects. For common + anything

added to a list will return a list, and that's why I think that even

with mixed types of objects the list is the most general outcome of +.

(I didn't stay at same object types, sorry.)

> Listen, you send me a blank check (the sum of an empty set of words),

> and I'll fill in what I feel like writing, too ;-)

It was not blank, it was another language. Presumably all greek to

you? ;-)

> > It is only this reason for which I think that they are the most

> > general type of object that can be used as operand of +. And so,

> > according to this questionable criterion, ...

>

> Questionable indeed; I'll "second" that!

But not so questionable as you might think. (Look at algebraic

structures.)

> > I thought that if something has to be returned in this case..

>

> Does a drink vending machine *have* to give me something

> if I ?

That depends on the definition of "drink vending machine". If the

"drink vending machine" is of type algebraic structure, then it might

return something. The part "neither put anything in nor even choose a

flavor" is wrong. Of course you put something in. That is the empty

list and the key press \GSLIST.

But the more important thing here is that we start again making shitty

analogies. I don't care what a "drink vending machine" would do and

I'll not consider algebraic structures with the aid of "drink vending

machines".

> > then the most general object of all that can be added, the list.

>

> So hey, the most general type of "number" that can be returned

> is a complex-valued number, which can be added to any other

> type of number, so in the same spirit, I propose that all

> results of arithmetic (especially if zero) should be returned

> as a complex number object! Now we're talkin' "real math" !!!

We are not talking about numbers but about any object that can be used

as an operand for +. Since lists are the objects that always retain

their type when added, they are somehow distinct from all other

objects. They are more general as output object types of the built-in

+. The command \GSLIST is "apply + to each pair of elements in a

list", so when we already have enough operants for +, we have the

result according to the built-in rules of the HP-addition, which is

*not* the usual mathematic defined addition. When we have only 1

operand, we return the operand itself, assuming that the missing

operand is the neutral element of the algebraic structure { { obj} +}.

This is 0 for numbers, "" for string etc. When there is no operand, we

use the list as the most general operand to +, then use another empty

list as the neutral element of list addition as defined on the HP

(previous rule), and then return an empty list.

So, the two necessary rules for extending + to 1 or 0 operands are:

1) Case of 1 operand: Add it to the neutral element of {{operandType}

+}

2) Case of 0 operands: Assume existence of {} as the most general

thing that can be added on the HP, and then use (1)

They seem to be able to work. I don't declare these rules to be the

best possible, I only think about extending the built in + and in

consequence the built-in \GSLIST and have no better idea.

When you already have two real numbers, then you are at { {reals} + }

and because in this case the + is the same like math defined addition

of reals, you simply get the real result. (Exactly the same for

{{complex} +} etc.) Why do you compare the case "1 or 0 operands for

+" with the case "2 operands for +"?

If with "real math" you refer ironically to what I said, then it's

your right to find that shit. But if you refer ironically to the

concept of mathematics as a whole, then remember please that even your

treasured HP48GX wouldn't exist without this "real math".

> > Mathematica for example allows to define functions using default

> > values in case they are used without arguments.

>

> Who defines it -- the vendor hard-codes it into the product,

> or *allows* you to make your *own* definition?

> (same logic applies to what I was saying)

Not the vendor, the user. You make your *own* definitions that are

then vary tightly integrated in the rest of the CAS. You can even

change the built in definition of, say *.

Look:

Unprotect[Prod[]]

Prod[string1_, string2_]:=AddString[string1,string2]

Protect[Prod[]]

From this moment on, entering "wow"*"wow" will return "wowwow"

*without* *forgeting* the definitions for multiplication that exist so

far. That means that entering 3*4 will still return 12. The

definitions in Mathematica are far more flexible than those of the

HP49G because of the way that they are implemented.

>

> > > By the way, if list elements are of mixed types,

> > > then the "sum" can be a bit strange, e.g.:

> > >

> > > { 2 3 4 "5" 6 7 8 } \GSLIST ==> "95678"

> > >

> > > { 2 3 4 { 5 6 } 7 8 } \GSLIST ==> { 9 5 6 7 8 }

>

> > Why strange?

>

> Although it is the inevitable result of using STREAM

> (and of going left to right), the fact remains:

>

> Elements preceding the "odd object" get combined into one item,

> while elements following the odd object are preserved;

> this is a bit more non-commutativity than normal,

> and I would regard it as just as reasonable for the

> calc to error out, if it wanted to, just as it does for SORT

> (or you *could* liberalize SORT to allow sorting anything, too;

> perhaps return an empty list to represent the total generality

> of not having any idea what the answer should be :)

The underlying operation + *is* already non-commutative for the

argument type combination number, string. "3" 5 + is not 3 "5" +. So {

2 3 4 "5" 6 7 8 } \GSLIST ==> "95678" is in perfect agreement to

addition as defined on the HP, which is not the same definition like

the mathematic one.

You talk in the same context about \GSLIST and SORT considering how

they react when they are given lists of intermixed object types, but

there are basic differences. There addition of a string and a number

*is* defined in HP, but not the sorting of intermixed strings and

numbers. We can't follow the same rules for \GSLIST and SORT. I don't

say that the definition of sorting numbers and strings can't be done,

I say that it hasn't been done in the HP. So while in HP the structure

{{numbers strings} +} exist, the structure {{{numbers strings}} SORT }

doesn't exist. It would be nice if we could somehow easily modify

SORT, to deal also with lists of numbers and strings but we can't. (Or

is there any way to do so?)

> > Well, as long as we can << * >> STREAM, be it that way and let \GSLIST

> > and \PILIST eat, digest and **** what they want. :)

>

> Yes, and let { } \GSLIST return the same as { } \<< + \>> STREAM,

> which it does, thank heaven for this bit of sanity ;-)

What is insane in trying to think about possible extensions of + for 0

or 1 arguments?

> [r->] [OFF]

>

Up and running,

Nick.

Nov 7, 2002, 7:52:38 AM11/7/02

to

Seen:

> The part "neither put anything in nor even choose a flavor" is wrong.

> Of course you put something in. That is the empty list

> and the key press \GSLIST.

You think you are summing the list itself;

I think the command is supposed to sum only what is *inside* the list,

so when nothing is inside, and when "sum" can be of many different

result types, no outcome is defined for me.

> I'll not consider algebraic structures...

I never knew that an HP calc list object was an algebraic structure,

after all, even if a list of strings.

Oh, well, on another note, the microsoft.com site itself

has become unreadable at 800x600, at which all the text

is now also "greeked" (turns into indistinct characters

which no longer mean anything).

-[]-

Nov 7, 2002, 8:14:20 AM11/7/02

to

"Nick Karagiaouroglou" <n...@imos-consulting.com> wrote in message

news:cd9ca36b.02110...@posting.google.com...X

> When we have only 1

> operand, we return the operand itself, assuming that the missing

> operand is the neutral element of the algebraic structure { { obj} +}.

> This is 0 for numbers, "" for string etc.

news:cd9ca36b.02110...@posting.google.com...X

> When we have only 1

> operand, we return the operand itself, assuming that the missing

> operand is the neutral element of the algebraic structure { { obj} +}.

> This is 0 for numbers, "" for string etc.

Yes! When there is only one object in the list to be multiplied or summed

returning the object itself would be a good fix.

> When there is no operand, we

> use the list as the most general operand to +, then use another empty

> list as the neutral element of list addition as defined on the HP

> (previous rule), and then return an empty list.

Returning empty list { } or generating an error?

A hard decision...may I suggest yet another flag for

error (the default action) overriding?

> The underlying operation + *is* already non-commutative for the

> argument type combination number, string. "3" 5 + is not 3 "5" +. So {

> 2 3 4 "5" 6 7 8 } \GSLIST ==> "95678" is in perfect agreement to

> addition as defined on the HP, which is not the same definition like

> the mathematic one.

I think that a general object summation and/or product is the operation

and that operation is non-commutative.

OR - is a programming language structure "for..next -loop" commutative?

???

VPN

Nov 8, 2002, 5:29:42 AM11/8/02

to

READ about SigmaLIST:

> > When we have only 1

> > operand, we return the operand itself, assuming that the missing

> > operand is the neutral element of the algebraic structure { { obj} +}.

> > When we have only 1

> > operand, we return the operand itself, assuming that the missing

> > operand is the neutral element of the algebraic structure { { obj} +}.

A totally screwed view of things. There are many algebraic

structures (more precisely, semigroups) in the mathematical

and even the real world which don't have a neutral element.

Understand first the basic concept of an operator defined on

the domain of non-empty sequences of elements of some set or

type of objects. That these sequences can be identified with

the 48/49 nonempty lists is obvious. Observe also that these

sequences or lists form itself a (not commutative) semigroup

with respect to concatenation, likewise denoted by +.

In higher mathematics, the Sigma-operator, usually denoted by

a bold-printed Sigma, is recursively defined with respect to an

arbitrary additive semigroup A as follows where S denotes the

domain of Sigma consisting of the finite (non-empty) sequences

of elements of A, or non-empty lists if you like:

Sigma {x} = x

Sigma {x_o ... x_n+1} = Sigma {x_o ... x_n} + x_n+1

Dedekind's famous Recursion theorem (1888) tells us for the

present case that there is *one and only one* operator whose

domain of definition is the whole S and whose range of values

is a subset of A which satisfies these two equations. Actually

the range of values is also the whole A in the present case.

As is seen from this definition, the logically correct stack

diagram of Sigmalist for a singleton { x } on level 1 is

{ x } SigmaLIST -> x

The smallest program to realize this behaviour of the current

SigmaLIST is the Extended UsrRPL proggram

IFERR SigmaLIST THEN HEAD

(UsrRPL PRG-delimiters and a final END are dispensable).

In modern computers, the interpretation of the + symbol

depends solely on its arguments. This convention is also

useful in everday life. There we meet semigroups called

*domains of magnitudes*, like lenght, mass, volumina etc,

considered already by the ancient Greek mathematicians

(who seemingly had a deeper understanding of mathematics

than some contemporary Greeks). The operation of adding

magnitudes of the same kind is denoted by + as well. The

famous Archimedean axiom postulates that if a,b are two

magnitudes of the same kind, there is always a number n

such that n a > b. Here n a is the n-fold repetition of

of + appied to a. Measuring magnitudes with real numbers

is essentially based on the Archimedean axiom.

- Wolfgang

Nov 8, 2002, 6:40:40 AM11/8/02

to

"Wolfgang Rautenberg" <ra...@math.fu-berlin.de> wrote in message

news:3DCB9216...@math.fu-berlin.de...> READ about SigmaLIST:

X

> In higher mathematics, the Sigma-operator, usually denoted by

> a bold-printed Sigma, is recursively defined with respect to an

> arbitrary additive semigroup A as follows where S denotes the

> domain of Sigma consisting of the finite (non-empty) sequences

> of elements of A, or non-empty lists if you like:

>

> Sigma {x} = x

> Sigma {x_o ... x_n+1} = Sigma {x_o ... x_n} + x_n+1

I think SigmaLIST is for LIST of objects summation,

more of a programming language command than math

and that the math thing is the Summation Sigma,

which also understands symbolic sums.

VPN

Nov 8, 2002, 7:10:45 AM11/8/02

to

Veli-Pekka Nousiainen wrote:

> I think SigmaLIST is for LIST of objects summation,

> more of a programming language command than math

> I think SigmaLIST is for LIST of objects summation,

> more of a programming language command than math

One of your typical scrams. Do you really think

that programming language commands have nothing

do do with higher math? I claim that commands like

SigmaLIST cannot be fully understood without a

minimum of training in abstract thinking. My

advice is first to read my post thorouhgly and

then comment :-)

- Wolfgang

Nov 8, 2002, 7:31:28 AM11/8/02

to

John H Meyers <jhme...@miu.edu> wrote in message news:<3DCA6216...@miu.edu>...

> Seen:

>

> > The part "neither put anything in nor even choose a flavor" is wrong.

> > Of course you put something in. That is the empty list

> > and the key press \GSLIST.

>

> You think you are summing the list itself;

> I think the command is supposed to sum only what is *inside* the list,

> so when nothing is inside, and when "sum" can be of many different

> result types, no outcome is defined for me.

> Seen:

>

> > The part "neither put anything in nor even choose a flavor" is wrong.

> > Of course you put something in. That is the empty list

> > and the key press \GSLIST.

>

> You think you are summing the list itself;

> I think the command is supposed to sum only what is *inside* the list,

> so when nothing is inside, and when "sum" can be of many different

> result types, no outcome is defined for me.

For the third and last time:

If a list doesn't contain anything and we give such a list to \GSLIST,

then we have the operation + with no operands. Because of the

"generality" of lists as arguments to +, we *assume* that the null

arguments defaults to one emptly list as element in the original list

that we gave \GSLIST. That is from {} \GSLIST we default to { {} }

\GSLIST. For the second missing argument we use the neutral element

for list addition which is again an empty list, that is from { {} }

\GSLIST we move to { {} {} } \GSLIST, which then has the result {}.

The above is not even a suggestion but rather trying to think about

how to avoid problems with \GSLIST by ways based on some elementary

rules that already exist in the inner wolrd of the 49G.

> > I'll not consider algebraic structures...

>

> I never knew that an HP calc list object was an algebraic structure,

> after all, even if a list of strings.

The algebraic structure is not the list alone, but the list elements

seen as members of a set in conjunction with some operation (in this

case +) that is carried out on the elements of the list. The operation

+ has such a wealth of "additional" properties compared to plain

number addition, that you can not only talk about algebraic

structures, but even face problems like the above.

> Oh, well, on another note, the microsoft.com site itself

> has become unreadable at 800x600, at which all the text

> is now also "greeked" (turns into indistinct characters

> which no longer mean anything).

Hurrah! MS is a greek company! (Though I would prefer Apple.)

Nick.

Nov 8, 2002, 8:07:17 AM11/8/02

to

Hi VPN!

>> Returning empty list { } or generating an error?

>> A hard decision...may I suggest yet another flag for

>> error (the default action) overriding?

An error is also a good mechanism for rounding up the behavior of

\GSLIST and it can also have advantages in many cases. I was only

thinking about a possible concept of operation of \GSLIST without

having to error out when not even one element exists in the list.

Additional flag you say? There are some unused flags on the HP49G, so

why not? After all that would make the HP49G even more controlable by

the users. BTW, there are already enough flags for a periodic system

of system flags for the HP49G, and their 2^128 "combounds" ;-)

> > The underlying operation + *is* already non-commutative for the

> > argument type combination number, string. "3" 5 + is not 3 "5" +. So {

> > 2 3 4 "5" 6 7 8 } \GSLIST ==> "95678" is in perfect agreement to

> > addition as defined on the HP, which is not the same definition like

> > the mathematic one.

>

> I think that a general object summation and/or product is the operation

> and that operation is non-commutative.

> OR - is a programming language structure "for..next -loop" commutative?

> ???

> VPN

Exactly so, only the special case of normal addition of numbers is

commutative and it has to be if we want to have calcs that behave

mathematically correct. But as you say, in the general case of adding

strings and numbers and lists and what so ever, we can't expect

commutativity.

About the commutativity of FOR...NEXT, what an interesting question!

Thanks for this Veli-Pekka. The problem is how to define commutativity

in such cases. The arguments to FOR are two numbers and one name and

the result depends not only on these arguments but also to what

happens in the loop body, which is not argument to FOR, but on the

other hand could be considered argument to the whole FOR..NEXT. Hey, I

know what I'll be doing in the weekend. ;-)

Loopings,

Nick.

Nov 8, 2002, 8:39:29 AM11/8/02

to

"Wolfgang Rautenberg" <ra...@math.fu-berlin.de> wrote in message

news:3DCBA9C5...@math.fu-berlin.de...> Veli-Pekka Nousiainen wrote:

> > I think SigmaLIST is for LIST of objects summation,

> > more of a programming language command than math

>

> One of your typical scrams. Do you really think

when I saw your math explanations. Does it always have to be that

_complicated.

To me SigmaLIST is a FOR..NEXT (or any) loop

eg. a programming language structure and I would approach

using CS rather than math.

nevertheless there was no flaw per se in your explanations

and I was not arguing about their valitidy

just giving this forum a glimpse of my simplified pow

of the particular command.

Cheez!

What do YOU want me to comment?

I'm not at your level in math and I doubt I never will be.

Have a nice day.

VPN

Nov 8, 2002, 10:29:50 AM11/8/02

to

Veli-Pekka Nousiainen wrote:

> > One of your typical scrams. Do you really think

> Scram? Yeah - my reactor (=brains) was shut down in emergency

> when I saw your math explanations. Does it always have to be that

> _complicated.

>

> To me SigmaLIST is a FOR..NEXT (or any) loop

> eg. a programming language structure and I would approach

> using CS rather than math.

> > One of your typical scrams. Do you really think

> Scram? Yeah - my reactor (=brains) was shut down in emergency

> when I saw your math explanations. Does it always have to be that

> _complicated.

>

> To me SigmaLIST is a FOR..NEXT (or any) loop

> eg. a programming language structure and I would approach

> using CS rather than math.

OK Veli, you know I like you and your postings :-)

The only problem is you're too easily influenced

by people discussing things they'd better mute upon.

Do not believe that in math and in particular in the

SigmaLIST command there is something like a "missing

argument". Expressing oneself in this way mystifies

things which in reality are completely clear, having

understood the concept of a recursive definition.

I didn't discuss the relationship between SigmaLIST

and the sole Sigma command. IMHO, the latter could

have been programmed more general, to cover also

summation in all available semigroup like SigmaLIST,

not only in the rings R, C or the ring of algebraics.

On the additive semigroup of algebraics, both SigmaLIST

and Sigma seem to do the same. Clearly, Sigmalist need

not defining additional arguments of Sigma like lower

and upper summation index as is seen from the recursive

definition of SigmaLIST I gave in the previous post.

Thus, in one direction, Sigmalist is more general, but

as regards the treatment of algebraics, Sigma is more

general. It would perhaps pay to compare these two

commands more closely.

Have a nice day as well, Wolfgang

PS. Not necessary to grasp everything I talked about :-)

But mathematicians working on computer algebraic systems

need to know still much more on algebra and its relationship

to programming as indicated above ...

Nov 8, 2002, 12:11:30 PM11/8/02

to

Wolfgang Rautenberg <ra...@math.fu-berlin.de> wrote in message news:<3DCB9216...@math.fu-berlin.de>...

> READ about SigmaLIST:

> > > When we have only 1

> > > operand, we return the operand itself, assuming that the missing

> > > operand is the neutral element of the algebraic structure { { obj} +}.

>

> A totally screwed view of things. There are many algebraic

> structures (more precisely, semigroups) in the mathematical

> and even the real world which don't have a neutral element.

> READ about SigmaLIST:

> > > When we have only 1

> > > operand, we return the operand itself, assuming that the missing

> > > operand is the neutral element of the algebraic structure { { obj} +}.

>

> A totally screwed view of things. There are many algebraic

> structures (more precisely, semigroups) in the mathematical

> and even the real world which don't have a neutral element.

Undoubtfully there are such algebraic structures but I only think

about the HP49G and nothing else. In this case there exists a neutral

element for any object type that can be used as argument to + upon

which \GSLIST built.

> Understand first the basic concept of an operator defined on

> the domain of non-empty sequences of elements of some set or

> type of objects. That these sequences can be identified with

> the 48/49 nonempty lists is obvious. Observe also that these

> sequences or lists form itself a (not commutative) semigroup

> with respect to concatenation, likewise denoted by +.

Did I ever say anything different?

> In higher mathematics, the Sigma-operator, usually denoted by

> a bold-printed Sigma, is recursively defined with respect to an

> arbitrary additive semigroup A as follows where S denotes the

> domain of Sigma consisting of the finite (non-empty) sequences

> of elements of A, or non-empty lists if you like:

>

> Sigma {x} = x

> Sigma {x_o ... x_n+1} = Sigma {x_o ... x_n} + x_n+1

>

> Dedekind's famous Recursion theorem (1888) tells us for the

> present case that there is *one and only one* operator whose

> domain of definition is the whole S and whose range of values

> is a subset of A which satisfies these two equations. Actually

> the range of values is also the whole A in the present case.

I am very happy that you shine with such a light in my life, really.

I didn't know all that and so I thought that you could perhaps appear

and tell me. Now I am really happy to know that, thanks for the

favour ;-)

> As is seen from this definition, the logically correct stack

> diagram of Sigmalist for a singleton { x } on level 1 is

>

> { x } SigmaLIST -> x

Wouldn't what I said have the same behavior for a singleton?

I only dare going further, if you allow of course ;-), and think aloud

about some possibility to extend this for an empty list and this only

for the case of the HP49G and its definition of \GSLIST which

technically bases on its definition of +.

> The smallest program to realize this behaviour of the current

> SigmaLIST is the Extended UsrRPL proggram

>

> IFERR SigmaLIST THEN HEAD

>

> (UsrRPL PRG-delimiters and a final END are dispensable).

I didn't propose any program what so ever but only thought

conceptually. In fact the above program is (in the particular case of

the HP49) equivalent to the concept of using the neutral element of

the "missing" argument in case of a singleton. Both methods would

return the same results, but the above program still errors out with

an empty list as argument. Because I thought about possible ways to

handle even such cases, I came to the idea that the two rules "In case

of null-list put an empty list into the argument list", and "In case

of singleton add neutral element", would be *one* of the possible ways

to handle such cases and extend the capabilities of \GSLIST. I was not

instructing anyone how to write a program for this purpose, and I was

even less inclined to say that extending it this way is a must. So be

happy your program is the best, I fall on my knies in front of you,

blah blah, blah blah and so on, and so on...

> In modern computers, the interpretation of the + symbol

> depends solely on its arguments. This convention is also

> useful in everday life.

What a surpricing insÃght for me, thank you.

> There we meet semigroups called

> *domains of magnitudes*, like lenght, mass, volumina etc,

> considered already by the ancient Greek mathematicians

> (who seemingly had a deeper understanding of mathematics

> than some contemporary Greeks).

Here we go again.

The contemporary Germans *must* of course state their superiority

compared to the contemporary Greeks. (EU-Kaisers, you see ;-))

The Greeks again *must* call contemporary USA-citizens names, (

especially if they are called Nick and don't live in Greece ).

And the contemporary USA-citizens *have to* point their fingers on

Europe, and so on, and so on.

Is that some kind of competition?

As for comparisons about the understanding of Mathematics by some

contemporary Nicks, you had better consider that no contemporary

Greek will ever give a damn about any comment coming from a

contemporary German, not because we think that we already understood

everything, but because we are so used to hear such things that

in the mean time we ignore them.

Or, as you say in your mother language Wolfgang:

"Ich schalte auf Durchzug".

> The operation of adding

> magnitudes of the same kind is denoted by + as well. The

> famous Archimedean axiom postulates that if a,b are two

> magnitudes of the same kind, there is always a number n

> such that n a > b. Here n a is the n-fold repetition of

> of + appied to a. Measuring magnitudes with real numbers

> is essentially based on the Archimedean axiom.

I don't see anything here that isn't compatible to the

above idea of possibilities to eventually extend \GSLIST.

Except of course the inability of contemporary Greeks, oops

sorry I meant Nicks, to be compatible to anything, especially

to contemporary Wolfgangs.

Any compatilizers out there? ;-)

Nick.

Nov 8, 2002, 12:27:21 PM11/8/02

to

"Veli-Pekka Nousiainen" <DROP...@welho.com> wrote in message news:<gpNy9.1299$Z6.4...@reader1.news.jippii.net>...

On the HP49G yes, it is that way, since \GSLIST can't be used for a

symbolic sum. Things are different of course if we only consider it

abstractly and we demand \GSLIST to become a synonym for Sigma that

can operate with lists exactly like Sigma operates with its arguments.

But we don't demand such a thing, or do we?

Greetings,

Nick.

Nov 8, 2002, 2:46:08 PM11/8/02

to

Nick Karagiaouroglou wrote:

> ... \GSLIST can't be used for a

> symbolic sum.

> ... \GSLIST can't be used for a

> symbolic sum.

Again one of these unchecked claims typical for you.

Put a list of two symbolics on the stack, { A B }

say. Apply SigmaLIST. The result is 'A+B' as expected.

SigmaLIST yields the symbolic sum also in the general

case of a list of algebraics if the list size is >1.

Maybe one has to care about some flags.

And here a second wrong statement of yours, in

the same context. In contradiction to your claim

that the additive semigroups of the HP49 have all

a neutral element the truth is that the additive

semigroup of symbolics has *no* neutral element.

(even the NULLSYMBOLIC, accessable only in SysRPL,

is not a Zero with respect to +).

What an annoying di