Konrad Hinsen skrev 2014-02-25 10.07:
Alberto González Palomo writes:
Thanks for the example. That's in fact the kind of information I was
looking for: general design principles that help finding the right way
to express things.
I feel another piece of general design principles coming up...
For the particular case of "sum", I find the definition in arith1 a
bit vague:
An operator taking two arguments, the first being the range of
summation, e.g. an integral interval, ...
There is no definition of "range of summation", just an example. You use a
set in your example, which is fine, but there's nothing in the definition
of "sum" that tells me that sets are a valid specification for a "range of
summation".
Which leads to another question: is there any validation tool for
OpenMath that checks the semantics? The XML schemas and the XSLT
stylesheet from the OpenMath Web site only check syntactical aspects,
they won't stop me from using transc1/sin as a summation range, for
example.
The semantics aren't part of the standard, and often not specified by the
content dictionaries either.
What ultimately defines semantics of symbols are the programs that read or
write OM objects -- those that the standard (somewhat unintuitively) refers
to as phrasebooks. Different phrasebooks are not required to agree on the
semantics of a symbol: one phrasebook may support sets as first argument of
arith1#sum, another phrasebook might have no concept of sets and therefore
only support arith1#sum where the first argument is the blessed kind of
integer interval, and a third phrasebook might not support arith1#sum at
all. The first approach would be natural for a full-featured CAS like Maple
or Mathematica, the second approach would be sensible for a phrasebook that
is a front-end for some programming language with first-class functions but
not sets, and the third approach is sensible if the phrasebook doesn't even
support first-class functions and thus wouldn't have much use for this symbol.
Claims that arith1#plus is associative shouldn't be taken as excluding
floating-point numbers (except possibly to exclude using arith1#plus in a
context where you really wish to discuss the gory details of floating-point
addition). What it means is rather that the _concept_ of addition expressed
by this symbol may be assumed to be associative, and phrasebooks may
preprocess expressions accordingly, should they feel like doing so. So the
little lie involved is rather "I lie when I say this floating-point
operation really is addition, but the error is negligible, and you know what
I mean anyway." Besides, if you express something scientific, I suspect you
really want real number addition, and use floating-point addition in
calculations simply because it is good enough.
Lars Hellström
_______________________________________________
Om mailing list
[email protected]
http://openmath.org/mailman/listinfo/om