Re: [CODEC] Sign Extension Error in Murmur3

On Mon, 4 Nov 2019 at 00:53, Claude Warren wrote: > > I think the way to prove they behave correctly is to test the results > against the original "C" implementation. With this in mind I proposed the > changes. > > I agree that there should be a way to revert to the old code as there is > code

Re: [CODEC] Sign Extension Error in Murmur3

As a third option as @melloware said in the pull request comments the original implementation came from Apache Hive. The current hashes could be named hash31Hive and hash128Hive On Mon, Nov 4, 2019 at 12:53 AM Claude Warren wrote: > I think the way to prove they behave correctly is to test the

Re: [CODEC] Sign Extension Error in Murmur3

I think the way to prove they behave correctly is to test the results against the original "C" implementation. With this in mind I proposed the changes. I agree that there should be a way to revert to the old code as there is code in the wild that depends on the earlier implementation. I know

Re: [rng] Releasing 1.3

Hi. > [...] > > So there are at least two options: > > 1. Release using JDK 9 +1 > 2. Update the examples project to use source 11 for the Java modules code and > release using a non-oracle JDK 11 > > Note that updating to use source 11 will break the Jenkins build which uses > JDK 9 to run a

Re: [rng] Releasing 1.3

On Sun, Nov 3, 2019 at 5:44 PM Alex Herbert wrote: > > > > On 3 Nov 2019, at 20:12, Alex Herbert wrote: > > > > > > > >> On 3 Nov 2019, at 19:30, Gary Gregory garydgreg...@gmail.com>> wrote: > >> > >> On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert > > >> wrote:

Re: [CODEC] Sign Extension Error in Murmur3

As I see it, there are two use cases here. 1) Commons Codec code is used exclusively, in which case it is essential that the output does not change for a given seed. 2) Commons Codec is used in conjunction with other implementations, in which case it is essential that Codec is aligned with other

Re: [rng] Releasing 1.3

> On 3 Nov 2019, at 20:12, Alex Herbert wrote: > > > >> On 3 Nov 2019, at 19:30, Gary Gregory > > wrote: >> >> On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert > > >> wrote: >> >>> I think everything is finalised for a release of

Re: [CODEC] Sign Extension Error in Murmur3

> On 3 Nov 2019, at 21:45, Gary Gregory wrote: > > I feel like I am missing something basic in the assumption of this issue: > there is no such thing as an unsigned int in Java and the ticket talks > about (C?) unsigned ints. Please help me understand how or why we should > care about C vs.

Re: [CODEC] Sign Extension Error in Murmur3

I feel like I am missing something basic in the assumption of this issue: there is no such thing as an unsigned int in Java and the ticket talks about (C?) unsigned ints. Please help me understand how or why we should care about C vs. Java ints. Are we comparing apples to oranges here? Thank you,

Re: [rng] Releasing 1.3

> On 3 Nov 2019, at 19:30, Gary Gregory wrote: > > On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert > wrote: > >> I think everything is finalised for a release of RNG, namely: >> >> All bugs and issues with SonarCloud and LGTM.com are fixed. >> The user guide has been updated for all the new

Re: [rng] Releasing 1.3

On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert wrote: > I think everything is finalised for a release of RNG, namely: > > All bugs and issues with SonarCloud and LGTM.com are fixed. > The user guide has been updated for all the new features. > The performance and quality results have been updated

[rng] Releasing 1.3

I think everything is finalised for a release of RNG, namely: All bugs and issues with SonarCloud and LGTM.com are fixed. The user guide has been updated for all the new features. The performance and quality results have been updated in the user guide. Any objections to me cutting a release

[CODEC] Sign Extension Error in Murmur3

There is an error in the current Murmur3 code introduced by sign extension errors. This is documented in CODEC-264.[1] I have created a pull request to fix it.[2] While the code changes did not change any of the existing Murmur3 tests, I did add new tests that failed until the changes were