Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Dynamically generate a symbol name

Reply
Thread Tools

Dynamically generate a symbol name

 
 
Max Williams
Guest
Posts: n/a
 
      12-11-2007
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 bject0, bject2 ... bject9,
how can i do something like

10.times do |n|
do_something_with(bject#{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/.

 
Reply With Quote
 
 
 
 
Sam Smoot
Guest
Posts: n/a
 
      12-11-2007
On Dec 11, 5:51 am, Max Williams <(E-Mail Removed)> 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 bject0, bject2 ... bject9,
> how can i do something like
>
> 10.times do |n|
> do_something_with(bject#{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.
 
Reply With Quote
 
 
 
 
Trans
Guest
Posts: n/a
 
      12-11-2007


On Dec 11, 6:51 am, Max Williams <(E-Mail Removed)> 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 bject0, bject2 ... bject9,
> how can i do something like
>
> 10.times do |n|
> do_something_with(bject#{n} => "foo")
> end


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

T.

 
Reply With Quote
 
Gary Wright
Guest
Posts: n/a
 
      12-11-2007

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

 
Reply With Quote
 
Sam Smoot
Guest
Posts: n/a
 
      12-11-2007
On Dec 11, 9:45 am, Gary Wright <(E-Mail Removed)> 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.
 
Reply With Quote
 
Clifford Heath
Guest
Posts: n/a
 
      12-11-2007
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.
 
Reply With Quote
 
Eivind Eklund
Guest
Posts: n/a
 
      12-12-2007
On Dec 11, 2007 4:45 PM, Gary Wright <(E-Mail Removed)> 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.

 
Reply With Quote
 
Gary Wright
Guest
Posts: n/a
 
      12-12-2007

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

 
Reply With Quote
 
Eivind Eklund
Guest
Posts: n/a
 
      12-12-2007
On Dec 12, 2007 9:40 AM, Gary Wright <(E-Mail Removed)> 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.

 
Reply With Quote
 
Max Williams
Guest
Posts: n/a
 
      12-12-2007

cool, thanks guys.
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(Encryption Package) error: cannot find symbol symbol: class BaseNCode clusardi2k@aol.com Java 6 08-29-2012 08:33 PM
Why ":symbol" failed but 'symbol' successed with JRuby 1.0.3? Song Ma Ruby 2 07-20-2008 04:08 AM
How to dynamically generate function name and call it? Hemant Shah Perl Misc 11 09-28-2006 06:25 PM
How to generate variable labels for same component within a generate loop Weng Tianxiang VHDL 5 02-16-2006 01:45 PM
what's differnece between #ifdef symbol and #if defined(symbol) baumann@pan C Programming 1 04-15-2005 08:25 AM



Advertisments