Yes I'd define unboundedPreceding to -sys.maxsize, but also any value less than min(-sys.maxsize, _JAVA_MIN_LONG) are considered unboundedPreceding too. We need to be careful with long overflow when transferring data over to Java.
On Wed, Nov 30, 2016 at 10:04 AM, Maciej Szymkiewicz <[email protected] > wrote: > It is platform specific so theoretically can be larger, but 2**63 - 1 is a > standard on 64 bit platform and 2**31 - 1 on 32bit platform. I can submit a > patch but I am not sure how to proceed. Personally I would set > > unboundedPreceding = -sys.maxsize > > unboundedFollowing = sys.maxsize > > to keep backwards compatibility. > On 11/30/2016 06:52 PM, Reynold Xin wrote: > > Ah ok for some reason when I did the pull request sys.maxsize was much > larger than 2^63. Do you want to submit a patch to fix this? > > > On Wed, Nov 30, 2016 at 9:48 AM, Maciej Szymkiewicz < > [email protected]> wrote: > >> The problem is that -(1 << 63) is -(sys.maxsize + 1) so the code which >> used to work before is off by one. >> On 11/30/2016 06:43 PM, Reynold Xin wrote: >> >> Can you give a repro? Anything less than -(1 << 63) is considered >> negative infinity (i.e. unbounded preceding). >> >> On Wed, Nov 30, 2016 at 8:27 AM, Maciej Szymkiewicz < >> [email protected]> wrote: >> >>> Hi, >>> >>> I've been looking at the SPARK-17845 and I am curious if there is any >>> reason to make it a breaking change. In Spark 2.0 and below we could use: >>> >>> Window().partitionBy("foo").orderBy("bar").rowsBetween(-sys.maxsize, >>> sys.maxsize)) >>> >>> In 2.1.0 this code will silently produce incorrect results (ROWS BETWEEN >>> -1 PRECEDING AND UNBOUNDED FOLLOWING) Couldn't we use >>> Window.unboundedPreceding equal -sys.maxsize to ensure backward >>> compatibility? >>> >>> -- >>> >>> Maciej Szymkiewicz >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe e-mail: [email protected] >>> >>> >> >> -- >> Maciej Szymkiewicz >> >> > > -- > Maciej Szymkiewicz > >
