Naming convention of iterated binary operation

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Naming convention of iterated binary operation

Jeremy Murphy
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Naming convention of iterated binary operation

Rob Stewart-2
On May 1, 2016 11:25:39 PM EDT, Jeremy Murphy <[hidden email]> wrote:

>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.

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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Naming convention of iterated binary operation

Jeremy Murphy
On 2 May 2016 at 18:20, Rob Stewart <[hidden email]> wrote:

> On May 1, 2016 11:25:39 PM EDT, Jeremy Murphy <
> [hidden email]> wrote:
> >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.
>
> 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.)
>

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Naming convention of iterated binary operation

Louis Dionne
In reply to this post by Jeremy Murphy
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

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
Reply | Threaded
Open this post in threaded view
|

Re: Naming convention of iterated binary operation

Rob Stewart-2
In reply to this post by Jeremy Murphy
On May 2, 2016 5:30:40 AM EDT, Jeremy Murphy <[hidden email]> wrote:

>On 2 May 2016 at 18:20, Rob Stewart <[hidden email]> wrote:
>> On May 1, 2016 11:25:39 PM EDT, Jeremy Murphy < [hidden email]> wrote:
>> >
>> >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.
>
>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.

There's some detail missing. How is your iterated GCD function different from a variadic gcd()?

___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Naming convention of iterated binary operation

Jeremy Murphy
On 3 May 2016 at 05:19, Rob Stewart <[hidden email]> wrote:

> On May 2, 2016 5:30:40 AM EDT, Jeremy Murphy <
> [hidden email]> wrote:
> >
> >A variadic template version with the same name makes sense to me,
> >though.
>
> There's some detail missing. How is your iterated GCD function different
> from a variadic gcd()?


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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Naming convention of iterated binary operation

Rob Stewart-2
On May 3, 2016 1:37:22 AM EDT, Jeremy Murphy <[hidden email]> wrote:

>
>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.

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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost