# Converting strings of numbers to numbers?

I have strings of numbers (possibly a vector of strings of numbers) which can be either integer or floating point – I may not know the type in advance – and I want to preserve the type. I understand that I should use function `parse` to convert the string to number. One possible (but ugly?) strategy is the following (e.g., with `s="200"` or `s="2.0e3"`):

``````s = "200";
x = try
parse(Int,s)
catch
parse(Float64,s)
end;
``````

Is there a better way to do this? Something like `parse(Number,s)`, or something?

2 Likes

Look at `tryparse`.

You can consider parsing as `Float64` and then checking if it is an integer:

``````y = parse(Float64, "200")
x = isinteger(y) ? Int(y) : y
``````
4 Likes

Thanks for 2 suggestions!

I don’t understand what is wrong with plain old `parse`.

``````julia> s1 = "200"
"200"

julia> s2 = "2.0e3"
"2.0e3"

julia> parse(s1)
200

julia> parse(s2)
2000.0

``````
2 Likes

It will no longer work in v0.7/master.
`parse(string)` is really designed for parsing Julia code, so it has been moved to `Meta.parse`.

Unfortunately, you can’t either do `parse(Number, string)`, or `parse(Unsigned, string)` which would be useful if you don’t mind the type instability, and simply want to get the value returned as a type that can represent the number in the string (if it is a valid format), possibly as a `BigInt` or `BigFloat`.

I may just have to add that functionality to my Strs package

1 Like

There is a problem with that though, if the integer would take more than 52/53 bits to represent exactly.

1. It invokes the Julia parser, which is a much more generic solution, and consequently less efficient for a specific parsing task. Eg on `v0.6.2`, I find a ~400x speed difference between `parse(...)` and `parse(Int, ...)`.
2. For the same reason, it does not restrict or validate input (as long as it is valid Julia code). This can lead to unintended consequences.

Parsing text as a given type and parsing it as code are very different tasks; consequently `v0.7` distinguishes `Meta.parse`.

3 Likes

I tried to do `parse(Rational,"2//3")` but that didn’t work.
Anyway, I assume that `parse(Int,string)` and `parse(Float64,string)` will work in v0.7, and that it is `parse(string)` that won’t work in v0.7??

Technically `parse(string)` will work in `v0.7`, but you get a deprecation warning.

Just a minor comment. Sorry that’s a bit out of topic.

Would it be better at this point to say "It will no longer work in v1.0”? So the discussion keeps more focused on what’s the technical problem and not generating confusion between what is v0.7 and v1.0 and so on.

Ok: will `parse(Int,string)` work i v1.0?

1 Like

Yes, AFAIK what doesn’t show a deprecation warning in v0.7 will work in v1.0 too. What still works in v0.7 but prints a deprecation warning, then you might want to change it to something more stable, since in v1.0 won’t work.

Go for `parse(Int, str)`

Yes (unless, of course, a last minute PR changes that, but this is unlikely )

However, generally, if you are asking questions in the “first steps” category, you should not need to worry about `v0.7` at this point. People are trying to be helpful by pointing these things out, but this is not an immediate concern if you are just learning the language.

One possibility would also be to replace `parse(Int,str)` with `Int(str)`, `parse(Float64,str)` with `Float64(str)`, introduce `Rational(str)`, etc. – unless some of these methods are taken.

Conversion (`convert(T, ...)`), construction (`T(...)`), and parsing (`parse(T, ...)`) are usually distinguished (the manual talks about the first two), even if the distinction isn’t always clearcut. Parsing usually involves ambiguities that have to be resolved/decided (eg the base), and the user should always be prepared for a `ParseError` (or preferably use `tryparse`). Because of this, I like the current arrangement.

2 Likes

Might it not be possible to speed up the generic `Meta.parse` method by initially using a regex to check if the string is only digits, or has a decimal point, then branching it to `parse(Int,...)` or whatever? This might help with the 400x performance gap, to at least give it reasonable performance for floats and ints, and one can use the generic algorithm then with better speed.

For short strings like that, I’m afraid that using Regex might be slower than just some optimized tests for those conditions.

Not really, because the check will fail in all cases where `Meta.parse` is supposed to be used and for the other cases there are already optimized versions. Also, the regex lookup itself will dominate the time so this would still be much slower than using the correct function.

1 Like

The main goal of my post was not to use regexes specifically or to try to replace the specialized methods. There are real world scenarios where completely arbitraty code has to be parsed, and a large percentage of the time you might be dealing with integers or floats, but you might have to be prepared to deal with algebraic expressions and other functional lisp forms. Therefore it is desirable to have a meta-method that selects the optimal parse method upon arbitray code parsing, since input may contain a large percentage of integers or floats, but it is also necessary to be able to handle expressions if necessary.