Hi Eric,
nice - this is exactly what I meant. I wonder if Julia Symbols
themselves could become like this in the future.
Cheers,
Oliver
On 17.08.2016 18:44, Erik Schnetter wrote:
See <https://github.com/eschnett/ValueSymbols.jl> for what I had in mind.
-erik
On Wed, Aug 17, 2016 at 10:32 AM, Yichao Yu <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz
<[email protected] <mailto:[email protected]>>
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
<[email protected]> 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]> wrote:
Hello Andreas,
consider iterating over a Dict{Symbol,Int64}:
|
d =Dict(:foo =>42,:bar =>77)
forx ind 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]>
http://www.perimeterinstitute.ca/personal/eschnetter/
<http://www.perimeterinstitute.ca/personal/eschnetter/>
--
Erik Schnetter <[email protected] <mailto:[email protected]>>
http://www.perimeterinstitute.ca/personal/eschnetter/
