Variablen mit Nachkommastellen

[Quadro]

Hi Leute,

ich wollte mal fragen ob jemand weis wie man Variablen erstellt, die auch Nachkommastellen haben (z.B. 3,76). Ich weiss dass man bei den Variablen auch auf Gleitkomma umstellen kann. Dann gibt es auber immer wieder Fehler und es funktioniert nicht richtig! Gibt es da noch ne andere Lösung oder muss ich es mit dem Gleitkomma machen?

Gruss,
Quadro

[Dirk Fox]

Hallo Quadro,

wenn Du nur zwei Nachkommastellen benötigst, kannst Du die ganzzahligen Werte zuvor mit 100 multiplizieren und das Ergebnis wieder durch 100 teilen. Das klappt, wenn Du nur mit Zahlen zwischen -327,67 und 327,67 rechnen musst.

Beste Grüße,
Dirk

[Dirk Fox]

Hallo Ford,

wie kann es sein, dass hier Fehler passieren? Was für Fehler?

Ok, die ausführliche Version:

Gleitkommadarstellungen von Zahlen sind immer nur eine Näherung an den exakten Wert über die e-Funktion; daher lassen sich nicht alle Werte hinreichend exakt darstellen (siehe z.B. https://de.wikipedia.org/wiki/Gleitkommazahl). Und Fehler können sich aufsummieren. Abhängig von den konkreten Rechenoperationen kann es daher sein, dass die Verwendung von Gleitkommaarithmetik Fehler liefert.

Natürlich kann man den maximalen Fehler ausrechnen oder abschätzen. Benötigt man nur wenige Nachkommastellen, ist es allerdings manchmal geschickter, mit zwei zusätzlichen Stellen vor dem Komma zu rechnen - das geht zudem erheblich schneller als die Fließkomma-Arithmetik.

Beste Grüße,
Dirk

[vleeuwen]

Knowledge of Numerical analysis is an important basic for a better understanding of these end figure problems.
The organization of the calculation has a narrow relation with the rounding error (accuracy of the calculation).

[jona2004]

Hallo Dirk,
So ganz richtig ist nicht was Du sagts, die Werte werden eigentlich bei üblichen Gleitkommazahlen nicht über die e-funktion bestimmt, sondern um exponente zur basis 2.
Das am meisten verbreitete Gleitkommazahlenformat ist das IEEE 754 format und besteht aus dem vorzeichenbit, der mantisse und dem exponenten zur basis 2.
Die mantisse ist dabei als Zahl zwischen [1 -- 2) (also 1.999999) interpretiert. Das IEEE754 verwendet am häufigsten ein 32bit oder ein 64 bit format. dabei ist beim 64-bit sowohl der Dynamikbereich als auch die Genauigkeit höher als bei 32-bit
Robopro verwendete ein 48bit Format, über die genaue Aufteilung in vorzeichen, exponent, mantisse habe ich auf die Schnelle nichts gefunden. Ich vermute es wird eine 32bit vorzeichenbehaftete mantisse und einen 16-bit exponent haben.
Damit sollte man schneller rechnen als mit dem IEEE 754 format, das doch einige Fallen aufweist und ziemlich viele Bitmanipulationen benötigt.
Wie richtig gesagt gibt es immer Rundungsfehler, deshalb sollte man Gleitzahlen eigentlich nie auf Gleichheit vergleichen. (dazu gibt es auch einen Hinweis im Roboprohandbuch).
Daneben ist es auch üblich und recht einfach mit fraktionalen Zahlen z.B. vom [-1 +1) zu rechnen, die es erlauben zu größten Teil die normale integerarithmetik zu verwenden und dementsprechend schnelles Rechnen erlauben.
Allerdings muss man hier sehr (ähnlich wie bei Deinem ersten Beispiel auch) auf den Zahlenbereich aufpassen.
Das ist eigentlich der Hauptvorteil der Gleitkommazahlendarstellung, dass man sich zum Dynamikbreiche keine Gedanken machen muss, da der i.a. für diese Art Anwendungen mehr als ausreichend ist.

PS: Wenn jemand das 48-bit format kennt, würde mich das schon interessieren

Grüße Joachim

[Dirk Fox]

Hallo Joachim,

So ganz richtig ist nicht was Du sagts, die Werte werden eigentlich bei üblichen Gleitkommazahlen nicht über die e-funktion bestimmt, sondern um exponente zur basis 2.

Du hast Recht - danke für die Korrektur. Jedoch gilt für alle Darstellungen unabhängig von der Basis, dass die Werte nur genähert und nicht exakt sind. Da die Darstellung in der Regel als Dezimalzahl erfolgt, kann es zu "überraschenden" Abweichungen kommen, wenn die Rechenbasis der Fließkommaarithmetik eine andere ist als 10.

Robopro verwendete ein 48bit Format, über die genaue Aufteilung in vorzeichen, exponent, mantisse habe ich auf die Schnelle nichts gefunden.

Die Mantisse hat in RoboPro 32 Bit. Die Genauigkeit wird mit "9 Dezimalstellen" angegeben - das kann sich aber über Fehlersummen schnell reduzieren (gefunden in der Online-Hilfe, Kapitel 12).

Beste Grüße,
Dirk

[UMueller]

Hallo,
mir scheint in RoboPro wurde da ein wenig (mehr) gepfuscht :
die arithmetischen Befehle kommen wohl nicht mit dem Gleitkomma zurecht.
Abhilfe :
die Operatoren + - * / in Zusammenhang mit dem Befehl = verwenden. Siehe auch Hilfe 12. Dezimalzahlen das mit den Operatoren ist wohl wörtlich gemeint.
Alle (einschl. der Variablen) in Gleitkommaeinstellung und mit Punkt als Dezimaltrennzeichen.

Gruß Ulrich Müller

[thkais]

Hallo,

@UMueller: Ich kann das nicht ganz nachvollziehen - ich habe Variablenzuweisungen und Rechenoperationen mit Fließkomma ohne den "=" Befehl hinbekommen, sogar ausschließlich mit orangen Datenfluss-Verbindungen. Hast Du da ein konkretes Beispiel, bei dem es nicht funktioniert?

[UMueller]

Hallo tkais,

Beispiel Grünes Männchen - Konstante +1.1 - Befehl + - Var 0 - Rotes Männchen
Alles Gleitkomma, Meldung :
Kein angeschlossener Eingang kann den Befehl + verarbeiten
Verbindung + und Var 0 ist rot
rein mit gelben Elementen gehts, ist dann natürlich nicht mehr steuerbar.
Operator + auf Befehl = geht auch, nicht aber Befehl +


Getestet mit v2.1.4.1 und v3.2.4


Gruß Ulrich Müller

[jona2004]

Hallo Ulrich, Thkais,
Die Aussagen von Ulrich sind nachvollziehbar, ich habe bisher allerdings wie Thkais Gleitkommazahlen auch nur per Datenfluss verarbeitet. d Es scheint tatsächlich nur der = Befehl zu klappen. Das ist aber m.E. zu verkraften, da man per Datenflussoperatoren das gleiche Ergebnis mit etwas mehr Zeichenaufwand hinkriegt.
Um nochmal auf das Ausgangsthema zurückzukommen:
Gleitkommazahlen im Binärsystem haben kleine Feinheiten. Z.B kann die Zahl 0,1 im üblichen Binärsystemen nur per unendlicher Reihe also nie ganz genau dargestellt werden. Das sieht dann in etwa so aus. DIe erste Stelle von rechts nach dem gedachten Binärpunkt hat das Gewicht 1/2 die nächste 1/4, 1/8 usw.
die 0.1 ist dann 000110011001100 ...
Das hat denn u.A zur Folge, dass Vergleiche auf '=' i.a. daneben gehen.
Grüße Joachim

[jona2004]

Hallo Ford,
Zur Info 48-bit ist auch Gleitkomma.
Wer sagt denn, dass hier nicht so genau wie moeglich gerechnet wird? Wenn das Format bekannt ware koennte man da mal nachrechnen, aber so steht fuer mich nur die Vermutung (Robopro Hilfe spricht von etwa 10^-9 Genauigkeit) im Raum dass mit einer mindestens 32-bit langen mantisse (vorzeichen plus 31 Stellen) gearbeitet wird. Die anderen 16-bit koennte den (allerdings dann sehr grossen) 15bit exponenten plus vorzeichen beinhalten.

Grüsse Joachim

[jona2004]

Hallo Ford,
Es ist kein Problem Zaehlschleifen etc. mit Gleitkommaoperatoren in Robopro zu machen.
Auch die sqrt funktion gibt es-
Das Problem von Ulrich ist, dass erwartet wurde der Befehl + (in der Hilfe 8.5.2) könnte Gleitkommazahlen verarbeiten, was wohl nicht der Fall ist.
Persönlich verwende ist den + oder - Befehl recht selten und arbeite lieber via Datenfluss (organge Pfeile) als mit dem Kontrollfluss (blaue), weil man dann Daten und Kontroller sauberer auseinanderhalten kann. Dann brauche ich nur den Zuweisungsbefehl (=) und der funktioniert.
Also kurzgefasst, Dein Programm kann man mit Robopro nachbilden.

Ob man lieber textbasiert programmiert oder per Ablaufdiagramm steht auf einem anderen Blatt, aber C++ ist schon hart für Kinder iund darum geht es.

PS: Hast Du mal Deinen Code durch einen Linter laufen lassen? Das könnte spannend werden.

Grüße Joachim

[jona2004]

Hallo Ford,
ganz OOT - LINT is ein Werkzeug zur statischen Codeanalyse, und meldet potentiell gefährlich Konstruktionen, fehlende type casts etc.
Grüße Joachim

[vleeuwen]

Funny discussion, can someone produce an overview and summery?

What options are offered by the TX-C (ARM processor) for hardware floating point arithmetic?
Software emulation of floating point arithmetic is time consuming in embedded C applications.

[jona2004]

Hallo,
Der Thread ist wie vleeuwen sagt etwas in 2 Hauptthemen zerfallen, deshalb hier wie gewünscht eine Zusammenfassung.
A) von Quadro gestartet: Die Behauptung, dass es bei Umsetzung von Festkomma auf Gleitkomma immer wieder zu Fehlern kommt. Allerdings hat Quadro keinen Test, an dem man das nachprüfen kann, geschickt. Daraus ergab sich eine Diskussion, dass es generell schwierig ist "genau" mit Gleitkommazahlen zurechnen.

