>I get the feeling you want to parameterise ECPoint by instances of EC. Is
that right?
This is exactly correct (it does look like this is "triangular dispatch",
thanks for the link). At the moment, I'm sticking the EC on every point as
an attribute:
immutable ECPoint{P}
x::Z{P}
y::Z{P}
ec::EC{P}
ECPoint(x, y, ec) = y^2 == ec.f(x) ? new(x, y, ec) :
error("($x,$y)
not a solution of $ec")
end
It kind of feels (at least in this case, though perhaps not in general -
maybe being hashable is sufficient? :s) that you could "hack" the type
system to use `ECPoint{P, A, B}` (where `y^2 = x^3+Ax+B (mod P)` is the
specific EC I want an ECPoint type for). I think setting this up will
quickly get pretty messy (!, presumably why it's not a feature - yet) but
maybe I'll give it a try...
On 21 July 2014 13:14, Avik Sengupta <[email protected]> wrote:
> So a type parameter is a placeholder, that takes that takes a value from a
> (optionally constrained) set when the type is instantiated.
>
> Thus to say "immutable ECPoint{EC{P}}" where EC is a concrete type does
> not make sense. I get the feeling you want to parameterise ECPoint by
> instances of EC. Is that right? Unfortunately, only types, integers and
> symbols can currently be used as type parameters (and maybe tuples?). User
> defined immutable types cannot be used as type parameters yet. That may
> change in the future.
>
> So that I think is the primary issue with what you want to do. However,
> even if you imagine different kinds of curves are represented as different
> Julia types (which makes it possible to use them as type parameters), the
> kind of chained type parameters that you want is not possible right now .
> See https://github.com/JuliaLang/julia/issues/3766 for some discussion.
>
> Hope that helps
>
> Regards
> -
> Avik
>
>
> On Monday, 21 July 2014 20:16:15 UTC+1, andy hayden wrote:
>>
>> I was wondering if there anyone had any rules of thumb for when to create
>> parametric types of a parametric types (if this is even possible?).
>>
>> To give a concrete example, I was messing around to describe/implement
>> elliptic curve point addition:
>>
>> # ring of integers mod P
>> immutable Z{P} <: PAdicInteger
>> val::Integer
>>
>> Z(val) = new(mod(val, P))
>> end
>>
>>
>>
>> immutable EC{P} # elliptic curve
>> a::Z{P}
>> b::Z{P}
>> f::Function
>>
>> EC(a, b) = new(a, b, x -> Z{P}(x^3 + a*x + b))
>> end
>>
>>
>> Which works great (and I can add some neat methods cleanly), however I
>> then want a type dependent on an elliptic curve, the solutions of that
>> curve (so I can define addition), something like:
>>
>> immutable ECPoint{EC{P}}
>> x::Z{P}
>> y::Z{P}
>>
>> ECPoint(x, y) = y^2 == EC.f(x) ? new(x, y) :
>> error("($x,$y) not a
>> solution of $EC")
>> end
>>
>>
>> This doesn't compile. I can put the EC as an attribute (and assert I'm
>> using equal ECs in every method), but to me it seems "nicer" to rely on the
>> type system.
>> Is there a trick here for types dependant of parametric types? Am I just
>> thinking about this "wrong"?
>>
>> Best,
>> Andy
>>
>> p.s. no doubt I'm reinventing the julia wheel with p-adics and elliptic
>> curves... :)
>>
>
