#4102: make bessel_J symbolic
----------------------------------+-----------------------------------------
Reporter: jwmerrill | Owner: burcin
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-5.7
Component: calculus | Resolution:
Keywords: | Work issues: doctest fixes, various
minor documentation and other issues
Report Upstream: N/A | Reviewers: Karl-Dieter Crisman
Authors: Benjamin Jones | Merged in:
Dependencies: | Stopgaps:
----------------------------------+-----------------------------------------
Changes (by benjaminfjones):
* cc: burcin (added)
Comment:
Replying to [comment:22 kcrisman]:
Thanks for looking over the patch!
> Dumb comments since I don't have time for proper review - and more
importantly, there are no obvious horrible things (though I haven't gone
in depth with branches yet). If all this really works and there are no
typos, I think this will be a VERY nice addition.
> * `unqiue` typo
> * `Verfify` typo
> * `increasin` typo
> * I don't know why, but the math following "It follows from
Bessel's..." doesn't look right in the doc (the `:math:` directive is not
parsed)
Fixed, it was a one space indentation problem.
> * Is \operatorname{bessel\_I}(\alpha, x) standard or should we just
just the I sub whatever?
I was unsure about this. I think now it makes most sense to just stick
with I_\alpha when in a math block.
> * {{{`test_relation()`}}} needs to be in double back ticks or have a
link to the appropriate place in the ref manual
> * Trac tickets should use `:trac:` syntax
> * Does `f(x) = Bessel(0): plot(f, (x, 1, 10))` work, or must one use
`Bessel(0)(x)`? The example after that makes it look like maybe not...
The way the code works you have to specify the variable on the right hand
side, e.g.:
{{{
sage: f(x) = Bessel(0)(x)
sage: f(x) = bessel_I(0, x)
}}}
This is because `Bessel()` returns lambda functions under the hood.
Personally, I prefer having the variable dependence made explicit, but I'm
open to suggestions if there are other
ways you can think of to get that functionality.
> * Bessel Y and Bessel K need a little filling out - and one of the
`:math:` directives doesn't show up at all, the other isn't parsed right
for some reason again
I'll work on Bessel Y and K, I realize now that you mention it that I
didn't fill in the definitions there :). Anyone with good doctest
suggestions for these is welcome to chime in, I'll add the tests if you
can think of interesting or relevant ones.
> * I'd personally get rid of the whitespace changes in
sage/functions/special.py - unlikely to have an effect, but not really
necessary.
Yep, you're right.
> * How should we deal with the removal of the `"maxima"` and `"pari"`
arguments? I'm not sure if it's really feasible to have a deprecation
period for that, but we should discuss it.
This is a question that's been troubling me. I don't know how to make the
deprecation happen and make progress here without renaming the new
functions and then swapping them in when the deprecation period is over.
The infrastructure we have for adding symbolic functions (inheriting from
`BuiltinFunction`, etc) doesn't support any kind of system arguments
without overriding `call()`.
At least existing code that uses the Bessel functions as they are now in
Sage won't break unless they explicitly use the system argument.
Maybe @burcin has a suggestion here?
> * I suppose we don't need to keep ''all'' old tests, but some of them
are rather different and might be worth putting in a TESTS section
somewhere, just so that we don't have some unexpected regression only they
catch.
Good point, I'll see what I can salvage.
> * The switch to alpha from nu - I would rather not deprecate this
either, but in principle someone could have used it as a keyword argument
in the past...
It doesn't make a difference to me, I used alpha because that's what's on
the wikipedia page :) Abramowitz & Stegun uses n or \nu and so does the
mpmath documentation. I can easily switch \alpha to \nu with some editor-
fu.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/4102#comment:25>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