B) von UMueller gestartet: Die Aussage, dass der Befehl '+' keine Gleitkommazahlen verarbeitet ist richtig (Um ganz klar zu sein Befehl level 3 Hilfekapitel 8.5). Nach meinen Experimenten geht nur der Zuweisungsbefehl '=', was aber m.E. absolut ausreichend ist, wenn man sowieso Daten- und Kontrollfluss trennt indem man mit Operatoren (Hilfe Kapitel 8.8) arbeitet.

Um noch abschliessend vleeuwen's neue frage zubeantworten:
Solange nicht die exakte Bezeichung des Microcontrollers bekannt ist, kann man nicht mit 100% Sicherheit sagen of der A8 eine floatingpoint hardwareunit hat, aber es ist bei diesen grossen Controllern sehr wahrscheinlich. Beim M3 gibt es keine fängt erst bei Cortex M4 an.
Allerdings ist floatingpoint in software auch nicht extrem schlecht.

Hello,
The Thread is, as vleeuwen says, split into two topics, so here a short summary as requested.
A) Started by Quadro: It is claimed here that the conversion from integer to floating point data has errors and that the handling of floating point has bugs in general. Unfortunately, Quadro has not posted a testcase to try this out. Out of this there was a discussion started how "accurate" you can calculate using floatingpoint at all.

