On Thu, 02 Feb 2017 09:03:06 +0100, Jörg Schaible wrote:
Gilles wrote:
Hi.
On Wed, 01 Feb 2017 19:28 +0100, Jörg Schaible wrote:
Hi Raymond,
Raymond DeCampo wrote:
On Mon, Jan 30, 2017 at 8:58 AM, Gilles
wrote:
A very important issue here: what JDK version do we target?
I'd go for Jav
On Thu, 2 Feb 2017 13:15:00 +, sebb wrote:
On 2 February 2017 at 12:35, Emmanuel Bourg
wrote:
Le 1/02/2017 à 20:11, Gilles a écrit :
One aspect is that if we have separate components, they can target
different versions (each time answering the above question).
People in "Commons" pushing
On 2 February 2017 at 12:35, Emmanuel Bourg wrote:
> Le 1/02/2017 à 20:11, Gilles a écrit :
>
>> One aspect is that if we have separate components, they can target
>> different versions (each time answering the above question).
>> People in "Commons" pushing for a supposedly minimal mass for a
>>
Le 1/02/2017 à 20:11, Gilles a écrit :
> One aspect is that if we have separate components, they can target
> different versions (each time answering the above question).
> People in "Commons" pushing for a supposedly minimal mass for a
> component are at odds with offering more choices to contrib
Gilles wrote:
> Hi.
>
> On Wed, 01 Feb 2017 19:28 +0100, Jörg Schaible wrote:
>> Hi Raymond,
>>
>> Raymond DeCampo wrote:
>>
>>> On Mon, Jan 30, 2017 at 8:58 AM, Gilles
>>>
>>> wrote:
>>>
A very important issue here: what JDK version do we target?
I'd go for Java8, in the hop
Hi.
On Wed, 01 Feb 2017 19:28 +0100, Jörg Schaible wrote:
Hi Raymond,
Raymond DeCampo wrote:
On Mon, Jan 30, 2017 at 8:58 AM, Gilles
wrote:
A very important issue here: what JDK version do we target?
I'd go for Java8, in the hope to revive interest in Commons from an
audience that might
Hi Raymond,
Raymond DeCampo wrote:
> On Mon, Jan 30, 2017 at 8:58 AM, Gilles
> wrote:
>
>>
>> A very important issue here: what JDK version do we target?
>>
>> I'd go for Java8, in the hope to revive interest in Commons from an
>> audience that might be put off by the "no fun" of older and soon
On Tue, 31 Jan 2017 19:28:31 -0500, Raymond DeCampo wrote:
On Mon, Jan 30, 2017 at 8:58 AM, Gilles
wrote:
A very important issue here: what JDK version do we target?
I'd go for Java8, in the hope to revive interest in Commons from an
audience that might be put off by the "no fun" of older a
On Mon, Jan 30, 2017 at 8:58 AM, Gilles
wrote:
>
> A very important issue here: what JDK version do we target?
>
> I'd go for Java8, in the hope to revive interest in Commons from an
> audience that might be put off by the "no fun" of older and soon
> unsupported JVM.
I am inclined to go with J
On Mon, 30 Jan 2017 12:40:06 +0100, Eric Barnhill wrote:
I agree the solvers don't seem to be in the scope.
Let's agree to defer the decision. :-)
The MathArrays are a great idea but could use some rethinking.
Fine thne. Could you please start a new thread with some of the
things to rethink
On Mon, 30 Jan 2017 12:30:20 +0100, Emmanuel Bourg wrote:
Le 30/01/2017 à 12:08, Gilles a écrit :
Ideally, it should be another light-weight component (because
solvers
are used in so many areas).
This thread is about if (and how) we can try and stretch the scope a
little, so as to group sever
On Mon, Jan 30, 2017 at 12:51 PM, sebb wrote:
>
> > Also, there are a lot of basic array-wise operations that might benefit
> > from inclusion. To pick an example at random, element-by-element cosine.
> In
> > fact I already have a whole library of these (very simple) methods for up
> > to 3 dime
On 30 January 2017 at 11:40, Eric Barnhill wrote:
> I agree the solvers don't seem to be in the scope.
>
> The MathArrays are a great idea but could use some rethinking.
>
> First of all there are leftover references to classes like Field that have
> disappeared with the larger math framework and
I agree the solvers don't seem to be in the scope.
The MathArrays are a great idea but could use some rethinking.
First of all there are leftover references to classes like Field that have
disappeared with the larger math framework and these should go.
Also, there are a lot of basic array-wise o
Le 30/01/2017 à 12:08, Gilles a écrit :
> Ideally, it should be another light-weight component (because solvers
> are used in so many areas).
>
> This thread is about if (and how) we can try and stretch the scope a
> little, so as to group several basic utilities in a single component.
I'd prefe
On Mon, 30 Jan 2017 08:49:49 +0100, Emmanuel Bourg wrote:
Hi,
Shouldn't [numbers] focus only on number structures (fractions,
complex)
and the basic operations on them?
Strictly speaking, yes; but I'm trying to fit more in it than just
the obvious, so as to not require many new components (a
Hi.
On Mon, 30 Jan 2017 08:10:27 +0100, Benedikt Ritter wrote:
Hello Gilles,
Am 30.01.2017 um 02:17 schrieb Gilles
:
Hi.
Anyone has a statement about it?
Functionalities that are candidates to be moved from "Math"
to "Numbers":
* FastMath
I just thought, maybe FastMath would fit into Com
Hi,
Shouldn't [numbers] focus only on number structures (fractions, complex)
and the basic operations on them? I'm not sure the solvers fit in the scope.
Emmanuel Bourg
Le 30/01/2017 à 02:17, Gilles a écrit :
> Hi.
>
> Anyone has a statement about it?
>
> Functionalities that are candidates to
Hello Gilles,
> Am 30.01.2017 um 02:17 schrieb Gilles :
>
> Hi.
>
> Anyone has a statement about it?
>
> Functionalities that are candidates to be moved from "Math"
> to "Numbers":
> * FastMath
I just thought, maybe FastMath would fit into Commons Lang. WDYT?
Benedikt
(Sorry for OT posting :
Hi.
Anyone has a statement about it?
Functionalities that are candidates to be moved from "Math"
to "Numbers":
* FastMath
* CombinatoricsUtils [1]
* ContinuedFraction [1]
* special functions [1]
* solvers
* MathArrays [2]
* MathUtils [1]
* ...
Thanks,
Gilles
[1] With redesigned API (e.
20 matches
Mail list logo
