OK! I 'll note " this can be obnoxious on really large sets, requires it to 
retain every element in the collection" .
I'll create new PR!

2019年10月5日土曜日 1時49分50秒 UTC+9 Chris:
>
> I like it!
>
> Either frequency or tally works for me, though I'd suggest "tally" since 
> it's a verb and you never "frequency" up a list of different occurrences.
>
> It looks like a simple and useful addition to the standard library.
>
> For folks complaining about streaming or other issues--a simple note on 
> the docs saying "hey, this can be obnoxious on really large sets" seems 
> reasonable. There are dozens of footguns lying around for people that don't 
> know better in any programming language, no reason to inconvenience 
> ourselves out of concern that somebody might do something suboptimal.
>
> On Tue, Oct 1, 2019 at 12:14 PM Osawa QWYNG <[email protected] 
> <javascript:>> wrote:
>
>>
>> frequency sounds good! 
>>
>> I also have tried to get some data through the production console.
>>
>> PHP has a similar method
>> https://www.php.net/manual/en/function.array-count-values.php
>>
>> May I update My PR?
>>
>> 2019年10月1日火曜日 7時36分56秒 UTC+9 OvermindDL1:
>>>
>>> I prefer the name `frequency` as well, however I would vote not to 
>>> include it.  It is trivial enough just type it inline where needed as it as 
>>> and it would not be used often-enough to be worth inclusion I think.  
>>> Perhaps as another library for now?
>>>
>>> On Monday, September 30, 2019 at 11:35:46 AM UTC-6, Allen Madsen wrote:
>>>>
>>>> I think the problem with including this in the core library is that you 
>>>> can end up with very different implementations depending on what your use 
>>>> case is. So, if it were included in the standard library, it would need to 
>>>> be explicit about when to use it and when not to.
>>>>
>>>> The version provided in the PR is memory inefficient, because it first 
>>>> does a group by, which requires it to retain every element in the 
>>>> collection. For simple, use cases that may be fine, but if you're 
>>>> streaming 
>>>> a large amount of data, you probably only want to keep track of the 
>>>> counts. 
>>>> If you're keeping track of the counts, you're probably being inefficient 
>>>> speed wise, because you're constantly updating the accumulator map for 
>>>> each 
>>>> item in the collection. To do that efficiently, you probably want to use 
>>>> an 
>>>> ETS table. But, do you really want an ETS table to be created any time you 
>>>> call this function?
>>>>
>>>> Allen Madsen
>>>> http://www.allenmadsen.com
>>>>
>>>>
>>>> On Mon, Sep 30, 2019 at 1:20 PM Paul Byrne <[email protected]> 
>>>> wrote:
>>>>
>>>>> Most occasions I've needed to do this kind of count, I've been trying 
>>>>> to get some data through the production console, rather than it being 
>>>>> some 
>>>>> business logic, to get a sense of how often some data problem has 
>>>>> occurred.
>>>>>
>>>>> Given that I think it's a rather nice addition to the toolbox. It's 
>>>>> certainly generic enough, though possibly too niche.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Mon, Sep 30, 2019, 12:57 Wojtek Mach <[email protected]> wrote:
>>>>>
>>>>>> As I mentioned on the linked PR, I’m in favor of such feature. I like 
>>>>>> how Clojure calls this function: frequencies. Thus if we are considering 
>>>>>> Enum.frequencies/1 and/or Enum.frequencies/2, it has my vote.
>>>>>>
>>>>>> To move the proposal forward I think it would be very valuable if you 
>>>>>> could survey other programming languages to see if they have such 
>>>>>> feature 
>>>>>> and if so - under what function name.
>>>>>>
>>>>>> -- 
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "elixir-lang-core" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>> send an email to [email protected].
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/1ACBE99E-BE36-4035-991C-9BD03651048C%40wojtekmach.pl
>>>>>> .
>>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "elixir-lang-core" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to [email protected].
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAL%3D_u%3DLVpD4Gf5Ay_ezX7W%3DFRoB5y31EU%3DLAiOHhTK%2BGSFyzeg%40mail.gmail.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAL%3D_u%3DLVpD4Gf5Ay_ezX7W%3DFRoB5y31EU%3DLAiOHhTK%2BGSFyzeg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/0e4dc6bc-4654-4698-b8a9-cc9b0782bbbc%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/0e4dc6bc-4654-4698-b8a9-cc9b0782bbbc%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/ee4089e3-874b-41e8-a00d-1b0a58b7b9f7%40googlegroups.com.

Reply via email to