Dynamically generate a symbol name

Discussion in 'Ruby' started by Max Williams, Dec 11, 2007.

  1. Max Williams

    Max Williams Guest

    I'm sure this is simple but i can't work out the syntax - if i want to
    use a bunch of symbols that are named :eek:bject0, :eek:bject2 ... :eek:bject9,
    how can i do something like

    10.times do |n|
    do_something_with:)object#{n} => "foo")
    end

    ie, do the same thing with but pass through a differently named symbol
    each time?

    thanks
    max
    --
    Posted via http://www.ruby-forum.com/.
     
    Max Williams, Dec 11, 2007
    #1
    1. Advertising

  2. Max Williams

    Sam Smoot Guest

    On Dec 11, 5:51 am, Max Williams <> wrote:
    > I'm sure this is simple but i can't work out the syntax - if i want to
    > use a bunch of symbols that are named :eek:bject0, :eek:bject2 ... :eek:bject9,
    > how can i do something like
    >
    > 10.times do |n|
    > do_something_with:)object#{n} => "foo")
    > end
    >
    > ie, do the same thing with but pass through a differently named symbol
    > each time?
    >
    > thanks
    > max
    > --
    > Posted viahttp://www.ruby-forum.com/.


    :"object#{n}" is the syntax. Or just "object#{n}".to_sym.

    I would avoid doing this though. Symbols aren't meant to represent
    infinite variations. They're stored in a Hash internally, so the more
    symbols you add, the slower they get.

    So a small finite set of symbols is good. To represent environments,
    or database names, or even columns. Representing filenames as symbols,
    or user_ids, or something similarly large and near as infinite as
    makes no difference is a bad idea IMO.

    At least if I understand the mechanics of Symbol storage. And I may
    not. ;-)
     
    Sam Smoot, Dec 11, 2007
    #2
    1. Advertising

  3. Max Williams

    Trans Guest

    On Dec 11, 6:51 am, Max Williams <> wrote:
    > I'm sure this is simple but i can't work out the syntax - if i want to
    > use a bunch of symbols that are named :eek:bject0, :eek:bject2 ... :eek:bject9,
    > how can i do something like
    >
    > 10.times do |n|
    > do_something_with:)object#{n} => "foo")
    > end


    10.times do |n|
    do_something_with:)"object#{n}" => "foo")
    end

    T.
     
    Trans, Dec 11, 2007
    #3
  4. Max Williams

    Gary Wright Guest

    On Dec 11, 2007, at 7:00 AM, Sam Smoot wrote:
    >
    > :"object#{n}" is the syntax. Or just "object#{n}".to_sym.
    >
    > I would avoid doing this though. Symbols aren't meant to represent
    > infinite variations. They're stored in a Hash internally, so the more
    > symbols you add, the slower they get.


    Hash table performance shouldn't be affected by size, that is the
    whole point of using a hash table.

    The memory footprint will grow as you add symbols and
    since symbols are not garbage collected in MRI you might
    end up with a memory leak if you are constantly generating
    new symbols.

    Gary Wright
     
    Gary Wright, Dec 11, 2007
    #4
  5. Max Williams

    Sam Smoot Guest

    On Dec 11, 9:45 am, Gary Wright <> wrote:
    > On Dec 11, 2007, at 7:00 AM, Sam Smoot wrote:
    >
    >
    >
    > > :"object#{n}" is the syntax. Or just "object#{n}".to_sym.

    >
    > > I would avoid doing this though. Symbols aren't meant to represent
    > > infinite variations. They're stored in a Hash internally, so the more
    > > symbols you add, the slower they get.

    >
    > Hash table performance shouldn't be affected by size, that is the
    > whole point of using a hash table.
    >
    > The memory footprint will grow as you add symbols and
    > since symbols are not garbage collected in MRI you might
    > end up with a memory leak if you are constantly generating
    > new symbols.
    >
    > Gary Wright


    Ahh, thanks Gary. Guess that's my lack of a CompSci degree showing
    through. ;-)
     
    Sam Smoot, Dec 11, 2007
    #5
  6. Gary Wright wrote:
    > Hash table performance shouldn't be affected by size, that is the
    > whole point of using a hash table.


    Besides which any literal symbol references will probably be substituted
    by a pointer to the hash-table element at compile time. The hash table
    should only be used at compile time to provide a unique memory address.
    Obviously not in the case of :"...#{}" symbols though.

    Clifford Heath.
     
    Clifford Heath, Dec 11, 2007
    #6
  7. On Dec 11, 2007 4:45 PM, Gary Wright <> wrote:
    > On Dec 11, 2007, at 7:00 AM, Sam Smoot wrote:
    > >
    > > :"object#{n}" is the syntax. Or just "object#{n}".to_sym.
    > >
    > > I would avoid doing this though. Symbols aren't meant to represent
    > > infinite variations. They're stored in a Hash internally, so the more
    > > symbols you add, the slower they get.

    >
    > Hash table performance shouldn't be affected by size, that is the
    > whole point of using a hash table.


    The memory footprint will increase. Unless you're already past the
    limit where each cache line on average only contains one accessed
    symbol, this memory footprint increase will decrease cache locality
    which again will decrease performance. In the general case: Depending
    on hash table implementation, you could also have chaining costs as
    your hash table grows to be full (which gives conflicts that need
    either chaining, a tree, or a rebuild of the table to handle).

    "Hash table performance is not affected by size" is a simplification
    that hold when you have a pre-90s microprocessor or a microcontroller
    and the entire hash table is in memory to start with and you have no
    two entries that hash to the same slot. This is a restricted case.
    Assuming some speed loss for increased size is a good assumption.

    As for the point of a hash table, I tend to think of it as "Fast
    access to data where the ordering property don't matter" (or lookup is
    convenient on something that isn't a number).

    Eivind.
     
    Eivind Eklund, Dec 12, 2007
    #7
  8. Max Williams

    Gary Wright Guest

    On Dec 12, 2007, at 2:29 AM, Eivind Eklund wrote:
    > The memory footprint will increase.


    Yes. I said that.

    > "Hash table performance is not affected by size" is a simplification
    > that hold when you have a pre-90s microprocessor or a microcontroller
    > and the entire hash table is in memory to start with and you have no
    > two entries that hash to the same slot. This is a restricted case.
    > Assuming some speed loss for increased size is a good assumption.


    Of course. But your observations are true of any data structure that
    indexes arbitrary data and so isn't all that helpful in understanding
    what differentiates a Hash with O(1) lookup from a Tree with O(log n)
    lookup from an Array with O(n) lookup.

    Gary Wright
     
    Gary Wright, Dec 12, 2007
    #8
  9. On Dec 12, 2007 9:40 AM, Gary Wright <> wrote:
    >
    > On Dec 12, 2007, at 2:29 AM, Eivind Eklund wrote:
    > > The memory footprint will increase.

    >
    > Yes. I said that.


    And I repeated it with information about what that memory size
    increase meant, because I saw it as in conflict with what the rest of
    your text communicated, especially for those that don't know this
    stuff well. More details below.

    > > "Hash table performance is not affected by size" is a simplification
    > > that hold when you have a pre-90s microprocessor or a microcontroller
    > > and the entire hash table is in memory to start with and you have no
    > > two entries that hash to the same slot. This is a restricted case.
    > > Assuming some speed loss for increased size is a good assumption.

    >
    > Of course. But your observations are true of any data structure that
    > indexes arbitrary data and so isn't all that helpful in understanding
    > what differentiates a Hash with O(1) lookup from a Tree with O(log n)
    > lookup from an Array with O(n) lookup.


    Absolutely agreed; my point was intended to be helpful in
    understanding how real world implementations work, as I understood it
    as if we were discussing a real world implementation (in particular,
    how the Ruby interpreter works). The abstractions are also useful;
    it's just that they are not the whole world, and it is easy to miss
    how the underlying details can make the conclusion invalid because the
    abstraction breaks.

    In particular, most analysis abstracts memory as if memory had
    constant access time. Nowadays, that abstraction breaks a lot. An
    anecdotal comparison to put it in perspective: Today, main memory has
    a speed compared to the CPU that's slower than the tape drive on a VAX
    compared to the CPU of the VAX.

    Another way to get some perspective: Today, a CPU generally executes
    several instructions per clock cycle. Ten years ago (last time I
    worked on doing cycle-by-cycle optimization outside embedded systems),
    a main memory fetch ran about 70 cycles. I couldn't find any numbers
    for today - but CPU speed increase at a rate of over 1.5x per year,
    while RAM speed increase at about 1.2x per year. Very conservatively,
    a cache miss take the same time as executing 150 non-cache-missing
    pipelined instructions.

    At large scales, you'll miss the cache anyway or not get incidental
    caching, so looking at the O-time of the algorithm is sort of
    sufficient. At very small scales, you'll always hit the cache, so the
    O-time is sufficient. At the intermediate scale - and I would guess
    Ruby symbol table lookups often would fit in there - you get very
    important cache interaction effects, including effects from whether
    cache lines incidentally grab more than one item. This means that the
    "hash lookup time is O(1)" claim does not hold for that case.

    This was my point. I hope the longer and more elaborate variant help
    somebody understand something they otherwise wouldn't.

    Eivind.
     
    Eivind Eklund, Dec 12, 2007
    #9
  10. Max Williams

    Max Williams Guest

    Max Williams, Dec 12, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Weng Tianxiang
    Replies:
    5
    Views:
    1,351
    Christophe
    Feb 16, 2006
  2. baumann@pan
    Replies:
    1
    Views:
    767
    Richard Bos
    Apr 15, 2005
  3. Song Ma
    Replies:
    2
    Views:
    258
    Charles Oliver Nutter
    Jul 20, 2008
  4. Hemant Shah
    Replies:
    11
    Views:
    216
    Uri Guttman
    Sep 28, 2006
  5. Replies:
    6
    Views:
    2,019
Loading...

Share This Page