Oh yeah, those fields having abstract type is a doozy – you'll want to introduce a type parameter for that type and make all of the field of that type.
> On Oct 21, 2014, at 7:34 PM, alexander maznev <[email protected]> > wrote: > > 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]> >>> 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.
