On Sat, Jan 18, 2020 at 7:35 PM Bruno P. Kinoshita
wrote:
> I think we should revert the change in a 1.14.1 or 1.15, and include in
> the release notes what happened.
> From what I understood, this would not break 1.14 users that were not
> using the deprecated methods. And would not affect 1.13
I think we should revert the change in a 1.14.1 or 1.15, and include in the
release notes what happened.
>From what I understood, this would not break 1.14 users that were not using
>the deprecated methods. And would not affect 1.13 users upgrading to 1.14.1 or
>1.15 (whichever we choose next).
Gilles,
>> There, we can simply sample the user-defined function
> I'm not sure I understand.
Just an implementation detail. We need to pass some sample points through the
user-defined function in order to construct an equivalent matrix.
> Throwing an exception if the transform does not abide b
> On 18 Jan 2020, at 16:09, Gary Gregory wrote:
>
> Any thoughts of the effect of this on the Commons Collections Bloom filter
> proposal?
>
It would have no effect. Claude’s Bloom filter code was what spotted the bug in
the MurmurHash3 implementations. We fixed hash32 and hash128 by creati
Hello.
2020-01-18 15:40 UTC+01:00, Matt Juntunen :
> Gilles,
>
>> If the "Transform" is intimately related to the "core" and there is a
>> single
>> set of properties that make it "affine" (and work correctly), I'd tend to
>> keep the name "Transform".
>
> So, if I'm understanding you correctly, y
We have fixed quite a few bugs and added some significant enhancements
since Apache Commons CSV 1.7 was released, so I would like to release
Apache Commons CSV 1.8.
Apache Commons CSV 1.8 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/csv/1.8-RC1 (svn
revision
Any thoughts of the effect of this on the Commons Collections Bloom filter
proposal?
Gary
On Fri, Jan 17, 2020 at 9:00 PM wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> aherbert pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/as
Gilles,
> If the "Transform" is intimately related to the "core" and there is a single
> set of properties that make it "affine" (and work correctly), I'd tend to
> keep the name "Transform".
So, if I'm understanding you correctly, you're saying that since the
partitioning code in the library on
