No, you don't want to wrap everything in a BigInt. Like everyone else has said, just use a parameter in your types and in your functions.
--Tim On Tuesday, October 21, 2014 04:34:00 PM alexander maznev 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] > > > > <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.
