[Om] Tutorial or example collection for OpenMath?

[Lars Hellström]

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