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/
