Why that's happening is that you're actually AND'ing together the bit representations of those strings. Without the quotes perl would be AND'ing the bit representations of those numbers, as integers.

In this case, under the ASCII charset the strings "123.45" and "234.56" are represented by the bits:

1        2        3        .        4        5
00110001 00110010 00110011 00101110 00110100 00110101
2        3        4        .        5        6
00110010 00110011 00110100 00101110 00110101 00110110

Thus when AND'ing them together you keep all bits which are 1 in both things as 1, and everything else becomes 0 resulting in the string "020.44" represented in ASCII with:

0        2        0        .        4        4
00110000 00110010 00110000 00101110 00110100 00110100

All this is probably not portable to systems with odd charsets like EBCDIC.

Now, if we were to AND together numbers (not strings) like say 123 and 234, we'll get a completely differnt result. For example, the numbers 123 and 234 and represented by:

123
01111011
234
11101010

Note that this is different then AND'ing together strings since we're working with numbers, not charactors. Thus the result is 106, represented by:

01101010

Another thing to note is that if you try to have perl and together non-integers like doing 123.45 & 234.56, perl appears to treat 123.45 and 234.56 as if we used int(123.45) and int(234.56), which avoids odd situations you'd get if you tried to AND floating point numbers together, because they're implemented in a way that varies greatly from machine to machine.

All bit strings here were generated with unpack "B*", ..., so have most signifigant byte first.