Math schrieb:> Funktion Potenzieren in Csharp nur über die math.pow Methode?
Erlaube mir die Gegenfrage: Warum sollte es mehrere Alternativen in der
Programmiersprache geben?
Abgesehen davon ist es in den beiden Vorgängern C und Java prinzipiell
nicht anders. Die Syntax stellt nur grundlegende Operationen bereit.
Komplexe Berechnungen sind Sache von Funktionen/Methoden.
Stefan ⛄ F. schrieb:> Erlaube mir die Gegenfrage: Warum sollte es mehrere Alternativen in der> Programmiersprache geben?
In Python gibt es zum Beispiel einen überladbaren Potenzoperator und das
klassische Math.pow. Die Frage ist also nicht abwegig (auch wenn google
wohl schneller gewesen wäre).
Stefan ⛄ F. schrieb:> Erlaube mir die Gegenfrage: Warum sollte es mehrere Alternativen in der> Programmiersprache geben?
Eine reicht, wenn sie generisch ist. Math.Pow rechnet aber fest mit
double und ist deswegen nur eingeschränkt auf long und ulong anwendbar.
Die Operatoren +, -, * und / hingegen sind generisch und funktionieren
deswegen ohne Einschränkungen sowohl mit double als auch mit long. Gäbe
es einen Potenzoperator ähnlich dem ** in anderen Programmiersprachen,
wäre dieser sicher ebenfalls generisch.
Da C# drei Generationen jünger als sein Urgroßvater C ist, sollte man
eigentlich meinen, dass solche Schwächen mittlerweile ausgemerzt sein
sollten. Das sind sie aber nicht.
Ein anderes Beispiel für die unreflektierte Übernahme von Altlasten ist
die verkehrte Vorrangreihenfolge der Vergleichs- und der bitweisen UND-
und ODER-Operatoren.
C# ist halt im Wesentlichen eine Copy-Paste-Sprache, bei der einfach nur
bestehende Sprachkonzepte und -elemente 1:1 zusammenkopiert wurden, ohne
sich Gedanken darüber zu machen, welche davon einer Überarbeitung
bedürfen.
Yalu X. schrieb:> Math.Pow rechnet aber fest mit> double
und das ist mein Problem. brauche das Ergebnis als float, um es auf 9
Nachkommastellen begrenzt zu haben
Ganz so unreflektiert finde ich das nicht. Die Math Bilbiothek könnte
problemlos auch eine pow() Funktion für Integer bereit stellen. Nur
braucht man das sehr selten und würde zudem sehr schnell den möglichen
Zahlenbereich überschreiten.
x^2 braucht man oft, dafür schreibt man einfach x*x.
x^3 ersetzt man durch x*x*x.
und so weiter, danach wird es aber schon exotisch.
Doch wenn du x^1.5 rechnen willst, brauchst du bereit die Fließkomma
Algorithmen.
Stefan ⛄ F. schrieb:> Doch wenn du x^1.5 rechnen willst, brauchst du bereit die Fließkomma> Algorithmen.
Was wenn du eine fixed point oder Matrix-Klasse implementiert hast und
die potenzieren willst?
Math schrieb:> und das ist mein Problem. brauche das Ergebnis als float, um es auf 9> Nachkommastellen begrenzt zu haben
dann muss etwas her wie convert.tosingle
Felix U. schrieb:> Was wenn du eine fixed point oder Matrix-Klasse implementiert hast und> die potenzieren willst?
Dann implementierst du den passenden Algorithmus und alle sind
glücklich.
Stefan ⛄ F. schrieb:> Dann implementierst du den passenden Algorithmus und alle sind> glücklich.
Da wäre es doch schön wenn man ein für eine allgemeine Operation wie
das Potenzieren auch einen Operator hätte, den man entsprechend
überladen kann.
Felix U. schrieb:> Da wäre es doch schön wenn man ein für eine allgemeine Operation wie> das Potenzieren auch einen Operator hätte, den man entsprechend> überladen kann.
Ja schon. Nur diskutiert dann jeder darüber, welche Operation noch dazu
zählen soll. Was ist mit der Wurzel? Oder Währungen? Wenn ich eine
Programmiersprache gestalten würde, dann würde ich dieses Wunschkonzert
bewusst ausschließen, weil das ein Fass ohne Boden ist.
Math schrieb:> kann ich einen gleitkommatypen auf genau drei nachkommastellen> reduzieren?
Davon gehe ich doch mal stark aus - kenne C# allerdings nicht.
Ich benutze dazu üblicherweise Datentypen mit einstellbarer Genauigkeit
und passend zur Anwendung einstellbaren Rundungsregeln: BigDecimal
Warum C+ nur BigInteger kennt, ist mit ein Rätsel. Selbst Datenbanken
haben BigDecimal.
Aber was fehlt kann man hinzufügen, haben andere schon gemacht:
https://gist.github.com/JcBernack/0b4eef59ca97ee931a2f45542b9ff06d
Stefan ⛄ F. schrieb:> Ja schon. Nur diskutiert dann jeder darüber, welche Operation noch dazu> zählen soll. Was ist mit der Wurzel? Oder Währungen?
Die Wurzel ist ja nur eine Potenz, das fiele also schon mal weg.
Währungen oder Einheiten sind eine lineare Skalierung und deshalb schon
darstellbar. Es ist ja nicht so, als müsste man hier ganz neue Theorien
entwickeln, wir können uns an der Mathematik orientieren.
Felix U. schrieb:> Was wenn du eine fixed point oder Matrix-Klasse implementiert hast und> die potenzieren willst?
Dann schreibst du dir einfach deine eigenen Operatoren dafür. Was denn
sonst?
Math schrieb:> kann ich einen gleitkommatypen auf genau drei nachkommastellen> reduzieren?
Du meinst sicher eigentlich: dezimale Nachkommastellen. Und dann ist
die Antwort natürlich: garnicht, jedenfalls für die "normalen"
Gleitkommatypen.
Ausnahme ist Decimal, denn das wurde extra dafür geschaffen, mit
Dezimalkram umzugehen.
Was nun die normalen Floats betrifft: einfach nur für die Ausgabe
entsprechend runden. An vielen Stellen gibt es schon passende
Vorrichtungen dafür, die aber alle letztlich auf die passenden
Überladungen der ToString-Methode zurückgreifen, nämlich auf die, die
einen Formatstring akzeptieren.
Yalu X. schrieb:> C# ist halt im Wesentlichen eine Copy-Paste-Sprache, bei der einfach nur> bestehende Sprachkonzepte und -elemente 1:1 zusammenkopiert wurden, ohne> sich Gedanken darüber zu machen, welche davon einer Überarbeitung> bedürfen.
So ist es. Mußte mal eine Weile mit C# beruflich arbeiten. Es gibt zwar
eine Menge Dinge die nicht schlecht gelöst sind, aber man war nicht
konsequent bis zum Schluß.
Z.B. die Einführung der Nullable-Wertetypen ist keine schlechte Sache,
da man so einfach herausfinden kann ob eine Variable mit Werten belegt
wurde oder nicht. Man muß also die Variable nicht mehr mit irgend einem
Wert initialisieren, von dem man hofft das er niemals in dem zu
erwartenden Wertebereich auftritt. Aber an Stelle alle Variable als
Nullable zu deklarieren hat einen zusätzlichen Datentyp eingeführt.
Beispiel:
int a; ist nicht nullable
int? a; ist nullable
In den normalen Algorithmen verhalten sich nullable Variable genauso wie
die normalen. Bei nullable kann ich halt nur zusätzlich die Abfrage
a==NULL machen bzw. die Variable auf NULL setzen. Hätte man generell
einführen können hat man aber nicht.
Ebenso hat man versucht das (nach meinem Empfinden) unsägliche
Headerkonzept von C durch das sehr gute Unit-Konzept von Pascal/Delphi
zu ersetzen, was ja auch nicht verwunderlich da ja der Chefentwickler
von C# Herr Heljsberg früher bei Borland war und als Erfinder von
Turbopascal und Delphi gilt. Leider funktioniert das ganze nicht so gut
wie in Delphi.
Die Compilierung der Programme zur Laufzeit und der unsägliche Overhead
des .NET Frameworks macht das ganze so unsäglich träge und die Programme
um ein vielfaches größer. Jede native Exe ist deutlich schneller.
Man hätte hier wirklich die Chance gehabt das Gute aus der C und
Pascalwelt zusammen zu führen und eine gute Programmiersprache zu machen
die das gute aus beiden Welten vereint. Aber man hat es wieder einmal
vergeigt, indem man die Altlasten wieder mit geschleppt hat und und gute
(neue) Ansätze nicht konsequent bis zum Ende geführt hat.
Math schrieb:> brauche das Ergebnis als float, um es auf 9> Nachkommastellen begrenzt zu haben
Die Genauigkeit zu reduzieren, ist doch nie ein Problem. Im konkreten
Fall kannst du das Ergebnis nach float casten oder (wenn es exakt 9
Nachkommastellen sein sollen) mit Math.Round auf die gewünschte
Stellenzahl runden.
Aber wozu will man das, außer bei der Ausgabe? Und für die Ausgabe gibt
es bessere Möglichkeiten, die Anzahl der angezeigten Nachkommastellen
festzulegen.
Stefan ⛄ F. schrieb:> Ganz so unreflektiert finde ich das nicht. Die Math Bilbiothek könnte> problemlos auch eine pow() Funktion für Integer bereit stellen. Nur> braucht man das sehr selten
Es geht nicht nur um die Generizität, sondern auch darum, dass das
Aussehen einer Formel in einem Programm möglichst der mathematischen
Schreibweise entsprechen sollte. Wegen der Eindimensionalität der
Programmiersprachensyntax ist das nicht vollständig möglich (man kann
bspw. auch keine Brüche mit übereinanderstehendem Zähler und Nenner
schreiben), aber a^b oder a**b sieht schon sehr viel übersichtlicher aus
als Math.Pow(a, b).
Aus diesem Grund verwendet man ja auch +, -, * und / und nicht etwa
Math.Add(), Math.Multiply(), Math.Subtract() und Math.Divide().
Was die Generizität betrifft: Ganzzahlige Exponenten habe ich sehr oft.
Wenn ich immer sicher wäre, dass dabei die pow-Funktion die Potenz nicht
über Logarithmus und Exponentiation, sondern über die jeweils minimale
Anzahl von Multiplikationen berechnet, wäre das ok. Aber da müsste ich
jeweils tiefer in die Implementation der Funktion schauen.
> x^2 braucht man oft, dafür schreibt man einfach x*x.> x^3 ersetzt man durch x*x*x.
Und wie sieht es bei (2*a+3*b+4)**3 aus? Temporäre Variablen, die nur
dem Zweck dienen, Einschränkungen der Programmiersprache auszubügeln,
verwende ich ungern.
> Doch wenn du x^1.5 rechnen willst, brauchst du bereit die Fließkomma> Algorithmen.
Für die sehr seltenen Fälle, wo man gebrochene Exponenten ungleich 0.5
braucht, akzeptiere ich auch die pow-Funktion trotz ihres hässlichen
Aussehens :)
Yalu X. schrieb:> aber a^b oder a**b sieht schon sehr viel übersichtlicher aus> als Math.Pow(a, b).
Wieder dieser C/C++-Scheuklappenblick, den ich so zum Kotzen finde.
Nein, das ist NICHT übersichtlicher. Es hat nämlich mit der
mathematischen Notation ebenfalls rein garnix zu tun. Sprich: ist nur
für Leute auflösbar, die diese Sprachen können.
> Aus diesem Grund verwendet man ja auch +, -, * und / und nicht etwa> Math.Add(), Math.Multiply(), Math.Subtract() und Math.Divide().
Ja, diese Operatoren entsprechen ja auch der mathematischen Notation
derselben Sache. Naja, bis auf das Asterisk, was die Sache nicht ganz
trifft...
Und übrigens: das "Math." an jeder einzelnen Stelle ist überflüssig. Man
muss halt einmal am Anfang der Datei Math "usen" und der Drops ist
gelutscht.
Math schrieb:> warum wird das in der TextBox so hässlich angegeben
das Problem tritt nur auf, wenn ich eine Dezimalzahl in die TextBox
links eingebe. Bei natürliche Zahlen wird die Umrechnung korrekt auf
drei nachkommastellen angegeben
Ich sehe da nichts hässliches, außer deinen Formfehler:
Quelltexte und Fehlermeldungen postet man als Text, nicht als Bild.
Schaltpläne postet man als Bild, nicht als Text (Prosa).
Ist das so schwer? Oder bin ich zu alt?
Math schrieb:> könnt ihr mir helfen?
Du arbeitest offensichtlich mit deutschen Locales. Und in der deutschen
Kultur dient halt "." nicht als Dezimaltrenner. Sprich: gib einfach
"3,22" statt "3.22" ein ud alles ist schick.
Yalu X. schrieb:> Aus diesem Grund verwendet man ja auch +, -, * und / und nicht etwa> Math.Add(), Math.Multiply(), Math.Subtract() und Math.Divide().
Naja, und wenn den Multiplikationsoperator irgendwann auf Vektoren und
Matritzen ausweiten möchte, wird es sehr schnell sehr hässlich.
Ich finde da infix-Funktionen irgendwie ganz nett, aber vermutlich führt
das auch zu ekligen Konsequenzen. :-(
Math schrieb:> könnt ihr mir helfen?
Ich würde da einfach mit Ganzzahlen arbeiten.
Drei Nachkommastellen -> multipliziere den Kram mit 1000.
Sechs Nachkommastellen -> multipliziere den Kram mit 1000000.
Das ganze in einen Ganzzahltyp wandeln (also Nachkommaanteil
abschneiden) und für die Ausgabe wieder zurückteilen. Intern wird nur
mit der Ganzzahl weitergearbeitet.
c-hater schrieb:> Du arbeitest offensichtlich mit deutschen Locales. Und in der deutschen> Kultur dient halt "." nicht als Dezimaltrenner. Sprich: gib einfach> "3,22" statt "3.22" ein ud alles ist schick.
Ja das hilft. Weiteres Problem: durch convert to string wird "," genutzt
und nicht ".". Das Messgerät will aber "."
Math schrieb:> Ja das hilft. Weiteres Problem: durch convert to string wird "," genutzt> und nicht ".". Das Messgerät will aber "."
liegt es daran, dass ich dezimal nutze? Ich muss es ja nutzen, um die
Rundung machen zu können
Math schrieb:> Ja das hilft. Weiteres Problem: durch convert to string wird "," genutzt> und nicht ".". Das Messgerät will aber "."
Wenn die deutschen Locales nicht für deine Anwendung passen, musst du
halt andere nehmen, die besser passen.
Da du die mehrfach benutzt, wäre es sinnvoll, die nur einmal für die
Klasse zu beschaffen. Geht ungefähr so:
private NumberFormatInfo nfi=new
Globalization.CultureInfo("en-US").NumberFormat;
Um dies verwenden zu können, mußt du von der Unsitte ablassen, für allen
Scheiß Convert zu verwenden. Statt dessen die lokalisierbaren
Typmethoden für die Konvertierung von/zu String verwenden. Deine Zeile
sieht dann ungefähr so aus (unter der Bedingung, dass du das von oben
getan hast, also die NumberFormatInfo in nfi zur Verfügung steht):
txtNSpannung.Text = Dezimal.Parse(txtSpannung.Text,
NumberStyles.AllowDecimalPoint, nfi).ToString("0.000", nfi);
Dann hast du Ein- und Ausgabe mit US-Locales.
Math schrieb:> hier wird ein String mit "," ausgegeben. Aber warum?
Konvertiert den Wert der angegebenen Dezimalzahl unter Verwendung der
angegebenen kulturspezifischen Formatierungsinformationen in die
entsprechende Zeichenfolgendarstellung.
Achtung, beim Parsen wird jetzt aber immer noch die lokale Kultur
(wahrscheinlich DE?) verwendet! Bei ToDecimal kann auch die invariante
Kultur angegeben werden.
Wenn es hässlich ist, einfach in mehrere Zeilen aufteilen und using
verwenden.
InvariantCulture schrieb:> Achtung, beim Parsen wird jetzt aber immer noch die lokale Kultur> (wahrscheinlich DE?) verwendet
hab ich geprüft, wird nicht.
c-hater schrieb:> Und übrigens: das "Math." an jeder einzelnen Stelle ist überflüssig. Man> muss halt einmal am Anfang der Datei Math "usen" und der Drops ist> gelutscht.
Dies bedarf wohl eins deiner fett unterlegten Worte.
Math.Pow ist eine statische Methode. Es gehört zum guten Umgang
zwischen C# Entwicklern den Namensraum explizit anzugeben. Das erhöht
die Lesbarkeit und reduziert "Verschmutzung" durch globale Importe von
namespaces. Kann man machen, muss man nicht...
Um zur Verwirrung beizutragen gibt es übrigens auch noch
Math schrieb:> Yalu X. schrieb:>> Aber wozu will man das, außer bei der Ausgabe?>> um ein Messgerät zu parametrisieren.
Und wie übergibst du die Zahl dem Messgerät? Doch sicher als String über
irgendeine Schnittstelle. Also rechnest du mit der gerundeten Zahl nicht
weiter, sondern möchtest sie nur ausgeben.
Um eine Zahl auszugeben, rundet man sie nicht numerisch, sondern
übergibt der Routine, die die Zahl in einen String konvertiert,
entsprechende Formatierungsparameter:
Jedzia D. schrieb:> Math.Pow ist eine statische Methode.
Ja klar.
> Es gehört zum guten Umgang> zwischen C# Entwicklern den Namensraum explizit anzugeben.
Nur ist Math halt keine Namensraum, sondern eben eine Klasse...
Und zwar eine so grundlegende (weil direkt im Namensraum System
gelegen), dass man in mathematiklastigen Klassen üblicherweise darauf
verzichtet, jedes einzelne Vorkommen von Methoden daraus voll zu
qualifizieren. Volle Qualifizierung würde übrigens auch bedeuten, dass
man jedesmal:
System.Math.irgendwas schreiben müßte.
Das ist Bullshit. Das macht kein Mensch. Außer dir vielleicht...
Huch @yalu.
Ich war einen Sekundenbruchteil schneller.
Wir sollten unbedingt noch alle 35 anderen Möglichkeiten(Hypothetische
Zahl, ist großzügig gerundet) dieses Problem zu lösen auflisten:)
Gilt dann: "Viele Köche verderben den Brei" ?
Yalu X. schrieb:> rundet man sie nicht numerisch, sondern> übergibt der Routine, die die Zahl in einen String konvertiert,> entsprechende Formatierungsparameter:
gibt es einen konkreten Vorteil?
Math schrieb:> wenn ich den Spieß umdrehe, d.h. ich bekomme einen String mit ".", dann> würde man es so machen? (vorausgesetzt, mehr als 3 nachkommastellen)
Einfach so, wie ich es vorgeschlagen habe. Offensichtlich der Einzige
der bisherigen Threadteilnehmer, der hier wirklich Ahnung vom
Dotnet-Framework hat.
Naja, ein Tippfehler wäre noch zu korrigieren, "Decimal" statt
"Dezimal".
Oder auch gleich Decimal durch double ersetzen, denn wie inzwischen
rausgearbeitet wurde, hast du ja garnicht vor, mit dem Wert weiter zu
rechnen (was ich sofort vermutet hatte), sondern willst ihn nur
ausgeben.
Double kennt alle von mir verwendeten Methoden-Overloads ebenfalls und
wird tun, was du willst.
Math schrieb:> c-hater schrieb:>> Double kennt alle von mir verwendeten Methoden-Overloads ebenfalls und>> wird tun, was du willst.>> math.round geht damit nicht
Brauchst du auch nicht. Das wird bei der Ausgabe durch den Formatstring
erledigt. Und es ist halt nur die Ausgabe relevant.
c-hater schrieb:> Math schrieb:>> math.round geht damit nicht
Das ist doch Bullshit. Math.Round geht sogar nur mit double. Brauchst
du aber hier garnicht. Das wird bei der Ausgabe durch den Formatstring
erledigt. Und es ist halt nur die Ausgabe relevant.
Du weißt nichtmal näherungsweise, was du eigentlich tust, richtig?
c-hater schrieb:> Das ist doch Bullshit. Math.Round geht sogar nur mit double.
Das sieht zumindest die Microsoft Doku anders. Scheinbar haben die auch
nicht so viel Ahnung von ihrem Framework wie du
c-hater schrieb:> Brauchst du auch nicht. Das wird bei der Ausgabe durch den Formatstring> erledigt. Und es ist halt nur die Ausgabe relevant.
verstanden. trzd kurz die Frage,warum hier das komme aus txt nicht zum
Punkt wird (nach der Zuweisung hat die Variable ein Komma)
GlobaleVariablen.Pulsbreite = string.Format(
txtPulsbreite.Text,CultureInfo.InvariantCulture);
Math schrieb:> trzd kurz die Frage,warum hier das komme aus txt nicht zum> Punkt wird (nach der Zuweisung hat die Variable ein Komma)> GlobaleVariablen.Pulsbreite = string.Format(> txtPulsbreite.Text,CultureInfo.InvariantCulture);
hat jemand eine Ahnung?
Math schrieb:> hat jemand eine Ahnung?
Ja, meine KI. Die ist inzwischen bei 99.99% Trollwahrscheinlichkeit
angekommen (d.h.: semantisch ist die echt TOP!). Ich selber mit meiner
einzig verfügbaren NI hänge noch bei ca. 99% rum, d.h.: es besteht noch
ein gewisser Restzweifel, es am Ende doch mit einem völligen Nixwisser
zu tun zu haben.
Wie auch immer: Tschüß, ich kann und werde nichts mehr für dich tun.
Egal ob Troll oder tatsächlich Vollidiot...
Math schrieb:> ich bin wirklich müde. sitze den Tag an verschiedenen Programmen. Mag> sein, dass die Frage nicht helle ist.
Wieder eine Dezimalstelle bei der KI-Bewertung genommen. Nunmehr 99.99%
pro Troll...
Felix U. schrieb:> Du musst uns mal nen größeren Screenshot von deinem Programm zeigen> damit wir wissen dass es echt ist
fällt schwer hier offen und ehrlich zu sein, wenn viele über einen
herziehen
Jedzia D. schrieb:> Was Du hier suchst ist CultureInfo.InstalledUICulture,> CultureInfo("en-GB") oder CultureInfo("de-DE"). Bei Ersterem, was die> Grundeinstellung ist kann es dazu kommen, dass bei einem amerikanischen> Nutzer dein Programm nicht funktioniert. Das Bedarf einer Prüfung und Du> solltest dich in das Thema einlesen und darüber nachdenken.
habe ich. Wenn ich den invariant Befehl nutze, dann mit dem Ziel
entweder von uS auf DE und andersherum. Messgerät benötigt US, meine
Anwendungssoftware arbeitet mit DE. Und deswegen gibt es die häufigen
Wechsel in meinem Code. Was auch soweit funktioniert bis auf die Zeile
GlobaleVariablen.Pulsbreite = string.Format(
txtPulsbreite.Text,CultureInfo.InvariantCulture);
ich glaube, dass die garnicht auf dem screen drauf ist. spielt aber auch
keine Rolle
Jedzia D. schrieb:> Um zur Verwirrung beizutragen gibt es übrigens auch> nochmessErgebnis.ToString("0.00"); //2 dezimalstellen>> messErgebnis.ToString("n2",> System.Globalization.CultureInfo.InvariantCulture); // 2 dezimalstellen,> kulturbezogene Trennzeichen
normalerweise hätte ich es so gemacht. aber dafür müsste ich jetzt eine
menge Code ändern
c-hater schrieb:> Du arbeitest offensichtlich mit deutschen Locales. Und in der deutschen> Kultur dient halt "." nicht als Dezimaltrenner. Sprich: gib einfach> "3,22" statt "3.22" ein ud alles ist schick.
In C# gibt es das "Culture"-Property/Methode -ich weis nicht mehr genau
ob's ein Property oder Methode war, bin aus dem Kram vor einem Jahr
ausgestiegen - , womit sich solche Dinge lösen lassen. Ich meine mich
noch dunkel zu erinnern das da "invariantCulture" oder so ähnlich weiter
hilft, bin mir aber nicht mehr sicher. Suche mal nach diesem Begriff.
Statt dem ganzen locale-Krampf würde ich vermutlich die Strings schlicht
selbst zusammenbauen... das Ausgabeformat ist schließlich bekannt.
Und, wie bereits erwähnt, intern mit Integern arbeiten.
Math schrieb:> GlobaleVariablen.Pulsbreite = string.Format(> txtPulsbreite.Text,CultureInfo.InvariantCulture);
danke für die Hinweise. Aber warum wird hier nicht von komma auf punkt
gewechselt?
Gegenvorschlag, @svenska:
Ich würde erst einmal verstehen wollen, was ich da eigentlich mache und
die 10 minuten zum Verständnis von
s.
https://docs.microsoft.com/de-de/dotnet/api/system.globalization.cultureinfo.invariantculture?view=netcore-3.1
aufbrigen, danach dann die richtige Methode wählen, wie z.B. "Invariant"
von Maschine zu Maschine oder zum Speichern und eine spezifische, bzw.
lokale Formatierungsmethode zum Anzeigen für den User.
Schwer ist das wirklich nicht.
Math schrieb:> Math schrieb:>> GlobaleVariablen.Pulsbreite = string.Format(>> txtPulsbreite.Text,CultureInfo.InvariantCulture);>> danke für die Hinweise. Aber warum wird hier nicht von komma auf punkt> gewechselt?
weil: "Die invariante Kultur ist Kultur unabhängig. Sie ist mit der
englischen Sprache verknüpft, aber nicht mit einem Land bzw. einer
Region."
...
Ist der ERSTE Satz:)
Math schrieb:> danke für die Hinweise. Aber warum wird hier nicht von komma auf punkt> gewechselt?
Laß' dir einfach mal die Bedeutung des Begriffes "invariant" in dein
Gehirn rieseln...
Übrigens etwas, was einige der bisherigen Threadteilnehmer ebenfalls
versäumt haben...
Ich möchte jetzt keine Namen nennen, aber jeder Interressierte kann das
natürlich dem Thread entnehmen. Jedenfalls solange yalu nicht seine
Connections spielen läßt. Da kann es schnell mal passieren, dass
objektive Wahrheit einfach mal wegzensiert wird... Weil sie yalu nicht
gefällt...
Math schrieb:> Math schrieb:>> GlobaleVariablen.Pulsbreite = string.Format(>> txtPulsbreite.Text,CultureInfo.InvariantCulture);>> danke für die Hinweise. Aber warum wird hier nicht von komma auf punkt> gewechselt?
Falls es hilft, hier verschiedene Ausgaben von meinem System für dich
zur Orientierungshilfe:
1
double val = 3.14159;
2
var result = val.ToString("n2", System.Globalization.CultureInfo.InvariantCulture);
3
result.Dump();
4
5
result = val.ToString("n2", System.Globalization.CultureInfo.CurrentUICulture);
6
result.Dump();
7
8
result = val.ToString("n2", new System.Globalization.CultureInfo("de-DE"));
9
result.Dump();
produziert (das Dump() ist hier die Ausgabe):
3.14 <- unabhängig der Kultur, immer gleiche Ausgabe
3.14 <- abhängig von den System-Einstellungen
3,14 <- Komma, Deutsch
OH EINE VERSCHWÖRUNG!!! Meine CurrentUICulture produziert auch einen
Punkt.
Nein, mein System ist auf Amerikanisch eingestellt, sollte bei Dir aber
wie das 3. Ergebnis aussehen.
Jedzia D. schrieb:> 3.14 <- unabhängig der Kultur, immer gleiche Ausgabe
aber das ist doch der Punkt. Jede Ausgabe müsste mit . erscheinen. Bei
mit mir Komma
GlobaleVariablen.Pulsbreite = string.Format(
txtPulsbreite.Text,CultureInfo.InvariantCulture);
Math schrieb:> Jedzia D. schrieb:>> 3.14 <- unabhängig der Kultur, immer gleiche Ausgabe>> aber das ist doch der Punkt. Jede Ausgabe müsste mit . erscheinen. Bei> mit mir Komma>> GlobaleVariablen.Pulsbreite = string.Format(> txtPulsbreite.Text,CultureInfo.InvariantCulture);
hat sich erledigt sry
Jedzia D. schrieb:> Gegenvorschlag, @svenska:> Ich würde erst einmal verstehen wollen, was ich da eigentlich mache
Gut, ich gebe zu, dass ich mich weder mit C# noch mit .net jemals
tiefgreifend beschäftigt habe.
Wenn ich merke, dass ich nicht mehr verstehe, was ich eigentlich tue
(z.B. weil ich die Runtime nicht verstehe) und mich aus irgendwelchen
Gründen nicht tief in das System einarbeiten kann oder will, dann baue
ich Trivialfälle eben von Hand nach.
Es geht nicht darum, dass "dann mach es selbst" hier der richtige Ansatz
ist, aber jeder Programmierer sollte in der Lage sein, einen korrekten
String notfalls zu Fuß bauen zu können. Schließlich bringt es nichts,
wenn man sich drei Tage mit der Runtime prügelt, nur um dann
möglicherweise festzustellen, dass die vorhandenen Funktionen nicht
mächtig(*) genug sind.
(*) In diesem Fall sind sie offensichtlich mächtig genug, aber das gilt
nicht für jedes Framework - und die Antwort ist auch auch nicht immer
offensichtlich. Fehlende Dokumentation ist genauso schädlich wie
schlecht geschriebene Dokumentation oder das eigene Unverständnis, die
Dokumentation zu verstehen.
Was hat das mit Potenzieren zu tun?
Gemäß
https://docs.microsoft.com/de-de/dotnet/api/system.convert.todecimal?view=netcore-3.1
meint die Fehlermeldung offenbar das zweite Argument der ToDecimal
Funktion. Aber in dem von dir zitierten Quelltext sehe ich nur ein
Argument. Die Fehlermeldung scheint sich auf einen anderen Quelltext zu
beziehen.
Zerlege das mal in drei einzelne Zeilen, dann wird die Fehlermeldung
vielleicht klarer, welcher Funktionsaufruf hier der problematische ist.
Stefan ⛄ F. schrieb:> Gemäß> https://docs.microsoft.com/de-de/dotnet/api/system.convert.todecimal?view=netcore-3.1> meint die Fehlermeldung offenbar das zweite Argument der ToDecimal> Funktion. Aber in dem von dir zitierten Quelltext sehe ich nur ein> Argument. Die Fehlermeldung scheint sich auf einen anderen Quelltext zu> beziehen.
ist eine Falsche Klammerstellung. Das Argument, in dem die
nacvhkommastellen angegeben werden, gehören zu math.round
Dimha B. schrieb:> ist eine Falsche Klammerstellung.
Ja, jetzt sehe ich es auch. Danke.
Das ",1" ist in der Fehlermeldung gemeint, und zwar für die Funktion
> ToString(Double, IFormatProvider)> Konvertiert den Wert der angegebenen Gleitkommazahl mit doppelter> Genauigkeit in die entsprechende Zeichenfolgendarstellung.
1 ist kein IFormatProvider.
Du wolltest wohl eher die Funktion
> ToString(Double, IFormatProvider)
verwenden und die ",1" als Argument zu Math.Round() verwenden. Also
gehört das ",1" eine Klammer weiter nach links.
Thread beobachten
Seitenaufteilung abschalten