Re: The word "symbol"
Date: 18 Aug 2005 07:38:12 -0700
Message-ID: <1124375892.574334.167880_at_g44g2000cwa.googlegroups.com>
dawn wrote:
> Marshall Spight wrote:
> > >
> > > an ordered list, even (or do you consider that redundant?)
> >
> > Not at all! The formal term is "sequence" as distinct from set, but
> > I just use the term "list".
>
> when someone says "sequence" I assume ordering, if they say "multiset"
> or "bag" I assume no implied ordering, but with "list" I figure it
> could be either ordered or not. Is that a fair understanding of the
> terms?
Mostly. The one difference is that when I use "list" I mean it has order.
Here's a relevant quote from a set theory text:
"A *sequence* is a function from the set P of positive integers into a set A. ... Sometimes the domain of a sequence is the set N = {0, 1, 2 ... } of nonnegative integers rather than P. In such a case we say that n begins with 0 rather than 1. ... Such a finite sequence is sometimes called a list ..."
That's the definition I use: a list (or sequence) is a function from int -> A
> Yes. In fact, I am settled on that one with the last round on it here.
> I will hopefully not unsettle myself again the next time I read about
> how inferior any model is that orders attributes by using numbers
> rather than (or in addition to) naming them with words. cheers!
For myself, I try to distinguish between the "mathematical foundation" part, and the "good design" part. What works mathematically is not the same question as what makes for a convenient and useful notation.
It's *clear* that there are some places where, notationally, it is easier to speak of ordered attributes, and it is *clear* that there are some places where it better to use names.
Which would you rather write:
result = f(1,2,"hello");
or
result = f(origin=1, count=2, prompt="hello");
But at the same time, consider:
A:(origin, count, prompt)
result = { A | origin < count, length(prompt) > 0 }
In an ordered-tuple notation, the first thing you'd have to do is give components 1, 2, and 3 names so you could write expressions with them. I don't see how you could even write the second one without doing so, although I believe there are probably stack based languages that could do it.
Marshall Received on Thu Aug 18 2005 - 16:38:12 CEST