Was kapierst Du daran nicht? Das sind ja relativ sinnlose Metriken.

Das mit dem 31.03. kam nur dadurch zustande, dass in Wien schon 01.04. war, in Ami-Land (wo der Server von use.perl.org steht) aber noch nicht...

ok -.- ich hab nicht auf den link geklickt, und somit nur den anfang gelesen :P habs verpeilt\n\n

<!--EDIT|vayu|1175511125-->

[quote=docsnyder,02.04.2007, 08:55][...]

Quote

$n&1

Autsch, das kann ins Auge gehen, denn das hängt davon ab, wie Zahlen intern repräsentiert sind, d.h. das klappt nicht mit jeder Zahlendarstellung und ist zudem noch plattformabhängig.
[...][/quote]
Unsinn. Egal wie eine Architektur die Bits in den Registern oder im Speicher anordnet, so sind sie auf jeden Fall bei allen Zahlen in der gleichen Reihenfolge abgelegt, also funktioniert die AND-Operation einwandfrei.

Es gibt nur dann Probleme, wenn entweder einer der Operanden gar kein Integer ist, oder wenn Binärdaten verschiedener Architekturen miteinander gemischt werden -- zum Beispiel weil man mit unpack herumgespielt hat. In letzterem Falle funktioniert die Methode mit dem Modulo-Operator aber genauso wenig.

Output:

Quote

---------- Perl ----------
AND: ungerade
MODULO: gerade
                Rate modulo_test    and_test
modulo_test  836470/s          --        -27%
and_test    1152738/s         38%          --

Output completed (10 sec consumed) - Normal Termination

Mein Vorredner hat meinen Code ja schon verteidigt :)

..ausserdem: "modulo" funktioniert irgendwo zwischen 2^51 und 2^52 nicht mehr ohne Zusatzmodule richtig, "and" schon .. ^^
..wie man an den unterschiedlichen Ergebnissen sehen kann.
Achja, der Geschwindigkeitsunterschied zwischen And und Modulo wächst mit der Grösse der Zahl; Modulo wird immer langsamer.\n\n

<!--EDIT|GoodFella|1175540884-->

@murphy

Quote

Unsinn. Egal wie eine Architektur die Bits in den Registern oder im Speicher anordnet, so sind sie auf jeden Fall bei allen Zahlen in der gleichen Reihenfolge abgelegt, also funktioniert die AND-Operation einwandfrei.

Ja, in der gleichen Reihenfolge sind Bits schon abgelegt (sieht man mal von MSB und LSB ab, denn das aufzudröseln obliegt Perl), nein, mein Einwand bezieht sich ja auch nicht auf die "Reihenfolge" von Bits, sondern auf deren Bedeutung (nicht Syntax, sondern Semantik (dieser Unterschied sollte schon klar sein! )), aber nicht in der gleichen "Repräsentation"( ! ). Z.B. gibt es eine Repräsentation von Integers, bei der es sowohl +0 als auch -0 gibt. Negative und positive Zahlen sind in dieser Darstellung in ihrem Niederwertigsten Bit eben nicht gleich, d.h. "3&1" ist verschieden von "-3&1" (und doch sind beide "ungerade"). Es kommt also sehr wohl auf die interne Repräsentation von Zahlen an. Das ist in verschiedenen Informatik-Büchern nachzulesen (bitte nötige mich nicht dazu, den Nachweis zu erbringen. Ich weiß nicht "wo", aber ich weiß "daß" ! ).

Wie das nach pack und unpack ist, weiss ich nicht, aber auf jeden Fall führt Modulo eine "arithmetische" Operation durch und "muß" daher zum richtigen Ergebnis führen (wenn es sich bei dem Argument denn um eine Zahl handelt und nicht etwa um ein pack-bit-gedrösel), während das eine "boolsche" Operation (wie "&") eben gerade "nicht" tut, weil sie auf Bit-Ebene operiert.

Sorry, Murphy, aber es ist "wirklich" so!

@GoodFella

Schön, es ist ja unbestritten, daß "&" auf den meisten Plattformen das tut, was Du denkst (Dein Beispiel in Ehren, aber es hat eben nur eine Bedeutung für Deine Plattform, nicht für den allgemeinen Fall, um den es hier geht).

Ich glaube, es ist allgemein nicht so sehr im Bewußtsein von Programmierern, was sich auf der untersten Ebene eines Rechners abspielt (heute weiß doch keiner mehr so richtig, was ein Compiler eigentlich so alles tut und wie er Dinge auf Maschinen-Ebene abbildet). Auch der Unterschied zwischen "arithmetischen" Operationen (auf der Abstraktion eines Zahlenmodells) und "boolschen" Operationen auf Bit-Level (niederste Abstraktions-Stufe und daher plattformabhängig ! ), bzw. der "Unterschied" der jeweiligen Abstraktionsebene scheint nicht immer ganz durchzudringen.

