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.
With best regards, Alexander Nozik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
