Range of a function
<<Read this in a fixed-width font.>>
Nate, and P1788 members
I don't want to sound shrill, but may I ask the modal folk to stop
referring to the definition of the range:
range(f, ss) = { f(x) | x in ss and x in domain D_f of
f } (eqn1)
where f is a function from a set X to a set Y (i.e., f : X -> Y),
and ss is any subset of X,
as a "cset interpretation", please?
It has nothing to do with csets as such. Csets just use it, but it is
classical set theory and standardised (I believe) from around 1910.
In all my own experience of areas of mathematics -- mainly topology,
real analysis, functional analysis and numerical analysis -- this has
been standard and unquestioned. I would cite, e.g., Kelley's "General
Topology" for chapter & verse, but just now it is buried in a box in
my messy house (where for several days yet, the electrician rips up
ever more old carpet, lifts ever more floorboards, and spreads ever
more brick dust).
At the mathematical level, evaluating a function at a single point
has a different notation from evaluating over a set.
EVALUATE AT POINT EVALUATE ON SET
f(x) = { y if x in D_f range(f,{x}) = { {y} if x in D_f
{ and {
{ else "undefined" { else Empty
are, in set theory, equivalent; either can be regarded as syntactic
sugar for the other. I have always regarded "evaluate on set" as the
more appropriate for interval theory.
Which is why I am _strongly_ against hi-jacking NaI to have a meaning
"f(x) undefined". The set paradigm has Empty to mean that. If the
modal folk need NaI to mean that, then we need more than one NaI.
That's OK. As I shall shortly be arguing (if Dan Zuras and others
don't beat me to it) various people think 754 should have provided
for several "official" NaNs, with specified different meanings and
resulting semantics; and we should seriously consider doing that from
the start with NaI.
I am aware of 3 main ways of evaluating a function, relevant to
interval applications:
1. To take (eqn1) as it stands, and if f fails to be everywhere defined
on ss, make no comment.
Personally, I call this "loose" evaluation but if there's another
commonly used name I'm happy to use it.
Optimisation people need this, e.g. in branch & bound methods, when
deciding whether a sub-box should be kept or discarded. It is of
no consequence whether f is defined everywhere on the sub-box.
2. To take (eqn1) as it stands, but if f fails to be everywhere defined
(and continuous) on ss, raise a flag or equivalent.
Personally, I call this "strict" evaluation.
People doing validated solution of ODEs need this, to check that it
is valid to apply a fixed-point theorem.
3. The "reverse mode" meaning of evaluation, defined by Arnold Neumaier
in his June 2008 email, and specified in detail by the Vienna
proposal.
Constraint propagation people need this.
Those are all within the set paradigm. The modal paradigm may have
needs incompatible with all of these -- that's fine, as long as we
all recognise it.
Let us keep in our minds as we move to the implementation levels of
the standard, that we need to support each of these "ways" and make them
- convenient to use by simple-minded programmers,
- efficient at run time.
If I understand Michel Hack's recent email correctly, he thinks this
is perfectly feasible, and our task is largely a matter of design
choices rather than of deciding principles.
Best wishes
John Pryce
j.d.pryce@xxxxxxxxxxxx