Talk:Multiplicative order: Difference between revisions

Provide reference to 100x faster Python code
No edit summary
(Provide reference to 100x faster Python code)
 
(One intermediate revision by one other user not shown)
Line 87:
 
: ), you wouldn't have been able to learn anything at all by comparison, unless you can guess already what the Haskell code means. It's exactly '''because''' I used the '''same''' algorithm that you can learn something from it. [[User:Dirkt|Dirkt]] 05:50, 10 December 2007 (MST)
 
Whatever the merits or flaws of the Bach & Shallit description, it is all that the J program had to
go on when it was written. As things now stand in this page, the specifications are now different:
the original specs by Bach & Shallit, and the specs you have written. Also, the J and Haskell programs
are commented to different standards.
 
With disparate languages it can be (and is) difficult to devise simple tasks that bring into focus
the distinct features of the languages. What you need are both: simple tasks that hopefully bring
out a single orthogonal feature, and more complicated tasks such as multiplicative order that
tells you what are the areas where it may be fruitful to explore simpler tasks. [[User:Roger Hui|Roger Hui]] 01:01, 11 December 2007 (MST)
 
=== Java solution ===
Line 96 ⟶ 106:
 
:You're allowed to fix it too if you know how. No one will be angry. --[[User:Mwn3d|Mwn3d]] 09:43, 8 December 2007 (MST)
 
=== Python solution ===
 
Python "multOrder()" code is nice and self-contained. I happily used it until being pointed to sympy "n_order()". For multOrder(2, 2**41+3) timeit reports 33.6ms, for n_order(2, 2**41+3) timeit reports 206us (on a Raspberry Pi4B). sympy "n_order()" seems to work similar to "multOrder()", just 100x faster:
https://github.com/sympy/sympy/blob/46e00feeef5204d896a2fbec65390bd4145c3902/sympy/ntheory/residue_ntheory.py#L13-L53
--[[User:HermannSW|HermannSW]] ([[User talk:HermannSW|talk]]) 12:19, 2 August 2021 (UTC)
Anonymous user