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/MATH1452
> (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/MATH1448 and partially
> MATH1452:
>
> https://bitbucket.org/Altavir/dataforge/src/1433da0d2f19ab26d709de8750e002847a4b4887/dataforgemaths/src/main/kotlin/hep/dataforge/maths/expressions/AD.kt?at=ad&fileviewer=fileviewdefault
>
> 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 MATH1448 (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 floatingpoint 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/dataforgemaths/src/main/kotlin/hep/dataforge/maths/expressions/AD.kt?at=ad&fileviewer=fileviewdefault#AD.kt78.
> 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/dataforgemaths/src/test/java/hep/dataforge/maths/expressions/ADTest.kt?at=ad&fileviewer=fileviewdefault.
> 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, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
