Some User RPL questions
Joseph K. Horn
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-
Bill Storey
(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)
James Horn
> (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
Per Blomqvist
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...
John H Meyers
> 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! =-----
John H Meyers
John H Meyers
> 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]
Wolfgang Rautenberg
> 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
John H Meyers
> 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? ;-)
Per Blomqvist
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...
Wolfgang Rautenberg
> 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
Per Blomqvist
"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 ).
Wolfgang Rautenberg
> { 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
Joseph K. Horn
-jkh-
rcobo
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
Veli-Pekka Nousiainen
VPNnews:3DBA6067...@math.fu-berlin.de...
Paul Floyd
>
>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?
Peter Geelhoed
>
> 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)
Nick Karagiaouroglou
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.
Wolfgang Rautenberg
> > 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
Peter Geelhoed
>
> > 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
Wolfgang Rautenberg
> 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
John H Meyers
> { 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
Jean-Yves Avenard
"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
John H Meyers
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!
John H Meyers
Nick Karagiaouroglou
> (sum and product of list elements) won't even accept
> a list of *one* element! (Error: Invalid Dimension!)
Easy.
0 + SigmaLIST
1 + PiLIST
Nick.
John H Meyers
[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?" ;-)
Veli-Pekka Nousiainen
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
Veli-Pekka Nousiainen
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...
Wolfgang Rautenberg
> > 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
Nick Karagiaouroglou
> 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.
Nick Karagiaouroglou
> 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??;-))
John H Meyers
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 :)
Wolfgang Rautenberg
> 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
Carsten Dominik
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
John H Meyers
> 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!
Wolfgang Rautenberg
> 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 :-)
John H Meyers
UPDIR is backward, DOWNDIR is forward :)
I'm not quite sure which way Down Under is, however.
-[30]-
Veli-Pekka Nousiainen
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...
Joseph K. Horn
>
> 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-
Nick Karagiaouroglou
> 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.
Nick Karagiaouroglou
> 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.
John H Meyers
> 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]
Nick Karagiaouroglou
> [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.
John H Meyers
> 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]
.
Nick Karagiaouroglou
> 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.
John H Meyers
> 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).
-[]-
Veli-Pekka Nousiainen
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
Wolfgang Rautenberg
> > 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
Veli-Pekka Nousiainen
> 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
Wolfgang Rautenberg
> 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
Nick Karagiaouroglou
> 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.
Nick Karagiaouroglou
>> 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.
Veli-Pekka Nousiainen
> 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
Wolfgang Rautenberg
> > 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 ...
Nick Karagiaouroglou
> 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.
Nick Karagiaouroglou
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.
Wolfgang Rautenberg
> ... \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 discussion with you. Isn't it
completely obvious that SigmaLIST applied to the
empty list cannot reasonably be defined in a
general way? As pointed out already by JHM, the
best thing is let { } SigmaLIST error as it does.
I know you'll not much care about these remarks.
But I hope some others in this NG will.
- Wolfgang
PS. If I were you I would leave this NG for a
year to learn basic math and programming. Having
less noise of empty barrels could perhaps be a
signal to some experts (like DM) to return to
this NG :-)
John H Meyers
> 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 empty list as element in the original list
> that we gave \GSLIST. That is from {} \GSLIST we default to { {} }
> \GSLIST.
What, then, if you perform "+" with nothing at all on the stack?
Why, I now know -- because of the "generality" of lists as arguments
to +, we *assume* that the null stack defaults to one empty list,
and the sum of that empty list, in general, is that list itself,
so from <empty stack> + we default to the same thing as
summing { {} } and thus we return an empty list,
rather than "Too Few Arguments"
Hey, I get it, at last!
Veli-Pekka Nousiainen
It seems possible to do that using betaENTER and STARTERR
I mean: put an empty list on an empty stack when user presses [ + ]
I think I'm also finally getting it. ;-)
VPN
PS: I should leave this NG for a decade to learn some serious math,
but naah...I rather watch and learn from mistakes and debates.
It hurts, but no pain - no gain..news:3DCC96B6...@miu.edu...
X
John H Meyers
> the special case of normal addition of numbers is commutative
In algebraic theory, but not in practical computation, e.g.
{ 3.0 -2.0 -1.0 1E-15 } \GSLIST
is not the same as
{ 3.0 -2.0 1E-15 -1.0 } \GSLIST
For a "sidebar" on the more accurate computation
of means and standard deviations, see:
http://groups.google.com/groups?selm=56sid5%24dj3%40news.iastate.edu
http://groups.google.com/groups?threadm=868566066.6605%40dejanews.com
http://groups.google.com/groups?selm=3B8B0C34.E9E99F91%40miu.edu
Nick Karagiaouroglou
> Seen:
>
> > 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 empty list as element in the original list
> > that we gave \GSLIST. That is from {} \GSLIST we default to { {} }
> > \GSLIST.
>
> What, then, if you perform "+" with nothing at all on the stack?
>
> Why, I now know -- because of the "generality" of lists as arguments
> to +, we *assume* that the null stack defaults to one empty list,
> and the sum of that empty list, in general, is that list itself,
> so from <empty stack> + we default to the same thing as
> summing { {} } and thus we return an empty list,
> rather than "Too Few Arguments"
>
> Hey, I get it, at last!
Indeed, this would be the strict consequence of "defaulting" nada args
to an empty list. Anyway, all that adventurous things are only meant
in the sence "*if* we want no errors at all for \GSLIST, *then* this
could be a possible concept".
Of course, as you said, the question is, do we really want to default
any possible "bad argument value" or "too few arguments"? I don't
think so.
Greetings,
Nick.
Nick Karagiaouroglou
> by people discussing things they'd better mute upon.
And of course Wolfgang will decide who these persons are.
> 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.
Oh, then I wonder what the error message after {} \GSLIST
wants to say to me. Well, *that's* real mystic. Anyway,
on the HP49G it is possible to have \GSLIST opeerate upon
missing arguments. And it is exactly this case, which I
thought about - provided we have demand additionally to
avoid *any* error messages. Only under these premises, I
thought about some possible behavior of the command.
In general, the operation defined upon a set that contains
"nada" , can as well do anything to the elements, so also
checking if "nada" has been supplied to the operation.
Again, this is the case on the HP49G, not because of some
universal valid truth, but simply because the user *can*
supply and empty list to \GSLIST. You can consider this
as an error and say that "nada" doesn't belong to the set
upon the element of which the operation operates, and so
return an error message. *Or* you can consider "nada" as
a valid element of the set and try to change the behavior
of \GSLIST, so that it doesn't error out.
The second of the two possibilities is neither wrong nor
exotic. (Take a look at Mathematica.)
Nick
Nick Karagiaouroglou
> Nick Karagiaouroglou wrote:
> > ... \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.
This is not what I meant, and this is also not what VPN
meant, I think. I rather talked about for example
sum(n=1,N,n) which \GS can handle, but \GSLIST can't.
> 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 +).
Really?
number+0=number
"string"+""="string"
(complex)+(0,0)=(complex)
and so on.
> What an annoying discussion with you. Isn't it
> completely obvious that SigmaLIST applied to the
> empty list cannot reasonably be defined in a
> general way? As pointed out already by JHM, the
> best thing is let { } SigmaLIST error as it does.
> I know you'll not much care about these remarks.
> But I hope some others in this NG will.
I repeatedly said that I don't want to change the current
behavior of \GSLIST. I think only about a change *in case*
we want it not to error out, when {} is supplied as argument.
> PS. If I were you I would leave this NG for a
> year to learn basic math and programming. Having
> less noise of empty barrels could perhaps be a
> signal to some experts (like DM) to return to
> this NG :-)
Thanks heavens you are not me, and for the future you will
leave such decisions for me. The only signal that this
group needs is that thinking is not a priviledge of any
particular person, who then decides who else is allowed
to think and who isn't. I have to repeat once more, please
comment anything that I say, but stop advertising me as
the "bad/stupid guy". This is neither fair, nor nice.
Nick.
Nick Karagiaouroglou
> Seen:
>
> > the special case of normal addition of numbers is commutative
>
> In algebraic theory, but not in practical computation, e.g.
>
> { 3.0 -2.0 -1.0 1E-15 } \GSLIST
>
> is not the same as
>
> { 3.0 -2.0 1E-15 -1.0 } \GSLIST
Sigh! It seems that practical computation still doesn't exactly follow
theory. Well, only textbooks are ideal, the rest being a more or less
imperfect implementation.
Nick.
Wolfgang Rautenberg
Wolfgang Rautenberg wrote
> > Nick Karagiaouroglou wrote:
> > > ... \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.
> This is not what I meant ...
Relevant is what you write and not what you mean.
You wrote that \GSLIST can't be used for a symbolic
sum, and this is simply wrong!
> > 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 +).
> Really?
> number+0=number
> "string"+""="string"
What has the fact that the semigroup of strings has
a Zero in common with the fact that the additive semigroup
of symbolics has not ??? You claimed that *each* semigroup
dealt with by \GSLIST has a neutral element. And this
is wrong again.
> ... but stop advertising me as
> the "bad/stupid guy"...
I didn't say you are a bad guy, but if you classify
yourself as a stupid guy, I do not contradict...
- Wolfgang
Nick Karagiaouroglou
> Nick Karagiaouroglou wrote:
> Wolfgang Rautenberg wrote
> > > Nick Karagiaouroglou wrote:
> > > > ... \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.
>
> > This is not what I meant ...
>
> Relevant is what you write and not what you mean.
> You wrote that \GSLIST can't be used for a symbolic
> sum, and this is simply wrong!
Sometimes the meaning of what one says can be assumed viewing the
history of the thread. Veli-Pekka has already commented in the
preciding messages:
>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.
"Symbolic sums" stands here for sums like sum(n=1,N,n), was my
assumption and that's why I just used the same words again.
Even the corresponding package of Mathematica is named "symbolic sums"
though symbolic items in a list can be added with each other without
this package.
Of course the HP49G is not Mathematica (and how we wish it would be
;-)) but you seem to always find something to hook on especially when
you already have put somebody in some category.
If what I write is relevant, then I might remind you to apply this
first to you and remember what you wrote about be here one year ago.
If I have taken that for relevant you wouldn't sit where you sit now.
> > > 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 +).
>
> > Really?
> > number+0=number
> > "string"+""="string"
>
> What has the fact that the semigroup of strings has
> a Zero in common with the fact that the additive semigroup
> of symbolics has not ??? You claimed that *each* semigroup
> dealt with by \GSLIST has a neutral element. And this
> is wrong again.
Is it? Then find me please a counter example with no neutral element.
And BTW, *you* spoke about semi-groups. It was not a coincidence that
I stayed to algebraic structure and didn't go further. The properties
of the structure have to be found first and then we should go on
classifying.
> > ... but stop advertising me as
> > the "bad/stupid guy"...
>
> I didn't say you are a bad guy,
You *did* but you forgot later. So much about relevance of written
words.
> but if you classify
> yourself as a stupid guy, I do not contradict...
This seems to be your biggest wish, isn't it Wolfgang? OK, I dare
classify myself stupid, and I'll never dare calling me intelligent,
quite contrary to you, the most brilliant programmer of all times, to
which we must sing hymnes of admiration all our lives, in order to
keep him happy.
Agnowledgement and admiration is not everything, Wolfgang...
Nick.