I have no idea why, but for some reason, the overall factor of NN[i,j] inside the sum is causing an issue. I think this is a bug. Distributing this factor over the term inside seems to make it work—but it's a bit worrying that this happens! Might be worth submitting feedback about it, and maybe someone else here might have better insight and a more robust workaround.
A workaround
In the meantime, here's an ad-hoc workaround: define a helper function to Expand the first argument of any sums in the expression, and apply that to e first.
ExpandSums[expr_] := (expr /. (Sum[x_, y__] :> Sum[Expand[x], y]))
D[ExpandSums[e], g[i]]
(Note that the summation index i will be replaced with K[1], as it should, lest the outer i explicit in D[ExpandSums[e], g[i]] interfere with the one inside e!)
Make the workaround automatic
If you want to make the above application of ExpandSums happen automatically each time you evaluate D—and effectively "build it into the definition of D"—you can do so with the following trick (which is for preventing the definition from being applied recursively forever):
Unprotect[D];
interceptDDef = True; Protect[interceptDDef];
D[x_, y___] :=
Block[{interceptDDef = False}, D[ExpandSums[x], y]] /; interceptDDef
Protect[D];
(* Test *)
D[e, g[i]]
(This trick is not original to me; it's been known for a long time! I think it's even mentioned in this book.)
More info on why this is happening:
It seems to not be a problem of Mathematica's differentiation, but of how Sum and KroneckerDelta interact and automatically expand to strange piecewise expressions.
Consider
Sum[KroneckerDelta[i,k], {i, 1, n}]
The above input is obtained as an intermediate expression, I believe, in evaluating
D[Sum[a[i], {i, 1, n}], a[k]]
We can see that this is the case by inactivating KroneckerDelta:
Block[{KroneckerDelta = Inactive[KroneckerDelta]}, D[Sum[a[i], {i, 1, n}], a[k]]]
A minimal case exhibiting the problem you've brought to attention seems to be
expr = Sum[f[i] (a[i] + a[j]), {i, 1, n}, {j, 1, n}];
(* Causes Mathematica to hang: *)
D[expr, a[k]]
The same issue seems to be happening:
ok = Block[{KroneckerDelta = Inactive[KroneckerDelta]}, D[expr, a[k]]]
(* Out: an expression involving KroneckerDelta's! *)
And Mathematica effectively hangs when re-activating the KroneckerDelta's:
(* Hangs: *)
Activate @ ok
So, it seems like that's where the issue "really" is. I'm not sure yet how to turn automatic expansion of Sums of KroneckerDelta's into piecewise functions off...
Another bug to watch out for!
Note that using a Method option for Sum is inappropriate here, as for some reason—quite unexpectedly—D can't handle differentiation with respect to composite symbols (e.g. a[i] as opposed to just a) for Sums with a Method value, even Automatic! Contrast
D[Sum[a[i],{i,1,n}], a[k]]
D[Sum[a[i],{i,1,n},Method->Automatic], a[k]]
Now consider—a worse bug—the following:
D[Sum[a[i],{i,1,n},Method->Automatic], a[i]]
It seems Mathematica doesn't know how to perform the alpha-conversion needed for the Sum in this case, and misinterprets a[i] as unbound by Sum, and uniform across all i.
I'm going to submit a separate ticket for this, but thought it was worth it to warn you off using Methods in symbolic sums, as apparently doing so is buggy when it comes to differentiation.
SubscriptandOverscripts in expressions. They look pretty, but they make a mess of everything else. Use e.g.g[i]instead of Subscript[g, i] – MarcoB Nov 11 '21 at 22:38II[I,j]orII[i][j]? – PManjunatha Nov 11 '21 at 23:08Method -> "Procedural"to yourSumhelps? See https://mathematica.stackexchange.com/questions/250239/slow-sum-with-subscripts/ – Chris K Nov 12 '21 at 02:02a[i, j]instead ofa[i][j]if only for the reason that built-ins likeArrayconventionally give generalize from one argument to two arguments in the first manner instead of the second (test outArray[a, {2,2}])! – thorimur Nov 12 '21 at 02:07i(I) in the original expression is a built-in symbol meaning the imaginary unit. It will not be treated as a variable (usually). – thorimur Nov 12 '21 at 02:311/2instead of0.5when doing symbolic reasoning; numbers entered in decimal format are treated as inexact machine numbers, and certain simplifications you might want to do later might not work as expected, as the presence of0.5will automatically convert symbolic mathematical constants likePiinto approximate numeric form! – thorimur Nov 12 '21 at 02:35Dgi = D[e, Subscript[g, i]]instead of Dgi = D[e, Subscript[g, I]]. – Akku14 Nov 12 '21 at 07:29