4 ms·

At the end of the day, if you are storing inputs and outputs to a function as a pair of numbers - one for the actual value, and one for the derivative - and if

At the end of the day, if you are storing inputs and outputs to a function as a pair of numbers - one for the actual value, and one for the derivative - and if addition and multiplication work the way you expect and propagate derivatives correctly - then you are using dual numbers, regardless of if you notate it a + b*h or {"value": a, "derivative": b}. Pytorch does things slightly differently in that it is mostly focused on reverse-mode autodiff, and so it stores adjoints relative to the overall output rather than partial derivatives relative to the input, but this isn't really an entirely different thing, in the same way that the FFT isn't entirely different from the DFT. There seems to be some confusion about the relationship between dual numbers and smooth infinitesimal analysis. Both have nilpotent elements, but with dual numbers the background logic is classical, whereas it isn't with smooth infinitesimal analysis. EDIT: I see you've edited your post to try to get in some extra criticism after I've already responded. That's terrible form, so I'll just respond here. Dual numbers are a nice way to get started with forward-mode autodiff, to which it is so related that the two are essentially the same thing with different labels. Pytorch instead uses reverse-mode autodiff. Reverse-mode and forward-mode autodiff are different, but not so different that they are entirely different things. Reverse-mode is, as I put it in my OP, "not much more advanced" than forward-mode, even if not identical. What is entirely different, much more advanced, and what Pytorch really doesn't do, is anything like the "epsilon-delta proofs" you keep hanging your hat on. If Pytorch did that, it would be useless. The entire point of autodiff is to avoid such things. Beyond that, I would suggest slowing down a bit as you are mixing quite a few things up. Nonstandard analysis has nothing to do with dual numbers at all, for instance. And you're very much misinterpreting that MSE post of mine you linked to (thanks!).

fpgamlirfanboy 3y ago
> and if addition and multiplication work the way you expect and propagate derivatives correctly - then you are using dual numbers you literally started out your miraculous comment with > This new algebra is called the ring of "dual numbers." The difference is that instead of adding a new element "i" with i² = -1, we add one called "h" with h² = 0! not some observation about caching derivatives. so i'll repeat myself for the 3rd time: there are no magical numbers anywhere in pytorch or tensorflow or cafe or any other serious autodiff implementation that abide by the rules you so jubilantly exclaim about.
- MikeBattaglia 3y ago
  Thank you for repeating yourself three times. It seems like you think that the dual number algebra involves "magic woo numbers." It seems like you haven't really worked through this stuff too much. I would suggest reading some of the resources above, such as the MIT lecture series. The rest of your points I think I have already addressed, though you ignored in your reply - I've said Pytorch does reverse mode diff several times at this point.
  - fpgamlirfanboy 3y ago
    > It seems like you haven't really worked through this stuff too much yup not at all - i just wandered in off the street and knew accidentally that you were talking about non-standard analysis. > The rest of your points I think I have already addressed please show me the source line number in pytorch or tensorflow that defines this number > we add one called "h" with h² = 0!
    - samatman 3y ago
      You seem somewhat obsessed with the idea that reverse-mode autodiff is not the same technique as forward-mode autodiff. It makes you,,, angry? Seems like such a trivial thing to act a complete fool over. What's up with that? Anyway, here's a forward differentiation package with a file that might interest you https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/dual.jl https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/...
      - fpgamlirfanboy 3y ago
        it's amazing to me that pointing out a straight up mathematically factual inaccuracy is considered "angry" and "acting a fool".
        samatman 3y ago
        > there's a reason no one uses dual numbers (non-standard analysis) for anything (neither autodiff nor calculus itself) wrong > there are no [dual] numbers anywhere in [...] any other serious autodiff implementation wrong > please show me the source line number did > i'm wrong and this other guy is right correct. > this is why i hate this kind of "TIL, gee whiz" math tidbits acting a fool. angrily so.

fpgamlirfanboy 3y ago

> and if addition and multiplication work the way you expect and propagate derivatives correctly - then you are using dual numbers you literally started out your miraculous comment with > This new algebra is called the ring of "dual numbers." The difference is that instead of adding a new element "i" with i² = -1, we add one called "h" with h² = 0! not some observation about caching derivatives. so i'll repeat myself for the 3rd time: there are no magical numbers anywhere in pytorch or tensorflow or cafe or any other serious autodiff implementation that abide by the rules you so jubilantly exclaim about.

MikeBattaglia 3y ago
Thank you for repeating yourself three times. It seems like you think that the dual number algebra involves "magic woo numbers." It seems like you haven't really worked through this stuff too much. I would suggest reading some of the resources above, such as the MIT lecture series. The rest of your points I think I have already addressed, though you ignored in your reply - I've said Pytorch does reverse mode diff several times at this point.
- fpgamlirfanboy 3y ago
  > It seems like you haven't really worked through this stuff too much yup not at all - i just wandered in off the street and knew accidentally that you were talking about non-standard analysis. > The rest of your points I think I have already addressed please show me the source line number in pytorch or tensorflow that defines this number > we add one called "h" with h² = 0!
  - samatman 3y ago
    You seem somewhat obsessed with the idea that reverse-mode autodiff is not the same technique as forward-mode autodiff. It makes you,,, angry? Seems like such a trivial thing to act a complete fool over. What's up with that? Anyway, here's a forward differentiation package with a file that might interest you https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/dual.jl https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/...
    - fpgamlirfanboy 3y ago
      it's amazing to me that pointing out a straight up mathematically factual inaccuracy is considered "angry" and "acting a fool".
      - samatman 3y ago
        > there's a reason no one uses dual numbers (non-standard analysis) for anything (neither autodiff nor calculus itself) wrong > there are no [dual] numbers anywhere in [...] any other serious autodiff implementation wrong > please show me the source line number did > i'm wrong and this other guy is right correct. > this is why i hate this kind of "TIL, gee whiz" math tidbits acting a fool. angrily so.