[Numbers] Scope?

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Numbers] Scope?

Gilles Sadowski
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.g. to allow usage as Java8 functional
     interface).
[2] Partly (e.g. "linearCombination").


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Benedikt Ritter-4
Hello Gilles,

> Am 30.01.2017 um 02:17 schrieb Gilles <[hidden email]>:
>
> 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 :-))

> * CombinatoricsUtils [1]
> * ContinuedFraction [1]
> * special functions [1]
> * solvers
> * MathArrays [2]
> * MathUtils [1]
> * ...
>
> Thanks,
> Gilles
>
> [1] With redesigned API (e.g. to allow usage as Java8 functional
>    interface).
> [2] Partly (e.g. "linearCombination").
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
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 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.g. to allow usage as Java8 functional
>     interface).
> [2] Partly (e.g. "linearCombination").
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Gilles Sadowski
In reply to this post by Benedikt Ritter-4
Hi.

On Mon, 30 Jan 2017 08:10:27 +0100, Benedikt Ritter wrote:

> Hello Gilles,
>
>> Am 30.01.2017 um 02:17 schrieb Gilles
>> <[hidden email]>:
>>
>> 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?

Could be, but I'd consider it only if Lang would become "multimodule".

An interesting feature would be to be able to replace, at runtime,
in some portion of code, all calls to "Math" with calls to "FastMath"
(or any other class that implement the set of functions provided by
the JDK's "Math" class).
Is this feasible?

> [...]
>
> (Sorry for OT posting :-))

That's quite on-topic.
We should advance on a global roadmap for handling the future of
"Commons Math".

"FastMath" functions are at least as accurate as "Math". But the
"Fast" claim is not verified in some cases (hence a name change
might be in order).

The functions of "FastMath" are building blocks for other "low-level"
functionality; hence it should be made available either "standalone",
or in a light-weight component (hence the "Numbers" proposal), or in
a module of its own.

>
>> * CombinatoricsUtils [1]
>> * ContinuedFraction [1]
>> * special functions [1]
>> * solvers
>> * MathArrays [2]
>> * MathUtils [1]
>> * ...
>>
>> Thanks,
>> Gilles
>>
>> [1] With redesigned API (e.g. to allow usage as Java8 functional
>>    interface).
>> [2] Partly (e.g. "linearCombination").
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
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 (although I'd
prefer that way).

> I'm not sure the solvers fit in the scope.

I'm also not sure.

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.

Gilles

>
> Emmanuel Bourg
>
> Le 30/01/2017 à 02:17, Gilles a écrit :
>> 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.g. to allow usage as Java8 functional
>>     interface).
>> [2] Partly (e.g. "linearCombination").
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Emmanuel Bourg-3
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 prefer creating [math] sub modules than independent components.
Otherwise what will be left in [math] once you are done slicing it?

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Eric Barnhill
In reply to this post by Emmanuel Bourg-3
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 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 dimensions which I would be happy to contribute.

My understanding is that such operations can be accomplished elegantly with
lambdas now. But speaking only for myself, I tend to stick to "old school"
Java syntax and I know I find these methods very useful.

If there was general agreement on inclusion of MathArrays, I am happy to
work on it.

Eric


On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg <[hidden email]> wrote:

> 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 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.g. to allow usage as Java8 functional
> >     interface).
> > [2] Partly (e.g. "linearCombination").
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

sebb-2-2
On 30 January 2017 at 11:40, Eric Barnhill <[hidden email]> 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 these should go.
>
> 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 dimensions which I would be happy to contribute.

If every mathematical operation has its own function that quickly gets
very unwieldy to test and maintain.

> My understanding is that such operations can be accomplished elegantly with
> lambdas now. But speaking only for myself, I tend to stick to "old school"
> Java syntax and I know I find these methods very useful.

Or surely one can use a Visitor strategy if lambdas are too modern?

> If there was general agreement on inclusion of MathArrays, I am happy to
> work on it.
>
> Eric
>
>
> On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg <[hidden email]> wrote:
>
>> 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 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.g. to allow usage as Java8 functional
>> >     interface).
>> > [2] Partly (e.g. "linearCombination").
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Eric Barnhill
On Mon, Jan 30, 2017 at 12:51 PM, sebb <[hidden email]> 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 dimensions which I would be happy to contribute.
>
> If every mathematical operation has its own function that quickly gets
> very unwieldy to test and maintain.
>

