Naming convention of iterated binary operation
Dear list entities, is there such a convention or precedent for naming an iterated binary operation? For example, Boost.Functional/Hash has an iterated hash() called hash_range(). I don't mind the "_range" suffix but I prefer the "iterated_" prefix based on the mathematical definition: https://en.wikipedia.org/wiki/Iterated_binary_operation The case in point is gcd() in Boost.Math: we want to provide an iterated gcd but we can't quite decide how to name it. I like the "iterated_" prefix but I would rather go with whatever might be the convention. Thanks, cheers. Jeremy
On May 1, 2016 11:25:39 PM EDT, Jeremy Murphy
Given that the definition you linked noted only a couple of cases using different names for iterated variants and a couple of cases that use the same name as for the non-iterated function, it isn't clear that there is a case for preferring that modifier. (I'm no mathematician, so I have no experience to draw upon here.) In C++, given overloading, it isn't necessary to use a different name for different arguments. Therefore, I wonder whether "gcd" is sufficient for the iterated case. ___ Rob (Sent from my portable computation engine)
On 2 May 2016 at 18:20, Rob Stewart
Yes, I haven't searched far and wide for examples yet. I like the "iterated_" prefix because it seems the most universal or generic in meaning: it's not actually specific to C++ even though we have "iterators". That's just my personal preference, not what I think is necessarily the best answer. In C++, given overloading, it isn't necessary to use a different name for
different arguments. Therefore, I wonder whether "gcd" is sufficient for the iterated case.
Indeed, this is an interesting point and I thought about it for some time already. My (strong) feeling is that functions with different semantics should have different names, but I don't have a formal or strong argument to support this. I know we can use the same name but it doesn't seem like a good idea apart from minimizing the number of names in a namespace. A variadic template version with the same name makes sense to me, though. Cheers. Jeremy
On 3 May 2016 at 05:19, Rob Stewart
Only in the type signature. It's fairly obvious but I'll make it explicit. Variadic gcd takes n things of type T and returns a T: f(T, ..., T) -> T whereas "iterated" gcd takes a thing (Range) or things (iterators) that denote a range of Ts: g(U) -> T g(U, U) -> T So yes, in the implementation, variadic gcd is an iterated binary operation (with special case of n=1). But the semantics are different because of how the input is interpreted, which for me is sufficient reason to give them different names. So it's probably more accurate that I say it's gcd over an iterator range that I think should have a different name to 'plain' gcd (which is iterated in a variadic version). Which makes the "_range" suffix all the more sensible. Cheers. Jeremy
On May 3, 2016 1:37:22 AM EDT, Jeremy Murphy
I see the range-based variants as obvious, without special naming, because the only logical semantic is to iterate the range of values. If adding a modifier helps with overloading, then I do like the "_range" suffix far more than your "iterated_" prefix, FWIW. ___ Rob (Sent from my portable computation engine)
Dear list entities,
FWIW, and you might already know that, but the functions F_l and F_r in the Wikipedia article you linked are sometimes called F_l: fold_left foldl fold accumulate F_r: fold_right foldr reverse_fold This is probably a personal bias from mathematics, but using the iterated_ prefix makes me think that it could be this kind of iteration hash(hash(hash(hash(x)))) Of course the above makes no sense for a binary operation, but this is what the name alone means to me. Bottom line: I don't think there's a convention, and if there's one, it's not well known. Good luck, naming is hard :-) Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Naming-convention-of-iterated-binary-oper... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (3)
-
Jeremy Murphy -
Louis Dionne -
Rob Stewart