[stdlib] Add method atof() to String

[fknfilewalker]

This PR adds a function that can convert a String to a Float64. Right now it is implemented just for Float64 but maybe we should add other precisions?

This supports the following notations:

"-1236.233"
"2.25"
"2."
"1.7E+3"
# as well as the f/F postfix notation
"-1236.233f"
"2.25F"
"2.f"
"1.7E+3F"

[Moosems]

I think this also needs tests

[fknfilewalker]

What do I have to do to make the 'Standard Library tests and examples' test pass?

[artemiogr97]

What do I have to do to make the 'Standard Library tests and examples' test pass?

@fknfilewalker seems like some files are not well formatted, try running mojo format . and commit your changes

[artemiogr97]

@fknfilewalker there is still the file 'test_string' that needs to be formated, that's why the test are failing

[Moosems]

@JoeLoser Would you be willing to review this or get someone from the proper team? Hope you're having a good day!

[laszlokindrat]

Thank you for the patch, this is gonna be awesome! I have a few suggestions and quibbles, but it's generally looking nice!

[laszlokindrat]

Since result is a Float64 this will implicitly convert shift anyway. Does this work?

Suggested change

	var shift: Int = 10 ** abs(exponent)
	if exponent > 0:
	result *= shift
	if exponent < 0:
	result /= shift
	var result *= 10.0 ** exponent

[fknfilewalker]

the problem here is that mojo rounds the floats differently, and doing a division for negative exponents is closer to how mojo does it.
e.g., -0.3
mojo stores it as -0.29999999999999999
while the multiply method (3.0 * 0.1) returns -0.30000000000000004
the division method (3.0 / 10.0) produces -0.29999999999999999

so the result is different depending on whether doing a * 10 or / 0.1 or vice versa

A similar strange situation is the following

print(233.0 / 1000.0) #prints 0.23299999999999998
var x: Float64 = 233.0
var div: Float64 = 1000.0
print(x/div) #prints 0.23300000000000001

If this is a compiler issue and we can fix that then this suggestion would be definitely the better option

[laszlokindrat]

Okay, this makes sense actually. Can you please ensure we have at least one test case that hits this? Please leave a comment both here and at that test case to explain this. Thank you!

[laszlokindrat]

Also, please add a changelog entry!

[laszlokindrat]

Great patch, thank you so much!

[laszlokindrat]

@JoeLoser Would it make sense to make this functionality parametric on a floating point type? I.e. something like

fn atof[type: Dtype = Dtype.float64](str: String) raises -> Scalar[dtype]:
    constrained[type.is_float(), "must be float"]()
    ...

[laszlokindrat]

@fknfilewalker If you are interested, you could also do an overload for StringLiterals that returns arbitrary precision floats:

fn atof(str_literal: StringLiteral) -> FloatLiteral: ...

[JoeLoser]

@JoeLoser Would it make sense to make this functionality parametric on a floating point type? I.e. something like

fn atof[type: Dtype = Dtype.float64](str: String) raises -> Scalar[dtype]:
    constrained[type.is_float(), "must be float"]()
    ...

Is your goal to make it work for arbitrary-precision floats, or something else?

[laszlokindrat]

@JoeLoser Would it make sense to make this functionality parametric on a floating point type? I.e. something like

fn atof[type: Dtype = Dtype.float64](str: String) raises -> Scalar[dtype]:
    constrained[type.is_float(), "must be float"]()
    ...

Is your goal to make it work for arbitrary-precision floats, or something else?

Making it work for FloatLiteral would be nice, but there might be use cases where it's important not to have to go through Float64 if wanting to go to Float32 or Float16 (because it might actually give different results due to rounding).

[modularbot]

✅🟣 This contribution has been merged 🟣✅

Your pull request has been merged to the internal upstream Mojo sources. It will be reflected here in the Mojo repository on the nightly branch during the next Mojo nightly release, typically within the next 24-48 hours.

We use Copybara to merge external contributions, click here to learn more.

[modularbot]

Landed in 8641d49! Thank you for your contribution 🎉

[fknfilewalker]

@fknfilewalker If you are interested, you could also do an overload for StringLiterals that returns arbitrary precision floats:

fn atof(str_literal: StringLiteral) -> FloatLiteral: ...

Sure, is there a reason why we have the inner _atof function (same for _atol)?

[fknfilewalker]

@JoeLoser Would it make sense to make this functionality parametric on a floating point type? I.e. something like

fn atof[type: Dtype = Dtype.float64](str: String) raises -> Scalar[dtype]:
    constrained[type.is_float(), "must be float"]()
    ...

Is your goal to make it work for arbitrary-precision floats, or something else?

Making it work for FloatLiteral would be nice, but there might be use cases where it's important not to have to go through Float64 if wanting to go to Float32 or Float16 (because it might actually give different results due to rounding).

In order for this to work with FloatLiteral we would need to use StringLiteral I guess? How does it work to create a function for runtime values and compile time values?

[fknfilewalker]

Could atof() accept a Stringable instead of a String? Then everything could be used?

[laszlokindrat]

Sure, is there a reason why we have the inner _atof function (same for _atol)?

I don't think so, maybe the implementation used to be different and this was left over.

In order for this to work with FloatLiteral we would need to use StringLiteral I guess?

Yes.

Could atof() accept a Stringable instead of a String?

Yes, but notice that the overload I suggested returns a FloatLiteral, not a Scalar[...]:

fn atof(str_literal: StringLiteral) -> FloatLiteral: ...

FloatLiteral is arbitrary precision, and they idea here would be that this function can only be invoked at compile time. For this to work, we need to make StringLiteral @nonmaterializable, which is something I'm working on.