> unless they just became numbers to index into a global array somewhere
I had assumed that this is basically what Symbols (being interned strings)
are.
> Maybe you can solve the CategorizedPoint problem by using an @enum.
For a fixed set of categories, of course, but not otherwise.
> Stack-allocating non-bits-type immutables is on the roadmap to 1.0
I know - but what if I want to put the CategorizedPoint values into an
array? :-)
On Wednesday, August 17, 2016 at 2:27:09 PM UTC+2, Cedric St-Jean 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
> <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?
>>>
>>>
>
