Re: Semantic information for math representations of physics

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