A friendly Introduction to Backpropagation in Python

Post by badminton1 » Mon, Nov 27, 2017, 4:01 AM UTC

sushantc wrote: post #8

badminton1 wrote: post #6

Some suggestions: 1) I would make a better distinction between the function declaration and the program output. e.g: format the output differently. like gray. 2) Capitalization. "InvalidWRTargError". It would help if you could capitalize it as "InvalidWrtArgError". This is a guideline in most coding standards. https://en.wikipedia.org/wiki/Camel_case#In_abbreviations 3) Better naming: - "getNumericalForwardGradient":…

Thanks partycoder! Points taken; will make some changes. Regarding numerical gradients, named it so to differentiate it from analytical gradients, which leverage formulas from calculus. The "numerical" ones are calculated using (f(x+h)-f(x))/h every time.

Post by badminton1 » Mon, Nov 27, 2017, 6:59 AM UTC

ydidntithnkftht wrote: post #10

sushantc wrote: post #8

Earlier quoted context omitted.

Thanks partycoder! Points taken; will make some changes. Regarding numerical gradients, named it so to differentiate it from analytical gradients, which leverage formulas from calculus. The "numerical" ones are calculated using (f(x+h)-f(x))/h every time.

Python community conventions are not camel case for functions... forwardAddGate would be forward_add_gate and return is not a function call... return(max(x,y)) or return(x+y) would be return max(x, y) or return x + y spaces around operators... x + y not x+y spaces around function args... def foo(a, b) not def foo(a,b) and when calling... foo(1, 2) not foo(1,2) https://www.python.org/dev/peps/pep-0008/ Just things to…

Post by gspetr » Mon, Nov 27, 2017, 12:33 PM UTC

kamyarg wrote: post #14

My eyes hurt. https://www.python.org/dev/peps/pep-0008/