LogLayer

[jeffdonahue]

This adds LogLayer, a NeuronLayer, which by default takes the natural log of its inputs. It's designed analogously to ExpLayer and PowerLayer. (In general computes log_{\gamma}(\alpha x + \beta) with log_param { base: \gamma scale: \alpha shift: \beta }.)

[longjon]

@pannous I do think LogLayer is the best name here; we have ExpLayer, not ExponentiationLayer, log is the commonly used mathematical abbreviation, Caffe has distinct mechanisms for logging and an existing nomenclature for output layers.

[longjon]

I kinda prefer the name log here, sticking with the name of the elementwise call, but either one is okay...

[jeffdonahue]

not my choice -- the MKL function is vsLn/vdLn.

[longjon]

Oh. :(

[longjon]

This looks good to me as a counterpart to ExpLayer.

As a more general issue affecting both of these, however, I wonder if this is the best way to resolve the tension between granularity and functionality. As far as I can tell, these layers could just implement simple exp and log, with scale and shift factored out (in-place, if desired), and with base changes factored out, as that's how the implementations work already...

[jeffdonahue]

@longjon yeah, I put the shift/scale fields in to match the existing Exp and Power layers and because in my own usage I often end up wanting them, but, especially with your Python layer specs making it more convenient to do compositions of simpler layers, it might be time to factor them out (i.e. create ShiftLayer and ScaleLayer and remove those fields from Exp, Power, and Log). I guess my preference would be to merge this as it's consistent with what we have now, then follow up with (or let someone else follow up with...) that refactoring later, but maybe it's better to not add to the existing mess -- I'll leave that up to you.

[shelhamer]

Looks good to me.

it might be time to factor them out (i.e. create ShiftLayer and ScaleLayer and remove those fields from Exp, Power, and Log). I guess my preference would be to merge this as it's consistent with what we have now, then follow up with (or let someone else follow up with...) that refactoring later

This is fine. It could make for a nice warm-up PR in the future.

@jeffdonahue rebase and merge away.

[jeffdonahue]

Thanks for the review @shelhamer and @longjon!