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.
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
>
>
--
Matt Sicker <boa...@gmail.com>
