Handling Uint64 Arithmetic Operations and Integer Type Encoding in eKuiper #2284
Replies: 1 comment
-
To tackle the problem of calculating the difference between A and B, one approach could be to leverage the comparison of A and B(whether A is greater than B) to determine whether the result is positive or negative. Subsequently, you can adjust the result based on your specific requirements. The resulting encoding problem in eKuiper is due to the limitation that only bigint (int64) types are supported for integer types. In EdgeX, if the ValueType of a reading is INT8, INT16, INT32, INT64, UINT, UINT8, UINT16, UINT32, or UINT64, eKuiper tries to convert it to the bigint type for processing. This automatic data type conversion in EdgeX is described in more detail in the eKuiper documentation (https://ekuiper.org/docs/en/latest/guide/sources/builtin/edgex.html). Based on the information provided, if the calculation involves uint64 type and any other uint type, the result should be encoded as uint64. For calculations involving other types, the results should be encoded as int64. |
Beta Was this translation helpful? Give feedback.
-
Hello everyone,
I have come across a use case in which I need to perform a subtraction operation on two EdgeX variables, A and B, both of type Uint64. The intention is to calculate the delta (A - B) between these variables. However, I noticed that if the result of this subtraction is a negative value, it is still encoded in Uint64, which gives an incorrect result. For example, if I perform 6 - 7, instead of obtaining -1 as expected, I get 18446744073709551615 due to the Uint64 encoding.
One potential solution I considered is using a cast function to convert the result to a bigint (int64). However, this approach raises concerns with large positive values that may not fit within int64.
Furthermore, I observed that whenever Uint64 is involved in a computation with other integer types, the result is automatically encoded in Uint64. Is this design choice deliberate? On the other hand, when Uint32, Uint16, or Uint8 are involved in a computation, the result is always encoded in Int64. Could someone shed light on the rationale behind this behavior and whether there are considerations for improving it to handle negative results appropriately?
Thank you for your insights and guidance.
Beta Was this translation helpful? Give feedback.
All reactions