First of all, I really think that 'invert' is very unfortunate name for such an operation. I was very surprised with the proposed semantic, which for me looks more like 'transpose' (remember matrix transpose).
But even with that name the operation is possible to lose data if values are not unique, so two such consecutive operations may result in different result than the original input. I doubt that the rules which value takes priority are general enough to go into standard library, and should be specific to the place of invocation. On 7 February 2019 05:27:29 GMT+11:00, Justin Gamble <justins...@gmail.com> wrote: >Thanks for your feedback Amos. I hope you can appreciate that not all >applications are focused primarily around performance. > >If performance is key to your application, then you are responsible for > >learning tricks to optimize the code. That might include iterating >over >your map a single time, and doing multiple transformations at once - >including inverting the map. > >For applications where performance is a consideration, but not the >prime >focus, things are different. Here maintainabiility tends to be the key >focus. I find it elegant to write code where functions do not have >side-effects. (If you are doing multiple transformations while >iterating >over a map to invert it, then yes you are introducing side-effects. >Perhaps the side-effects are justified, but that is a design decision) > >Perhaps you'll agree that the proposed implementation of Map.invert() >looks >clear. But two questions: > > 1. Would someone new to Elixir write it out so simply? >2. What happens if a map has multiple keys that map to the same value - > > which value will become the key in the inverted map? This requires > additional testing and documentation. > > >Elixir is a productive language. It should not require each user to go > >through the tedium of implementing, testing and documenting common code > >like this. That is the purpose of having a re-useable library. > >I think Map.invert() is a tool that should be offered for users that >want >it. As an analogy, consider the filter() function that is offered by >both >Enum and Stream modules. Some users will select Stream.filter/2 for >performance, but does that mean Enum.filter/2 should be deprecated? I >don't think so. Users need to be smart enough to know which functions >work >for them. > >In the example scenario I described, I simply wanted an inverted map. >And >I questioned why this was not already provided by the library? > >On the topic of performance, I have one other tidbit to mention. In my > >application, I achieved performance by launching a separate thread for >each >Robot Framework file that was being processed. The resulting execution >time >is so blindingly fast, that I am more than pleased. I certainly have >no >need to further >optimize the performance, especially if that would complicate the code. > >Thanks, >Justin > >On Wednesday, February 6, 2019 at 9:57:51 AM UTC-7, Amos King - Binary >Noggin wrote: >> >> I find that small piece of code would often have other data >processing >> connected to it. I'd hate to cycle through the map multiple times if >I was >> going to swap the key and value, and then do more processing on the >value. >> I think such a function would encourage the practice of chaining >along >> without thinking of the consequences of performance. I personally >don't >> find this to be useful as part of the core of the language, but maybe >in a >> package that you reuse in many of your own projects. If you find that >it is >> pulled into all of your projects it could then be open-sourced so >that >> others could take advantage of it. >> >> Amos King >> CEO >> Binary Noggin >> http://binarynoggin.com #business >> https://elixiroutlaws.com #elixir podcast >> http://thisagilelife.com #podcast >> >> ======================================================= >> I welcome VSRE emails. Learn more at http://vsre.info/ >> ======================================================= >> >> >> >> On Wed, Feb 6, 2019 at 12:35 AM Justin Gamble <justi...@gmail.com >> <javascript:>> wrote: >> >>> Hi, >>> >>> I think an invert() method on Map would be convenient to use. It is >only >>> a handful of lines of code to add to a custom program, but why >should users >>> need to do that? In my opinion this basic functionality should be >>> implemented by the Map module. >>> >>> The invert() method would operate the same way it does for Ruby: >>> https://ruby-doc.org/core-2.2.2/Hash.html#method-i-invert >>> >>> Recently I wanted to invert a map in one of my Elixir programs >(details >>> below), and I googled and found the below solution by Chris McCord >in h >>> >ttps://stackoverflow.com/questions/26614682/how-to-change-all-the-values-in-an-elixir-map >>> : >>> >>> def invert(map) when is_map(map) do >>> for {k, v} <- map, into: %{}, do: {v, k} >>> end >>> >>> I would basically like the above function to be added to the >Elixir.Map >>> module. >>> >>> Here is the scenario for which I wanted to use this the invert >function: >>> >>> *My Elixir program is synchronizing Robot Framework source code >files >>> with TestRail. Robot Framework defines automated test cases. >TestRail is >>> a web-based Test Case Management system. The goal is to >synchronize >>> TestRail to contain all the tests that are defined in the Robot >Framework >>> files, and in the same directory structure.* >>> >>> *Originally the Elixir program was specified to only create test >cases in >>> TestRail. When you are creating a test case, the TestRail API >>> <http://docs.gurock.com/testrail-api2/reference-cases#add_case> >requires >>> you to specify the ID of the directory (aka "section") where the >case is >>> written. For this I use an Elixir Map to map paths to section IDs. >When I >>> want to create a file in directory "/path/to/test.robot", then I >Lookup the >>> section ID from my map & then call the "add_case" TestRail API >function.* >>> >>> *That version of the program was a success. My boss was impressed >and >>> next asked for enhancements to the program. The new functionality >being >>> requested is to have existing TestRail Test Cases get updated with >the >>> latest test steps defined in Robot Framework. Part of that update >is to >>> verify that the path to the test case is the same in the Robot >Framework >>> source code and in the TestRail. In this case we first call the >TestRail >>> API to lookup a test case, at which point we know the section ID >that it >>> belongs to. But we need to translate that to a directory path and >confirm >>> that this path is the same location as where the test file exists in >the >>> Robot Framework source code. * >>> >>> *For updating, it makes sense to also be able to use an Elixir Map >to map >>> from the Section ID back to the Path -- the inverse of the original >map. * >>> >>> *It is true that I could iterate through the original map until I >found >>> the section ID in the value section, and then return the map index. >But >>> that seems awfully inefficient when you consider that there are >hundreds of >>> test files and thousands of tests. So I decided an inverse map >would >>> provide faster lookup, at the cost of more memory being used. Also >note >>> that in my scenario both the indexes and the values are unique; it >is a >>> 1-to-1 mapping.* >>> >>> >>> This is just one example scenario. I imagine other examples exist, >or >>> else the invert() function would never have been created in the Ruby > >>> community. >>> >>> -- >>> 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 elixir-lang-co...@googlegroups.com <javascript:>. >>> To view this discussion on the web visit >>> >https://groups.google.com/d/msgid/elixir-lang-core/b2c7e58a-ad99-4458-a45e-9f7d5f7fce15%40googlegroups.com > >>> ><https://groups.google.com/d/msgid/elixir-lang-core/b2c7e58a-ad99-4458-a45e-9f7d5f7fce15%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> > >-- >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 elixir-lang-core+unsubscr...@googlegroups.com. >To view this discussion on the web visit >https://groups.google.com/d/msgid/elixir-lang-core/d064aea6-7c8a-418a-91d6-8a4c4968da7f%40googlegroups.com. >For more options, visit https://groups.google.com/d/optout. -- Kind regards, Dmitry Belyaev -- 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/54972947-5E99-47C6-AD4A-825C5A2771DC%40gmail.com. For more options, visit https://groups.google.com/d/optout.
