Re: Re: Re: why is this code bad under -w option?

Color me crazy, but why do you want to spend the time calculating 2**30 when you may not even use it?!?

% perl -MO=Deparse -e 'print 2**30'
print 1073741824;
-e syntax OK
[download]

(1) Calculating 2 ** $n, where n is a human-scale integer, is ridiculously easy and cheap for computers to do. It's just a bit shifting operation.

(2) Sub-expressions consisting of constants, such as (2**30) are computed during the compilation stage, not the runtime stage, as demonstrated above. In Perl this doesn't matter that much for runtime savings, since you must compile on every run, but why not use Perl's compiler to do the work instead of expressing yet more (possibly buggy) Perl code to be interpreted to accomplish the same calculation?

(3) Yes, I said possibly buggy. In your first map definition, you define KB, MB and GB as consecutive multiples of ten, not consecutive powers of 1000. If a maintenance programmer would find the numeric literal or simple expression more readable than the code that derives those values, please, use the numbers!

Update: Okay, you wanted 10, 20, 30 for KB, MB, GB, just to do a runtime 2**$e later. I still say this doesn't save resources and it doesn't make it more readable. But I'll grant it's what you intended, and not a bug. :)

--
[ e d @ h a l l e y . c c ]

Comment on Re: Re: Re: why is this code bad under -w option? Select or Download Code

Replies are listed 'Best First'.
Re4: why is this code bad under -w option? by dragonchild (Archbishop) on Jul 28, 2003 at 17:46 UTC
In your your first map definition, you define KB, MB and GB as consecutive multiples of ten, not consecutive powers of 1000. I'm storing the powers, not the values. So, the powers are 10, 20, and 30. I then take it to the power later. Thus, it's not buggy (at least from an analysis point of view). I was suggesting another solution. In no way do I ever say that you have to do it this way or I'll come over to your house with Vino and Guido to break your kneecaps. :-) And, in fact, you're right about calculating the values ahead of time, but not for the reason you think. The best reason is if the requirements change and there's a new block size called HH that resolves to 734623 bytes. My way is a little obfuscated. Your way is more explicit. Good call! ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]

Replies are listed 'Best First'.

Re4: why is this code bad under -w option?
by dragonchild (Archbishop) on Jul 28, 2003 at 17:46 UTC

In your your first map definition, you define KB, MB and GB as consecutive multiples of ten, not consecutive powers of 1000.
I'm storing the powers, not the values. So, the powers are 10, 20, and 30. I then take it to the power later. Thus, it's not buggy (at least from an analysis point of view).
I was suggesting another solution. In no way do I ever say that you have to do it this way or I'll come over to your house with Vino and Guido to break your kneecaps. :-) And, in fact, you're right about calculating the values ahead of time, but not for the reason you think. The best reason is if the requirements change and there's a new block size called HH that resolves to 734623 bytes. My way is a little obfuscated. Your way is more explicit. Good call!
------
We are the carpenters and bricklayers of the Information Age.
Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]