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.
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 <[email protected] >> <javascript:>> 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 <[email protected] >>> <javascript:>> 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 <[email protected] <javascript:>> >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> > >
