[om] Specfun CD's (was: library)

[Bruce Miller]

J H Davenport wrote:
> > Are there other issues?
> Yes, I think there, as regards the name of the symbol (assuming that, in
> general, one doesn't beileve that
> <OMS name="E" cd="specfun"/> is acceptable): 

Well, then we'd need at most 26 symbols in the CD.

> BesselJ is slightly easier for the algebra system whose name we have
> chosen to use; 

IFF the Lucky CAS implemented ALL fcns in specfun, with exactly the 
same properties (branch cuts, and whatever else), then it could save 
the trouble of mapping the names in input.  But to output, it still 
needs to know which of it's own symbols are in the specfun CD.
... not much of a win, really.

> ... J is easier for (any) rendered.

Hmm, this is possibly a valid point: to simplify writing a 
(very) low-quality renderer directly from OpenMath (rather 
than via, say XSLT to Presentation MathML).

However, knowing nothing more than the string "J" and 2 args,
not only will it have to resort to math-italic (correct in this
case, but others functions call for roman, bold, sans-serif, ...),
it will produce, at best:  
    $J(\nu,z)$
I'm not sure how much it is worth -- personally, for such output,
I'd probably still prefer 
  $\mathrm{BesselJ}(\nu,z)$ !

Also, we'll end up with perhaps more mini-CD's than would be
obvious at first glance.  There's the LegendreFunction P
to be distinguished from a LegendrePolynomial P.
I recently became aware of the `Ferrer functions' P & Q,
related to the Legendre functions P & Q -- they are typically 
written in a sans-serif, and defined on part of the real line.

An OrthogonalPolynomial CD would need to broken up to
distinguish the LegendrePolynomial P from the 
JacobiPolynomial P.  Not to mention the various `shifted'
forms which generally get a * superscript.
And, then there's the complete vs incomplete elliptic integrals
of the second kind: both "E".  There may be a few more
such cases where the `obvious' sub-CD would have to be
broken up into smaller units.

So, I'm not sure if it's a win, and if it is, whether it's 
worth the trouble.

> > If the latter, can you point to examples of how
> > currying is explicitly handled?
>
> Possibly the best is in the current draft of logic3.ocd (currently with
> Olga Caprotti for looking at, but I have placed a copy at
> http://staff.bath.ac.uk/masjhd/cd/logic3.ocd
> with David's HTML version at
> http://www.bath.ac.uk/~masjhd/cdfiles/html/extra/logic3.html)

I looked around there, but I couldn't recognize which part
of it dealt with the currying issue (the links to sts were broken).
Presumably defining, say, BesselJ as a function of 2 args (w/ STS)
is the straightforward approach.
What does one do to handle currying?  Define 2 different BesselJ's ?

   BesselJ   maps C^2 -> C
   BesselJnu maps C   -> a function mapping C->C
Or can one  associate 2 distinct STS signatures with a single fcn?

Incidentally, with optional arguments (such as in, say, Lisp :>,
or even LaTeX, for that matter), one can trivially define the
Legendre function P_{\nu} = P^{0}_{\nu} by the same function as
P^{\mu}_{\nu}.  Is this sensible in STS or should we require
the explicit argument 0? (or define 2 functions?)


> It is. There are some comments in our paper in AISC 2000:
> http://www.apmaths.uwo.ca/~djeffrey/offprints.html
> and more in a follow-up article in press - should I post a copy? In
> particular, thanks to David Jeffrey, we destroy the "it's a Riemann
> surface" point of view as a computational tool.

I would be very interested.

----------------
Bruce Miller
<bruce.miller at nist.gov>  http://math.nist.gov/~BMiller/
--
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems