On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz <
oliver.sch...@tu-dortmund.de> 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/
>>>
>>
>>
