I had issues with how Julia does not seem to do type coarsing even when a function will only take arguments of that one type. I.e. point_a * 10 will fail because it expects a BigInt but receives an Int64, which i guess is solved by wrapping every single number passed around in the BigInt class, or duplicating all the methods. At any rate I tested it with BigInt instead of Number and the run times do not change much. Also I introduced a type when replacing divmod with divrem, it should be. (q,c),d = divrem(d,c), c
On Tuesday, October 21, 2014 7:19:10 PM UTC-4, Kevin Squire wrote: > > One problem is that you're using an abstract type (Number) for all of the > variable members if your types. > > In function declarations, this is okay, because the function is > specialized on the concrete number type. But for types, abstractly typed > members are boxed (stored as pointers), because the exact type is not given > in the definition. > > You can get close to the same flexibility of the current code by using > parametric types, which should erase any performance gap. > > Cheers, > Kevin > > On Tuesday, October 21, 2014, alexander maznev <[email protected] > <javascript:>> wrote: > >> This should be an equivalent, or nearly there, implementation of Elliptic >> Curves mod p as found in the Python ecdsa library. >> >> https://gist.github.com/anonymous/a3799a5a2b0354022eac >> >> Noticeably, regular mod is 10x slower than python? >> Inverse_mod is 7x slower than python. >> Double is 7x slower than python >> Multiply is more than 7X slower than python. >> >>
