Forum: Ruby format an integer

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.
Me M. (Guest)
on 2008-10-27 17:12
Hi,
this is a pretty silly question but I cannot figure it how to do.
I need to format an integer in order to have always two digits:

ex:
1 => 01
22 => 22

How can I do that in the shortest way possible?
Thanks in advance
Matthew M. (Guest)
on 2008-10-27 17:17
(Received via mailing list)
On Oct 27, 2008, at 10:11 AM, Me Me wrote:

> Hi,
> this is a pretty silly question but I cannot figure it how to do.
> I need to format an integer in order to have always two digits:
>
> ex:
> 1 => 01
> 22 => 22
>
> How can I do that in the shortest way possible?
> Thanks in advance


"%02d" % num
Me M. (Guest)
on 2008-10-27 17:33
> "%02d" % num

Thanks
Dan W. (Guest)
on 2008-10-27 17:36
(Received via mailing list)
Q_txt = res_q[0][1]
  (0..10).each do |qt|
    question_text = q_txt.scan(/\w+/)[qt]
  end

when I access question_text after, obviously it's out of scope what am I
missing here?



Kind Regards,
Dan
David A. Black (Guest)
on 2008-10-27 18:36
(Received via mailing list)
Hi --

On Tue, 28 Oct 2008, Daniel Malcolm Webb [dbw] wrote:

> Q_txt = res_q[0][1]
>  (0..10).each do |qt|
>    question_text = q_txt.scan(/\w+/)[qt]
>  end
>
> when I access question_text after, obviously it's out of scope what am I
> missing here?

Blocks have a kind of one-way valve local scope. Variables that
already exist before the block will exist in the block. Variables that
are created in the block do not survive past the block.


David
The H. (Guest)
on 2008-10-27 21:13
David A. Black wrote:
> On Tue, 28 Oct 2008, Daniel Malcolm Webb [dbw] wrote:
>> Q_txt = res_q[0][1]
>>  (0..10).each do |qt|
>>    question_text = q_txt.scan(/\w+/)[qt]
>>  end
>>
>> when I access question_text after, obviously it's out of scope what am I
>> missing here?
>
> Blocks have a kind of one-way valve local scope. Variables that
> already exist before the block will exist in the block. Variables that
> are created in the block do not survive past the block.

This is one reason I prefer {...} instead of do...end for blocks, since
for me the curly braces shout "new scope".  while...end, for...end,
until...end, if...end, unless...end do not introduce new scopes, yet
do...end does.

Though class...end, module...end, def...end also give new scopes, there
is little room for confusion because those are not control structures.
Robert K. (Guest)
on 2008-10-28 15:33
(Received via mailing list)
2008/10/27 David A. Black <removed_email_address@domain.invalid>:
>> missing here?
Not what you asked for, but: "Q_txt" != "q_txt".  Also, you should do
the scan only once - this is more efficient:

texts = res_q[0][1].scan(/\w+/)
texts.each_with_index do |question_text, qt|
   ...
end

> Blocks have a kind of one-way valve local scope. Variables that
> already exist before the block will exist in the block. Variables that
> are created in the block do not survive past the block.

Which is basically the same in many modern programming languages,
isn't it?  Of course, there are some subtleties (e.g. whether
shadowing of more local definitions is allowed etc.).

Kind regards

robert
Dan W. (Guest)
on 2008-10-28 15:54
(Received via mailing list)
Thanks Robert,

eventually managed another work around similar to yours. The Q/q was
indeed a typo that didn't make it into the final code. Help is
appreciated though :)

Kind Regards,
Dan
Joel VanderWerf (Guest)
on 2008-10-28 22:30
(Received via mailing list)
Robert K. wrote:
> 2008/10/27 David A. Black <removed_email_address@domain.invalid>:
...
>> Blocks have a kind of one-way valve local scope. Variables that
>> already exist before the block will exist in the block. Variables that
>> are created in the block do not survive past the block.
>
> Which is basically the same in many modern programming languages,
> isn't it?  Of course, there are some subtleties (e.g. whether
> shadowing of more local definitions is allowed etc.).

That rules out javascript as modern. Grrr.
This topic is locked and can not be replied to.