Weird string to float conversion

Just came across this weird bug, where the conversion of a string with a number separated by comma is interpreted somewhat right, but not quite, which is always weird.

I am converting a string with the number 46,00003 and get 46.097722 as a result!? So I don’t know what it is doing but its doing something that is almost right, which is always really weird, because in programming things usually either work or don’t work.

In Germany it is actually the norm to have a comma as a decimal separator and not the dot like in english, so I assumed the number component would interpret the comma correctly as the decimal separator, but apparently that’s not the case but it is instead doing something very different, yet comes up with a result that is pretty close.

Would love to understand what’s going on.

Take a look:

string_to_float.gh (5.3 KB)

1 Like

It’s a point/vector.
46.0977 is the length of a vector having as component XYZ {46,3,0}.
At the [List item] component output your data is still a text; to the panel is shown as text, to the number is converted first to a point/vector and then to a number.

It could be interesting if the gh UI shown a small icon/color to tell IF and how many implicit conversions are happening at every input params…

1 Like

Oh, okay, yeah that makes sense where the number comes from.

But it doesn’t make sense to convert it to a point/vector first and then to a number which is the length of the vector.

Good to know though, so I first have to replace all comma’s in numbers into dots and then have it interpret as a number. I wonder if it changes with locale, so I have my computer set up in English, but if I were to set it to german if it would work correctly then, since then all numbers use the comma as a decimal separator!?

I believe it’s hard-coded
Decimal separator > .
Text character > ,
But a confirmation from the high-grounds would be best.

Edit: Numeric keyboard comma VS point

Yep, formatting values to text allows for the specification of a Culture, but parsing text into values always uses the ‘Invariant’ culture, which basically means US style without the American English idiosyncrasies.

And indeed in this case the comma is interpreted as an x/y separator.

1 Like