User talk:Hkdtam: Difference between revisions
→Square form factorization
SqrtNegInf (talk | contribs) (→Perl 6 treatment of '\r\n': new section) |
|||
| (8 intermediate revisions by 4 users not shown) | |||
Line 14:
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: [https://docs.perl6.org/type/Str Perl 6 / Str data type] --[[User:SqrtNegInf|SqrtNegInf]] ([[User talk:SqrtNegInf|talk]]) 00:28, 24 March 2019 (UTC)
== Simulated annealing ==
Made an update to your SA code, check out the
[https://github.com/SqrtNegInf/Rosettacode-Perl6-Smoke/S/Simulated_annealing 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... --[[User:SqrtNegInf|SqrtNegInf]] ([[User talk: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 --[[User:Hkdtam|Hkdtam]] ([[User talk: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... --[[User:SqrtNegInf|SqrtNegInf]] ([[User talk:SqrtNegInf|talk]]) 20:42, 28 January 2020 (UTC)
== Regarding "Elliptic Curve Digital Signature Algorithm" ==
Have you looked at trying the [https://modules.raku.org/search/?q=Digest%3A%3ASHA256%3A%3ANative 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;
with
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, # https://en.bitcoin.it/wiki/Secp256k1
:10("0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F"),
:10("0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141"),
:10("0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798"),
:10("0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8"));
would be better written as:
our (\A,\B,\P,\O,\Gx,\Gy) = 0, 7, # https://en.bitcoin.it/wiki/Secp256k1
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F,
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141,
0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8;
They are already integers, albeit expressed in hexadecimal, no need to convert to strings and then re-interpret them.
Thanks for adding this! --[[User:Thundergnat|Thundergnat]] ([[User talk: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. --[[User:Hkdtam|Hkdtam]] ([[User talk: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,
[https://github.com/SqrtNegInf/Rosettacode-Raku-Smoke/blob/39385f8a609dac85c0737a58dd79952caaf8ee76/S/Square_Form_Factorization.1 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. --[[User:Hkdtam|Hkdtam]] ([[User talk:Hkdtam|talk]]) 17:49, 26 March 2021 (UTC)
:Try running https://replit.com/@PeteLomax1/SnowOddballSdk#main.c - it completes in less than a second! --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|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 --[[User:Hkdtam|Hkdtam]] ([[User talk:Hkdtam|talk]]) 17:52, 26 March 2021 (UTC)
| |||