[krastanov]

Presumably the Ad package has a list of known derivatives. The Sym package now "automatically" uses it, without ever having to have known of it.

The "coordination" is that they both use the "symbol" sin to refer to the idea of sine function.

[shele]

Interesting that is is this way in Haskell in this example: In Julia, there are community/consensus-based processes to what the "idea" of a symbol is (or rather, the idea of a function with its current methods and its future methods defined for new types) and package interoperability often works in a similar way.

[leephillips]

There is some confusion about what a symbol is in Julia due to bad tutorial information floating around the web. Here is Stefan Karpinski’s masterful explanation of what a Symbol really is:

https://stackoverflow.com/a/23482257

[krastanov]

As the sibling comment mentioned, this thread started using the word "symbol" in two different ways. There is the Julia/Lisp/Ruby use of the word symbol which is related to representing code in code and to homoiconicity. That is discussed in the sibling stack-overflow link.

Earlier in this thread though "symbol" was used in a less formal, handwavy way as "a named handle to some concept in the language". In that sense, indeed, the way that Julia adds multiple methods to a single named function and supports multiple dispatch permits amazing interoperability (and has little to do with Julia/Lisp/Ruby symbol datastructures).

[shele]

Right, my point is just: As new methods are added by the owners of new types it requires a common understanding and community consensus how a function should act on new types (i.e. about the "idea" of the function.)

[magicalhippo]

Right, I was confused because for some reason I imagined "sin" coming from the symbolic library, but I'm assuming it's just built-in so AD knows about.

[cryptonector]

The `sin` function comes from this bit at the end of TFA:

    instance VectorSpace d => Floating (Dual d) where
      pi             = D pi zero
      exp   (D u u') = D (exp u)  (scale (exp u) u')
      log   (D u u') = D (log u)  (scale (log u) u')
  --->sin   (D u u') = D (sin u)  (scale (cos u) u')
      cos   (D u u') = D (cos u)  (scale (-sin u) u')
      sinh  (D u u') = D (sinh u) (scale (cosh u) u')
      cosh  (D u u') = D (cosh u) (scale (sinh u) u')

and the `sin` function on the right-hand side comes from `Float`, since `Float` is the type of the argument `u` in `sin u` in `D (sin u) (scale (cos u) u')`.

[krastanov]

Not quite. This subthread is about the extremely short, one-line implementation mentioned here https://news.ycombinator.com/item?id=32882825 (which merges two unrelated modules (autodiff and symbolic) and uses autodiff to implement symbolic differentiation). Your comment is true for the original 38-line implemention of autodiff at the very top of the thread, but not in this subthread. The 38-line implementation is similar to the aforementioned autodiff module though.

[pfortuny]

However, if the symbolic package knows that

cos(a+b) == cos(a)cos(b) - sin(a)sin(b)

then it works.

Something must be known in advance about the relationship between sin and cos for addition, otherwise you cannot go from one to the other (and the basic

cos(a)^2+sin(a)^2=1

is not enough for that.

[cryptonector]

Yes, indeed, I was referring to TFA, and obviously I was confused.