Inefficiency caused by current Mode scheme #1

ekmett opened this Issue Jun 26, 2010 · 3 comments


None yet

3 participants

ekmett commented Jun 26, 2010

The current entangling of the concepts of Mode and infinitesimal mean that every user of the AD library has to dispatch virtually everything that want to do with an AD variable via a dictionary. While this provides unusually strong guarantees, that only the properties that AD s a inherits from Mode s and the underlying numeric type a can be used, it means that the resulting code can be considerably slower than would be otherwise possible.

We could adjust AD to have separate mode and infinitesimal attributes, and adjust UU, UF, FU, FF to have MUU MUF MFU MFF variants that accept a mode, so that most of the combinators do the right thing. The cost of this is that we need to be more careful about all the extraneous instances that our Modes have picked up, and which properties we allow AD to inherit.

To obtain something approximating the current level of safety, we'll have to remove a lot of current instances and hide the AD data constructor.

@alang9 alang9 closed this Mar 12, 2013

This might just be me not quite understanding some of this, but does the past days pull request also address the safety issue alluded to in this ticket? The Types have all been generalized/modified, but I don't see any changes in whats exported. Is the api safety matter superfluous?

ekmett commented Mar 13, 2013

We still need to go through and make sure most of the more egregious out-of-scope behavior is managed correctly. I haven't done a sanity check pass yet, which is why it hasn't been released to hackage.

@alang9 alang9 reopened this Mar 13, 2013
ekmett commented Mar 30, 2014


@ekmett ekmett closed this Mar 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment