replace number parsing functions with parse and tryparse

[JeffBezanson]

Continuation of #9487

[ivarne]

Why no depwarn here?

A comment refering to #10543 would also be great so that it is easier to see where a deprecation is comming from (without digging into git history).

[JeffBezanson]

This is actually just a utility used by actual deprecated functions. There never was a float_isvalid before.

[jhlq]

Unrelated question, in this function isnull is called twice, would it in
general offer a performance gain to save the value from the first call in a
local variable or is the execution time equivalent to that of fetching the
variable? Is there a definable turning point in function complexity at
which saving its output becomes beneficial? Can saving array values as
local variables offer improvement or does Julia automatically detect and
optimize reusable local values?
On Mar 17, 2015 8:01 PM, "Jeff Bezanson" notifications@github.com wrote:

In base/deprecated.jl
#10543 (comment):

@@ -496,3 +496,19 @@ function to_index{T<:Real}(A::AbstractArray{T})
depwarn("indexing with non Integer AbstractArrays is deprecated", :to_index)
Int[to_index_nodep(x) for x in A]
end
+
+function float_isvalid{T<:Union(Float32,Float64)}(s::AbstractString, out::Array{T,1})

• tf = tryparse(T, s)
• isnull(tf) || (out[1] = get(tf))
• !isnull(tf)
  +end

This is actually just a utility used by actual deprecated functions. There
never was a float_isvalid before.

—
Reply to this email directly or view it on GitHub
https://github.com/JuliaLang/julia/pull/10543/files#r26598614.

[JeffBezanson]

Yes, in general re-using a result is faster than calling a function twice.
However in this case, isnull is so trivial:

isnull(x::Nullable) = x.isnull

that it will be inlined and I'm pretty sure there'd be nothing to gain by saving its result.

In a very small number of cases Julia can automatically avoid redundant work from calling a function multiple times with the same arguments. However this is hard to do in general. For example Arrays are mutable, so it's meaningful to allocate two different ones with the same contents --- you might be planning to mutate them differently. So we can't do this optimization in such cases. Much more can be said but this topic gets complicated quickly.

[JeffBezanson]

Ah, net -3 functions. That's what I like to see.

We could also replace the raise argument to the existing parse with tryparse.

[johnmyleswhite]

Love this change.

[jakebolewski]

+1 to tryparse

[tkelman]

Since float32_isvalid and float64_isvalid were deprecated without using the @deprecate macro, they need to be put back in the exports list.

[quinnj]

What would be the best way to do 0.3 compatibility with tryparse (since I'm assuming backporting wouldn't be a possibility)? Something like:

function tryparse{T}(::Type{T}, x)
    try
        v = Nullable(parse(T, x))
    catch
        v = Nullable{T}()
    end
    return v
end

? Not quite sure all that was change here (or if there's something more performant for compatibility)

[JeffBezanson]

Yes that should work.

[quinnj]

I ended up with the following, should probably submit to Compat

function tryparse{T<:Integer}(::Type{T}, x)
        local v
        try
            v = Nullable(parseint(T,x))
        catch
            v = Nullable{T}()
        end
        return v
    end
    function tryparse{T<:FloatingPoint}(::Type{T},x)
       local v
        try
            v = Nullable(parsefloat(T,x))
        catch
            v = Nullable{T}()
        end
        return v 
    end
    function tryparse{T}(::Type{T},x)
        local v
        try
            v = Nullable(parse(x)::T)
        catch
            v = Nullable{T}()
        end
        return v
    end

[tkelman]

Could you check VERSION instead of using a try/catch?

[quinnj]

Not sure I follow @tkelman. I'm trying to get a package working on 0.3 and 0.4 and utilize the tryparse in 0.4, so I need something that will emulate the behavior in 0.3.

[tkelman]

The way almost all of the Compat.jl "use 0.4 syntax on 0.3" replacement rules work is by checking the exact VERSION where the change was made on 0.4-dev, and only applying the replacement rule for versions before that.

[quinnj]

Sure, I understand that and have that kind of VERSION check already. My question revolves around what is the best replacement form for 0.3.

[tkelman]

Right, nevermind, sorry I missed that the semantics of this would appear to require a try/catch on 0.3.