I've been using the commons math geometry libraries for some simple 2d
intersection functions, but I'm now interested in expanding it's use to
include some manipulation of 3d models with polygon counts that will
easily reach 200,000 tris. More specifically I would like to build
physical support
Hello.
I noticed that the "Text" component uses "git".
It would be simpler to also use git for the "filter" component.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mai
Hi Eric,
there hasn't been any documentation except of javadoc on it. I've added
a page in the APT format. msv site requires documentation. Not sure
what's required here.
Best,
/Bernd
On 02/11/16 09:09, Eric Barnhill wrote:
Hi Bernd,
looks like I need org/sonatype/aether/graph/DependencyFi
On 2016-11-04, Gary Gregory wrote:
>> Repository: commons-compress
>> Updated Branches:
>> refs/heads/master 46f57bf93 -> f538f38bd
>
>> avoid overflow when resizing
> Isn't this worthy of a JIRA and note in changes.xml?
the change is to a class completely new in 1.13.
Stefan
---
Isn't this worthy of a JIRA and note in changes.xml?
Gary
-- Forwarded message --
From:
Date: Fri, Nov 4, 2016 at 8:50 AM
Subject: commons-compress git commit: avoid overflow when resizing
To: comm...@commons.apache.org
Repository: commons-compress
Updated Branches:
refs/head
Hello,
Apologies if this has already been discussed. I searched the mailing lists
and issue tracker but couldn't find any references.
I'm using MultiVariableExpander, and the compilation of my code, which was
working with 1.8.1, starting failing with digester 2.0 (it also fails with
digester3):
i
On 2016-11-01, M N wrote:
>> read never indicates EOF as it stands, I think we should return -1
>> rather than 0 when position equals size. WDYT?
> Yes, indeed the contract specifies to return -1 in this case so we
> should change this.
will do.
>>> In resize() method there is also a danger to
I second that, recalling some very rough API transitions/incompatibilities in
the past (e.g., around 'LeastSquaresOptimizer')...
--Wilhelm
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/Re-Math-Re-LU-decomposition-very-SLOW-commons-math3-linear-tp4692297p4692482.ht
On Fri, 4 Nov 2016 03:16:29 -0700 (PDT), wilbur wrote:
Makes all sense. I will prepare a "minimally invasive" patch that
exactly
mimics the original behavior.
In a possible future version, I think interfaces should be used from
the
beginning, even if there is only a small chance that differen
Makes all sense. I will prepare a "minimally invasive" patch that exactly
mimics the original behavior.
In a possible future version, I think interfaces should be used from the
beginning, even if there is only a small chance that different
implementations arise. It is hard/impossible to resolve th
10 matches
Mail list logo