Prozentrechnung !

International Deutsch
#1

Ich bekomme es nicht auf die Reihe !

Heir erstmal der Sketch :

#define clockPoti A2
int ClockSpeed = 0;
unsigned long clockPrev = 0;
int ledStatus = LOW;
//int gateLenght = 15;


#define gatePoti A3
unsigned long gateLenght = 0;
unsigned long gatePrev = 0;

int redLed = 13;







void setup(){
  
  pinMode(redLed, OUTPUT);
  clockPrev = millis();
  
  Serial.begin(9600);

}


void loop(){
  
  ClockSpeed = analogRead(clockPoti);
  gateLenght = analogRead(gatePoti);
  gateLenght = gateLenght / 1024;
  
  if((millis() - clockPrev) > ClockSpeed) {
    clockPrev = millis();
    digitalWrite(redLed, HIGH);
    gatePrev = millis();
  }
  
    if((millis() - gatePrev) > (ClockSpeed * gateLenght)) {
      digitalWrite(redLed, LOW);
      
      
    }
    
    
    
}

Mit gateLenght moechte ich prozentual einstellen koennen wie lange redLed (abhaengig von ClockSpeed) leuchtet. Aber ich hab da wohl einen Denkfehler drin, so funktioniert es nicht. Ich dachte, wenn ich gateLenght durch 1024 teile, hab ich bei maximal geoeffnetem poti = 1 1*clockSpeed waere also 100%, alles andere ist dann zwischen 0 - 100%

Ich hoffe, ihr versteht was ich meine und koennt mir auf die spruenge helfen.

#2

gatelength müsste eine float oder double sein, damits funktioniert. ;)

#3

Danke ! So funktioniert es. Manchmal kann das leben so einfach sein. Wieso bin ich da nicht selbst drauf gekommen :blush:

#4

Betriebsblindheit, passiert. :)

#5

XD so kann man es auch nennen.

#6

eldopa: Ich dachte, wenn ich gateLenght durch 1024 teile, hab ich bei maximal geoeffnetem poti = 1 1*clockSpeed waere also 100%, alles andere ist dann zwischen 0 - 100%

Du mußt durch 1023 Teilen nicht durch 1024 um 100% zu bekommen. Der Maximalwert des ADC ist 1023. Grüße Uwe

#7

Sowas geht auch ohne floats. Einfach nicht teilen, also 

(millis() - gatePrev)*1024 > (ClockSpeed * gateLenght))

Und vorher gateLenght nicht durch 1024 teilen. Davon abgesehen schreibt man length mit "th".

#8

ok, danke euch allen. auf jeden fall funktioniert es schon mal und ich werde es noch auf 1023 ändern, oder von Udo die variante übernehmen.

macht es einen unterschied ob ich mit float, oder unsigned long arbeite ? beide typen nutzen 4 bytes, aber vielleicht gibt es ja unterschiede in der geschwindigkeit der berechnung ??????

#9

Ich würde aus dem Bauch heraus sagen, das Integer-Operationen immer schneller sind. Hat der Atmel eigentlich eine FPU? Falls nicht, würden Floatingpoint-Operationen in Software abgebildet, was dann deutlich langsamer wäre.

#10

Zum Einen das, zum Anderen sind Ganzzahloperationen genauer und sicherer, was Rechenfehler angeht.

#11

Ob nun Ganzzahloperationen wirklich immer genauer sind, wage ich mal zu bezweifeln. Ein "(int) 11/2" liefert ja schon mal 10% Fehler.

#12

Aber wie Du gerade selbst bewiesen hast ist Dir der Sachverhalt in dem Fall klar. :)

#13

http://arduino.cc/en/Reference/Float: Datatype for floating-point numbers, a number that has a decimal point. Floating-point numbers are often used to approximate analog and continuous values because they have greater resolution than integers. Floating-point numbers can be as large as 3.4028235E+38 and as low as -3.4028235E+38. They are stored as 32 bits (4 bytes) of information. Floats have only 6-7 decimal digits of precision. That means the total number of digits, not the number to the right of the decimal point.

http://arduino.cc/en/Reference/Long: Long variables are extended size variables for number storage, and store 32 bits (4 bytes), from -2,147,483,648 to 2,147,483,647.

Bei long hast Du bis zu 10 significante Stellen; bei float kannst Du grüßere Zahlen darstellen aber nur mit 6-7 significante Stellen. Was ist genauer? Grüße Uwe

#14

@mkl0815: Dein Beispiel stimmt nicht. 11/2 liefert 5 mit 0% Fehler. Der 10% Fehler liegt in Deiner Annahme, daß da 5.5 rauskommen sollte. Bevor Du argumentierst, daß 11/2 doch immer gleich 5.5 sein muß, denke mal kurz darüber nach wie groß der Fehler bei sqrt(4) ist. 0 oder 200%?

Auf was ich raus will: bevor man von Fehlern redet muß man erst einmal schauen was denn das erwartete Ergebnis sein soll.

