Skip to content
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

Type inference for cat #5339

Closed
simonster opened this issue Jan 9, 2014 · 6 comments
Closed

Type inference for cat #5339

simonster opened this issue Jan 9, 2014 · 6 comments
Labels
arrays [a, r, r, a, y, s] compiler:inference Type inference

Comments

@simonster
Copy link
Member

The return type of cat is determined by the value of the dim argument as well as the types of the inputs, which means we can't infer the dimensionality of the returned array. OTOH dim is usually constant, so we usually have all of the information necessary to determine the return type at compile time, just not in a way that type inference can use. What is the best approach here?

@pao
Copy link
Member

pao commented Jan 9, 2014

Could use a macro, same as we do for @printf?

@simonster
Copy link
Member Author

A macro is an interesting idea, but I'm not sure how we'd implement it. The dimensionality is max(dim, map(ndims, args)...), but we don't know the dimensionality of the arguments before type inference, so we can't just add a typeassert.

@mbauman
Copy link
Member

mbauman commented Jan 9, 2014

You could do the same sort of pseudo-typing that NumericExtensions does with its functors, couldn't you? E.g., @cat(n,X...) would emit a call to cat{n}(DimT{n}(),X...), where DimT is an empty type whose sole purpose is to carry around an integer as parameterized type information. Would that be sufficient for getting the type inference up and running?

@simonster
Copy link
Member Author

Even if you encapsulate dim in a type, you still need to do the max operation across dim and the number of dims in the input arrays, which is not so simple to code in a way that type inference can make sense of. One approach is to make tuple of dim length and do what I did in #4741, but I wasn't really comfortable with how ugly that was at the time, and this would be even uglier because we'd be creating a tuple just for the sake of being able to perform the max operation.

@kshyatt kshyatt added arrays [a, r, r, a, y, s] types and dispatch Types, subtyping and method dispatch labels Sep 15, 2016
@JeffBezanson JeffBezanson added compiler:inference Type inference and removed types and dispatch Types, subtyping and method dispatch labels Apr 4, 2018
@rikhuijzer
Copy link
Contributor

Related PR at #45028.

@aviatesk
Copy link
Member

Fixed by #45028, thanks for mentioning this issue on the PR, @rikhuijzer !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrays [a, r, r, a, y, s] compiler:inference Type inference
Projects
None yet
Development

No branches or pull requests

7 participants