This is what I was saying:
immutable CurveFP{T<:Number}
p::T
a::T
b::T
function CurveFP(p::T, a::T, b::T)
mod(4a^3 + 27b^2, p) != 0 || error("4*$a^3 + 27*$b^2 ≡ 0 mod $p")
new(p, a, b)
end
end
CurveFP{T<:Number}(p::T, a::T, b::T) = CurveFP{T}(p, a, b)
CurveFP(p::Number, a::Number, b::Number) = CurveFP(promote(p, a, b)...)
This allows specilized code be generated for CurveFP{T} for each T. The
version where the fields are abstractly typed defines a single type and
code that deals with that type has to generically deal with any possible
type of Number value for each field.
Also note that the way you were using assert is not quite right: assert
should only be used to check internal correctness of your own code, not to
check that users of your code are doing the right thing. If you remove all
asserts, your code should continue to work identically from the user's
perspective.
On Wed, Oct 22, 2014 at 10:14 AM, Erik Schnetter <[email protected]>
wrote:
> What Stefan is probably trying to say:
>
> Instead of a function f(x, y) where x and y can have different types,
> write f{T}(x::T, y::T), so that x and y are forced to have the same
> type -- but this type can be any type. In this way, e.g. x+y can be
> evaluated very efficiently, and without type conversion, independent
> of whether x is Int or BigInt.
>
> -erik
>
>
> On Tue, Oct 21, 2014 at 8:36 PM, Stefan Karpinski
> <[email protected]> wrote:
> > 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.
> >>>
> >
>
>
>
> --
> Erik Schnetter <[email protected]>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
