ok, I 'll do it！ I'll note "this can be obnoxious on really large sets. requires it to retain every element in the collection" to doc Certainly, Verb is better. I'll create new PR!
2019年10月5日(土) 1:49 Chris <[email protected]>: > 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]> 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]. >> 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/CAKwTqEk8UxYVPpp9H24YPB0sCNv1_P9nxCALRh7XP2YUsPEJKQ%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAKwTqEk8UxYVPpp9H24YPB0sCNv1_P9nxCALRh7XP2YUsPEJKQ%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]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CADfR9tF9xadaLLBXBGAKkKxQoPw6579PKo94JpVS0KkpSB-Hug%40mail.gmail.com.
