Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Hi Tero, Thanks for the suggestion. Done: https://github.com/JuliaLang/julia/commit/f17dc963f76bc07623bb6be0605f8406f4cffab2 Best, Charles On 2 January 2016 at 20:51, Tero Frondelius wrote: > Hi > You should update the documentation to be clearer, thus others wouldn't > have to struggle with the same misunderstanding in the future. > -- Um axé! :) -- Charles Novaes de Santana, PhD http://www.imedea.uib-csic.es/~charles
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Hi You should update the documentation to be clearer, thus others wouldn't have to struggle with the same misunderstanding in the future.
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Hi Kristoffer, Thanks for pointing this out! Actually, I had in mind that annotation *had* impact on performance. I read the documentation about performance-tips before and I understood that the exceptions listed in http://docs.julialang.org/en/release-0.4/manual/performance-tips/#type-declarations were the rule. I know it is a matter of my bad English together with my distraction during the reading the docs. It happens quite often with me, especially when the main statement is not in the beginning of the sentence (that is the case of the sentence "In many languages with optional type declarations, adding declarations is the principal way to make code run faster. This is *not* the case in Julia. (...)"). In other words: you just opened my mind for this. Your message was clear :) Thanks! Best, Charles On 1 January 2016 at 21:35, Kristoffer Carlsson wrote: > Maybe you know it but it is worth pointing out. Type annotation has ZERO > impact on performance because Julia compiles the function for the given > type arguments anyway. > > There are reasons to annotate as a way of documenting what types the > function expects or to implement dispatch rules, However, from what I have > seen, it is common for new Julia users coming from statically typed > languages to put the type annotations too narrow. > -- Um axé! :) -- Charles Novaes de Santana, PhD http://www.imedea.uib-csic.es/~charles
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Maybe you know it but it is worth pointing out. Type annotation has ZERO impact on performance because Julia compiles the function for the given type arguments anyway. There are reasons to annotate as a way of documenting what types the function expects or to implement dispatch rules, However, from what I have seen, it is common for new Julia users coming from statically typed languages to put the type annotations too narrow.
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Thanks Yichao, Eric, and Kevin for your messages. I learned a lot from you!
I solved this specific problem using AbstractFloat and Integer, as you
suggested.
But I see I have a lot of old code where I was using "Float64" and "Int64"
and I now understand I need to change all of them to make them a bit more
portable. For example, to use template (function f1{T}(p1::T,
v1::Vector{T}, m1::Matrix{T}).
Thanks a lot!
Charles
On 1 January 2016 at 09:02, Eric Forgy wrote:
> Ah. Thanks for the correction :)
>
> Happy New Year!
>
--
Um axé! :)
--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Ah. Thanks for the correction :) Happy New Year!
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
I think you meant "...instead of Int64, you can try Integer". Int is a type
alias for Int64 (on 64 bit platforms) or Int32 (on 32 bit platforms).
Cheers,
Kevin
On Thursday, December 31, 2015, Eric Forgy wrote:
> Hi Charles,
>
> Like Yichao says, you probably don't want to define your functions too
> specifically, but that doesn't mean you need to go all the back and use
> Number. Instead of Float64, you can try AbstractFloat and instead of Int64,
> you can try Int.
>
> I might define your function signature like:
>
> function main{F<:AbstractFloat,I<:Int}(Qi::F, Qf::F, dq::F, Np::I, r2dq::F
> , r2fa::F, torem::I)
>
> so it isn't defined in terms of abstract types.
>
> Hope this helps.
>
> Happy New Year! :D
>
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Hi Charles,
Like Yichao says, you probably don't want to define your functions too
specifically, but that doesn't mean you need to go all the back and use
Number. Instead of Float64, you can try AbstractFloat and instead of Int64,
you can try Int.
I might define your function signature like:
function main{F<:AbstractFloat,I<:Int}(Qi::F, Qf::F, dq::F, Np::I, r2dq::F,
r2fa::F, torem::I)
so it isn't defined in terms of abstract types.
Hope this helps.
Happy New Year! :D
Re: [julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
On Thu, Dec 31, 2015 at 10:41 AM, Charles Novaes de Santana wrote: > Hi people, > > I defined a simple function that is running perfectly in my machine, but a > collaborator of mine is facing problems to run this function in a Ubuntu 32 > bits running in Virtualbox (he has a windows machine 64 bits, but for some > reason he can not run Ubuntu 64 bits in Virtualbox). > > Below you can find the prototype of the function I have and how I call it > > function main(Qi::Float64, Qf::Float64, dq::Float64, Np::Int64, > r2dq::Float64, r2fa::Float64, torem::Int64) first: Int is Int32 on 32bit And it is bad practice to declare strict type in function parameters, especitally for numbers. There's no performance difference since the compiler always specialize on the actual types and it leads to annoy errors like this. > > #code here# > > end > > main(-5.0,5.0,1.0,9,-1.0,-1.0,1); > > And now you can find the error message he receives: > > ERROR: LoadError: MethodError: `main` has no method matching main(::Float64, > ::Float64, ::Float64, ::Int32, ::Float64, ::Float64, ::Int32) > Closest candidates are: > main(::Float64, ::Float64, ::Float64, !Matched::Int64, ::Float64, > ::Float64, !Matched::Int64) > in include at ./boot.jl:261 > in include_from_node1 at ./loading.jl:304 > in process_options at ./client.jl:280 > in _start at ./client.jl:378 > while loading /home/lucas/.julia/v0.4/Multifractal/test/runtests.jl, in > expression starting on line 16 > > > According to this > (http://docs.julialang.org/en/release-0.4/manual/methods/#defining-methods) > I understand this problem could be solved by replacing all my "Float64" and > "Int64" by "Number". Is that the good practice? Wouldn't it make my code > slower as the exact type is not defined? > > thanks for any help! have a nice last day of Gregorian year! ;) > > Charles > > > -- > Um axé! :) > > -- > Charles Novaes de Santana, PhD > http://www.imedea.uib-csic.es/~charles
[julia-users] Type mismatch: MethodError, !Matched::Int64, etc...
Hi people, I defined a simple function that is running perfectly in my machine, but a collaborator of mine is facing problems to run this function in a Ubuntu 32 bits running in Virtualbox (he has a windows machine 64 bits, but for some reason he can not run Ubuntu 64 bits in Virtualbox). Below you can find the prototype of the function I have and how I call it function main(Qi::Float64, Qf::Float64, dq::Float64, Np::Int64, r2dq::Float64, r2fa::Float64, torem::Int64) #code here# end main(-5.0,5.0,1.0,9,-1.0,-1.0,1); And now you can find the error message he receives: ERROR: LoadError: MethodError: `main` has no method matching main(::Float64, ::Float64, ::Float64, ::Int32, ::Float64, ::Float64, ::Int32) Closest candidates are: main(::Float64, ::Float64, ::Float64, !Matched::Int64, ::Float64, ::Float64, !Matched::Int64) in include at ./boot.jl:261 in include_from_node1 at ./loading.jl:304 in process_options at ./client.jl:280 in _start at ./client.jl:378 while loading /home/lucas/.julia/v0.4/Multifractal/test/runtests.jl, in expression starting on line 16 According to this ( http://docs.julialang.org/en/release-0.4/manual/methods/#defining-methods) I understand this problem could be solved by replacing all my "Float64" and "Int64" by "Number". Is that the good practice? Wouldn't it make my code slower as the exact type is not defined? thanks for any help! have a nice last day of Gregorian year! ;) Charles -- Um axé! :) -- Charles Novaes de Santana, PhD http://www.imedea.uib-csic.es/~charles
