http://qs321.pair.com?node_id=368942


in reply to A philosophical pondering concerning hexes

I've often felt that base manipulation was one of perl's shortcomings -- not because it can't do it just because it's difficult and, as you point out, the functions work in reverse.

I don't want to see your magic function because we'd then have:

dec(998) == 998 dec(999) == 999 dec(1000) == 8 dec(1001) == 9 dec(1002) == 514
which I'm sure you'll agree is just wrong.

I'd prefer that the existing functions did what they appear to do: hex() returns a hexidecimal representation of the input data and oct() returns an octal representation. Similarly a bin() function should return a binary representation.

As changing now would be an absolute backward-compatability nightmare, I'd suggest using the full names for decimal-to-base-n conversion: hexidecimal(255) eq 'FF'.

We might also include generic base manipulator, but it's probably more a loadable (module) function (the functionality below probably already exists in a module, I haven't checked):

# changebase($number, $from[, $to]); print changebase(255, 10, 16); # FF print changebase(0xFF, 16, 10); # 255 print changebase('FF', 16); # assume change to base 10 when no 'to' i +s supplied # 255 print changebase('FF', 16, 2); # 11111111
An OO module could even be more transparent:
use Base; $hex = new Base 16 => 'FF'; print $hex; # Stringify # FF print $hex->binary; # Return value only ($hex->binary is an alias f +or $hex->base 2) # 11111111 print $hex; # FF print $hex->to_binary; # Change value # 11111111 print $hex; # 11111111
After all that, my main point is that I absolutely agree that those two functions are completely non-intuitive.
"Get real! This is a discussion group, not a helpdesk. You post something, we discuss its implications. If the discussion happens to answer a question you've asked, that's incidental." -- nobull@mail.com in clpm

Replies are listed 'Best First'.
Re^2: A philosophical pondering concerning hexes
by Llew_Llaw_Gyffes (Scribe) on Aug 13, 2005 at 05:55 UTC

    You're absolutely right on the 1000/1001 etc. case, I didn't think that through far enough. I was thinking more in terms of "This is wrong, what would be a better approach?" than specific implementations.

    A better implementation would be to add functions like oct2dec(), hex2dec(), dec2binary() ....