Hi Benedikt.
On Sun, 11 Sep 2016 12:32:36 +0000, Benedikt Ritter wrote:
Gilles <gil...@harfang.homelinux.org> schrieb am So., 11. Sep. 2016
um
13:33 Uhr:
Hello.
On Sat, 10 Sep 2016 19:18:32 -0600, Shane S wrote:
> Hi Gilles,
>
> Thank you for your response. These methods are used primarily in
> computational number theory applications. I myself came across the
> need for
> these algorithms when studying and implementing traditional and
> proposed
> variants of the Quadratic Sieve integer factorisation algorithm.
But
> these
> methods are also required for other factorisation algorithms such
as
> the
> number field sieve. As a result, the library additions I propose
> would also
> have cryptographic applications.
Lacking the necessary knowledge, I have no clear view of who
would be potential users of your proposed contributions.
For example, assuming that this code were available for use,
how much would still be necessary in order to build a
cryptographic application?
> These methods are no more complex than modInverse() in BigInteger
> and from
> my limited experience, have found the use cases to be similar in
> general.
Given that most (and perhaps all) current uses of Commons Math
are in applications that deal with "double", I'd guess that
extensions of "BigInteger" would be better located in their own
component.
To me this (again) raises the question whether we need a dedicated
Math
TLP...
As I've argued already, whether another TLP or this
("Commons") TLP, it does not change anything about the
issue itself: there are too many totally unrelated topics
within the Commons Math codebase. And each of those may
(and does) have non-overlapping user communities. [Which
entails the current maintenance problem.]
Likewise, the solution is the same: modularization.
"Commons" can quite perfectly be the home to several new
components outsourced from Commons Math, each with a much
more focused scope (and corresponding community).
The issue, raised by you for example, of having to group
all "mathematically"-oriented tools in a single component
(or TLP) makes no sense, neither conceptually nor from a
project management POV: "Mathematics" (with an "s"!) is not
one topic.
Of course, it's this PMC's right to not want to manage the
resulting components; but in that case, it should have
accepted to donate the code to said-TLP.
[This much was requested by James Carman, but was vetoed by
some PMC people.]
Regards,
Gilles
Benedikt
[In line with all the reasoning about monolithic vs modular which
you can find in the ML archive discussions that happened around
last May.]
> I can certainly understand the reluctance in light of the limited
> human
> resources. I would like to contribute to the maintenance of the
code
> base
> in any way I can. I have no experience in open source projects
like
> this,
> but I am willing to learn.
My idea is to create a module that would collect all
functionalities that deal with "higher" precision and
"big" numbers.
Candidates for this component could be
o.a.c.math4.util.BigReal
o.a.c.math4.dfp
o.a.c.math4.primes
o.a.c.math4.fraction
Would you be interested in working on that?
> If it is agreed that the functionality I propose is useful,
I don't doubt that it is interesting functionality; I have
no idea whether it is useful (in the sense that it would
more users than just you).
> I could also
> commit to maintaining it
That is usually a requirement for incorporating code in Commons
(but we failed spectacularly in that respect in Commons Math!).
Best regards,
Gilles
>
> Thank you
>
> On Sep 9, 2016 5:24 PM, "Gilles" <gil...@harfang.homelinux.org>
> wrote:
>
>> Hi.
>>
>> Thanks for offering to contribute to Commons Math.
>>
>> However, this is a quite advanced topic, and I don't
>> know whether Commons Math is the right place for this
>> functionality.
>> Could you provide more background information about
>> who (or what applications) are the potential users
>> for these algorithms?
>>
>> Please note that this is not outright rejection, but
>> we are severely lacking human resources to manage the
>> existing codebase[1] and discussions are ongoing as to
>> how best continue this project.
>>
>> My personal opinion is that all well-defined topics
>> (such as your proposal might be) should be developed
>> in their own component.[2]
>>
>> Best regards,
>> Gilles
>>
>> [1] See the "dev" ML archives if you'd like to know
>> how this happened.
>> [2] See the archives, too.
>>
>> On Thu, 8 Sep 2016 11:16:03 -0600, Shane S wrote:
>>
>>> Hello all,
>>>
>>> I would like to create a class of some common number theory
methods
>>> for
>>> the
>>> Commons Math library (or add methods the the BigInteger class).
I
>>> am
>>> motivated to do this following a summer research project at my
>>> university
>>> (University of Calgary). I was/am implementing some factoring
>>> algorithms
>>> for cryptographic applications and found that there were no
>>> libraries to
>>> do
>>> things such as:
>>> - Determining quadratic residuocity by way of Jacobi/Legendre
>>> symbol
>>> calculation
>>> - Determining the square root (mod p)
>>> - variations of the Sieve of Eratosthenes for producing a list
of
>>> primes
>>>
>>> I also noticed the lack of library support for these operations
>>> while
>>> doing
>>> my first math based crypto course, as did many of my peers. I
think
>>> that
>>> the increasing practical use of these methods warrants their
>>> inclusion in
>>> the Commons Math library.
>>> I implemented Java methods for these operations for my own use
and
>>> would
>>> like to contribute them to Commons Math. I am looking for any
>>> comments
>>> about this, specifically if the developer and commiter community
>>> here
>>> would
>>> support this. I am completely new to open source projects and
>>> welcome any
>>> advise.
>>>
>>> Sincerely,
>>>
>>> Shane Sims
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