B) Started by UMUeller: The claim that the command '+' can not handle floatingpoint numbers is true. (To be clear it is about the commands as per help chapter 8.5). According to my experiments only the command '=', can handle floating point. IMHO it is sufficient, if you split Command- and Dataflow anyway using the Operators (Chapter 8.8).

To answer the new question from vleeuwen:
As long as not the exact type number is known, one cannot be 100% sure if the ARM8 offers floating point hardware, but typically those high powered machines offer it. The Coprocessor Cortex M3 does not have a floatingpointunit it starts from M4. But floating point is software is not too bad either.


Grüße / regards Joachim

[schnaggels]

@jona2004
Im TXC ist ein ARM 9 processor (32bit 200 MHz), genauer ein AT91SAM9260.
http://www.atmel.com/devices/SAM9260.aspx

FPU: No

(wenn ich das richtig gesehen habe...)

Gruß,
Thomas

[vleeuwen]

Thanks,
hereby some links (back ground info) about floating point and precision:

http://infocenter.arm.com/help/index.js ... eagah.html
http://en.wikipedia.org/wiki/48-bit
http://en.wikipedia.org/wiki/Single-pre ... int_format
http://en.wikipedia.org/wiki/IEEE_floating_point
http://ijetecs.com/wp-content/uploads/2 ... uchita.pdf