#15

[quote author=Udo Klein link=topic=91917.msg692037#msg692037 date=1329327933] @mkl0815: Dein Beispiel stimmt nicht. 11/2 liefert 5 mit 0% Fehler. Der 10% Fehler liegt in Deiner Annahme, daß da 5.5 rauskommen sollte. Bevor Du argumentierst, daß 11/2 doch immer gleich 5.5 sein muß, denke mal kurz darüber nach wie groß der Fehler bei sqrt(4) ist. 0 oder 200%?

Auf was ich raus will: bevor man von Fehlern redet muß man erst einmal schauen was denn das erwartete Ergebnis sein soll. [/quote] Die Quadratwurzel einer reellen Zahl ist aber als diejenige -positive- Zahl definiert, dessen Quadrat der Radikand ist. Von daher ist -2 KEINE Lösung von sqrt(2).

Und wenn du gebrochene Zahlen darstellen willst, dann packst du ja auch noch einen Skalierungsfaktor dazu. Wenn du dich mit floats im untersten Wertebereich aufhälts gibt es da auch Rundungsfehler.

#16

Uh, das war jetzt die volle Dröhnung. XD

Ich für meinen Teil favorisiere ganze Zahlen zur Berechnung, weil Ganzzahloperationen ein gutes Stück schneller sind (solange man keine FPU hat) und ich bekomme nur Rundungsfehler wenn ich das will. ;)

#17

Hihi, genau darauf habe ich gewartet ;)

Die Quadratwurzel einer reellen Zahl ist aber als diejenige -positive- Zahl definiert, dessen Quadrat der Radikand ist. Von daher ist -2 KEINE Lösung von sqrt(2).

Das war nicht die volle Dröhnung. Die kommt jetzt: Floats sind keine reellen Zahlen. Floats können nicht einmal die rationalen Zahlen abbilden. Quadratwurzelfunktionen kann man genau dann definieren wenn die Quadratfunktion surjektiv ist. Auf den reellen Zahlen hingegen ist sie das nicht, wenn dann nur auf reellen Zahlen >= 0 oder man erlaubt als Ergebnis komplexe Zahlen, dann ist die obige Definition nicht mehr sinnvoll. Von daher ist Deine Definition nur Dein Wunschdenken bzw. das was Dir in der Schule vermittelt wurde. Welche Quadratwurzelfunktion man dann als "die richtige" Auszeichnet hängt normalerweise von weiteren Randbedingungen ab, z.B. einer geeigneten "Auswahlfunktion". Und nein, Wikipedia liefert keine vollständige Erklärung. Dort steht nur das was Du in der Schule lernst.

Soll heißen: ob und wieviel das Ergebnis von SQRT richtig oder falsch ist liegt viel mehr in der Fragestellung als am tatsächlichen Ergebnis und genau das gleiche gilt auch für die "Integerdivision".

#18

Doch, floats sind reell und rational, da die Menge aller Werte für Floats (nennen wir sie einmal F) eine Teilmenge der rationalen Zahlen ist, welche wiederum eine Teilmenge der reellen Zahlen ist. Von daher bietet es sich an, für F die Definition der Quadratwurzel zu nehmen, die auf R und Q schon üblich ist, nur halt mit anschließender Näherung, um in den Wertebereich zu passen. Eine Näherung ist ja schon auf Q nötig für Zahlen wie sqrt(2), jedoch ist F nicht dicht, sodass die Approximation irgendwann auch mal zum Ende kommt. Natürlich kann es aber sein, dass man beide Lösungen einer Quadratwurzel sucht oder nur die negative, das wird dann aber üblicherweise mit einem Vorzeichen vor der Wurzel dargestellt. Zumindest auf wohlgeordneten Mengen wir R, Q oder auch F, auf denen man klar definieren kann, was größer und was kleiner als 0 ist.

Aber ich bezweifle, dass diese Diskussion irgendetwas zum Thema beiträgt.

#19

Also ich finde ja dass Mathematiker, wenn sie so Zeugs schreiben, mit F gleichzusetzen sind. XD

Aber Du hast schon recht, bei der Diskussion bringt uns das tatsächlich nicht weiter. ;)

Wie gesagt, solange man keine FPU hat sind Ganzzahloperationen auf jeden Fall schneller.

#20

Joghurt: Also ich finde ja dass Mathematiker, wenn sie so Zeugs schreiben, mit F gleichzusetzen sind. XD

In dem Sinne, dass sie nicht dicht sind? Streng genommen heißt es ja auch dicht liegen. Aber wie sagt man noch so schön: Mathematiker sind konvergent. Beweis: Mathematiker sind monoton und beschränkt. Und ja, auf Prozessoren ohne FPU sollte man Floats nur nehmen, wenn man sie braucht. Bei ints gibt es natürlich Rechenoperationen, bei denen man nennenswerte Rundungsfehler zu erwarten hat, aber die lassen sich meist auch durch geschickte Skalierung beheben.