Denkt bitte mal drüber nach, bevor ihr "Gegenfeuer" gebt. Ich äußere meine Bedenken nicht ohne Grund, d.h. ich bin keiner von denen, die mal so auf die Schnelle was posten, weil man sich etwas nicht vorstellen kann.

See (e.g.): http://www.gdv.informatik.uni-frankfurt.de/lehre....pen.pdf

Greetz, Doc\n\n

<!--EDIT|docsnyder|1175543048-->

[quote=docsnyder,02.04.2007, 21:34][...] mein Einwand bezieht sich ja auch nicht auf die "Reihenfolge" von Bits, sondern auf deren Bedeutung (nicht Syntax, sondern Semantik (dieser Unterschied sollte schon klar sein! )), aber nicht in der gleichen "Repräsentation"( ! ). Z.B. gibt es eine Repräsentation von Integers, bei der es sowohl +0 als auch -0 gibt. Negative und positive Zahlen sind in dieser Darstellung in ihrem Niederwertigsten Bit eben nicht gleich, [...][/quote]
Hmm, ich muss zugeben, bei komischen Darstellungen negativer Zahlen kann's auch Probleme geben.

Aber ich kenne eigentlich gar kein modernes System mehr, dass etwas anderes als eine Zweierkomplementdarstellung für negative Integer benutzt und Maschinenwortgrößen hat, die aus einer Zweierpotenz von Bits bestehen.

@murphy

Ja, aus Zweierpotenzen bestehen sie alle (das ist das Wesen der Informatik ! ).

Nein, es geht vielmehr darum, "wie" ein Bitmuster "interpretiert" werden und nicht alle Maschinen sind X86-Rechner oder Linux-Systeme (es gibt viele Ansätze wie Zahlen repräsentiert werden können und es gibt viele Plattformen, welche dies auf verschiedenste Weisen umsetzen). Ja, es stimmt, daß Euer Ansatz (Deiner und der von GoodFella) "in der Regel" aufgeht, aber er ist bitteschön nicht "allgemeingültig" und schon garnicht "plattformunabhängig".

Wie gesagt: in der Regel funktioniert das ($n&1), aber eben nur in der Regel und nicht im Allgemeinen.

Viele Grüsse, Doc

Wie wäre es mit abs($n)&1 ? Benchmarktechnisch ist das minimal schneller als $n%2.

Ich denke, wenn man davon ausgeht, dass die Eingabezahl ein Integer ist, funktioniert das immer. Bin aber an Gegenbeispielen interessiert.

Achja und $n%2 funktioniert auch nicht im Allgemeinen, wie mein Beispiel gezeigt hat. Nach der Methode ist die Zahl 19229024324098347987343 nämlich fälschlicherweise gerade.\n\n

<!--EDIT|GoodFella|1175551032-->

[quote=renee,02.04.2007, 09:02]@doc: Ich hab's auch erst geschluckt. Aber noch schlimmer hat mich Thomas Klausner erwischt. Sein April-Scherz war noch besser (siehe http://use.perl.org/~domm/).

Das passiert wohl wenn man ernsthaft arbeitet und nicht auf den Kalender achtet. Und dass wo ich doch so gerne die Leute verar****.[/quote]
Oder der hier: http://www.ccc.de/updates/2007/bundestrojaner-elster

@GoodFella

Quote

Achja und $n%2 funktioniert auch nicht im Allgemeinen, wie mein Beispiel gezeigt hat. Nach der Methode ist die Zahl 19229024324098347987343 nämlich fälschlicherweise gerade.

Das liegt schlicht und ergreifend daran, daß die gewählte Zahl den Wertebereich einer Integer-Variablen auf Deiner Maschine übersteigt.


ergibt


d.h. die letzten (=niederwertigsten) Stellen können nicht mehr dargestellt werden und sind daher Null. (Der Genauigkeitsbereich von Zahlen bei deren Darstellung in Rechnern ist eben endlich)

Daß Dein Beispiel mit AND das richtige Ergebnis liefert ist Zufall, denn Du wertest das niederwertigste Bit der darstellbaren Bits aus, nicht das niederwertigste Bit der Zahl an sich. Wenn Du's nicht glaubst, dann versuche das mal mit


Die &-Methode meint nämlich, die Zahl sei ungerade.

Quote

Wie wäre es mit abs($n)&1 ? Benchmarktechnisch ist das minimal schneller als $n%2.

Wie gesagt, i.a. kannst Du das (aus den genannten Gründen) nicht auf Bit-Ebene machen. Aber irgendwie scheinst Du Dich der Begründung zu verschliessen, denn daraus geht klar hevor, warum man das nicht so machen kann.

Gruss, Doc

P.S. Wie gesagt, in der Regel klappt's ja mit "&", aber es ist eben nicht portabel, "%" hingegen schon.\n\n

<!--EDIT|docsnyder|1175587456-->