With C++ complex numbers (a library I have looked at quite a bit) there are
three categories of operators: complex operations, transcendental overloads
and operator overloads. Keeping with that model for arrays does not add up
to so many functions. The new class would be around half those, and half
the functions already in the current class (e.g. shuffle, range, norm) some
of which are already operator overloads.
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
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 several basic utilities in a single
>> component.
>
> I'd prefer creating [math] sub modules than independent components.

Either you or I have misunderstood the consensus that CM cannot
provide (what I'd call) "partial" releases (I had proposed that
currently unsupported code[1] will not be released anymore).

The consequence is that the date of the next release of CM was
likely to be: never.

The consequence of which is that valuable _and_ supported code
must be moved to other components (that would also become a
good opportunity to get rid of obsolete stuff, and redesign
without backwards compatibility burdens) in order to be useful
to a larger audience.

> Otherwise what will be left in [math] once you are done slicing it?

Good question.
Development can be viewed from the [Math] component POV (removing
stuff) or from each of the new components' view (what's in scope?).

The former POV leads to project death.[2]

The latter is being worked on, and in the end, the goal is that
CM will loose nothing[3]: it will depend on other components where
the "removed" functionality has been transferred.

A big component like Commons Math is a nightmare to manage; as
we've seen, it simply did not work (reasons, according to me, have
been already amply exposed on this ML).
Small components are more agile.

The proposed roadmap increases the chances to attract enough
contributors so that eventually the huge task of supporting
the whole of CM can be considered again.
In the meantime, more focused components can attract contributors
who will not have to wait years to see their work released
officially.

This IMO is actually more community-building stuff than clinging
onto an old component, full of good code[4] but an empty shell,
community-wise.


Gilles

>
> Emmanuel Bourg
>

[1] Unsupported = nobody knows the code enough to timely follow up
     on reports about it.
[2] Visible symptom is: nobody works on reports piling up in JIRA.
[3] Of course, there will backwards incompatible changes, but that
     fact was agreed on several years ago, when the then current
     development branch was aimed at releasing the next major version.
[4] But also containing outdated things to be revamped or thrown away.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Gilles Sadowski
In reply to this post by Eric Barnhill
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 about?

> First of all there are leftover references to classes like Field that
> have
> disappeared with the larger math framework and these should go.

Agreed (no use-case have popped up IIRC).

> 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 dimensions which I would be happy to contribute.
>
> My understanding is that such operations can be accomplished
> elegantly with
> lambdas now. But speaking only for myself, I tend to stick to "old
> school"
> Java syntax and I know I find these methods very useful.

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.

> If there was general agreement on inclusion of MathArrays, I am happy
> to
> work on it.

Great.  But let's discuss first the above.


Gilles

>
> Eric
>
>
> On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg <[hidden email]>
> wrote:
>
>> 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 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.g. to allow usage as Java8 functional
>> >     interface).
>> > [2] Partly (e.g. "linearCombination").
>> >
>> >


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Numbers] Java version? (Was: Scope?)

Gilles Sadowski
> [...] 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.


Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Java version? (Was: Scope?)

garydgregory
+1 on Java 8.

Gary

On Mon, Jan 30, 2017 at 5:25 PM, Gilles <[hidden email]>
wrote:

> [...] 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.
>>
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Java version? (Was: Scope?)

Eric Barnhill
Okay. I will catch myself up on Lambdas and come back with a proposal for
this class at that time.

Eric

On Tue, Jan 31, 2017 at 3:05 AM, Gary Gregory <[hidden email]>
wrote:

> +1 on Java 8.
>
> Gary
>
> On Mon, Jan 30, 2017 at 5:25 PM, Gilles <[hidden email]>
> wrote:
>
> > [...] 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.
> >>
> >
> >
> > Gilles
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Raymond DeCampo
In reply to this post by Gilles Sadowski
On Mon, Jan 30, 2017 at 8:58 AM, Gilles <[hidden email]>
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 Java 8.  Oracle has stopped public updates for
Java 7, so perhaps "soon unsupported" is an understatement.

There are methods in java.lang.Math introduced in Java 8 (with the naming
pattern *Exact) which could simplify/eliminate some of the methods in
ArithmeticUtils.


>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Gilles Sadowski
On Tue, 31 Jan 2017 19:28:31 -0500, Raymond DeCampo wrote:

> On Mon, Jan 30, 2017 at 8:58 AM, Gilles
> <[hidden email]>
> 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 Java 8.  Oracle has stopped public updates
> for
> Java 7, so perhaps "soon unsupported" is an understatement.

