openPMD-standard
openPMD-standard copied to clipboard
openPMD
gridGlobalOffset: allow int
Especially in PIC simulations, the grid offset is usually a full number (of cells) and should be able to be stored as int as well to the currently allowed floats.
We should relax its allowed types for gridGlobalOffset.
@ax3l Question: Since floating point numbers includes integers are not integers always allowed any place where a floating point number is called for? In other words, it seems to me you don't have to make this explicit in the standard. Any well constructed reader should be able to handle any floating point number that is stored as an integer.
@DavidSagan, sorry, does your comment suggest storing it as a float encoded as a float that happens to be an integer or as an integer encoded as an integer in a seemingly float field? It's confusing.
@t184256 My comment is that if the standard specifies a number as a float then this does not preclude the actual stored number to be an integer. That is, the standard need not specify that an integer is also possible.
Since floating point numbers includes integers [...]
No, in computer science floating point and integer representations are very different. Floats are not the superset of ints and also not vice versa :) Furthermore, one looses precision in most casts ("most" depending on the value).
We specify this reference also very precisely in the first section of the base standard: Conventions Throughout these Documents.
@ax3l
No, in computer science floating point and integer representations are very different.
This is true but from the perspective of the Standard I cannot see where just specifying that by specifying data as floating point does not preclude the actual storage as integer is going to be a problem.
We are just explicit and sometimes we actually need ints only, e.g. for number offsets in (particle) patches or snapshot (iteration) numbers.
We are just explicit and sometimes we actually need ints, e.g. for number offsets in (particle) patches.
All I am suggesting is that in the Standard when you you define "float" it is stated that this always includes the possibly of storing the data as integer. So then you don't have to worry about having to specify things for individual data sets and attributes.
I don't see the need for allowing integer values explicitly . Storing the number of cells rather than a physical distance does not conflict with the definition of simulation units.
Furthermore, gridGlobalOffset is stored as 64-bit double precision floating point, as per the standard. That means that the 53 bit of the mantissa can be used to store integer values precisely (i.e. bit-precise).
This would be viable if there is an absolute need to state explicitly that storing integers is allowed... or if you expect to ever have grids greater than 2^53 per dimension...
I would like keeping it explicit but we could add a definition for (anything) that includes all of the above and use it. But then, anything is not a string and confuses again. Dunno, I think the explicit way keeps it simple for people and is not too much to write in type: .
The reason we kept it to an explicit list of types was simply because we did not explicitly dig into representations of structs (#144) and complex' (#29) in various file formats yet. And one really does not want to have a struct, complex, quaternion, string, bool or anything exotic in an offset attribute as a reader tool without expecting it.
To my mind this is getting into implementation details that are best left out of the Standard. Just like the Standard avoids specifying that the storage must use HDF5 format. There are long and short ints and signed and unsigned ints whose representations are different so if you really want to get specific you need to say what is allowed and what is not. And if you specify float or int for one parameter but only float for another does that mean that the second parameter cannot store the value as an integer? Or do you want to everywhere just specify "float or int"?