There shouldn't be any penalty:
julia> foo(x) = x == 0
foo (generic function with 1 method)
julia> foo2(x) = x == zero(x)
foo2 (generic function with 1 method)
julia> @code_llvm foo(3.2)
define i1 @julia_foo_21071(double) {
top:
%1 = fcmp oeq double %0, 0.000000e+00
ret i1 %1
}
julia> @code_llvm foo2(3.2)
define i1 @julia_foo2_21116(double) {
top:
%1 = fcmp oeq double %0, 0.000000e+00
ret i1 %1
}
BTW, it's not "type instability" because there's no variable whose type is
uncertain. You can always compare a Float64 to an Int, etc.---at most the CPU
will have to do a conversion. But in this case LLVM is smart enough to do that
conversion for you at compile time.
--Tim
On Sunday, August 16, 2015 07:10:25 AM Sisyphuss wrote:
> In the Rational.jl
> <https://github.com/JuliaLang/julia/blob/master/base/rational.jl> :
>
> In Line 8: `num == den == zero(T)` uses `zero(T)` to represent 0
> In Line 9: `g = den < 0` uses `0` to represent 0
>
> Why this difference? My intuition tells me that in Line 8, it can be
> replaced by 0 without performance issue.
