Vector string representation

If you ask for a format for serialisation, simply stick to one format that you can parse easily and safely.

I'll have European users. If they enter a number, their natural instinct will be to enter the decimal separator as a comma. I don't want to fight them on points like this.

So then just let them enter the number with the comma separator, and convert it to a non-ambiguous format before you store it. Do users enter numbers one at a time, or do they enter the entire vector at once?

The problem isn't reading in their numbers with all the different formats. It's not even displaying back their numbers in the proper format. It's how to actually display the vector to the user. I'm used to seeing this exact format:



With a comma and then a space, and bracketed by those angle brackets.

But that command and space in the middle pose trouble to a human reader, because in different regions or formats both of those symbols can have syntactic meaning. The computer really doesn't care. It'd have no problem with <234,4543, 1 454 234 234,2345>, but that is really hard to read for a human.

How are vectors and Cartesian coordinates written in Europe? Do they still use a comma in the middle as an X/Y separator?

If you're dealing with Cartesian coordinates, then you should use the decimal separator. Pick up a math book from Europe, their numbers are written the same way as ours. The use of the comma in place of the decimal separator is mostly (I believe) with respect to currency. The other option is to change your element separator; using something like
<1,24 : 35,6 : 0,34> . This way there can be no confusion that the ':' separates the elements of the vector.

For serialisation use an unambiguous format, it doesn't really matter which one you choose. It doesn't even have to be human readable.

For displaying it you should display the components in the user's local format, so use an element separator which isn't a decimal separator anywhere (basically, anything other than . or ,). I often use ;.

OT: I see this is posted in Math and Physics, and I am not sure if this not better housed in General Development

Quote:

Original post by Numsgil I'll have European users. If they enter a number, their natural instinct will be to enter the decimal separator as a comma. I don't want to fight them on points like this.

So, where exactly lies the problem and which programming language do you use?

Because serialisation/deserialisation and user-interaction have, on the first hand, nothing to do with each other.

On the second hand, maybe you want users to directly edit serialisation files; then it is like with programming, and I would not support locales in config-files (like there are no locales for programming languages C++ or C#).

On the gripping hand, maybe your problem lies in converting user input into usable data that you want to serialise later. Et voila, you don't have a serialisation problem anymore, but the problem of parsing user input properly, and that is where the programming language could be deciding, because C# does the locale kludgery for you automatically, like 'float f = float.Parse ("0,5")' will automagically yield 0.5 for float f. If it is C++, it becomes system and framework dependent. For example, QT has builtin support for locales, but there also exist lower level string manipulation libraries.

Btw, I would personally only localise number formatting if also the rest of the application is localised. I find it always confusing to have to type "0,5" in an application that is otherwise english. But that's probably personal taste.

Serialization was probably poor word choice on my part. I'm using C#, and I'm trying to implement the ToString() and Parse and TryParse methods. In my mind that's part of the serialization spectrum, but I think the word serialization is mostly used with disk access and networking in mind, which isn't my primary purpose here.

I'll play around with : and ; as element separators and see how much I like it.

I think there is no localization problem with European countries. While it's true that in some countries (Italy included) we often write numbers with the comma, we are also used to read numbers with the dot. In fact this is the way numbers are often written on internet sites or softwares.
But I find quite strange the use of the angle bracket to denote a vector. I think is more common the use of parenthesis. For example:
(345.2278, 23431.3423)

You can also simply use a space to separate the components.

Here (in Europe) in school we use (12,90 ; 80,76) to represent a vector. But the calculator used in school (and the books that explain the use of the calculator) uses a '.' and not a ','. So I don't think there is a real problem. I for one have never ever had a problem while programming. Just make sure you state somewhere that you use a '.' and not a ','. Of course when a ';' or a ':' (since a ';' might conflict with some end of line code or something) is used you can just parse them in the same way. Or just replace them at runtime.

Quote:

Original post by apatriarca But I find quite strange the use of the angle bracket to denote a vector. I think is more common the use of parenthesis. For example: (345.2278, 23431.3423)

Yes, but then it can be confused with an open interval. The angle bracket is less common, but also less ambiguous.

Quote:

Here (in Europe) in school we use (12,90 ; 80,76) to represent a vector

Thanks, that's what I was wondering. I'll probably adopt either a : or ;

I'd stick with standard representation, as in C++. Then there is no ambiguity.

12.3445, 199909.2, 3.0E-5

As for brackets, it's just a standard you have to decide, and stick to it.

xml?

C-style? Vector(12.3445, 199909.2, 3.0E-5)

custom? Vector[x=12.3445, y=199909.2, z=3.0E-5]

Quote:

Original post by Numsgil Quote: Original post by apatriarca But I find quite strange the use of the angle bracket to denote a vector. I think is more common the use of parenthesis. For example: (345.2278, 23431.3423) Yes, but then it can be confused with an open interval. The angle bracket is less common, but also less ambiguous.

The angle brackets has several uses in math, so the representation with angle brackets can be ambiguous too. The meaning of a math symbol is often only clear when inserted in his context. In your case, if the user expect to see a vector, he will not find ambiguous the use of parenthesis. If it isn't clear that the value you are showing is a vector then your problem don't reside in the use of parenthesis or angle brackets but in your UI.

Quote:

Original post by apatriarca Quote: Original post by Numsgil Quote: Original post by apatriarca But I find quite strange the use of the angle bracket to denote a vector. I think is more common the use of parenthesis. For example: (345.2278, 23431.3423) Yes, but then it can be confused with an open interval. The angle bracket is less common, but also less ambiguous. The angle brackets has several uses in math, so the representation with angle brackets can be ambiguous too. The meaning of a math symbol is often only clear when inserted in his context. In your case, if the user expect to see a vector, he will not find ambiguous the use of parenthesis. If it isn't clear that the value you are showing is a vector then your problem don't reside in the use of parenthesis or angle brackets but in your UI.

Sure. They're often used to denote the inner (dot) product. But I specifically have intervals and I specifically have vectors, so I need some way to tell an open interval apart from a vector. And I'm running out of different brackets to use ;)

Anyway there isn't a right/wrong answer. It just comes to a combination of personal taste and what the user expects.

Quote:

Original post by Numsgil Yes, but then it can be confused with an open interval.

This could drive you crazy, but here in germany, we also write intervals like this:

[inclusive..inclusive]
[inclusive..exclusive[
]exclusive..inclusive]
]exclusive..exclusive[