[Om3] strict/pragmatic for cn.

[Michael Kohlhase]

Stephen Watt wrote:
> Hello from London.  Once you decide about which part of the day to
> have this discussion, I can see whether I can join by telephone or
> chat.
>
> Don't forget the other option, which is to propagate new MathML design
>   
Actually, there are a couple of issues up for discussion on om3 where
you can propose this :-).

Michael
> -- Stephen
>
> On Fri, Oct 24, 2008 at 3:26 AM, David Carlisle <davidc at nag.co.uk> wrote:
>   
>> Michael,
>> I agree that we should include cn normalisation in the pragmatic/strict
>> transform and description, including removal of any <sep/>, but...
>>
>>     
>>>  OpenMath, which only supplies OMI (Integers) and OMF (IEEE Floats)
>>>       
>> This is true, but this more than anything else in OM shows its
>> origins in computational numeric systems at a particular point in time.
>>
>> It's a limitation we can live with in OM, but copying it to MML would
>> be a harmonisation too far I think.
>>
>> I think in the "K-12-14" range that we claim MathML targets saying that
>> IEEE double is primitive but real numbers are not really can't work.
>> Even in the field of numerical computing it's not so clear that double
>> has the status that it once had (NAG keeps thinking about quad prec for
>> example)
>>
>> So I agree we should make cn normalization an explict part of
>> pragmatic->strict, but I don't think that the noralization should be so
>> agressive. That does mean that further normalization to OM will need to
>> be done (and documented somewhere).
>>
>> meanwhile comments on the current draft...
>>
>>
>>
>>
>>     
>>> The base attribute should only be used on elements with type "integer"
>>> or "real".
>>>       
>> why not e-notation (at least)
>>
>>     
>>> When base > 36, some integers cannot be represented using numbers and
>>> letters alone
>>>       
>> anglo saxon bias on the definition of letter here
>>
>>
>>     
>>> (in the same was as described for type "integer").
>>>       
>> way
>>
>>     
>>> The content of a cn element may be PCDATA
>>>       
>> traditionally we've allowed mglyph
>>
>>     
>>> , a infinity symbol (representing positive real infinity), a minfinity
>>> symbol (representing negative real infinity) or a notanumber element.
>>>       
>> Not clear why you need <cn><infinity/></cn> rather than just <infinity/>
>>
>>     
>>> e-notation
>>>    This type is deprecated. It is recommended to use double or real instead.
>>>       
>> why,  do we really want to change
>> <cn type="e-notation>1<sep/>100</cn> to
>> <cn
>> type=""real">1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cn>
>>
>>
>> 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.
>> ________________________________________________________________________
>>
>>
>>     

-- 
----------------------------------------------------------------------
 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
----------------------------------------------------------------------