Schrift
[thread]5662[/thread]

Archive-Flag (Win32::File): Archive-Flag löschen (Seite 3)

Leser: 2


<< |< 1 2 3 >| >> 27 Einträge, 3 Seiten
Crian
 2003-09-11 15:05
#80634 #80634
User since
2003-08-04
5866 Artikel
ModeratorIn
[Homepage]
user image
achso, sag das doch ;-)

[quote=Dubu,11.09.2003, 08:12]Hier muss man wirklich mehr Stellen hinschreiben, um das Einerkomplement ~3 sehen zu koennen.

[...]

Code: (dl )
1
2
3
3           <=> 00000011
~3 <=> 11111100
...
[/quote]
Ist denn bei Perl festgelegt, wie die Komplemente gebildet werden (auf wieviele binäre Stellen)?\n\n

<!--EDIT|Crian|1063278610-->
s--Pevna-;s.([a-z]).chr((ord($1)-84)%26+97).gee; s^([A-Z])^chr((ord($1)-52)%26+65)^gee;print;

use strict; use warnings; Link zu meiner Perlseite
eisbeer
 2003-09-11 21:01
#80635 #80635
User since
2003-08-29
347 Artikel
BenutzerIn
[Homepage] [default_avatar]
Ach ja, sorry: Den anderen natürlich auch besten Dank
Die meisten PC Probleme befinden sich zwischen Bildschirm und Stuhl...
esskar
 2003-09-11 21:08
#80636 #80636
User since
2003-08-04
7321 Artikel
ModeratorIn

user image
[quote=Crian,11.09.2003, 13:05]Ist denn bei Perl festgelegt, wie die Komplemente gebildet werden (auf wieviele binäre Stellen)?[/quote]
das geht wohl "automatisch"; wie bei c/c++ auch...

Code: (dl )
1
2
3
4
5
6
7
unsigned char byte = 255;
unsigned int uint = 65535;
unsigned long ulong = 4294967295;

byte & ~3;
uint & ~3;
ulong & ~3;


ist immer richtig!
esskar
 2003-09-11 21:12
#80637 #80637
User since
2003-08-04
7321 Artikel
ModeratorIn

user image
bzw.
in c/c++ ist es wohl eher immer so,
dass auf 32-bit immer gefüllt wird und dann je nach bedarf abgeschnitten wird;
bei einer 32-bit-cpu ist das eh am schnellsten...
deswegen sollte man, wenn man bei Komma-Zahlen in c/c++ immer mit Complex typen arbeiten, dann mit double und dann mit float gdw. man performance raushohlen will!
Crian
 2003-09-11 22:26
#80638 #80638
User since
2003-08-04
5866 Artikel
ModeratorIn
[Homepage]
user image
Ja. Also wird Perl das vermutlich auch intern auf 32 bit (oder 64 bit, falls ein 64-bit-C-Compiler zugrunde liegt?) berechnen.

Hmm... das mit den 64 bit ist wohl Unsinn, schließlich nimmt Perl den C-Compiler ja nicht als Innenleben mit, sondern wird nur auf dem selben compiliert...
s--Pevna-;s.([a-z]).chr((ord($1)-84)%26+97).gee; s^([A-Z])^chr((ord($1)-52)%26+65)^gee;print;

use strict; use warnings; Link zu meiner Perlseite
Dubu
 2003-09-12 01:44
#80639 #80639
User since
2003-08-04
2145 Artikel
ModeratorIn + EditorIn

user image
[quote=Crian,11.09.2003, 13:05]Ist denn bei Perl festgelegt, wie die Komplemente gebildet werden (auf wieviele binäre Stellen)?[/quote]
Ja und nein. ;-)
[quote=Symbolic Unary Operators,perlop]
Unary "~" performs bitwise negation, i.e., 1's complement. [...] Note that the width of the result is platform-dependent: ~0 is 32 bits wide on a 32-bit platform, but 64 bits wide on a 64-bit platform, so if you are expecting a certain bit width, remember use the & operator to mask off the excess bits.
[/quote]
Das sollte man auch im Hinterkopf behalten, wenn man damit rechnet, denn ob Perl eine Zahl als Integer oder Double speichert, kann man ihr von aussen ja nicht ansehen:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
[...]
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8,
[...]

$ perl -le 'print ~0'     # Integer, 32-Bit-Plattform
4294967295

