This one is really (quite) short!
David wrote -- >> It's not particularly common (and never necessary) to specify both a >> domain and a condition And moreover, there is no difference between these since 'being an element of the domain' is a condition; and the other conditions are merely 'AND'ed with this condition to describe a new domain. But hold, I am not sure that I am now again agreeing completely with David. I do agree with him that there should be no need for things like 'prodcond' since all BINDS must have a condition (although syntactically it may be missing since it is assumed or depend on the context or ...) In particular, it is not clear to me why a 'vector of A's' (or any collector) is intuitively reasonable just to avoid extending the syntax. Why must OM remain frozen in this way? Everything in OM could be expressed in a language as simple as (or even simpler than) NL3 but that might be less efficient and would certainly make it less understandable to mathematicians (of coourse, it might help software??). So it comes back to the question of how close to commonly used non-digital methods of describing 'mathematical semantics' should OM be? chris to a subset of the [email protected] wrote: ----- To: [email protected] From: [email protected] Sent by: [email protected] Date: 23/03/2009 11:00 Subject: Om3 Digest, Vol 18, Issue 5 Send Om3 mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://openmath.org/mailman/listinfo/om3 or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Om3 digest..." Today's Topics: 1. Re: Summary of the Davenport&Kohlhase Proposal (David Carlisle) 2. Re: Summary of the Davenport&Kohlhase Proposal (Paul Libbrecht) 3. Re: Summary of the Davenport&Kohlhase Proposal (David Carlisle) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Mar 2009 10:20:40 GMT From: David Carlisle <[email protected]> Subject: Re: [Om3] Summary of the Davenport&Kohlhase Proposal To: [email protected] Message-ID: <[email protected]> I'm strongly opposed to this. I'm opposed to the change to OpenMath and if we should as a group decide to change OpenMath in this way, I'd still argue that MathML would be best advised not to use the new features in any mapping to its "strict" subset. This is a breaking change to OpenMath, with a rather thin justification, which is, in total > James and I don't like that this has two binds and two unrelated dummy > variables, That is, it is introducing a breaking change for purely cosmetic reasons. It wouldn't be impossible to consider change if the change was actually an improvement but I don't think it is, for several reasons. A binding symbol is currently typeable by viewing ombind head bvar x f(x) as syntactic sugar for apply head lambda x. f(x) A binder with multiple children, as proposed here, can thus be seen as essentially mapping to the cartesian product of the domains of each of the children, but uniquely for openmath the vector construct symbol is being omitted. If it is made explict then no extension is needed, and only a single child of ombind is needed. Michael's proposed bind(O,v_1,...,v_n,A_1,...A_n) is just a custom syntax for bind(O,v_1,...,v_n, apply vector (A_1,...A_n) ) > So we are proposing a liberalization of OpenMath objects: all OpenMath2 > objects are extended Objects and retain their original meanings. But can > now define more mathematical symbols and represent more objects. No, actually you can only represent the same set of objects, with the extra complication that there are more ways to do it, so need extra FMP saying that they are equivalent, and the extra complication that the new way breaks all existing OM applications. > with a new symbol productcond. Irrespective of whether we extend OMbind, I don't think we should explode the number of symbols required by introducing symbols like this. The example Michael happened to pick on had both a domain [0,k] and a condition (i !=- j) specified, and the proposed rewrite to a prodcond symbol that _requires_ both a domain and a condition (as they are given positionally). It's not particularly common (and never necessary) to specifiy both a domain and a condition, so this prodcond symbol would almost always require dummy conditions being specified (such as ("true" or default domains being specified, to fill in the relevant slots. Or you have yet more additional symbols, for product(withdomain) and product(justwithcondiition)/ In all cases the choice of whether to specify a constraint on a bound variable as a domain constraint or a condition is entirely arbitrary. Saying that a bound variable has domain R is the same as saying it is subject to a condition (x in R) and these two formulations should have the same openmath encoding, but this proposal arbitrarily distinguishes them as ombind prodcond bvar x R true f(x) and ombind prodcond bvar x some-superset-of-R apply in x R f(x) In general for a more complicated domain you may, at the authors whim, choose to express part of the constraint as a domain and part as a condition, so Michael's example domain: [0,k] condition: i!=j could just as easily be expressed as domain: R condition: i in [0,k] and i!=j or domain: [0,k] \ {j} condition: true or any other alternative, the distinction between domain and condition is entirely arbitrary and it's a feature not of problem of OpenMath that these are not distinguished. David ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________ ------------------------------ Message: 2 Date: Mon, 23 Mar 2009 11:39:15 +0100 From: Paul Libbrecht <[email protected]> Subject: Re: [Om3] Summary of the Davenport&Kohlhase Proposal To: David Carlisle <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" David, please explain how much this is breaking. I only see this as an expansion but I agree this brings yet another way of writing. It allows expressions which, earlier, were disallowed by the schema, to be allowed now. paul Le 23-mars-09 ? 11:20, David Carlisle a ?crit : > This is a breaking change to OpenMath, with a rather thin > justification, -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2203 bytes Desc: not available Url : http://openmath.org/pipermail/om3/attachments/20090323/a6c6a028/attachment-0001.bin ------------------------------ Message: 3 Date: Mon, 23 Mar 2009 10:46:16 GMT From: David Carlisle <[email protected]> Subject: Re: [Om3] Summary of the Davenport&Kohlhase Proposal To: [email protected] Message-ID: <[email protected]> > please explain how much this is breaking. > I only see this as an expansion but I agree this brings yet another > way of writing. Well it's my TeX heritage telling me that any change will break something. Since one of the main points of OpenMath is communicating expressions, making a change for cosmetic reasons that results in no existing systems being able to process the expression seems like a bad idea, even if you thought the change was an improvement. So my adjective "breaking" was probably gratuitous, as "breaking change" and "change" probably mean the same thing here. > It allows expressions which, earlier, were disallowed by the schema, > to be allowed now. In other words, making expressions that were authored previously in error suddenly aquire an unintended meaning and be no longer flagged as an error. David ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________ ------------------------------ _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3 End of Om3 Digest, Vol 18, Issue 5 ********************************** --------------------------------------------------------------------------- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302) _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
