note Abigail-II Your <tt>dec</tt> has a problem. Anything matched by <code>/^[0-7]+$/</code> or <code>/^\d+$/</code> is going to be matched by <code>/^(0x)?[0-9A-Fa-f]+$/i</code> as well, so if you do the tests in order you present it, it'll assume either hexadecimal, or binary. Reversing the order will give a problem as well. How would you distinguish between <tt>10₁₆ == 16₁₀</tt>, <tt>10₁₀</tt>, and <tt>10₈ == 8₁₀</tt> (subscripts indicate base)? <p> Of course, as pointed out, your fallacy lies in assuming that <tt>oct</tt> and <tt>hex</tt> return decimal representations of numbers - they don't. They return <em>numbers</em>: <code> $ perl -MDevel::Peek -wle 'Dump hex 10' SV = IV(0x8192014) at 0x8181270 REFCNT = 1 FLAGS = (IOK,READONLY,pIOK) IV = 16 </code> It's a number - without a stringified valued. <p> Also, Perl already has a function to turn a number into a hexadecimal, octal or binary representation: it's called <tt>sprintf</tt>. <p> Abigail 368936 368936