I'm trying to put it in a mild way, given the history of discussions
on such issues. The "End of Service Life" of Java 5 was 2009, yet
"Commons Math" was still targetting it 7 years later (including the
last 2 major versions)!

>
> There are methods in java.lang.Math introduced in Java 8 (with the
> naming
> pattern *Exact) which could simplify/eliminate some of the methods in
> ArithmeticUtils.

Then we should move the functions that have an "xxxExact" counterparts
to "FastMath" (as per the Javadoc of that class, claiming that is a
drop-in replacement of "java.lang.Math").

Would you be willing to file a JIRA issue for that task, and take it
on?
Then a sub-task might be to check whether, as of Java 8, "FastMath"
is still faster or more accurate for some functions.

Regards,
Gilles

>
>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Jörg Schaible
In reply to this post by Raymond DeCampo
Hi Raymond,

Raymond DeCampo wrote:

> On Mon, Jan 30, 2017 at 8:58 AM, Gilles <[hidden email]>
> 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 Java 8.  Oracle has stopped public updates for
> Java 7, so perhaps "soon unsupported" is an understatement.

Android still does not even provide Java 8 support. There are always more
players in the camp than expected.

> There are methods in java.lang.Math introduced in Java 8 (with the naming
> pattern *Exact) which could simplify/eliminate some of the methods in
> ArithmeticUtils.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Gilles Sadowski
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
>> <[hidden email]>
>> 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 Java 8.  Oracle has stopped public updates
>> for
>> Java 7, so perhaps "soon unsupported" is an understatement.
>
> Android still does not even provide Java 8 support. There are always
> more
> players in the camp than expected.

It would be great to have those players in our camp!

I'm not against targetting old Java (cf. "Commons RNG"), so let's
not start the wrong fight.
The issue is: What do we gain (really) and what do we loose (really)
going one way or the other?

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 contributors.

We can't be expected to work with a hand tied behind the back for
the sake of the "unknown" programmer.
Removing the fun entails less opportunities to gather interest for
the project, so that eventually there won't be any code at all,
neither Java 8, nor Java 7.

Regards,
Gilles

>> There are methods in java.lang.Math introduced in Java 8 (with the
>> naming
>> pattern *Exact) which could simplify/eliminate some of the methods
>> in
>> ArithmeticUtils.
>
> Cheers,
> Jörg
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Jörg Schaible-5
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
>>> <[hidden email]>
>>> 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 Java 8.  Oracle has stopped public updates
>>> for
>>> Java 7, so perhaps "soon unsupported" is an understatement.
>>
>> Android still does not even provide Java 8 support. There are always
>> more
>> players in the camp than expected.
>
> It would be great to have those players in our camp!
>
> I'm not against targetting old Java (cf. "Commons RNG"), so let's
> not start the wrong fight.
> The issue is: What do we gain (really) and what do we loose (really)
> going one way or the other?
>
> 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 contributors.
>
> We can't be expected to work with a hand tied behind the back for
> the sake of the "unknown" programmer.
> Removing the fun entails less opportunities to gather interest for
> the project, so that eventually there won't be any code at all,
> neither Java 8, nor Java 7.

Don't get me wrong. I am not against Java 8 here, but the arguments "it is
not maintained by Oracle" or "nobody is using it anymore" are simply not
valid. I maintain other open source stuff and I get regularily complaints
from developers if they cannot port their Java apps to Android where classes
targeting Java 8 are not usable.

If we decide, we have a big benefit e.g. by using lambdas or streams, fine.
We just have to be clear about the consequences. Is Numbers exotic enough
that nearly no one expects it to run on Android?

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Scope?

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
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 contributors.
>
> We can't be expected to work with a hand tied behind the back for
> the sake of the "unknown" programmer.
> Removing the fun entails less opportunities to gather interest for
> the project, so that eventually there won't be any code at all,
> neither Java 8, nor Java 7.

Keep in mind that developers are users before becoming contributors. If
we target a narrower set of users we also limit our ability to recruit
new contributors. So we have to find a balance between not too old
technologies to avoid scaring potential contributors, and not too recent
to keep a decent user base that will provide new contributors.

As far as I'm concerned the 'scary' limit is anything < Java 5. I
wouldn't mind contributing to a Java 5, 6 or 7 project is it's
fulfilling an important need for me.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12