[Trac] [OpenMath] #59: CD minmax1

[OpenMath]

#59: CD minmax1
------------------------------+---------------------------------------------
     Reporter:  jauecker      |          Owner:  kohlhase  
         Type:  proposal      |         Status:  new       
     Priority:  major         |      Milestone:  CD3 Draft1
    Component:  OM3 Standard  |        Version:            
   Resolution:                |       Keywords:            
Include_gantt:  0             |   Dependencies:            
   Due_assign:  YYYY/MM/DD    |      Due_close:  YYYY/MM/DD
------------------------------+---------------------------------------------
Comment (by jauecker):

 '''David:'''


 >Detail: You are quite correct, in this case, but if min over (0,1] is
 'allowed' then please make it 0, not something like 'the smallest positive
 IEEE number' or 'undefined'.  In other words, feel free to extend its
 coverage but do not hence make its result unintuitive at the K-12 level.

 actually I really think MathML shouldn't say.

 the content mathml for min over (0,1] means just that, and you should be
 able to write it down without knowing what it means.

 whether it means undefined, or 0 or the smallest ieee double is
 something that depends to a certain extent on the context.
 MathML only needs to define that <min/> relates to the min function, it
 shouldn't define the min function itself. Also as a general principle,
 the arguments (child nodes) of an expression in MathML should never be
 restricted by mathematical concepts, only structurally. You should be able
 to apply <min/> to a set of complex numbers, even though that isn't
 (normally) an ordered set; if only to encode the statemnt that the
 minimum doesn't exist, or to allow a student to write down a wrong
 answer, or...


 >Sure, but for K-12 it would be reasonable to limit to a smaller,
 understandable class of functions (assuming we said anything at all about
 their domains, such as what a funtion is and whether it is real, complex,
 quarternionic ...).  For example we could only integrate functions with
 'discrete discontinuities' (thus nothing on 'bounded
 variation' ... hope I recalled that bit correctly:-).

 I don't think the mathml spec should go anywhere near such
 cosiderations. You should be able to implement a conforming mathml
 implementation that just takes content mathml and renders them (via TeX
 for example) to do this you need to know that <int/> means integral (or
 at least that it is rendered with an integral sign) you don't need to be
 able to investigate the mathematical properties of the integrand.
 the integrand can be an image (an mglyph inside a csymbol for example).
 The fact that integration can only be applied to certain
 functions should not limit the terms that may be used as the child of
 <int/> any content mathml expression may be used as the integrand.
 All we have to say is that the term the denotes the integral of the
 integrand. Whether or not that term has any mathematical value isn't
 something that we can specify.

 I don't disagree with you that the level of mathematical sophistication
 assumed by the descriptions is variable, but in all cases I'd move
 towards normalising things to say as little as possible. Basically you
 just need to say enough and with enough mathematical rigour to say which
 function you mean. So for plus you can just refer to "addition" but for
 the inverse trig functions you need to tie down branch cuts and refering
 to an external refernce is one way to do that without having to mention
 any details of why the definition of the function might not be obvious.
 For standard deviation and other stats/probability functions you may
 need to say a bit about sampling/distribution in order to keep yourself
 honest but the less we say the better.

-- 
Ticket URL: <https://trac.kwarc.info/OM3/ticket/59#comment:5>
OpenMath <http://www.openmath.org>
The development of the OpenMath Standard and Content Dictionaries.