Hi.
On Sat, 17 Feb 2018 19:25:30 +0300, Alexander Nozik wrote:
Hello all,
Gilles suggested that I should write some considerations about
improvement to common maths automatic differentiation here. I've
opened an Issue here: https://issues.apache.org/jira/browse/MATH-1452
(I really do not like mailing lists). But since I've done my own
implementation on top of Commons Maths, I can share it.
Thanks a lot for the offer.
I hope that we'll agree on a common path to make the
AD functionality easy to use.
The
implementation is in Kotlin, so I won't be able to contribute it to
commons math as is, but still we can discuss how to backport it to
java.
I think that a working Java implementation is a requirement for
inclusion in the "Commons" project.
[Discussing contribution in another language would require its
own ML thread (yes, the "dev" ML is still the only official
channel for decisions).]
Here is the source code of two classes which solve
https://issues.apache.org/jira/browse/MATH-1448 and partially
MATH-1452:
https://bitbucket.org/Altavir/dataforge/src/1433da0d2f19ab26d709de8750e002847a4b4887/dataforge-maths/src/main/kotlin/hep/dataforge/maths/expressions/AD.kt?at=ad&fileviewer=file-view-default
The class on the top is a Context for mathematical operations with AD
numbers. Since CM already have Fields, it implements the Field.
I have a problem with the CM "Field".
Did you have a look at my comments to issue MATH-1448 (and related
code)?
Unfortunately, I don't have the time right now to go further with
that work; but I'm more and more convinced that something is wrong
with the current design of "Field": if the requirement is to have
and API that provides
* addition (and its neutral element)
* multiplication (and its neutral element)
* some other functions that allow for more performant
implementations of common opreations
why not just define one or more interfaces to that effect?
[Unless I'm mistaken the most used "field" is the "RealFieldElement"
with its implementation over "double". Given the inherent inaccuracy
of floating-point numbers, they actually do not abide by the (math)
field requirements.]
The
idea is that context stores some critical properties of numbers which
are shared between instances like order of differentiation and
parameters names. In this case the object equality check used instead
of instance equality, so to context with same orders and set of names
are still equal. The AD class below is just a wrapper for
DerivativeStructure that also includes Field context. Binary
operations additionally perform check if argument uses the same
context as `this` object.
Hard to follow without being able to see it working...
Are you willing to port to Java? And it seems that
we have to first solve the "Field" issue (or can we
do without; i.e. make the enhancement assuming "double"
everywhere?).
The actual check occurs here:
https://bitbucket.org/Altavir/dataforge/src/1433da0d2f19ab26d709de8750e002847a4b4887/dataforge-maths/src/main/kotlin/hep/dataforge/maths/expressions/AD.kt?at=ad&fileviewer=file-view-default#AD.kt-78.
In theory, one can perform field transformation, merging parameters
sets from both ADs, but it requires understanding about inner
workings
of DerivativeStructure which I lack. Basically what I need is an
ability to create a new DerivativeStructure with parameter number i
mapped to number j.
The proposed solution does not seem to involve any major performance
impact.
It would be nice if JMH benchmarks could confirm it.
[But this is not a priori requirement as far as I'm concerned, if
the usability improvement is worth it.]
Name resolution happens only when one calls derivative with
given name and is not really a great performance impact since string
hashes are calculated on string creation. The only place with actual
performance impact is when field transformation happens (if it will
be
implemented), but this transformation is supposed to be rare and it
currently not possible at all.
?
I'm lost here; sorry. :-{
The test code in kotlin looks like this:
https://bitbucket.org/Altavir/dataforge/src/8131099f29ebf27fb170ace037cda61df9790fc2/dataforge-maths/src/test/java/hep/dataforge/maths/expressions/ADTest.kt?at=ad&fileviewer=file-view-default.
It is kotlin though, it would be much more verbatim in java. I plan
also to implement expressions which would allow lazy calculations of
AD structures like (NamedVector)->AD. This one could be more or less
easily done in Java.
Good (but I don't understand what you mean!).
Best regards,
Gilles
With best regards, Alexander Nozik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
