in reply to Re^3: Rosetta Code: Long List is Long (Updated Solutions)
in thread Rosetta Code: Long List is Long
I think that you are thinking of the Guttman-Rosler Transform?
Agreed. BTW I believe the GRT is generally faster than the Schwartzian Transform (this node has more detail on sorting history in Perl).
Though fond of the GRT, I couldn't make it work for this problem because of the unusual requirement to sort descending by count yet ascending by name (it would work nicely to sort both fields ascending via the classic pack "NA*" trick). If anyone can see a way to make GRT work for this problem, please let us know.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^5: Rosetta Code: Long List is Long (Updated Solutions)
by jwkrahn (Abbot) on Dec 09, 2022 at 22:47 UTC | |
Perhaps add a negative sign to the numbers before sorting and remove it after? | [reply] |
by eyepopslikeamosquito (Archbishop) on Dec 10, 2022 at 13:53 UTC | |
Thanks for the tip! This is bizarre, but thanks to your tip, while just trying to get a GRT solution to work, I seem to have accidentally "out-marioroy-ed" marioroy. :) I would have thought this impossible, so I've probably overlooked something, but this version runs three seconds faster on my machine than mario's astonishing dualvar solution while using slightly less memory (2,657,968K v 2,824,184K). Here is the source code. This is just a first cut at this approach, so further improvements may be available.
Example Run
Code Differences The only substantive differences between dualvar llil2d.pl and llil2grt.pl above are: vs:
| [reply] [d/l] [select] |
by eyepopslikeamosquito (Archbishop) on Jan 02, 2023 at 09:58 UTC | |
llil2cmd.pl - abbreviated version of llil2grt.pl For cheap thrills, I created llil2cmd.pl, a short command line version of llil2grt.pl:
Curiously, this abbreviated version runs at about the same speed on Windows, but significantly faster on my Ubuntu Linux VM:
To get more detailed timings, I hacked out a long short version:
As you can see from the times reported by the Linux time command, it seems that large lexical variables in Perl are significantly slower to cleanup at program exit than non-lexicals (about three seconds slower in this example: 33.475s vs 30 secs for llil2grt.pl, 28.629s vs 28 secs for llil2cmd-long.pl). New perl 5.36 experimental for_list feature After stumbling upon perl 5.36 and the for_list feature - a simple speed comparison I had to give the perl 5.36 for_list feature a try (update: List::Util's pairmap might be worth a try given it was mentioned in a reply). After building perl v5.36 from source (my Ubuntu system perl is v5.34 - update see improved build perl 5.38 notes): and adding: to the top of llil2grt.pl while changing one line from: to: it produced the same result, but did not run appreciably faster. Update: as for why it isn't much faster, see ikegami's replies at: Re^2: Why does each() always re-evaluate its argument? (Updated x2 - experimental "for_list" ) Update: Improved Ubuntu Perl Build Notes
Manual install of CPAN Roman module Later I manually installed Roman by CHORNY from CPAN into this local non-root Perl 5.36 as follows:
Update: Better to do it via: cpanm --from https://www.cpan.org/ --verify Roman 2>&1 | tee Roman.tmp Updated: Added steps for building perl v5.36.0 from source and manual install of Roman module. Noted that large lexical variables are slower to cleanup at program exit. | [reply] [d/l] [select] |