Exactly. A data type comprises two sets: a set of values and a set of
operations defined using those values. A value then is simply a member
of a set which has operations defined over the set.

That definition for 'value of a function' is more equivalent to 'return
value' in a computational context. The RM doesn't make as much
distinction among functions and other relations; they are all relations.
Data type support, which is both necessary for the RM and orthogonal to
the RM, makes more distinction among functions and other relations.

Please note, though, that the wolfram definition is consistent with the
element of a set definition above, and the function f is merely an
operation defined using the set of values in its range (possibly among
other sets.)

What's wrong with the ISO 2382 definition? It's the first definition in
the standard.

The Greeks had a paradox:
1) A cat has one more tail than no cat.
2) No cat has 12 tails.
3) Therefore a cat has 13 tails.

The word "no" is used two different ways.  In the (1) "no" is a zero
and in (2) it is non-existence.

ab nilo, ex nilo  -- from nothing comes nothing.

But I have to have a bag first and it has to make sense to put bananas
in that bag.

Yes, zero is the additive identity.  But this is a convention used to
get rid of the empty set problem and preserve easy computations.

I agree that this is pure procedural programming in mathematical
disguise; I want a set-oriented solution.  This depends on the index
set being finite; commutative and associative are a bonus that don't
work so well for countably infinite series.  You can easily find a set
in which you associate the elements in different ways and get
different results.

(1 + -1 +1 + -1 +1 ..) = ((1-1) + (1-1) + ..) = 0
(1 + -1 +1 + -1 +1 ..) = (1 + (-1 +1) + (-1 +1) + ..) = 1

The convention is to say it is undefined or that it does not converge.
I am a little soft on saying the answer is the set {0, 1}, and
defining other such results as the set of naturals or whatever.  I
have no idea what the rules would be like.

No, I am saying I want to move from "list-theoretic" and "set-
theoretic" summations.

...

That's might be more polite than calling somebody a professional obfuscator.

Ah, I see Bob has preceded me with this point.

D'oh! :-)

Marshall

He'd say:

count = 0;
for each item
  count = count + 1
end for

And what does that evaluate to if there are no items? <<

Notice how you created zero from nothing?

Things can get really bad.  Your choices for defining a summation
indexed over an empty are to define it as zero to get rid of it or to
define it as undefined to get rid of it.  The important thing is to
get rid of it.

Another convention in traditional Sigma notation is that when the
initial value of an index is greater than the final value, the
summation is zero.  That is not a set-oriented approach to
summations.  Again, the idea that ordering changes the results is
strictly a convention.

What do you want to do about 0^0?   How would you define 0/0 without a
convention?  Instead of a FOR EACH loop, we might define summation
this way in pseudo-SQL.

CREATE FUNCTION Sum(my_set)
RETURNS <numeric data type>
AS
BEGIN
DECLARE total <numeric data type>;
SET total = MIN(my_set); -- exists in the data!
REPEAT
SET my_set = my_set – {MIN(my_set)}; -- remove element from countable
set
SET total =  total + MIN (my_set); -- add element that exists in data
to total
UNTIL my_set = {}; -- use all the elements
RETURN total;
END;

This handles a set with one element and we don't have to create a zero
out of thin air.  The loop removes the minimal element (could be max,
could be random) from the set and adds it to the running total until
the set is empty.  If the set starts empty, we get a NULL.

Now try these statements:

CREATE TABLE Empty – no rows possible
(i INTEGER NOT NULL
 CHECK (1=0));

SELECT SUM(i) FROM Empty;  -- returns  null
SELECT SUM(i) FROM Empty GROUP BY i; -- returns an empty table
SELECT SUM(i), COUNT(i), COUNT(*) FROM Empty GROUP BY i; --empty
table, 3 columns

So why is GROUP BY not returning a NULL or a zero?  That will give you
a headache!  A table always has at least one grouping, so there is
always at least one row.  Think of {{}}, a set whose element is the
empty set.  Let's keep going with another table that only has a NULL:

CREATE TABLE JustNulls
(i INTEGER CHECK (i IS NULL));

INSERT INTO JustNull VALUES (NULL);

SELECT SUM(i) FROM JustNull;  -- returns null
SELECT SUM(i) FROM JustNull GROUP BY i; -- returns null
SELECT SUM(i), COUNT(i), COUNT(*) FROM JustNull GROUP BY i; -- null,
0, 1

Once again you are introducing confusion, in this case muddying the
waters with unstated design questions, confusing a system that is
designed to anticipate suppliers and bills with one that isn't.   The
fact that such misconnections is tolerated by so many is just a
reflection of the rampant illiteracy in the western world today.  Those
people who can't position an English sentence relative to the task at
hand are no different from the janitor I knew who wanted the computer to
pick tommorow's track winners for him, they are basically incompetent
for the task.