User talk:Hkdtam

From Rosetta Code

Nice to see more Perl 6 tasks

Glad to see another person entering Perl 6 tasks, hope you have the inclination to keep on doing so. If you do, a small request: When you add/edit a task, put a short summary of what you've done, even just 'added Perl 6', in the 'Summary' line. It helps people viewing the recent change get a sense of what languages are being worked on. Additionally, I get automated notifications based on that summary, which helps me keep my smoke-testing archive up-to-date. --SqrtNegInf (talk) 19:34, 29 November 2018 (UTC)

I'd like to add few other notes. Please be sure that you have permission to post third party code. You are attributing things nicely so not really a problem yet, but I'd like to keep it that way. Also, try to be sure that the code actually solves the task. Specifically, in the Send email task, the Perl 6 code generates an email, but doesn't actually have any mechanism to send it. Thanks! --Thundergnat (talk) 19:59, 29 November 2018 (UTC)

Also, it is much better to post examples that actually work. Median filter tries to use methods that aren't actually implemented yet. Speculatively they may be in the future, but they aren't at this point. --Thundergnat (talk) 13:30, 30 November 2018 (UTC)

Problems with 'Addition chains' task

Can you double-check that the 'Addition chains' task you posted is based on a correctly functioning local version? For starters, you have $num = $nbLimit, which is an assignment, not a test/comparison (should be $num <= $nbLimit). But with that fixed, it reveals that the routine 'findNonBrauer' is not working. I'd be happy to take a further look at this if you get stuck while debugging. --SqrtNegInf (talk) 15:32, 4 February 2019 (UTC)

Perl 6 treatment of '\r\n'

That pairing gets special treatment (handled as a "single grapheme") precisely because of it's role in line-termination. Here's one place that's documented: Perl 6 / Str data type --SqrtNegInf (talk) 00:28, 24 March 2019 (UTC)

Simulated annealing

Made an update to your SA code, check out the version of the code with notes at my github project. Of course feel free to re-work any portions where you feel that I've gone too far in the mini-fication of the code. I've been known to get carried away... --SqrtNegInf (talk) 04:10, 28 January 2020 (UTC)

Thanks again for the uplift and in fact bug fixing maneuvers :-D I guess the errors introduced via my incorrect translation made it fail to achieve desired convergence. This is an interesting entry and I will likely try again via another translation in the future in order to learn more on the topic. In the mean time, I do have some questions and may ask for your opinion via github so sorry in advance for any future bothering. :-D --Hkdtam (talk) 16:58, 28 January 2020 (UTC)
There were no errors in your code! Your translation from 'Go' was faithful and accurate. No bugs were fixed in my revision, I was just fussing around with the style of the code, as described in my github notes. The reason I replaced the output section was it was the easiest way to show how it looked with fewer digits of precision. thundergnat++ looked at my changes and pointed out how to use an 'anonymous container' to avoid creating a useless temporary variable. RC is all about learning... --SqrtNegInf (talk) 20:42, 28 January 2020 (UTC)

Regarding "Elliptic Curve Digital Signature Algorithm"

Have you looked at trying the Digest::SHA256::Native module? It is a high speed C based implementation and should be much faster than the pure Perl 6 Digest::SHA. It would let you replace the lines:

   my \z = :16((sha256 msg).list>>.&{"%02s".sprintf(.base(16))}.join) % $.n;


   my \z = :16(sha256-hex msg) % $.n;

getting the same results, and should be much faster besides.

Also, the constants block

   our (\A,\B,\P,\O,\Gx,\Gy) = (0, 7, #

would be better written as:

   our (\A,\B,\P,\O,\Gx,\Gy) = 0, 7, #

They are already integers, albeit expressed in hexadecimal, no need to convert to strings and then re-interpret them.

Thanks for adding this! --Thundergnat (talk) 23:27, 24 February 2020 (UTC)

Thanks for your advice. >> Have you looked at "Digest::SHA256::Native"? Yes I did but for some unknown reasons I couldn't get any non-trivial module to install. I am using rakudobrew and when I do
   zef install Digest::SHA256::Native
then I will get the following error
   [Digest::SHA256::Native] Could not find LibraryMake at line 2 in:
so the syndrome is like when installing a module A depends on BCDEF, it will complain about missing B, then when I build B, it will say C is missing. I have two installations ( ubuntu16.04+v2020.01.1 and centos7+v2019.11 ) and the same happened on both of them. I tried to google for that and didn't see anyone got similar problem lately. Anyway I may try again later this weekend with a start from scratch. All in all, thank you very much. --Hkdtam (talk) 01:53, 26 February 2020 (UTC)

Square form factorization

While Raku is slow, there is in particular a large start-up penalty related to all the Unicode names you put into the code. Look at the timings in my version, with no Unicode. I saw in the IRC archive that this has been noticed before, but apparently not fixed.

@SqrtNegInf - Thanks for your advice. Yes I did aware of the trade off, starting back at the time when I used these Unicode eye candies on the DES entry. --Hkdtam (talk) 17:49, 26 March 2021 (UTC)
Try running - it completes in less than a second! --Pete Lomax (talk) 09:18, 26 March 2021 (UTC)
Hi again Pete, I would say, on a very dramatic scale, it is like comparing Assembly with React Native. :-D --Hkdtam (talk) 17:52, 26 March 2021 (UTC)