Dezimal->Binär

SeppJ schrieb:

Lass doch diese kryptischen Mikrooptimierungen, die der Compiler ohnehin macht

Nein, kann der Compiler nicht, weil das ein int ist und kein unsigned und deshalb das Verhalten anders ist.

(sofern sie überhaupt Sinn machen, was nicht unbedingt gesagt ist!)

Doch, hier sind sie sogar semantisch richtig. Denn der TE will ja gerade die Bits aus der Zahl extrahieren.

Btw, bin ich der einzige, der den Threadtitel seltsam findet?
val ist ja schon binär, da muss gar nichts umgerechnet werden.

Um auf die n-te Stelle zuzugreifen reicht ein val&(1<<n), was oft schneller als ein Array-Lookup ist.

EOP

Ist zwar beschränkt aber schell und benötigt kein Rumgefummel mit Schleifen oder ähnlich komplizierten Konstrukten:

line += (ich & 0x80) == 0x80 ? "1" : "0";
	line += (ich & 0x40) == 0x40 ? "1" : "0";
	line += (ich & 0x20) == 0x20 ? "1" : "0";
	line += (ich & 0x10) == 0x10 ? "1" : "0";
	line += (ich & 0x08) == 0x08 ? "1" : "0";
	line += (ich & 0x04) == 0x04 ? "1" : "0";
	line += (ich & 0x02) == 0x02 ? "1" : "0";
	line += (ich & 0x01) == 0x01 ? "1" : "0";

EOP schrieb:

Ist zwar beschränkt aber schell

Ja, schell ist es, aber schnell nur beschränkt. operator+=(const char*) ist alles, nur nicht C (und damit auch nicht schnell).

inflames2k

big B schrieb:

Btw, bin ich der einzige, der den Threadtitel seltsam findet?
val ist ja schon binär, da muss gar nichts umgerechnet werden.

Um auf die n-te Stelle zuzugreifen reicht ein val&(1<<n), was oft schneller als ein Array-Lookup ist.

Entweder musst du mich abholen und mir die Stelle zeigen an der val zu Beginn Binär ist, oder es gibt diese einfach nicht. Oder aber du hast den TE nicht verstanden. Jedenfalls ist 13 nicht dual, ich tippe eher auf dezimal.

SeppJ

inflames2k schrieb:

big B schrieb:

Btw, bin ich der einzige, der den Threadtitel seltsam findet?
val ist ja schon binär, da muss gar nichts umgerechnet werden.

Um auf die n-te Stelle zuzugreifen reicht ein val&(1<<n), was oft schneller als ein Array-Lookup ist.

Entweder musst du mich abholen und mir die Stelle zeigen an der val zu Beginn Binär ist, oder es gibt diese einfach nicht. Oder aber du hast den TE nicht verstanden. Jedenfalls ist 13 nicht dual, ich tippe eher auf dezimal.

Er meint den weit verbreiteten Irrglauben, dass Variablen in irgendeinem System gespeichert wären, aus dem man sie umrechnen müsste. Im Computer steht keine "13" als Ziffernfolge, sondern 13, die Zahl. Die 13 kann man als eine Ziffernfolge in einem beliebigen System ausgeben, aber selber ist die 13 bloß das abstrakte Konzept der Zahl, losgelöst von jeder Darstellung. Und das ist es, was im Computer gespeichert ist. 13 ist 13, das was um 1 größer ist als 12, egal, ob man "13", "IIIIIIIIIIIII", "0xD", "XIII", "1101" oder sonst etwas dazu sagt.

^

Ganz, ganz tief im Inneren hat der Computer natürlich schon irgendeine Art und Weise, seine Zahlen darzustellen. Abstrakte Konzepte können schließlich keine physikalische Realität haben. Aber ob das nun Murmeln sind, Ameisen die einem Pfad folgen oder digitalelektronische Schaltkreise, die die Zahl speichern, davon bekommt man auf Höhe der Computerprogrammierung gar nicht mehr mit und es sollte daher auch nicht weiter wichtig sein. Es erklärt bloß, wieso manche Werte wie 256 oder 65768 so oft im Computer vorkommen.^

