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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://kwarc.info/kohlhase skype: m.kohlhase * International University Bremen until Feb. 2007 ---------------------------------------------------------------------- _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
