From dev-return-166446-archive-asf-public=cust-asf.ponee.io@commons.apache.org Mon Feb 19 03:41:48 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 7315818064D for ; Mon, 19 Feb 2018 03:41:47 +0100 (CET) Received: (qmail 10939 invoked by uid 500); 19 Feb 2018 02:41:46 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 10923 invoked by uid 99); 19 Feb 2018 02:41:45 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Feb 2018 02:41:45 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 05CC6C00CA for ; Mon, 19 Feb 2018 02:41:45 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id ZjTLs17R_WRy for ; Mon, 19 Feb 2018 02:41:42 +0000 (UTC) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 53F845F58D for ; Mon, 19 Feb 2018 02:41:42 +0000 (UTC) Received: by mail-it0-f44.google.com with SMTP id a75so874288itd.0 for ; Sun, 18 Feb 2018 18:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=dvlpIXpavwhDsK9/N5+f9Ix9BTO3zR6fM6O3lQohdsU=; b=c3M8+aAxYIGsctpdV83SSBGFzKoIoMGed1HUC5lmlMa6AomNARB61D5hnsZT3lA9zJ ymh/6rPU4kU5VvRGV5A54gU4ow/Uggc6hbmRTSv41qhmNZDD7rjcyDfpy9LWv6ABTAAM fXUcVKFGGSzPVARPCGLVf3SvB6IaxDHhj4/iscttJSrMnQtA94ZNAK8y/LB6TjGK82mu 5dxPD/+SIj6Aza8cWjO01pudEdewrOLMcc3noDsY3wt18jy4ESUETyPDy0Tb3u1STv4d vZRNCM6oEENJweGoaz5++NNUjtcnVXkpw5ZPv+JWuYfcGONANV97Y/MHRvTay5BqhcAh of3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=dvlpIXpavwhDsK9/N5+f9Ix9BTO3zR6fM6O3lQohdsU=; b=CbcrISbFR+PN347dgxHKnYK308vuMUZOVYRdTclE/0t/Pj1YvwBj1qhX3/Sp95DrEp KE/qNLmRKo5nuJaIofK9WwnEuX+o9bHW4w+Dti4qvQecdu3eUjEm81eVXaOmlh52P7lk 3uVwrT5Zau9smgV3mTRpZwZ7iLiEkwlsz7lDyz7UJJsLLRd0so2rUcug6j3gVKioq0Ks zItN4m0mxqUewurXWF1mtGtfLTefHePA3ovaKaZfvnqZjbbzICNYWZscETn4eACq3Ywq 4SnNmR9EQtirc1CdZtmrdGDHoJSPIoBXhD0J0J1spejC6bvTDq8u0Y0Q5FEaNh1Diw9w x1EQ== X-Gm-Message-State: APf1xPDhHqkALV9qs+2BLWL09BI9FTWRAr17a/6WAp7WZBDd9Z2b4iph j03AYZMQ3tI5jrt4Zaf9njxDJmAynSlC4DFG7yI= X-Google-Smtp-Source: AH8x226akuXCt1N3COcnO1G/Uz8xDeleZxuJFUBUTPVVZNw0NotwkrperLYr643KnM2ds1FRPgjj8BhPTdKHm+u1Swg= X-Received: by 10.36.204.138 with SMTP id x132mr18429104itf.88.1519008095681; Sun, 18 Feb 2018 18:41:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.197.138 with HTTP; Sun, 18 Feb 2018 18:41:35 -0800 (PST) In-Reply-To: <0f44658335d6ebe8320f24cdd35c093c@scarlet.be> References: <0a21e40a-e2ef-fae5-e4ff-182beb45fcf4@gmail.com> <0f44658335d6ebe8320f24cdd35c093c@scarlet.be> From: Matt Sicker Date: Sun, 18 Feb 2018 20:41:35 -0600 Message-ID: Subject: Re: [math] Automatic differentiation with names To: Commons Developers List Content-Type: multipart/alternative; boundary="94eb2c05b23ef440a8056587a1b7" --94eb2c05b23ef440a8056587a1b7 Content-Type: text/plain; charset="UTF-8" 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 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-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > -- Matt Sicker --94eb2c05b23ef440a8056587a1b7--