>> (ASIDE: Regarding presentation: it is not always algorthmically eay >> whether to present 0.00000000000001 m as 1 * 10e-14 or a 10 fm = 10 * >> 10-15. In a scientific context, only the SI steps should be used, in >> another context the closest decimal may be appropriate.)
> But floating point numbers are handled by the implementation of [[IEEE > floating-point standard]]. > > Displaying the numbers is another question. There I have to agree that it > always makes sense to also store a typical used unit for that type of data. I agree. What I propose is that the user interface supports entering and proofreading "10.6 nm" as "10.6" plus "n" (= nano) plus "meter". How the value is stored in the data property, whether as 10.6 floating point or as 1.6e-8 is a second issue -- the latter is probably preferable. I only intend to show that scientific values are not always trivial to reverse engineer from a floating point value to the intended value. In addition to a storage option of the desired unit prefix (this may be considered a original-prefix, since naturally re-users may wish to reformat this) it is probably necessary to store the number of significant decimals. I believe in the user interface this needs not be any visible setting, simply the number of digits can be preserved. Without these is impossible to store and reproduce information like "10.20 nm", it would be returned as 1.02 10^-8 m. Complex heuristic may "guess" when to use the scientific SI prefixes instead. The trailing zero cannot be reproduced however when completely relying on IEEE floating-point. Gregor _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
