Yeah, wrapping everything in BigInt is a great way to pessimize your code. On Tue, Oct 21, 2014 at 9:38 PM, Tim Holy <[email protected]> wrote:
> 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. > >