SeppJ schrieb:

^... Es erklärt bloß, wieso manche Werte wie 256 oder 65768 so oft im Computer vorkommen.^

Also 65768 ist mir noch nicht so oft vor die Augen gekommen.

^Ok, vielleicht wenn ich bei der Aufzählung von Zweierpotenzen ganz stark schiele^

SeppJ

DirkB schrieb:

SeppJ schrieb:

^... Es erklärt bloß, wieso manche Werte wie 256 oder 65768 so oft im Computer vorkommen.^

Also 65768 ist mir noch nicht so oft vor die Augen gekommen.

^Ok, vielleicht wenn ich bei der Aufzählung von Zweierpotenzen ganz stark schiele^

Da bin ich wohl im Gehirn mit den Zeilen durcheinander gekommen . Früher konnte ich das mal auswendig, bis zu richtig hohen Werten hin. Das war nämlich bei den 16-Bit Systemen noch richtig wichtig. Die heutigen wichtigen Zahlen sind aber zu groß, um sie sich zu merken, daher nehme ich bei jeder Zahl zwischen 4000000000 und 4500000000 automatisch an, dass es exakt 2^32 (Zahl ist gerade) oder 2^32-1 (ungerade) ist, wenn ich sie sehe.

EOP

shellfisch schrieb:

EOP schrieb:

Ist zwar beschränkt aber schell

Ja, schell ist es, aber schnell nur beschränkt. operator+=(const char*) ist alles, nur nicht C (und damit auch nicht schnell).

Da hast du recht und ich nicht drauf geachtet wo es gepostet wurde.
Nimmt man eben strcat.

char line[100] = "\0";
	char ich = 30;
	strcat( line, (ich & 0x80) == 0x80 ?  "1" : "0" );
	strcat( line, (ich & 0x40) == 0x40 ?  "1" : "0" );
	strcat( line, (ich & 0x20) == 0x20 ?  "1" : "0" );
	strcat( line, (ich & 0x10) == 0x10 ?  "1" : "0" );
	strcat( line, (ich & 0x08) == 0x08 ?  "1" : "0" );
	strcat( line, (ich & 0x04) == 0x04 ?  "1" : "0" );
	strcat( line, (ich & 0x02) == 0x02 ?  "1" : "0" );
	strcat( line, (ich & 0x01) == 0x01 ?  "1" : "0" );

oder:

int i;

for( i = 0x80; i > 0; i >>= 1 )
	strcat( line, (ich & i) == i ?  "1" : "0" );

DarkShadow44

Wie wärs mit

const int length=32;

int number=7;

char Binary[length+1];
unsigned int pos=1;
for(int i=0; i<length; i++)
{
    Binary[length-i-1] = (number & pos) == 0 ? '0' : '1'; 
    pos <<=1;
}
Binary[length]='\0';

EOP

LOL, hab nicht gedacht, daß um kurz vor 5 jemand das liest.

EOP schrieb:

Nimmt man eben strcat.

Und strcat ist eine Schnelle Funktion?

EOP schrieb:

int i;
for( i = 0x80; i > 0; i >>= 1 )
	strcat( line, (ich & i) == i ?  "1" : "0" );

Sowas kommt raus, wenn man die "Strings" von C nicht verstanden hat.

EOP schrieb:

LOL, hab nicht gedacht, daß um kurz vor 5 jemand das liest.

Ich habe noch dein uneditierten Post gelesen und mich eben über den Code gewundert.

SeppJ

DarkShadow44 schrieb:

Wie wärs mit

const int length=32;

int number=7;

char Binary[length+1];
unsigned int pos=1;
for(int i=0; i<length; i++)
{
    Binary[length-i-1] = (number & pos) == 0 ? '0' : '1'; 
    pos <<=1;
}
Binary[length]='\0';

Und somit sind wir wieder da, wo der TE war, als er gefragt hat . Der Ursprungscode war eben schon ganz ok.

Aber EOP hat hoffentlich was daraus gelernt

danke für die Antworten.

Da die Frage aufkam, warum ich nicht einfach die Zahl 13, die ja im Speicher eh schon als Folge von 0 und 1 vorliegt, verwende.

