www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - So... add maxCount and maxPos?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
This is one of those cases in which we were pedantically right to not 
add them, but their equivalents look like crap.

https://github.com/D-Programming-Language/phobos/pull/3942


Andrei
Jan 20
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
 This is one of those cases in which we were pedantically right to not
 add them, but their equivalents look like crap.
 
 https://github.com/D-Programming-Language/phobos/pull/3942
[...] I don't like this. I'd much rather we rename those functions to be something more generic. After all, minPos is a horrible name when the predicate has nothing to do with minimum values. What about extremumPos? (Though that's rather ugly to type.) T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Jan 20
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/20/2016 12:29 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via
Digitalmars-d wrote:
 This is one of those cases in which we were pedantically right to not
 add them, but their equivalents look like crap.

 https://github.com/D-Programming-Language/phobos/pull/3942
[...] I don't like this. I'd much rather we rename those functions to be something more generic. After all, minPos is a horrible name when the predicate has nothing to do with minimum values. What about extremumPos? (Though that's rather ugly to type.)
extremumPos has been on my wish list for a while now, but (a) we're stuck with minPos anyway, (b) extremumPos sounds elitist. -- Andrei
Jan 20
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 20, 2016 at 02:30:10PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 01/20/2016 12:29 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
This is one of those cases in which we were pedantically right to
not add them, but their equivalents look like crap.

https://github.com/D-Programming-Language/phobos/pull/3942
[...] I don't like this. I'd much rather we rename those functions to be something more generic. After all, minPos is a horrible name when the predicate has nothing to do with minimum values. What about extremumPos? (Though that's rather ugly to type.)
extremumPos has been on my wish list for a while now, but (a) we're stuck with minPos anyway, (b) extremumPos sounds elitist. -- Andrei
If renaming is out of the question, then I suppose maxPos/maxCount would be the next less evil. :-P If we ever get to D3, this would be one of the things that should be changed... but until then, I guess we can live with maxPos/maxCount. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Jan 20
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/20/2016 06:29 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via
Digitalmars-d wrote:
 This is one of those cases in which we were pedantically right to not
 add them, but their equivalents look like crap.

 https://github.com/D-Programming-Language/phobos/pull/3942
[...] I don't like this. I'd much rather we rename those functions to be something more generic. After all, minPos is a horrible name when the predicate has nothing to do with minimum values.
The predicate always describes an order relative to which to find a minimum.
Jan 20
prev sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 20 January 2016 at 17:29:28 UTC, H. S. Teoh wrote:
 On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu 
 via Digitalmars-d wrote:
 This is one of those cases in which we were pedantically right 
 to not add them, but their equivalents look like crap.
I don't like this. I'd much rather we rename those functions to be something more generic. After all, minPos is a horrible name when the predicate has nothing to do with minimum values. What about extremumPos? (Though that's rather ugly to type.)
maxCount sounds too much like it's suppose to be a function in SQL querying, and minCount... ugg... now I wonder what in the world we're talking about. From algorithm.d:
 int[] a = [ 2, 3, 4, 1, 2, 4, 1, 1, 2 ];
 // Minimum is 1 and occurs 3 times
 assert(a.minCount == tuple(1, 3));
 // Maximum is 4 and occurs 2 times
 assert(a.maxCount == tuple(4, 2));

 // Minimum is 1 and first occurs in position 3
 assert(a.minPos == [ 1, 2, 4, 1, 1, 2 ]);
 // Maximum is 4 and first occurs in position 2
 assert(a.maxPos == [ 4, 1, 2, 4, 1, 1, 2 ]);
These unittests make it completely clear what it wants to do. I'd almost say lowestCount and highestCount would almost be better, but i am not sure. or just unitCount? Or countOf and posOf? which make a lot more sense when instantiated: So a.countOf!("a < b")? I'm seriously behind on all of this.
Jan 21
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/21/2016 08:42 AM, Era Scarecrow wrote:
 I'd almost say lowestCount and highestCount would almost be better, but
 i am not sure.
minCount is already a given. -- Andrei
Jan 21
next sibling parent Iakh <iaktakh gmail.com> writes:
On Thursday, 21 January 2016 at 14:04:58 UTC, Andrei Alexandrescu 
wrote:
 On 01/21/2016 08:42 AM, Era Scarecrow wrote:
 I'd almost say lowestCount and highestCount would almost be 
 better, but
 i am not sure.
minCount is already a given. -- Andrei
countMost!less and posMost!less
Jan 21
prev sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 21 January 2016 at 14:04:58 UTC, Andrei Alexandrescu 
wrote:
 On 01/21/2016 08:42 AM, Era Scarecrow wrote:
 I'd almost say lowestCount and highestCount would almost be 
 better, but I am not sure.
minCount is already a given. -- Andrei
I have a slight problem where I'm not already familiar with most of the standard library functions (D, libc, etc) that are usually available. This usually means I have a naive approach and/or naming convention to what's already been in place 15+ years. Of course when I do take the time to go through the libraries and documentation I'll say 'oohhh that's cool!'; But because I'm not actively using it I'll promptly forget it :(
Jan 23
prev sibling next sibling parent reply Ivan Kazmenko <gassa mail.ru> writes:
On Wednesday, 20 January 2016 at 17:16:00 UTC, Andrei 
Alexandrescu wrote:
 This is one of those cases in which we were pedantically right 
 to not add them, but their equivalents look like crap.

 https://github.com/D-Programming-Language/phobos/pull/3942
As it seems related, let me share my personal experience with minPos. Most of the time, I want one of the two things related to an extremum. 1. The minimum or maximum element itself. I write it as a.minPos.front. That's almost fine, but maybe there is a more expressive way? 2. The index of minimum or maximum element, mostly using plain array as a range. I write "a.length - a.minPos.length", and it looks completely unintuitive. Additionally, when compiling to 64 bits, I usually still want an int to use with other ints around (longs are overkill most of the time), and the cast adds more clobber. Again, is there a better way to express that? 3. Other uses: I've yet to see the need. In a random collection of my D code, the number of occurrences of cases 1:2:3 is 6:4:0. I've got used to "minPos !(q{a > b})" instead of "maxPos", but a maxPos alias would of course make things a bit more clear. Don't know how much of a justification that is. Ivan Kazmenko.
Jan 20
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:
 On Wednesday, 20 January 2016 at 17:16:00 UTC, Andrei Alexandrescu wrote:
 This is one of those cases in which we were pedantically right to not
 add them, but their equivalents look like crap.

 https://github.com/D-Programming-Language/phobos/pull/3942
As it seems related, let me share my personal experience with minPos. Most of the time, I want one of the two things related to an extremum. 1. The minimum or maximum element itself. I write it as a.minPos.front. That's almost fine, but maybe there is a more expressive way?
Sadly, no. I'm very willing to add an overload of min and max for one argument (which fortunately does not compile currently) to compute these over a range. In fact literally today I wrote r.min and was surprised it didn't work. Would you want to embark on that? Code, docs, unittests, the works.
 2. The index of minimum or maximum element, mostly using plain array as
 a range.  I write "a.length - a.minPos.length", and it looks completely
 unintuitive.  Additionally, when compiling to 64 bits, I usually still
 want an int to use with other ints around (longs are overkill most of
 the time), and the cast adds more clobber.  Again, is there a better way
 to express that?
No better way currently. We could add (min|max)Index but I like (min|max)Pos quite a bit. They offer more flexibility for non-random access ranges. For random access ranges you should soon be able to write a.before(a.minPos).length, for a different kind of unintuitiveness :o). Andrei
Jan 20
next sibling parent reply Ivan Kazmenko <gassa mail.ru> writes:
On Thursday, 21 January 2016 at 01:11:19 UTC, Andrei Alexandrescu 
wrote:
 On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:
 1. The minimum or maximum element itself.  I write it as
 a.minPos.front.  That's almost fine, but maybe there is a more
 expressive way?
Sadly, no. I'm very willing to add an overload of min and max for one argument (which fortunately does not compile currently) to compute these over a range. In fact literally today I wrote r.min and was surprised it didn't work. Would you want to embark on that? Code, docs, unittests, the works.
Hmm. I was at first frustrated by not having min(Range). But I looked for a reason it does not yet exist, and I found one. Say we define min of one argument, which is a range, to be the minimum value of that range. Now, what if we unpack tuples as arguments for min, and some tuple happens to have one element, which is a range? Currently, this immediately triggers a compile error. On the other hand, if we add the one-argument range version, it will silently produce a value of another type. As all of this may happen only at compile time, and the type system is rather strict, hopefully this will hit a compile error down the road, but even then, the actual cause will be harder to find. An example: ----- import std.algorithm, std.range, std.stdio, std.typecons; alias minBinary = (x, y) => x < y ? x : y; auto min (Args...) (Args args) if (args.length > 1) { return args.only.reduce!minBinary; } auto min (T) (T [] arr) { return arr.reduce!minBinary; } void main () { writeln (min (3, 1, 2)); // 1 writeln (min ([3, 1, 2])); // 1 writeln (min (tuple ([5, 6], [1, 2], [3, 4]).expand)); // [1, 2] writeln (min (tuple ([3, 1, 2]).expand)); // 1, huh? } ----- So, min(Range) + tuple expansion = problem. An alternative would be to define min(one argument) to just be that argument. That would be consistent with what we have now, but violates the principle of least astonishment for newcomers: why would min ([3, 1, 2]) return [3, 1, 2] and not 1? Currently, it just does not compile. So, I convinced myself that the current situation is the lesser evil. Currently, the second and fourth writeln in the example just don't compile if we comment out our min functions.
 2. The index of minimum or maximum element, mostly using plain 
 array as
 a range.  I write "a.length - a.minPos.length", and it looks 
 completely
 unintuitive.  Additionally, when compiling to 64 bits, I 
 usually still
 want an int to use with other ints around (longs are overkill 
 most of
 the time), and the cast adds more clobber.  Again, is there a 
 better way
 to express that?
No better way currently. We could add (min|max)Index but I like (min|max)Pos quite a bit. They offer more flexibility for non-random access ranges. For random access ranges you should soon be able to write a.before(a.minPos).length, for a different kind of unintuitiveness :o).
Well, this at least reads a bit like English: take the part of "a" before minimum position in "a" and calculate its length. The downside is two uses of "a" which are certain to put more burden on the optimizer. The current "whole length minus length after minimum" is a negative wording, which adds to perceived complexity every time it is used. Ivan Kazmenko.
Jan 20
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/20/2016 09:36 PM, Ivan Kazmenko wrote:
 So, min(Range) + tuple expansion = problem.
OK, convinced. There's of course the option of (min|max)Element. -- Andrei
Jan 20
prev sibling parent reply default0 <schneider.cedric gmx.de> writes:
On Thursday, 21 January 2016 at 02:36:05 UTC, Ivan Kazmenko wrote:
 An alternative would be to define min(one argument) to just be 
 that argument.  That would be consistent with what we have now, 
 but violates the principle of least astonishment for newcomers: 
 why would min ([3, 1, 2]) return [3, 1, 2] and not 1?  
 Currently, it just does not compile.
As a newcomer to the language, and as a reader of https://dlang.org/phobos/std_algorithm_comparison.html#min which states "Iterates the passed arguments and returns the minimum value." my intuitive understanding would be that yes of course min(x) returns x. However the above could of course also be reworded as "Iterates the passed list of arguments and returns the minimum value." to be even more clear about it NOT iterating individual arguments but the argument list as a whole :-) If I were to be a newcomer to programming in general this might be confusing, though. However, it's certainly consistent and easy to wrap your head around and also what I would have expected it to do the first time I came across the function.
Jan 21
parent Ivan Kazmenko <gassa mail.ru> writes:
On Thursday, 21 January 2016 at 12:17:26 UTC, default0 wrote:
 On Thursday, 21 January 2016 at 02:36:05 UTC, Ivan Kazmenko 
 wrote:
 An alternative would be to define min(one argument) to just be 
 that argument.  That would be consistent with what we have 
 now, but violates the principle of least astonishment for 
 newcomers: why would min ([3, 1, 2]) return [3, 1, 2] and not 
 1?  Currently, it just does not compile.
As a newcomer to the language, and as a reader of https://dlang.org/phobos/std_algorithm_comparison.html#min which states "Iterates the passed arguments and returns the minimum value." my intuitive understanding would be that yes of course min(x) returns x. However the above could of course also be reworded as "Iterates the passed list of arguments and returns the minimum value." to be even more clear about it NOT iterating individual arguments but the argument list as a whole :-) If I were to be a newcomer to programming in general this might be confusing, though. However, it's certainly consistent and easy to wrap your head around and also what I would have expected it to do the first time I came across the function.
Still, looks like Java, C# and Python have min work this way: given a single argument which is a collection, it returns the minimum in that collection, not the collection itself. A Python example: min ([1]) // 1 min ([2, 1]) // 1 min ((([1, 2], [2, 3]))) // [1, 2] min ((([1, 2]))) // 1 min ((([1, 2],),)) // ([1, 2],) In Python, the what happens is also tricky: def g(): return (1, 2) // tuple of two values g() // (1, 2) min (g()) // 1 from tuple min (*g()) // 1 from expanded tuple def f(): return (1,) // tuple of a single value f() // (1,) min (f()) // 1 min (*f()) // error, cannot expand
Jan 21
prev sibling parent tn <no email.com> writes:
On Thursday, 21 January 2016 at 01:11:19 UTC, Andrei Alexandrescu 
wrote:
 On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:
 2. The index of minimum or maximum element, mostly using plain 
 array as
 a range.  I write "a.length - a.minPos.length", and it looks 
 completely
 unintuitive.  Additionally, when compiling to 64 bits, I 
 usually still
 want an int to use with other ints around (longs are overkill 
 most of
 the time), and the cast adds more clobber.  Again, is there a 
 better way
 to express that?
No better way currently. We could add (min|max)Index but I like (min|max)Pos quite a bit. They offer more flexibility for non-random access ranges.
But (min|max)(Index|Key) offer different type of flexibility as those make sense for associative containers.
Jan 21
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/20/2016 06:16 PM, Andrei Alexandrescu wrote:
 This is one of those cases in which we were pedantically right to not
 add them, but their equivalents look like crap.

 https://github.com/D-Programming-Language/phobos/pull/3942


 Andrei
One reason why dual notions usually both receive names is that naming one of them but not the other is arbitrary and confusing. (Reversing all arrows in the respective category is often just not a very natural operation, even if it has a computational interpretation.) Languages don't just leave out one of && or || either.
Jan 20