Forum: Ruby sytnax

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Shai R. (Guest)
on 2007-08-02 14:02
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]

)
Sebastian H. (Guest)
on 2007-08-02 14:07
(Received via mailing list)
Shai R. wrote:

> way to write the case statement, so i can assign 'var' at the end?
var=case number
...
end


HTH,
Sebastian
Tom L. (Guest)
on 2007-08-02 14:07
> case number
> when 1: 'one'
> when 2: 'two'
> when 3: 'three'
> else
>         'else'
> end >> var

var = case ...
Shai R. (Guest)
on 2007-08-02 14:18
..quick reply (didn't last a minute)
:)

thanks.
Phlip (Guest)
on 2007-08-02 16:54
(Received via mailing list)
Shai R. wrote:

> ..quick reply (didn't last a minute)
> :)
>
> thanks.

Or...

var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')
Shai R. (Guest)
on 2007-08-02 17:17
Phlip wrote:
> Shai R. 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?
Phlip (Guest)
on 2007-08-02 18:36
(Received via mailing list)
Shai R. 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.)
Brett S. (Guest)
on 2007-08-02 20:33
(Received via mailing list)
Phlip wrote:
> 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.
unknown (Guest)
on 2007-08-02 20:59
(Received via mailing list)
Hi --

On Thu, 2 Aug 2007, Shai R. wrote:

>> 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
unknown (Guest)
on 2007-08-02 21:04
(Received via mailing list)
Hi --

On Thu, 2 Aug 2007, Phlip wrote:

> (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
Alex Y. (Guest)
on 2007-08-02 21:17
(Received via mailing list)
removed_email_address@domain.invalid wrote:
>>> any lead to which one is faster?
> 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...
This topic is locked and can not be replied to.