Ich brauch eine exakte binäre Darstellung einer Zahl, die ich in ein BYTE Array schreibe und das klatsche ich dann auf ein (primitives) Speichermedium.
Würde ich einfach byteweise die Variable int x=13 in das Array verschieben, so hängt das Ergebnis von Dingen wie Endianess ab.

Ich hingegen möchte auf dem Speichermedium z.B. an Stelle Byte=2 im Bitbereich 3-6 den Wert 13 abspeichern. Ich berechne mir also die Binärdarstellung von 13, diese ist 1101, und nun setze ich in Byte 2 die Bits folgendermaßen:

...
Byte2
Bit1=?
Bit2=?
Bit3=1
Bit4=1
Bit5=0
Bit6=1
Bit7=?
Byte3
...

SeppJ

Dann ist dein Ursprungsalgorithmus absolut 100% ok. Im Prinzip auch alle anderen, denn ich sehe nicht, wieso hier Performance relevant sein sollte. Natürlich nicht so, wie von EOP vorgemacht, das wäre bloß Verschwendung. Aber man braucht auch keine unleserlichen Mikrooptimierungen, die vielleicht hier und dort einen einzelnen Takt sparen könnten. Das Speichermedium (selbst wenn es DRAM sein sollte) dürfte schließlich um Größenordnungen langsamer sein als ein Prozessor.

Falls es keine Überschneidungen zwischen den Bytes auf dem Speichermedium geben sollte, spielt Endianess übrigens keine Rolle und du kannst alles durch einfaches Shiften erreichen.

01000100010101010110 schrieb:

Würde ich einfach byteweise die Variable int x=13 in das Array verschieben, so hängt das Ergebnis von Dingen wie Endianess ab.

Sag das doch gleich.

Da kannst du auf so Funktionen wie man: htonl (gibts auch für Windows) zurückgreifen oder die Zahlen als Zeichenkette speichern (das ist dann langsam).

Es gibt auch noch superoptimierte Formate, die kleine Zahlen in einem Byte und grössere in mehreren speichern.

EOP

SeppJ mach mich bitte nicht weinen.
Ich kann Kritik von vielen ertragen, aber nicht von dir.

Nicht alle meine posts sind so 100% ernsthaft. Besunders nicht um 1/2 5 morgens. (Für die, die's noch nicht gemerkt haben)

SeppJ

EOP schrieb:

SeppJ mach mich bitte nicht weinen.
Ich kann Kritik von vielen ertragen, aber nicht von dir.

Nicht alle meine posts sind so 100% ernsthaft. Besunders nicht um 1/2 5 morgens. (Für die, die's noch nicht gemerkt haben)

Dafür war's dann wieder zu gut . Sah aus wie ein ernsthafter Versuch, der ausgerechnet an einer Stelle (Zeichenkettenbehandlung in C) fehlschlug, an der schon viele verzweifelt sind.

EOP

SeppJ schrieb:

EOP schrieb:

SeppJ mach mich bitte nicht weinen.
Ich kann Kritik von vielen ertragen, aber nicht von dir.

Nicht alle meine posts sind so 100% ernsthaft. Besunders nicht um 1/2 5 morgens. (Für die, die's noch nicht gemerkt haben)

Dafür war's dann wieder zu gut . Sah aus wie ein ernsthafter Versuch, der ausgerechnet an einer Stelle (Zeichenkettenbehandlung in C) fehlschlug, an der schon viele verzweifelt sind.

Na was gibt's denn jetzt schon wieder zu meckern?
Ist 1A C, funktioniert. macht kein malloc ohne free usw., usf.
Ihr seid ja schon ein bißchen pingelig. Oder?

EDIT:
Und außerdem war die Zeichenkettenbehandlung mehr als exklusiv hervorragend.

Wollt ich nur mal so erwähnt haben.
Mehr als exklusiv hervorragend war die.

EOP

War eigentlich nur ein Spaßprogramm, das ich nur so hingerotzt hsbe.
Sollte nur alles in binär ausgeben. Hingerotzt eben.

Dezimal-&gt;Binär

Dezimal->Binär