So, ich muß das Thema nochmal ins Forum schreiben, vielleicht kann mir da irgend jemand helfen. "Lustigerweise" bekomme ich die Aufgabe auf dem Papier hin, aber ich fahre mich fest wenn ich sie auf den Computer übertragen und mit komplexeren vermaschten Netzen durchführen will. Was ich meine ist ein vermaschtes Netz aus Widerständen, aus dem an bestimmten Stellen ein Strom eingespeist und an anderen Stellen entnommen wird - wie verteilen sich dort die Stromflüsse, wo fließt wieviel Strom? Von der Aufgabe her total simpel, von der Lösung schon schwieriger. Ich möchte erst einmal keinen meiner Versuche präsentieren, keiner hat funktioniert und ich weiß nicht wo der Fehler liegt. Oder auch keine Vorgaben machen, wie die Knoten und Verbindungen zur Lösung abgelegt werden müssen, evtl. habe ich da schon einen Fehler gemacht, der die spätere Lösung behindert. Wäre schön wenn das irgendjemand in PHP schafft, so daß ich es hinterher auch verstehe. Evtl. ginge es recht einfach mit Tools wie linsolve, aber das hilft mir nicht wirklich weiter, ich würde gerne verstehen wie es funktioniert und den Teil, der mir offensichtlich fehlt, dazulernen.
Beitrag #6937393 wurde von einem Moderator gelöscht.
Ehrlich gesagt, verstehe ich überhaupt nicht, was dein Ziel ist. Trotzdem mal ein Versuch: Hier findest du den Quellcode von ngspice: https://sourceforge.net/projects/ngspice/ Das ist zwar nicht in PHP programmiert, aber vielleicht findest du irgendwo einen Konverter von C nach PHP. Wenn nicht, ist das sogar ein Vorteil für dich, da du bei der manuellen Konvertierung viel mehr über die Funktionsweise erfährst, und das möchtest du doch: Ben B. schrieb: > ich würde gerne verstehen wie es funktioniert und den Teil, der mir > offensichtlich fehlt, dazulernen. Falls dir das nicht weiterhilft, musst du schon etwas mehr Informationen über dein Vorhaben und die dabei aufgetretenen Probleme herausrücken. Sonst könnte der Eindruck entstehen, dass du hier einfach nur von anderen Software für lau entwickeln lassen möchtest.
Sowas habe ich auch mal in C gemacht. Netzliste aus einem C-Programm heraus erstellt. Spice rechnen lassen. Ergebnisdatei wieder durch C eingelesen und graphisch angezeigt. Man muss nur wissen, wie die Spice Inputs und Outputs aussehen.
Das geht auch ohne Spice. Es sind ja nur paar Widerstände. 1. Gauss-Algorithmus bzw. Gleichungssystemlöser für PHP oder besser Typescript besorgen 2. für alle Knoten Gleichungen für die Ströme aufstellen (eine große Matrix) 3. Gleichungen für alle Spannungen aufstellen (in die gleiche Matrix schreiben) 4. Gleichungssystem lösen lassen In dem Ergebnisvektor hast du alle Ströme und Spannungen.
> Warum in PHP und warum nicht in JavaScript? kannst Du es in JavaScript? Ich bin nicht so fit in C, aber gut in PHP und weil die beiden recht ähnlich sind wär's in PHP vielleicht gar nicht so schlecht für den Fall, daß es einer in C kann. > 1. Gauss-Algorithmus bzw. Gleichungssystemlöser für PHP > oder besser Typescript besorgen Hast Du sowas? Bzw. warum ist es so schwer, sowas selbst zu schreiben? @Yalu Mir geht's nicht um kommerzielle Software-Entwicklung für lau , auch nicht darum, das "Produkt" zu vermarkten. Ich vermute das will keiner außer ich haben. Mich nervt im Moment nur ein wenig, daß ich das nicht selbst hinbekomme. Spice ist ja gleich wieder sehr komplex mit Wechselspannung, Phasenlage und dem ganzen Kram - so viel brauche ich gar nicht, mir ging es um eine reine "oberflächliche" DC-Variante. Die Probleme, die aufgetreten sind waren immer eine der drei Möglichkeiten Division durch Null bzw. falsche/unlösbare Gleichungen, Endlosschleifen bei der Bildung der Gleichungen oder einfach komplett falsche Ergebnisse. Ich mache irgendwo Fehler bei den Gleichungssystemen aber ich kann nicht gut beschreiben oder genau wissen wo.
Da du es auf dem Papier hinbekommst, kannst du ja die aufgestellten Gleichungen und die Zwischenergebnisse bei deren Lösung Schritt für Schritt vergleichen und damit den Fehler eingrenzen.
Ben B. schrieb: >> 1. Gauss-Algorithmus bzw. Gleichungssystemlöser für PHP >> oder besser Typescript besorgen > Hast Du sowas? Bzw. warum ist es so schwer, sowas selbst > zu schreiben? Ist es nicht. Gauss-Verfahren wird in praktisch jeder Numerik-Einführung beschrieben, weil das eine Standard-Methode ist. Schwierig ist ggf. nur der Klimbim außen drumrum, also Erkennung, wann Zeilenvertauschung notwendig ist, Prüfung, dass es keine kurzgeschlossenen idealen Spannungsquellen oder leerlaufende Stromquellen gibt und ähnliches. > [...] so viel brauche ich gar nicht, mir ging es um > eine reine "oberflächliche" DC-Variante. Ach so... das vereinfacht natürlich vieles; Du musst nicht mit komplexen Zahlen herummachen, sondern reelle genügen. > Die Probleme, die aufgetreten sind waren immer eine > der drei Möglichkeiten Division durch Null bzw. > falsche/unlösbare Gleichungen, Endlosschleifen bei > der Bildung der Gleichungen oder einfach komplett > falsche Ergebnisse. Ich mache irgendwo Fehler bei den > Gleichungssystemen aber ich kann nicht gut beschreiben > oder genau wissen wo. Naja, Du solltest - Aufstellen der Gleichungen, - Umformen des Gleichungssystems, - Lösen der Gleichungen (Rückwärts-Einsetzen) separat implementieren. Sprich: Erstmal dafür sorgen, dass einfache Fälle mit vorher bekannter Lösung und ohne Sonderfälle korrekt gerechnet werden. Dann erst kommt die Automatik, die aus der Netzliste die Gleichungen aufstellt.
> Ach so... das vereinfacht natürlich vieles; Du musst > nicht mit komplexen Zahlen herummachen, sondern reelle > genügen. Hatte ich gehofft. Ich habe auch einen Versuch mit komplexen Zahlen gemacht, bzw. in Richtung Vektorrechnung, hat aber keine besseren Ergebnisse gebracht. Hast Du sowas schon gebastelt, Egon?
Ben B. schrieb: >> Ach so... das vereinfacht natürlich vieles; Du musst >> nicht mit komplexen Zahlen herummachen, sondern reelle >> genügen. > Hatte ich gehofft. Ich habe auch einen Versuch mit > komplexen Zahlen gemacht, bzw. in Richtung Vektorrechnung, > hat aber keine besseren Ergebnisse gebracht. Naja, was heisst "bessere Ergebnisse"... wenn man komplexe Wechselstromrechnung machen will, braucht man halt die komplexen Zahlen. Ist auch nicht wirklich schwierig, nur ggf. einmal das Gerammel für die Grundoperationen. > Hast Du sowas schon gebastelt, Egon? Jein. Ich habe mal an einem Analyseprogramm herumgebastelt, ja, aber das funktionierte nicht mit linearen Gleichungs- systemen, sondern analysierte die Schaltungsstruktur. Es war deshalb auf Reihen-Parallelschaltungen und Ketten- leiter beschränkt, konnte also nicht beliebige Schaltungen berechnen (z.B. keine Brückenschaltungen). Allerdings arbeitete es mit komplexen Zahlen (AC-Analyse). In Deinem Fall ist die Knotenpotenzialanalyse die Standard- methode. Struktur und Bauteilwerte der Schaltung stecken in der (reellen oder komplexen) Matrix der Leitwerte; die Variablen sind die Knotenpotenziale, die als Ergebnisse berechnet werden sollen. Wie das mit dem Konstantenvektor und den Strom- und Spannungsquellen funktionierte, habe ich vergessen. Lässt sich aber im Prinzip herausfinden; es gibt auch Papers darüber. Die rein mathematische Seite dürfte nicht übermäßig schwierig sein; das Problem besteht eher darin, dass man keine verbotenen Schaltungen konstruieren darf (z.B. Parallelschaltung zweier unterschiedlicher Spannungsquellen). Hilfe wird aber deutlich einfacher, wenn Du konkreter fragst und ggf. was zur Arbeitsweise Deines Codes sagst...
Zeig doch mal Deine Papierversion und den PHP-Code her, dann kann man auch was dazu sagen.
> Zeig doch mal Deine Papierversion Da habe ich das mit der Knotenpunktregel und Maschenregel gemacht, wie für die ganz normale Brückenschaltung. Die Summe aller Spannungen und die Summe aller Ströme in einem Knotenpunkt ist Null. I lässt sich dabei durch U/R ersetzen und umgekehrt, alle R sind bekannt. Für komplexere Sachen werden aber auch die Gleichungen gleich wesentlich komplexer und an dem Punkt hört's auf dem Papier auf, Spaß zu machen. > und den PHP-Code her, dann kann man auch was dazu sagen. Den kann ich nach dem ganzen Gebastel keinem mehr zumuten, manche Teile sind auch schon Monate alt, so daß ich selbst nicht mehr 100% durchblicke wieso ich manches so und nicht anders probiert habe oder zu welchen Versuch der Teil gerade gehört. Das würde ich mir selbst zerreißen wenn ich es irgendwo abgeben müsste. Den Lösungs-Kern schreibe ich wenn dann auf jeden Fall nochmal komplett neu, was anderes bleibt mir nicht übrig und daher auch dieser Thread. Vielleicht kann ich noch Teile der Schaltplan-Bildung wiedernutzen, aber mehr als diese beiden Sachen waren auch nie da. Im Grunde war das so aufgebaut, daß alle Stromknoten einen festen "Namen" hatten und alle Verbindungen als Widerstand zwischen zwei "Namen" dargestellt waren. Dadurch konnte man erste Vereinfachungen vornehmen wie parallele Widerstände finden und diese zu einem einzelnen Äquivalent-Widerstand zusammenfassen - wobei das Hilfen für den Menschen sein sollten, dem Computer müssten solche Vereinfachungen egal sein, der kompensiert das durch etwas mehr Rechenleistung und deswegen habe ich diesen Schritt wieder weggelassen. Man konnte auch nach "inaktiven Teilen" suchen und diese für die Berechnung als irrelevant markieren, etwa wenn ein Widerstand nur eine Verbindung oder gar keine besitzt. Wobei das tricky war, wenn ich das normal schreibe, dann andersrum, also ich markiere die aktiven Teile bzw. aktiven Stromknoten. Da muß nach beiden Seiten durch den Schaltplan laufen und ein Widerstand ist nur dann "aktiv" wenn es an beiden Seiten einen aktiven Stromknoten gibt. Wenn nicht, z.B. weil ein Ende irgendwo in der Luft hängt, kann da auch kein Strom fließen, der Widerstand kann aus der Berechnung raus, U und I gleich Null. So findet man auch Fehler wenn eine Stromquelle mit keiner Stromsenke verbunden ist oder eine Stromsenke mit keiner Stromquelle, wobei eine Stromsenke gleich wie eine Stromquelle "aufgebaut" war, nur mit negativem Strom. Die kann man gleich mit einem X markieren und aus der Berechnung herausnehmen. Es sollte aber auch keinen Unterschied machen wenn man sie drinlässt (mit Strom gleich Null), solange es mindestens eine aktive Stromquelle und -senke gibt. Ohne mindestens eine solche Verbindung sind alle Ströme Null. Dann noch eine Prüfung, ob die Summe aller Ströme aller aktiven Stromquellen und -senken sich aufheben, wenn nicht dann meckern oder anpassen, das ist einfach. Als nächstes habe ich probiert, in einer Schleife daraus Gleichungen für jeden R zu erzeugen, egal wie lang die Gleichungen werden (ein Computer löst sie auch wenn sie aus tausenden Teilen bestehen). Dabei wurden alle R als Teilströme durch sie hindurch abgebildet, die man hinterher einfach alle hätte addieren können. Wenn sich ein R gleichungsmäßig verändert hat, wurde die Schleife nochmals für alle anderen R durchlaufen. Das war der vielversprechendste Versuch, aber mir ist es bei komplexeren Schaltungen nicht gelungen, einen stabilen Zustand des Gleichungssystems zu erreichen. Wie gesagt, ich glaube irgendwo ist der Lösungsansatz nicht der beste oder schlicht falsch. Menschliche Logik oder Auffassungsvermögen nachzubilden ist gar nicht so einfach, vielleicht ist es besser irgendwas "stupides" für den Computer zu basteln und dieses genau so stupide durchrechnen zu lassen anstelle zu versuchen, es wie ein Mensch zu lösen.
Ich habe mal rudimentär ein Progrämmchen in Python (PHP kann ich nicht) geschrieben, das nach dem Knotenpotentialverfahren die Spannungen und Ströme einer Schaltung aus Widerständen, Stromquellen und GND-Referenzen berechnet. Das sollte sich mit endlichem Aufwand auch in PHP umsetzen lassen. Für die Lösung des linearen Gleichungssystems wollte ich das Rad nicht neu erfinden und habe deswegen die linalg.solve() aus NumPy verwendet. Die Ergebnisse für die angehängte Beispielschaltung:
1 | V_A = 1.780984e-01 V |
2 | V_B = 1.810636e-01 V |
3 | V_C = 3.061216e-01 V |
4 | |
5 | I_R1 = -1.976798e-05 A |
6 | I_R2 = -1.280232e-03 A |
7 | I_R3 = -5.684455e-04 A |
8 | I_R4 = 5.486775e-04 A |
9 | I_R5 = 6.513225e-04 A |
Zum Vergleich die Ergebnisse der Simulation mit LTspice:
1 | --- Operating Point --- |
2 | |
3 | V(a): 0.178098 voltage |
4 | V(b): 0.181064 voltage |
5 | V(c): 0.306122 voltage |
6 | I(I2): 0.0025 device_current |
7 | I(I1): 0.0012 device_current |
8 | I(R5): 0.000651322 device_current |
9 | I(R4): 0.000548678 device_current |
10 | I(R3): -0.000568445 device_current |
11 | I(R2): -0.00128023 device_current |
12 | I(R1): -1.9768e-005 device_current |
Passt :)
> Für die Lösung des linearen Gleichungssystems wollte > ich das Rad nicht neu erfinden und habe deswegen die > linalg.solve() aus NumPy verwendet. Genau da liegt das Problem. Könnte ich natürlich irgend wie ähnliches zurechtbiegen, aber PHP kann kein Linsolve mit Bordmitteln.
Ben B. schrieb: >> Für die Lösung des linearen Gleichungssystems wollte >> ich das Rad nicht neu erfinden und habe deswegen die >> linalg.solve() aus NumPy verwendet. > Genau da liegt das Problem. Könnte ich natürlich irgend wie ähnliches > zurechtbiegen, aber PHP kann kein Linsolve mit Bordmitteln. Ich hatte gedacht, deine Probleme liegen im Aufstellen der Gleichungen: Ben B. schrieb: > Die Probleme, die aufgetreten sind waren immer eine der drei > Möglichkeiten Division durch Null bzw. falsche/unlösbare Gleichungen, > Endlosschleifen bei der Bildung der Gleichungen oder einfach komplett > falsche Ergebnisse. Ich mache irgendwo Fehler bei den Gleichungssystemen > aber ich kann nicht gut beschreiben oder genau wissen wo. Für das Lösen des Gleichungssystems, nachdem es einmal aufgestellt worden ist, findest du im Netz jede Menge Beispiele, auch in PHP: http://tutorialspots.com/php-solve-system-of-linear-equations-using-matrices-3493.html https://numphp.org/blog/solving_a_linear_system_in_php https://stackoverflow.com/questions/11137840/php-algorithm-to-solve-a-system-of-linear-equations-of-grade-1 ...
>Was ich meine ist ein vermaschtes Netz aus Widerständen, aus dem an >bestimmten Stellen ein Strom eingespeist und an anderen Stellen >entnommen wird Oh, oh, da wird mir ganz mulmig. Stell Dir ein Mini-Netzwerk aus zwei Knoten A und B vor, die über einen Widerstand (1 Ohm) miteinander verbunden sind. Knoten A soll auf Masse liegen. In A soll ein Strom von 2 A reinfließen und aus B ein Strom von 3 A raus. Dein Algorithmus soll nun das Potential von Knoten B berechnen. Problem: Die Aufgabenstellung ist physikalisch unsinnig, denn 2 A rein und 3 A raus widerspricht der Ladungserhaltung. Wenn Du Deinen Netzwerken Ströme von außerhalb in Knoten rein oder raus erlauben willst, muss Du Dir (auch) darüber Gedanken machen, wie Du solche Fälle mathematisch berücksichtigen willst.
>und den Teil, der mir offensichtlich fehlt, dazulernen. Wie andere hier schon sagten, brauchst Du für diese Aufgabe genau zwei Teile: Einen Builder, der aus den Netzdaten das LGS ("A·x = b") generiert, und einen Solver, der es löst. Er gibt bestimmten Elementen in der Matrix A und dem Vektor b bestimmte Werte. Das ist alles. Zeilenvertauschungen muss der Solver natürlich handeln können (kommen massenhaft vor, weil A dünn besetzt ist), aber das ist eh selbstverständlich. Auch eine Pivotsuche ist empfehlenswert. Ist aber alles kein Act. Du kannst Dir natürlich noch einen schicken grafischen Editor basteln; das wäre dann aber eine andere Baustelle. >vermaschtes Netz aus Widerständen, aus dem an bestimmten Stellen ein Strom >eingespeist und an anderen Stellen entnommen wird Braucht niemand. Einem Netz, bei dem in irgendeinen Knoten zusätzlich ein Strom von 3 A rein- und von einem anderen Knoten genausoviel wieder wegfließen soll, fügt man schlicht eine 3-A-Stromquelle hinzu, die das Gewünschte erledigt. >Die Summe aller Spannungen und die Summe aller Ströme in einem Knotenpunkt >ist Null. Ja, der Summenstrom ist für jeden Knoten Null. Für Spannungssummen gibt es auch eine "Ist-gleich-Null-Regel", aber die bezieht sich auf Maschen. Also auf das, womit Du Dich nicht beschäftigen möchtest. Oder hast Du Lust darauf, irgendwelche rekursiv arbeitenden Suchbaumalgorithmen zu entwickeln, um geschlossene Pfade (= Maschen) im Netz ausfindig machen zu können? Nein, natürlich nicht. Musst Du zum Glück auch nicht, denn Du kannst ja auch nur durch die Betrachtung der Knoten und Zweige zu einer Lösung kommen (halt nur nicht zu einer unschlagbar effizienten). >Im Grunde war das so aufgebaut, daß alle Stromknoten einen festen >"Namen" hatten Zahlen 1, 2, 3... reichen auch und Du kannst auch besser damit rechnen. >Dadurch konnte man erste Vereinfachungen vornehmen wie parallele >Widerstände finden und diese zu einem einzelnen Äquivalent-Widerstand >zusammenfassen Kann man machen (--> kleineres LGS --> weniger Speicher, mehr Speed), muss man aber nicht. >etwa wenn ein Widerstand nur eine Verbindung oder gar keine besitzt. Also: Ein Widerstand hat immer zwei Beinchen, und jedes endet auch immer in einem Knoten. Es ist aber durchaus zulässig, dass einem Knoten nur ein Zweig zugeordnet ist. So ließe sich dann ein in der Luft hängender Widerstand modellieren. Wobei Du obligatorischerweise einen der beiden Knotenpunkte noch als GND-Knoten festlegen musst. Stell doch das LGS von Hand auf und rechne nach, dass die Determinante von A nicht Null ist - nicht mal dann, wenn R = 0 ist. Also wird auch der Solver damit kein Problem haben. Die Lösung ist natürlich 0, 0, 0. Mit vielen Spannungsquellen in Reihe statt des Widerstands wäre dieses "Netz" (das ja eigentlich keins ist) sogar interessant: Auf welchen Potentialen liegen die Zwischenknoten? Möchtest Du nicht, dass Dein Programm das ausrechnen kann? Mit einer Stromquelle wäre so etwas allerdings tatsächlich verboten. Man darf auch keine (verschiedenwertige) I-Quellen in Reihe schalten, oder (verschiedenwertige) U-Quellen parallel zueinander. Auch U-Quellen kurzschließen ist verboten und es darf auch keine geschlossenen Pfade im Netz geben, die ausschließlich U-Quellen enthalten (außer, die Summe aller Us ergibt Null). Bei all dem ist die Matrix A dann auch singulär und der Solver wird beim Versuch, das LGS zu lösen, scheitern, weil er in irgendeinem Eliminationsschritt kein von Null verschiedenes Pivotelement findet. >Stromsenke Was soll das sein? >vielleicht ist es besser irgendwas "stupides" für den Computer zu basteln >und dieses genau so stupide durchrechnen zu lassen anstelle zu versuchen, >es wie ein Mensch zu lösen. Gut erkannt. Warum machst Du es dann nicht so? Du musst halt ein "großes" System als Ansatz akzeptieren. Da muss dann zwar der Solver mehr ackern, aber das Besetzen von A und b durch den Builder ist easy. "Groß" bedeutet: Der Lösungsvektor besteht aus allen N Knotenpotentialen und allen B Zweigströmen. Das ist das Maximum an Unbekannten. Das System hat dann die Dimension d = N + B (*). Für einen (s. o.) einzelnen Widerstand zwischen zwei Knoten (B = 1, N = 2) macht das d = 3, und für die klassische Brückenschaltung (B = 6, N = 4) schon d = 10. Die Lösung eines LGS mit Gauss (genauer: Die LR-Zerlegung der Koeffizientenmatrix) erfordert 1/3 d^3 Operationen; für ein d=30-System sind das 9000 Stück. Das wirst Du auf Deinem PC (noch) nicht spüren. (*) Aber Achtung: Es enthält nicht B Zweiggleichungen und N Knotengleichungen, sondern B Zweiggleichungen, N - 1 Knotengleichungen und eine Gleichung zur Festlegung, welcher Knoten auf GND liegt. Abschließend noch ein Tipp: Es ist eine gute Idee, für einen Zweig grundsätzlich nur ein Bauelement zuzulassen: R oder U-Quelle oder I-Quelle. Das stellt keine Einschränkung dar, denn aus jedem anderen Zweig kann man durch Hinzufügen von Knoten eine Kette mehrerer Primitivzweige machen: o---U---R---o ===> o---U---o---R---o. Für den Fall, dass zwei Knoten durch "Leitung" miteinander verbunden sind, gilt ebenfalls: Kann man machen, muss man aber nicht. Man darf das einfach als Zweig betrachten. Wenn darin ein wohldefinierter Strom fließt, wird er auch korrekt ausgerechnet. (Wie wäre das eigentlich bei der Knotenpotential-Methode? Für R = 0 ist G = unendlich aber das kann man ja schlecht in die G-Matrix schreiben?) OK, das soll dann auch mal genügen.
LostInMusic schrieb: ....Viel Text.... > OK, das soll dann auch mal genügen. Und deshalb habe ich damals einfach Spice genommen. Da haben viele kluge Leute die ganzen Sonderfälle schon einprogrammiert. Da konnte ich nicht viele Fehler im Algorithmus machen, weil ich wußte, Spice liefert einfach. Manche Leute haben Spass an der Mathematik, den Formeln und dem Lösen von Gleichungen. Ich wollte nur das Ergebnis. Da war der Spice Weg schneller und zuverlässiger.
Es ist ja auch völlig legitim, ein Tool zu verwenden, ohne zu wissen, wie es (im Detail) funktioniert. Man muss dann halt auf seine Qualität vertrauen. Die Fragen des TO zielten aber eindeutig auf das mathematische Know-How ab. "Wie wird eine Zange hergestellt?" "Nimm doch die aus dem Werkzeugkasten!"
Erst kommt die Mathematik. Man benoetigt N Gleichungen mit N Unbekannten. Die sollten unabhaengig voneinander sein und gut bestimmt. Das bedeutet stabil gegen kleine Aenderungen. Die wirft man dann in den Gauss Algorithmus. Da kommen dann die Werte raus fuer die Unbekannten. Dazu vorne dran etwas fuer den Input der Daten, und hinten dran etwas fuer den Output. Bei beiden scheint mir Javascript tauglicher zu sein.
In Javascript wird das nicht einfacher/schwerer als in PHP. Im Augenblick habe ich leider nicht so viel Zeit, um die Sache nochmal anzugehen. Ich lese zwar alles in diesem Thread sehr interessiert durch, aber kann mich im Moment nicht konzentriert auf einen Programmierversuch stürzen (einfach zuviele andere Dinge). Oder mal eine Frage ins Blaue, falls das jemand hier programmieren kann, wieviel müsste man dafür bezahlen? Ich habe bei manchen Programmier-Aufgaben das Problem, daß ich versuche, sie zu exakt anzugehen. Vielleicht trifft das hier auch zu und erklärt die Fehlversuche. Als Beispiel, wenn ich einen Ego-Shooter (auf Deutsch Ballerspiel) schreiben würde, dann würde ich probieren, genau auszuwerten ob ein Ziel getroffen wurde oder nicht, auf den Pixel genau. Das ist natürlich etwas aufwendig, deswegen verwenden solche Spiele einfach eine sogenannte Hitbox, die sich wesentlich einfacher handhaben lässt und nehmen die dabei auftretenden Ungenauigkeiten in Kauf. Für diesen speziellen Fall weiß ich, daß das ausreichend gut funktioniert, aber wenn ich ein vergleichbares Problem vor mir habe und sowas nicht weiß, würde ich das pixelgenaue Äquivalent probieren, was deutlich schwerer realisierbar ist (oder am Ende aus irgend einem Grund nicht gut funktioniert). Ich weiß nicht ob ich hier gerade wieder so einen "Fehler" mache oder nicht.
Ben B. schrieb: > In Javascript wird das nicht einfacher/schwerer als in PHP. Natürlich nicht. Javascript ist eine einzige Grütze. Aber aufgrund des Nutzung im Web wird es seit einiger Zeit überall reingedrückt, egal ob sinnvoll oder nicht.
Bisschen witzig ist das hier schon. Erst kommt jemand, der möchte alles selber machen und lernen. Insbesondere die Mathematik. Das vorgeschlagene Paket Spice, was alles löst, möchte er nich benutzen sondern lieber selber prokeln. Und dann 14 Tage später wird ihm alles zu viel, und er möchte, dass ihm jemand anders das programmiert. Es geht also doch nicht um das Lernen, sondern eine Lösung zu haben. Dann hätte er doch auch Spice nehmen können. Damit wäre er jetzt schon fertig.
Ben B. schrieb: > Ich habe bei manchen Programmier-Aufgaben das Problem, > daß ich versuche, sie zu exakt anzugehen. Das ist m.o.w. normal. Ich behaupte, dass das jedem so geht. Ein (methodischer) Fehler wird es erst, wenn man auf diesem Stand stehenbleibt . Soll heißen: Jeder übertreibt irgendwann. Wenn man aber erkennt , dass man übertreibt, sollte man sich bemühen, es zu unterlassen. (Und man sollte sich natürlich auch bemühen, solche Situationen zu erkennen ...) Ein verwandter Fehler besteht darin, mit Gewalt jede Lösung eines Teilproblems selbst erfinden zu wollen, statt bei Standardproblemen auf Standardlösungen zurückzugreifen -- auch das ist eine Art von Übertreibung. > Vielleicht trifft das hier auch zu und erklärt die > Fehlversuche. Fehlversuche sind erstmal kein Problem. Sie werden eins, wenn man keine Schlussfolgerung daraus zieht, wie man es besser macht. > Als Beispiel, wenn ich einen Ego-Shooter > (auf Deutsch Ballerspiel) schreiben würde, dann würde > ich probieren, genau auszuwerten ob ein Ziel getroffen > wurde oder nicht, auf den Pixel genau. Das ist > natürlich etwas aufwendig, deswegen verwenden solche > Spiele einfach eine sogenannte Hitbox, die sich > wesentlich einfacher handhaben lässt und nehmen die > dabei auftretenden Ungenauigkeiten in Kauf. Für diesen > speziellen Fall weiß ich, daß das ausreichend gut > funktioniert, aber wenn ich ein vergleichbares Problem > vor mir habe und sowas nicht weiß, würde ich das > pixelgenaue Äquivalent probieren, was deutlich > schwerer realisierbar ist Das macht doch vorläufig überhaupt nichts. Wenn man nicht weiss, wo man anfangen soll, fängt man erstmal irgendwo an, wo man ein Problem sieht, das einem lösbar erscheint, und sammelt Lösungsideen. Ist man unsicher, ob eine bestimmte Idee überhaupt funktionieren kann, macht man einen Vorversuch. Stellt sich das Teilproblem immer noch als zu komplex heraus, beschränkt man sich auf einen gut handhabbaren Spezialfall. Glaubt man, für das bearbeitete Teilproblem eine (halbwegs vollständige) Prinziplösung beisammen zu haben, fängt man an, eine konkrete Lösung auszuformulieren und zu implementieren. Nach jedem größeren Arbeitsschritt stellt man sich drei Fragen: 1. (Funktionalität): "Ist das, was der bereits implementierte Teil leistet, nützlich ? Leistet es einen klar abgrenzbaren und beschreibbaren Teil der Arbeit, die das Gesamtsystem später mal leisten soll? Ist mir der künftige Platz dieses Teilsystems im -- noch nicht existierenden -- Gesamtsystem klar?" 2. (nichtfunktionale Qualitätsaspekte): "Ist die Teillösung hinsichtlich ihrer Betriebseigenschaften verträglich mit den Anforderungen und den anderen Teilsystemen? Sind Ressourcenverbrauch, Zuverlässigkeit, Kosten, Masse, Volumen, Lärm, ... akzeptabel?" 3. (Wissen und Wissensdefizite): "Ergeben sich aus dem, was ich jetzt zum Laufen gebracht habe, neue Aspekte, neue Fragestaellungen für das Gesamtprojekt? Sind mir Probleme aufgefallen, von denen ich vorher keine Ahnung hatte?" > (oder am Ende aus irgend einem Grund nicht gut > funktioniert). Oho! Das ist aber ganz und gar nicht dasselbe. Eine funktionierende Lösung, die nur unnötig aufwendig ist, ist ein Erfolg -- wenn auch einer mit Verbesserungs- potenzial. Eine Lösung, die aufgrund mangelnder Qualität nicht einsetzbar ist, ist ein Fehlschlag. (--> Ruskins Law: "Es ist besser, zuviel zu bezahlen als zu wenig. [...]") Im Beispiel Deiner Kollisionserkennung: Zuerst muss man natürlich irgend eine Idee habe, um Kollisionen überhaupt zu erkennen (Funktionalität). Dann muss man als Randbedingung absichern, dass die geplante Lösung auch praktisch einsetzbar ist (nichtfunktionale Qualitätsaspekte), also beispielsweise, dass sie schnell genug ist (Laufzeit). Wer viel Erfahrung und/oder ausreichend Hintergrundwissen hat, bekommt das beim ersten Schuss hin -- wer noch unerfahren ist, dreht eben eine oder zwei Ehrenrunden. Das ist eben so. Es gilt aber der Ausspruch von Alf:" Etwas nicht zu können ist kein Grund, es nicht zu tun!" :) > Ich weiß nicht ob ich hier gerade wieder so einen "Fehler" > mache oder nicht. Ich weiss nicht, welchen Fehler Du machst. Von außen sieht es jedenfalls nach einer soliden mentalen Blockade aus.
>...ob ich hier gerade wieder so einen "Fehler" mache oder nicht.
Können wir rausfinden: Stell für dieses Netzwerk das zugehörige LGS auf
(*) und poste hier das Ergebnis Deiner Bemühungen. Das wird alle
Probleme, die Du hast, offenlegen. Ganz simpel, oder?
(*) LGS = lineares Gleichungssystem. "Das" LGS meint irgendeins. Nur
aufstellen. Von Hand. Form egal. Nichts rechnen. Viel Erfolg.
LostInMusic schrieb: > Nichts rechnen. Wenn man es anders zeichnet, so dass die Kreuzung wegfällt, dann ist es eine einfache H-Brücke aus Widerständen und wenn alle Widerstände gleich groß sind, fließt kein Strom.
@Michael M: Hoppla, Missverständnis: Der Kreis mit dem Pfeil darin ist kein Ampèremeter, sondern eine Konstantstromquelle ==> in dem betreffenden Zweig fließt der Strom I in Pfeilrichtung. Es handelt sich hier nicht um eine Wheatstonebrücke, auch wenn das Netz dieselbe Topologie hat.
Ben B. schrieb: > Wäre schön wenn das irgendjemand in PHP schafft Hi, ich hatte n paar Minuten und hab mal yalus python in für Dich hoffentlich leichter lesbaren php Code 'übersetzt' keine Abhängigkeiten, keine Bibliotheken, keine hübsche Struktur; ich hab nur versucht so nah wie möglich an yalus code zu bleiben, Hab ein mini bisschen Struktur hinzugefügt, dass Du erkennst was hinzugefügt wurde um externe Bibliotheken zu umgehen. gruss 'sid
HÄ? wieso hatter zweimal... hab ich etwa doppelt geklickt?? yalu, könntest Du bitte eins löschen? Danke 'sid
sid schrieb: > yalu, könntest Du bitte eins löschen? Danke Ich habe das zweite Datei gelöscht oder, genauer gesagt, den Löschbutton gedrückt. Auf Grund von irgendwelchem serverseitigen Caching kann es eine Weile dauern, bis der gelöschte Anhang tatsächlich verschwindet.
Yalu X. schrieb: > Ich habe das zweite Datei gelöscht oder, genauer gesagt, den Löschbutton > gedrückt. Ich danke Dir, keine Ahnung wie das passiert ist; ich vermute ich hab irgendetwas beim upload knopf verbaselt. Ich hab scheinbar auch was beim automatisierten Einrücken mit meinem Editorscript vergessen; weswegen er nun Einzeiler nicht korrekt eingerückt hat... Achja So ist das halt wenn man was 'schnell schnell' macht, ohne nochmal drüber zu gucken. Und ja, es IST mir peinlich ;) Zum Glück ist php indent-agnostic :D 'sid
@sid Ganz großes Danke für Deine Mühe, vielleicht habe ich heute etwas Zeit, mir den Code einmal anzuschauen und auseinanderzunehmen. Ich habe auf jeden Fall irgendwie zu kompliziert gedacht oder versucht, in zuvielen Schritten zuviel zu optimieren - alle meine Versuche waren vom Code her deutlich länger als Deine Variante. Wie gesagt, ich vergesse immer wieder, daß Computer "dumm" sind bzw. "dumme" Aufgaben mögen und unschlagbar darin sind, "dumme" Aufgaben selbst bei gigantischer Länge in extremer Geschwindigkeit durchzurechnen, wozu ein Mensch niemals fähig wäre. Wegen den PHP-Versionen sollte es bei solchen Dingen recht wenig Probleme geben. Die gibts eher bei "internationalen Funktionen", Sicherheit/Kryptographie oder Erweiterungen wie mysql/mysqli. Ich habs auf meinem Heimserver kurz getestet (PHP 7.4) funktioniert, Scriptlaufzeit unter einer Millisekunde. Müsste direkt mal testen, wieviele Widerstände es bräuchte, um auf eine Scriptlaufzeit von einer Sekunde zu kommen. **g** Wenn Du mal in der Nähe bist (im Osten von Berlin) sag Bescheid, lade ich Dich auf ein Bier ein. Oder sag mir welche Marke Du gerne hast und lass mir Deine Adresse zukommen (judoka ät gmx deutsch), dann schicke ich Dir ein Fass.
:
Bearbeitet durch User
Hi Ben, zuviel der Ehre ;) das Bier hätte Yalu mehr verdient, ich hab nur übersetzt. Den Gauß'schen Eliminierer hatte ich noch halb im Hinterkopf, deswegen konnt ich den auch recht fix (wieder-)finden.. Also nahezu keine Eigenleistung wie Du siehst (nur Fleissarbeit quasi.. und bei den paar Zeilen von Fleiss zu sprechen ist auch bisserl was drüber :D) Bin ein Kind des Kohlenpott übrigens... Berlin ist daher eher etwas ausserhalb von "Nähe" ;) Aber ich danke Dir herzlich für die Einladung; und stosse in Gedanken gerne mit Dir an. Ja, und ich kenne das nur zu gut, man will "besonders schlau" und endet mit "besonders überfüllt" dabei ist "besonders banal" häufig die beste Methode. Ein Grund weswegen ich OOP für deutlich weniger gut halte als es der Hype einen Glauben lassen will :D grüsse 'sid
So, ich hab nochmal ein paar Tests an meinem alten Code gemacht, lustigerweise scheint der eigentliche Solver (den ich als größtes Problem gesehen habe und deswegen im Vorfeld soviel wie möglich zusammenfassen und vereinfachen wollte) "lauffähig" gewesen zu sein, ich hab mich also irgendwo bei diesen Zusammenfassungen und der Schaltungsanalyse aufgehängt. Egal, mit dem übernommendem Code läufts erstmal ganz gut, ich muss mir nur noch ein paar Gedanken über die Fehlerkorrektur machen. Im Moment hat das Script eine starke GIGO-Mentalität (garbage in - garbage out), also ein negativer Widerstand oder eine falsch gepolte Stromquelle erzeugt lustige Effekte, die zwar mathematisch korrekt, aber praktisch völliger Quark sind. OOP mag ich auch nicht, ich finde prozedurale Programmierung wesentlich besser. Der Datenfluss lässt sich für mich prozedural deutlich besser darstellen (Eingabe->Prozedur->Ausgabe) bzw. größere Prozeduren lassen sich einfacher in kleinere Teile zerlegen, dadurch finde ich Programmcode besser verständlich bzw. man kann sich leichter in solchem Code zurechtfinden. Ich bin in der Programmierung sowieso eher "old school", obwohl manche alten Konzepte aus sicherheitstechnischen Aspekten nur noch wenig Sinn machen. Sowas wie "code is data and data is code" wird heute leider gar nicht mehr gerne gesehen, und strenge Deklaration von Variablen werde ich wohl niemals mögen. define blub as string blub=1 **kotz** Oder Konstanten sind genau so "schlimm". <?php foo="bar"; ?> **kotz** Keine Ahnung wofür man das eigentlich braucht, außer daß man sich Konstanten auf diese Weise nicht so leicht durch Unachtsamkeit zerschießen kann. Meine Programme nutzen allerdings kaum Konstanten, bzw. wenn ich sowas brauche, dann bekommt das einen Namen, der impliziert, daß man den Inhalt nicht überschreiben sollte. Als Beispiel sowas wie $config_foo="bar"; ... Immer diese verschiedenen Programmierstile, furchbar. :)
Bitte 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.