[Om] [Om3] Math in office documents/Providing an implementation for a symbol

[Paul Libbrecht]

Le 16-déc.-08 à 11:10, Professor James Davenport a écrit :
>> 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.
> Correct.

That gives freedom, true, and it's a good thing!

>> I want to directly define what the black box contains, without
>> necessarily describing any of its properties.
> But, if you are defining what it contains, aren't you therefore ALSO
> defining its properties?

erm... an FMP of the style:
  function(x) = {do-bla-bla-in-a-concrete-way}
is a valid FMP, quite a constraining one, but a valid one which does  
specify the value everywhere this equality holds!

The only bit you are missing compared to an implementation spec is the  
contraint that says that not only this property holds but that this is  
the way it's implemented! That's a useless constraint to my taste.

(and a good machine should be able to know, by theorems, that this FMP  
is valid even though it uses it's own,
I wonder how NAG library or Maple could solve this challenge, for  
example, a nice one)

>> 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.&nbsp; Given SI units, there is only one  
>> correct
>> implementing expression.

I don't agree there's a single one even though there is probably only  
one found on earth a of today.

paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2203 bytes
Desc: not available
Url : http://openmath.org/pipermail/om/attachments/20081216/e06d66f2/attachment.bin