piece1 CD: What if pieces overlap?

[lars-hellstrom]

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.

[JamesHDavenport]

I like the idea of elsepiece. If someone wants to write this, I’ll review it. From: lars-hellstrom [mailto:[email protected]] Sent: 23 July 2017 19:33 To: OpenMath/CDs <[email protected]> Cc: Subscribed <[email protected]> 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->.

[kohlhase]

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.

[car222222]

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.

[lars-hellstrom]

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

[davidcarlisle]

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

[kohlhase]

I support this solution.