Re: [Geometry] Class "Equivalency"

Gilles, I took another look at the code and it turns out we can easily remove the entire Equivalency interface and just use methods of the form "eq(T, DoublePrecisionContext)", exactly the same way that the VectorXD classes do it now. This way, it's a little more clear what precision is being

Re: [Geometry] Class "Equivalency"

Hi. 2020-01-03 22:02 UTC+01:00, Matt Juntunen : > Gilles, > > Yes, users are responsible for handling their own PrecisionContexts. The > idea behind the Equivalency interface was to provide an easy way to perform > "fuzzy" comparisons between objects. The interface itself does not define > what

Re: [Geometry] Class "Equivalency"

Gilles, Yes, users are responsible for handling their own PrecisionContexts. The idea behind the Equivalency interface was to provide an easy way to perform "fuzzy" comparisons between objects. The interface itself does not define what the comparison involves. Classes that implement the

[RESULT][VOTE] Release Apache Commons Codec 1.14 based on RC1

This VOTE thread passes with the following ballots: +1 Gary Gregory, binding +1 Rob Tompkins, binding +1 Bruno P. Kinoshita, binding +0 Claude Warren, non-binding Gary On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote: > We have fixed quite a few bugs and added some significant enhancements

[Geometry] Class "Equivalency"

Hello. I'm wary about making that class part of the public API. I thought that the original idea was that users would be responsible of how they handle the "PrecisionContext". However, it seems that "Equivalency" requires equality of "PrecisionContext" instances (not the "double" value). This is

Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1

> On Jan 3, 2020, at 9:20 AM, Alex Herbert wrote: > > > >> On 3 Jan 2020, at 14:07, Rob Tompkins wrote: >> >> >> >>> On Jan 3, 2020, at 9:02 AM, Rob Tompkins wrote: >>> >>> >>> On Jan 2, 2020, at 9:27 PM, Rob Tompkins wrote: > On Jan 2, 2020, at 6:55 PM,

Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1

> On 3 Jan 2020, at 14:07, Rob Tompkins wrote: > > > >> On Jan 3, 2020, at 9:02 AM, Rob Tompkins wrote: >> >> >> >>> On Jan 2, 2020, at 9:27 PM, Rob Tompkins wrote: >>> >>> >>> On Jan 2, 2020, at 6:55 PM, Alex Herbert wrote:  > On 2 Jan 2020, at 16:53, Rob

Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1

> On Jan 3, 2020, at 9:02 AM, Rob Tompkins wrote: > > > >> On Jan 2, 2020, at 9:27 PM, Rob Tompkins wrote: >> >> >> >>> On Jan 2, 2020, at 6:55 PM, Alex Herbert wrote: >>> >>>  >>> On 2 Jan 2020, at 16:53, Rob Tompkins wrote: +0 (could be convinced of +1)

Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1

> On Jan 2, 2020, at 9:27 PM, Rob Tompkins wrote: > > > >> On Jan 2, 2020, at 6:55 PM, Alex Herbert wrote: >> >>  >> >>> On 2 Jan 2020, at 16:53, Rob Tompkins wrote: >>> >>> +0 (could be convinced of +1) >>> >>> RAT: >>> >>> * >>>

Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1

I am not a PMC member but, I'll report any way +0 (non binding) *FindBug* issues show: MurmurHash3 case fall through issues. I believe these are expected and can be fixed with an annotation. Suggest release and fix in next update *CPD* issues shows private static long getLittleEndianLong(final