User since
2003-08-04
2536
Artikel
ModeratorIn
mh. aber Math::BigInt bzw. use bigint bringt auch nicht das gewünschte Ergebnis:
use Math::BigInt;
$x = Math::BigInt->new("4653896912");
$x->brsft("13");
print $x->bstr;
bringt: 568102
aber in php:
<?
echo (4653896912 >> 13);
?>
bringt 43814.
any ideas?
User since
2003-08-04
7321
Artikel
ModeratorIn
stimmt schon:
unsigned __int64 num = 0x11564D4D0L; #4653896912
unsigned int64 shifted = (num >> 13);
printf("%u\n", shifted); #568102
bzw.
100010101011001001101010011010000 #4653896912
10001010101100100110 #568102
man sieht schön, dass die letzten 13 bytes "verschwunden" sind
:) also\n\n
<!--EDIT|esskar|1089224294-->
User since
2003-08-04
2536
Artikel
ModeratorIn
ja, ok, das bedeutet, dass es generell funktioniert; was mir aber am herzen liegt, ist das verhalten von php und bash (und und und, kA, wer das wie macht) zu haben, nicht das korrekte perl-ergebnis, dass aber vom php/bash-ergebnis abweicht....
User since
2003-08-04
7321
Artikel
ModeratorIn
und jetzt seh ich auch wie das ergebnis von php und bash zu stande kommt
print ((4653896912 - 4294967296) >> 13);
heißt also, perl arbeitet mit "unsigned" und php und bash wohl mit "signed"
User since
2003-11-28
3645
Artikel
ModeratorIn
Wenn ich die Sourcen von perl richtig deute, dann versucht perl so lange wie moeglich mit Integern zu arbeiten. Wenn das mit signed nicht moeglich ist, wird als letzte Moeglichkeit unsigned verwendet, anstelle gleich floats zu verwenden. Siehe auch PERL_PRESERVE_IVUV in den Sourcen.
User since
2003-08-04
7321
Artikel
ModeratorIn
das solange nicht minus gerechnet oder eine negative zahl in "benutzt" wird, es immer unsigned ist... vorallem beim überlauf