$ perl -le '$i=1_000_000_000; print ~~$i'    # doppelt negiert => gleicher Wert wie vorher
1000000000

$ perl -le '$i=8_000_000_000; print ~~$i'     # Zu gross fuer einen Int!
4294967295     # Ups!

Das letzte Ergebnis ist dann doch ueberraschend, denn es sieht so aus, als ob vorher eine 0 in $i gestanden haette, was aber nicht der Fall war.

Was da intern passiert kann man sich ungefaehr mit Devel::Peek anschauen:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ perl -MDevel::Peek -le '$i=8_000_000_000; print Dump($i); \
     print ~~$i; print Dump($i)'

SV = NV(0x8175f88) at 0x8170fe8
 REFCNT = 1
 FLAGS = (NOK,pNOK)
 NV = 8000000000

4294967295
SV = PVNV(0x818d040) at 0x8170fe8
 REFCNT = 1
 FLAGS = (NOK,pIOK,pNOK,IsUV)
 UV = 4294967295
 NV = 8000000000
 PV = 0

Man sieht: Waehrend direkt nach der Zuweisung unsere skalare Variable (SV) $i intern als Double Float (NV) aufgefuehrt wird - klar, es ist zu lang fuer einen Integerwert - haben wir nach der print-Anweisung auf einmal neben dem Double noch einen unsigned Int (UV) und einen Stringwert (PV) fuer $i, obwohl die Variable selber nicht veraendert wurde. Ich kenne mich mit den Perl-Interna nicht genug aus, um das korrekt zu interpretieren, aber ich nehme an, dass Perl das bitweise Inverse nicht aus einem NV berechnen kann, sondern nur aus einem IV oder UV. Woher der PV dabei kommt, ist mir aber schleierhaft. Die Flags sagen interessanterweise aus, dass der NV weiterhin gueltig ist, aber intern (privat) noch ein Int, der unsigned ist, wenn ich das richtig interpretiere (pIOK, IsUV). Der auf einmal gefuellte Stringwert (PV) taucht in den Flags aber nicht auf.

Ebenfalls lustig wird es, wenn man sich anschaut, wie die Ergebnisse von ~$i und ~~$i an andere Variablen zugewiesen werden:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
$ perl -MDevel::Peek -le '$i=8_000_000_000; print Dump($i); \
   $j= ~$i; print Dump($i), Dump($j); \
   $k = ~~$i; print Dump($i), Dump($k)'

SV = NV(0x8175fe8) at 0x8171048
 REFCNT = 1
 FLAGS = (NOK,pNOK)
 NV = 8000000000

SV = PVNV(0x818d050) at 0x8171048
 REFCNT = 1
 FLAGS = (NOK,pIOK,pNOK,IsUV)
 UV = 4294967295
 NV = 8000000000
 PV = 0
SV = IV(0x817308c) at 0x81710c0
 REFCNT = 1
 FLAGS = (IOK,pIOK)
 IV = 0

SV = PVNV(0x818d050) at 0x8171048
 REFCNT = 1
 FLAGS = (NOK,pIOK,pNOK,IsUV)
 UV = 4294967295
 NV = 8000000000
 PV = 0
SV = IV(0x8173098) at 0x8176c4c
 REFCNT = 1
 FLAGS = (IOK,pIOK,IsUV)
 UV = 4294967295

In $j ist also ein Int, in $k ein unsigned Int, das Inverse von $i offensichtlich 0 und dessen Inverses (wie dann zu erwarten) 0xFFFFFFFF.

Manchmal graut es mir vor dem, das Perl intern so treibt... ;)
Wer sich mit Perls Opcodes auskennt, kann ja mal das erste Beispiel mit perl -MO=Concise durchnudeln und etwas mehr dazu erzaehlen. :)

Ach ja: Ich halt's fuer einen Bug.
Crian
 2003-09-14 01:39
#80640 #80640
User since
2003-08-04
5866 Artikel
ModeratorIn
[Homepage]
user image
Urgs? Das ist ja unschön. Aber vielen Dank für die ausführliche Darstellung :-)
s--Pevna-;s.([a-z]).chr((ord($1)-84)%26+97).gee; s^([A-Z])^chr((ord($1)-52)%26+65)^gee;print;

use strict; use warnings; Link zu meiner Perlseite
<< |< 1 2 3 >| >> 27 Einträge, 3 Seiten



View all threads created 2003-08-27 00:31.