TIA Array ohne festen Datentyp

[M0077227]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich bin gerade dabei einen Standard Speicherbaustein zu entwickeln.

Dieser soll beliebige Messwerte (alle möglichen Datentypen sollen erlaubt sein) nehmen in ein Array speichern und aus diesem soll dann noch der Mittelwert und der Median berechnet werden.
Dabei bin ich auf folgendes Problem gestoßen und zwar:
Mir ist es zwar möglich einen beliebigen Datentyp am Eingang anzulegen indem ich den Input als Variant definiere, jedoch habe ich keine Möglichkeit gefunden ein Array vom Datentyp Variant anzulegen um beliebige Datentypen abzuspeichern.

Momentan habe ich es so gelöst, das ich alle Werte einfach in einen String kopiere jedoch ist hier das Problem das ich mit den Werten nicht rechnen bzw. zur Median Bildung auch nicht sortieren kann.

Ich hoffe ich habe das so ca Verständlich formuliert und hoffe jemand von euch kann mir helfen

 

[vollmi]

Da musst du immer Abstriche machen. Du könntest das Array mit einem Rechentafeln Datentypen aufbauen mit möglichst wenig Verlust. Z.b LInt. Und dann den variant Datentypen entsprechend wandeln.
Bei den Wandlungen kann es halt zu genauigkeitsverlusten kommen.


Gesendet von eyePhone

 

[RedCali]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schau die mal in der LGF Bibliothek den Baustein FIFO / LIFO an - dort wird ein Variant verwendet und auch ein Array
Ein "Array of Variant" geht so nicht, das muss man von außen als variant übergeben und dann innen auf Array und Typ prüfen
So könnte man den Baustein generisch aufbauen - die frage ist natürlich ob das auch sinn macht, da ja bereits zum Engineering Zeitpunkt der Datentyp feststeht im Normalfall.

Ist es nicht sinnvoller den Baustein für die unterschiedlichen Datentypen vorzuhalten?
Dazu müsste man einen Baustein für einen Datentyp entwickeln und dann entsprechend kopieren und die Datentypen in der Schnittstelle anpassen.

 

[maxder2te]

Da musst du immer Abstriche machen. Du könntest das Array mit einem Rechentafeln Datentypen aufbauen mit möglichst wenig Verlust. Z.b LInt. Und dann den variant Datentypen entsprechend wandeln.
Bei den Wandlungen kann es halt zu genauigkeitsverlusten kommen.

Gesendet von eyePhone

Der Ansatz ist prinzipiell nicht so schlecht, es geht aber auch verlustfrei.
Du kannst den Rohdatenspeicher beispielsweise als ARRAY[a..b] OF LWORD deklarieren. Je nach beschaltetem Datentyp wandelst du deinen Eingang dann auf LWORD um und umgekehrt.

Der Unterschied zu LINT ist, dass bei der Umwandlung LREAL_TO_LINT eine Rundung stattfindet, bei LREAL_TO_LWORD und umgekehrt hingegen nur ein Bitmuster kopiert wird.

Theoretisch ist natürlich auch denkbar, dass man den Speicher anschließend effizienter ausnutzt, indem z.B. bei einem REAL-Puffer sowohl Low-DWORD als auch High-DWORD als Speicher ausgenutzt werden usw. Für einen Bibliotheks-FB ist das schon mal denkbar - für eine spezifische Anwendung wäre mir der Aufwand zuviel.

 

[Howard]

Moin,

Der Ansatz ist prinzipiell nicht so schlecht, es geht aber auch verlustfrei.
Du kannst den Rohdatenspeicher beispielsweise als ARRAY[a..b] OF LWORD deklarieren. Je nach beschaltetem Datentyp wandelst du deinen Eingang dann auf LWORD um und umgekehrt.

Der Unterschied zu LINT ist, dass bei der Umwandlung LREAL_TO_LINT eine Rundung stattfindet, bei LREAL_TO_LWORD und umgekehrt hingegen nur ein Bitmuster kopiert wird.

Theoretisch ist natürlich auch denkbar, dass man den Speicher anschließend effizienter ausnutzt, indem z.B. bei einem REAL-Puffer sowohl Low-DWORD als auch High-DWORD als Speicher ausgenutzt werden usw. Für einen Bibliotheks-FB ist das schon mal denkbar - für eine spezifische Anwendung wäre mir der Aufwand zuviel.

Ich finde die Idee auch ganz cool - nur Rechnen und Median ist dann wieder nicht (außer man wandelt dann wieder jeden Wert zurück usw...). Wenn das gespeicherte also irgendwie mathematisch auswertbar gehalten werden soll, dann würde ich wie vollmi zum LInt greifen.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn das gespeicherte also irgendwie mathematisch auswertbar gehalten werden soll, dann würde ich wie vollmi zum LInt greifen.

Ich sehe keinen Widerspruch zwischen mathematischer Auswertbarkeit und Lword-Speicherung. Die Datentyp-Prüfung des Variant muss ohnehin gemacht werden - das Case beim Herauslesen ist also ein überschaubarer Aufwand.
Wenn der TIA Compiler auch nur einigermaßen intelligent ist, fallen sogar die Typecasts weg und die Geschichte wird effizienter - SCL vorausgesetzt (und ehrlich: sowas in einer anderen Sprache schreiben macht wohl kaum Sinn).

 

[Howard]

Ja klar, ohne SCL wird es wohl knifflig.
Und natürlich klappt das WORD-basierte speichern und auch ein nachträgliches bearbeiten. Man kauft sich dadurch halt ein zusätzliches casten ein, beim Eintragen, Austragen und Auswerten. Das währe mir persönlich zuviel Performanceverlust für ein bisschen Datenhandling.

 

[maxder2te]

Ja klar, ohne SCL wird es wohl knifflig.
Und natürlich klappt das WORD-basierte speichern und auch ein nachträgliches bearbeiten. Man kauft sich dadurch halt ein zusätzliches casten ein, beim Eintragen, Austragen und Auswerten. Das währe mir persönlich zuviel Performanceverlust für ein bisschen Datenhandling.

Die Aufgabe war ja Universalität, was auch Gleitkommaoperanden (REAL, LREAL) beinhaltet. Du schließt diesen Fall aus deiner Betrachtung aus.
Schließt du diesen Fall mit ein und bist der Meinung, dass LINT_TO_LWORD oder DINT_TO_DWORD mehr Performance benötigen als REAL_TO_LINT usw. dann kann ich deine Ansicht nachvollziehen.