Sorry I was not clear enough. They are not the same but there is no reason
to use Float32 on a 32 bit system and Float64 on a 64 bit system. On both
32bit and 64bit CPUs you will usually have 80bit floating point units. So
both will be equally fast (if we ignore caching for a moment). In contrast
integers and in particular array indices will be slower if one uses Int64
on a 32bit system. Therefore we have Int as a shortcut for the "native"
integer type.
Cheers,
Tobi
Am Montag, 25. August 2014 21:57:40 UTC+2 schrieb Roy Wang:
>
> I didn't know Float64 and Float32 are the same on 32-bit systems. Thanks.
>
> On Monday, 25 August 2014 15:48:30 UTC-4, Tobias Knopp wrote:
>>
>> Thats for a reason. Float64 and Float32 are the same on 64 and 32 bit
>> computers. Its only the integer types where this matters.
>>
>> Am Montag, 25. August 2014 21:38:44 UTC+2 schrieb Roy Wang:
>>>
>>> Thanks Tom. Pweh, that's what I suspected.
>>>
>>> I glanced at boot.jl, and it doesn't seem Julia has a typealias for
>>> doubles. I'll define my own to check for 32 vs. 64-bit systems.
>>>
>>> On Monday, 25 August 2014 15:10:30 UTC-4, Tomas Lycken wrote:
>>>>
>>>> Actually, Int (and UInt) are aliases to the “native size integer”, so
>>>> if you specify Int you will get Int32 on a 32-bit system and Int64 on
>>>> a 64-bit system. So no, don’t change my_var::Int to my_var::Int32 -
>>>> that’ll make your code *worse* on 64-bit systems ;)
>>>>
>>>> // T
>>>>
>>>> On Monday, August 25, 2014 9:05:06 PM UTC+2, Roy Wang wrote:
>>>>
>>>>
>>>>> Thanks guys. So to clarify: FloatingPoint is not a concrete types, so
>>>>> explicitly defining variables or function inputs using it will not speed
>>>>> things up. Instead, I should use Float64, Float32, etc.
>>>>>
>>>>> Is Int an abstract type as well? I'm wondering if I should go back and
>>>>> rename everything my_var::Int to my_var::Int32.
>>>>>
>>>>> John: I couldn't find the mutate!() function in the Julia Standard
>>>>> Library v0.3. Do you mean my own function that mutates the source array?
>>>>>
>>>>> On Monday, 25 August 2014 14:54:14 UTC-4, Patrick O'Leary wrote:
>>>>>>
>>>>>> On Monday, August 25, 2014 12:28:00 PM UTC-5, John Myles White wrote:
>>>>>>>
>>>>>>> Array{FloatingPoint} isn't related to Array{Float64}. Julia's type
>>>>>>> system always employs invariance for parametric types:
>>>>>>> https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
>>>>>>>
>>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCovariance_and_contravariance_%28computer_science%29&sa=D&sntz=1&usg=AFQjCNH5Mpuwh71o9dv0_TDx9OcMvvKfWg>
>>>>>>>
>>>>>>
>>>>>> To underline this point a bit, it's even a bit worse than that:
>>>>>> Array{FloatingPoint} will work just fine for a lot of things, but it
>>>>>> stores
>>>>>> all elements as heap pointers, so array-like operations (such as linear
>>>>>> algebra routines) will often be extremely slow.
>>>>>>
>>>>>> As a rule, you almost never use an abstract type as the type
>>>>>> parameter of a parametric type for this reason. Where you wish to be
>>>>>> generic over a specific family of types under an abstract type, you can
>>>>>> use
>>>>>> type constraints:
>>>>>>
>>>>>> function foo{T<:FloatingPoint}(src::Array{T,1})
>>>>>> ...
>>>>>> end
>>>>>>
>>>>>> But often type annotations can be omitted completely.
>>>>>>
>>>>>
>>>>
>>>
