You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2012/08/03 22:22:06 UTC
[Math] Towards release 3.1
Hello.
More than 60 issues have been resolved since the release of Commons Math
3.0.
I think that it is time to lay out a road map for the next release (3.1),
with a target date of early September (at which point, 3.0 will be 6 months
old).
The following issues have been worked on as much as permitted for a minor
release (backwards-compatibility) and thus can be considered resolved w.r.t.
the 3.1 release:
MATH-825
MATH-803
MATH-800
MATH-799
MATH-784
The following issues are bugs that do not block the 3.1 release (either they
are minor or they would require semantic changes that are forbidden, or will
be surprising, in a minor release):
MATH-821
MATH-788
MATH-758
The following are the more serious issues:
MATH-836
MATH-828
MATH-819
MATH-789
MATH-778
MATH-740
MATH-738
"Wish" or "improvement" issues that miss a patch should not be blocking the
3.1 release.
Some of them are still marked with 3.1 as the target version. Please give
your opinion about whether they could be easily implemented in the next few
weeks, or should be postponed to release 3.2 or 4.0.
Some issues have a large scope and would require a re-design of certain
classes (e.g. MATH-765 and related), not to be implemented in a minor
release.
Please review all issues (especially those assigned to you, or reported by
you, or where you took an active part in the discussion) and provide
feedback on their "currentness".
Thanks and best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello Sébastien.
>
> >
> > More than 60 issues have been resolved since the release of Commons Math
> > 3.0.
> > I think that it is time to lay out a road map for the next release (3.1),
> > with a target date of early September (at which point, 3.0 will be 6 months
> > old).
> >
> I agree.
>
> >
> > The following issues have been worked on as much as permitted for a minor
> > release (backwards-compatibility) and thus can be considered resolved w.r.t.
> > the 3.1 release:
> > MATH-825
> > MATH-803
> >
> See my comments on MATH-821 below.
>
> >
> > MATH-800
> > MATH-799
> > MATH-784
> >
> The issue is effectively solved, but must remain opened as a reminder until 4.0.
>
> >
> > The following issues are bugs that do not block the 3.1 release (either they
> > are minor or they would require semantic changes that are forbidden, or will
> > be surprising, in a minor release):
> > MATH-821
> >
> I'm waiting for answers on the users ML (see
> http://markmail.org/thread/vu2ulvyt7pseyheq). Maybe august was not the
> best time to launch such a poll. Will try to resend it in early
> september, what do you think?
That's fine. But I doubt that you'll get more answers ;-).
In the mean time, I don't think that we have to solve this for 3.1; it can
be assumed that it is an "unsupported feature with an undefined result".
> > MATH-788
> > MATH-758
> >
> > The following are the more serious issues:
> > MATH-836
> > MATH-828
> > MATH-819
> > MATH-789
> >
> > MATH-778
> >
> Dfp Dfp.multiply(int x) does not comply with the general contract
> FieldElement.multiply(int n)
> This one will have to wait, because the problem is a bit deeper than I
> thought initially. I still need to make a thorough report.
>
> > MATH-740
> > MATH-738
> >
> Incomplete beta function I(x, a, b) is inaccurate for large values of
> a and/or b. I'm working on this one. Not sure I'll be able to give a
> satisfactory answer, but I would like some more time to work on it.
>
> >
> > "Wish" or "improvement" issues that miss a patch should not be blocking the
> > 3.1 release.
> > Some of them are still marked with 3.1 as the target version. Please give
> > your opinion about whether they could be easily implemented in the next few
> > weeks, or should be postponed to release 3.2 or 4.0.
> >
> MATH-820 is fairly easy to implement, but not absolutely necessary. If
> I can find some time, I will happily do that, but otherwise, it can
> wait.
> >
> > Some issues have a large scope and would require a re-design of certain
> > classes (e.g. MATH-765 and related), not to be implemented in a minor
> > release.
> >
> > Please review all issues (especially those assigned to you, or reported by
> > you, or where you took an active part in the discussion) and provide
> > feedback on their "currentness".
So please change the "fix release" items as you see fit.
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Gilles,
>
> More than 60 issues have been resolved since the release of Commons Math
> 3.0.
> I think that it is time to lay out a road map for the next release (3.1),
> with a target date of early September (at which point, 3.0 will be 6 months
> old).
>
I agree.
>
> The following issues have been worked on as much as permitted for a minor
> release (backwards-compatibility) and thus can be considered resolved w.r.t.
> the 3.1 release:
> MATH-825
> MATH-803
>
See my comments on MATH-821 below.
>
> MATH-800
> MATH-799
> MATH-784
>
The issue is effectively solved, but must remain opened as a reminder until 4.0.
>
> The following issues are bugs that do not block the 3.1 release (either they
> are minor or they would require semantic changes that are forbidden, or will
> be surprising, in a minor release):
> MATH-821
>
I'm waiting for answers on the users ML (see
http://markmail.org/thread/vu2ulvyt7pseyheq). Maybe august was not the
best time to launch such a poll. Will try to resend it in early
september, what do you think?
> MATH-788
> MATH-758
>
> The following are the more serious issues:
> MATH-836
> MATH-828
> MATH-819
> MATH-789
>
> MATH-778
>
Dfp Dfp.multiply(int x) does not comply with the general contract
FieldElement.multiply(int n)
This one will have to wait, because the problem is a bit deeper than I
thought initially. I still need to make a thorough report.
> MATH-740
> MATH-738
>
Incomplete beta function I(x, a, b) is inaccurate for large values of
a and/or b. I'm working on this one. Not sure I'll be able to give a
satisfactory answer, but I would like some more time to work on it.
>
> "Wish" or "improvement" issues that miss a patch should not be blocking the
> 3.1 release.
> Some of them are still marked with 3.1 as the target version. Please give
> your opinion about whether they could be easily implemented in the next few
> weeks, or should be postponed to release 3.2 or 4.0.
>
MATH-820 is fairly easy to implement, but not absolutely necessary. If
I can find some time, I will happily do that, but otherwise, it can
wait.
>
> Some issues have a large scope and would require a re-design of certain
> classes (e.g. MATH-765 and related), not to be implemented in a minor
> release.
>
> Please review all issues (especially those assigned to you, or reported by
> you, or where you took an active part in the discussion) and provide
> feedback on their "currentness".
>
>
> Thanks and best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 12/09/2012 14:04, Gilles Sadowski a écrit :
> Hello.
>
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
>
> I quote my remarks from an earlier message in this thread:
>
>> [...] issues resulted in some work being done, [...]
>> My opinion is that releases must reflect that fact. Or, conversely, only
>> "nothing new happened" is a reason for not providing a new release.
>>
>> Of course, there should be a balance between the work imposed by preparing a
>> release, and the updated contents to be released. I think that the trade-off
>> is already largely positive.
>
> and
>
>>>> "Wish" or "improvement" issues that miss a patch should not be blocking the
>>>> 3.1 release.
>
> and
>
>> Of course, I'd be all for setting a date for release 3.2 too!
>
> Context:
> I have to abide by the requirement to use an _official_ release of CM and my
> code relies on bug fixes present in the development version.
>
> Are there any technical reasons to object to the starting of the release
> process?
I would also be glad to see 3.1 out.
As far as I am concerned, the work on differentiation is almost ready.
If we can solve the silly problem I mentioned in another message a few
minutes ago, I would be happy to finish that and release 3.1.
Luc
>
>
> Thanks for your attention,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Sébastien Brisard <se...@m4x.org>.
> [...]
> I have been working on the stat package
> throws stuff. If I can have the weekend to finish, I could finish
> that; otherwise we release with this issue partly done (which is OK
> by me, as long as we push out the ticket).
>
I'm still working on the linear package, and there is still a lot to
do, I'm not sure I can go through it all y the weekend...
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Phil Steitz <ph...@gmail.com>.
On 9/12/12 5:04 AM, Gilles Sadowski wrote:
> Hello.
>
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
>
> I quote my remarks from an earlier message in this thread:
>
>> [...] issues resulted in some work being done, [...]
>> My opinion is that releases must reflect that fact. Or, conversely, only
>> "nothing new happened" is a reason for not providing a new release.
>>
>> Of course, there should be a balance between the work imposed by preparing a
>> release, and the updated contents to be released. I think that the trade-off
>> is already largely positive.
> and
>
>>>> "Wish" or "improvement" issues that miss a patch should not be blocking the
>>>> 3.1 release.
> and
>
>> Of course, I'd be all for setting a date for release 3.2 too!
> Context:
> I have to abide by the requirement to use an _official_ release of CM and my
> code relies on bug fixes present in the development version.
>
> Are there any technical reasons to object to the starting of the release
> process?
I have a couple of things in progress (the KS test / distribution
issue, making EmpiricalDistribution implement the distribution
interface) that could wait if everything else is ready. All that is
*required* is that we resolve or push out all issues marked as 3.1.
We can always follow with 3.2 or 3.1.1 soon, so I see no harm to
getting this out quickly. I have been working on the stat package
throws stuff. If I can have the weekend to finish, I could finish
that; otherwise we release with this issue partly done (which is OK
by me, as long as we push out the ticket).
Phil
>
>
> Thanks for your attention,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 12/09/2012 14:55, Thomas Neidhart a écrit :
> On Wed, Sep 12, 2012 at 2:04 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
>> Hello.
>>
>> This thread was left alone for some time, although the main issue was not
>> settled: I requested the release of a new version of CM.
>>
>> I quote my remarks from an earlier message in this thread:
>>
>>> [...] issues resulted in some work being done, [...]
>>> My opinion is that releases must reflect that fact. Or, conversely, only
>>> "nothing new happened" is a reason for not providing a new release.
>>>
>>> Of course, there should be a balance between the work imposed by
>> preparing a
>>> release, and the updated contents to be released. I think that the
>> trade-off
>>> is already largely positive.
>>
>> and
>>
>>>>> "Wish" or "improvement" issues that miss a patch should not be
>> blocking the
>>>>> 3.1 release.
>>
>> and
>>
>>> Of course, I'd be all for setting a date for release 3.2 too!
>>
>> Context:
>> I have to abide by the requirement to use an _official_ release of CM and
>> my
>> code relies on bug fixes present in the development version.
>>
>> Are there any technical reasons to object to the starting of the release
>> process?
>>
>
> Hi Gilles, all,
>
> I support the release request and we are already in September anyway (which
> was the envisioned release time of CM 3.1 afaikr).
> Regarding open issues from my side:
>
> * I would like to fix MATH-848 before the release but will have time the
> next 2 weeks
> * MATH-789: I did an initial analysis but failed to further proceed, maybe
> Luc can take a look?
I have done that (but Thomas will probably change the rank computation
as per another message).
> * MATH-842: the fix I made seems to work, but needs more investigation,
> can be postponed
> * MATH-819: more like a general problem and may be resolved as WONT FIX,
> TBD
>
> The additions I proposed can all be postponed (and I need something to do
> over winter ;-)
I have also completed the first batch of work about the new
differentiation framework. Now the core stuff is in place, and it is
used in both the solvers package and in the optimizer package.
I will add new things to this first batch, of course, but none of them
should postpone 3.1.
As far as I am concerned, 3.1 could be released anytime now.
Luc
>
> Cheers,
>
> Thomas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Thomas Neidhart <th...@gmail.com>.
On Wed, Sep 12, 2012 at 2:04 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Hello.
>
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
>
> I quote my remarks from an earlier message in this thread:
>
> > [...] issues resulted in some work being done, [...]
> > My opinion is that releases must reflect that fact. Or, conversely, only
> > "nothing new happened" is a reason for not providing a new release.
> >
> > Of course, there should be a balance between the work imposed by
> preparing a
> > release, and the updated contents to be released. I think that the
> trade-off
> > is already largely positive.
>
> and
>
> > > > "Wish" or "improvement" issues that miss a patch should not be
> blocking the
> > > > 3.1 release.
>
> and
>
> > Of course, I'd be all for setting a date for release 3.2 too!
>
> Context:
> I have to abide by the requirement to use an _official_ release of CM and
> my
> code relies on bug fixes present in the development version.
>
> Are there any technical reasons to object to the starting of the release
> process?
>
Hi Gilles, all,
I support the release request and we are already in September anyway (which
was the envisioned release time of CM 3.1 afaikr).
Regarding open issues from my side:
* I would like to fix MATH-848 before the release but will have time the
next 2 weeks
* MATH-789: I did an initial analysis but failed to further proceed, maybe
Luc can take a look?
* MATH-842: the fix I made seems to work, but needs more investigation,
can be postponed
* MATH-819: more like a general problem and may be resolved as WONT FIX,
TBD
The additions I proposed can all be postponed (and I need something to do
over winter ;-)
Cheers,
Thomas
Re: [Math] Towards release 3.1
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Gilles,
2012/9/12 Gilles Sadowski <gi...@harfang.homelinux.org>:
> Hello.
>
> This thread was left alone for some time, although the main issue was not
> settled: I requested the release of a new version of CM.
>
> I quote my remarks from an earlier message in this thread:
>
>> [...] issues resulted in some work being done, [...]
>> My opinion is that releases must reflect that fact. Or, conversely, only
>> "nothing new happened" is a reason for not providing a new release.
>>
>> Of course, there should be a balance between the work imposed by preparing a
>> release, and the updated contents to be released. I think that the trade-off
>> is already largely positive.
>
> and
>
>> > > "Wish" or "improvement" issues that miss a patch should not be blocking the
>> > > 3.1 release.
>
> and
>
>> Of course, I'd be all for setting a date for release 3.2 too!
>
> Context:
> I have to abide by the requirement to use an _official_ release of CM and my
> code relies on bug fixes present in the development version.
>
> Are there any technical reasons to object to the starting of the release
> process?
>
If you did not have this precise requirement, I would have been a bit
reluctant to release 3.1 in the middle of MATH-854. Considering your
situation, I don't see any real objection on my side.
(Sparse vectors *will* be deprecated, as only Phil answered, but this
will wait until 3.2...).
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
This thread was left alone for some time, although the main issue was not
settled: I requested the release of a new version of CM.
I quote my remarks from an earlier message in this thread:
> [...] issues resulted in some work being done, [...]
> My opinion is that releases must reflect that fact. Or, conversely, only
> "nothing new happened" is a reason for not providing a new release.
>
> Of course, there should be a balance between the work imposed by preparing a
> release, and the updated contents to be released. I think that the trade-off
> is already largely positive.
and
> > > "Wish" or "improvement" issues that miss a patch should not be blocking the
> > > 3.1 release.
and
> Of course, I'd be all for setting a date for release 3.2 too!
Context:
I have to abide by the requirement to use an _official_ release of CM and my
code relies on bug fixes present in the development version.
Are there any technical reasons to object to the starting of the release
process?
Thanks for your attention,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello Thomas.
> > More than 60 issues have been resolved since the release of Commons Math
> > 3.0.
>
> The number of resolved issues in JIRA is misleading as it includes also
> issues resolved as Won't Fix or Duplicate. Also not all issues have been
> closed after the release of 3.0, some have been kept in status resolved
> intentionally as they were marked as "Later" or "Incomplete".
Well, all of these issues resulted in some work being done, even if to reach
a "Won't fix" conclusion.
My opinion is that releases must reflect that fact. Or, conversely, only
"nothing new happened" is a reason for not providing a new release.
Of course, there should be a balance between the work imposed by preparing a
release, and the updated contents to be released. I think that the trade-off
is already largely positive.
>
> > I think that it is time to lay out a road map for the next release (3.1),
> > with a target date of early September (at which point, 3.0 will be 6 months
> > old).
>
> +1
>
> > The following are the more serious issues:
> > MATH-836 Fraction(double, int) constructor strange behaviour:
> should be solved
>
> > MATH-828 Unbounded solutions in Simplex Solver:
> should be solved, will create another issue as follow up
>
> > MATH-819 Infeasible solution in Simplex Solver:
> either won't fix or not a problem, user was providing very large
> (unnecessary) bounds in the problem which lead to obvious
> numerical problems.
>
> > MATH-789 Correlated random vector generator fails:
> I did initial analysis, but need more information about the
> implemented algorithm to fix it
>
> * MATH-777 More CrossoverPolicy's are needed: partly done, need to add
> two more policies from the patch
Thanks.
> > "Wish" or "improvement" issues that miss a patch should not be blocking the
> > 3.1 release.
> > Some of them are still marked with 3.1 as the target version. Please give
> > your opinion about whether they could be easily implemented in the next few
> > weeks, or should be postponed to release 3.2 or 4.0.
>
> MATH-748 Clustering algos
> MATH-749 Complex Hull
> MATH-750 Voronoi
> MATH-751 Computational geometry algos (wrapper issue for the 3 others)
> MATH-752 Triangulation
>
> I put them with target release 3.1, but they are obviously not blocking,
> but I am willing to do work on them in the coming weeks.
As these are totally new features which were not yet discussed in-depth (API
etc.), I'd be tempted to think that they should be formally postponed to
3.2. In case we reach an agreement on the implementation of any of them
before 3.1 is released, the "fix release" can always be modified
appropriately.
I'd like that this thread leads to agreed date for a feature-freeze.
Of course, I'd be all for setting a date for release 3.2 too! [That would be
good if you are wanting these features to appear as soon as possible in an
official release.]
> [...]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Thomas Neidhart <th...@gmail.com>.
On 08/03/2012 10:22 PM, Gilles Sadowski wrote:
> Hello.
>
> More than 60 issues have been resolved since the release of Commons Math
> 3.0.
The number of resolved issues in JIRA is misleading as it includes also
issues resolved as Won't Fix or Duplicate. Also not all issues have been
closed after the release of 3.0, some have been kept in status resolved
intentionally as they were marked as "Later" or "Incomplete".
> I think that it is time to lay out a road map for the next release (3.1),
> with a target date of early September (at which point, 3.0 will be 6 months
> old).
+1
> The following are the more serious issues:
> MATH-836 Fraction(double, int) constructor strange behaviour:
should be solved
> MATH-828 Unbounded solutions in Simplex Solver:
should be solved, will create another issue as follow up
> MATH-819 Infeasible solution in Simplex Solver:
either won't fix or not a problem, user was providing very large
(unnecessary) bounds in the problem which lead to obvious
numerical problems.
> MATH-789 Correlated random vector generator fails:
I did initial analysis, but need more information about the
implemented algorithm to fix it
* MATH-777 More CrossoverPolicy's are needed: partly done, need to add
two more policies from the patch
> "Wish" or "improvement" issues that miss a patch should not be blocking the
> 3.1 release.
> Some of them are still marked with 3.1 as the target version. Please give
> your opinion about whether they could be easily implemented in the next few
> weeks, or should be postponed to release 3.2 or 4.0.
MATH-748 Clustering algos
MATH-749 Complex Hull
MATH-750 Voronoi
MATH-751 Computational geometry algos (wrapper issue for the 3 others)
MATH-752 Triangulation
I put them with target release 3.1, but they are obviously not blocking,
but I am willing to do work on them in the coming weeks.
> Please review all issues (especially those assigned to you, or reported by
> you, or where you took an active part in the discussion) and provide
> feedback on their "currentness".
see above.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Towards release 3.1
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 03/08/2012 22:22, Gilles Sadowski a écrit :
> Hello.
Hi Gilles,
>
> More than 60 issues have been resolved since the release of Commons Math
> 3.0.
> I think that it is time to lay out a road map for the next release (3.1),
> with a target date of early September (at which point, 3.0 will be 6 months
> old).
+1
>
> The following issues have been worked on as much as permitted for a minor
> release (backwards-compatibility) and thus can be considered resolved w.r.t.
> the 3.1 release:
> MATH-825
> MATH-803
> MATH-800
> MATH-799
> MATH-784
>
> The following issues are bugs that do not block the 3.1 release (either they
> are minor or they would require semantic changes that are forbidden, or will
> be surprising, in a minor release):
> MATH-821
> MATH-788
> MATH-758
>
> The following are the more serious issues:
> MATH-836
> MATH-828
> MATH-819
> MATH-789
> MATH-778
> MATH-740
> MATH-738
>
> "Wish" or "improvement" issues that miss a patch should not be blocking the
> 3.1 release.
> Some of them are still marked with 3.1 as the target version. Please give
> your opinion about whether they could be easily implemented in the next few
> weeks, or should be postponed to release 3.2 or 4.0.
>
> Some issues have a large scope and would require a re-design of certain
> classes (e.g. MATH-765 and related), not to be implemented in a minor
> release.
>
> Please review all issues (especially those assigned to you, or reported by
> you, or where you took an active part in the discussion) and provide
> feedback on their "currentness".
Since a few weeks, I am working on the differentiation API (it was
surprinsingly difficult to implement Dan Kalman's paper efficiently).
The core part is almost ready, as per Julien and Phil comments. I hope
to commit a first working set in a few days now.
I would like to have this API and some preliminary implementations
included in 3.1. The ones I would like to have are the basic building
blocks supporting direct implementation by user and finite differences
at least for small derivation orders.
Luc
>
>
> Thanks and best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org