New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Julep: allow passing an operator to var
#29
Comments
That's a really cool idea! My only concern is with the proposed API, since for similar functions like |
I totally agree. It's a bit like |
BTW, is the operation |
As I'm thinking about it, |
I am concerned of the semantically ambiguous definitions, not the absence of the definition. This is different from the discussion of OP, but I hope Statistics provides an API for the square error function with "two" arguments for package developers. |
To be honest, I'm quite surprised that Being able to use various definitions of
This is an interesting observation. A more basic but very related problem is how (Err... though looking into the code for Anyway, I guess color spaces are generally curved spaces with a nontrivial metric? In that case it appears a variance can be defined consistently without computing the mean or any differences, for example: https://golem.ph.utexas.edu/category/2017/02/variance_in_a_metric_space.html Exactly the same observations could be made for geographic coordinate systems, and the same tradeoffs that face the design of I think this points in an interesting but frustratingly complex direction:
|
I should point out that regardless of being "cool" I know for a fact that being able to get the outer product version is also useful for |
Now I see your concern, @kimikage. Yes, if you have a metric, then more generally Looks like the covariance can be defined similarly: https://arxiv.org/pdf/1106.5758.pdf
I'm probably misunderstanding, but vector spaces admit multiplication by a scalar.
Agreed, but I think it's clearly the right roadmap. Wrt API, one option would be to allow keyword arguments A agree with @c42f that ideally we might want a trait to pick these defaults automatically. However, in cases where the normal definitions don't apply, perhaps (as in the case of wanting to support multiple notions of product) it might be better to have people specify the operations directly. We could even support the case |
I don't want to write many keyword arguments:sweat_smile:, so I think the level of abstraction as follows is fine: var((x, μ)->(x - μ)^2, [1, 2, 3]) |
Nice. This emphasizes that we hardly need μ = mean(iter)
v = mean(x->(x-μ)^2, iter) other than for the |
You're right. However, the element-wise function with two arguments is simple when considering the |
Sure, but this is literally computed as (I can guess that this might have been to preserve correct rounding and solve some promotion issues, but a lazy inverse type would have done the same.) |
Thinking further about that, I guess scalar division isn't ambiguous in the same way that scalar addition is, so maybe it's fine... I'll stop thinking about that for now :-D |
This is a bit of a cross-post from JuliaGraphics/ColorVectorSpace.jl#126, but let me provide a more succinct summary specialized to this package. Consider the following demo:
There's a sense in which the error is the correct outcome, and the one that returns a vector is a bit of a misnomer; after all, the definition of
var
asE[(X-μ)^2]
requires that one can computey^2
for objects drawn fromX
, but*
does not mean elementwise multiplication.Over in ColorVectorSpace we've hit upon the following idea: defining
⋅
(\cdot
) as the "dot product",⊙
operating elementwise (like broadcasting-*
but we can't pass that as a function argument and therefore need a different operator), and⊗
(\otimes
) to mean the outer product. In that circumstance,var(⋅, a)
becomes the mean-square-error,var(⊙, a)
becomes the elementwise variance, andvar(⊗, a)
is the covariance.I'd be interested in your thoughts. I also think it makes sense for ColorVectorSpace and maybe StaticArrays (CC @c42f) to synchronize, if possible.
The text was updated successfully, but these errors were encountered: