Open sbernard31 opened 7 months ago
@PFnord, @mgdlkundera, @jvermillard, @JaroslawLegierski any opinion about it ?
Is there a way where, if the number is received as an integer, to store it and use it as an integer, and if it's a float number, decode it as double? I think if you try to use only double for those parameters you will have errors in strict equality with a lot of integer values
As I understand it those attributes are "Float" explained in an older spec (2018_OMA_SPEC in Data Types appendix):
Represented as a binary floating point value [IEEE 754-2008] [FLOAT]. The value may use the binary32 (4 byte length) or binary64 (8 byte length) format as indicated by the Length field. When transmitted over network, the data is represented in network byte order (big endian)
I would assume, treating a float attribute as double seems ok to me.
Spec specify we can have 64bit integers resources, which I would assume means we can have 64 bit integer attributes (or close to it). I would agree with @jvermillard and treat them as integer/long when possible?
As I understand it those attributes are "Float" explained in an older spec (2018_OMA_SPEC in Data Types appendix):
I understand the data type appendix is about LWM2M Resource typing, I don't think this is about attributes typing.
Spec specify we can have 64bit integers resources, which I would assume means we can have 64 bit integer attributes (or close to it).
During comparison this should be OK but as I said if someone send me a st=9223372036854775807, it will be converted in 9223372036854776000. In that case we can eventually raise an error or log a warning or change the code to support it.
Is there a way where, if the number is received as an integer, to store it and use it as an integer, and if it's a float number, decode it as double?
Not really, currently the attribute is strongly typed. We can eventually change the type to :
String
and create corresponding number only when needed but if want to make validation handling String will be painful. (and probably less efficient than BigDecimal anyway)BigDecimal
from a design point of view this is the simple and more elegant one. (but with probably some memory usage overhead : http://javamoods.blogspot.com/2009/03/how-big-is-bigdecimal.html)
Number
and try to create the smaller possible type without data loss but this will lead to a painful code and a not so easy to use API (mainly because Number abstraction in java abstract almost nothing ...). I'm not sure this kind of optimization really worth it. :grimacing: For now, I feel acceptable solutions could be :
Maybe moving to BigDecimal, is not so Bad ?
I created a PR about using BigDecimal instead of Double : #1647
The specification v1.1.1 defines
greater than
,lesser than
andstep
as decimal :But there is (or at least I find nothing) which clearly define limit for this decimal. E.g. nothing says that this decimal should be representable as IEEE double-precision, floating-point numbers [IEEE.754].
Currently, in Leshan we encode decimal attribute as java
double
but that means that some decimal number can not be used. (classic precision number issue with floating point number)When
greater than
,lesser than
andstep
is used to target :double
, I guess users should expect to face this kind of problem.long
, maybe users could expect to be able to use all possible long and this will not be possible. (e.g. 9223372036854775807l can not be represented indouble
not enough precision and so will be approximated by 9223372036854776000)ULong
, maybe user could expect to be able to use all possible ULong and this will not be possible too.So question is :
OR maybe this is an issue but we can deal with it later (see if some user faces issue about it) ?
If we keep this limitation I think we should at least manage when we receive a decimal attribute value which can not be converted into double without precision loss by :