Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
Jeffrey Shallit
Recurrent thoughts about mathematics, science, politics, music, religion, and
Recurrent thoughts about mathematics, science, politics, music, religion, and
Recurrent thoughts about mathematics, science, politics, music, religion, and
Recurrent thoughts about ....
-
Jeffrey Shallit
American mathematician, professor of computer science at a major Canadian university, & skeptic.
All comments are moderated to remove spam and duplication. Please be patient; your comment will usually appear within 12 hours.
7 comments:
Googling for that monstrous number shows lots and lots of places affected. But what on earth is it?
It's 0x03157de000000000, with lots of zeros at the end. But so far as I can tell, 0x03157de0 isn't anything very interesting.
There's no obvious IEEE floating-point screwup that would look like this. (For instance, interpreting a NaN as an ordinary floating-point value doesn't produce anything in that range.)
It's close to being what you'd get from converting 4 x 10^17 from Fahrenheit into Celsius, but only to about 6 figures.
Anyone got more patience and/or ingenuity than me?
Prime factors: 2^37 x 11 x 146989
I'll keep thinking about it.
222222157650853888 decimal
... in binary
0000 0011
0001 0101
0111 1101
1110 0000
0000 0000
0000 0000
0000 0000
0000 0000
... in hex
3157DE000000000
... in Fahrenheit
399999883771537000
... ... in binary
0000 0101
1000 1101
0001 0101
1100 0110
0110 0110
0110 0110
0110 0110
1000 0000
... ... in hex
58D15C666666668
I thought about what might happen if a time stamp ended up in the wrong place in a database so I looked at the dates and times google cached results with this number but I found no correlations.
222222157650853888 alone doesn't make sense as a unix time stamp (its like 7,000,000,000 + years) but... the first two bytes of the number (in hex reading from the left) 3157DE00 is
827,842,048 seconds
or
03 / 26 / 96 @ 6:07:28am as unix time stamp
or
26.2332918 years
Obviously no fruitful results. I only post so others don't bother with these particular trains of thought or others may see something I missed.
The zeroes at the end of the number seem to indicate that it's the result of converting a 32-bit float to an integer.
And indeed, the following C program produces the number:
#include <stdio.h>
main() {
float a = 3.999999e17;
a = a*5/9;
printf("%.0f\n", a);
}
The constant really is 3.999999e17, since 3.9999987e17 and 3.9999991e17 produce the wrong result (and I omitted the subtraction of 32 because it has no effect on a large 32-bit float).
I like the 'feels like' row: is '-' the sound you make at that temperature?
Well, likely it is because the applet is written in
Java, which speaks only IEEE big endian,
and it got its number from a IEEE little endian
source.
Ah! The big-endian single-precision floating point representation of 222222157650853888 consists of printable characters: \E_x
It's probably just a coincidence that the number is so close to (20/9)*10^17.
(And it doesn't seem to be a big-endian vs. little-endian problem, because you get an even larger number if you reverse the bytes.)
Post a Comment