You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Semantically, the numerics of an i128 are not the same as the numerics of (months,days,nanos) since i128 + i128 != (months, days,nanos) + (months, days,nanos).
The consequence of defining this type numerically here is that arithmetic kernels will accept this type, but they will yield a semantically incorrect result (e.g. i128 + i128 to sum two intervals of 1 month each).
To Reproduce
Do a numerical operation on two arrays of MonthDayNano type (for example add or subtract them). The arithmetic will be performed directly on the i128 representation rather than field by field
Expected behavior
The intervals should be calculated field by field; So for example to add two MonthDayNano fields, the kernels should add the nanoseconds, days and months separately
Additional context
The text was updated successfully, but these errors were encountered:
It might be better to disallow arithmetic for this type because number of days in a month and number of nanos in a day is different depending on the reference point of time you are in. So there is no perfect way to handle it. Compute engines can choose their own tradeoffs and implement arithmetic and ordering downstream.
Describe the bug
Pointed out by @jorgecarleitao and @b41sh on #779 (comment)
To Reproduce
Do a numerical operation on two arrays of
MonthDayNano
type (for example add or subtract them). The arithmetic will be performed directly on thei128
representation rather than field by fieldExpected behavior
The intervals should be calculated field by field; So for example to add two
MonthDayNano
fields, the kernels should add the nanoseconds, days and months separatelyAdditional context
The text was updated successfully, but these errors were encountered: