On Mon, 19 Feb 2018 15:17:34 +0300, Alexander Nozik wrote:
You got me wrong again.
What did I get wrong?
Kotlin is fully compatible with java and
usually one converts Java code to Kotlin, which is done
automatically.
Unless I'm totally off base, I guess a code written in Kotlin
needs specific support (e.g. a library dependency) to be run
on a JVM.
If so, one question is whether it is advantageous to use that
Kotlin rather than pure Java (and do without the additional
library).
But I can convert kotlin code back to Java.
Is it a one-time port (and thereon, maintenance is done on the
Java code)? Or do you mean a conversion step (as part of the
build for example) that creates Java sources (or bytecode) so
that maintenance requires coding in Kotlin?
Commons math does not
support newer versions of JVM with functional features,
My latest suggestion is to target Java 8.
so for now it
easier to think in kotlin,
Not for me. :-}
I can imagine it has interesting features for those who
use it. But are those indispensable for the project we
are talking about?
and then produce Java6 compatible
classes.
Do you have a requirement to use Java 6?
Gilles
On 19.02.2018 14:29, Gilles wrote:
On Sun, 18 Feb 2018 20:41:35 -0600, Matt Sicker wrote:
We've even talked about adding Scala libraries in the past and
there was
support, so I'd imagine Kotlin is fine as well. It may be worth
including
as its own module mainly due to the Kotlin dependency, though the
domain
itself helps raise it to that level as it is.
IIUC, the core engine is CM's "DerivativeStructure" and "DSCompiler"
classes; hence, it would seem (?) overkill to add a dependency that
will then require a conversion layer in order to be called from
Java.
Regards,
Gilles
On 18 February 2018 at 18:02, Gilles <gil...@harfang.homelinux.org>
wrote:
On Sat, 17 Feb 2018 22:30:38 +0300, Alexander Nozik wrote:
On 17.02.2018 21:16, Gilles wrote:
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.]
You got me wrong here. These methods are made only for better
user-side API. Kotlin allows to use classes as receivers (run a
lambda
function, using objects as a context), therefore it sometimes
makes
sense to create a scope class and add some additional
functionality to
it. It does not matter though since I already removed all those
methods into separate extension class (after back porting to java
they
will be either static members or won't be needed at all). Also, I
can
use any custom class for the context, it does not have to be
RealField
itself.
I've finally found the code you were talking about. And those new
fields indeed look much better than RealFieldElements. I totally
agree
that special functions like `sin` etc should be removed form the
interface and implemented as a static class like java.util.Math
(it
would be good just to copy Math contents, so switching from one
type
of numbers to another will require simple change of imports).
I can translate my work back to java when I am done, but it still
requires two changes to DerivativeStructure API (at least in its
current API) to work better:
1) The Derivative structure should have an additional field with
names of parameters. In the current implementation it seemed to
me
reasonable to use RealField instance since DerivativeStructures
with
different orders and different set of parameters are members of
different fields. So Fields themselves should be parametric. In
case
of new Field API I think that DerivativeStructure should have an
internal object, call it Signature for example, which will store
the
same information. I can do that myself and post a pull request
when I
am done.
2) Those RealFields or Signatures could be transformed along with
underlying DerivativeStructures therefore allowing to merge two
AD
numbers with different signatures into a new number with
completely
new signature. In order to do so, I need a method inside the
DerivativeStructure to change the numbering of parameters and add
new
parameters (with zero derivatives). Derivative structures are
just
linear structures so it should not be hard, but I am not sure
that I
will be able to spend enough time on it to understand, how it
works.
One final remark. We've got an idea we will try to implement in
the
future. The idea is to use the same API to create a syntactic
trees
from expressions. It is needed to send a definition of some
function
to another process or other the internet. In theory, I do not see
any
differences in implementation, so I think that you should keep
this
feature in mind. It would be great to be able to just replace one
type
for another and get the whole new functionality.
I do not have in-depth knowledge of the current code in order to
figure out the implications.
Please implement whatever enhancements you have in mind.
Actually, I'd suggest that we create a new module in "Commons
Numbers": "commons-numbers-autodiff".
It would host the refactoring of "DerivativeStructure", using JDK8
("java.util.function") and trying to get rid of
"RealFieldElement",
seeing how it will impact the unit test suite (and your
use-cases).
WDYT?
Thanks,
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