Question for European Users (after reading RemiD's comment on my bug thread)

[Matty]

This relates to blitz3d's reading and parsing of text files.

Create a text file as follows:

input.txt

Code Select Expand


1.50


Create a b3d file as follows:

Code Select Expand


graphics 800,600,0,2
setbuffer backbuffer()
infile = readfile("input.txt")
val$ = readline(infile)
myscale# = float(val)
closefile infile
cls
text 400,300,myscale,1,1
flip
waitkey
end


Does the number get read in as 1 point 5 or 1 hundred and 50?

In other words does blitz3d's conversion from string to float depend on the user's cultural settings and therefore treats "," and "." differently for floats as strings in text files depending on culture?

Or does blitz3d always treat a "." as the decimal point in strings as floats?

[steve_ancell]

I just did it this way as an example and it converts the string to 1.5, I used the same method on files years ago for loading level in a game and it had the same result.

Code Select Expand


Graphics 800,600,0,2
SetBuffer BackBuffer()
val$ = "1.50"
myscale# = Float(val)
Cls
Text 400,300,myscale,1,1
Flip
WaitKey
End


[steve_ancell]

Since I stopped using Blitz3D and move over to AppGameKit it has the same result in the latter.

[angros47]

I am in Europe, and Blitz3D still requires the dot, not the comma, like most of the programming languages

In everyday writing we use comma, not dot, to separate the integer and the decimal part of a number, but on computers, this applies only to some spreadsheets and some GUI.

In programming, we use the dot, because comma is used to separate different values.

By the way, if you check the file https://github.com/blitz-research/blitz3d/blob/master/bbruntime/basic.cpp, at the function "_bbStrToFloat", you can see that the conversion is performed by C the function "atof". This means, in theory if the "C" locale is configured to accept a comma, instead of a dot, it should use the European format, but the C locale is evaluated at build time, so, if the Blitz3D compiler is built using a C++ compiler with American setting, it won't change its behavior if it's used on an European machine.

I hope it's what you wanted to know

[Matty]

Thanks, that's what I wanted to know.

Answered. Thanks.

[Derron]

In BlitzMax you only need to care for ", vs ." in case something sets the locale. So be aware when using MaxGui-stuff from someone - or eg wxWidgets.

In that case you eg had to do:

Code (Blitzmax) Select Expand


Extern
Function setlocale(category:Int,locale$z)
End Extern
setlocale(6, "C")


Dunno if something exists in Blitz3D too.


If you write CSV-files with your tool you need to know in advance which locale the "reader" will use. Think either Excel or "Calc" (from OpenOffice/LibreOffice) had issues if you used the "wrong" locale. Same might happen for other tools. At least I remember to have adjusted my stringified floats when creating CSV-data for some tools at work.

As long as you are the only "user" of your files (so only you load and save and use them) it should be fine to stay with the dot separator.


bye
Ron

[Matty]

It's an issue in any language that assumes that locale is what the user's computer is unless you declare it - so it was an issue for me in C#.

It's not an issue in either Blitzplus or Blitz3d or the original Blitzbasic.

I haven't used BlitzMax but I imagine if it has a locale setting it can be a problem with that one.

Thanks again.

[RemiD]

i don't think this is an issue...

what the OS / programming langage does is different than the result displayed on the screen.

[Derron]

i don't think this is an issue...

what the OS / programming langage does is different than the result displayed on the screen.

If your programming language offers this: "StringToFloat(text)" it should care for the locales of the computer. If BlitzMax offers "string(a float)" and the result is "1.4" it is kinda "wrong" for Europeans who prefer "1,4".
Creating CSV files could lead to issues ... some programmes expect you to use locale comma separators.

This might be especially the case if the "data file" is expected to be human readable - means internal and visual representation need to be the same.

A float would internally not be saved with a separator at all. Maybe this is what RemiD thought of (internal vs external representation).


bye
Ron