search

microsoft / knossos-ksc

Compiler with automatic differentiation
Other
45 stars 10 forks source link

Rename module entry points #947

Closed dcrc2 closed 3 years ago

dcrc2 commented 3 years ago

This PR renames the pybind entry points to be ~forward and backward~ entry and entry_vjp irrespective of whether LM AD is used. (Previously the backward entry point was either rev_entry or sufrev_entry.)

In particular, for the embedded C++ examples, this means that any two C++ functions can be used as the entry points. I've removed the generate_lm parameter from cpp_string_to_autograd_function, which didn't really make sense in this context as nothing is being generated.

In order for this to work, the embedded C++ examples need to have C++ functions with the correct names (entry and entry_vjp). I've done this here by adding trivial forwarding functions with the correct name, rather than by changing the existing names. This is done with PRs #925 and #931 in mind: the forwarding function will need to do a little more work when those PRs are merged. I'm intending to rebase those PRs onto this one.

Note that these changes mean that we no longer generate an entry point for [fwd f] when LM AD is requested. I don't think we were actually using this anywhere.

awf commented 3 years ago

I've just realised I've named these badly, sorry.

"Forward" should really be reserved for "compute the function, and anything else needed for a subsequent backward"

[edited:] I think now we should call the entry points "func", and "func_vjp". (Or indeed "entry" and "entry_vjp").

Then KscAutogradFunction can decide to make use of them in its "forward" and "backward" pending #768

dcrc2 commented 3 years ago

I think now we should call the entry points "func", and "func_vjp". (Or indeed "entry" and "entry_vjp").

OK, renamed to entry and entry_vjp.