Moderator: Co-Administratoren
Achso...und dein Beitrag ist das nicht? Was Ich habe deinen Beitrag gemeldet. Aus meiner Sicht solltest du dafür verwarnt werden. Und bei einer weitere Verwarnung gehörst du gesperrt.mule hat geschrieben:Ja, wäre schön wenn Badenpower endlich nach dem was er in seiner Signatur stehen hat auch handelt: Also hier endlich die Biege macht! Das Gemotze und Gestänkere ist null konstruktiv und daher schlicht Spam und müllt damit diesen Thread nur zu!
Dankefischmir hat geschrieben:...Ich habe deinen Beitrag gemeldet. Aus meiner Sicht solltest du dafür verwarnt werden. Und bei einer weitere Verwarnung gehörst du gesperrt.mule hat geschrieben:....!
.
Die Idee hatte ich auch bereits. Wenn also detailliert dargelegt werden könnte für welchen Anwendungsfall welche Verschlüsslungsalgorithmen benötigt werden, wäre es sicherlich ein leichtes diese durch Erweiterung der Skriptsprache zur Verfügung zu stellen - offen bin ich dafür allemal. Auf die UTF8 und andere sinnvolle String-Funktionen hattest du mich ja auch gestoßen, sodass ich das ganze dann zeitnah umsetzen konnte und nun sogat einige hier im Forum zur Verfügung gestellten Skripte diese neuen Funktionen bereits nutzen.robsdobs hat geschrieben: Als Anwendungsfall hatte BadenPower das Benutzen von ToString(30) für Verschlüsselung. Dafür hatte Jens ja einen Ausweg gezeigt (obwohl ich der Meinung bin, wenn man den Anwendungsfall hat, dafür eine dedizierte Funktion besser wäre, die einen Standardisierten Algorithmus verwendet).
Welche?robsdobs hat geschrieben:Jens hat ja gute Argumente gebracht.
Und die nächste Fehlinformation.jmaus hat geschrieben:Und übrigens, auch das Argument das wenn man früher ToString(30) gemacht hatte man damit rechnen konnte wie lange der resultierende string wird passt nicht ganz. Das stimmt nur bedingt denn z.b. hat ToString(300) auch nur „nan“ zurückgegeben weil eine 300 Nachkommastellendarstellung per se nicht möglich ist/war mit den von ReGa genutzten Methoden.
Ich kann nicht für andere sprechen, aber ich finde die Möglichkeit mit den Vergleichen gut.BadenPower hat geschrieben:Als Begründung für die Kappung soll angebliche Beseitigung der möglichen Verwirrung der Ausgabe für "normale" User sein und die nun gegebene Möglichkeit von Vergleichen.
Wo ist hier jetzt die Möglichkeit von vergleichen gegeben?
Wo wird der User jetzt mehr verwirrt?
1. wenn .ToString(20) nur 15 Nachkommastellen ausgibt oder
2. wenn .ToString(20) die Ungenauigkeit bei Gleitkommazahlen offenlegt.
Ich denke es ist Punkt 1.
Und wieso soll diese Möglichkeit wegfallen, aber andere Funktionen...
Dies nennt man nicht Fehlinformation, sondern Irrtum. Und diesen einzugestehen habe ich keinerlei Problem. Ich habe die Ausgabe von "nan" wohl fälschlicherweise in diesem Kontext gespeichert und war mir recht sicher, dass auch bereits so bei vorherigen Tests wahrgenommen zu haben. Bei kurzen Nachtests hast du natürlich recht und man kann sogar ToString(3000) eingeben. Der Nutzen des ganzen erschliesst sich mir trotzdem nicht und deine bisherigen Argumente überzeugen mich weiterhin nicht. Daher ändert das auch nichts an meiner Entscheidung (auch wenn die dir nicht gefallen mag), dass bis auf Weiteres es bei der maximalen Länge von 15 Nachkommastellen bleibt, da dies für 99.9% der Anwendungsfälle die bessere Herangehensweise ist. Sollten mir in konstruktiver weise sinnvolle Gründe vorgebracht werden warum mehr als 15 Nachkommastellen bei der ToString-Wandlung einer Gleitkommazahl im Kontext einer Hausautomation sinnvoll ist, so werde ich mir das gerne erneut auf den Tisch ziehen.BadenPower hat geschrieben:Und die nächste Fehlinformation.jmaus hat geschrieben:Und übrigens, auch das Argument das wenn man früher ToString(30) gemacht hatte man damit rechnen konnte wie lange der resultierende string wird passt nicht ganz. Das stimmt nur bedingt denn z.b. hat ToString(300) auch nur „nan“ zurückgegeben weil eine 300 Nachkommastellendarstellung per se nicht möglich ist/war mit den von ReGa genutzten Methoden.
Und ich weis wirklich nicht, weshalb Du diese immer und immer wieder streust und dies vor allem, wenn es um von Dir geänderte Funktionen geht.
Hier der Gegenbeweis, dass .ToString() selbstverständlich immer die richtige Nachkommastellenanzahl zurückgab und nicht wie behauptet "nan":
Das sehe ich genau soBlack hat geschrieben:ich kann es langsamm nimmer lesen....
Das hast Du falsch Verstanden.robsdobs hat geschrieben:Ich kann nicht für andere sprechen, aber ich finde die Möglichkeit mit den Vergleichen gut.
Ich bin auch schon mehrfach auf das Problem beim Vergleich von Gleitkommazahlen hereingefallen. Wenn man nur selten damit beschäftigt ist, denkt man nicht daran.
Code: Alles auswählen
real lReal = 0.3;
if ( 0.7 - 0,4 == lReal)Nein, das steht dem Homematic-Nutzer nicht frei, ausser Du machst keine Firmware-Updates Deiner CCU mehr.66er hat geschrieben:Es steht doch jedem einzelnen Nutzer frei, die Programme von Jens einzusetzen oder es sein zu lassen, oder ?
Wie sollte das gehen?66er hat geschrieben: Basierend z.B. auf Deinem Gegenbeweis in Deinem letzten Beitrag, denke ich, Du bringst das nötige Fachwissen offensichtlich mit. Warum machst Du es nicht besser und steckst Deine Energie anstatt in die Fehlersuche bei Jens in ein eigenes, besseres Projekt und veröffentlichst eine eigene Version?
Das kann leider nicht geschehen, da eine Zusammenrbeit auf Augenhöhe nicht gewünscht ist.66er hat geschrieben: Falls das Wunder doch noch eintritt und Ihr Euch konstuktiv/additiv zusammentut, wird es Mega-Gut.
Ich werde nur kein Bugs mehr melden.jmaus hat geschrieben:Wenn diese Entscheidung dich nun dazu bewegt alle deine Aktivitäten im Forum einzustellen, so ist dies vielleicht bedauerlich, aber wohl auch nicht zu vermeiden.