Du beginnst mit zahl bei 0, wirst aber nur aktiv wenn zahl ≥ 1 :-)
Sofern das nicht sowieso raus optimiert wird, sparst du dir schon mal einen Vergleich pro Durchlauf, wenn du direkt bei 1 beginnst. Und du sparst dir optisch eine Einrückungsebene.
ConvertToInt64 brauchst du auch nicht, liest sich nur schwer aber der Compiler wandelt dir das automatisch um.
Was ich mir jetzt alles überlege, bitte selber noch nachprüfen.
Was genau soll in primzahl stehen? So wie ich das Sieb verstehe, markiert es Zahlen. Wäre also ein Array von bool Werten statt Zahlen?
Ich würde primzahl[ i ] nicht mit i+1 füllen, sondern mit i. Sonst kennt sich keiner mehr aus.
Das führt dann dazu dass du nicht mehr primzahl[zahl] auslesen musst was einen Zugriff auf das Array bedeutet, sondern du bei der Prüfung auf != u und der Rechnung mit % direkt zahl verwenden kannst.
Nur für primzahl [zahl] != 0 brauchst du noch das Array, denn das prüft die Markierung der Zahl, statt den Wert selbst.
Zu if (primzahl[zahl] % u == 0) was mit sinnvolleren Zuweisungen das selbe ist wie if (zahl % u == 0).
Die % Rechnung wird nicht Null, wenn zahl < u. Du kannst also die innere Schleife bei u beginnen, statt bei 0. Das spart einiges an Durchläufen.
Wenn du die Schleife erst bei u+1 beginnst und den Fall zahl == u separat in der äußeren Schleife behandelst, kannst du den Test primzahl[zahl] != u auch weglassen.0
Ein weiterer Ansatz: Das Sieb markiert Vielfache einer Zahl.
Du durchläufst JEDE Zahl und prüfst mit % ob sie ein Vielfaches von u ist. Das funktioniert zwar, ist aber sehr viel Aufwand. Für u = 1000 findest du ein Vielfaches und prüfst dann die nächsten 999 Zahlen ebenfalls, obwohl die kein Vielfaches sein können. Für u = 10000 prüfst du 9999 andere Zahlen ohne Ergebnis.
Also beginne die innere Schleife bei zahl = u und dann nicht mehr zahl++ sondern zahl += u. Dann brauchst du die % Operation nicht mehr und kannst ohne weitere Prüfung primzahl[zahl] = 0 setzen.
Als welcher Datentyp ist denn das Datum in Win32_OperatingSystem gespeichert?
Dieses ToString überall finde ich eine Katastrophe, machen anfangs alle. Alles was man hat wird in einen String gewandelt und dann wieder mühsam zurück.
Wenn die Tabelle Win32_OperatingSystem sauber angelegt ist, ist das Datumsfeld bereits ein Datum und muss nur noch passend gecasted werden.
Ich denke das liegt am "Screen.PrimaryScreen.Bounds.[...]"
Wenn du nur nach dem ersten Bildschirm fragst, bekommst du in der Tat auch nur den ersten zu sehen.
Zitat
screen.Bounds.ToString());" zeigt es richtig an, aber in einer Art und Weise, wie mir das nicht gefällt (Siehe Anhang)
Mal ne irrwitzige Idee, was wenn du die Ausgabe in der Form die du haben willst ganz einfach nicht immer nur mit dem selben Screen.PrimaryScreen.Bounds.Width machst, sondern mit dem aktuellen screen.Bounds.Width?
Was macht der Ping wenn er keine Antwort kriegt, fällt der dann wirklich in eine Exception oder gibt das einen Status zurück?
Dann wäre dein Programm nämlich weit davon entfernt "nichts zu tun", weil es dann permanent ständig pingen würde :-)
laut Einzelkschritt wird die "1" aber in "Wert" geschrieben...
Und was passiert wenn du weiter tippst mit dem Wert?
Den Ausdruck "if ((value % 1) > 0)" finde ich interessant. Da sollte ein Kommentar ran, der aussagt was das soll.
Length == 3 wird nur aktiv wenn genau drei Nachkommastellen eingegeben werden. Was wenn jemand eine Zahl mit 5 Nachkommastellen hineinkopiert?
Machs lieber etwas überschaubarer, zum Beispiel teste ob 100 * value noch Nachkommastellen hat.
Und wieso werden die drei Algorithmen (sind ja alles eine Form der Tiefensuche) haupsächlich für Bäume erklärt?
Ein Baum ist ein Graph mit vielen Einschränkungen. Es gibt nur genau einen Einstiegspunkt, eine definierte Richtung (Pfeil bei der Verbindung) und keine Zyklen. Beim Binärbaum hat ein Knoten maximal zwei Nachfolger, so dass man von links und rechts sprechen kann und die Nachfolger somit auch geordnet sind (z.B. links ist immer kleiner als rechts).
Ein allgemeiner Graph kann bidirektionale Verbindungen und Zyklen haben und seine Nachfolger haben auch nicht unbedingt eine Sortierung.
Preorder und Postorder besuchen die Nachfolger beim Binärbaum entweder alle vor dem Knoten oder alle nach dem Knoten. Das lässt sich von den zwei Nachfolgern beim Binärbaum leicht auf sonstige Anzahlen an Nachfolgern erweitern. Dann sind es eben nicht zwei Teile die man alle vor/nach dem Knoten besucht, sondern mehr.
Inorder besucht den Knoten genau zwischen dem linken und dem rechten Nachfolgerknoten. Das "zwischen" wird beim beliebigen Graphen schwer, denn der hat nicht nur (maximal) zwei Nachfolger.
Natürlich kannst du dir eine Strategie überlegen die "inorder" funktioniert. Zum Beispiel indem du den Knoten selbst immer nach dem ersten Nachfolgebaum untersuchst (egal wie viele noch kommen), oder immer vor dem vorletzten, oder immer nach der Hälfte oder was dir eben einfällt.
Hiermit bekomme ich den Wert weiß aber nicht wie ich das der Schleife übergeben kann, weil ich daraus nicht Length entnehmen kann.
Ist nicht das i das du hier erhältst schon genau diese Anzahl?
Nächster Punkt. Dein Code sieht für mich aus als bräuchtest du nicht nur die Zahl der angehakten Checkboxen, sondern solltest auch wissen welche das sind.
Also solltest du trotzdem alle durchlaufen und in der Schleife aber nur diejenigen berücksichtigen die Checked sind.
Sonst würdest du bei einer angehakten Checkbox mit dem Zähler 1 in deine Schleife gehen und *immer* nur Textbox 0 ansprechen, *egal welche Checkbox* angehakt ist.
Statt dem Gebastel mit den Namen könntest du alle Checkboxen und Textboxen jeweils in ein Array oder eine Liste packen. Dann kannst du mit Index auf diese Elemente zugreifen und brauchst nicht ständig mit Controls.Find hantieren.
Dann *irgendwann später* wenn du verstanden hast was du da tust und wie man Listen, Array etc. benutzt, kannst du dir ansehen was Databinding und Linq ist.
Aber bitte alles der Reihe nach verstehen. Kein Arbeitgeber will von dir hören dass du weißt wie man Linq schreibt und deshalb nicht mehr wissen musst was ein Array ist.
Da du die Variablen nicht als Zahl deklariert hast sondern als Weekday, will der Compiler dafür auch ein Element der Aufzählung haben.
Du könntest das casten als (Weekday)1, dann geht das. Aber dann nimmst du dir den Vorteil, sofort sehen zu können welches Aufzählungselement das ist.
Soweit dazu warum die 1 nicht ohne ausdrücklichen Cast akzeptiert wird.
Warum die 0 dann doch funktioniert, könnte daran liegen dass eine solche Variable mit einer 0 vorbelegt wird wenn du nichts anderes angibst. Daher könnte es sein dass der Compiler erkennt, da passiert ja nichts was ohne diese Zeile nicht auch passieren würde, und er deswegen die Zuweisung hinnimmt.
Mal angemerkt, selbst wenn man rausfinden könnte *wie viele* Parameter eine Methode/Funktion hat, weiß man ja immer noch nicht *welche* das sind.
Würde also nicht sehr viel bringen, denn man hat dann immer noch keinen Hinweis darauf was man da nun übergeben soll.
Klar, wenn du auf beide wartest wird auch auf beide gewartet :-)
Erstelle die zwei Tasks nur einmalig und lass die selbst in einer Schleife schauen ob noch was in der Queue ist.
Zitat
"Queue ist gesperrt"
Eigentlich ist die Queue hier ja *nur* leer, aber nicht gesperrt.
Das nicht gefundene Element heißt jetzt anders, aber das Problem ist dasselbe. Nämlich die Klasse Jahrgaenge weiß nicht was listFach sein soll, denn das Object das so heißt gehört zu einer anderen Klasse.
Lösung: Gib den zu suchenden Wert als Parameter in die Methode Load() hinein.
In der Klasse Jahrgaenge gibt es nichts das FachID heißt.
Du brauchst an dieser Stelle die Instanz des WPF Formulars, denn die kennt das Element namens FachID.
Noch schöner wäre es wenn du den Text aus FachID als Parameter in die Load() Methode übergibst.
Dann muss diese Methode nicht mehr wissen woher dieser Wert stammt. Einer Methode die Daten lädt sollte das nämlich egal sein können.
Es könnte hilfreich sein wenn du die ganzen Begriffe erklärst. Was ist CPU1500, was TIA? Was tut man wenn man eine "PLC Variablen Tabelle projektiert"?
Ja das außerdem! Darauf hab ich gar nicht geachtet.
Wichtig ist also wirklich, debuggen! Anschauen was passiert.
Sonst leitet einen die völlig unbegründete Annahme "alles funktioniert wie es soll, aber ein get funktioniert nicht" in die völlig falsche Richtung.
Bist du sicher dass überhaupt eine Nullstelle berechnet wird?
Zum einen läufst du in Einerschritten über das x. Da muss die Funktion schon passend gewählt sein, um überhaupt Nullstellen zu finden die genau auf diesem Einserraster liegen.
Zum anderen ist die interne Darstellung von Kommazahlen eine komplexe Sache, da gibt es kleine Ungenauigkeiten durch Rundungsfehler, die man bei der gerundeten Ausgabe zwar nicht sieht, die aber trotzdem da sind.
Nehmen wir an du kommst mit dem x wirklich auf eine Nullstelle. Durch die Art und Weise wie ein double dargestellt wird, ist das Ergebnis aber nicht genau 0, sondern vielleicht 0,0000000012345.... Dein Test auf exakt Null findet die exakt-Null daher nicht.
Schau dir mit dem Debugger an was da genau passiert und ob überhaupt eine Nullstelle gefunden wird.
Wenn das der Fall ist, sollten die Werte vom get auch zurückgegeben werden.
Abgesehen von Sinn oder Unsinn dieses Vorhabens, aber wenn die Umsetzung dieser Klassen in der selben Firma erfolgt, sollte doch eigentlich eine Teambesprechung ausreichen um die Programmierung einheitlich zu gestalten ;-)
Ich vermute die *public* InnerClass wird nicht sehr hilfreich für einen Anwender deiner Basisklasse sein. Denn wer die Basisklasse nutzt, will in der Regel nicht wissen welche abgeleitete Klasse tatsächlich dahinter steckt und kann daher auch nicht auf die jeweils spezielle InnerClass zugreifen.
Daher ist es für den Anwender der Basisklasse egal wie diese Klasse heißt.
Dem Autor der abgeleiteten Klassen würde ich auch keine solchen Vorschriften machen, selbst wenn ich könnte. Der soll das nutzen was er braucht und wie er es braucht. Vielleicht braucht eine abgeleitete Klasse mehrere innere Klassen, oder auch mal gar keine.
Oder der Autor möchte die innere Klasse(n) in verschiedenen Ableitungen ausdrücklich verschieden benennen, um zu zeigen in welcher Ableitung er sich gerade befindet. Im Beispiel der Datenbankklassen vielleicht einmal MysqlInnerClass und dann SqlserverInnerClass oder PostgresInnerClass.
wie das Program auf 4.5 kommt weiß ich auch nicht so genau, ist aber auch nicht so tragisch.
Doch ist es. Denn du musst es ja nachbauen und solltest dazu wissen wie.
Woher stammt der Wert 4,5? Da solltest du nachfragen wie man auf den kommt.
Ich würde mir zunächst ansehen wie die gegebenen Werte aus der Tabelle zusammenhängen, also nach welcher Funktion (linear, quadratisch oder sonstiges) man bei einem festen gegebenen Gewicht auf die Werte kommt, sowie wie man bei fester Prozentzahl auf die Werte kommt.
Wenn man sich die Zeile 60 ansieht, stellt man fest dass es schon mal nicht linear ist.
Am besten alle Werte in ein Koordinatenssystem einzeichnen, vielleicht wird da schon ein Ansatz ersichtlich.
Die 4,9 können eigentlich auch nicht sein.
Die Zeile 60 hat, wenn man von linearen Werten ausgeht, bei 24% den Wert 5,0. 23,2% sind noch weiter in Richtung der "5 1/4", also müsste das Ergebnis höher sein als die soeben erwähnten 5%.
Das Gewicht geht leicht in Richtung der Zeile 70, wo die Ergebniswerte ebenfalls höher sind. Also müsste das Ergebnis nochmal ein ganz kleines bisschen höher werden.
IntersectsWith wendet man auf ein Rectangle an und übergibt ein weiteres Rectangle.
pictureBox.Bounds ist vom Typ Rectangle.
bullet ist von welchem Typ?
"lineString" scheint ein komplexes Objekt zu sein das verschiedene "Geometries" und "Points" enthält. Daher kann das rein vom Inhalt her nichts sein was aus einem einzigen double stammt. Erst recht nichts was man durch einen Cast einfach konvertieren könnte.
Ich würde sagen da trifft beides zu. Zum einen falsches Feld und zum anderen muss es eine Konvertierungsroutine geben.
Nachdem du einen Gewinner ermittelt hast, könntest du aus der Prüfmethode heraus springen.
Die Variablen initialisieren wäre kein Schaden. Wird nicht sogar angemeckert dass die keinen eindeutigen Wert bekommen?
Zur Prüfung an sich fällt einem sicherlich das ein oder andere ein.
Zum Beispiel könntest du eine Zeile (Spalte, Diagonale) komplett durchlaufen, dir merken wie viele gleiche Farben du bis zur aktuellen Position schon hintereinander gefunden hast und wenns die vierte mit gleicher Farbe ist, ist das Spiel zu Ende.
Aber ob sich das in der Praxis tatsächlich lohnt?
was passiert wenn der Buchstabe NICHT dem gedrückten entspricht ???
Dann wird er nicht "aufgedeckt". Ansonsten passiert erst mal nichts.
Gehen wirs mal durch. Man gibt ein A ein.
Du prüfst die erste Stelle. Die ist kein A. Wird jetzt schon der Galgen weiter gezeichnet? Nein!
Du prüfst die zweite Stelle. Die ist auch kein A. Es wird immer noch nicht gezeichnet.
Du prüfst die ... Stelle. Die ist ein A. Gut dass du den Galgen noch nicht weiter gezeichnet hast!
Oder: du hast alle Stellen geprüft und nirgends war ein A dabei. DANN kannst du den Galgen weiter zeichnen.
Während du die einzelnen Stellen durchgehst, musst du dir merken ob mindestens eine davon den eingegebenen Buchstaben enthält. Am besten in einem Bool, den du für jede passende Stelle auf true setzt.
Nach der Schleife über die Stellen weißt du dann ob dieser Buchstabe ein Treffer war.
Vermutung rein vom ansehen deines Codes.
Wenn man einen Buchstaben eingibt, prüfst du für JEDE Stelle, ob sie diesen Buchstaben enthält oder nicht. Wenn nicht, zeichnest du den Galgen für JEDE falsche Stelle ein Stück weiter.
Das heißt, ein Wort mit 5 Buchstaben von denen einer der gedrückte ist, zeichnet den Galgen trotzdem um 4 Teile weiter.
Tatsächlich solltest du zuerst prüfen ob es eine Stelle mit dem Buchstaben gibt. Wenn ja, ALLE passenden Buchstaben aufdecken. Wenn nein, den Galgen um EIN Stück erweitern.
Was soll "_ = pictureBox1.CreateGraphics();" sein? Das kann m.M. raus.
die Ausdrücke werden dadurch zum Teil unendlich lang. Hier ein sehr einfaches Beispiel:
Console.WriteLine(TestObjekt.Field[Testklasse.fld.item1]);
58 Zeichen sind doch traumhaft kurz, bezogen auf die Anzahl Zeichen :-)
Ich beziehe die Begriffe "lang" und "kurz" gerne auf die Zeit die man beim Lesen und Verstehen braucht, nicht auf die Länge der Zeile.
Ich würde daher sogar fld noch ausschreiben. Wenn du später wieder in deinen Code schaust und nicht mehr auswendig weißt was das bedeuten soll, ärgerst du dich dass du "damals" nicht ein paar Buchstaben mehr verwendet hast, um zu beschreiben was das sein soll.
Mit den bisherigen Antworten bekommst du deinen Code verkürzt und er bleibt trotzdem noch lesbar und verständlich.
Der Vergleich von zwei Objektvariablen ergibt, ob beide Variablen auf das selbe Objekt zeigen.
Bei einem String will man aber in der Regel nicht wissen ob zwei Stringvariablen auf das selbe Stringobjekt zeigen, sondern ob die Strings vom Inhalt her gleich sind. Der Vergleich von Strings ist daher überschrieben und vergleicht den String Inhalt.
Bildlich: Du hast zwei verschiedene Zettel, also verschiedene Objekte. Auf beiden steht der gleiche Text.
Der Objektvergleich ergibt "sind nicht gleich", denn es sind zwei separate Zettel.
Der Textvergleich ergibt "ist gleich", denn es ist der selbe Text.
Für deinen Vergleich ist das sehr wichtig, denn bisher vergleichst du das Objekt btnStart.Content das selbe Objekt ist wie der String "Start". Das dürfte nicht der Fall sein.
Was du stattdessen wissen willst ist, ob in btnStart.Content der Text "Start" steht.
Die Warnung zeigt an, dass du an dieser Stelle etwas tust, was du eventuell nicht so haben willst.
Ich frage mich nur, warum die erste if-Anweisung vorher nicht gezogen hat.
Schau dir das auch im Debugger an. Ich sehe auf Anhieb keinen Fehler dabei.
Zitat
Was ist der Unterschied es vorher in eine Variable zu schreiben als es direkt im Vergleich zu tun?
Schon die Lesbarkeit ist um einiges besser wenn du keinen irre langen Ausdruck schreibst, sondern eine passend benannte Variable.
Wenn du das dt weglässt und die Variablen date und today nennst, wirds noch flüssiger lesbar.
Außerdem kannst du ein paar Vergleiche weglassen.
Wenn das erste if "dtValue > dtNowPlus60" nicht zutrifft, ist klar dass "dtValue ≤ dtNowPlus60" ist.
Damit reduziert sich das ganze dann zu
if (date > today+60)
return grün
else if (date ≥ today)
return gelb
else
return rot
(mit oder ohne else, wie du es schöner findest)
Anstatt System.Convert würde ich value direkt casten "(DateTime)value". Sieht auch direkt wieder kürzer aus und wenn value kein DateTime ist, knallt dir dein Programm komplett weg, anstatt mit einem eventuell falschen Wert unbemerkt falsch weiter zu machen.