Warum rechnet mein mega 8 falsch

2^10

Was soll denn hier passieren?

Oder das ergebniss hat zuviel Biss und frist den Rest auf?

geht 2^10 überhaupt in C (so wie du willst)? glaub du solltest mal die 
funktion pow ausprobieren :-)
War ^ nicht sowas wie XOR?

2 XOR 10 = 0010 XOR 1010 = 1000 = 8 :-)

Geil, ich hab's auch nicht bemerkt. Sollte mir nen Kaffe machen... :-)

gar nichts habe ein probkem mit einen drucksensor

dort werden berechnungen gemacht um den druck zu errechnen.


z.b

sems=26051+822*170/2^10+24576

26051 lese ich vom sensor
die 822 auch.

in excel bekomme ich 50763 wie es sein soll
der avr bringt 5819

warun

siehe oben... das zeichen ist nicht das exponenten-zeichen sondern steht 
für xor. Einfach mal pow anstatt ^ benutzen.

Weil ^ in C nicht Hoch, sondern XOR bedeutet.

Schreib statt 2^10 einfach 1024 und es sollte wunderbar laufen :)

pow(2,10) ergibt 800.


Also irgendwas stimmt nicht

Sorry  400 in hex sind dez =1024

geht doch

jetzt probiere ich es mit der ganzen formel

Du gibst das Ergebnis aber schon so aus:

sprintf(Buffer("X = %d",(int)pow(2,10));

Also der Typecast nach int, damit es mit %d zusammmenpasst

Ich begreife es nicht


wenn ich (822*170)/pow(2,10)

bekomme ich 8

das kann doch nicht sein

Herrmann,

> wenn ich (822*170)/pow(2,10)
> bekomme ich 8

vielleicht solltest Du Dich erst einmal näher mit den Regeln der 
Ganzzahl-Arithmetik beschäftigen. Dann hast Du nicht so viel Frust, und 
die Ergebnisse werden auch besser.

Zunächst einmal: pow(2,10) macht niemand. Wozu die Rechenzeit 
investieren, wenn man das Ergebnis auch hinschreiben kann? Also 1024 
stattdessen.

Zweitens: Du hast bei ganzen Zahlen nur einen beschränkten Wertebereich.
822 * 170 sollte nach Deiner Meinung 139740 ergeben. Wenn ein int(eger) 
aber 16 bit ist, dann bekommst Du einen Überlauf, und das Ergebnis 
modulo 2 hoch 16 (=65536). Das ergibt dann 8668. Und wenn Du 8668 durch 
1024 teilst, dann kommt 8,46... raus. Und da wir mit ganzen Zahlen 
rechnen, eben die 8.

Du hast jetzt 2 Alternativen:

a) Du kannst mit Fließkomma rechnen. Dauert länger, ist aber u.U. 
vertretbar. Fließkomma hat den Datentyp "float" und eine Fließkomma-Zahl 
ist alles, was einen Punkt in der Zahl hat. Also eine Konstante "12" ist 
eine Festkommazahl, eine Konstante "12.0" ist eine Fließkommazahl.

b) Du könntest - wenn es Dir auf Geschwindigkeit oder Codegröße oder 
Ehrgeiz ankommt - mit 32bit Festkommazahlen rechnen. Der Datentyp dafür 
lautet "long", und eine long-Konstante erzeugst Du mit "12L".

Nur Mut, es ist nicht wirklich schwer.

Du kannst auch einfach die Rechnung ein wenig umstellen, dann passt es 
auch wieder:

(822*34) / pow(2,10) * 5

(822*34) passt noch in einen Int
/1024
* 5

du rechnest also in 2 Schritten: erst mal 34, dann mal 5 ergibt zusammen 
mal 170.

Darunter leidet aber deine Auflösung, weil du beim teilen durch 1024 die 
Nachkommastellen verlierst :(

Danke

Ich habe leider nur ein C Buch da steht drin das der int ein 32bit 
bereich hat.aber so ist es aber beim avr oder gcc nicht.

Hat jemand ein gutes buch für c und avr wo sawas drin steht????


Danke

> Merke: In einen int passen nur Zahlen von -32768...32767 rein.

Das stimmt so nicht, das hängt einfach vom Compiler ab.

Powned =)

> Ich habe leider nur ein C Buch da steht drin das der int ein 32bit
> bereich hat.aber so ist es aber beim avr oder gcc nicht.

Dann ist das ein scheiß Buch. Es war schon immer so (C gibt es seit den 
70'ern) dass der Typ int die Lieblings-Wortbreite des verwendeten 
Prozessors hat. Der Autor kann also gar nicht wissen wie Breit ein int 
ist. Bei den heute üblichen PC-Prozessoren sind das 32 Bit, da hat der 
Autor schon recht. Vor ein paar Jahren (DOS/Win3.1 evtl. noch Win95/98) 
waren es typischerweise 16 Bit. 32 hätten die CPUs ab 386 schon gekonnt, 
die Standard-int breite wurde aber lange für die Programmierer 
beibehalten die sich drauf verlassen hatten dass ein int immer 16 Bit 
breit ist. Und es gab ein paar Großrechner mit so krummen Sachen wie 13 
oder 18 Bit. Und gerade C wird eben nicht nur für PCs benutzt.

Randy

> Ich habe leider nur ein C Buch da steht drin das der int ein 32bit
> bereich hat.

Dann empfehle ich stattdessen "The C Programming Language" von Kernighan 
& Ritchie.

Im Standard ist eigentlich festgelegt, daß "short" 16 Bit hat und "long" 
32 Bit. Wie Randy schon schreibt, ist "int" Compiler-abhängig, d.h. der 
Compiler nimmt entweder "short" oder "long" dafür.