piece1 CD: What if pieces overlap? #6

Activity

1. JamesHDavenport commented on Jul 24, 2017

   

   JamesHDavenport

   on Jul 24, 2017 via email

   Contributor

   More actions

   I like the idea of elsepiece. If someone wants to write this, I’ll review it. From: lars-hellstrom [mailto:notifications@github.com] Sent: 23 July 2017 19:33 To: OpenMath/CDs <CDs@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [OpenMath/CDs] piece1 CD: What if pieces overlap? (#6) This is mostly a note for Chris, who was given the task of looking through the CDs for issues. Looking at piece1, I see the following in the description of piece1.piece: This introduces an individual component of a piecewise definition. It has precisely two arguments: the first is the value, and the second is a Boolean (meant to be a predicate) which is true if and only if this piece is to provide the value of the piecewise construct. (Emphasis mine.) This means several pieces can provide the value simultaneously, and logically I think that amounts to making an implicit claim that the separate pieces agree on the value whenever that happens, which is fine mathematically but possibly unexpected if coming from a programming perspective. Thus I think the following changes would be useful: * Add a note (CDComment or Example) making the above explicit, as a warning to the user. * Add a constructor elsepiece (or whatever) that is like piece, but implicitly includes the requirement that no previous piece's condition is true. This is of course trivially reducible to piece (and for reasoning that might be the right thing to do), but I think elsepiece would be a more direct counterpart of similar constructions in programming languages than piece is, so having both might help avoid transcription errors. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#6>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGvamYRMrou6feHwsQ6szUWr25N6jf7gks5sQ5HdgaJpZM4Ogh9->.
2. kohlhase commented on Jul 25, 2017

   

   kohlhase

   on Jul 25, 2017

   Member

   More actions

   I do not really like the idea of elsepiece, but we could just adopt the convention of programming languages that always the "first matching piece gets executed". We will just have to clarify the behavior in notes and maybe even FMPs and examples.
3. car222222 commented on Jul 28, 2017

   

   car222222

   on Jul 28, 2017

   Collaborator

   More actions

   Right now I prefer Michael's solution (assuming he is correct about 'first match wins' being 'the convention'). This is certainly true for case-like statements but when setting values the later setting usually over-rides the earlier.
4. kohlhase

   assigned

   car222222

   on Jul 28, 2017
5. lars-hellstrom commented on Sep 12, 2017

   

   lars-hellstrom

   on Sep 12, 2017

   Author

   More actions

   The MathML standard (Section 4.4.1.9) is more explicit on this matter:

   It should be noted that no "order of execution" is implied by the ordering of the piece child elements within piecewise. It is the responsibility of the author to ensure that the subsets of the function domain defined by the second children of the piece elements are disjoint, or that, where they overlap, the values of the corresponding first children of the piece elements coincide. If this is not the case, the meaning of the expression is undefined.

   If nothing else, this invalidates the interpretation made by @kohlhase
6. davidcarlisle commented on Oct 6, 2017

   

   davidcarlisle

   on Oct 6, 2017

   Member

   More actions

   I think the easiest way to resolve this while maintaining mathml compatibility is to copy the wording @lars-hellstrom quoted from mathml and stick it in piece1.ocd
7. kohlhase commented on Oct 7, 2017

   

   kohlhase

   on Oct 7, 2017

   Member

   More actions

   I support this solution.