On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug <fgp@phlo.org> wrote:
On Jan20, 2014, at 08:42 , David Rowley <dgrowleyml@gmail.com> wrote: >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug <fgp@phlo.org> wrote:
>> * I've also renamed INVFUNC to INVSFUNC. That's a pretty invasive change, and
>> it's the last commit, so if you object to that, then you can merge up to >> eafa72330f23f7c970019156fcc26b18dd55be27 instead of >> de3d9148be9732c4870b76af96c309eaf1d613d7. > > > Seems like sfunc really should be tfunc then we could have invtfunc. I'd probably > understand this better if I knew what the 's' was for in sfunc. I've not applied > this just yet. Do you have a reason why you think it's better?
My issue with just "invfunc" is mainly that it's too generic - it doesn't tell you what it's supposed to be the inverse of.
I've always assumed that 's' in 'sfunc' and 'stype' stands for 'state', and that the naming is inspired by control theory, where the function which acts on the state space is often called S.
Ok, that makes more sense now and it seems like a reasonable idea. I'm not not quite sure yet as when someone said upthread that these "negative transition functions" as I was calling them at the time should really be called "inverse transition functions", I then posted that I was going to call the create aggregate option "invfunc" which nobody seemed to object to. I just don't want to go and change that now. It is very possible this will come up again when the committer is looking at the patch. It would be a waste if it ended up back at invfunc after we changed it to invsfunc.
