ANN: Anyone need my 2.7x faster factorial (or gamma) function?


Cool, thanks for explaining. I didn’t realise an un-called throw could cost so much – seems like this would affect many things?

Sprinkling @inline around & testing is however a task within my pay grade, which I did not perform. Is inlining also the reason that @btime factorial() is failing to see differences that @btime map!(...) shows?


You must have been looking at an old commit; the PR already has a look-up table for all 171 integers (ignore most of the “discussion” there, just what I discovered along the way speaking to myself and some “discoveries” tuned out wrong, nobody seems to be reading/reviewing or merging there at the moment):

Right, that was my original goal to get it to be fast; and hopefully with it still at the top of the function. You may want such exceptional cases there for readability (“design-by-contract”). It’s just that in the assembly you don’t want it first, or even in the same function. I was thinking something like Match.jl might eventually handle such and make good code, if Julia compiler itself doesn’t figure out.


Possibly because

  1. the original PR was closed, so the threat of breaking SpecialFunctions is not that imminent,

  2. it requires quite a bit of investigation to find out the rationale for this PR.

You should compose the PR message so that a person reading it for the first time, unaware of any context or history (these can be referenced later), can understand

  1. the motivation (why change)
  2. the implementation (what changed),
  3. and the benefits.