-
Notifications
You must be signed in to change notification settings - Fork 12
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
Rethink maps #36
Comments
Maps as an interface is definitely the right approach. We would probably still need a special type for affine maps however as I think using composition notion This question goes hand-in-hand with the question of broadcast and domains. That is, can we write I believe there is a package out there that has something like |
Okay, good points! Let's use About affine maps, I was thinking of the following:
where Perhaps it depends on what we define the operation of applying a map to be. If the syntax is On the other hand, if we continue to use As an interface and from the point of view that maps are functions, I'm talking in thin air now, perhaps some exploring is called for. |
My current feelings are:
How does this fit into maps? Something like a rotation is both a function and a matrix, depending on what it's acting on. I guess I'm arguing these should be different types... |
I completely agree here. |
So, this would lead to using the For Domains, each domain is free to implement |
While we are rethinking maps, we may want to rethink The equality of a Currently, there is no specific problem, but the two use-cases are incompatible and it may be good to keep the distinction in mind. |
I think this needs to go hand in hand with broadcasting, and essentially the storing the map means a lazy broadcast. I think we could mirror the relationship between So I guess I’d rename BroadcastDomain(+, BroadcastDomain(exp, im*(0..1)), 2+im) One issue is to support |
Sounds sensible, it is a type of lazy domain. Most importantly, a user who is interested in retaining the map needs a safe way to store the map and the original domain. It is still somewhat fishy to do that in |
I think this remains the largest open issue with The definition of a |
We are converging to
Domain
as an interface: it is any object type that supportseltype
andin
. We make methods with which one can combine domains, where the individual domains don't have to beDomain
types. This is clearly very flexible. Perhaps we can do the same for maps and make the framework more generic/applicable?A map is really just a function:
y = f(x)
. Thus, perhaps any type that supports the calling operator can be seen as a map. Or perhaps any type that supports*
can be a map. We could treat a matrixA
as a map, the map then being the matrix-vector producty = A*x
. Even a number could be a map:2
represents multiplication by2
. As long as*
is associative (which I think Julia already assumes in many cases), the interpretation of*
as applying a map is consistent with composition:(A*B)*x = A*(B*x)
. With this approach, I think we would not even have to implement affine maps. We can just use the existing linear algebra functions and vectors/matrices.Julia functions have a known output type if you give it a (combination of) input type(s). The current definition of
AbstractMap{S,T}
really is like a typed function. It corresponds to a function for which you restrict the input type to beS
. The output typeT
is perhaps superfluous. From this point of view, a better name might beTypedMap{S}
orTypedFunction{S}
. It could have an implementation like:Any concrete subtype would implement multiplication for arguments of type
S
only.In order to generically support maps like
2
,cos
andrand(2,2)
, it is somewhat restrictive to assume that the input type is known. We can in general assume that, given the map and the input type, the output type is known. (Worst case it isAny
.) Thus, we could haveTypedMap{S} <: AbstractMap
whereAbstractMap
has no type parameters at all. What the map does, depends on the type of the input and is expressed by implementing(*)(m::MyMap, x)
.Ideally, eventually, computing Jacobians etcetera is done generically via automatic differentiation. Composition of maps ideally would use fusion (like broadcast), rather than layered
CompositeMap
's orCompositeMap
's with many elements.As with domains, as long as you are manipulating variables of type
AbstractMap
we can use standard function names. If you intend to manipulate any object that implements the map interface, whatever we decide it to be, the intention has to be implicit in the name of the function that is being called (likeconvert_map
andpromote_map
) or the operation has to be consistent with the generic meaning of the function name (as with*
).I'm sure there'll be some problems I'm not seeing at the moment too.
The text was updated successfully, but these errors were encountered: