[Numpy-discussion] automatic differentiation with PyAutoDiff
Travis Oliphant
travis at continuum.io
Thu Jun 14 17:42:28 EDT 2012
On Jun 14, 2012, at 1:53 PM, James Bergstra wrote:
> On Thu, Jun 14, 2012 at 11:01 AM, Nathaniel Smith <njs at pobox.com> wrote:
>
>>> Indeed that would be great as sympy already has already excellent math
>>> expression rendering.
>>>
>>> An alternative would be to output mathml or something similar that
>>> could be understood by the mathjax rendering module of the IPython
>>> notebook.
>>
>> I'd find it quite useful if it could spit out the derivative as Python
>> code that I could check and integrate into my source. I often have a
>> particular function that I need to optimize in many different
>> situations, but would rather not pull in a whole (complex and perhaps
>> fragile) bytecode introspection library just to repeatedly recompute
>> the same function on every run...
>>
>> -N
>
> I was hoping to get by with bytecode-> bytecode interface, are there
> bytecode -> source tools that could help here?
>
There have been some attempts in the past. The most advanced tool I've seen here is by Sean Ross-Ross: https://github.com/srossross/meta
Here's an example:
import meta
# get some code object (i.e. from compile or from func.func_code --- with no return statement)
mod2 = meta.decompile(code)
meta.dump_python_source(mod2)
-Travis
> Otherwise it might be possible to appeal to the symbolic intermediate
> representation to produce more legible source.
>
> With regards to "pulling in a whole bytecode introspection library" I
> don't really see what you mean. If the issue is that you want some way
> to verify that the output function is actually computing the right
> thing, then I hear you - that's an issue. If the issue that autodiff
> itself is slow, then I'd like to hear more about the application,
> because in minimization you usually have to call the function many
> times (hundreds) so the autodiff overhead should be relatively small
> (I'm not counting Theano's function compilation time here, which still
> can be significant... but that's a separate concern.)
>
> - James
> --
> http://www-etud.iro.umontreal.ca/~bergstrj
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120614/f871ccc1/attachment.html>
More information about the NumPy-Discussion
mailing list