KEINE Freigabe der macOS Version Sequoia für tomedo®
Alle Hinweise und Informationen finden Sie unter folgendem Link.

Bei einer simplen Division von zwei Variablen in einem CKE stoße ich an meine CKE-Grenzen:

Ich möchte ganz einfach den Quotienten aus der Variablen ZentraleApnoen und AnzahlApnoen berechnen. In meinem Beispielfall sollte bei der Berechnung 4 / 10 = 0.4  herauskommen. Es wird aber 0,0 berechnet. Wenn ich testweise das "/" durch ein "+" ersetze, kommt 14 heraus.

Wo liegt mein Denkfehler?

 

Gefragt in Frage von (5.6k Punkte)
0 Punkte

4 Antworten

Moin Hans Jörg

versuch es mal mit Score nicht editierbar v2 und folgender Vorbefüllung: 0$[ZentraleApnoen]$/0$[AnzahlApnoen]$ 

Für die Divison ist "/" richtig, für die Addition "+"

Ich habe im Tauschcenter ein CKE für alle arithmetischen Funktionen reingestellt. 

Hier der Auszug für die Division aus v1 und v2. Die Felder v1 und v2 habe ich mit 4 Dezimalstellen gewählt, das Ergebnisfeld hat 2 Dezimalstellen. Die "0" vor dem Kommando verhindert, dass bei leeren Feldern eine Fehlermeldung kommt.

Ich benötige diese Funktionen zur Berechnung von Messergebnissen in meinen CKE.

Die absolute Krönung wäre, es den ESC SCORE2/SCORE2-OP nachzubilden.

https://www.msdmanuals.com/medical-calculators/ACCAHA2013-de.htm

Mit der Formel bin ich bisher leider nicht weiter gekommen.

 

Begriffe = (CAlter * ln(Alter)) + (CSqAlter * sq(ln(Alter))) + (CTotalChol * ln(Gesamtcholesterin)) + (CAlterTotalChol * ln(Alter) * ln(Gesamtcholesterin)) + (CHDLChol * ln(HDL-Cholesterin)) + (CAlterHDLChol * ln(Alter) * ln(HDL-Cholesterin)) + (Antihypertonika-Therapie * CAntihypertonika-Therapies * ln(Systolischer Blutdruck)) + (Antihypertonika-Therapie * CAlterAntihypertonika-Therapies * ln(Alter) * ln(Systolischer Blutdruck)) + (!Antihypertonika-Therapie * COffHypertensionMeds * ln(Systolischer Blutdruck)) + (!Antihypertonika-Therapie * CAlterOffHypertensionMeds * ln(Alter) * ln(Systolischer Blutdruck)) + (CRaucher * Raucher) + (CAlterRaucher * ln(Alter) * Raucher) + (CDiabetes * Diabetes)


Vielleicht findet unser Schwarmwissen da die Lösung.
 

Beantwortet von (35.2k Punkte)
Bearbeitet von
0 Punkte

Moin, Christian,

Deinen Arithmetik-CKE hatte ich als Inspiration schon ausprobiert. Leider funktioniert es mit der Vorbefüllung: 0$[ZentraleApnoen]$/0$[AnzahlApnoen]$ und der Score-Variante 2 auch nicht. Alle Rechenoptionen ergeben das korrekte Ergebnis (Addition/Subtraktion/Multiplikation), nur die Division führt zum falschen Ergebnis. Ändern der Nachkommastellen bleibt auch ohne Effekt. Grrrr.

siehe Antwort unten von Herrn Thierfelder
Sehr geehrter Herr Baumann

4/10 ist für den Computer eine Ganzzahl Division ist also 0 rest 4 ... Wenn Sie eine Gleitkomma Division haben wollen so müssen Sie das genau angeben, also 4./10. wo dann 0,4 herauskommt. Das kann man erreichen indem man in der gesamten berechnung noch eine Gleitkommazahl hinzufügt. zb (1.0*4)/(1.0*10)
Beantwortet von (89.6k Punkte)
+1 Punkt
In meinem Beispiel habe ich für die Zahlenwerte x und y 4 Nachkommastellen genommen, es funktioniert aber auch, wenn man nur ganze Zahlen, ohne nachkommastellen verwendet und im Scorefeld entsprechend Nachkommastellen einstellt.
sie müssen die Zahlen ZentraleApnoen und und AnzahlApnoen auch auf eine Nachkommastelle einstellen, dann funktioniert es
Beantwortet von (27.5k Punkte)
0 Punkte
Super! Innerhalb von 14 Stunden wurde mein Rätsel gelöst. Vielen Dank an alle Beitragenden (ChatGPT hätte es nicht schneller und vor allem nicht besser hinbekommen...):

