Thanks for the explanation, Yichao!

On Wednesday, August 17, 2016 at 4:33:43 PM UTC+2, Yichao Yu wrote:
>
>
>
> On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz <oliver...@tu-dortmund.de 
> <javascript:>> wrote:
>
>> Hi Yichao
>>
>> I get that - I was just curious why (and I guess there's likely a very 
>> good reason for it). My intuition would be that a non-GCed interned string 
>> type could be represented by a bitstype (i.e. a pointer or index to the 
>> string table). So I was surprised that Symbol is an object reference and 
>> wanted to understand this a bit better.
>>
>
> It's a pointer to managed memory with tag that's all what's needed for it 
> to be a !pointerfree type. There are way more things that we don't GC and 
> it has nothing to do with whether it's a isbits type or not.
>  
>
>>
>>
>> Cheers,
>>
>> Oliver
>>
>>
>> On Wednesday, August 17, 2016 at 3:35:41 PM UTC+2, Yichao Yu wrote:
>>>
>>>
>>> > PS: Yes, symbols in Julia should be bitstypes.
>>>
>>> No, it's a object reference and isn't a `isbits()` type.
>>>
>>>
>>>>
>>>> On Wed, Aug 17, 2016 at 8:26 AM, Cedric St-Jean <cedric...@gmail.com> 
>>>> wrote:
>>>>
>>>>> Good points. 
>>>>>
>>>>> Given that symbols have a name which is a string, I don't see how they 
>>>>> could be a bits-type unless they just became numbers to index into a 
>>>>> global 
>>>>> array somewhere...... i.e. a pointer. Stack-allocating non-bits-type 
>>>>> immutables is on the roadmap to 1.0, so that should solve your problems.
>>>>>
>>>>> Maybe you can solve the CategorizedPoint problem by using an @enum.
>>>>>
>>>>> On Wed, Aug 17, 2016 at 6:48 AM, Oliver Schulz <
>>>>> oliver...@tu-dortmund.de> wrote:
>>>>>
>>>>>> Hello Andreas,
>>>>>>
>>>>>> consider iterating over a Dict{Symbol,Int64}:
>>>>>>
>>>>>> d = Dict(:foo => 42, :bar => 77)
>>>>>> for x in d println("$(typeof(x)), $(isbits(x))") end
>>>>>>
>>>>>>
>>>>>> During iteration, a lot of stack allocated "Pair{Symbol,Int64}" 
>>>>>> objects are created. That is very bad for performance.
>>>>>>
>>>>>> immutable CategorizedPoint
>>>>>>     x::Float64
>>>>>>     y::Float64
>>>>>>     category::Symbol
>>>>>> end
>>>>>>
>>>>>>
>>>>>> Also, consider a (hypothetical) data type for categorized points 
>>>>>> (with a finite number of categories - but extensible, so that Symbol is 
>>>>>> a 
>>>>>> better fit than using an enum):
>>>>>>
>>>>>> immutable CategorizedPoint
>>>>>>     x::Float64
>>>>>>     y::Float64
>>>>>>     category::Symbol
>>>>>> end
>>>>>>
>>>>>> I would definitely want this to be a bits-type, and not have every 
>>>>>> instance heap-allocated.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>>
>>>>>> On Wednesday, August 17, 2016 at 11:44:13 AM UTC+2, Andreas Lobinger 
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello colleague,
>>>>>>>
>>>>>>> On Wednesday, August 17, 2016 at 11:12:51 AM UTC+2, Oliver Schulz 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Sure -  I was assuming that as Symbol (as an interned string) is 
>>>>>>>> basically just a pointer. So comparisons are O(1), etc. What I'd like 
>>>>>>>> to 
>>>>>>>> understand is, why can't it be a bitstype? Currently, it's not, so 
>>>>>>>> Symbol 
>>>>>>>> cannot be used in a lightweight (i.e. stack-allocated) immutable type. 
>>>>>>>> I 
>>>>>>>> assume there's a good reason for it, I just want to understand why.
>>>>>>>>
>>>>>>>
>>>>>>> Could you make an example how you would like to use Symbol in 
>>>>>>> lightweight types?
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Erik Schnetter <schn...@gmail.com> 
>>>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>>>
>>>
>>>
>

Reply via email to