Hallo zusammen, ich möchte in einem Unterprogramm den Lambdawert berechnen. Folgende Formel habe ich mir dafür hergeleitet: Lambda = k m t_m / t_B Lambda ist die Luftzahl (Genauigkeit 0,0001, Wertebereich 0,0000..3,0000) t_B ist die Einspritzdauer (Genauigkeit 1µs, Wertebereich 0..20.000µs) t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs) m ist der Luftdurchsatz (Genauigkeit 0,1 kg/h, Wertebereich 0,0..999,9kg/h) k ist eine Konstante (Genauigkeit beliebig, Wertebereich ~1*10^-2..3*10^-3) Die Formel ist eine Zahlenwertgleichung d.h., die Werte können direkt mit obigen Einheiten eingesetzt werden und es ergibt sich der korrekte Lambdawert. Ich habe bei der Berechnung zwei grundlegende Vorgaben: (1) Lambda muss eine Genauigkeit von 0,0001 haben! (2) Der Wert muss möglichst schnell zu berechnen sein! Tja, wie gehe ich da am Besten ran? Ich hatte mir überlegt, den Wert als uint16_t darzustellen, so dass die höchstwertigste Dezimalstelle die Vorkammastelle ist. Dann käme ich auf einen Wertebereich von 0,0000..6,5535. Wie aber führe ich die Berechnung selbst am einfachsten aus? Welchen Term muss ich mit welcher Genauigkeit rechnen, damit ich am Ende die benötigte Genauigkeit von 0,0001 bekomme? Wie geht man an sowas grundsätzlich ran, gibt es ein Tutorial? Grüße Jan P.s.: Zielsystem ist ein ATMega2561, Speicherplatz ist noch unkritisch!
> Lambda = k m t_m / t_B
Mit den Tokens (pre) und (/pre) in eckiger Klammer wäre das nicht
passiert.
So siehts schöner aus:1 | Lambda = k * m * t_m / t_B |
> t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs)
0...120000 sind schon doppelt soviel wie in ein unsigned short passt.
also dürfte hier schon long integer Arithmetik nötig werden.
Wenn dann Lambda noch auf 1/10000 aufgelöst werden soll, dann muss1 | k * m * tm |
mindestens genau diesen Faktor größer als t_B sein, wenn das Ganze nicht mit Fließkommazahlen berechnet werden soll. Ein paar Grundlagen siehe Festkommaarithmetik
>(2) Der Wert muss möglichst schnell zu berechnen sein! Gibt es auch eine Definition zu "möglichst schnell"? >t_B ist die Einspritzdauer (Genauigkeit 1µs, Wertebereich 0..20.000µs) Den Wertebereich glaube ich nicht. >t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs) Den auch nicht. >k ist eine Konstante (Genauigkeit beliebig, Wertebereich >~1*10^-2..3*10^-3) ;-) Konstanten haben eigentlich per Definition keinen Wertebereich. Oder soll das ein Wert aus einer Kennlinie sein? Oliver
Lothar Miller schrieb: > Wenn dann Lambda noch auf 1/10000 aufgelöst werden soll, dann muss >
1 | k * m * tm |
mindestens genau diesen Faktor größer als t_B > sein, wenn das Ganze nicht mit Fließkommazahlen berechnet werden soll. Fliesskomma hab ich mir auch überlegt. Aber seine Zahlen sind in einem derartig grossem Dynamikbereich, dass ich denke, dass da nur Phantasiewerte rauskommen werden. Mit den Vorgaben wäre ein naives Einsetzen in die Formel und float rechnen nahe an der Fahrlässigkeitsgrenze. > Ich hatte mir überlegt, den Wert als > uint16_t darzustellen, so dass die höchstwertigste Dezimalstelle die > Vorkammastelle ist. Dann käme ich auf einen Wertebereich von > 0,0000..6,5535. Dein Problem ist nicht der Datentyp für lambda. Dein Problem ist, dass dir die Berechnung hinten und vorne überlaufen wird, wenn du nicht vorsichtig bist.
Karl heinz Buchegger schrieb: > Mit den Vorgaben wäre ein naives Einsetzen in die Formel > und float rechnen nahe an der Fahrlässigkeitsgrenze. ACK Leider fehlt immer noch die Angabe zur maximalen Dauer der Berechnung... > t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs) > Lambda ist die Luftzahl (Genauigkeit 0,0001, Wertebereich 0,0000..3,0000) wenn Lambda nur auf 1/10000 aufgelöst werden soll, dann kann getrost auch auch t_m in der Genauigkeit (Auflösung) reduziert werden. Es bringt nichts, mit 6 Nachkommastellen zu rechnen, und gleich darauf 2 davon wegzuwerfen.
>wenn Lambda nur auf 1/10000 aufgelöst werden soll,
Ich wollte es ja erst nicht fragen, aber was wird denn da für ein
Luftmassensensor eingesetzt? Der Wertebereich umfasst zwar 10000 Werte,
über die Genauigkeit sagt das aber gar nichts.
(Um nicht gleich zu fragen: Sind 0,0001 GENAUIGKEIT für Lambda nicht
reines Wunschdenken?)
Oliver
Er meint wohl Auflösung und nicht Genauigkeit...
Jan Sams schrieb:
> t_B ist die Einspritzdauer (Genauigkeit 1µs, Wertebereich 0..20.000µs)
Wo kriegt man denn diese Super-Extra-High-Präzisionsventile, die die
Einspritzdauer auf 5 Stellen bzw. 1ns exakt einhalten?
Bei 0.000µs kriegst Du aber nen wunderschönen Division/0 Error.
Peter
>Er meint wohl Auflösung und nicht Genauigkeit... :-) Je nun, das ist die Original-Spezifikation: >(1) Lambda muss eine Genauigkeit von 0,0001 haben! Der Sinn meiner Frage war schon, das zu hinterfragen... Oliver
Karl heinz Buchegger schrieb: > Fliesskomma hab ich mir auch überlegt. Aber seine Zahlen sind in einem > derartig grossem Dynamikbereich, dass ich denke, dass da nur > Phantasiewerte rauskommen werden. Ausgerechnet mit dem Dynamikbereich sehe ich kein Problem. Grenzwertig ist eher die Genauigkeit einer "float" Mantisse mit 6-7 Dezmalstellen bei Parametern die schon 5-6 signifikante Dezimalstellen haben und einer gefordeten Genauigkeit des Ergebnisses von knapp 5 Dezimalstellen. Das ist knapp, könnte aber noch ausreichen.
In aller Kürze, weil noch zwei Fragen von Euch offen sind: Es handelt sich nicht um eine Hardware die im Fzg. eingesetzt werden soll, sondern um einen Simulationsprüfstand (HiL). Das ist der Hintergrund für die hohe Genauigkeit. Auf eine Ausführungszeit möchte ich mich nicht festlegen. Es geht darum, die Berechnung möglichst schnell auszuführen. Anders herum: angepeilt sind ungefähr 1ms. Wenn's schneller geht -> sehr gut. Wenn's länger dauert -> schade, aber hilft ja nichts. Danke für Eure Antworten! Grüße Jan P.s.: Das mit der Konstante stimmt schon, sie ist in Wirklichkeit nicht konstant. Sie setzt sich, je nach Testfall, aus anderen Konstanten zusammen (Dichte Benzin oder Dichte Diesel etc.).
A. K. schrieb:
> Ausgerechnet mit dem Dynamikbereich sehe ich kein Problem.
dito.
Ich dachte genau das wäre der Vorteil von Fließkomma.
Wenn man große und kleine Werte addiert, dann kann es Probleme geben,
aber wenn man z.B. 10E+25 durch 10E-12 teilt, dann sollte das Ergebnis
(im Rahmen der Auflösung, also die 6-7 Stellen) genau sein.
>Das mit der Konstante stimmt schon, sie ist in Wirklichkeit nicht >konstant. Sie setzt sich, je nach Testfall, aus anderen Konstanten >zusammen (Dichte Benzin oder Dichte Diesel etc.). Was die Sache auch nicht genauer macht. Oder hast du da auch eine supergenaue Temperaturmessung dran? Noch 'ne Frage: Wie (d.h. in welcher Form/Darstellung/Protokoll, und wie schnell) bekommst du denn die Werte in den Prozessor? Oliver
A. K. schrieb: > Karl heinz Buchegger schrieb: > >> Fliesskomma hab ich mir auch überlegt. Aber seine Zahlen sind in einem >> derartig grossem Dynamikbereich, dass ich denke, dass da nur >> Phantasiewerte rauskommen werden. > > Ausgerechnet mit dem Dynamikbereich sehe ich kein Problem. Du hast recht. Sind ja nur Multiplikationen und keine Additionen enthalten.
:
Wiederhergestellt durch User
Hallo nochmal, zuerst einmal vielen Dank für Eure Antworten. Ursprünglich wollte ich nur wissen, wie man am sinnvollsten an so eine Formel herangeht. Da aber hier Fragen über die Zweckmäßigkeit auftauchen: Es geht darum, einen Teststand für Motorsteuergeräte zu bauen. Da ich u.a. die Luftmasse also selber vorgebe, kann ich sie auch als beliebig genau annehmen. Die Frage, wie die Werte in den Prozessor kommen, erübrigt sich damit auch. Die "Konstante" setzt sich aus weiteren Konstanten zusammen. Je nach verwendetem Kraftstoff oder Einspritzventilen ergibt sich ein anderer Wert. Demnach ist die "Konstante" zwar für jeden Testfall konstant, kann aber für andere Fälle halt doch variieren. Aus Euren Antworten lese ich, dass ich die Berechnung mit float-Datentypen machen soll. Grüße Jan
Die Frage ist ehr wie schnell du das berechnen willst. ein AVR Prozessor ist damit hoffnungslos überfordert. Mit float Zahlen noch mehr als mit Int. Wenn du diese Formel schnell berechnet haben willst solltest du dich mit 32bit Prozessoren wie ARM7 oder ARM9 bzw dem Cortex-M3 anfreunden. Selbst ein ARM9 mit 200MHz Taktung braucht µs für die multiplikation von Floatzahlen MfG Stefan
Oben schreibt er, dass eine solche Berechnung pro Millisekunde ausreicht. Dafür tut es auch ein AVR.
Die erste Multiplikation
1 | k*m |
kann ich ja mit einer Tabelle lösen. Kostet mich zwar 20kB (da die Luftmasse 10.000 16-Bit Werte hat), aber das stört mich nicht. Der Mega2561 ist groß und meine Hardware ein Einzelstück. Deutlich aufwändiger wird die Division...
Warum programmierst du das nicht einfach mal und testes das im Simulator mal aus. Dann siehst du doch ob es klappt oder nicht. Oder schreib mal die Zyklen neben deinen Befehlen. Gruss Helmi
Probier doch erst einmal aus, was bei Fliesskommarechnung als Laufzeit rauskommt, bevor du sämtliche Räder neu erfindest.
Das du das Ergebnis vermutlich als float speichern willst, braucht es für die Tabelle 40 KB. Ich würde aber erst einmal abschätzen, wie lange die Berechnung nun wirklich braucht. Im AVR-Studio simulieren, und die Laufzeit für ein paar Wertekombinationen durchspielen. Dann weisst du, ob manuelle Laufzeitoptimierungen überhaupt erforderlich sind. Oliver
A. K. schrieb: > Probier doch erst einmal aus, was bei Fliesskommarechnung als Laufzeit > rauskommt, bevor du sämtliche Räder neu erfindest. Seh ich auch so. Ich würd sogar weiter gehen: Auf dem PC in ineinandergeschachtelten Schleifen den kompletten Wertebereich aller Variablen durchackern lassen. Dabei jeweils eine double Version mit einer float Version vom Ergebnis her vergleichen und den prozentuellen Fehler feststellen und das Maximum davon festhalten. Ist mir doch egal, ob der PC da ein paar Stunden (wenn überhaupt) daran knabbert. Optimierung aus, FPU Unterstützung abdrehen, damit sich das PC Programm in der Berechnung möglichst gleich dem verhält, was sich auch auf dem AVR abspielen wird (ev. float Zwischenvariablen einführen, damit die eigentliche float Rechnung auch mit der kleineren Mantisse gemacht wird.)
Viel Vergnügen. Das sind 2.4e13 Operationen. Ich würde eher sagen, dass der maximale Fehler bei korrekt arbeitender Fliesskommalib ungefähr ein letztes Mantissenbit pro Operation rauf oder runter ist. Das ist bei 3 Operationen weniger als eine Dezimalstelle, also ausreichend. Und wenn die Lib nicht ganz so korrekt ist, dann nützt dir das Ergebnis vom PC auch nix.
Kompletten Wertebereich durchgehen kannst du vergessen. Wenn das bei mehreren Eingangsvariablen so einfach wäre, könnte man Software sehr leicht brute-force-mäßig auf Korrektheit prüfen. Geht aber in der Praxis nicht, weil der Kunde schon gestorben ist, wenn das Ergebnis da ist.
Die Berechnung in float scheint um die 800 Takkte zu benötigen (ich hab nur ein paar Wertekombinationen überprüft). Das ist selbst bei 1MHz Prozessortakt schnell genug für 1ms, wenn das Programm ansonsten nicht allzuviel anderes machen muß. Allerdings bleibt nach wie vor die Frage, wo die Werte für die Berechnung herkommen. Wenn die als Tabelle im Speicher liegen, reicht es ja nur für ein paar Sekunden Meßzeit. Oliver
Hallo Auf die 800 Zyklen bin ich gestern Abend auch gekommen. Die Division ist dabei der zeitaufwändigste Teil. Ich verstehe Deine Frage nach der Herkunft der Werte leider nicht: Der Luftmassenstrom m wird vom Anwender eingegeben. Eine Tabelle gibt es dafür nicht. Einspritzdauer t_B und Zykluszeit t_m werden über die Input Capture Funktion gemessen.
>Ich verstehe Deine Frage nach der Herkunft der Werte leider nicht: Der >Luftmassenstrom m wird vom Anwender eingegeben. Eine Tabelle gibt es >dafür nicht. Einspritzdauer t_B und Zykluszeit t_m werden über die Input >Capture Funktion gemessen. Nun denn, wenn man das weiß, könnte man auf die Idee kommen, k*m bei der Eingabe einmal zu berechnen, und danach als konstant anzusehen. Das spart eine Multiplikation im ms-Takt. Aber es ist deine Entscheidung, die interessanten Randbedingungen von den uninteressanten zu unterscheiden. Oliver
Hallo, wenn die Lufmasse konstant sein soll, da Handeingabe , dann muss mindestens auch die Drehzahl konstant sein.Dann ist auch t_m auch kein Kriterium mehr, sondern nur die absolute Einspritzmenge/ Umdrehung ~ t_b. Ausser t_m beeinflusst die Einspritzmenge/Zeiteinheit. Wenn nun k*m = konstant , kann man ja eine Tabelle für 1/x [1..20000] nehmen. Oder eine kleine Tabelle mit 1/1,1/2,1/4,1/8,1/2^n der Tabellenplatz käme aus dem Exponenten von t_b. Und dann die Näherungsformel: (1) xi+1 = xi(2 − D · xi), wobei D eben t_b wäre und xi als Startwert aus der Tabelle käme. Viel wichtiger: Wenn sich die t_b Werte nicht schnell ändern, wäre eine Berechnung mittels des vorherigen Wertes möglich. Wäre der nächste Wert 5% vom vorherigen entfernt, wären nach 2 Berechnungen von (1) der Wert auf 1e-6 genau. sei t_b_alt = 1 und der neue Wert 1.05 x1 = 1*(2-1.05*1)= 0,95 x2 = 0.95*(2-1.05*0.95)= 0.952375 = 1/1.050006563 Jetzt bleibt die Frage, sind 4 Mul+2 Diff für die Bestimmung von 1/x und 1 Mul zur anschliessenden Berechnung schneller als 1 Division. Gruß Horst Gruß Horst
Subtraktion von Daten in grossem Dynamikbereich reduziert die Genauigkeit erheblich. Iteration führt zusätzlich zu Fehlerakkumulation. Da hier ohnehin schon wenig Genauigkeitsreserve ist: davon würde ich abraten.
Ich würde mit Fixed point gehen, Lambda = k m t_m / t_B sowie 16.16 Integer, was dann später ev. aufgeweitet werden kann, mit mehr Nachkommastellen.
Hallo, @A. K: die Subtraktion in (1) xi+1 = xi(2 − D · xi), liegt doch bei 2.0-1.0, da verliert man 1 Bit an Genauigkeit. Da ist keine hohe Dynamik.Es korrigiert sich ja auch selbst. Falls es unklar beschrieben war: D ist die Zahl und xi die Näherung für 1/D, also ist D*xi ~ 1.0 wie in dem Rechenbeispiel bei 5% Abweichung zu sehen. Diese Formel macht nur Sinn, wenn man schnell multiplizieren kann und eine gute Näherung hat, deshalb die Tabelle, die aber nur Sinn macht, wenn man stark schwankende Werte hat. Selbst D= 1.5 und Näherung x0= 1 x1= 1(2-1.5*1) = 0.75 (das wäre auch die lineare Näherung zwischen 1/1 und 1/2 ) x2= 0.75(2-1.5x0.75) = 0.65625 x3= 0.65625(2-1.5*0.65625)= 0.6665039 x4= 0.6665039(2-1.5*0.6665039)= 0.666666626 hat schon 6..7 Stellen Da der AVR nun einmal einen MUL Befehl kennt, "kann" es schneller sein. Gruß Horst
Ich hatte nicht untersucht wie gross der Fehler tatsächlich ist. Nachdem die ursprüngliche Lösung schon viel schneller als nötig ist (50µs@16MHz statt 1ms), sehe ich keinen Grund für eine derartige Optimierung.
Und wer liest die daten im ms Takt ab/aus?
Horst schrieb: > Wenn sich die t_b Werte nicht schnell ändern, wäre eine Berechnung > mittels des vorherigen Wertes möglich. Das ist der Punkt in dem ich Probleme sehe. Jede Rechnung bringt potentiell zum Fehler aus der vorherigen Rechnung einen zusätzlichen Fehler hinzu. Nach 1000 solchen iterativen Rechnungen ist das Ergebnis bei der geringen Genauigkeitsreserve möglicherweise nur noch Phantasie. Ein Aspekt den man bei Iteration stets im Auge behalten sollte.
Hallo, die Optimierung ist nun gänzlich unproblematisch. Wie die Wurzel bei der Heron-Formel , verdoppelt sie im jedem Schritt die Anzahl der genauen Stellen. Das der vorherige Schätzwert für neuen 5% davon abweichenden, selbst 1e-6 davon liegt, macht sich nirgendwo bemerkbar (ob 0.050001 oder 0.049999 ). Hier von 1.0 ausgehend immer 5% mehr bei jeweil zweimaliger Iteration:
1 | program DivTest;//freepascal oder Delphi |
2 | {$Apptype console}
|
3 | |
4 | function DiVIter(x,rez:single):single; |
5 | begin |
6 | DivIter := (single(2.0)-single(x*rez))*rez; |
7 | end; |
8 | |
9 | var |
10 | i : integer; |
11 | x,d : single; |
12 | begin |
13 | x := 1.0; |
14 | d := 1.0; |
15 | For i := 0 to 29 do |
16 | begin |
17 | x := x*1.05; |
18 | d := diviter(x,d);d := diviter(x,d); |
19 | writeln(x:10:5,d:10:5,' ', x*d-1.0) |
20 | end; |
21 | end. |
22 | |
23 | X 1/X rel. Abweichung |
24 | 1.05000 0.95238 -6.238336566E-06 |
25 | 1.10250 0.90702 -6.243170217E-06 |
26 | 1.15763 0.86383 -6.243170217E-06 |
27 | 1.21551 0.82270 -6.211577640E-06 |
28 | 1.27628 0.78352 -6.209570961E-06 |
29 | 1.34010 0.74621 -6.231809776E-06 |
30 | 1.40710 0.71068 -6.210872121E-06 |
31 | 1.47746 0.67684 -6.224567214E-06 |
32 | 1.55133 0.64461 -6.219126986E-06 |
33 | 1.62889 0.61391 -6.275373592E-06 |
34 | 1.71034 0.58468 -6.219858873E-06 |
35 | 1.79586 0.55683 -6.219383975E-06 |
36 | 1.88565 0.53032 -6.195066254E-06 |
37 | 1.97993 0.50506 -6.274746239E-06 |
38 | 2.07893 0.48101 -6.263777534E-06 |
39 | ..... |
Natürlich hat sich das ganze bei 50e-6 Sekunden Rechenzeit erledigt. Gruß Horst P.S: Warum schafft man sich eine AVR 256er an, wenn nicht weiß, ob der überhaupt schnell genug ist... :confused:
Ich habe von Anfang an geschrieben, dass ich eine möglichst schnelle Berechnung suche. Die 1ms habe ich einmal in den Raum geworfen und gleich im nächsten Satz darauf hingewiesen, dass es schneller besser wäre. Warum steht das hier den ganzen Thread über im Mittelpunkt? Die Anforderung "so schnell wie möglich" ist doch eindeutig! @laeubi: Die Daten liest niemand im ms-Takt aus. Aber wenn ich nur 1ms für diese Berechnung brauche, kann ich mit dem Prozessor auch noch andere Dinge erledigen. Ich schaue mir gerade die Methode mit der Iteration an. Sieht vielversprechend aus! Ich melde mich wieder, sobald ich sie simuliert habe. Grüße Jan P.s.: Den Mega2561 habe ich ausgewählt, weil ich in der AVR-Architektur bleiben möchte und für LUT viel Programmspeicher benötige. Er ist ein guter Kompromiß!
@ Jan Sams (Gast) >wäre. Warum steht das hier den ganzen Thread über im Mittelpunkt? Die >Anforderung "so schnell wie möglich" ist doch eindeutig! Eben, sie ist eindeutig Unsinn! So schnell wie möglich kann auch heissen, nimm nen Quad-Core mit 3 GHz! >@laeubi: Die Daten liest niemand im ms-Takt aus. Aber wenn ich nur 1ms >für diese Berechnung brauche, kann ich mit dem Prozessor auch noch >andere Dinge erledigen. Schon, aber meist dreht der Prozzessor bei vielen Leuten Däumchen. In Warteschleifen ;-) MFg Falk
Falk Brunner schrieb: >>@laeubi: Die Daten liest niemand im ms-Takt aus. Aber wenn ich nur 1ms >>für diese Berechnung brauche, kann ich mit dem Prozessor auch noch >>andere Dinge erledigen. > > Schon, aber meist dreht der Prozzessor bei vielen Leuten Däumchen. In > Warteschleifen ;-) Ja und wie sagt man hier so schön: Das Geld gibt es für nicht gebrauchte Ressourcen nicht zurück.
>Ich habe von Anfang an geschrieben, dass ich eine möglichst schnelle >Berechnung suche. Du hast von Anfang an ziemlich deutlich gemacht, daß du die tatsächlichen Anforderungen an das System noch gar nicht kennst. Selbst, wenn das ganze "nur" eine Studien-/Praktikums-/Semesterarbeit ist, gilt doch für die genauso, wie für alles andere: Ohne Kenntnis und Festlegung der Anforderungen ist jede Lösung falsch. Nur so als Beispiel: >t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs) Nett, aber sinnlos. Ich rate jetzt mal drauf los: Es geht um einen Kolben-Verbrennungmotor. 120.000µs entspräche da einer Leerlaufdrehzahl von 500 1/min, ein realistischer Wert. Nur, viel mehr als das 15-fache wird die Maximaldrehzahl nicht betragen. Also ist das Minimum des Wertebereiches nicht 0 bzw. 1, sondern irgenwas um 8000, und die minimale Zyklusdauer 8ms. Ob du jetzt aus diesen 8ms eine Anforderung für eine maximale Berechnungszeit von Lambda anleiten kannst, oder ob diese von etwas ganz anderem abhängt, keine Ahnung. Das musst (!!!) du selber erarbeiten. Und wenn du dann irgendwann sagen kannst: Die Lösung muß sicherstellen, daß die Berechnung von Lambda maximal 1ms dauert, weil/damit... dann bist du einen wichtigen Schritt weiter. Oliver
Bei der Diskussion, warum unbedingt die genaue Zeitdauer benötigt wird, hast Du mich zwar nicht überzeugt. Mit der Berechnung hast Du allerdings recht (darauf hast Du doch auch schon in Deinem ersten Posting hingewiesen?) und zugegeben, da habe ich nicht richtig nachgedacht.
Besondere Anforderungen sind mir immer verdächtig, d.h. es könnte oft einfacher gehen. Probleme dieser Art kann man oft mit LUT=Lookup Tabellen umgehen ggf. interpolieren, ich denke da auch an Fuzzy Logik. Meist wird nicht jede Zwischenstufe benötigt sondern nur konkrete Zielwerte. Musst halt gucken, ob das für dich eine Option ist.
Ich habe noch eine Idee, ohne zu wissen was du genau brauchst. Ich musste an die alten Rechenschiebertricks denken: Multiplikation und Division kann über logarithmieren in eine Addition/Subtraktion überführt werden.
Schorsch schrieb: > Multiplikation und Division kann über logarithmieren in eine > Addition/Subtraktion überführt werden. log (a*b*c) = log a + log b + log c Und was genau bringt das? Soll man jetzt megabyteweise Lookup-Tabellen für Logarithmen anlegen? :-)
>Und was genau bringt das? Soll man jetzt megabyteweise Lookup-Tabellen >für Logarithmen anlegen? :-) http://de.wikipedia.org/wiki/Cordic Ich nehme an es geht um die Realisierung für einen Regler, da reichen ein paar Werte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.