On Sat, Mar 16, 2013 at 9:02 PM, David Li wrote:
> Okay, I'll start on that once I manage to get the integration algorithm to
> handle most problems that a high-school/freshman college student would
> encounter. (Currently it won't handle any trig integrands involving more
> than a u-substitution,
Okay, I'll start on that once I manage to get the integration algorithm to
handle most problems that a high-school/freshman college student would
encounter. (Currently it won't handle any trig integrands involving more
than a u-substitution, and does not use integration by parts.)
Perhaps the d
This is something SymPy wants. It's even on the GSoC ideas list.
I would put the integration stuff in the integration module. As I
pointed out on the pull request, what you really have here is a new
integration heuristic, which can (should) be "integrated" with
integrate() itself. It is already g
Alright, thank you for pointing out that typo. I've fixed it.
I have finished porting; the code is still at the same place,
https://github.com/sympy/sympy_gamma/pull/8. If this is something SymPy
would want, how best should be integrated? Which module(s) does it belong
in and what should the AP
Hi David,
Great work. Just wanted to point you out one small thing in
http://sympy-gamma-li.appspot.com/input/?i=integrate%28exp%28x%29%20/%20%281%20%2B%20exp%282x%29%29%29
In the first step after "Let u = e^x"; "then let du = e^x ..." But I think
it be some thing like this "then du = e^x dx
That would be a good idea. Looking at the code, everything has an
_eval_derivative method which should work. My only concern is that, for
instance, in Pow it combines the power, chain, and exponential rules into
one expression.
In any case, most of the code I added was related to printing and
form
> I don't know if it's idiomatic, but one suggestion is to derive the
> derivative rules automatically from diff. At the very least use a fallback
> so it works for functions you don't have rules for.
>
I agree that it'd be unfortunate to rewrite all of the differentiation
logic. Maybe there is a
> If this an "idiomatic" use of strategies then I'll convert the rest of
the code.
There is no idiomatic or agreed upon use of strategies. They're new,
experimental, and used almost exclusively by me.
The only good idea I can push with confidence is that you should strive to
separate your functi
I don't know if it's idiomatic, but one suggestion is to derive the
derivative rules automatically from diff. At the very least use a fallback
so it works for functions you don't have rules for.
Aaron Meurer
On Mar 15, 2013, at 10:42 AM, David Li wrote:
Okay, so I'd just like to make sure I'm u
Okay, so I'd just like to make sure I'm using strategies/rules correctly. I
have the gist of the derivative implementation at
https://gist.github.com/lidavidm/5171100.
- The rules convert the function to be differentiated into a namedtuple
corresponding to the derivative rule to be applie
Slightly off topic: I think that many people would be interested to
see a blog post on planet.sympy.org about this development. On one
hand you have done a lot of work on gamma itself, on the other your
work with this integrator shows a nice way to extend sympy without
worrying too much about upstr
The driving idea behind strategies is that you should make lots of little
functions that each do one thing. These should separately be composed
together to make larger functions. This way the little mathematical
transformations can be reused in the future or can be wrapped with the kind
of report
Alright, thank you all for the feedback!
I just started looking at the strategies module, I think I could map my
rules to rules in the strategies module and have intsteps/diffsteps be a
strategy; I'll look into this some more. I can get rid of the format
function easily, I'm not really using it
13 matches
Mail list logo