Die Lösung für mein Problem lautet nun also:

(1.0*$[ZentraleApnoen]$)/(1.0*$[AnzahlApnoen]$)

So klappt es. Das Setzen der Nachkommastellen allein hatte nicht ausgereicht.
Beantwortet von (5.6k Punkte)
0 Punkte
die Lösung funktioniert gut, hat aber den Nachteil, dass der Score "unlogisch oder nicht definiert" ist, wenn der Teiler 0 ist. Sowas finde ich immer ein wenig unschön.

Wenn Sie bei den Zahlenwerten ZentraleApnoen und und AnzahlApnoen auch auf eine Nachkommastelle einstellen, funktioniert die Rechnung und mit der Syntax 0$[ZentraleApnoen]$/0$[AnzahlApnoen]$ kann auch kein unlogischer Score beim Teilen durch 0 rauskommen.

Hallo Herr Tenzer,

das Problem mit der Teilung durch 0 leuchtet mir ein, kann ja durchaus auch vorkommen. Leider funktioniert die Variante 0$[ZentraleApnoen]$/0$[AnzahlApnoen]$ auch mit der Einstellung Nachkommastelle 1 für die beteiligten Variablen nicht. Habe ich da was übersehen?

in Ihrem Beispiel haben die "Anzahl Apnoen" und "Davon Zentral" keine Nachkommastelle.

Sonst würde da 10.0 und 4.0 stehen und nicht 10 und 4.
Ach so, ich dachte es liegt an der Einstellung "Konfiguration". Jetzt ergibt sich für mich das Problem, dass die Zahlen 10 und 4 per regex aus einer GDT-Tabelle entnommen werden und daher keine Nachkommastelle "mitgeliefert" bekommen. Gibt es einen Weg, automatisiert aus einem Integer einen Float / Nachkommastelle zu machen?
Vielen Dank, Herr Tenzer, für den Tip:

Umwandlung einer Zahl (Integer) in Nachkommastelle durch einfache Übernahme in eine zweite Variable Typ Score v2 mit einer Nachkommastelle. So klappte es dann doch.

Ganz tricky, so eine simple Division.
Herr Thierfelder hat die Erklärung geliefert, weshalb es ohne Dezimalstellen nicht immer korrekt funktioniert. In meinem Beispiel indem CKE im Tauschcenter funktioniert es, weil ich 4 Nachkommastellen eingestellt habe, aber auch in meiner Antwort darauf aufmerksam gemacht.
Es stimmt, die Division funktioniert so, wie Du es in Deinem Arithmetik-CKE (sehr hilfreich übrigens!) dargestellt hast. Ich hatte dort auch geschaut und es mir nachgebaut.

Das Problem ergab sich in meinem speziellen Fall aus dem Umstand, dass die für die Division verwendeten CKE-Felder (mit Konfiguration 2 Nachkommastellen) beim automatischen Befüllen über regex die übertragene Zahl 10 nicht in 10.00 umgewandeln. Es wird dort (wie gesagt trotz Konfiguration 2 Nachkommastellen) die Zahl 10 angezeigt. Wenn man in ein CKE-Feld mit Konfiguration 2 Nachkommastellen manuell "10" eintippt, wird ja "10,00" gespeichert. Beim automatischen Befüllen scheint die Umwandlung aber nicht zu erfolgen. Man könnte dieses Verhalten als Bug bezeichnen, da sich das Feld ja nicht so verhält wie konfiguriert. Vielleicht kann Zollsoft hier nachfeilen, wenn einmal Zeit ist...
Böse Falle.

Wenn man das weiß, hilft vielleicht die nochmalige Übernahme in einzweites Zahlenfeld mit Dezimalstellen, oder eben die Multiplikation mit 1.0
Genau so habe ich es jetzt gemacht. Zwischenschritt einer Variable mit Nachkommastelle und dann Vorbefüllung. Elegant ist was anderes, aber am Ende klappt es so.
17,842 Beiträge
26,010 Antworten
46,516 Kommentare
23,395 Nutzer