syntax question:
i have a 'case' expression:
case number
when 1: var = 'one'
when 2: var = 'two'
when 3: var = 'three'
else
var = 'else'
end
but instead of assigning the 'var' variable for each 'when', what is the
way to write the case statement, so i can assign 'var' at the end?
(something like
case number
when 1: 'one'
when 2: 'two'
when 3: 'three'
else
'else'
end >> var
[humm, a more elegant way]
)
--
Posted via http://www.ruby-forum.com/.
Shai Rosenfeld wrote:
case number
when 1: var = 'one'
when 2: var = 'two'
when 3: var = 'three'
else
var = 'else'
endbut instead of assigning the 'var' variable for each 'when', what is the
way to write the case statement, so i can assign 'var' at the end?
var=case number
...
end
HTH,
Sebastian
--
NP: Porcupine Tree - Start Of Something Beautiful
Jabber: sepp2k@jabber.org
ICQ: 205544826
case number
when 1: 'one'
when 2: 'two'
when 3: 'three'
else
'else'
end >> var
var = case ...
--
Posted via http://www.ruby-forum.com/\.
Shai Rosenfeld wrote:
..quick reply (didn't last a minute)
thanks.
Or...
var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
--
Phlip
Test Driven Ajax (on Rails) [Book]
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
Phlip wrote:
Shai Rosenfeld wrote:
..quick reply (didn't last a minute)
thanks.
Or...
var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
nice! 
any lead to which one is faster?
--
Posted via http://www.ruby-forum.com/\.
Shai Rosenfeld wrote:
> var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
nice!
any lead to which one is faster?
D'OH!
(There was just a big discussion on Ruby performance, or lack thereof.
Google "Performance diffrence between ifs and case", and learn A>
premature optimization is the root of all evil, and B> you can profile
each system with unit tests and Benchmark library.)
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath
O'Reilly Media - Technology and Business Training <-- assert_latest Model
Hi --
Phlip wrote:
Shai Rosenfeld wrote:
..quick reply (didn't last a minute)
thanks.
Or...
var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
nice!
any lead to which one is faster?
Some quick benchmarking suggests that for small numbers of items
they're about equal, but the case one slows down faster as the number
of choices increases, presumably because it has to do a comparison for
each one instead of just one hash fetch.
It would also depend on which one matched, though -- for example:
case 1
when 1 then "one"
when 2 then "two"
...
when 1000000 then "one million"
end
will match on the first comparison, so it doesn't matter that there
are a million of them.
David
On Thu, 2 Aug 2007, Shai Rosenfeld wrote:
--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
Phlip wrote:
Shai Rosenfeld wrote:
var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
nice!
any lead to which one is faster?
D'OH!(There was just a big discussion on Ruby performance, or lack thereof.
Google "Performance diffrence between ifs and case", and learn A>
premature optimization is the root of all evil, and B> you can profile
each system with unit tests and Benchmark library.)
In this case it's hash lookup vs. case scanning which is significantly different than if vs. case. Since hash lookups should be O(1) and scanning all the clauses of a case statement is O(n), using the hash would in theory be faster. However, if you're only doing it a couple times and there's a small number of cases, the overhead of creating the Hash might make the case statement faster. In fact, constructing the hash the first time will be at least O(n), so the hash method will almost definitely be slower if you only do the lookup once. Of course, as you said, the best way to find out is to benchmark it yourself.
Hi --
Shai Rosenfeld wrote:
var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
nice!
any lead to which one is faster?
D'OH!
(There was just a big discussion on Ruby performance, or lack thereof.
Google "Performance diffrence between ifs and case", and learn A>
premature optimization is the root of all evil, and B> you can profile
each system with unit tests and Benchmark library.)
Not all optimization is premature, and it's not the case that no
information is available to people before they start to code
something, or even just out of academic or scientific interest quite
apart from any particular coding project.
There's a long history of quite interesting discussion about
performance on this list, often involving benchmark reports (and
therefore explicitly in the knowledge of the relevance of the
benchmarking process). Those discussions can be very illuminating,
and I'd prefer not to see them routinely squashed before they have a
chance to start.
David
On Thu, 2 Aug 2007, Phlip wrote:
--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
dblack@rubypal.com wrote:
Hi --
Shai Rosenfeld wrote:
var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
nice!
any lead to which one is faster?
D'OH!
(There was just a big discussion on Ruby performance, or lack thereof.
Google "Performance diffrence between ifs and case", and learn A>
premature optimization is the root of all evil, and B> you can profile
each system with unit tests and Benchmark library.)Not all optimization is premature, and it's not the case that no
information is available to people before they start to code
something, or even just out of academic or scientific interest quite
apart from any particular coding project.There's a long history of quite interesting discussion about
performance on this list, often involving benchmark reports (and
therefore explicitly in the knowledge of the relevance of the
benchmarking process). Those discussions can be very illuminating,
and I'd prefer not to see them routinely squashed before they have a
chance to start.
They're only going to get more interesting in future, as we have more different implementations to play with, too...
On Thu, 2 Aug 2007, Phlip wrote:
--
Alex
