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

[J H Davenport]

On Fri, 10 Aug 2001, Richard Fateman wrote:
> 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 still think that link is wrong. I just tried it again.
>  I think you mean
> http://icm.mcs.kent.edu/research/iamc01proceedings.html
True - the proceedings link is a link from the site I cited., which is the
link Paul told us to use - oh well.

> 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.
This could be done, but I fear that the 'modest map' does not scale in
practice. Special functions are close to unbounded in their complexity,
and choices of notation, it seems to me.

> 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.
No -it's not my view of CDs, it's my view of naming conventions.
>
> 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.
It would have been, had XML not existed. I (personally as opposed to any
OpenMath grouping) fail to see why Lisp is commercially "bad", while a
language far more verbose which is still about trees is "good". However,
XML seems de facto to have the Web world by storm. Let me just emphasise
that the XML encoding of OpenMath is only one option.

>   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.
There are XSL readers and parsers for OpenMath CDs - David Carlisle is the
expert.
>
> (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
To what extent do you view the CDs at
http://www.nag.co.uk/projects/OpenMath/omsoc/cdfiles/html/core/
as not being human-readable.
> (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. )
It would be possible to build such, though quite what sense it wold make
to have a mathematics 'representation' of a CD I don;t know. Maybe you
could enlighten us.


> 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.
personally, I don't see a distinction, but that's life.
>
> 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.
I'm glad you think that - I hpe that is the notation people are converging
towards.
>
>
> 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.
Absolutely. I have argued with MathML folks that we need &InvisiblePlus;,
as in (\LaTeX notation) $4\frac12$ meaning $4+\frac12$.

> As far as branch cuts go, the view (maybe expressed by Bruce's
See a later response.
James

--
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