Why shouldn't you use YAML to store eye tracking data? /s
-
Never said it had to be a text file. There are many binary serialization formats that could be used. But is a lot of situations the overhead you save is not worth the debugging effort of working with binary data. For something like this that is likely not going to be more then a GB or so, probably much less it really does not matter that much if you use binary or text formats. This is an export format that will likely just have one batch processing layer on. This type of thing is generally easiest for more people to work with in a plain text format. If you really need efficient querying of the data then it is trivial and quick to load it into a DB of your choice rather then being stuck with sqlite.
As long as it is something I want to be loading all at once, I would go with JSON and use the JSON binary format provided by
QJsonDocument
and forget about it.
But if I expect it to get bigger and need stuff partially loaded, things get lengthier.
Stream Reading libraries (e.g. the XML one in Qt) makes it much longer to write and that's where I would consider whether to use a database instead. -
Cuelang: https://cuelang.org/docs/reference/spec/#numeric-values
Implementation restriction: although numeric values have arbitrary precision in the language, implementations may implement them using an internal representation with limited precision. That said, every implementation must:
- Represent integer values with at least 256 bits.
- Represent floating-point values with a mantissa of at least 256 bits and a signed binary exponent of at least 16 bits.
- Give an error if unable to represent an integer value precisely.
- Give an error if unable to represent a floating-point value due to overflow.
- Round to the nearest representable value if unable to represent a floating-point value due to limits on precision. These requirements apply to the result of any expression except for builtin functions, for which an unusual loss of precision must be explicitly documented.
wrote on last edited by [email protected]Thanks for teaching me something, but the obscurity of your answer just illustrates how rare that requirement is in human readable formats, and mostly limited to data formats designed for numeric precision, like HDF5, FITS or protobuf.
-
Thanks for teaching me something, but the obscurity of your answer just illustrates how rare that requirement is in human readable formats, and mostly limited to data formats designed for numeric precision, like HDF5, FITS or protobuf.
wrote on last edited by [email protected]I don't think having well-defined precision is a rare requirement, it's more that most devs don't understand (and/or care) about the pitfalls of inaccuracy, because they usually aren't obvious. Also, languages like JavaScript/PHP make it hard to do things the right way. When I was working on an old PHP codebase, I ran into a popular currency library (Zend_Currency) that used floats for handling money, which I'm sure works fine up until the point the accountants call you up asking why they can't balance the books. The "right way" was to use the bcmath extension, which was a huge pain.
-
JSON is valid YAML does not imply that YAML is valid JSON
wrote on last edited by [email protected]That was my point, yes, but I was replying to @[email protected]'s suggestion that "all yaml is just sparkling json".
-
What text based serialization formats do enforce numeric precision?
AFAIK it’s always left up to the writer (serializer)
Technically, JSON enforces a specific numeric precision by enforcing that numbers are stored as JS-compatible floating point numbers with its associated precision.
Other than that, the best way to go if you want to have a specific precision is to cast to string before serialisation.
-
Yeah this isn't even human readable even when it's in YAML. What am I going to do? Read the floats and understand that the person looked left?
It's human-readable enough for debugging. You might not be able to read whether a person look left, but you can read which field is null or missing or wildly out of range. You can also read if a value is duplicated when it shouldn't be.
Human-readable is primarily about the structure and less about the data being human readable.
-
It's human-readable enough for debugging. You might not be able to read whether a person look left, but you can read which field is null or missing or wildly out of range. You can also read if a value is duplicated when it shouldn't be.
Human-readable is primarily about the structure and less about the data being human readable.
wrote on last edited by [email protected]You could also not be an idiot and write a debug script that checks those values or atleast provides an interface
But I guess they don't teach that kind of thing in the javascript and python school of dogshit programming
-
You could also not be an idiot and write a debug script that checks those values or atleast provides an interface
But I guess they don't teach that kind of thing in the javascript and python school of dogshit programming
wrote on last edited by [email protected]Who pissed in your coffee?
Sure you can write some script to interpret the data, but then you need to write an extra script that you need to run any time you step through the code, or whenever you want to look at the data when it's stored or transferred.
But I guess you have never worked on an actually big project, so how would you know?
I guess you aren't entirely wrong here. If nobody other than you ever uses your program and nobody other than you ever looks at the code, readability really doesn't matter and thus you can microoptimize everything into illegibility. But don't extrapolate from your hobby coding to actual projectes.
-
Who pissed in your coffee?
Sure you can write some script to interpret the data, but then you need to write an extra script that you need to run any time you step through the code, or whenever you want to look at the data when it's stored or transferred.
But I guess you have never worked on an actually big project, so how would you know?
I guess you aren't entirely wrong here. If nobody other than you ever uses your program and nobody other than you ever looks at the code, readability really doesn't matter and thus you can microoptimize everything into illegibility. But don't extrapolate from your hobby coding to actual projectes.
LMFAO in my turf if we need to constantly check some values we either have a hook or a wrapped Stream<T>
Weak diss
-
LMFAO in my turf if we need to constantly check some values we either have a hook or a wrapped Stream<T>
Weak diss
wrote on last edited by [email protected]I was discussing topical points. You were here "dissing".
That's poor behaviour and seriously just childish. Clearly not professional in any way. Probably like your code.