Hello Bryce,
Le 16-déc.-08 à 03:12, Bryce L Nordgren a écrit :
I posted to OM3 mostly because it seemed that MathML3 was tooling up
to directly reference OM3 content dictionaries. Also, I may have
missed something, but from what I can tell, the only way to define
new symbols for use with either MathML or OM is to define it within
an OM content dictionary.
OM3 is a fine discussion for that, it is indeed slightly more followed
by the W3C-math-wG but much less from OpenMath veterans. I'll allow
myself to cross-post even though it's not really elegant.
Asking here seemed the appropriate place, especially if discussion
risked articulating a new requirement of the system.
This is true indeed.
A new requirement of the "standard" and not "system", right?
The below mail seems indeed to express a wish to specify symbols with
a single way to interprete them. I feel it is a bad practice but
still, it can be achieved today, with zero DEFMP or extra
implementation element: your symbol declaration should contain a
single FMP, that specifying the implementation.
The only freedom you leave to receivers of such a symbol declaration
is to take the freedom to consider an own interpretation of that
symbol to be equivalent to that symbol satisfying the prescribed
function equality.
Do you want to even avoid that freedom?
I really don't see a reason and it shows a global mistrust to
mathematics.
As far as I know, a system "implements FMPs" by just having their
developers "knowing" that their implementations satisfy the FMP in a
theoretical way. That knowledge may be wrong but that would be a bug
of them.
(please note: there's more than evaluating to a "implementing" a
function, inverting or solving equations with it are examples of it).
paul
My concern with the <FMP> element is that is a tool used to describe
the properties of a black box, where the symbol is any object
satisfying all of the <FMP>s. As I understand it, additional <FMP>s
are not equivilent to "alternative implementations"; in my
understanding, they are additional constraints on the symbol, and
ALL constraints must be jointly satisfied. I want to directly
define what the black box contains, without necessarily describing
any of its properties.
For instance, I want a function called Planck_bb_freq(nu, T), to
compute an object's blackbody radiance at the given frequency and
temp. Given SI units, there is only one correct implementing
expression. I don't want to describe the properties of this
function (peak described by the frequency form of the Wien
displacement law, falls off exponentially at higher freqs and
polynomially at lower; integral over all wavelengths is the Stephan-
Boltzmann law). I have the one and only defining equation of the
symbol, so I want to associate it with the name. What's more, I
want to ensure that whenever I reference the symbol in a context
where it is evaluated, it always computes the expression I've
specified (example OMA given at end of email). I want to
explicitly forbid any mathematical system from taking liberties with
the expression, inferring anything extra, or fiddling with the
units. :)
The processing system is allowed to supply implementations for
times, divide, minus, power, exp, speed_of_light, Planck_constant,
and Boltzmann_constant (unless I get paranoid about these last three
and just type in values in the correct unit system). It may
precompute constant terms if it desires or perform any other
computational optimization which does not affect the result.
How does one express this sentiment in a content dictionary? And if
there is no means of doing it, could such a facility possibly be
added to OM3?
Thanks,
Bryce
<om2:OMA>
<om2:OMS name="times" cd="arith1"/>
<!-- First term (2 h nu^3)/(c^2) -->
<om2:OMA>
<om2:OMS name="divide" cd="arith1"/>
<!-- 2 h nu^3 -->
<om2:OMA>
<om2:OMS name="times" cd="arith1"/>
<om2:OMI>2</om2:OMI>
<om2:OMS name="Planck_constant"
cd="physical_consts1"/>
<!-- nu cubed -->
<om2:OMA>
<om2:OMS name="power" cd="arith1"/>
<om2:OMV name="ʋ"/>
<om2:OMF dec="3"/>
</om2:OMA>
</om2:OMA>
<!-- c^2 -->
<om2:OMA>
<om2:OMS name="power" cd="arith1"/>
<om2:OMS name="speed_of_light" cd="physical_consts1"/>
<om2:OMI>2</om2:OMI>
</om2:OMA>
</om2:OMA>
<!-- Second Term: 1 / (e^((h nu)/(k T)) -1 )-->
<om2:OMA>
<om2:OMS name="divide" cd="arith1"/>
<om2:OMF dec="1"/>
<!-- e^((h nu)/(k T)) -1 -->
<om2:OMA>
<om2:OMS name="minus" cd="arith1"/>
<!-- e^((h nu)/(k T)) -->
<om2:OMA>
<om2:OMS name="exp" cd="transc1"/>
<om2:OMA>
<om2:OMS name="divide" cd="arith1"/>
<!-- h nu -->
<om2:OMA>
<om2:OMS name="times" cd="arith1"/>
<om2:OMS name="Planck_constant"
cd="physical_consts1"/>
<om2:OMV name="ʋ"/>
</om2:OMA>
<!-- k T -->
<om2:OMA>
<om2:OMS name="times" cd="arith1"/>
<om2:OMS name="Boltzmann_constant"
cd="physical_consts1"/>
<om2:OMV name="T"/>
</om2:OMA>
</om2:OMA>
</om2:OMA>
<om2:OMF dec="1"/>
</om2:OMA>
</om2:OMA>
</om2:OMA>
_______________________________________________
Om mailing list
[email protected]
http://openmath.org/mailman/listinfo/om
