Resolving MethodErrors #12
Comments
|
Let me explain these issues and how to fix them.
As you correctly assumed, XGrad (or, more specifically, Espresso) can't parse doesn't help since you still modify The easiest way to fix it is to use new names for variables, e.g. something like: I thought about automatic renaming so that you don't have to do it manually, but implications are unclear at the moment. For the same reason there's still no first-class support for loops in Espresso - without mutating variables loops are nearly useless (I think we will add support for them anyway, but design depends on use cases, and I haven't found a good one yet). Your example may be rewritten (automatically, so that the user doesn't have to worry about it) into something like: I'm also worried about distribution types like If I propose to go in 2 steps:
Does it sound reasonable to you? |
|
Thanks, yes this sounds manageable. One of the big benefits of source transformation is having so much flexibility in what I pass to the next stage. I know Julia does some kind of SSA transform -- I think it might be required by LLVM -- but maybe this isn't available to the user. But it should be easy enough to implement. And I can rewrite to |
Yes and yes. I'll take a look at automatic renaming over the weekend.
Ah, I didn't realize it was a self-containing example. Let me first explain why this happens because you may encounter other errors like this. As I've mentioned somewhere else, It's easy to fix it by defining a differentiation rule for where and voilà! This may look like a set of hacks and monkey patching, but normally (e.g. in machine learning) the workflow is a bit different: you define a set of primitives like Here's how I derived code for Then I ran and got expression: Finally, we replace the first term ( If this is still black magic for you, but you need some more rules, don't hesitate to simply ping me :) |
Oh, I meant for me to rewrite it that way. But it would be better if this can go into XGrad directly - should make it more broadly usable anyway. Thanks! A couple of other questions. You write normlogpdf(z::Number) = -(abs2(z) + 1.8378770664093454836)/2instead of using Also, for this bit: @diffrule normlogpdf(μ, σ, x) μ ∇normlogpdf(ds, μ, σ, x)[2]
@diffrule normlogpdf(μ, σ, x) σ ∇normlogpdf(ds, μ, σ, x)[3]
@diffrule normlogpdf(μ, σ, x) x ∇normlogpdf(ds, μ, σ, x)[4]Does this mean the code for Thanks for all your help with this :) |
I hoped to fix it before you would notice :) It's a bug. I fixed it in the past, but it snuck back. I added and issue for it.
In this specific case - yes, but you shouldn't worry about it right now. I simplify things a bit for now to make cognitive load smaller and snippets more understandable, but in general it's very easy to make XGrad optimize your code (at least eliminate common subexpressions).
It's the default behavior, e.g. in the generated code above you can see: tmp687 is a (generated) name of resulting variable and 3 other elements are derivatives of that result w.r.t. each of input parameters. |
Fixed it, tested with constant: Checkout master of Espresso and XGrad to try it out. |
|
Great, thank you Andrei!
…On Wed, Jan 3, 2018 at 3:20 PM Andrei Zhabinski ***@***.***> wrote:
I added and issue for it.
Fixed it, tested with constant:
const log2π = 1.8378770664093454836
Checkout master of Espresso and XGrad to try it out.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#12 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABISwRX6Mtd-PangHlS17KF-mzXIKaf9ks5tHAtNgaJpZM4RRRbJ>
.
|
|
Automatic variable renaming is in place. Example: gives: Things like which gives: |
|
Oh that's great! Easy for me to replace them all before calling it. Thanks!
…On Fri, Jan 5, 2018 at 5:07 PM Andrei Zhabinski ***@***.***> wrote:
Automatic variable renaming is in place. Example:
using Espresso
ex = quote
x = 0
x = x + a
x = x * b
y = x * x
end
to_expr(ExGraph(ex))
gives:
quote
x = 0
x2 = x + a
x3 = x2 * b
y = x3 * x3
end
Things like x += 1 aren't supported, though. Maybe I'll rewrite them to x
= x + 1 before parsing, but it's hard to predict all possible use cases,
so I have doubts. However, in your restricted use case you can easily
rewrite them as:
using Espresso
rules = [:(_x += _y) => :(_x = _x + _y),
:(_x *= _y) => :(_x = _x * _y)]
ex = quote
a = 0
a += 1
a *= a
end
rewrite_all(ex, rules)
which gives:
quote
a = 0
a = a + 1
a = a * a
end
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#12 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABISwXIxKeATKhULEeYXmLj7bwsCjuBAks5tHsdWgaJpZM4RRRbJ>
.
|
I'm trying to use
XGradfor Soss, and running into some problems.Starting with something like this:
I get
I'm not sure how to teach it about
+=, so I change to this:That helps a little:
I thought maybe I could use
normlogpdfinstead, but that's not any better:The text was updated successfully, but these errors were encountered: