I appreciate the feedback I'm still just getting acquainted with Julia as
you can tell, I'll post an updated version with some benchmarks in a bit.
One thing I'm not sure about is if this is the correct Method
Parametrization syntax - it seems to work though...
function +{T}(point_a::PointEC{T}, point_b::PointEC{T})
>Using dispatch to express some of the logic may seem appealing but I
suspect it's not a good idea unless the result type only depends on the
input types
Do you mean the PointINF related logic? Python uses a Point(None, None,
None, None) of the same class as the other points, one alternative would be
a PointEC{Void} in that case the logic could go into the functions,
although that might actually be slower than a unique PointINF type?
>assert
It was just seemed quicker to write assert than to write proper error
messages, that's obviously something that should be done if I were to port
the entire library.
Still wondering about Mod seeming to run nearly 10x slower in Julia than
Python.
def test(n=10**7):
t= time.time()
p = 6277101735386680763835789423207666416083908700390324961279
Gx = 0x188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012
for i in range(n):
(Gx+i) % p
return (time.time() - t)/ n
function test(n=10^7)
t= time()
Gx = 0x188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012
p = 6277101735386680763835789423207666416083908700390324961279
for i=1:n
mod((Gx+i), n)
end
return (time() -t)/n
end
On Wednesday, October 22, 2014 10:47:10 AM UTC-4, Stefan Karpinski wrote:
>
> 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]
> <javascript:>> 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] <javascript:>> 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]
>> <javascript:>>
>> > 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] <javascript:>>
>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>
>
