[Om] Tutorial or example collection for OpenMath?

[Konrad Hinsen]

David Carlisle writes:

 > There are STS signatures for all the core CDs and there is a link from
 > each symbol in the (x)html presentation of the CD to the corresponding STS.
 > 
 > So the status of the STS is that they are an official part of the
 > OpenMath release, but you don't have to use them to use the CDs if they
 > are incompatible with your needs (or you just don't like them:-)

OK, so I can either use "basic" OpenMath with loose semantics, or
"typed" OpenMath with stricter semantics. For the latter, I have the
choice between a light-weight type system (STS) and a more rigorous
one (ECC). Does that sound about right?

Are there ECC signatures as well for the core CDs? Or is ECC merely
a framework in which applications can define their own types?


Lars Hellström writes:

 > I feel another piece of general design principles coming up...

Great :-)

 > 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 

OK, that fits with the summary I tried to make above. Type signatures
are then a way to fix semantics, but everyone can come up with their
own.

Is there any way to state the semantics rules to be applied in an
OpenMath document? This could either be something precise like "use
the STS signatures from the OpenMath site" or the simple statement
"this document was created by phrasebook XYZ".

 > 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 

That's fine for many applications, but the non-associativity of
floating-point addition is sometimes a real problem, in particular
when program writers happily ignored it. See
http://dx.doi.org/10.1109/MCSE.2011.21 for a real-life story about a
program that produces different results depending on the number of
processors it runs on (due to dependence on summation order), with the
differences being so important that they change the interpretation of
the results.

Konrad.