Alberto González Palomo writes: > I'm not aware of any validation tool, but you can check the Simple > Type System (STS) used for symbol signatures in the OM CDs. > http://www.openmath.org/cd/sts.xhtml
Thanks, that looks interesting. What's the status of these type signatures? Are they part of the CD, and thus of the standard? I don't remember seeing any reference to them in the OpenMath Standard 2.0. > For instance, arith1:sum has: > > http://www.openmath.org/sts/arith1.xhtml#sum That's bad news for me because it means I can't use OpenMath sums at all for my application. Sums are defined only for Abelian monoids, which excludes any expression containing floating-point numbers, since floating-point addition is not associative. This is not merely a theoretical concern as summation order definitely matters in some of my use cases. Exploring further, I note that arith1.plus also requires commutativity. Is there any CD that covers floating-point arithmetic? OpenMath does provide floating-point numbers, so there should also be something one can do with them. > For the double sum you mentioned, that would be nested: A bit verbose but perfectly fine - if I didn't need those floats. Francis Wright writes: >> 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". If by "set" you mean the use of { } in the example above then I think that is part of the TeX syntax used to present the example and does not imply a set. Lars explicitly referred to set1.cartesian_product, so I do have a set. Reconsidering this, it wouldn't really help me because a summation range defined by a set obviously implies that summation order doesn't matter. Konrad. _______________________________________________ Om mailing list Om@openmath.org http://openmath.org/mailman/listinfo/om