[Om3] [Fwd: ISSUE-33 (statistical symbols): Kyle's Siegrist's request for new Content-MathML symbol]

Michael Kohlhase m.kohlhase at jacobs-university.de
Mon Oct 27 07:37:26 CET 2008


Dear all,

I talked with Chris Rowley at the MathML F2F, he has been encouraged by
your coments to try and come up with a first draft for the CDs.

Michael

Professor James Davenport wrote:
> On Fri, October 24, 2008 5:10 pm, Paul Libbrecht wrote:
>   
>> Le 24-oct.-08 à 12:09, Professor James Davenport a écrit :
>> so we would make the whole of combinat1 in MathML-cd-group?
>>     
> I don't see why? The original author merely wanted to beable to express
> this is MathML (as opposed to the case where it COULD already be expressed
> in MathML, and MathML3 had to preserve this expressibility. My informal
> understanding of the MathML CD group was "all the CDs needed to express
> the (pragmatic->strict versions of the) MathML-C in MathML 2".
>   
>>>> 2. Permutation coefficient:  n(n -1)...(n - k + 1), usually
>>>> rendered P(n, k) or nPk or (n)k.
>>>>         
>>> Personally, I've always written n!/k!, but if there's a call for it, I
>>> could always add it to combinat1.
>>>       
>> Looks like it's common so it's probably needed in combinat1.
>>     
> True. Michael - can you ask your student who's working on OM3 CDs to do
> this, since he's probably more up-to-date with the tools than I am at the
> moment.
>   
>>>> 3. A probability operator with an optional "given" construction
>>>> (for conditional probability).  Typical rendering would be
>>>>    P(A, B, ...) (without conditioning) or  P(A, B, ... | C, D, ...)
>>>> (with conditioning).
>>>>         
>>> For the monadic versions P(A), or P(A|C D ...) I have no problem: I
>>> assume
>>> their absence is due to the fact that we never had a probabilist on
>>> board
>>> in OM. I assume the proposers P(A, B, ...) is P(A&B&...), and we MIGHT
>>> want to see that represented explicitly.
>>>       
>> I've never seen the "," sepped version (though been TA in such branch,
>> shame on me!).
>>     
> I think that adds to my question.
>   
>>>> 4. An expected value operator with an optional "given" construction
>>>> (for conditional expected value).  Typical rendering would be E(A,
>>>> B, ...) (without conditioning) or  E(A, B, ... | C, D, ...) (with
>>>> conditioning).
>>>>         
>>> Again, I hace no problem with E(A) or E(A|C ...).
>>> I have no idea what is meant by E(A,B).
>>>       
>> You can measure expectation on any event, can't you?
>>     
> Yes, but what is the 'event'. What do you understand by
> E(height,weight|elephant)? The tuple (3m, 9500kg)? In that case, how is
> this different from the tuple (E(height|elephant),E(weight|elephant))?
> Note that I'm not saying there's a good rason against it, merely that I
> haven't seen a good reason for it.
>
> James Davenport
> Hebron & Medlock Professor of Information Technology
> Formerly RAE Coordinator and Undergraduate Director of Studies, CS Dept
> Lecturer on CM30070, 30078, 50209, 50123, 50199
> Chairman, Powerful Computing WP, University of Bath
> OpenMath Content Dictionary Editor
> IMU Committee on Electronic Information and Communication
>
>   

-- 
----------------------------------------------------------------------
 Prof. Dr. Michael Kohlhase,       Office: Research 1, Room 62 
 Professor of Computer Science     Campus Ring 12, 
 School of Engineering & Science   D-28759 Bremen, Germany
 Jacobs University Bremen*         tel/fax: +49 421 200-3140/-493140
 m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase 
 skype: m.kohlhase   * International University Bremen until Feb. 2007
----------------------------------------------------------------------



More information about the Om3 mailing list