http://www.cs.mcgill.ca/~cs573/fall2002 ... /index.htm
See 3.2 note 1

Robopro
The precision of arithmetic operations is 48 bits with a 32 bit mantissa.
This corresponds to a precision of slightly more than 9 decimal digits.

[jona2004]

Hallo Thomas (schnaggels),
Die Frage bzgl. Floatingpointhardware von vleeuwen und meine Antwort bezogen ich auf den neuen TX-C. Im Unterforum "Kontakt mit fischertechnik" wurde da als Core ein "TXT: ARM Cortex A8 (32bit 500 MHz) + Cortex M3 / 128 MB DDR3 RAM, 64 MB flash", erwähnt. Ob der floating pointunterstützung hat ist eben noch unklar m.E höchstwahrscheinlich. Sicherlich wird nicht das aktuelle 48-bit RoboPro Format unterstützt.
Und damit wir noch was spekulieren können (Macht ja auch Spaß), Atmel hat auf ihrer Website keinen ARM A8 im Angebot. Aber TI und Freescale haben in der Gewichtsklasse etwas.

Das 48bit format mit 32 bit vorzeichenbehafteter Mantisse und evtl. 16bit exponent ist in software auf einem 32-bit Rechner deutlich einfacher zuverarbeiten als das IEEE format. Allerdings spannen 16bit Exponent einen unnötig grossen dynamic Bereich auf (64-bit double IEEE754 hat nur 11bit). In Hardware balanciert man dann Mantisse (Genauigkeit) und Exponent (Dynamikbereich) besser aus.

Grüße Joachim

[hamlet]

Hallo,
Bislang unterstützt RoboPro lediglich 48bit floats und 16bit signed integers ... Auch der TX-ARM9 ist ein 32-Bit Prozessor, was durchaus vom ft-Marketing betont wurde. Trotzdem beschränkt sich RoboPro auf 16bit integer. Naja, und String-Konstanten gibt es auch noch. Die Operatoren haben sogar eine optionale Überlauferkennung. Vermutlich haben die ft-Entwickler dafür eine plattformunabhänge SW-Implementation. Das ganze läuft ja sowohl im Online- (PC) als auf im Offline-Mode (TX/ARM9).
Wahrscheinlich ist es am einfachsten, dies beizubehalten, nicht zuletzt aus Kompatibilitäts-Gründen zu existierenden RoboPro-Programmen. Zudem könnte eine Änderung der Variable-Typen in ein aufwändiges Unterfangen in den Tiefen von RoboPro mit großem Testaufwand ausarten. Wahrscheinlich müssten auch die Operatoren, Listen und die Ausgabefunktionen anpasst werden. Die Dokumentation natürlich auch.
Ich bin gespannt.
Beste Grüße,
Helmut

[schnaggels]

Hallo Joachim,

mir ist der Sinn der ganzen Diskussion nicht klar.

Der ROBOPro Entwickler war so nett die von ft nicht geforderte Unterstützung für Floatingpoint in RoboPro einzubauen. Um den Aufwand zu begrenzen, geht das eben korrekt nur über die "=" Operatoren. Wo ist denn das Problem?

Welche Sprache und Möglichkeiten man später auf dem TXT unter Linux benutzen will ist ja jedem selbst überlassen oder?

Gruß,
Thomas