311–320 of 339 posts
Reminds me that the reasoning behind austerity came from an Excel calculation that didn't include all the relevant rows :~/ https://www.theguardian.com/politics/2013/apr/18/uncovered-e... https://www.bbc.co.uk/news/magazine-22223190 https://theconversation.com/the-reinhart-rogoff-error-or-how...
Have had a similar issue when adding git revisions to YAML documents. The problem is that if a YAML parser sees a string like this: "0123e04" It interprets it as a number: 123 * 10^4 Our hacky solution was to prefix the revision hashes like sha-0123e04, but still this was quite annoying. After that experience, I have stopped using YAML for any of my own configuration. Have started preferring putting my configurations…
Have had a similar issue when adding git revisions to YAML documents. The problem is that if a YAML parser sees a string like this: "0123e04" It interprets it as a number: 123 * 10^4 Our hacky solution was to prefix the revision hashes like sha-0123e04, but still this was quite annoying. After that experience, I have stopped using YAML for any of my own configuration. Have started preferring putting my configurations…
This is why i love JSON. It's only string, number, boolean, arrays, objects/dictionaries, unless you write custom serializer and deserializers..
Have had a similar issue when adding git revisions to YAML documents. The problem is that if a YAML parser sees a string like this: "0123e04" It interprets it as a number: 123 * 10^4 Our hacky solution was to prefix the revision hashes like sha-0123e04, but still this was quite annoying. After that experience, I have stopped using YAML for any of my own configuration. Have started preferring putting my configurations…
But hashes are numbers, not strings, so is it really only YAML at fault ?
The point is that this behavior is sporadic. It doesn't apply consistently across all git hashes, which is the real problem. It is easy to be caught unawares by this behavior.
Earlier quoted context omitted.
But hashes are numbers, not strings, so is it really only YAML at fault ?
Hashes are NOT numbers in base 10 scientific notation, which is how the hash that I showed you would be interpreted by YAML. The point is that this behavior is sporadic. It doesn't apply consistently across all git hashes, which is the real problem. It is easy to be caught unawares by this behavior.
This is part of more general problem, they had to rename a gene to stop excel auto-completing it into a date. https://www.theverge.com/2020/8/6/21355674/human-genes-renam... Edit: Apparently Excel has its own Norway Problem ... https://answers.microsoft.com/en-us/msoffice/forum/msoffice_...
Earlier quoted context omitted.
It looks like it is intended behavior in Excel.
Yes. Excel cells are set to a "General" format that, by default, tries to guess the type of data the cell should be from its content. A date looking entry gets converted to a date type. A number looking string to a number (so 5.80 --> 5.8, very annoying since I believe in significant digits) When you import cvs data, for example, the default import format is "General" so date looking strings will be changed to a date…
[0] The only thing you can safely do with CSV files is to interpret every value as text cell. CSV files always require out of band negotiation on everything, including delimiters, quotation, escape characters, the data type of each column.
Earlier quoted context omitted.
> they had to rename a gene to stop excel auto-completing it into a date. No one in their right mind uses a spreadsheet for data analysis. Good for working out your ideas but not in a production environment. I figure excel was chosen as this the utility the scientists were most familiar with. The proper tool for the job would be a database. I recall reading about a utility, a highly customized database with an interf…
The analysis itself isn’t (usually) happening in Excel. A lot of tools operate on CSV files. People use Excel to peek at the results or prepare input for other tools, and that’s how the date coercion slips in. Sometimes, people do use it to collate the results of small manual experiments, where a database might be overkill. Even so, the data is usually analyzed elsewhere (R, graphPad, etc).
The mistake was to believe that Excel can operate on CSV files. It doesn't support them in any meaningful way. It supports them in a "I can sort of pretend that I support CSV files" way.
The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…