Make type of cell size subtype of AbstractFloat #9
Conversation
|
Looks good. Not sure what's happening with failing on 0.6 and not liking list comprehensions. |
|
The error in question is:
Oh dear. This is interesting. The definition of "pure" is that a function has no side effects: it takes an input and returns an output and doesn't modify anything. Like a mathematical function. In Julia we have the interesting situation that compiling things may have external consequences, such as creating new types. A closure is a kind of function-within-a-function that, as an internal Julia compiler implementation detail, creates a new Julia type that contains the captured variables. Thus, the side-effect is that calling the function generator creates a new type that in theory is visible after the compilation is complete (in practice seeing this is almost impossible for end users, but to the compiler guys it is important that things aren't changing underneath them during certain stages of compilation). Also note that this is exactly the same as issue JuliaLang/julia#16806 (A comprehension also does something funky at the compiler level - they are specially blessed things and probably do something like the closure does for performance reasons). All this is to say that this is a problem that will probably never go away - we should plan to change the relevant code at some point. Probably isn't too hard. |
|
Uh, what? I don't understand this PR. Aren't the following exactly equivalent: foo(x::AbstractFloat) = x
bar{T<:AbstractFloat}(x::T) = xI mean, with those definitions we have julia> foo(1.0)
1.0
julia> bar(1.0)
1.0
julia> foo(big(1.0))
1.000000000000000000000000000000000000000000000000000000000000000000000000000000
julia> bar(big(1.0))
1.000000000000000000000000000000000000000000000000000000000000000000000000000000 |
|
Closing this. |
Type of dx is too restrictive