Question about type of numeric LWM2M attributes.

[sbernard31]

The specification v1.1.1 defines greater than, lesser than and step as decimal :

• https://www.openmobilealliance.org/release/LightweightM2M/V1_2_1-20221209-A/HTML-Version/OMA-TS-LightweightM2M_Core-V1_2_1-20221209-A.html#Table-732-1-lessNOTIFICATIONgreater-class-Attributes
• https://datatracker.ietf.org/doc/html/draft-ietf-core-conditional-attributes#section-3.1

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 and step is used to target :

• a LWM2M float resource where value is encoded with java double, I guess users should expect to face this kind of problem.
• a LWM2M integer resource, where value is encoded with java 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 in double not enough precision and so will be approximated by 9223372036854776000)
• a LWM2M unsigned integer resource, where value is encoded with java ULong, maybe user could expect to be able to use all possible ULong and this will not be possible too.

So question is :

• is this limitation acceptable ?
• OR should we use BigDecimal instead ?
• 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 :

• raising an exception ?
• OR logging a warning ?

[sbernard31]

@PFnord, @mgdlkundera, @jvermillard, @JaroslawLegierski any opinion about it ?

[jvermillard]

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

[PFnord]

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?

[sbernard31]

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. 😬

For now, I feel acceptable solutions could be :

• use BigDecimal to fully support it
• keep the Double limitation but warn or raise exception when we get a string value which can not be store in double.

Maybe moving to BigDecimal, is not so Bad ?