[om] Specfun CD's answers to all the questions.

[Richard Fateman]

J H Davenport wrote:
> 
> On Thu, 9 Aug 2001, Richard Fateman wrote:
> > J H Davenport wrote:
> > > http://icm.mcs.kent.edu/research/iamc.html#iamcworkshop,
> > I see no paper by you at that site.  I searched for
> > james, davenport, cd, special.  No hits.
> Odd, that page includes
> OpenMath Content Dictionaries: the Current State
>        James H. Davenport (jhd at maths.bath.ac.uk)
>        paper in PDF
>        download gzip-ed postscript

I still think that link is wrong. I just tried it again.

 I think you mean

http://icm.mcs.kent.edu/research/iamc01proceedings.html


> The PDF version is at:
> http://icm.mcs.kent.edu/research/iamc2001.papers/davenport.pdf
> http://staff.bath.ac.uk/masjhd/CDState3.pdf
> 
> > If there are questions, let's hear them!
> The two design questions are exemplified in the two fragments at the top
> of page 21.

OK. Should there be a small CD for J or a large CD which
includes BesselJ.
  Easy solution. Write a program that takes many small ones
and packages it into a big one.  Then you don't have to write
the big one. You need a modest map: BesselJ <-> J.

  Or alternatively, write a program that splits a big one
into individual CDS. Then you don't have to write the little ones.

If your view of CDs and transformations on them is insufficient
to allow both of these transformations to be easily programmed, then
you have a bigger problem.

You need to be thinking of these CDs as data. That's why writing
them in Lisp seemed to be such a good idea to me.

If on the other hand they are written in XML, then what I would do
is take one of the XML-to-lisp readers, read in your CD(s), and
take one of the Lisp-to-XML writers and write out the transformed
CD(s).  I suppose you could replace "Lisp" with "Mathematica" or "Maple"
or "Perl".  But there is an ANSI Common Lisp.

  If your CD format is neither XML (it does not appear to
be Lisp), and there is no parser for it, then I would suggest remedying that.

(Another remedy which seems to be part of what is going on is to
have a human readable part.  Why not encode everything as human
readable and also readable by (say) a Mathematica program
(or equivalently since I have a Lisp program that reads Mathematica) a
 lisp program.  Then when someone
needs a CD in XML, run a translation program.  That way no human will
ever have to see ANY CD. )



Problem 2.
  I think you are not really talking about Currying, but about names and
functions as first-class objects.  Here is what I think Currying is
about.
  If a function F is defined as F(x,y,z) := x+y+z
Then F(3) is immediately defined as lambda(y,z).3+y+z.
It is a way of dealing with missing arguments.

To continue with Bessel Functions, it is clear to me that
you need to be able to talk about J  (Bessel function of the first kind),
J_3,    a function of one argument
  and
J_3(2),  a real number.

to use lambda(z).J_nu(z) instead of J_nu seems quite strange.  Wouldn't
a lambda-calculus fan actually simplify what you've written to J_nu?
(beta reduction perhaps?)

So talking about J_nu and even J is clearly the right thing to do.


By the way, any time you (or I) write F(x), I get kind of uncomfortable,
realizing that mathematicians use that exact same notation to denote
quite other things.  Like the Field of rational functions over the
indeterminate x with coefficients in F.
So the importance of attaching a meaning to that symbol J,  and not
just J_nu(z) is carried over to the issue of mathematicians being
so totally undisciplined with regard to ambiguity. In case you
have not thought about it much  (and many mathematicians somehow
hold the view that their language is perfectly clear until it
is challenged...)
the overuse of adjacency for some operation is probably the worst
offender.

As far as branch cuts go, the view (maybe expressed by Bruce's
friends) that you put them where you want them, and you move
them if you need to, is clearly the appropriate answer for someone
who is taking a course in complex variables. That is what
I was taught, and it is probably still taught that way.
Finding contour integrals means you move the cuts, and you probably
have no way to describe the cuts in Openmath, anyway. For
example, the cut might be a straight line from 0 to real infinity
with an infinitesimal semi-circle cut out around each integer.
Compose that function with some others and you have a mess.
You also haven't even touched the obvious generalization of
complex functions of several complex variables.  Where is the
branch cut for f(z,w):=log(sqrt(z+w)) ?

Is it appropriate for OM to leave out branch cuts? Sure. Because
it would be presumptuous in the extreme to claim that you
have decided what they are, and I don't see that you have to solve it.
It is a problem that need solving if you are asked for a numerical
value of a function on the (default) branch cut you've previously
picked.  But I didn't think OM was doing arithmetic.  If it were,
you could take as a guide, the writing of W. Kahan; this happens
to have been followed by ANSI Common Lisp, but that covers
mostly elementary trig/log/ type stuff in the complex plane.
Beyond that I think Bruce can try to push his people for default
branch cuts in a publication coming from NIST.  If OM wants to
incorporate that by reference, that would be fine. 

Any more questions?

Regards,
 Richard
--
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