-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
bc1ced6
commit 1257643
Showing
3 changed files
with
81 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this will fly.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, this doesn't seem nearly generic enough. We definitely need to do something but I don't think this is it.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't aware that others were watching. I am just playing with it. The motivation was the work on the generic linear algebra, but also the promotion rules for multiplication that have been discussed today. Solving linear systems with LU is stable under division, with QR it is stable under normalisation with 2-norm and for multiplication it is
T*S+T*S
stability and therefore I wanted to try to define promotion with respect to some arithmetic operation. Does it make sense?1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a very cogent summary of the type stability mess. Ugh.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are 2 big issues:
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jeff and Stefan gets a email any time someone pushes to julia.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found that some machinery that can tell you the result type of a math operation is very useful. I actually ended up writing some similar stuff in developing a package: https://github.com/lindahua/Accelereval.jl/blob/master/src/maptype.jl
This file answers the questions like: given two arrays with element type
T1
andT2
, what is the element type of the result array. Also note that the type behaviors are different for scalar computation and vectorized computation.I have always been looking forward to Julia providing something with which we may get the result type of an operation. However, I hope that it is something more generic than this.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JeffBezanson Regarding 1, I'd expect that it was covered since e.g.
(+)(Bool,Bool)=Int
, but maybe I'm not getting the point. My imagination and judgement is limited by my lack of knowledge about deeper levels of the type inference. My thought was that basically my "type arithmetic" (or should I call it tag arithmetic) does the same aspromote_rule
but without implicitly assuming the operation. Regarding 2, I was thinking about the handling of number element types only. Just curious, have you ever considered to parametrise arrays by their size?@lindahua I can see that you have had pretty much the same idea. To me it appears pretty generic that you can compute with the types, but I'm aware that I don't really understand the scope of this.
@ivarne Good to know. I expected this for the master branch and pull requests but not the other branches. I only pushed to JuliaLang to avoid compiling and running tests on my old laptop on which I was watching Barca-City.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can set up travis testing in your forked repo also. It is just a few clicks away, if you login with github and go to https://travis-ci.org/profile.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JeffBezanson I have been thinking a little more about this. I can use #6118 as case to follow up on your second item. The main reasons why it is a problem that arrays don't have their size as parameters is the use of
zero
andone
to determine the correct returneltype
. That was the reason for #4796 because the promotion rule used to betypeof(one(T)*one(S)+one(T)*one(S))
. You fixed the issue by avoidingone
and instead defining a new promotion functionarithtype
to deal with bools. My idea is to have+(Type,Type)
and*(Type,Type)
instead of havingpromote_type(Type,Type)
andarithtype(Type)
. If the returneltype
ingeneric_matvecmul
was determined byT*S+T*S
it would solve #6118 as well #4796. There might be a smarter solution, but at least I don't think that the array size is problem for type arithmetic.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this is surely the direction we need to move in. SIUnits is a great example:
1Meter*1Meter
is a completely different type from1Meter/1Meter
and from1Meter+1Meter
, so there's no way we'll be able to use a single type for all arithmetic operations.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until Julia provides/exposes the machinery to obtain the result type of a function, I agree that
fun(Type)
andfun(Type, Type)
etc are the best way I can see.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's a good way to do it, because there is duplication. There's no guarantee that
Type+Type
will tell you the correct type ofx+y
for actual values. It would be better to have a non-evaluating typeof, and use@typeof(a[1]+b[1])
, which would not actually access the arrays.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you provide an example of
Type+Type
giving the wrong type? I don't question your statement, but I cannot come up with one.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just that in the above scheme, you have to define both
+(::Type{A}, ::Type{B})
and+(::A, ::B)
, which makes it possible for them to be different. It should be designed so that this is not even possible.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great if a macro such as
@typeof
is provided. However, it is unclear to me how such a macro can be implemented, as in the macro expansion stage, the type information of the involved variables has not been available.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lindahua see Jeff's comment in: #6114 (comment).
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, then I am looking forward to this
@typeof
macro.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I see the problem. I still like the idea of using the types instead of the instances so maybe the definition of
+(x::Float64,y::Float64)=box(...)
could also make the definition+(::Type{Float64},Type{Float64})=@typeof(box(...))
. An example of the problem with the instance approach could behere
A*b
would construct anArray{Int,1}
for the result if the type was determined fromA[1]
andb[1]
.1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1257643
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was meant as a device to access the return type information from the normal definition without instances. It also seemed to me as a natural continuation of definitions like
promote_type(arithtype(T),arithtype(S))
.What I would like is some way to determine the return type of array computations. The solutions right now are not sufficient as far as I can see.
promote_type
generally doesn't give the right type, constructing instances fromone(Type)
doesn't work for arrays and even for numbers they might not be correct because of the ambiguity ofone(Real)
and usinga[1]
is also problematic as the example in the last comments showed, and it also doesn't work for empty arrays.