- From: Roger I Martin PhD <hypernexdev@hypernexinc.com>
- Date: Thu, 10 Feb 2005 08:40:30 -0500
- CC: www-math@w3.org
Roger I Martin PhD wrote: > > JB Collins wrote: > >> It seems to me that what you are offering supports >> translation into available numerical library calls. >> The problem I am facing is that physicists often "roll >> their own" numerical methods - and for good reason. >> General purpose methods, say for example a Runge-Kutta >> integrator, works well for general use. When high >> performance is required, however, an integrator >> specific to the equation of interest will generally >> work more efficiently. >> > Going to an integrator of the specific equation is where I'm going. > Not an available numerical library call. Differentiation is easier > example but I'm applying the rules of integration whenever possible to > avoid numerical integrators. That is the difference. The simple > example again. The integral of ln(x) from 1 to 2. The system does > not go to Romberg > http://mathworld.wolfram.com/RombergIntegration.html, discretise the > function but returns a compiled class with the answer ln(2). The > specialized integrator can be written by the physicist in mathml and > run. If I use http://mathworld.wolfram.com/Runge-KuttaMethod.html > then I write it in mathml with the equation of interest embedded in > it. What I'm thinking about is giving the physicists the ability to > often "roll their own" numerical methods without writing a line of > code or calling a numerical library. That would be the integral of 1/x > >> This latter case happens all of >> the time. Don't get me wrong: physicists use the >> general purpose libraries all of the time, also. But >> support for documenting the translation of >> mathematical descriptions to discrete representations >> is required for both cases. > Documentation? That's what the mathml doc combined with other namespaces does. The date of the compiled class would be more current unless a change was made in the xml doc holding the mathml and all related info. Even graphics can be added to the same xml document. Another problem I have seen repeatedly is that notes and comment documents in hand coded source code is incredibly unreliable; often out of date. Code documented by programmers has problems for several reasons beside it being the wrong person. Some programmers start with documentation while others get a round-to-it after projects are no longer hot. This causes variable effects like a method completely documented with no implementation at all or something implemented but named so poorly that no one knows what it does without considerable experimentation. When the starting point is markup in the abstract level of mathematics, changes and fixes are visible and current with the personnel who care the most, physicists and scientists or the project's champion. >> >> Regards, >> Joe Collins >> Naval Research Lab >> >> --- Roger I Martin PhD <hypernexdev@hypernexinc.com> >> wrote: >> >> >> >> >> >> >> >> __________________________________ Do you Yahoo!? Take Yahoo! Mail >> with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo >> >> > > > >
Received on Thursday, 10 February 2005 13:38:28 UTC