Discussion:
Typen für Messgrößen (Was: Immer wieder Software-Fehler: Schiaparelli u.a.)
(zu alt für eine Antwort)
Peter J. Holzer
2017-02-01 15:42:09 UTC
Permalink
Das ist aber wichtig. »s = a/2 * t * t« ist nicht nur weniger zu tippen
als »s = mul__m_per_s2__s2(div__m_per_s2__unit(a, 2), sq__s(t))«,
sondern auch deutlich lesbarer.
Für verschiedenste Dinge aus dem Problembereich werden
getypte Objekte nahe gelegt. Augenscheinlich nicht für
naturwissenschaftlich oder e-technisch "informierte" Formeln
in traditionellen Sprachen.
Warum sträuben sich fast alle Sprachentwickler, so etwas wie
Zahlen ausdrücklich für Repräsentationen vorzusehen und
Programmierern nahe zu legen, für Meter usw, nur Typen,
nicht aber den Typ verwischende Repräsentation zu verwenden?
Du hast offenbar das Thema der letzten paar Postings in diesem Thread
nicht ganz mitbekommen: Genau darum ging es.

Mit den Typdeklarationen

meter s;
meter_per_second2 a;
second t;

und geeignetem Operator-Overloading kann ein C++-Compiler zur
Compilezeit feststellen, dass die Einheiten zusammenpassen.

Wäre s dagegen als feet deklariert, würde es einen Typfehler geben, weil
die rechte Seite den Typ meter hat und meter und feet nicht
zuweisungskompatibel sind.

In C geht das nicht (jedenfalls nicht so elegant, wenn auch
möglicherweise etwas eleganter als ich oben skizziert habe).
'A' == 65
[...]
Dass diese Gleichung im Ausdrucksvorrat der Programmierer
weiter Bestand hat, statt für illegal erklärt und vom
compiler-Hersteller mit eineindeutiger, persistenter
Programmtransformation beseitigt zu werden, ist irgendwie
entlarvend.
C ist C. Es gibt genügend andere Sprachen, wo diese Gleichung nicht
gilt. Du kannst ja eine andere Programmiersprache verwenden (ich mache
das auch - meistens).

In C kann diese Gleichung nicht vom Compiler-Hersteller für illegal
erklärt werden, weil der Sprachstandard das vorschreibt (bei einem auf
ASCII aufbauendem runtime character set). Der Sprachstandard wiederum
wird das kaum ändern: "Existing code matters" stand schon in den
Richtlinien zum ersten C-Standard 1989, und mittlerweile gibt es noch
viel mehr Code, den man nicht mutwillig kaputtmachen möchte.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-02-01 20:31:32 UTC
Permalink
Post by Peter J. Holzer
Warum sträuben sich fast alle Sprachentwickler, so etwas wie
Zahlen ausdrücklich für Repräsentationen vorzusehen und
Programmierern nahe zu legen, für Meter usw, nur Typen,
nicht aber den Typ verwischende Repräsentation zu verwenden?
Du hast offenbar das Thema der letzten paar Postings in diesem Thread
nicht ganz mitbekommen: Genau darum ging es.
Dass die Sprachentwickler sich sträuben, Einheitensysteme
im Typsystem anzubieten, stimmt sehr wohl, das galt auch für C++,
s.u.
Swift, Rust, Scala, sonstwas hat immer irgend ein Oktett,
Dezisextett usf., die als Zahltypen dienen und in Programmen
dienen dürfen, ohne dass ein Standardnormal-Programmierer
von ihrer Verwendung für die Objekte des "Problembereichs"
absähe.

Für META-C++,
Post by Peter J. Holzer
Mit den Typdeklarationen
meter s;
meter_per_second2 a;
second t;
und geeignetem Operator-Overloading kann ein C++-Compiler zur
Compilezeit feststellen, dass die Einheiten zusammenpassen.
ist genau das der Denkfehler mit Bezug auf das Definieren
von Sprachen: Zufällig hat sich das template-System von C++
als eigene Metaprogrammiersprache ergeben. Es war
eben nicht geplant. Deswegen ist ein in META-C++ konstruierter
Typ auch keine einfache, direkte Folge der Sprachdefinition.
Sondern eine hochkomplexe, indirekte. Und von einer Bauart,
dass es einiger besonderer Akademiker bedurfte, um die Lösung in
ein sauberes Anhängsel im template-Sprech zu stricken.

Also: man baut nicht das in die Sprache, was nötig wäre, sondern
beschränkt sich auf das, was man hat und nennt das dann das Nötige.
Geht ja.
Meistens.
Man nutzt irgendwie das in der Sprache, was sich ergibt, wenn es
sich ergibt und nur wenn es sich mal ergibt.
Post by Peter J. Holzer
C ist C. Es gibt genügend andere Sprachen, wo diese Gleichung nicht
gilt. Du kannst ja eine andere Programmiersprache verwenden (ich mache
das auch - meistens).
Für den Stand der Software in Weltraumtechnik oder anderswo
kommt es nicht darauf an, was wir beide programmieren.

Es kommt darauf an, ob "der Markt" sich dazu aufrafft, sich nicht
jede vermeintliche Lösung als fertige Sprache aufdrängen zu lassen.

Was also kann bspw. den stereotypen Sprach-Fanatiker dazu bringen,
nicht mehr mit dem Finger auf die Norm zu zeigen, als müsse
man mit diesem Baseballschläger gegen jede technischen Veränderung
vorgehen? (Dann wären wir übrigens noch bei C with Classes...)

Häufig geht, was vielen Karrieren dient. Ein klares, im
Sprachkern verfügbares, einheitensicheres, einfaches Typsystem,
das den Arbeitgeber nicht viel kostet. Und auf gar keinen
Fall ein templatoides, auf Library-Auflösung setzendes System
mehrfach überladener, scheinheilig einfach tuender, handgetuneter
Operatoren, dessen Erklärung i.d.R. jenseits verfügbarer Personenjahre
liegt. Eine solche Herangehensweise gehört m.M.n. in die Experimentier-
Küche, in der man dann irgendwann zu einer richtigen Sprachdefinition
den Mut findet, wenn das auch Einschränkungen in der Flexibilität
bei Eigenbauten bedeuten könnte.

Die IT-Entscheider wissen andererseits zu sagen, dass es auf wichtigere
Dinge ankommt, werden die Schultern zucken und weiter alle dieselben
Folgen in Kauf nehmen, oder nicht?
Thomas Koenig
2017-02-02 23:10:59 UTC
Permalink
Post by G.B.
Post by Peter J. Holzer
Warum sträuben sich fast alle Sprachentwickler, so etwas wie
Zahlen ausdrücklich für Repräsentationen vorzusehen und
Programmierern nahe zu legen, für Meter usw, nur Typen,
nicht aber den Typ verwischende Repräsentation zu verwenden?
Du hast offenbar das Thema der letzten paar Postings in diesem Thread
nicht ganz mitbekommen: Genau darum ging es.
Dass die Sprachentwickler sich sträuben, Einheitensysteme
im Typsystem anzubieten, stimmt sehr wohl, das galt auch für C++,
s.u.
Ich verwende im echten Leben auch gerne MathCad, vor allem
wegen der Eineheitenumwandlung.
Post by G.B.
Häufig geht, was vielen Karrieren dient. Ein klares, im
Sprachkern verfügbares, einheitensicheres, einfaches Typsystem,
das den Arbeitgeber nicht viel kostet.
Dafür muss man sich erst mal drauf einigen, was man denn haben
möchte.

Wichtig ist zunächst mal die Unterscheidung von Dimensionen
(Länge, Zeit, Masse, Beschleunigung, Stromstärke) und
Einheiten (Mikrometer, Fortnight, Pfund, Angström pro Woche zum
Quadrat, Elektronenladungen pro Jahr).

Eine Sprachdefinition sollte die Wahl der Einheiten nicht auf
das SI-System und direkt abgeleitete Größen beschränken, sonst
verliert man die Physiker schnell als Klientel. Außerdem könnte
es Ärger mit sehr kleinen oder sehr großen Größen geben.

Wie darf man Einheiten aus den Basis-Einheiten ableiten dürfen?
Gebrochene Exponenten (wie z.B. Masse ^ 1/2) sind in manchen
Gebieten durchaus üblich, also sollte man zumindest zulassen.

Interessant wird es bei Rechnung mit verschiedenen Einheiten
(implizite vs. explizite Konvertierung?), ob man ein
Standard-Einheitensystem voraussetzt, in dem gerechnet wird,
wie man Library-Funktionen schreibt, die Einheiten prüfen,
aber unabhängig davon geschrieben werden können (keine separate
Integrationsroutine für Meter und Sekunden!) etc.

Ich habe da noch keinen sauberen, praktikablen Entwurf gesehen.
Wäre aber interessant. Im Zweifelsfall könnte ich probieren,
so ein System in einen existierenden Compiler reinzupacken :-)
Wäre dann aber natürlich nicht Sprachkern.
G.B.
2017-02-03 09:09:10 UTC
Permalink
Post by Thomas Koenig
Dafür muss man sich erst mal drauf einigen, was man denn haben
möchte.
Gibt's schon. Diese Einigung ist schon da:

(1) Die Dimensionen wie Länge oder Zeit sind als universelle Begriffe
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.

Ein Inch ist ebenso wie ein Millimeter eine Länge und nichts sonst,
soviel kann man für den gegebenen Fall der technischen Programmierung
feststellen.

(2) Man möchte, dass Größen nicht verwechselt werden können.

Das leisten Einheiten, gleich welche. Niemand sollte wirklich
10 Volt auf 5 Teile aufteilen können, in der Erwartung, dass
Hektopascal dabei herauskommen, Energieäquivalente hin
oder her. Dass die Dimension der geteilten Spannung immerhin
die einer Einheit wie Volt sein muss, steht so fest, dass solche
Regeln unzweideutig in formale Sprachen eingebaut werden können.
Post by Thomas Koenig
Interessant wird es bei Rechnung mit verschiedenen Einheiten
(implizite vs. explizite Konvertierung?), ob man ein
Standard-Einheitensystem voraussetzt, in dem gerechnet wird,
wie man Library-Funktionen schreibt, die Einheiten prüfen,
aber unabhängig davon geschrieben werden können (keine separate
Integrationsroutine für Meter und Sekunden!) etc.
Die Einheiten wären m.E. hinreichend behandelt, wenn

- der Übersetzer zahlmäßig gegebene Größen einer Dimension
bewerten muss, also bei Literalen.

Länge abstand := 14.92 m (* geht *)
Länge abstand := 14.92 (* Fehler *)

- I/O gesteuert werden muss. Also entweder dimensionierte Größen
aus Zahlwerten konstruiert (Eingabe), oder bit-Repräsentationen
aus dimensionierten Zahlwerten erzeugt werden müssen (Ausgabe).

An anderen Stellen im Programm stehen die dimensionierten Größen
für physikalische Größen, deren Bitrepräsentation oder Zahlwert
der Programmierung entzogen sind, modulo üblicher expliziter
Wandlungen für Tricks. Die Einheiten spielen für die Größe
hier keine Rolle, ganz so wie in der physikalischen Welt.
Sieghard Schicktanz
2017-02-03 22:04:14 UTC
Permalink
Hallo G.B.,

(Sorry - ich habe zufällig diese Diskussion gesehen und kann einiges darin
nach meinem Verständnis der Phsyik so nicht stehenlassen.)

Du schriebst am Fri, 3 Feb 2017 10:09:10 +0100:

[Dimensionen]
Post by G.B.
Post by Thomas Koenig
Dafür muss man sich erst mal drauf einigen, was man denn haben
möchte.
Einigen muß man sich hier eigentlich nicht, das ist eigentlich schon
vollständig definiert.
Post by G.B.
(1) Die Dimensionen wie Länge oder Zeit sind als universelle Begriffe
Ok, wobei es als _universelle_ "Begriffe" da eigentlich außer den beiden
nur noch Masse und (elektrische) Ladung zusätzlich gibt.
Post by G.B.
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.
Nein, falsch. _Einheiten_ sind lediglich Maßstäbe für Messgrößen in den
Dimensionen, die zudem nicht unabhängig von einer - meist willkürlich
festgelegten - Referenzgröße abgeleitet sind. In der Physik wird oft auch
mit sog. "natürlichen" Einheiten gearbeitet, die als Referenzgröße eine
Naturkonstante wie die Lichtgeschwindigkeit, Elektronenladung oder die
Planck'sche Konstante benutzen.
Post by G.B.
Ein Inch ist ebenso wie ein Millimeter eine Länge und nichts sonst,
Ein "Inch" ist ein _Maß_ für eine Länge, nicht die Länge selber.
Post by G.B.
(2) Man möchte, dass Größen nicht verwechselt werden können.
Das leisten Einheiten, gleich welche. Niemand sollte wirklich
Nein, das leisten EInheiten _nicht_. Einheiten für eine bestimmte Dimension
sind beliebig ineinander konvertierbar, wie z.B. 1 Zoll = 2,54cm. Das ist
ein wenig so wie bei Währungen, wobei im Gegesatz zu Währungen, mit ihren
veränderlichen Konvertierungsfaktoren, die Verhältnisse konstant sind.
Post by G.B.
10 Volt auf 5 Teile aufteilen können, in der Erwartung, dass
Hektopascal dabei herauskommen, Energieäquivalente hin
Nachdem die _Dimensionen_ so etwas wie "Basisvektoren" eines Raumes
sind, d.h. linear unabhängig untereinander, _können_ - physikalisch -
Größen unterschiedlicher Dimension nicht ineinander überführt werden.
Post by G.B.
oder her. Dass die Dimension der geteilten Spannung immerhin
die einer Einheit wie Volt sein muss, steht so fest, dass solche
Regeln unzweideutig in formale Sprachen eingebaut werden können.
Falsch. Gerade die elektrische Spannung ist eigentlich eine _abgeleitete_
Einheit, eine Linearkombination mehrerer Basisdimensionen.
(1 V = 1 kgm²/(s²C), d.h. Spannung = Masse*Länge²/(Zeit²*Ladung))
Post by G.B.
Die Einheiten wären m.E. hinreichend behandelt, wenn
- der Übersetzer zahlmäßig gegebene Größen einer Dimension
bewerten muss, also bei Literalen.
Länge abstand := 14.92 m (* geht *)
Länge abstand := 14.92 (* Fehler *)
auch: Länge abstand := 14.92 s (* Fehler *)
aber: Länge abstand := 5,874015748 inch (* i.O.! *)

Wesentlich ist hier die Verbindung zu den eingehenden Basis-Dimensionen.
Bei einer Implementierung könnte dann für die Repräsentation einer (Grund-)
Einheit jeweils ein Maßstabsfaktor bei der Repräsentation der Dimension
registriert sein, womit die Gesamtheit der Konvertierungsfaktoren beliebige
Kombinationen von Einheiten und implizite Umrechungen zuließe.
Post by G.B.
- I/O gesteuert werden muss. Also entweder dimensionierte Größen
aus Zahlwerten konstruiert (Eingabe), oder bit-Repräsentationen
aus dimensionierten Zahlwerten erzeugt werden müssen (Ausgabe).
Die _Benennung_ (m, Zoll, l, V, J, BTU...) der Einheiten ist eine
Eigenschaft der _Einheit_, die Kompatibilität zwischen Einheiten ergibt
sich daraus, ob deren _Zusammensetzung_ aus Dimensionen identisch ist.
Post by G.B.
Wandlungen für Tricks. Die Einheiten spielen für die Größe
hier keine Rolle, ganz so wie in der physikalischen Welt.
Richtig, die Einheiten spielen _keine Rolle_ für eine physikalische Größe,
sie sind nur von Bedeutung für den _Wert_, mit dem gerechnet wird.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Thomas Koenig
2017-02-03 23:55:02 UTC
Permalink
Post by Sieghard Schicktanz
Hallo G.B.,
(Sorry - ich habe zufällig diese Diskussion gesehen und kann einiges darin
nach meinem Verständnis der Phsyik so nicht stehenlassen.)
[Dimensionen]
Post by G.B.
Post by Thomas Koenig
Dafür muss man sich erst mal drauf einigen, was man denn haben
möchte.
Einigen muß man sich hier eigentlich nicht, das ist eigentlich schon
vollständig definiert.
Post by G.B.
(1) Die Dimensionen wie Länge oder Zeit sind als universelle Begriffe
Ok, wobei es als _universelle_ "Begriffe" da eigentlich außer den beiden
nur noch Masse und (elektrische) Ladung zusätzlich gibt.
Post by G.B.
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.
Nein, falsch. _Einheiten_ sind lediglich Maßstäbe für Messgrößen in den
Dimensionen, die zudem nicht unabhängig von einer - meist willkürlich
festgelegten - Referenzgröße abgeleitet sind.
Klar. Eine physikalische Meßgröße besteht aus einer Zahl, multipliziert
mit einer Einheit. Die Einheit hat eine Dimension.
Post by Sieghard Schicktanz
Post by G.B.
Ein Inch ist ebenso wie ein Millimeter eine Länge und nichts sonst,
Ein "Inch" ist ein _Maß_ für eine Länge, nicht die Länge selber.
Es existiert auch eine Länge von einem Zoll.
Post by Sieghard Schicktanz
Einheiten für eine bestimmte Dimension
sind beliebig ineinander konvertierbar, wie z.B. 1 Zoll = 2,54cm. Das ist
ein wenig so wie bei Währungen, wobei im Gegesatz zu Währungen, mit ihren
veränderlichen Konvertierungsfaktoren, die Verhältnisse konstant sind.
Das macht die Dimensionsanalyse so spannend :-)
Post by Sieghard Schicktanz
Post by G.B.
10 Volt auf 5 Teile aufteilen können, in der Erwartung, dass
Hektopascal dabei herauskommen, Energieäquivalente hin
Nachdem die _Dimensionen_ so etwas wie "Basisvektoren" eines Raumes
sind, d.h. linear unabhängig untereinander, _können_ - physikalisch -
Größen unterschiedlicher Dimension nicht ineinander überführt werden.
Post by G.B.
oder her. Dass die Dimension der geteilten Spannung immerhin
die einer Einheit wie Volt sein muss, steht so fest, dass solche
Regeln unzweideutig in formale Sprachen eingebaut werden können.
Falsch. Gerade die elektrische Spannung ist eigentlich eine _abgeleitete_
Einheit, eine Linearkombination mehrerer Basisdimensionen.
(1 V = 1 kgm²/(s²C), d.h. Spannung = Masse*Länge²/(Zeit²*Ladung))
Das ist reine Definitionssache. Es ist kein Problem, sich ein
Einheitensystem zu definieren, bei dem eine Grundeinheit die elektrische
Spannung ist und die Stromstärke eine abgeleitete Größe. Wenn man
Spannungen einfacher messen könnte als Ströme, könnte das durchaus Sinn
machen :-)
Post by Sieghard Schicktanz
Post by G.B.
Die Einheiten wären m.E. hinreichend behandelt, wenn
- der Übersetzer zahlmäßig gegebene Größen einer Dimension
bewerten muss, also bei Literalen.
Länge abstand := 14.92 m (* geht *)
Länge abstand := 14.92 (* Fehler *)
auch: Länge abstand := 14.92 s (* Fehler *)
aber: Länge abstand := 5,874015748 inch (* i.O.! *)
Ich würde das anders aufsetzen: Eine Variable einer Programmiersprache
hat eine Dimension und eine Einheit, also z.B.

Länge, Einheit(Meter) :: abstand
Länge, Einheit(Zoll) :: Maß

und dann

abstand = 2.31 {Meter} ! Geschweifte Klammer für Einheiten

oder

abstand = 25.12 {Zoll}

was dann eine Konvertierung von Zoll nach Meter auslösen würde

Noch interessanter wird es bei

Maß = 13 {Zoll}
abstand = Maß {Meter} + 1.32 {Meter}

wobei Maß {Meter} eine explizite Konvertierung erzwingen sollte.

abstand = Maß + 1.32 {Meter}

wäre ein Typfehler.

Oder doch besser eine implizite Umwandlung, vielleicht auf den Typ
der linken Seite?
Post by Sieghard Schicktanz
Wesentlich ist hier die Verbindung zu den eingehenden Basis-Dimensionen.
Bei einer Implementierung könnte dann für die Repräsentation einer (Grund-)
Einheit jeweils ein Maßstabsfaktor bei der Repräsentation der Dimension
registriert sein, womit die Gesamtheit der Konvertierungsfaktoren beliebige
Kombinationen von Einheiten und implizite Umrechungen zuließe.
Das ist ein Problem - Grundeinheiten sollten in der Programmiersprache
nicht festgelegt werden. SI-Einheiten gehen für viele Probleme,
aber halt nicht für alle.

Interessanter wäre der Fall

Länge, Einheit(Zoll) :: D
Geschwindigkeit, Einheit(Fuß/Minute) :: u
Viskosität, Einheit (Pa * s) :: eta
Dichte, Einheit (lb/ft^3) :: rho
Dimensionslos :: Re

und dann die Reynolds-Zahl berechnen:

Re = u * D * rho / eta

Implizite oder explizite Umwandlung? In welchen Einheiten sollte
bei einer expliziten Umrechnung gerechnet werden?

Ach ja, und dann gibt es noch die Leute, die gerne die Formel

a = ln(T/T0)

schreiben als

a = ln(T) - ln(T0)

Eeeeigentlich richtig, aber nicht mehr so ganz, wenn T eine Temperatur ist...
Sieghard Schicktanz
2017-02-06 00:19:48 UTC
Permalink
Hallo Thomas,
Post by Thomas Koenig
Post by Sieghard Schicktanz
[Dimensionen]
Klar. Eine physikalische Meßgröße besteht aus einer Zahl, multipliziert
mit einer Einheit. Die Einheit hat eine Dimension.
Wobei ich die Verknüpfung der (Maß-) Zahl mit der Einheit noch etwas
stärker sehen würde als "nur" eine Multiplikation. Für die Anwendung sind
die beiden _untrennbar_ verbunden, obwohl sie in gewisser Weise separat
verrechnet werden können.
Post by Thomas Koenig
Post by Sieghard Schicktanz
Ein "Inch" ist ein _Maß_ für eine Länge, nicht die Länge selber.
Es existiert auch eine Länge von einem Zoll.
Es existiert eine Länge, deren Maß "1 Zoll" beträgt. Die Hierarchie ist:
Dimension: Länge, Einheit: Zoll, Maßzahl: 1
Post by Thomas Koenig
Post by Sieghard Schicktanz
Einheiten für eine bestimmte Dimension
sind beliebig ineinander konvertierbar, wie z.B. 1 Zoll = 2,54cm. Das
ist ein wenig so wie bei Währungen, wobei im Gegesatz zu Währungen, mit
ihren veränderlichen Konvertierungsfaktoren, die Verhältnisse konstant
sind.
Das macht die Dimensionsanalyse so spannend :-)
Bei physikalischen Einheiten ist das noch recht übersichtlich wegen der
festen Verhältnisse, die nur gelegentlich unter Wahrung der Konsistenz an
neueste Erkenntnisse angepasst werden.
Bei Währungen geht's bunt durcheinander, da ist das Konvertierungssystem
nicht mal in sich konsistent (ein Betrag in Dollar, konvertiert in z.B.
Krüger Rand, kann von demselben Betrag, erst konvertiert in Euro und dann
in Krüger Rand, durchaus abweichen), und die Faktoren werden laufend
geändert und hängen zudem noch vom Konvertierungsmechanismus ab (Bank,
Wechselstube, Laden...). _Das_ sinnvoll abzubilden würde ich dem
sprichörtlichen "Sack Flöhe hüten" mindestens gleichsetzen.
Physikalische Einheiten sind dagegen harmlos.
Post by Thomas Koenig
Post by Sieghard Schicktanz
Nachdem die _Dimensionen_ so etwas wie "Basisvektoren" eines Raumes
sind, d.h. linear unabhängig untereinander, _können_ - physikalisch -
Größen unterschiedlicher Dimension nicht ineinander überführt werden.
[elektrische Spannung als abgeleitete Einheit]
Post by Thomas Koenig
Das ist reine Definitionssache. Es ist kein Problem, sich ein
Nach dem oben erwähnten Verständnis der Dimensionen als so etwas wie die
"Basisvektoren" eines Raumes ist das auch kein Problem - es gibt ja
beliebig viele solcher Basen des Raumes als Linearkombinationen (mit
gewissen Eigenschaften) der jeweiligen Basisvektoren.
(BTW, die elektrische Spannung läßt sich eigentlich tatsächlich mittels des
Quanten-Hall-Effekts sehr genau und meßgeräteunabhängig bestimmen.)
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by G.B.
Die Einheiten wären m.E. hinreichend behandelt, wenn
...
Post by Thomas Koenig
Ich würde das anders aufsetzen: Eine Variable einer Programmiersprache
hat eine Dimension und eine Einheit, also z.B.
Das entspricht ja genau dem, was ich anmerken wollte.
Post by Thomas Koenig
Länge, Einheit(Meter) :: abstand
Länge, Einheit(Zoll) :: Maß
Ggfs. müßte für eine _Variable_ eine Einheit überhaupt nicht angegeben
werden. Die Einheit ist Teil der Belegung mit dem Wert, der "irgendwo" aus
einer Eingabe oder als Konstante eingebracht werden muß - _dort_ muß die
Einheit definiert werden, und wohl auch bei der Ausgabe der Ergebnisse.
Post by Thomas Koenig
und dann
abstand = 2.31 {Meter} ! Geschweifte Klammer für Einheiten
Wie das dargestellt wird ist Implementationssache.
Post by Thomas Koenig
abstand = 25.12 {Zoll}
was dann eine Konvertierung von Zoll nach Meter auslösen würde
Aber _das_ würd ich nicht machen. Hier soll die Variable ruhig den Meßwert
(25,12) haben, wenn sie die Einheit "Zoll" besitzt. Eine Konvertierung muß
erst dann erfolgen, wenn sie zu einem Ergebnis in einer anderen Einheit
verrechnet werden soll, z.B. als Längenanteil einer Geschwindigkeit in km/h.
Post by Thomas Koenig
Noch interessanter wird es bei
Maß = 13 {Zoll}
abstand = Maß {Meter} + 1.32 {Meter}
Das würde ich _so_ nicht machen. In der Berechnung haben explizite
Einheiten bei den _Variablen_ nichts mehr verloren. Literale brauchen
natürlich diese Zuordnung, und eine ggfs. nötige Konvertierung muß so
stattfinden, daß das Ergebnis konsistent berechnet werden kann.
Post by Thomas Koenig
abstand = Maß + 1.32 {Meter}
wäre ein Typfehler.
Nein, das würde ich anders herum machen.

[Konvertierungsfaktoren]
Post by Thomas Koenig
Das ist ein Problem - Grundeinheiten sollten in der Programmiersprache
nicht festgelegt werden.
Da hast Du zwar Recht, aber irgendwie müssen die Einheiten zu einem
"gemeinsamen Nenner" kommen. Nicht bei allen Grundeinheiten gibt es eine
"natürliche Einheit" wie z.B. bei der elektrischen Ladung.
Post by Thomas Koenig
nicht festgelegt werden. SI-Einheiten gehen für viele Probleme,
aber halt nicht für alle.
Für welche gehen sie nicht? Ein solcher Fall würde mich wundern.
(Auch wegen der derzeitigen Inflation von SI-Einheiten für alle
möglichen Gebiete, insbes. Radioaktivität.)
Post by Thomas Koenig
Interessanter wäre der Fall
Länge, Einheit(Zoll) :: D
Geschwindigkeit, Einheit(Fuß/Minute) :: u
Viskosität, Einheit (Pa * s) :: eta
Dichte, Einheit (lb/ft^3) :: rho
Dimensionslos :: Re
Re = u * D * rho / eta
Und? Da muß eine _dimensionslose_ Zahl 'rauskommen, die von allen benutzten
Einheiten unabhängig ist. D.h. alle Einheiten müssen sich wegheben, und
unabhängig von irgendwelchen Konvertierungen während der Berechnung muß
immer derselbe Wert herauskommen.
Post by Thomas Koenig
Implizite oder explizite Umwandlung? In welchen Einheiten sollte
bei einer expliziten Umrechnung gerechnet werden?
Egal, die müssen intern nur konsistent benutzt werden. Praktisch kommen
natürlich noch Betrachtungen zum darstellbaren Bereich und der Genauigkeit
dazu, Wachstumsgeschwindigkeiten aus Lichtjahren und Mikrosekunden zu
berechnen ist sicher nicht besonders vorteilhaft.
Post by Thomas Koenig
Ach ja, und dann gibt es noch die Leute, die gerne die Formel
a = ln(T/T0)
schreiben als
a = ln(T) - ln(T0)
Eeeeigentlich richtig, aber nicht mehr so ganz, wenn T eine Temperatur ist...
Nee, das ist ganz prinzipiell falsch, weil da die von Dir so forsch
hingeschriebene Variable T0 _auch_ eine Temperatur sein _muß_. Und dann
steht da für den zweiten Ausdruck genaugenommen

a = ln(T)+ ln (<Tempertur>) - ln(T0)- ln (<Temperatur>),

wobei der Term "ln (<Tempertur>)" nicht berechenbar ist, aber da er einmal
positiv und einmal negativ auftritt und dafür beidesmal _dieselbe_
"<Temperatur>" sein muß, hebt er sich weg, und es bleiben die beiden
Ausdrücke für die _Maßzahl_ von "T" und die _Maßzahl_ von "T0", deren ln
problemlos bestimmt und die Differenz berechnet werden kann.
Der _zuvor_ durchzuführende Einheitenabgleich hat dann dafür gesorgt, daß
das Ergebnis wieder konsistent und unabhängig vom Einheitensystem sein muß.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Peter J. Holzer
2017-02-06 16:54:29 UTC
Permalink
Post by Sieghard Schicktanz
Post by Thomas Koenig
abstand = 25.12 {Zoll}
was dann eine Konvertierung von Zoll nach Meter auslösen würde
Aber _das_ würd ich nicht machen. Hier soll die Variable ruhig den Meßwert
(25,12) haben, wenn sie die Einheit "Zoll" besitzt. Eine Konvertierung muß
erst dann erfolgen, wenn sie zu einem Ergebnis in einer anderen Einheit
verrechnet werden soll, z.B. als Längenanteil einer Geschwindigkeit in km/h.
Es ist halt die Frage, ob die Einheit Teil des Werts einer Variable sein
soll (der eher dynamische Ansatz) oder Teil des Typs (der eher statische
Ansatz). Für beide Ansätze lassen sich sicher Argumente finden. Ich
verwende ja in der Praxis eher dynamische Sprachen wie Python oder Perl,
aber der Compiler kann sicher besseren Code erzeugen und mehr Fehler zur
Compilezeit finden, wenn man den statischen Ansatz wählt.
Post by Sieghard Schicktanz
Post by Thomas Koenig
Implizite oder explizite Umwandlung? In welchen Einheiten sollte
bei einer expliziten Umrechnung gerechnet werden?
Egal, die müssen intern nur konsistent benutzt werden.
Full ACK.
Post by Sieghard Schicktanz
Praktisch kommen natürlich noch Betrachtungen zum darstellbaren
Bereich und der Genauigkeit dazu, Wachstumsgeschwindigkeiten aus
Lichtjahren und Mikrosekunden zu berechnen ist sicher nicht besonders
vorteilhaft.
Menschen haben damit mehr Probleme als Computer. Mein Bart wächst - wenn
ich mich nicht verrechnet habe - um ca. 4E-31 Lichtjahre pro
Mikrosekunde. Sicher keine handliche Zahl, aber selbst in einer
Single-Precision-Floating-Point-Zahl noch locker abbildbar. Erst wenn
man die kinetische Energie eines vom wachsenden Bart angestoßenen
Teilchens berechnen will und zu diesem Behufe die Geschwindigkeit
quadriert, gibt es einen Underflow. Mit Double-Precision-
Floating-Point-Zahlen ist aber auch das kein Problem.

Insofern würde ich mir über unnötige Typumwandlungen keine Sorgen
machen, solange wir von Meßwerten in irgendeiner Form sprechen.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Sieghard Schicktanz
2017-02-06 23:51:12 UTC
Permalink
Hallo Peter,
Post by Peter J. Holzer
Es ist halt die Frage, ob die Einheit Teil des Werts einer Variable sein
soll (der eher dynamische Ansatz) oder Teil des Typs (der eher statische
Ansatz). Für beide Ansätze lassen sich sicher Argumente finden. Ich
Richtig. Da wird man wohl pragmatisch vorgehen müssen und feststellen, was
davon einfacher zu implementieren ist. Hat man viele Zuweisungen mit Werten
unterschiedlicher Einheitensysteme wird die Bewertung wohl anders ausfallen
als bei Rechnungen, die weitestgehend nur ein einziges Einheitensystem
benutzen.
Post by Peter J. Holzer
aber der Compiler kann sicher besseren Code erzeugen und mehr Fehler zur
Compilezeit finden, wenn man den statischen Ansatz wählt.
Das wäre auch ein Gesichtspunkt dafür.
Post by Peter J. Holzer
Post by Sieghard Schicktanz
Praktisch kommen natürlich noch Betrachtungen zum darstellbaren
Bereich und der Genauigkeit dazu, Wachstumsgeschwindigkeiten aus
...
Post by Peter J. Holzer
Menschen haben damit mehr Probleme als Computer. Mein Bart wächst - wenn
ich mich nicht verrechnet habe - um ca. 4E-31 Lichtjahre pro
Mikrosekunde. Sicher keine handliche Zahl, aber selbst in einer
Single-Precision-Floating-Point-Zahl noch locker abbildbar. Erst wenn
Vorsicht - ich habe nicht ohne Grund auch die Genauigkeit erwähnt. Kleine
Differenzen großer Werte sind problematisch, die Subtraktion (und die
Addition!) ist numerisch instabil. Zu Deinem Beispiel: Wieviele gültige
Stellen blieben übrig, wenn Du die Differenz der Geschwindigkeiten Deines
Barts und eine Grashalms brauchtest?
Post by Peter J. Holzer
quadriert, gibt es einen Underflow. Mit Double-Precision-
Floating-Point-Zahlen ist aber auch das kein Problem.
"Floating-Point-Zahlen" sind prinzipiell ungenau, bei komplexeren
Rechnungen muß man dabei immer mit einem Genauigkeitsverlust rechnen bzw.
muß man diesen analysieren, wenn man die Genauigkeit des Ergebnisses
kennen muß. Da können dann auf 0,1% genaue Eingangswerte schon auch mal
einen nur 15% sicheren Endwert liefern.
Post by Peter J. Holzer
Insofern würde ich mir über unnötige Typumwandlungen keine Sorgen
machen, solange wir von Meßwerten in irgendeiner Form sprechen.
Gerade da ist es wichtig, sich Gedanken über die Genauigkeit der Ergenisse
zu machen. Viele physikalische Konstanten sind inzwischen auf >8 gültige
Stellen vermessen oder festgelegt. Da tut sich eine "single"-Variable schon
schwer, die Genauigkeit abzubilden. Auch die maschinelle Berechnung stellt
nicht unbedingt absolute Präzision sicher!
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Peter J. Holzer
2017-02-09 19:52:31 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Peter,
[...]
Post by Sieghard Schicktanz
Post by Peter J. Holzer
Post by Sieghard Schicktanz
Praktisch kommen natürlich noch Betrachtungen zum darstellbaren
Bereich und der Genauigkeit dazu, Wachstumsgeschwindigkeiten aus
...
Post by Peter J. Holzer
Menschen haben damit mehr Probleme als Computer. Mein Bart wächst - wenn
ich mich nicht verrechnet habe - um ca. 4E-31 Lichtjahre pro
Mikrosekunde. Sicher keine handliche Zahl, aber selbst in einer
Single-Precision-Floating-Point-Zahl noch locker abbildbar. Erst wenn
Vorsicht - ich habe nicht ohne Grund auch die Genauigkeit erwähnt. Kleine
Differenzen großer Werte sind problematisch, die Subtraktion (und die
Addition!) ist numerisch instabil. Zu Deinem Beispiel: Wieviele gültige
Stellen blieben übrig, wenn Du die Differenz der Geschwindigkeiten Deines
Barts und eine Grashalms brauchtest?
Gleich viele, egal welche Einheit ich verwende. Wenn die Genauigkeit
einer FP-Zahl ausreicht, das Ergebnis in cm/Tag zu berechnen, dann
reicht sie auch aus, um es in Lichtjahren/Mikrosekunde zu berechnen, und
der relative Fehler ist gleich groß (+/- ein paar Eps wegen eventuell
gerundeter Zwischenergebnisse).
Post by Sieghard Schicktanz
Post by Peter J. Holzer
quadriert, gibt es einen Underflow. Mit Double-Precision-
Floating-Point-Zahlen ist aber auch das kein Problem.
"Floating-Point-Zahlen" sind prinzipiell ungenau,
Alle Zahlen sind prinzipiell ungenau. Versuch mal 1/3 als Integer
darzustellen, oder Pi als rationale Zahl. Und wenn Du nicht reine
Mathematik betreibst, sondern irgendetwas in der "richtigen Welt"
berechnen willst, sind schon deine Eingabe-Werte ungenau - und zwar im
Normalfall um vieles ungenauer als der durch den verwendeten Datentyp
erzwungene Quantisierungsfehler.
Post by Sieghard Schicktanz
bei komplexeren Rechnungen muß man dabei immer mit einem
Genauigkeitsverlust rechnen bzw. muß man diesen analysieren, wenn man
die Genauigkeit des Ergebnisses kennen muß. Da können dann auf 0,1%
genaue Eingangswerte schon auch mal einen nur 15% sicheren Endwert
liefern.
Ja, kann passieren. Ist aber meistens eher deswegen, weil die
Ungenauigkeit des Inputs (hier also 0.1%) sich im Lauf der Berechnungen
immer weiter aufschaukelt, nicht deshalb, weil man mit einem "ungenauen
Zahlentyp" rechnet.
Post by Sieghard Schicktanz
Post by Peter J. Holzer
Insofern würde ich mir über unnötige Typumwandlungen keine Sorgen
machen, solange wir von Meßwerten in irgendeiner Form sprechen.
Gerade da ist es wichtig, sich Gedanken über die Genauigkeit der Ergenisse
zu machen. Viele physikalische Konstanten sind inzwischen auf >8 gültige
Stellen vermessen oder festgelegt. Da tut sich eine "single"-Variable schon
schwer, die Genauigkeit abzubilden.
Dann verwendet man halt double. Man kann sich natürlich absichtlich in
den Fuß schießen, aber warum sollte man das tun? Im übrigen nützt mir
eine auf 8 Stellen genaue Konstante nur dann was, wenn auch alle anderen
Werte in meiner Berechnung diese Genauigkeit haben. Wenn meine gemessene
Länge nur auf 3 Stellen genau ist, ist wahrscheinlich nicht die auf 24
Bit gerundete Konstante das Problem (wenn es überhaupt ein Problem ist -
vielleicht muss das Ergebnis eh nur auf 2 Stellen genau sein).
Post by Sieghard Schicktanz
Auch die maschinelle Berechnung stellt nicht unbedingt absolute
Präzision sicher!
Man kann maschinell absolut präzise Unsinn berechnen ;-).

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Koenig
2017-02-06 23:26:11 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Thomas,
Post by Thomas Koenig
Post by Sieghard Schicktanz
[Dimensionen]
Klar. Eine physikalische Meßgröße besteht aus einer Zahl, multipliziert
mit einer Einheit. Die Einheit hat eine Dimension.
Wobei ich die Verknüpfung der (Maß-) Zahl mit der Einheit noch etwas
stärker sehen würde als "nur" eine Multiplikation. Für die Anwendung sind
die beiden _untrennbar_ verbunden, obwohl sie in gewisser Weise separat
verrechnet werden können.
Einheit und Maßzahl sind eben _nicht_ untrennbar miteinander
verbunden. Wenn ich 10 cm gemessen haben, dann ist das völlig
äquivalent zu 0.1 m (modulo Meßschranken etc.). Eine
Größe lässt sich nur mit Hilfe von Maßzahl und Einheit angeben,
aber die Maßzahl ist halt eben von der Einheit verbunden, und
ich kann die gleiche Größe mit Hilfe einer anderen Einheit
der gleichen Dimension angeben.

Und was die Verknüpfung angeht: "Multiplikation" ist das, was
man normalerweise dazu sagt, und es teilt einige Eigenschaften
mit der Multiplikation reeller Zahlen. Allerdings habe ich noch
keine Veröffentlichungen zu einem Axiomensystem für physikalische
Einheiten gesehen. Irgendwie mögen Mathematiker keine Einheiten,
oder sie halten sie für irrelevant oder trivial, sonst hätten
sie sich schon lange drangemacht.

Das Bridgman-Axiom (Physilalische Zusammenhänge sind unabhängig vom
verwendeten Einheitensystem) kommt dem noch am nächsten.
Post by Sieghard Schicktanz
Post by Thomas Koenig
Post by Sieghard Schicktanz
Nachdem die _Dimensionen_ so etwas wie "Basisvektoren" eines Raumes
sind, d.h. linear unabhängig untereinander, _können_ - physikalisch -
Größen unterschiedlicher Dimension nicht ineinander überführt werden.
[elektrische Spannung als abgeleitete Einheit]
Post by Thomas Koenig
Das ist reine Definitionssache. Es ist kein Problem, sich ein
Nach dem oben erwähnten Verständnis der Dimensionen als so etwas wie die
"Basisvektoren" eines Raumes ist das auch kein Problem - es gibt ja
beliebig viele solcher Basen des Raumes als Linearkombinationen (mit
gewissen Eigenschaften) der jeweiligen Basisvektoren.
Klar, man kann Dimensionen als einen Vektorraum auffassen. Das hilft
auch ungemein bei der Dimensionsanalyse.
Post by Sieghard Schicktanz
(BTW, die elektrische Spannung läßt sich eigentlich tatsächlich mittels des
Quanten-Hall-Effekts sehr genau und meßgeräteunabhängig bestimmen.)
Hmm... anscheinend wird der tatsächlich praktisch als Standard für die
Stromstärke genommen, zusammen mit dem Josephson - Effekt.
Post by Sieghard Schicktanz
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by G.B.
Die Einheiten wären m.E. hinreichend behandelt, wenn
...
Post by Thomas Koenig
Ich würde das anders aufsetzen: Eine Variable einer Programmiersprache
hat eine Dimension und eine Einheit, also z.B.
Das entspricht ja genau dem, was ich anmerken wollte.
Post by Thomas Koenig
Länge, Einheit(Meter) :: abstand
Länge, Einheit(Zoll) :: Maß
Ggfs. müßte für eine _Variable_ eine Einheit überhaupt nicht angegeben
werden. Die Einheit ist Teil der Belegung mit dem Wert, der "irgendwo" aus
einer Eingabe oder als Konstante eingebracht werden muß - _dort_ muß die
Einheit definiert werden, und wohl auch bei der Ausgabe der Ergebnisse.
Dynamische Einheiten? Nicht für hohe Anforderungen an Rechehenleistung,
bitte :-) Eine Variable einer Einheit zuzuordnen, macht schon Sinn.
Post by Sieghard Schicktanz
Aber _das_ würd ich nicht machen. Hier soll die Variable ruhig den Meßwert
(25,12) haben, wenn sie die Einheit "Zoll" besitzt.
(25,12) heisst was?
Post by Sieghard Schicktanz
Eine Konvertierung muß
erst dann erfolgen, wenn sie zu einem Ergebnis in einer anderen Einheit
verrechnet werden soll, z.B. als Längenanteil einer Geschwindigkeit in km/h.
Kann man natürlich so machen. Syntax wäre so oder...
Post by Sieghard Schicktanz
Post by Thomas Koenig
Noch interessanter wird es bei
Maß = 13 {Zoll}
abstand = Maß {Meter} + 1.32 {Meter}
Das würde ich _so_ nicht machen.i In der Berechnung haben explizite
Einheiten bei den _Variablen_ nichts mehr verloren.
Wenn man explizit konvertieren möchte, brauch man dafür halt irgendeine
Syntax. Im Zweifelsfall tut es natürlich auch

Maß = 13 {Zoll}
abstand = convert(Maß,Meter) + 1.32 {Meter}

oder halt doch implizit

abstand = Maß + Meter

Nur ist bei der impliziten Konvertierung erstmal unklar, wie die
ablaufen soll - rechts nach links, links nach rechts, oder alles
auf den Typ der linken Seite?
Post by Sieghard Schicktanz
[Konvertierungsfaktoren]
Post by Thomas Koenig
Das ist ein Problem - Grundeinheiten sollten in der Programmiersprache
nicht festgelegt werden.
Da hast Du zwar Recht, aber irgendwie müssen die Einheiten zu einem
"gemeinsamen Nenner" kommen.
Man definiert eine Einheit als ein Vielfaches von einer anderen,
möglicherwiese auch mit Offset (für die Leute, die unbedingt °C
nehmen wollen...)
Post by Sieghard Schicktanz
Nicht bei allen Grundeinheiten gibt es eine
"natürliche Einheit" wie z.B. bei der elektrischen Ladung.
Post by Thomas Koenig
nicht festgelegt werden. SI-Einheiten gehen für viele Probleme,
aber halt nicht für alle.
Für welche gehen sie nicht?
Häufig einfach unpraktisch. Aus numerischen Gründen sollten
viele Größen nicht allzu weit von 1 entfernt sein, und
wenn ein vernünftiges Einheitensystem für mein Problem aus
Elementarladung, Elektronenmasse, Vakuumlichtgeschwindigkeit,
Plancksches Wirkungsquantum, Boltzmann-Konstante besteht (wenn
das wirklich konsistent ist - habe ich nicht überprüft), dann
sollte ich das auch machen können.

Physiker gehen ja gerne lax mit Einheiten um - "Die
Lichtgeschwindigkeit ist eins" - das sollte man auch als Einheiten
formulieren können :-)
Post by Sieghard Schicktanz
(Auch wegen der derzeitigen Inflation von SI-Einheiten für alle
möglichen Gebiete, insbes. Radioaktivität.)
Post by Thomas Koenig
Interessanter wäre der Fall
Länge, Einheit(Zoll) :: D
Geschwindigkeit, Einheit(Fuß/Minute) :: u
Viskosität, Einheit (Pa * s) :: eta
Dichte, Einheit (lb/ft^3) :: rho
Dimensionslos :: Re
Re = u * D * rho / eta
Und? Da muß eine _dimensionslose_ Zahl 'rauskommen, die von allen benutzten
Einheiten unabhängig ist. D.h. alle Einheiten müssen sich wegheben, und
unabhängig von irgendwelchen Konvertierungen während der Berechnung muß
immer derselbe Wert herauskommen.
Klar, nur...
Post by Sieghard Schicktanz
Post by Thomas Koenig
Implizite oder explizite Umwandlung? In welchen Einheiten sollte
bei einer expliziten Umrechnung gerechnet werden?
Egal, die müssen intern nur konsistent benutzt werden.
Das muss richtg rauskommen, aber man muss schon festlegen, wie man
das haben will :-)
Post by Sieghard Schicktanz
Praktisch kommen
natürlich noch Betrachtungen zum darstellbaren Bereich und der Genauigkeit
dazu, Wachstumsgeschwindigkeiten aus Lichtjahren und Mikrosekunden zu
berechnen ist sicher nicht besonders vorteilhaft.
Post by Thomas Koenig
Ach ja, und dann gibt es noch die Leute, die gerne die Formel
a = ln(T/T0)
schreiben als
a = ln(T) - ln(T0)
Eeeeigentlich richtig, aber nicht mehr so ganz, wenn T eine Temperatur ist...
Nee, das ist ganz prinzipiell falsch,
Erzähl einem Mathematiker, dass ln(T/T0) = ln(T) - ln(T0) nicht mehr
gilt, der wird dich verständnislos anschauen :-)

Und ja, ich habe auch schon (in Vorlesungen) Dozenten darauf
hingewiesen, dass das so nicht geht.
Post by Sieghard Schicktanz
weil da die von Dir so forsch
hingeschriebene Variable T0 _auch_ eine Temperatur sein _muß_. Und dann
steht da für den zweiten Ausdruck genaugenommen
a = ln(T)+ ln (<Tempertur>) - ln(T0)- ln (<Temperatur>),
Ich glaube, da bricht die Mathe ein bisschen zusammen - Funktionen wie
der Logarithmus von einheitenbehafteten Größen sind nicht sinnvoll
definierbar, vor allem wegen der Umwandelbarkeit der Temperaturen.

Ist trotzdem ein Problem, wie man mit dem unbestimmten Integral
int 1/T dT umgeht. Laut Mathebuch steht dann als Lösung ln(T)
+ C. Geht natürlich nicht, also ziehen wir mal kurz das C in
den Logarithmus rein und machen ein ln(T/C1) draus.

Oder wir verneinen mal eben die Existenz von unbestimmten Integralen
(was aber auch irgendwo blöd wäre, Aufsummieren ist ja kein
Problem, der Grenzwert auch nicht, und Ableiten ist ja auch
zwanglos zu definieren) und lassen nur bestimmte Integrale zu,
nämlich int_T1^T2 1/T dT. Auch da bekommt man erstmal ln(T1)
- ln(T2) raus, was wir dann mit zugekniffenen Augen in ln(T1/T2)
verwandeln...
Sieghard Schicktanz
2017-02-07 22:09:13 UTC
Permalink
Hallo Thomas,
Post by Thomas Koenig
Post by Sieghard Schicktanz
stärker sehen würde als "nur" eine Multiplikation. Für die Anwendung
^^^^^^^^^^^^^^^^^
Post by Thomas Koenig
Post by Sieghard Schicktanz
sind die beiden _untrennbar_ verbunden, obwohl sie in gewisser Weise
separat verrechnet werden können.
Einheit und Maßzahl sind eben _nicht_ untrennbar miteinander
S.o.
Post by Thomas Koenig
verbunden. Wenn ich 10 cm gemessen haben, dann ist das völlig
äquivalent zu 0.1 m (modulo Meßschranken etc.). Eine
Natürlich, ist ja auch derselbe Wert: 0,1 = 10c (= 10*0,01).
Die _Einheit_ ist hier doch in beiden Fällen der "m", die modifizierenden
Vorsätze sind Teil der (Darstellung der) Maßzahl und zur Speicherung in
diese einzubeziehen ("constant folding").
Post by Thomas Koenig
Größe lässt sich nur mit Hilfe von Maßzahl und Einheit angeben,
aber die Maßzahl ist halt eben von der Einheit verbunden, und
ich kann die gleiche Größe mit Hilfe einer anderen Einheit
der gleichen Dimension angeben.
Sicher, aber das geht eben nur mittels _Um_rechnung, die "i.a." einen
anderen Wert für die Maßzahl liefert.
Post by Thomas Koenig
Und was die Verknüpfung angeht: "Multiplikation" ist das, was
man normalerweise dazu sagt, und es teilt einige Eigenschaften
mit der Multiplikation reeller Zahlen. Allerdings habe ich noch
keine Veröffentlichungen zu einem Axiomensystem für physikalische
Einheiten gesehen. Irgendwie mögen Mathematiker keine Einheiten,
oder sie halten sie für irrelevant oder trivial, sonst hätten
sie sich schon lange drangemacht.
Für Mathematiker ist das kein Thema, weil die schon lange ihr Verständnis
einer multiplikativen Verknüpfung weit über den Alltagsbegriff hinaus
erweitert haben. Die multiplizieren nicht nur Einheiten an Maßzahlen,
sondern auch Funktionen untereinander oder mit Matrizen, Distributionen mit
Mengen, Mengen untereinander u.v.m. Ist doch nix besonderes.
Post by Thomas Koenig
Das Bridgman-Axiom (Physilalische Zusammenhänge sind unabhängig vom
^k
Post by Thomas Koenig
verwendeten Einheitensystem) kommt dem noch am nächsten.
Ach, das hat sogar einen Namen? Ich habe das immer als Selbverständlichkeit
gesehen und gesagt bekommen.
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by Thomas Koenig
Post by Sieghard Schicktanz
Nachdem die _Dimensionen_ so etwas wie "Basisvektoren" eines Raumes
...
Post by Thomas Koenig
Klar, man kann Dimensionen als einen Vektorraum auffassen. Das hilft
auch ungemein bei der Dimensionsanalyse.
Als _etwas ähnliches wie_ einen Vektorraum. Ich würde mich hüten, darauf
die bekannten Operationen für solche ohne vorherige genaue Überprüfung
anzuwenden, schon angefangen mit der Basisrotation. Sie lassen aber
unterschiedliche Zusammensetzungen zu, die wieder als unabhängig
voneinander festgestellt werden können, was schon einer Basisrotation
nahe kommt.

...
Post by Thomas Koenig
Dynamische Einheiten? Nicht für hohe Anforderungen an Rechehenleistung,
bitte :-) Eine Variable einer Einheit zuzuordnen, macht schon Sinn.
Die Verarbeitung _intern_ muß ja die Einheiten nicht dynamisch verwalten,
es reicht dafür, wenn alle Eingangswerte _einmalig_ in ein einheitliches
System umgerechnet werden, mit dem dann weitergerechnet wird. Spezifische
Einheiten kommen erst wieder bei der Ausgabe ins Spiel, wo man natürlich
solche Angaben sehen will, die man gewohnt ist. (Ein weiterer Gesichtspunkt
ist natürlich auch, daß die Genaugkeit nicht mehr als unvermeidbar leiden
sollte.)
Post by Thomas Koenig
Post by Sieghard Schicktanz
Aber _das_ würd ich nicht machen. Hier soll die Variable ruhig den
Meßwert (25,12) haben, wenn sie die Einheit "Zoll" besitzt.
(25,12) heisst was?
Was als Beispiel drüber stand. Nein, das ist keine Spezialnotation, sondern
nur ein in Klammern geschriebener Wert.

...
Post by Thomas Koenig
Post by Sieghard Schicktanz
Das würde ich _so_ nicht machen.i In der Berechnung haben explizite
Einheiten bei den _Variablen_ nichts mehr verloren.
Wenn man explizit konvertieren möchte, brauch man dafür halt irgendeine
Syntax. Im Zweifelsfall tut es natürlich auch
Für eine reine _Berechnung_ muß hier nicht explizit konvertiert werden.
Eine expliziter Konvertierung muß doch nur bei der Aufbereitung zur
Ausgabe, d.h. dem Aufbau einer lesbaren _Darstellung_, des Variablenwertes
erfolgen.
Post by Thomas Koenig
Nur ist bei der impliziten Konvertierung erstmal unklar, wie die
ablaufen soll - rechts nach links, links nach rechts, oder alles
auf den Typ der linken Seite?
Implementationssache.
Post by Thomas Koenig
Post by Sieghard Schicktanz
[Konvertierungsfaktoren]
Man definiert eine Einheit als ein Vielfaches von einer anderen,
möglicherwiese auch mit Offset (für die Leute, die unbedingt °C
nehmen wollen...)
Ersteres ist eine Trivialität. Letzteres, ja, das ist ein recht spezieller
Fall - und sowas ist genaugenommen keine "Einheit" im physikalischen Sinn,
sondern eine Gradation(sskala). Da haben dann lediglich _Differenzen_
reguläre Einheiten, die Gradwerte sind nur unter bestimmten Bedingungen
verrechenbar.
Was ist z.B. das doppelte von 25°C? Soll das 50°C sein oder 323,15°C?

..
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by Thomas Koenig
nicht festgelegt werden. SI-Einheiten gehen für viele Probleme,
aber halt nicht für alle.
Für welche gehen sie nicht?
Häufig einfach unpraktisch. Aus numerischen Gründen sollten
viele Größen nicht allzu weit von 1 entfernt sein, und
wenn ein vernünftiges Einheitensystem für mein Problem aus
Elementarladung, Elektronenmasse, Vakuumlichtgeschwindigkeit,
Plancksches Wirkungsquantum, Boltzmann-Konstante besteht (wenn
das wirklich konsistent ist - habe ich nicht überprüft), dann
sollte ich das auch machen können.
Das heißt aber nicht, daß es nicht ginge, sondern daß es eben aus
praktischen, hier wohl im wesentlichen numerischen, Gründen ungünstig
sein kann. Da böte sich ein Skalierungsmechanismus an, der natürlich wieder
eine weitere Komplikation bedeutet. Oder an Anwendungsbereiche angepasste
Implementationen.
Post by Thomas Koenig
Physiker gehen ja gerne lax mit Einheiten um - "Die
Lichtgeschwindigkeit ist eins" - das sollte man auch als Einheiten
formulieren können :-)
Das sind die sog. "natürlichen" Einheiten - das bedeutet hier keineswegs,
daß die Lichtgeschwindigkeit dann eine dimensionslose Zahl wäre, sondern
lediglich, daß _alle_ Geschwindigkeiten in Vielfachen (oder Teilen) davon
ausgedrückt werden. Auch dann, wenn das darauffolgend nicht mehr explizit
erwähnt wird. Und wenn das der Autor dann irgendwann durcheinanderbringt,
hat er einen schwerwiegenden Fehler und seine Arbeit nutzlos gemacht.

...
[Reynolds-Zahl berechnen]
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by Thomas Koenig
Implizite oder explizite Umwandlung? In welchen Einheiten sollte
bei einer expliziten Umrechnung gerechnet werden?
Egal, die müssen intern nur konsistent benutzt werden.
Das muss richtg rauskommen, aber man muss schon festlegen, wie man
das haben will :-)
Das ist wieder eine Implementationssache . _wenn_ es richtig gemacht wurde,
dann _kommt_ das richtige heraus.

...
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by Thomas Koenig
Ach ja, und dann gibt es noch die Leute, die gerne die Formel
a = ln(T/T0)
schreiben als
a = ln(T) - ln(T0)
Eeeeigentlich richtig, aber nicht mehr so ganz, wenn T eine Temperatur ist...
Nee, das ist ganz prinzipiell falsch,
Erzähl einem Mathematiker, dass ln(T/T0) = ln(T) - ln(T0) nicht mehr
gilt, der wird dich verständnislos anschauen :-)
Da hast Du mich falsch verstanden - _falsch_ ist hier nicht die Separation
der Terme, sondern Deine Darstellung der Bedeutung.
Post by Thomas Koenig
Und ja, ich habe auch schon (in Vorlesungen) Dozenten darauf
hingewiesen, dass das so nicht geht.
Nicht ohne Berücksichtigung der Einheiten - und in Vorlesungen sollte
unbedingt darauf hingewiesen werden, daß hier diese Terme auftreten, auch
wenn sie sich am Ende wegheben.
Post by Thomas Koenig
Post by Sieghard Schicktanz
weil da die von Dir so forsch
hingeschriebene Variable T0 _auch_ eine Temperatur sein _muß_. Und dann
steht da für den zweiten Ausdruck genaugenommen
a = ln(T)+ ln (<Tempertur>) - ln(T0)- ln (<Temperatur>),
Ich glaube, da bricht die Mathe ein bisschen zusammen - Funktionen wie
der Logarithmus von einheitenbehafteten Größen sind nicht sinnvoll
definierbar, vor allem wegen der Umwandelbarkeit der Temperaturen.
Nene, da bricht mathematisch garnichts zusammen. Das sind "einfach"
Operationen auf einem erweiterten Definitionsbereich, der auch Nicht-
Zahlen umfasst, die zwar nicht mit regulären Zahlen oder untereinander
verrechnet werden können, die aber die "Primitivrelationen" der
Rechenoperationen (x - x = 0, x / x = 1, u.ä.) erfüllen.
Post by Thomas Koenig
Ist trotzdem ein Problem, wie man mit dem unbestimmten Integral
int 1/T dT umgeht. Laut Mathebuch steht dann als Lösung ln(T)
+ C. Geht natürlich nicht, also ziehen wir mal kurz das C in
den Logarithmus rein und machen ein ln(T/C1) draus.
Ja, und was sagt das dann aus? Das ist dann immer noch ein _unbestimmter_
Wert der Konstanten - um da was (physikalisch, numerisch) sinnvolles draus
zu machen, muß ein Kriterium her, das die Konstante zu bestimmen gestattet.
Am einfachsten setzt man die dann gerne zu 0...
Post by Thomas Koenig
Oder wir verneinen mal eben die Existenz von unbestimmten Integralen
Wie berechnest Du _numerisch_ ein solches eigentlich? Würde mich
interessieren...
Geht das nicht ein kleines Stückchen über das hier angestrebte Ziel hinaus?
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Thomas Koenig
2017-02-08 20:50:25 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Thomas,
Post by Thomas Koenig
Post by Sieghard Schicktanz
stärker sehen würde als "nur" eine Multiplikation. Für die Anwendung
^^^^^^^^^^^^^^^^^
Post by Thomas Koenig
Post by Sieghard Schicktanz
sind die beiden _untrennbar_ verbunden, obwohl sie in gewisser Weise
separat verrechnet werden können.
Einheit und Maßzahl sind eben _nicht_ untrennbar miteinander
S.o.
Post by Thomas Koenig
verbunden. Wenn ich 10 cm gemessen haben, dann ist das völlig
äquivalent zu 0.1 m (modulo Meßschranken etc.). Eine
Natürlich, ist ja auch derselbe Wert: 0,1 = 10c (= 10*0,01).
Die _Einheit_ ist hier doch in beiden Fällen der "m",
Das ist ein grundlegendes Missverständnis.

Es gibt zunächst einmal nichts, was eine spezielle Maßinheit
vor einer anderen auszeichnet. "cm" ist genauso valide wie "m";
im CGS-System ist cm sogar eine Grundeinheit.

Man kann die Einheiten ineinander umrechnen, und für viele
Anwendungen ist es auch sinnvoll, die SI-Einheiten zu verwenden.
Es ist aber genauso valide, mit cm zu rechnen, und zwar sowohl
auf einem Blatt Papier als auch mit einem Computer.
Post by Sieghard Schicktanz
Post by Thomas Koenig
Und was die Verknüpfung angeht: "Multiplikation" ist das, was
man normalerweise dazu sagt, und es teilt einige Eigenschaften
mit der Multiplikation reeller Zahlen. Allerdings habe ich noch
keine Veröffentlichungen zu einem Axiomensystem für physikalische
Einheiten gesehen. Irgendwie mögen Mathematiker keine Einheiten,
oder sie halten sie für irrelevant oder trivial, sonst hätten
sie sich schon lange drangemacht.
Für Mathematiker ist das kein Thema, weil die schon lange ihr Verständnis
einer multiplikativen Verknüpfung weit über den Alltagsbegriff hinaus
erweitert haben. Die multiplizieren nicht nur Einheiten an Maßzahlen,
sondern auch Funktionen untereinander oder mit Matrizen, Distributionen mit
Mengen, Mengen untereinander u.v.m. Ist doch nix besonderes.
Bloss die physikalischen Einheiten scheinen nicht so zu interessieren
:-)

Falls du doch was entsprechendes kennst, würde mich das sehr interessieren.
Post by Sieghard Schicktanz
Post by Thomas Koenig
Das Bridgman-Axiom (Physilalische Zusammenhänge sind unabhängig vom
^k
Post by Thomas Koenig
verwendeten Einheitensystem) kommt dem noch am nächsten.
Ach, das hat sogar einen Namen? Ich habe das immer als Selbverständlichkeit
gesehen und gesagt bekommen.
Der Name scheint weniger weit verbreitet zu sein, als ich dachte. Ich
habe es damals in der Dimensionsanalyse-Vorlesung unter diesem Namen
kennengelernt.

Das klingt trivial, hat aber einschneidende Konsequenzen über das, wie
physikalische Gesetze aussehen können - das Buckingham-Theorem folgt
daraus.
Post by Sieghard Schicktanz
Post by Thomas Koenig
Dynamische Einheiten? Nicht für hohe Anforderungen an Rechehenleistung,
bitte :-) Eine Variable einer Einheit zuzuordnen, macht schon Sinn.
Die Verarbeitung _intern_ muß ja die Einheiten nicht dynamisch verwalten,
es reicht dafür, wenn alle Eingangswerte _einmalig_ in ein einheitliches
System umgerechnet werden, mit dem dann weitergerechnet wird.
Den Ansatz kann man natürlich machen, aber ich halte ihn nicht für
gut. IMHO sollten Einheiten das abbilden, was die Physik uns sagt,
und da sind Einheiten beliebig.

Es gibt nichts, was im Universum die SI-Einheiten irgendwie bevorzugt
:-)



Ach so...
Post by Sieghard Schicktanz
Was ist z.B. das doppelte von 25°C? Soll das 50°C sein oder 323,15°C?
Natürlich die das zweite, sonst wird das spätestens mit dem idealen
Gasgesetz problematisch :-)
Post by Sieghard Schicktanz
Post by Thomas Koenig
Post by Sieghard Schicktanz
Für welche gehen sie nicht?
Häufig einfach unpraktisch. Aus numerischen Gründen sollten
viele Größen nicht allzu weit von 1 entfernt sein, und
wenn ein vernünftiges Einheitensystem für mein Problem aus
Elementarladung, Elektronenmasse, Vakuumlichtgeschwindigkeit,
Plancksches Wirkungsquantum, Boltzmann-Konstante besteht (wenn
das wirklich konsistent ist - habe ich nicht überprüft), dann
sollte ich das auch machen können.
Das heißt aber nicht, daß es nicht ginge, sondern daß es eben aus
praktischen, hier wohl im wesentlichen numerischen, Gründen ungünstig
sein kann.
Eine der praktischen Gründe ist, dass der Benutzer (und der Entwickler)
des Programms mit dem Einheitensystem klarkommen muss. "Geht nicht"
und "Will keiner" sind da Begriffe, die ineinander übergehen :-)
Post by Sieghard Schicktanz
Post by Thomas Koenig
Physiker gehen ja gerne lax mit Einheiten um - "Die
Lichtgeschwindigkeit ist eins" - das sollte man auch als Einheiten
formulieren können :-)
Das sind die sog. "natürlichen" Einheiten - das bedeutet hier keineswegs,
daß die Lichtgeschwindigkeit dann eine dimensionslose Zahl wäre, sondern
lediglich, daß _alle_ Geschwindigkeiten in Vielfachen (oder Teilen) davon
ausgedrückt werden. Auch dann, wenn das darauffolgend nicht mehr explizit
erwähnt wird. Und wenn das der Autor dann irgendwann durcheinanderbringt,
hat er einen schwerwiegenden Fehler und seine Arbeit nutzlos gemacht.
Ist, glaube ich, ziemlich üblich. Ich bin aber kein Physiker.
Post by Sieghard Schicktanz
[Reynolds-Zahl berechnen]
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by Thomas Koenig
Implizite oder explizite Umwandlung? In welchen Einheiten sollte
bei einer expliziten Umrechnung gerechnet werden?
Egal, die müssen intern nur konsistent benutzt werden.
Das muss richtg rauskommen, aber man muss schon festlegen, wie man
das haben will :-)
Das ist wieder eine Implementationssache . _wenn_ es richtig gemacht wurde,
dann _kommt_ das richtige heraus.
Ja. Und die Frage ist, was in einer Programmiersprache richtig ist
und wie man das vernünftigerweise implementiert
Post by Sieghard Schicktanz
...
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by Thomas Koenig
Ach ja, und dann gibt es noch die Leute, die gerne die Formel
a = ln(T/T0)
schreiben als
a = ln(T) - ln(T0)
Eeeeigentlich richtig, aber nicht mehr so ganz, wenn T eine Temperatur ist...
Nee, das ist ganz prinzipiell falsch,
Erzähl einem Mathematiker, dass ln(T/T0) = ln(T) - ln(T0) nicht mehr
gilt, der wird dich verständnislos anschauen :-)
Da hast Du mich falsch verstanden - _falsch_ ist hier nicht die Separation
der Terme, sondern Deine Darstellung der Bedeutung.
Inwiefern?
Post by Sieghard Schicktanz
Post by Thomas Koenig
Und ja, ich habe auch schon (in Vorlesungen) Dozenten darauf
hingewiesen, dass das so nicht geht.
Nicht ohne Berücksichtigung der Einheiten - und in Vorlesungen sollte
unbedingt darauf hingewiesen werden, daß hier diese Terme auftreten, auch
wenn sie sich am Ende wegheben.
Wie gesagt, der Müll wurde auch von Dozenten verbreitet, trotz lebhaftem
Protest von Studenten.
Post by Sieghard Schicktanz
Post by Thomas Koenig
Post by Sieghard Schicktanz
weil da die von Dir so forsch
hingeschriebene Variable T0 _auch_ eine Temperatur sein _muß_. Und dann
steht da für den zweiten Ausdruck genaugenommen
a = ln(T)+ ln (<Tempertur>) - ln(T0)- ln (<Temperatur>),
Ich glaube, da bricht die Mathe ein bisschen zusammen - Funktionen wie
der Logarithmus von einheitenbehafteten Größen sind nicht sinnvoll
definierbar, vor allem wegen der Umwandelbarkeit der Temperaturen.
Nene, da bricht mathematisch garnichts zusammen. Das sind "einfach"
Operationen auf einem erweiterten Definitionsbereich, der auch Nicht-
Zahlen umfasst, die zwar nicht mit regulären Zahlen oder untereinander
verrechnet werden können, die aber die "Primitivrelationen" der
Rechenoperationen (x - x = 0, x / x = 1, u.ä.) erfüllen.
Korrekt. und da sind wir wieder bei der mangelnden Axiomatisierung
von Einheiten. Wir rechnen munter damit, wir rechnen auch mit
Ableitungen nach dimensionsbehafteten Größen (Ableitung nach der Zeit).
Und dann steht da z.B. bei der Ableitung von A*sin(omega*t) plötzlich
das omega davor, als A*omega*sin(omega*t). Anwendung der Kettenregel,
klare Sache, aber trotzdem...
Post by Sieghard Schicktanz
Post by Thomas Koenig
Ist trotzdem ein Problem, wie man mit dem unbestimmten Integral
int 1/T dT umgeht. Laut Mathebuch steht dann als Lösung ln(T)
+ C. Geht natürlich nicht, also ziehen wir mal kurz das C in
den Logarithmus rein und machen ein ln(T/C1) draus.
Ja, und was sagt das dann aus? Das ist dann immer noch ein _unbestimmter_
Wert der Konstanten - um da was (physikalisch, numerisch) sinnvolles draus
zu machen, muß ein Kriterium her, das die Konstante zu bestimmen gestattet.
Am einfachsten setzt man die dann gerne zu 0...
und dann bekommt man bei Temperturen gleich mal ein Problem. Und
Integrale über 1/T kommmen z.B. in der Thermodynamik ziemlich
häufig vor :-)
Post by Sieghard Schicktanz
Post by Thomas Koenig
Oder wir verneinen mal eben die Existenz von unbestimmten Integralen
Wie berechnest Du _numerisch_ ein solches eigentlich? Würde mich
interessieren...
*grins*
Post by Sieghard Schicktanz
Geht das nicht ein kleines Stückchen über das hier angestrebte Ziel hinaus?
Mag sein, dass auch der eine oder andere Randbereich gestreift wird.
G.B.
2017-02-09 07:41:32 UTC
Permalink
Post by Thomas Koenig
Post by Sieghard Schicktanz
...
Post by Thomas Koenig
Post by Sieghard Schicktanz
Post by Thomas Koenig
Ach ja, und dann gibt es noch die Leute, die gerne die Formel
a = ln(T/T0)
schreiben als
a = ln(T) - ln(T0)
Eeeeigentlich richtig, aber nicht mehr so ganz, wenn T eine Temperatur ist...
Nee, das ist ganz prinzipiell falsch,
Erzähl einem Mathematiker, dass ln(T/T0) = ln(T) - ln(T0) nicht mehr
gilt, der wird dich verständnislos anschauen :-)
Da hast Du mich falsch verstanden - _falsch_ ist hier nicht die Separation
der Terme, sondern Deine Darstellung der Bedeutung.
Inwiefern?
Post by Sieghard Schicktanz
Post by Thomas Koenig
Und ja, ich habe auch schon (in Vorlesungen) Dozenten darauf
hingewiesen, dass das so nicht geht.
Nicht ohne Berücksichtigung der Einheiten - und in Vorlesungen sollte
unbedingt darauf hingewiesen werden, daß hier diese Terme auftreten, auch
wenn sie sich am Ende wegheben.
Wie gesagt, der Müll wurde auch von Dozenten verbreitet, trotz lebhaftem
Protest von Studenten.
Vermutlich ist den Mathematikern der Zugang dann eröffnet,
wenn sie Definitionen der Rechenregeln für Größen wie
Temperatur (Wert, Einheitdings) gezeigt bekommen.
Beweise von Schlüssigkeit und Eigenschaften daran angeschlossen.
Z.B. eine mathematische Struktur in der ln und / für
Tupel definiert sind, für Operanden mit Bestandteilen
Zahlwert und nähere Bestimmung.
Überzeugen wird, wenn das selbe Dokument den Sinn demonstriert.
Wie z.B. in industrieller und in wissenschaftlicher Anwendung
bessere, weil leichter deut- und prüfbare Ergebnisse entstehen,
die an jeder Stelle der Rechnung zeigen, welche Qualität einer
Quantität da verrechnet werden soll, und welche Operatoren
daher korrekterweise in Frage kommen. Das wird dann ein
mathematisches Heimspiel, also eher akzeptabel.
G.B.
2017-02-05 08:48:31 UTC
Permalink
Post by Sieghard Schicktanz
Post by G.B.
(1) Die Dimensionen wie Länge oder Zeit sind als universelle Begriffe
Ok, wobei es als _universelle_ "Begriffe" da eigentlich außer den beiden
nur noch Masse und (elektrische) Ladung zusätzlich gibt.
Das Universum (des Diskurses) soll sich hier mal über das ausdehnen,
was sich in technischen Steuerungen, oder auch in Programmen der
Buchhaltung findet.
Post by Sieghard Schicktanz
Post by G.B.
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.
Nein, falsch.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?

Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst

17 Knoten -> Geschwindigkeit und nichts sonst
8.7456 m/s -> Geschwindigkeit und nichts sonst

(NB Die Einheiten sollen in den Algorithmen idealerweise verschwinden:
wenn diese mit Gewicht rechnen, sollte es höchstens auf die darstellbare
Wertemenge, die Genauigkeit ankommen. Hier ist aber nichts neues.)

Es liegt IT-statistisch nahe, dass "Normalbedingungen auf der Erde" für
viele Anwendungen eines aufgebohrten Typsystems hinreichenden Mehrwert bieten.
Dabei nehme ich als unwahrscheinlich an, dass ein LKW in 12000 Meter über NN
fährt und ein dimensionierter Typ diese Bedingungen berücksichtigen muss.
Formal zwingen ist das vermutlich nicht, macht dimensionierte Typen aber
vielleicht praktikabler.

Als Begriffe sind tatsächlich Gewicht und Geschwindigkeit angesetzt.
Damit bekommen Variable im Anwendungsprogramm eine sinnvolle Typisierung.
Beispiel: Geschwindigkeit einer Laufkatze relativ zum Ausleger eines Krans:
0.8 m/s, enthaltend genau eine Zahl und genau eine implizierte Dimension,
obwohl also der Name der Dimension über den von Einheiten angegeben ist.

Du schreibst im weiteren Verlauf, wie sich die Identität der Dimension
von Größen der Physik durch Bezugnahme auf ein Basissystem implementieren
lässt, wodurch Anschlussfähigkeit entsteht.
Post by Sieghard Schicktanz
Post by G.B.
Ein Inch ist ebenso wie ein Millimeter eine Länge und nichts sonst,
Ein "Inch" ist ein _Maß_ für eine Länge, nicht die Länge selber.
Soviel Genauigkeit sollte in der Tat sein.
Post by Sieghard Schicktanz
Post by G.B.
(2) Man möchte, dass Größen nicht verwechselt werden können.
Das leisten Einheiten, gleich welche. Niemand sollte wirklich
Nein, das leisten EInheiten _nicht_. Einheiten für eine bestimmte Dimension
sind beliebig ineinander konvertierbar, wie z.B. 1 Zoll = 2,54cm.
Zoll wie auch cm bestimmen als ihre Dimension die Länge. Das ist die
gemeinte Leistung.
Post by Sieghard Schicktanz
Nachdem die _Dimensionen_ so etwas wie "Basisvektoren" eines Raumes
sind, d.h. linear unabhängig untereinander, _können_ - physikalisch -
Größen unterschiedlicher Dimension nicht ineinander überführt werden.
Die "orthogonale Basis" meine ich, wenn die Dimension von Größen nicht
verwechselbar sein sollen, weil sie, wie jetzt in Programmtexten häufig
der Fall, einfach nur als Zahl ausgedrückt werden.
Post by Sieghard Schicktanz
Falsch. Gerade die elektrische Spannung ist eigentlich eine _abgeleitete_
Einheit,
Eigentlich ist "Spannung" eine Bezeichnung für ein physikalisches Phänomen.

Das Wort wird in elektrotechnischen Anwendungen als bekannt vorausgesetzt.
Man rechnet mit Werten, die nicht erst auf kg, m, s zurückgeführt werden,
muss sich aber darauf verlassen, dass nicht jemand den Wert der anliegenden
Spannung in Variable_X speichern will, tatsächlich aber den Wert eines
Widerstandes dort zuweist, weil beide die gleiche Repräsentation haben
(Zahl) und der compiler an der falschen Zuweisung nichts aussetzen kann.

Bezugnahmen auf Masse, Weg, Zeit fallen unter das, was ein konsistentes,
aufgebohrtes Typsystem leisten können muss, aber Programmierer sollten einfach
ausdrücken können, dass da soundsoviel Spannung anliegt, und nicht
ausdrücken müssen, dass da soundsoviel Irgendwas anliegt, was im Programmplan,
in der Einheitenbürokratie, oder in physikalischer Energieäquivalenztheorie
als gemessene Spannung umgedeutet werden kann.

Entscheidend ist aber die Dimension der Einheit, nicht die Einheit.
Post by Sieghard Schicktanz
Wesentlich ist hier die Verbindung zu den eingehenden Basis-Dimensionen.
Bei einer Implementierung könnte dann für die Repräsentation einer (Grund-)
Einheit jeweils ein Maßstabsfaktor bei der Repräsentation der Dimension
registriert sein, womit die Gesamtheit der Konvertierungsfaktoren beliebige
Kombinationen von Einheiten und implizite Umrechungen zuließe.
Zum Beispiel.
Sieghard Schicktanz
2017-02-06 00:57:44 UTC
Permalink
Hallo G.B.,
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
(1) Die Dimensionen wie Länge oder Zeit sind als universelle Begriffe
...
Post by G.B.
Das Universum (des Diskurses) soll sich hier mal über das ausdehnen,
was sich in technischen Steuerungen, oder auch in Programmen der
Buchhaltung findet.
Kannst Du machen, aber da kommst Du dann mit Gödel in Konflikt...
(Ein Aximensystem kann nur entweder vollständig oder widerspruchsfrei sein.
"Buchhaltung" ist nicht widerspruchsfrei.)
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.
Nein, falsch.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Geschwindigkeit? Druck? Leistung?
Post by G.B.
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Ortsgeschwindigkeit 50 km/h -> Länge pro Zeiteinheit
Reifendruck 27 N/m² -> Kraft pro Länge im Quadrat
Motorleistung 87 kJ/h -> Arbeit pro Zeit
Post by G.B.
17 Knoten -> Geschwindigkeit und nichts sonst
8.7456 m/s -> Geschwindigkeit und nichts sonst
Und damit fällst Du gleich in das tiefe Loch der abgeleiteten bzw.
zusammengesetzten Einheiten. Wie berechnest Du aus einer Geschwindigkeit
und einer Zeit die zurückgelegte Strecke? Ist dann die Strecke für Dich
eine aus Geschwindigkeit und Zeit zusammengesetzte Einheit? Die ist doch
aber auch eine einfache Länge?
Post by G.B.
wenn diese mit Gewicht rechnen, sollte es höchstens auf die darstellbare
Wertemenge, die Genauigkeit ankommen. Hier ist aber nichts neues.)
Zur Sicherung der Konsistenz der berechneten Werte wäre es durchaus nicht
schädlich, die Einheiten mitzuverrechnen. Kommt dann am Ende statt z.B. ein
Gewicht ein Druck heraus, muß wohl was am "Algorithmus" oder mit den
Eingangswerten nicht stimmen.
Post by G.B.
Es liegt IT-statistisch nahe, dass "Normalbedingungen auf der Erde" für
viele Anwendungen eines aufgebohrten Typsystems hinreichenden Mehrwert
Was hat das mit der Darstellung von Einheiten zu tun?

...
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
(2) Man möchte, dass Größen nicht verwechselt werden können.
Das leisten Einheiten, gleich welche. Niemand sollte wirklich
Nein, das leisten EInheiten _nicht_. Einheiten für eine bestimmte
Dimension sind beliebig ineinander konvertierbar, wie z.B. 1 Zoll =
2,54cm.
Zoll wie auch cm bestimmen als ihre Dimension die Länge. Das ist die
gemeinte Leistung.
Soweit richtig, aber die jeweiligen Werte sind nicht unabhängig
voneinander, sollen sie dieselbe "Länge" (hier benutzt für die Instanz,
nicht für die allgemeine Dimension) darstellen.
Post by G.B.
Post by Sieghard Schicktanz
Nachdem die _Dimensionen_ so etwas wie "Basisvektoren" eines Raumes
...
Post by G.B.
Die "orthogonale Basis" meine ich, wenn die Dimension von Größen nicht
verwechselbar sein sollen, weil sie, wie jetzt in Programmtexten häufig
der Fall, einfach nur als Zahl ausgedrückt werden.
Das widerspricht aber Deiner oben angeführten Darstellung zu "Gewicht" und
"Geschwindigkeit" - eine _Basis_ eines Raumes ist auch dadurch
gekennzeichnet, daß die Anzahl ihrer Mitglieder minimal ist.
Post by G.B.
Post by Sieghard Schicktanz
Falsch. Gerade die elektrische Spannung ist eigentlich eine
_abgeleitete_ Einheit,
Eigentlich ist "Spannung" eine Bezeichnung für ein physikalisches Phänomen.
Exakt ausgedrückt richtig. Mit "die elektrische Spannung" war genau gemeint
"die _Einheit_ der elektrischen Spannung".
Post by G.B.
Entscheidend ist aber die Dimension der Einheit, nicht die Einheit.
Entscheidend ist die _Zusammensetzung_ der Dimension der Einheit aus den
verwendeten Basis-Dimensionen. Die Einheit selber hat Einfluß auf den
_Wert_ - den _Maß_/_Meß_wert - für die jeweilige Größe.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
G.B.
2017-02-06 09:29:43 UTC
Permalink
Post by Sieghard Schicktanz
Hallo G.B.,
Post by G.B.
Post by G.B.
(1) Die Dimensionen wie Länge oder Zeit sind als universelle Begriffe
...
Post by G.B.
Das Universum (des Diskurses) soll sich hier mal über das ausdehnen,
was sich in technischen Steuerungen, oder auch in Programmen der
Buchhaltung findet.
Kannst Du machen, aber da kommst Du dann mit Gödel in Konflikt...
Gerade durch die Einschränkung auf ziemlich endliche, nach Konstruktion
vom Übersetzer entscheidbare Typsysteme werden solche Interpretationsschwierigkeiten
umgangen.

(Wirtschaftliche Buchhaltung wird juristisch immer entschieden,
wenn Berechnungen das nicht können.)
Post by Sieghard Schicktanz
Post by G.B.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Geschwindigkeit? Druck? Leistung?
? der Text "m/s" kann für _eine_ Dimension im Typsystem stehen
(oder _drei_), für _eine_ Dimension im "phänomenologischen",
aber für _zwei_ Dimensionen in der Mechanik. Programme betreiben
aber i.d.R. keine Mechanik.

Wenn Programme einen Wert der Programm-definierten Dimenension
"Geschwindigkeit" aus programm-definiert Zeit-getypten
und programm-definiert Weg-getypten Operanden berechnen
können, und dann damit eine Wirkung wie Bremsen (also z.B.
negativ Beschleunigen) oder Beschleunigen (also z.B. negativ
Bremsen) auslösen, dann genügt das den Erfordernissen.
Post by Sieghard Schicktanz
Wie berechnest Du aus einer Geschwindigkeit
und einer Zeit die zurückgelegte Strecke?
Durch die Anwendung von – gemäß Typbestimmung – geeignet
definierten Operatoren, mit den Operanden von dimensionierten
Typen für Geschwindigkeit und Zeit. Heraus kommt eine Länge.
Zusammengesetze Einheiten sind m.E. ein unnötiger Zusatz.
Post by Sieghard Schicktanz
Post by G.B.
Es liegt IT-statistisch nahe, dass "Normalbedingungen auf der Erde" für
viele Anwendungen eines aufgebohrten Typsystems hinreichenden Mehrwert
Was hat das mit der Darstellung von Einheiten zu tun?
Es stand nur im nachfolgenden Absatz.
Post by Sieghard Schicktanz
Post by G.B.
Zoll wie auch cm bestimmen als ihre Dimension die Länge. Das ist die
gemeinte Leistung.
Soweit richtig, aber die jeweiligen Werte sind nicht unabhängig
voneinander, sollen sie dieselbe "Länge" (hier benutzt für die Instanz,
nicht für die allgemeine Dimension) darstellen.
Sind denn Zoll und cm nicht unabhängig in der Lage, zum Ausdruck
eines und desselben Rohrdurchmessers zu dienen?
Post by Sieghard Schicktanz
eine _Basis_ eines Raumes ist auch dadurch
gekennzeichnet, daß die Anzahl ihrer Mitglieder minimal ist.
Ich meinte hier die in der IT übliche Sprechweise "orthogonal",
die mit Vektorräumen nicht wirklich etwas zu tun hat, sondern
bildlich und abkürzend über IT spricht.

Auch scheint mir für die Anwendbarkeit des Typsystems nicht vorteilhaft,
den Programmierern vorzuschreiben, was ein minimales Dimensionensystem
in ihrem Anwendungsfall zu sein hat. Solange das dimensionierte
und mit Einheiten versehene Ergebnis der Programme anschlussfähig ist.
Post by Sieghard Schicktanz
Post by G.B.
Entscheidend ist aber die Dimension der Einheit, nicht die Einheit.
Entscheidend ist die _Zusammensetzung_ der Dimension der Einheit aus den
verwendeten Basis-Dimensionen. Die Einheit selber hat Einfluß auf den
_Wert_ - den _Maß_/_Meß_wert - für die jeweilige Größe.
Messwerte kommen nur in Wandlern und Literalen vor, deren Einheiten
verschwinden können sollen, zugunsten nur dimensioniert getypter
Größen. Für welche Operationen braucht es da eine Zusammensetzung von
Dimensionen aus Basis-Dimensionen?
Sieghard Schicktanz
2017-02-07 00:20:59 UTC
Permalink
Hallo G.B.,
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Geschwindigkeit? Druck? Leistung?
...
Post by G.B.
Wenn Programme einen Wert der Programm-definierten Dimenension
"Geschwindigkeit" aus programm-definiert Zeit-getypten
und programm-definiert Weg-getypten Operanden berechnen
können, und dann damit eine Wirkung wie Bremsen (also z.B.
negativ Beschleunigen) oder Beschleunigen (also z.B. negativ
Bremsen) auslösen, dann genügt das den Erfordernissen.
Und genau darum, wie sich sowas in einer Implementierung abbilden läßt,
geht es hier. _Wie_ ist zu erreichen, _daß_ es das den Erfordernissen
genügt?

...
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
Zoll wie auch cm bestimmen als ihre Dimension die Länge. Das ist die
gemeinte Leistung.
Soweit richtig, aber die jeweiligen Werte sind nicht unabhängig
...
Post by G.B.
Sind denn Zoll und cm nicht unabhängig in der Lage, zum Ausdruck
eines und desselben Rohrdurchmessers zu dienen?
Nein, sind sie nicht. Zwischen ihnen besteht immer das Verhältnis 2,54
(definiert!), soweit es sich un eine Repräsentation desselben Wertes, also
z.B. Deines Rohrdurchmessers, handelt.
Post by G.B.
Post by Sieghard Schicktanz
eine _Basis_ eines Raumes ist auch dadurch
gekennzeichnet, daß die Anzahl ihrer Mitglieder minimal ist.
Ich meinte hier die in der IT übliche Sprechweise "orthogonal",
die mit Vektorräumen nicht wirklich etwas zu tun hat, sondern
bildlich und abkürzend über IT spricht.
Der Begriff hat auch in der "IT" (ich bezweifle so langsam, daß das "I" in
der Bezeichnung angebracht ist) eine gewisse Vergleichbarkeit zu der in
anderen mathematischen Bereichen (wobei die "IT" ja kein solcher ist, das
wäre die Informatik). (Z.B. ist ein "orthogonaler Befehlssatz" ein,
möglichst minimaler, Befehlssatz, der durch Kombination der Befehlsfelder
alle möglichen (!) Konstellationen zum Programmaufbau zuläßt.)
Post by G.B.
Auch scheint mir für die Anwendbarkeit des Typsystems nicht vorteilhaft,
den Programmierern vorzuschreiben, was ein minimales Dimensionensystem
in ihrem Anwendungsfall zu sein hat. Solange das dimensionierte
und mit Einheiten versehene Ergebnis der Programme anschlussfähig ist.
Ja, auch dfarum geht es hier: nämlich um eine Methode, ein solches
Dimensionensystem - und das daran direkt angeschlossene Einheitensystem -
dme Programmierer _nicht_ aufzubürden, sondern dessen (deren) Behandlung
vollständig in die Sprachstruktur zu integrieren.
Post by G.B.
Messwerte kommen nur in Wandlern und Literalen vor, deren Einheiten
verschwinden können sollen, zugunsten nur dimensioniert getypter
Größen. Für welche Operationen braucht es da eine Zusammensetzung von
Dimensionen aus Basis-Dimensionen?
Für _alle_. Es gibt auch Geräte, die bei falschen Berechnungen deren
Anwender gefährden können. Sowas kam bereits sogar in der Luft- und
Raumfahrt vor, wo doch eigentlich besonders sorgfältig auf diese Dinge
geachtet wird.
Bei Buchhaltungs- Software sind wenigstens nur die virtuellen Kontenstände
kaputt, aber sogar da kann der Schaden immens werden.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
G.B.
2017-02-06 21:53:34 UTC
Permalink
Post by Sieghard Schicktanz
Ortsgeschwindigkeit 50 km/h -> Länge pro Zeiteinheit
Reifendruck 27 N/m² -> Kraft pro Länge im Quadrat
Motorleistung 87 kJ/h -> Arbeit pro Zeit
Ich schließe hier nochmal an. Es scheint, dass die für den
Programmiergebrauch erforderliche Eindeutigkeit des Schlusses
vom Namen der Einheit auf die Dimension einer Größe vielfach
schon per SI gegeben sein kann:

Reifendruck: 27 Pascal
Motorleistung: 24 1/6 Watt

Dabei ist freilich nie ein Anwendungsfall ausgeschlossen, wie
der, dass ein Mathematiker etwas wie Rechenkunst oder
Zahlenspielwert in "Pascal" bemessen möchte, und darum mit
entsprechender Einheit versehene Größen im eigenen Programm
vorsieht. Es bleibt der Vorteil, dass es immerhin nicht einfach
Zahlen sind, wenn auch Verwechslungsgefahr besteht.
Thomas Koenig
2017-02-06 23:36:38 UTC
Permalink
Post by G.B.
Reifendruck: 27 Pascal
Den Reifen würde ich als ziemlich platt bezeichnen :-)
Juergen Ilse
2017-02-06 13:12:37 UTC
Permalink
Hallo,

Es ist ja grausam, was ihr hier vom Stapel lasst ...
Post by G.B.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Voelliger Quatsch. Die unabhaengige Eigenschaft ist nicht "das Gewicht"
sondern "die Masse", aus der sich dann zusammen mit den auf diese Masse
einwirkenden Beschleunigungen die auf diese Masse einwirkenden Kraefte
ergeben, wovon die "Schwerkraft" (die auf die Masse wirkende Schwerkraft
wird i.a. als "Gewicht" bezeichnet, nicht etwa die Masse selbst). Eigent-
lich muesste man noch zwischen "schwerer Masse" (auf die die Schwerkraft
wirkt) und "traeger Masse" (auf die die Traegheit wirkt) unterscheiden,
aber da bekanntlich "schwere Masse" und "traege Masse" proportional zu-
einander sind, kann man sie letztlich auch gleichsetzen. Das durchein-
anderwerfen der Begriffe "Masse" und "Gewicht" ist furchtbar und ein
fast sicheres Zeichen fuer Schlamperei beim Umgang mit den Einheiten.
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
Ein Inch ist ebenso wie ein Millimeter eine Länge und nichts sonst,
Ein "Inch" ist ein _Maß_ für eine Länge, nicht die Länge selber.
"Inch" ist die Einheit, "ein Inch" ist eine Groesse, in diesem Fall eine
Laenge (umgerechnet ca. 0.0254 m).
Uebrigens ist nach dem SI die "elementare Groesse" nicht etwa (wie manche
meinen) die Ladung, sondern die Stromstaerke. Die Ladung ist eine abgeleitete
Groesse (Stromstaerke mal Zeit).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
G.B.
2017-02-06 13:58:25 UTC
Permalink
Post by Juergen Ilse
Hallo,
Es ist ja grausam, was ihr hier vom Stapel lasst ...
Post by G.B.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Voelliger Quatsch. Die unabhaengige Eigenschaft ist nicht "das Gewicht"
sondern "die Masse", aus der sich dann zusammen mit den auf diese Masse
einwirkenden Beschleunigungen
... deswegen die Hinweise: auf "Normalbedingungen auf der Erde",
auf Phänomene (Arzt: "Wieviel Masse haben sie?" Patient: "Äh...")
und, wichtiger, nicht auf derzeitige Physik, sondern ITechnische Programme
mit ihren eigenen Anforderungen, die für das Typsystem maßgebend sein
sollen. Das Gewicht auf dem Mond spielt keine Rolle in einem Programm,
das eine Masse auf der Erde bewegen soll.

Das Typsystem soll ermöglichen, dimensionierte Größen auszudrücken.
Dazu braucht es keine Namen vorzugeben.
Post by Juergen Ilse
Die Ladung ist eine abgeleitete
Groesse (Stromstaerke mal Zeit).
Die Spannung.

Es gibt einen wissenschaftlichen Zusammenhang, in dem Ladung,
nicht die Spannung, diese abgeleitete Größe ist. Es gibt eine Welt,
in der die Platten eines Kondensators aufgeladen sind, nicht mit einem
Rechenprodukt vom Stromstärke und Zeit, sondern elektrisch.
Es gibt Programme, in denen an modellierten Objekten eine Spannung
anliegt und nichts sonst, gemessen zu dem Zeitpunkt.
Die Zusammenhänge aufzudröseln ist nicht Aufgabe des Typsystems,
aber den Programmierer die Zahlwerte dimensionieren zu lassen,
wäre das aus meiner Sicht schon.
Juergen Ilse
2017-02-07 07:56:32 UTC
Permalink
Hallo,
Post by G.B.
Post by Juergen Ilse
Es ist ja grausam, was ihr hier vom Stapel lasst ...
Post by G.B.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Voelliger Quatsch. Die unabhaengige Eigenschaft ist nicht "das Gewicht"
sondern "die Masse", aus der sich dann zusammen mit den auf diese Masse
einwirkenden Beschleunigungen
... deswegen die Hinweise: auf "Normalbedingungen auf der Erde",
Was die Sache nicht besser macht. "Gewicht" ist eine Kraft, Masse eine
Eigenschaft der Materie. Das sind zwei voellig unterschiedliche Dinge,
die man (im Interesse von klarer Formulierung) gefaelligst auch nicht
durcheinanderwerfen sollte (auch wenn das umgangssprachlich manchmal
getan wird).
Post by G.B.
Post by Juergen Ilse
Die Ladung ist eine abgeleitete
Groesse (Stromstaerke mal Zeit).
Die Spannung.
... ist auch eine abgeleitete Einheit, was aber nichts daran aendert, dass
Stromstaerke mal Zeit Ladung ergibt und keine Spannung.
Post by G.B.
Es gibt einen wissenschaftlichen Zusammenhang, in dem Ladung,
nicht die Spannung, diese abgeleitete Größe ist.
Im SI sind sowohl Ladung als auch Spannung abgeleitete Groessen, die
elementare physikalische Groesse ist die stromstaerke.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Sieghard Schicktanz
2017-02-07 00:34:16 UTC
Permalink
Hallo G.B.,
Post by G.B.
Post by Juergen Ilse
Voelliger Quatsch. Die unabhaengige Eigenschaft ist nicht "das Gewicht"
sondern "die Masse", aus der sich dann zusammen mit den auf diese Masse
einwirkenden Beschleunigungen
... deswegen die Hinweise: auf "Normalbedingungen auf der Erde",
auf Phänomene (Arzt: "Wieviel Masse haben sie?" Patient: "Äh...")
Augenwischerei. Berechne die mögliche Beschleunigung Deines Autos aus dessen
Motorleistung und Gewicht (ugs. "Gewicht").
Post by G.B.
Das Typsystem soll ermöglichen, dimensionierte Größen auszudrücken.
Dazu braucht es keine Namen vorzugeben.
Es muß "nur" die _physikalischen_ (allg. physischen und logoschen)
Zusammenhänge unter den miteinander unvereinbaren Dimensionen kennen.
Post by G.B.
Die Spannung.
Es gibt einen wissenschaftlichen Zusammenhang, in dem Ladung,
nicht die Spannung, diese abgeleitete Größe ist. Es gibt eine Welt,
in der die Platten eines Kondensators aufgeladen sind, nicht mit einem
Rechenprodukt vom Stromstärke und Zeit, sondern elektrisch.
Es gibt viel Möglichkeiten, die "Basisvektoren" des physikalischen
Dimensionenssystems darzustellen. Das sind aber mitnichten unterschiedliche
"Welten", sondern nur jeweils spezifischen "Sichten" (Betrachtungsweisen,
Standpunkte), unter denen ein Phänomen betrachtet bzw. untersucht oder
dargestellt wird.
Post by G.B.
Die Zusammenhänge aufzudröseln ist nicht Aufgabe des Typsystems,
Doch, genau darum geht es hier.
Post by G.B.
aber den Programmierer die Zahlwerte dimensionieren zu lassen,
wäre das aus meiner Sicht schon.
Und? "[D]en Programmierer die Zahlwerte dimensionieren zu lassen" geht doch
mit Objektprogrammierung sowieso - definier' Dir halt für jede Einheit, die
Du verwenden willst, ein solches und verpasse ihm die nötigen
Umrechnungsoperatoren für alle damit verknüpften anderen Einheiten.

Solange das nur mit so einem Wust aus Umrechnungsoperatoren für alle
möglichen Einheitenkombinationen machbar ist, wird das niemand benutzen
wollen. Irgendeine Umrechnung wird dann immer fehlen, und da die Konsistenz
sicherzustellen sehe ich als praktisch unmöglich.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
G.B.
2017-02-07 10:15:48 UTC
Permalink
Post by Sieghard Schicktanz
Post by G.B.
... deswegen die Hinweise: auf "Normalbedingungen auf der Erde",
auf Phänomene (Arzt: "Wieviel Masse haben sie?" Patient: "Äh...")
Augenwischerei. Berechne die mögliche Beschleunigung Deines Autos aus dessen
Motorleistung und Gewicht (ugs. "Gewicht").
Am Ende rücken in dieser Sackgasse noch Intertialsysteme und Physik
in den Vordergrund, statt Programme, die bezifferte Masse verwenden sollten,
und Programme, die beziffertes Gewicht verwenden dürfen, weil sie
keiner Umrechnung in das Anwendungsfeld der ersteren Programme (mit Masse)
bedürfen. Die Gewichtsprogramme könnten durchaus konsistent sein, wenn sie
einen body-weight-index ausrechneten. Aber wenn es der Sache dient,
verzichte ich auf mein Körpergewicht (in kg) zugunsten meiner Körpermasse
(in kg).
Post by Sieghard Schicktanz
Post by G.B.
Das Typsystem soll ermöglichen, dimensionierte Größen auszudrücken.
Dazu braucht es keine Namen vorzugeben.
Es muß "nur" die _physikalischen_ (allg. physischen und logoschen)
Zusammenhänge unter den miteinander unvereinbaren Dimensionen kennen.
Warum muss ein Typsystem mit Dimensionen etwas über außerformale
Zusammenhänge wissen? Dieses Wissen kann jemand anbieten, falls
die außerformalen Zusammenhänge für eine Anwendung passen.
boost::unit versucht sowas, soweit ich sehe, für Anwendungen,
denen mit der SI-Basis gedient ist. Der formale Zusammenhang ist
"einfach" die Auflösung von parametrisierten Templates durch den
compiler. Das SI ist dafür ohne spezifische Bedeutung, nur Anlass
für die Verwendung eines C++ features, das dafür so gemacht ist,
wie assembler-Instruktionen für OOP.
Post by Sieghard Schicktanz
Post by G.B.
Die Zusammenhänge aufzudröseln ist nicht Aufgabe des Typsystems,
Doch, genau darum geht es hier.
Es kann das gar nicht können, insofern Typsysteme Formalia sind,
deren inhaltliche Deutung und Anwendbarkeit sich aus der Anwendung,
nicht aus der Sprachdefinition ergeben. Zahlen legen gar nicht
fest, welche Bedeutung sie haben. (Benutzerdefinierte) Typen sind
"mechanisch" mit den sprachdefinierten Möglichkeiten verknüpft,
ihren Objekten "Verhalten" anzuprogrammieren. Dimensionen sollen
das beschränkt auf die Verknüpfungen von Werten leisten, zusätzlich.
So, dass eine Summe Geldes durch ihren anwendungsgemäß bestimmmten
und ausgedrückten Wert angegeben ist, durch Betrag, Währung, Datum usf.
wie es bspw. die jeweiligen Gesetze und Richtlinien zu Verdatung
von Geldbeträgen vorsehen. Wie sich das Geld sonst noch "verhalten"
kann, ist eine separate Frage.
Post by Sieghard Schicktanz
Post by G.B.
aber den Programmierer die Zahlwerte dimensionieren zu lassen,
wäre das aus meiner Sicht schon.
Und? "[D]en Programmierer die Zahlwerte dimensionieren zu lassen" geht doch
mit Objektprogrammierung sowieso - definier' Dir halt für jede Einheit, die
Du verwenden willst, ein solches und verpasse ihm die nötigen
Umrechnungsoperatoren für alle damit verknüpften anderen Einheiten.
Das Emulationsargument. Es gibt so keine sprachdefinierte,
spezifische Ausdrucksmöglichkeit. Es gibt nur entweder implizit und
fehleranfällig das Bisherige (Zahlen ohne Dimension), was aber explizit
und weniger fehleranfällig werden soll (Zahlen mit Dimension).
Oder es gibt die Umnutzung der unspezifischen Typdefinition für
einen spezifischen Zweck. Das verwischt und macht die Analyse
schwierig und fehleranfällig.
Peter J. Holzer
2017-02-06 16:34:11 UTC
Permalink
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.
Nein, falsch.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Kommt darauf an, wie eng man "Einheit" fasst.

Der Verbrauch eines KFZ wird meistens in l/100km angegeben. In
SI-Einheiten umgerechnet und normalisiert sind das m² - die gleiche
Einheit wie für die Fläche. m² könnte also sowohl für die Dimension
"Fläche" stehen als auch für die Dimension "Kraftstoffverbrauch".

Im der Luft- und Raumfahrt wird der spezifische Impuls gerne in Sekunden
angegeben. Das ist zwar strenggenommen ein Einheitenfehler, aber da Du
es mit der Unterscheidung von Masse und Gewicht auch nicht so genau
Post by G.B.
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
wird Dich das nicht stören (und die Angabe in Sekunden hat den Vorteil,
dass man im metrischen und US-System die gleiche Maßzahl erhält). Eine
Sekunde kann also für die Dimension Zeit stehen oder für die Dimension
"spezifischer Impuls".

Nur zwei Beispiele, die mir so einfallen, es gibt sicher noch bessere.

Und da reden wir immer noch von physikalischen Einheiten. Wenn man sich
in Alltagsgefilde begibt, wo man Einheiten wie "Personen", "Prozent"
oder "Euro" hat, dann ist man von jeder Eindeutigkeit weit entfernt.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-02-06 21:30:16 UTC
Permalink
Post by Peter J. Holzer
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.
Nein, falsch.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Kommt darauf an, wie eng man "Einheit" fasst.
Der Verbrauch eines KFZ wird meistens in l/100km angegeben. In
SI-Einheiten umgerechnet und normalisiert sind das m²
OK.
Da es gelingt, Treibstoff-Verbrauch und Quadratmeter der Bedeutung
nach zu trennen, kommt wohl das Durcheinander eher von dem Versuch,
die reichhaltig und kaum zweideutig gegebene Bestimmung des einen
Begriffs (Verbrauch je "Normstrecke") auf SI-Minimalismus runter zu
dampfen.

Das ist nicht nötig:
Bei einem Typsystem, das Namen für Typen verwendet und Birnen und
Äpfel auch auseinander hält, wenn sie gleich repräsentiert werden
– bei dimensionierten Zahlen erscheint mir das zunächst als eine nahe
liegende Wahl – sollte die eine Einheit dann tatsächlich "l/100km"
o.ä. heißen. Die Aufgabe für die Programmierung wird darin bestehen,
Operationen an den dimensionierten Typ zu binden, die dann von
Quadratmeter-Operationen unterschieden sind, weil eben der Typ
für die m² anders heißt. Auch da gibt es wohl schon etwas, mit und ohne
Dimensionen/Einheiten.

Ob es sinnvoll ist, den compiler eine Konsistenzprüfung in
SI-Basiseinheiten durchführen zu lassen? (Glaube ich erst mal
nicht, weil die Reichweite der Physik für die komplexeren
Alltagsgefilde der Programmierung nicht groß genug ist.)
Post by Peter J. Holzer
Im der Luft- und Raumfahrt wird der spezifische Impuls gerne in Sekunden
angegeben. Das ist zwar strenggenommen ein Einheitenfehler, aber da Du
es mit der Unterscheidung von Masse und Gewicht auch nicht so genau
Na ja, Wortbedeutung und daran geknüpfte Operationen werfen eben
Fragen der Bestimmung auf, die sich nur im Bezugsrahmen der zu lösenden
Programmieraufgabe sinnvoll beantworten lassen. Da käme bspw. noch die
(Bogen-)Sekunde für die Kugelkoordinaten hinzu.
Post by Peter J. Holzer
Und da reden wir immer noch von physikalischen Einheiten. Wenn man sich
in Alltagsgefilde begibt, wo man Einheiten wie "Personen", "Prozent"
oder "Euro" hat, dann ist man von jeder Eindeutigkeit weit entfernt.
Das gerade gibt den Programmierern die Möglichkeit, das zu tun,
was sie sonst auch tun, aber ausdrücklich: Zu definieren, was mit den
Dingen einer Dimension gemacht (wie operiert) werden kann, und
was sie wert sind.

Dann wird ein Programmierer, so die Hoffnung, kaum auf die Idee
kommen können, den Treibstoffverbrauch mit dem Eintrag für die
Quadratmeterzahl der Wohnung zu verrechnen, obschon die SI-Einheiten
diesen Irrtum zulassen würden: Ein compiler würde für diese
Verrechnung eine nach Typname und Dimension stimmige Operation suchen.
Peter J. Holzer
2017-02-07 08:35:43 UTC
Permalink
Post by G.B.
Post by Peter J. Holzer
Post by G.B.
Post by Sieghard Schicktanz
Post by G.B.
des technischen Betriebs definiert und ferner aus Einheiten,
gleich welchen, eineindeutig bestimmt.
Nein, falsch.
Welche Einheit bestimmt denn zwei verschiedene Dimensionen im o.g. Sinn?
Kommt darauf an, wie eng man "Einheit" fasst.
Der Verbrauch eines KFZ wird meistens in l/100km angegeben. In
SI-Einheiten umgerechnet und normalisiert sind das m²
OK.
Da es gelingt, Treibstoff-Verbrauch und Quadratmeter der Bedeutung
nach zu trennen, kommt wohl das Durcheinander eher von dem Versuch,
die reichhaltig und kaum zweideutig gegebene Bestimmung des einen
Begriffs (Verbrauch je "Normstrecke") auf SI-Minimalismus runter zu
dampfen.
Bei einem Typsystem, das Namen für Typen verwendet und Birnen und
Äpfel auch auseinander hält, wenn sie gleich repräsentiert werden
[...]
Post by G.B.
Das gerade gibt den Programmierern die Möglichkeit, das zu tun,
was sie sonst auch tun, aber ausdrücklich: Zu definieren, was mit den
Dingen einer Dimension gemacht (wie operiert) werden kann, und
was sie wert sind.
Und genau das erlauben existierende Programmiersprachen auch jetzt
schon. Soweit ich sehe, ist von Deiner ursprünglichen Forderung nach
einem auf Einheiten basierenden Typsystem eigentlich nichts mehr
übriggeblieben.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-02-07 09:17:43 UTC
Permalink
Post by Peter J. Holzer
Und genau das erlauben existierende Programmiersprachen auch jetzt
schon. Soweit ich sehe, ist von Deiner ursprünglichen Forderung nach
einem auf Einheiten basierenden Typsystem eigentlich nichts mehr
übriggeblieben.
Bitte, wie unterstützen die compiler für Sprachen wie C, Swift, Delphi,
C#, Java, JavaSript, Python ... eine solche dimensionierte Typvereinbarung
so, dass compiler die Werte und Objekte auch gemäß genau dieser dimensionierten
Typvereinbarung spezifisch überprüfen?

Außer Meta-C++-Anhängen wie boost::unit und GNAT-Ada fällt mir da
nichts ein.

Ist es wirklich einfach, in boost::unit Typen für Verbrauch-je-100km und
Wohnungsquadratmeter zu erzeugen, die Fehlverrechnungen verhindern?

Dann würde ich auch gern die Einfachheit sehen, mit der operator+ für
Temperaturen je nach Anwendungsfall erlaubt (Statistik) oder
unterbunden werden kann (°C im genannten Fall).
Peter J. Holzer
2017-02-09 21:00:32 UTC
Permalink
Post by G.B.
Post by Peter J. Holzer
Und genau das erlauben existierende Programmiersprachen auch jetzt
schon. Soweit ich sehe, ist von Deiner ursprünglichen Forderung nach
einem auf Einheiten basierenden Typsystem eigentlich nichts mehr
übriggeblieben.
Bitte, wie unterstützen die compiler für Sprachen wie C, Swift,
Delphi, C#, Java, JavaSript, Python ... eine solche dimensionierte
Typvereinbarung so, dass compiler die Werte und Objekte auch gemäß
genau dieser dimensionierten Typvereinbarung spezifisch überprüfen?
Nicht alle diese Sprachen tun das ("das erlauben existierende
Programmiersprachen auch jetzt schon" ist eine Existenzaussage, keine
Allaussage).

Meiner Meinung nach erfüllen alle Sprachen, die Typdefinitionen und
Operator-Overloading (oder zumindest polymorphe Funktionen)
unterstützen, Deine Forderung (oder was halt von Deinen etwas
widersprüchlichen Ideen als Kern übrigbleibt), also z.B. C# und Python,
nicht aber C oder JavaScript.
Post by G.B.
Außer Meta-C++-Anhängen wie boost::unit und GNAT-Ada fällt mir da
nichts ein.
Ist es wirklich einfach, in boost::unit Typen für Verbrauch-je-100km und
Wohnungsquadratmeter zu erzeugen, die Fehlverrechnungen verhindern?
Keine Ahnung, ich programmiere nicht in C++. Es geht aber ganz ohne
boost::unit, nur mit normalen Klassendefinitionen und
Operator-Overloading. Ist halt Tipparbeit, aber nur bei der Definition
der Klassen (irgendwo muss schon irgendwer mal festlegen, was passieren
soll, wenn man °C und °C addiert, oder Fuß mit Metern multipliziert).

Hier mal eine kleine Skizze in Python, wie sowas für Temperaturen in
verschiedenen Skalen aussehen könnte:

--[units.py]-----------------------------------------------------------
class TemperatureInCelsius:
def __init__(self, value):
self.value = value

def __str__(self):
return "%f °C" % self.value

def __sub__(self, other):
if isinstance(other, TemperatureInCelsius):
return TemperatureDifferenceInCelsius(self.value - other.value)
else:
return self - TemperatureInCelsius(other)

class TemperatureInFahrenheit:
def __init__(self, value):
if isinstance(value, float):
self.value = value
elif isinstance(value, int):
self.value = value
elif isinstance(value, TemperatureInCelsius):
self.value = value.value * 9 / 5 + 32
else:
raise TypeError

def __str__(self):
return "%f °F" % self.value

def __add__(self, other):
if isinstance(other, TemperatureDifferenceInCelsius):
return TemperatureInFahrenheit(self.value + other.value * 9 / 5)
else:
raise TypeError

class TemperatureDifferenceInCelsius:
def __init__(self, value):
self.value = value

def __str__(self):
return "%f °C(Δ)" % self.value
------------------------------------------------------------------------

Python 3.4.2 (default, Oct 8 2014, 13:14:40)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
Post by G.B.
Post by Peter J. Holzer
from units import TemperatureInCelsius, TemperatureInFahrenheit
room_temperature_in_celsius = TemperatureInCelsius(20)
print(room_temperature_in_celsius)
20.000000 °C
Post by G.B.
Post by Peter J. Holzer
room_temperature_not_in_fahrenheit = room_temperature_in_celsius
print(room_temperature_not_in_fahrenheit)
20.000000 °C
Post by G.B.
Post by Peter J. Holzer
room_temperature_in_fahrenheit = TemperatureInFahrenheit(room_temperature_in_celsius)
print(room_temperature_in_fahrenheit) # prints 68 °F
68.000000 °F
Post by G.B.
Post by Peter J. Holzer
freezing_in_celcius = TemperatureInCelsius(0)
hot_in_celsius = freezing_in_celcius + room_temperature_in_celsius
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'TemperatureInCelsius' and 'TemperatureInCelsius'
Post by G.B.
Post by Peter J. Holzer
diff_in_celsius = room_temperature_in_celsius - freezing_in_celcius
print(diff_in_celsius)
20.000000 °C(Δ)
Post by G.B.
Post by Peter J. Holzer
hot_in_fahrenheit = room_temperature_in_fahrenheit + diff_in_celsius # and add a temperature and a difference (even in different units)
print(hot_in_fahrenheit)
104.000000 °F
In Python geht natürlich alles zur Laufzeit (nicht zur Compilezeit) und
Variablen (und Parameter) haben keinen Typ. In C++ würde man sich die is
isinstance-Kaskaden sparen und statt dessen Methoden mit verschiedenen
Parametern definieren. Ebenso könnte man C++ »=« überladen um eine
Einheitenumrechnung bei Zuweisung zu erreichen.
Post by G.B.
Dann würde ich auch gern die Einfachheit sehen, mit der operator+ für
Temperaturen je nach Anwendungsfall erlaubt (Statistik) oder
unterbunden werden kann (°C im genannten Fall).
Nachdem keine Programmiersprache Gedanken lesen kann, kann das meiner
Meinung nach nicht gehen. Aber Du kannst eine Funktion avg() definieren,
die überprüft, ob alle Argumente den gleichen Typ haben, denn
Durchschnitt der numerischen Werte ausrechnet und dann wieder in den
entsprechenden Typ zurückcastet.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-02-10 09:55:03 UTC
Permalink
Post by Peter J. Holzer
Post by G.B.
Bitte, wie unterstützen die compiler für Sprachen wie C, Swift,
Delphi, C#, Java, JavaSript, Python ... eine solche dimensionierte
Typvereinbarung so, dass compiler die Werte und Objekte auch gemäß
genau dieser dimensionierten Typvereinbarung spezifisch überprüfen?
Nicht alle diese Sprachen tun das ("das erlauben existierende
Programmiersprachen auch jetzt schon" ist eine Existenzaussage, keine
Allaussage).
Im rhetorischen Zusammenhang ist "Gibt's schon" in vernichtender
Absicht gemeint. So verstanden bin ich aufgefordert, mit einer
Existenzaussage von größerer Kardinalität zurückzufeuern: mit fast allen
mainstream-Sprachen, die nichts fertig Gangbares zu bieten haben.
Post by Peter J. Holzer
Meiner Meinung nach erfüllen alle Sprachen, die Typdefinitionen und
Operator-Overloading (oder zumindest polymorphe Funktionen)
unterstützen, Deine Forderung (oder was halt von Deinen etwas
widersprüchlichen Ideen als Kern übrigbleibt), also z.B. C# und Python,
nicht aber C oder JavaScript.
Überladene Operatoren tun es nicht, insofern sie keine spezifische
Ausdrucksweise erlauben:

Das Emulationsargument — man nehme das Typsystem, das für universelleren
Einsatz gemacht ist, und bastle sich aufwändig eine Sammlung von
Operator-Überladungen und halte sich dann an Konventionen – hast du selbst
m.E. gut ad absurdum geführt: schon das Beispiel zeigt, wie fummelig und
eigen eine solche Definition geeignet ausgewählter Operatoren werden kann.
Ganz zu schweigen von der Anpassung an den jeweiligen Zweck auf
dieser Basis. Wie sollen da Fehler vermieden werden, was doch eine
der Absichten dimensionierter Zahltypen ist? (Für einen einfachen
unittest von units.py habe ich erst mal, wie klar sein wird,
__eq__, __ne__, und __hash__ definieren müssen, um "grobe" Temperaturangaben
überhaupt vergleichen zu können. Dass allein schon "normale" Anwendungen
Temperatur-Objekte mit mehr Flexibilität bei +, -, usw haben werden
müssen, liegt auf der Hand, auch dann, wenn dieses Fehlen hier
dem Zweck gedient haben mag, zu zeigen, dass "isinstance" in Python
für die Typprüfung verwendet werden kann.)

Analoga:
Natürlich kann man mit Ganzzahl-Registern eine Fließkomma-Emulation
bauen. Das dient nicht nur zum Ausgleich für fehlende Hardware, sondern
auch für große/genaue Fließkommatypen in Software. Andererseits haben die
Sprachentwickler eine ganze Reihe von Programmiersprachen mit einem
Standardvorrat von Fließkommatypen ausgestattet. Das wird einen Grund haben...

Wirtschaftlich scheint mir wenig vielversprechend, ohne spezifische
Sprachunterstützung auf die gezeigte Art händisch Einheitensysteme
zu bauen. Sie können nichts anderes sein, als ad-hoc Versuche, das wirklich
beabsichtigte Ding zu implementieren.
Post by Peter J. Holzer
Post by G.B.
Dann würde ich auch gern die Einfachheit sehen, mit der operator+ für
Temperaturen je nach Anwendungsfall erlaubt (Statistik) oder
unterbunden werden kann (°C im genannten Fall).
Nachdem keine Programmiersprache Gedanken lesen kann, kann das meiner
Meinung nach nicht gehen.
Ein Ausdrucksmittel für Gedanken heißt Programmiersprache
und es wäre gut, den "Bereich" dimensionierte Zahlwerte
spezifisch ausdrücken zu können. Dann braucht man sich nicht
argumentativ im Kreis zu drehen, und allgemeines Typcasting als
spezifische Lösung zu empfehlen, wenn diese doch als
(a) fehleranfällige und
(b) zudem kaum eingesetzte Lösung
wirtschaftlich kaum Fuß fasst. Hieraus ergibt sich der Anreiz
für spezifische Unterstützung von dimensionierten Zahlen,
in Syntax und Semantik.
Peter J. Holzer
2017-02-11 10:48:17 UTC
Permalink
Post by G.B.
Post by Peter J. Holzer
Post by G.B.
Bitte, wie unterstützen die compiler für Sprachen wie C, Swift,
Delphi, C#, Java, JavaSript, Python ... eine solche dimensionierte
Typvereinbarung so, dass compiler die Werte und Objekte auch gemäß
genau dieser dimensionierten Typvereinbarung spezifisch überprüfen?
Nicht alle diese Sprachen tun das ("das erlauben existierende
Programmiersprachen auch jetzt schon" ist eine Existenzaussage, keine
Allaussage).
Im rhetorischen Zusammenhang ist "Gibt's schon" in vernichtender
Absicht gemeint. So verstanden bin ich aufgefordert, mit einer
Existenzaussage von größerer Kardinalität zurückzufeuern: mit fast allen
mainstream-Sprachen, die nichts fertig Gangbares zu bieten haben.
Kardinalität ist irrelevant. Es gibt tausende Programmiersprachen, und
niemand wird jemals mehr als die Hälfte davon verwenden. Relevant ist
einzig und allein, ob es eine gibt, die für das aktuelle Problem
geeignet ist (und ja, "geeignet" umfasst natürlich auch Kriterien wie
"ist dem Programmierer bekannt" und "wird nicht vom Management
abgelehnt").

Wenn Du also eine Programmiersprache findest, die deine Anforderungen
erfüllt, dann reicht das. Dass es tausende gibt, die sie nicht erfüllen,
kümmert Dich nicht weiter.
Post by G.B.
Post by Peter J. Holzer
Meiner Meinung nach erfüllen alle Sprachen, die Typdefinitionen und
Operator-Overloading (oder zumindest polymorphe Funktionen)
unterstützen, Deine Forderung (oder was halt von Deinen etwas
widersprüchlichen Ideen als Kern übrigbleibt), also z.B. C# und Python,
nicht aber C oder JavaScript.
Überladene Operatoren tun es nicht, insofern sie keine spezifische
Das Emulationsargument — man nehme das Typsystem, das für universelleren
Einsatz gemacht ist, und bastle sich aufwändig eine Sammlung von
Operator-Überladungen und halte sich dann an Konventionen – hast du selbst
m.E. gut ad absurdum geführt: schon das Beispiel zeigt, wie fummelig und
eigen eine solche Definition geeignet ausgewählter Operatoren werden kann.
Naja, nachdem Du bei allem, was darüber hinausgeht, explizit gesagt
hast, dass Du das nicht haben willst, weil es zu wenig allgemein wäre,
bleibt halt nichts anderes übrig, als die Sachen selber zu definieren.
Und das geht wie gesagt in vielen existierenden Programmiersprachen
bereits jetzt.

Gehe in dich, überlege Dir, was Du überhaupt haben willst, und schreibe
das mal konkret und widerspruchsfrei zusammen. Als Fleißaufgabe kannst
Du Dir noch eine Syntax überlegen. Und wenn Du uns wirklich beeindrucken
willst, dann mach Dir ein paar Gedanken darüber, wie man das
implementieren könnte.

Aber solange Du nich einmal weißt, was Du willst, und das Chaos Deiner
Gedanken nicht von Nomic-Spielchen unterscheidbar ist, sind Diskussionen
wenig fruchtbar.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Koenig
2017-02-12 10:14:02 UTC
Permalink
Post by Peter J. Holzer
Keine Ahnung, ich programmiere nicht in C++. Es geht aber ganz ohne
boost::unit, nur mit normalen Klassendefinitionen und
Operator-Overloading. Ist halt Tipparbeit, aber nur bei der Definition
der Klassen (irgendwo muss schon irgendwer mal festlegen, was passieren
soll, wenn man °C und °C addiert, oder Fuß mit Metern multipliziert).
Hier mal eine kleine Skizze in Python, wie sowas für Temperaturen in
[...]

Das Problem bei solchen hausgemachten Lösungen ist typischerweise, dass
sie in verschiedenen Projekten unterschiedlich und inkompatibel
umgesetzt werden, mit unterschiedlichen Zielen und - natürlich -
auch unterschiedlichen Fehlern.

Um wirklich nützlich zu sein, gehört so eine physikalisches
Einheitensystem in den Kern einer Sprache oder in eine
Standard-Bibliothek. Und da gibt es im Augenblick nichts
adäquates (außer MathCad, aber das ist ja nicht wirklich eine
Programmiersprache).
Peter J. Holzer
2017-02-12 17:11:15 UTC
Permalink
Post by Thomas Koenig
Post by Peter J. Holzer
Keine Ahnung, ich programmiere nicht in C++. Es geht aber ganz ohne
boost::unit, nur mit normalen Klassendefinitionen und
Operator-Overloading. Ist halt Tipparbeit, aber nur bei der Definition
der Klassen (irgendwo muss schon irgendwer mal festlegen, was passieren
soll, wenn man °C und °C addiert, oder Fuß mit Metern multipliziert).
Hier mal eine kleine Skizze in Python, wie sowas für Temperaturen in
[...]
Das Problem bei solchen hausgemachten Lösungen ist typischerweise, dass
sie in verschiedenen Projekten unterschiedlich und inkompatibel
umgesetzt werden, mit unterschiedlichen Zielen und - natürlich -
auch unterschiedlichen Fehlern.
Um wirklich nützlich zu sein, gehört so eine physikalisches
Einheitensystem in den Kern einer Sprache oder in eine
Standard-Bibliothek.
Standard-Bibliothek ja, Kern der Sprache meiner Meinung nach nein,
zumindest für eine general purpose Programmiersprache. Die meisten
Probleme haben wenig mit physikalischen Einheiten zu tun, und selbst
wenn, dann können je nach Anwendungsgebiet unterschiedliche Regeln
gelten (siehe die Diskussion über Temperaturen in diesem Thread).
Post by Thomas Koenig
Und da gibt es im Augenblick nichts adäquates (außer MathCad, aber das
ist ja nicht wirklich eine Programmiersprache).
Boost würde ich schon als Standard-Library ansehen. Ob Boost.Units
"adäquat" ist, kann ich nicht beurteilen.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Koenig
2017-02-13 07:23:07 UTC
Permalink
Post by Peter J. Holzer
Post by Thomas Koenig
Um wirklich nützlich zu sein, gehört so eine physikalisches
Einheitensystem in den Kern einer Sprache oder in eine
Standard-Bibliothek.
Standard-Bibliothek ja, Kern der Sprache meiner Meinung nach nein,
zumindest für eine general purpose Programmiersprache. Die meisten
Probleme haben wenig mit physikalischen Einheiten zu tun, und selbst
wenn, dann können je nach Anwendungsgebiet unterschiedliche Regeln
gelten (siehe die Diskussion über Temperaturen in diesem Thread).
Das Problem ist halt die Interaktion mit dem Rest der Sprache und
der Programme... mit Standard-Bibliothek meinte ich etwas, was
mit dem Rest der Sprache vorgesehen ist und interagieren kann.

Wenn ich (pseudo-C)

Meter l1;
Meter l2;
Sekunde t;
Geschwindigkeit v;

habe, sollte eine Funktion

Einheit Dividiere (Einheit a, Einheit b)
{
return a/b;
}

Fehlermeldungen werfen für

v = Dividiere (l1, l2)

und nicht für

v = Dividiere(l1, t);

und dafür muss die Sprache selber das kennen, oder in Form von
irgendeinem Template runterreichen.
Post by Peter J. Holzer
Post by Thomas Koenig
Und da gibt es im Augenblick nichts adäquates (außer MathCad, aber das
ist ja nicht wirklich eine Programmiersprache).
Boost würde ich schon als Standard-Library ansehen. Ob Boost.Units
"adäquat" ist, kann ich nicht beurteilen.
... das oben kann Boost, soweit ich das erkennen kann, nicht. Ich bin mir
auch nicht klar, wie es bei diesen Datentypen mit Arrays, Matritzen etc.
und der Kompatibilität mit den Standard-Funktionen dafür aussieht.

Außerdem ist das C++ (und ich verwende vor allem C, Fortran und Perl :-)
Peter J. Holzer
2017-02-13 18:02:55 UTC
Permalink
Post by Thomas Koenig
Post by Peter J. Holzer
Post by Thomas Koenig
Um wirklich nützlich zu sein, gehört so eine physikalisches
Einheitensystem in den Kern einer Sprache oder in eine
Standard-Bibliothek.
Standard-Bibliothek ja, Kern der Sprache meiner Meinung nach nein,
zumindest für eine general purpose Programmiersprache. Die meisten
Probleme haben wenig mit physikalischen Einheiten zu tun, und selbst
wenn, dann können je nach Anwendungsgebiet unterschiedliche Regeln
gelten (siehe die Diskussion über Temperaturen in diesem Thread).
Das Problem ist halt die Interaktion mit dem Rest der Sprache und
der Programme... mit Standard-Bibliothek meinte ich etwas, was
mit dem Rest der Sprache vorgesehen ist und interagieren kann.
Wenn ich (pseudo-C)
Meter l1;
Meter l2;
Sekunde t;
Geschwindigkeit v;
habe, sollte eine Funktion
Einheit Dividiere (Einheit a, Einheit b)
{
return a/b;
}
Fehlermeldungen werfen für
v = Dividiere (l1, l2)
und nicht für
v = Dividiere(l1, t);
Ist es Absicht, dass Du hier Dein sorgfältig eingeführtes Typsystem
durch einen Supertyp Einheit wieder komplett über den Haufen wirfst?
Was Du da machst, ist das Äquivalent der Verwendung eines void-Pointers
in C bzw. einer Object-Referenz in Java. In vielen Sprachen kann noch
zur Laufzeit überprüft werden, dass der Typ stimmt, aber zur
Compile-Zeit geht das nur mehr im Spezialfall (hier könnte es gehen,
wenn der Compiler »Dividiere« inlinet.
Post by Thomas Koenig
und dafür muss die Sprache selber das kennen, oder in Form von
irgendeinem Template runterreichen.
Dafür reicht meiner Meinung nach ein "normales" Typsystem mit
entsprechend definierten Operatoren. l1 / l2 ergibt hat nicht Typ
Geschwindigkeit, und damit schlägt die Zuweisung an v fehl, im besten
Fall zur Compilezeit, schlimmstenfalls zur Laufzeit.
Post by Thomas Koenig
... das oben kann Boost, soweit ich das erkennen kann, nicht. Ich bin mir
auch nicht klar, wie es bei diesen Datentypen mit Arrays, Matritzen etc.
und der Kompatibilität mit den Standard-Funktionen dafür aussieht.
Außerdem ist das C++ (und ich verwende vor allem C, Fortran und Perl :-)
C ist dafür meines Erachtens nicht geeignet. Fortran vermutlich auch
nicht (Sorry, mein Wissensstand ist da irgendwo zwischen Fortran-77 und
Fortran-90 stehengeblieben). Perl würde im Prinzip gehen, allerdings
haben Variablen in Perl keinen Typ, d.h, die Zuweisung an v würde
funktionieren, und erst wenn Du v irgendwo verwenden willst, wo eine
Geschwindigkeit erwartet wird, knallt es. Dank Autoload könnte man in
Perl auch Typen dynamisch erzeugen, damit man nicht für die Berechnung
der abgestrahlten Energie eines schwarzen Körpers einen Typ
WattOverKelvin4 definieren muss, sondern einfach $P = $σ * $A * $T**4
schreiben kann, wobei $σ, $A und $T die richtigen Typen haben.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Koenig
2017-02-18 22:01:25 UTC
Permalink
Post by Peter J. Holzer
Post by Thomas Koenig
Wenn ich (pseudo-C)
Meter l1;
Meter l2;
Sekunde t;
Geschwindigkeit v;
habe, sollte eine Funktion
Einheit Dividiere (Einheit a, Einheit b)
{
return a/b;
}
Fehlermeldungen werfen für
v = Dividiere (l1, l2)
und nicht für
v = Dividiere(l1, t);
Ist es Absicht, dass Du hier Dein sorgfältig eingeführtes Typsystem
durch einen Supertyp Einheit wieder komplett über den Haufen wirfst?
Naja, das System ist halt noch nicht sorgfältig durchdacht und
eingeführt, deshalb diskutiere ich ja auch :-)

Vielleicht wäre es tatsächlich besser, das anders zu machen,
so ähnlich vielleicht (Syntax diesmal an Fortran angelehnt):

function dividiere (a, b) result(v)
real, unit(*) :: a, b ! Beliebige Einheit
real, unit(a/b) :: v ! v hat Einheit a/b, sonst Fehler

v = a/b
end function dividiere

Damit könnte der Compiler beim Übersetzten von

x = dividiere(a,b)

prüfen, ob das passt.
Post by Peter J. Holzer
Post by Thomas Koenig
Außerdem ist das C++ (und ich verwende vor allem C, Fortran und Perl :-)
C ist dafür meines Erachtens nicht geeignet. Fortran vermutlich auch
nicht (Sorry, mein Wissensstand ist da irgendwo zwischen Fortran-77 und
Fortran-90 stehengeblieben).
Zu Fortran könnte man das vielleicht dazupacken, aber natürlich müsste
man erst mal einen abgeschlossenen Entwurf haben und dann auch noch
Unterstützung in dem Normenkomittee finden...
Lutz Donnerhacke
2017-02-20 16:51:51 UTC
Permalink
Post by Thomas Koenig
Naja, das System ist halt noch nicht sorgfältig durchdacht und
eingeführt, deshalb diskutiere ich ja auch :-)
Dann schau mal über den Tellerrand zu Haskell mit einem ausreichend
mächtigen Typsystem.
Thomas Koenig
2017-02-26 18:42:30 UTC
Permalink
Post by Lutz Donnerhacke
Post by Thomas Koenig
Naja, das System ist halt noch nicht sorgfältig durchdacht und
eingeführt, deshalb diskutiere ich ja auch :-)
Dann schau mal über den Tellerrand zu Haskell mit einem ausreichend
mächtigen Typsystem.
Ok...

Programmiersprachen, deren Typsystem ausreicht, um
dimensionsbehaftete Größen darstellen zu können, scheinen
also (bisher) C++, Ada und Haskell zu sein. Zumindest
Ada und Haskell scheinen vernünftige mehrdimensionale
Arrays zu haben.

Die Frage, ob derartige Einheitensysteme auch tatsächlich
existieren, brauchbar sind und - vor allem - wie gut sie
mit vorhandener Software wie Integratoren, Gleichungslöser
etc. zusammenarbeiten, ohne gleich alle Vorteile über Bord zu
werfen, ist für mich allerdings immer noch offen.
Lutz Donnerhacke
2017-03-01 21:14:44 UTC
Permalink
Post by Thomas Koenig
Die Frage, ob derartige Einheitensysteme auch tatsächlich
existieren, brauchbar sind und - vor allem - wie gut sie
mit vorhandener Software wie Integratoren, Gleichungslöser
etc. zusammenarbeiten, ohne gleich alle Vorteile über Bord zu
werfen, ist für mich allerdings immer noch offen.
Für Ada schau Dir den Postmortem des Mars Climate Orbiter an.
Thomas Koenig
2017-03-02 07:57:54 UTC
Permalink
Post by Lutz Donnerhacke
Post by Thomas Koenig
Die Frage, ob derartige Einheitensysteme auch tatsächlich
existieren, brauchbar sind und - vor allem - wie gut sie
mit vorhandener Software wie Integratoren, Gleichungslöser
etc. zusammenarbeiten, ohne gleich alle Vorteile über Bord zu
werfen, ist für mich allerdings immer noch offen.
Für Ada schau Dir den Postmortem des Mars Climate Orbiter an.
Das ist ja der Punkt:

Man _kann_ in Ada (oder C++, oder Haskell) ein Typsystem mit Einheiten
implementieren. Weil es umständlich ist, macht es keiner, und daher
passieren solche Fehler.

Daher wäre mir lieber, dass man sowas in der Kernsprache verankert, dass
man es einfach benutzen kann. Und das macht - mit Ausnahme von MathCad,
was ja nicht wirklich eine Programmiersprache ist - AFAIK niemand.
Stefan Reuther
2017-03-02 17:38:49 UTC
Permalink
Post by Thomas Koenig
Post by Lutz Donnerhacke
Post by Thomas Koenig
Die Frage, ob derartige Einheitensysteme auch tatsächlich
existieren, brauchbar sind und - vor allem - wie gut sie
mit vorhandener Software wie Integratoren, Gleichungslöser
etc. zusammenarbeiten, ohne gleich alle Vorteile über Bord zu
werfen, ist für mich allerdings immer noch offen.
Für Ada schau Dir den Postmortem des Mars Climate Orbiter an.
Man _kann_ in Ada (oder C++, oder Haskell) ein Typsystem mit Einheiten
implementieren. Weil es umständlich ist, macht es keiner, und daher
passieren solche Fehler.
Daher wäre mir lieber, dass man sowas in der Kernsprache verankert, dass
man es einfach benutzen kann. Und das macht - mit Ausnahme von MathCad,
was ja nicht wirklich eine Programmiersprache ist - AFAIK niemand.
Wenn es nur um das "einfach benutzen" geht, muss das aber nicht
Bestandteil der Kernsprache sein. Das kann auch Bestandteil der Library
sein.

Ein 'template<int M, int KG, int S, int A, int K> class Value'
(Templateparameter = Potenzen der Basiseinheiten) konnte man in C++98
schon bauen. Schon das konnte man in eine Library verpacken und dann
Distance d = 500*Kilometer;
Speed s = d / (5*Minutes);
schreiben (Library: 'typedef Value<1,0,0,0,0> Distance; typedef
Value<1,0,-1,0,0> Speed; typedef Value<0,0,1,0,0> Time; const Distance
Kilometer(1000); const Time Minutes(60);'). War halt nicht sehr verbreitet.

Mit C++11 geht dann auch
Distance d = 500_km;
Speed s = d / 5_min;
und viel besser kann's doch eigentlich kaum werden?


Stefan
G.B.
2017-03-03 08:25:20 UTC
Permalink
On 02/03/2017 18:38, Stefan Reuther wrote:

(http://en.cppreference.com/w/cpp/language/user_literal)
Post by Stefan Reuther
Mit C++11 geht dann auch
Distance d = 500_km;
Speed s = d / 5_min;
und viel besser kann's doch eigentlich kaum werden?
MAW, viel besser, als das Typsystem per Büchereivorgabe
oder sonst durch kombinatorischen Eigenbau zu verwenden,
kann es kaum werden?

Doch, kann es.

Wenn versucht wird, dieser offenbar wichtigen "Dimension"
beruflichen Ausdrucks in Programmtext nicht mit Emulation
durch Typen o.ä., sondern durch direkte, umweglose, und
spezifische Syntax und Semantik zu entsprechen.

Immerhin Syntax leisten die existierenden Ergänzungen.
Sie ziehen sich aber sonst auf einen bekannten Standpunkt
zurück: "man muss doch nur..." . (Und dann können wir unser
Produkt unverändert verkaufen! 8-]). Der geht auch mit
Assembler oder mit lambdas, man muss doch nur...

Spezifische Semantik ist da nur Nebenprodukt, das so gut oder so
schlecht funktioniert, wie alles, was aus unspezifischen Gründen
gut oder schlecht funktioniert.

- Was passiert, wenn wir die Dimension der Größe X verändern?

Es kommt darauf an, wie spezifisch, wie separat, wie schnell,
und wie entkoppelt diese Frage beantwortet werden kann.
Oder ob sie einen Rattenschwanz von Folgefragen nach sich
zieht.
Stefan Reuther
2017-03-03 17:39:15 UTC
Permalink
Post by G.B.
(http://en.cppreference.com/w/cpp/language/user_literal)
Post by Stefan Reuther
Mit C++11 geht dann auch
Distance d = 500_km;
Speed s = d / 5_min;
und viel besser kann's doch eigentlich kaum werden?
MAW, viel besser, als das Typsystem per Büchereivorgabe
oder sonst durch kombinatorischen Eigenbau zu verwenden,
kann es kaum werden?
Doch, kann es.
Wenn versucht wird, dieser offenbar wichtigen "Dimension"
beruflichen Ausdrucks in Programmtext nicht mit Emulation
durch Typen o.ä., sondern durch direkte, umweglose, und
spezifische Syntax und Semantik zu entsprechen.
[snip]

Das war viel um den heißen Brei drumherum geredet, aber was müsste denn
nun geändert werden, um "direkte, umweglose und spezifische Syntax und
Semantik" zu sein? Was müsste die Sprache anders machen als obige
Library (und warum ist Komplexität in der Sprache besser als in der
Library)?


Stefan
G.B.
2017-03-03 21:10:47 UTC
Permalink
Post by Stefan Reuther
was müsste denn
nun geändert werden, um "direkte, umweglose und spezifische Syntax und
Semantik" zu sein?
Das ist eine Formulierung der Ausgangsfrage.
Post by Stefan Reuther
Was müsste die Sprache anders machen als obige
Library
ZB Syntax und Semantik unabhängig vom Typsystem zur Verfügung
stellen, i.S.v. orthogonal.
Post by Stefan Reuther
(und warum ist Komplexität in der Sprache besser als in der
Library)?
Komplexitätsreduktion durch eingebaute Sprachmittel,
analog zur Entwicklung von Hochsprachen. Schon wenn Aspekte
von Quelltext von einander unabhängig analysiert werden können,
bedeutet diese getrennte Betrachtung weniger Komplexität.
Mglw. dabei in P berechendbare Änderbarkeit implizierend.

Das Ziel ist keine Kleinigkeit, vermute ich, es sei denn,
zwei getrennte Typsysteme können mit ihren bekannten und erprobten
Mitteln getrennte Ausdrucksmöglichkeiten "parallel" und konsistent
in der Sprache zur Verfügung stellen. So, dass im Brandfall
weder ein Bücherei-Spezialist noch ein Spieltheoretiker erforderlich
sind, damit ein Programmierer mit dimensionierten Größen
arbeiten und den Brand löschen kann.
Stefan Reuther
2017-03-05 16:02:26 UTC
Permalink
Post by G.B.
Post by Stefan Reuther
Was müsste die Sprache anders machen als obige
Library
ZB Syntax und Semantik unabhängig vom Typsystem zur Verfügung
stellen, i.S.v. orthogonal.
Das war jetzt nichts weiter als eine Aneinanderreihung von Schlagworten
ohne konkrete Handlungsaktion.
Post by G.B.
Post by Stefan Reuther
(und warum ist Komplexität in der Sprache besser als in der
Library)?
Komplexitätsreduktion durch eingebaute Sprachmittel,
analog zur Entwicklung von Hochsprachen. Schon wenn Aspekte
von Quelltext von einander unabhängig analysiert werden können,
bedeutet diese getrennte Betrachtung weniger Komplexität.
Wenn ich das Feature in der Library habe, kann ich die Kernsprache
analysieren, unabhängig davon die Library, und unabhängig den
Anwendercode. Ziel erreicht.

Hab ich das Feature in der Kernsprache, kann ich diese nicht mehr ohne
dieses Feature betrachten.


Stefan
G.B.
2017-03-06 08:15:12 UTC
Permalink
Post by Stefan Reuther
Post by G.B.
Post by Stefan Reuther
Was müsste die Sprache anders machen als obige
Library
ZB Syntax und Semantik unabhängig vom Typsystem zur Verfügung
stellen, i.S.v. orthogonal.
Das war jetzt nichts weiter als eine Aneinanderreihung von Schlagworten
ohne konkrete Handlungsaktion.
Nimm den Satz nochmals auf:
"zur Verfügung stellen" deutet auf die Handlung Lieferung des
Ergebnisses, nicht auf die Lieferung eines Produktionsplans.
Der würde das Nachdenken über die Zielerreichung ersetzen.
Syntax ist ein eingeführter Begriff, Semantik auch.

Sprachdefinitionen stellen Syntax und Semantik zur Verfügung,
ein kritischer Unterschied ist wenn Syntax und Semantik
unmittelbar verbunden beschrieben werden. Eine unten behandelte
Frage ist, ob Library einen komplexen, unspezifischen Umweg
zwischen Syntax und Semantik einbaut.
Post by Stefan Reuther
Wenn ich das Feature in der Library habe, kann ich die Kernsprache
analysieren, unabhängig davon die Library,
Eine Library, insofern sie in der Kernsprache geschrieben
ist, lässt sich nicht ohne die Kernsprache analysieren.
Eine Library, die das ganze Typsystem und die Sprache nutzt,
ist nicht orthogonal und nicht weniger komplex. Sie hat
insofern keine _spezifische_ Semantik für das parat, was ein
dimensionshungriger Programmierer vielleicht möchte.

Die Syntax der benutzerdefinierten Literale gehört konkret
nicht zur Library von C++, sondern zur Kernsprache, oder
nicht?

Zudem "muss man doch nur..." mit den Mitteln der templates
und Typen das richtige eigenbauen, oder dazu kaufen, oder ändern
und dabei alles richtig machen... Ohne dass dieses Verfahren
über die Komplexität der Kernsprache hinaus reichte?
Post by Stefan Reuther
und unabhängig den Anwendercode. Ziel erreicht.
Der Brandfall ist entscheidend: Ist es einfacher, aus den
semantischen Vorschriften von Dimensionen, definiert in der
Kernsprache, einen Fehler in der Implementierung zu erkennen,
oder bedarf es eines Spezialisten, der die Beschreibung
einer Bücherei (z.B. von templates mit Auflösung) und deren gesamten
Aufbau aus unspezifischen Sprachmitteln ständig und dauerhaft
im Griff hat?
Post by Stefan Reuther
Hab ich das Feature in der Kernsprache, kann ich diese nicht mehr ohne
dieses Feature betrachten.
Leztere Behauptung halte ich für falsch, dem "orthogonal" entgegen
gesetzt: z.B. macht die Sprachdefinition von C klar (F.2), dass
Fließkommaarithmetik mit single hinreichend ist, double nicht
zwingend erforderlich. Gleiches gilt dann für die Betrachtungen,
die sich aus allfälliger Wechselwirkung zwischen single und double
ergeben. Ich kann also zunächst C ohne "double" betrachten.

Die Hinzunahme von double zu einer Implementierung erzeugt
i.d.S. höhere Komplexität.

Ähnliches gilt für weitere Anhänge der Definitionen von C
oder Ada oder ...

Hingegen glaube ich, dass eine Analyse bspw. von boost::unit
in die Kernsprache C++ und in Library-Mechanik ziemlich weit
hineinreicht und zusätzlicher, äußerer Bestimmungen bedarf,
damit die Analyse mit Bezug auf dimensionierte Zahlen gelingt.
Sie lebt m.E. vom "geht doch erstmal"-Argument, das am Ende
teure Lösungen und Spezialisierungen im Markt etabliert hat.
Peter J. Holzer
2017-03-10 06:42:47 UTC
Permalink
Post by G.B.
Post by Stefan Reuther
Post by G.B.
Post by Stefan Reuther
Was müsste die Sprache anders machen als obige
Library
ZB Syntax und Semantik unabhängig vom Typsystem zur Verfügung
stellen, i.S.v. orthogonal.
Das war jetzt nichts weiter als eine Aneinanderreihung von Schlagworten
ohne konkrete Handlungsaktion.
"zur Verfügung stellen" deutet auf die Handlung Lieferung des
Ergebnisses, nicht auf die Lieferung eines Produktionsplans.
Der würde das Nachdenken über die Zielerreichung ersetzen.
Syntax ist ein eingeführter Begriff, Semantik auch.
Man kann auch eingeführte Begriffe so verwenden, dass ihre Kombination
wenig Sinn ergibt.

Insbesondere ist das Typsystem ein wichtiger Teil der Semantik jeder
Programmiersprache. "Semantik unabhängig vom Typsystem" ist daher ein
Unding. Du kannst eventuell das Typsystem unabhängig vom Rest der
Semantik betrachten, aber sicher nicht umgekehrt, weil ein Großteil der
Semantik einer Programmiersprache auf dem Typsystem aufbaut.
Post by G.B.
z.B. macht die Sprachdefinition von C klar (F.2), dass
Fließkommaarithmetik mit single hinreichend ist, double nicht
zwingend erforderlich.
Wo liest Du das heraus? Hier ist F.2 in voller Länge (aus N1570):

| F.2 Types
|
| The C floating types match the IEC 60559 formats as follows:
|
| — The float type matches the IEC 60559 single format.
| — The double type matches the IEC 60559 double format.
| — The long double type matches an IEC 60559 extended format,357) else a
| non-IEC 60559 extended format, else the IEC 60559 double format.
|
| Any non-IEC 60559 extended format used for the long double type shall
| have more precision than IEC 60559 double and at least the range of IEC
| 60559 double.358)
|
| Recommended practice
|
| The long double type should match an IEC 60559 extended format.
|
| F.2.1 Infinities, signed zeros, and NaNs
|
| This specification does not define the behavior of signaling NaNs.359)
| It generally uses the term NaN to denote quiet NaNs. The NAN and
| INFINITY macros and the nan functions in <math.h> provide designations
| for IEC 60559 NaNs and infinities.

Auch sonst steht m.E. nirgends, dass double optional ist. In 6.2.5 steht
etwa:

| There are three real floating types, designated as float, double, and
| long double. The set of values of the type float is a subset of the
| set of values of the type double; the set of values of the type double
| is a subset of the set of values of the type long double.

Alle drei Typen muss es geben.

Du verwechselst das möglicherweise damit, dass ein Compiler für
Zwischenergebnisse von Operationen auf float Werten einen breiteren Typ
verwenden darf, aber nicht muss. In K&R war noch beschrieben, dass diese
Zwischenergebnisse immer den Typ double haben, C89 hat aus dieser
Vorschrift eine Option gemacht.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-03-10 07:37:18 UTC
Permalink
Post by Peter J. Holzer
Insbesondere ist das Typsystem ein wichtiger Teil der Semantik jeder
Programmiersprache. "Semantik unabhängig vom Typsystem" ist daher ein
Unding. Du kannst eventuell das Typsystem unabhängig vom Rest der
Semantik betrachten, aber sicher nicht umgekehrt, weil ein Großteil der
Semantik einer Programmiersprache auf dem Typsystem aufbaut.
Das wäre dann eine Frage: Kann man etwas bauen, das wahlweise
orthogonal zum Typsystem Bedeutung geben kann? Oder: Kann eine
Sprache für dimensionierte Größen ein zweites Typsystem nutzen?
Post by Peter J. Holzer
Post by G.B.
z.B. macht die Sprachdefinition von C klar (F.2), dass
Fließkommaarithmetik mit single hinreichend ist, double nicht
zwingend erforderlich.
Ups, mein Lesefehler: "F.2 Types
Minimal conformance to the IEC 60559[!] floating-point
standards does not require a format wider that single."
Was i.d.Zshg. nichts über ISO/IEC 9899 sagt… Sorry.
Sieghard Schicktanz
2017-03-03 21:51:57 UTC
Permalink
Hallo G.B.,
Post by G.B.
Post by Stefan Reuther
Distance d = 500_km;
Speed s = d / 5_min;
und viel besser kann's doch eigentlich kaum werden?
Fürchterlich, vor allem die Syntax...
Post by G.B.
MAW, viel besser, als das Typsystem per Büchereivorgabe
oder sonst durch kombinatorischen Eigenbau zu verwenden,
kann es kaum werden?
Doch, kann es.
Könnte es evtl. auch dadurch, daß man es schafft, die Arithmetik in der
Sprache (wie ich ja schon mal angesprochen hatte) dahingehend zu erweitern,
daß neue Objekte (Einheiten) eingeführt werden, die sich in vieler Hinsicht
wie Zahlen verhalten, aber tatsächlich keine echten Zahlen sind. Sie müßten
normale Multiplikation (/ Division) zulassen, sowohl untereinander als auch
mit normalen Zahlen, und ausschließlich untereinander die spezielle additive
Operation der Subtraktion gleicher Einheiten mit dem Ergebnis 0.
Post by G.B.
Wenn versucht wird, dieser offenbar wichtigen "Dimension"
beruflichen Ausdrucks in Programmtext nicht mit Emulation
durch Typen o.ä., sondern durch direkte, umweglose, und
spezifische Syntax und Semantik zu entsprechen.
Damit wäre die direkteste Implementation gegeben, die ich mir so vorstellen
kann, wenn auch die Syntax etwas von der "umgangssprachlichen" Notation
abweicht - aber das ist ja auch bei der normalen Multiplikation so.
Das obige Beispiel würde damit etwa so aussehen:

Distance d = 500* km;
Speed s = d / (5*min);

Zusätzlich sollten diese "Einheiten"-Objekte mittels der dafür definierten
Operatoren noch solche Sachen können wie Umrechnungen:

N = 1* meter/(1* zoll); Ergebnis _Zahl_ 39.370079

und natürlich gemischte AUsdrücke, wo kompatible Einheiten (Längen, Zeiten,
Gewichte jeweils untereinander) an zulässigen Stellen vorkommen dürfen, z.B.

Gw = 12* 10* kg + 5* 500* g + 500* ounce;

(Da muß der Komplizierer [dt. für "Compiler"...] halt schon selber
bisserl symbolische Arithmetik können und die Einheiten mit ihren
Umrechnungsfaktoren zusammenfassen.)

Das wird dann zwar auch nicht einfach, aber das Ziel sollte ja auch nicht
nur sein, korrekte Ausdrücke verarbeiten zu können, sondern vor allem,
_fehlerhafte_ Ausdrücke _erkennen_ zu können. Das letztere ist IMHO
wesentlich wichtiger als das erstere.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Peter J. Holzer
2017-03-04 18:28:06 UTC
Permalink
Post by Sieghard Schicktanz
Post by Stefan Reuther
Distance d = 500_km;
Speed s = d / 5_min;
und viel besser kann's doch eigentlich kaum werden?
Fürchterlich, vor allem die Syntax...
[...]
Post by Sieghard Schicktanz
Damit wäre die direkteste Implementation gegeben, die ich mir so vorstellen
kann, wenn auch die Syntax etwas von der "umgangssprachlichen" Notation
abweicht - aber das ist ja auch bei der normalen Multiplikation so.
Distance d = 500* km;
Speed s = d / (5*min);
Post by Stefan Reuther
Schon das konnte man in eine Library verpacken und dann
Distance d = 500*Kilometer;
Speed s = d / (5*Minutes);
schreiben
Zusätzlich sollten diese "Einheiten"-Objekte mittels der dafür definierten
N = 1* meter/(1* zoll); Ergebnis _Zahl_ 39.370079
und natürlich gemischte AUsdrücke, wo kompatible Einheiten (Längen, Zeiten,
Gewichte jeweils untereinander) an zulässigen Stellen vorkommen dürfen, z.B.
Gw = 12* 10* kg + 5* 500* g + 500* ounce;
Irgendwie hatten wir das alles schon in diesem Thread.
Post by Sieghard Schicktanz
(Da muß der Komplizierer [dt. für "Compiler"...] halt schon selber
bisserl symbolische Arithmetik können und die Einheiten mit ihren
Umrechnungsfaktoren zusammenfassen.)
Nicht wirklich.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Sieghard Schicktanz
2017-03-05 20:46:41 UTC
Permalink
Hallo Peter,
Post by Peter J. Holzer
Post by Sieghard Schicktanz
Post by Stefan Reuther
Distance d = 500_km;
Speed s = d / 5_min;
und viel besser kann's doch eigentlich kaum werden?
Fürchterlich, vor allem die Syntax...
[...]
Post by Sieghard Schicktanz
Distance d = 500* km;
Speed s = d / (5*min);
Post by Stefan Reuther
Schon das konnte man in eine Library verpacken und dann
Distance d = 500*Kilometer;
Speed s = d / (5*Minutes);
schreiben
Durch einen etwas anderen Ansatz - Erweiterung der Arithmetik, und zwar
ohne Einschränkungen auf bestimmte Relationen. Wobei ich zugestehen muß,
mit der damals gebrachten Darstellung recht wenig anfangen, geschweige denn
ihre Realisier- und Nutzbarkeit beurteilen zu können.

[Umrechnungen]
Post by Peter J. Holzer
Post by Sieghard Schicktanz
N = 1* meter/(1* zoll); Ergebnis _Zahl_ 39.370079
[gemischte AUsdrücke]
Post by Peter J. Holzer
Post by Sieghard Schicktanz
Gw = 12* 10* kg + 5* 500* g + 500* ounce;
Irgendwie hatten wir das alles schon in diesem Thread.
Sicher, geht doch darum, das möglichst universell zu machen.
Post by Peter J. Holzer
Post by Sieghard Schicktanz
bisserl symbolische Arithmetik können und die Einheiten mit ihren
Umrechnungsfaktoren zusammenfassen.)
Nicht wirklich.
Also unwirklich? Auch recht...
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Matthias Frey
2017-03-07 08:53:38 UTC
Permalink
Post by G.B.
Doch, kann es.
Wenn versucht wird, dieser offenbar wichtigen "Dimension"
Das meinst auch nur du dass das "offenbar" ist.
Ich behaupte es ist "offenbar", dass man das in 99% der Anwendungen
nicht braucht.
Also bitte haltet das bitte aus dem Kern der üblichen Sprachen raus.
Man kann ja eine neue Sprache machen wenn man das will.

Matthias
G.B.
2017-03-07 09:24:10 UTC
Permalink
Post by Matthias Frey
Post by G.B.
Doch, kann es.
Wenn versucht wird, dieser offenbar wichtigen "Dimension"
Das meinst auch nur du dass das "offenbar" ist.
Ich behaupte es ist "offenbar", dass man das in 99% der Anwendungen
nicht braucht.
Sag doch mal, welche Bereiche der Softwareentwicklung in deine 99%
nach ihrer relativen Größe eingehen.

Z.B. nach der Budgetgröße am Markt, nach dem Gebiet (Verkehr,
Transnationale Unternehmenssoftware, Prozesssteuerung,
Banken und Versicherungen, Logistik, Foto, Maschinen (Mechatronik, Robotik),
eHandel (mit Währungen), Verteidigung, Forschung, ...), Anzahl der
verbundenen IT-Arbeitsplätze, Anzahl und Größe von Programmen einer
vergleichbaren Sorte, usw.

Ich verzichte gern auf "offenbar" zugunsten von "wenn", selbst wenn die
durchdachten Beiträge hier Hinweise sind, in denen berufserfahrene
Vollzeitprogrammierer durchblicken lassen, um was und auch um
wieviel Geld es bei Programmen gehen kann.
Matthias Frey
2017-03-08 07:25:00 UTC
Permalink
Post by G.B.
Post by Matthias Frey
Post by G.B.
Doch, kann es.
Wenn versucht wird, dieser offenbar wichtigen "Dimension"
Das meinst auch nur du dass das "offenbar" ist.
Ich behaupte es ist "offenbar", dass man das in 99% der Anwendungen
nicht braucht.
Sag doch mal, welche Bereiche der Softwareentwicklung in deine 99%
nach ihrer relativen Größe eingehen.
Z.B. nach der Budgetgröße am Markt, nach dem Gebiet (Verkehr,
Transnationale Unternehmenssoftware, Prozesssteuerung,
Banken und Versicherungen, Logistik, Foto, Maschinen (Mechatronik, Robotik),
eHandel (mit Währungen), Verteidigung, Forschung, ...), Anzahl der
verbundenen IT-Arbeitsplätze, Anzahl und Größe von Programmen einer
vergleichbaren Sorte, usw.
Ich dachte eigentlich an alle Bereiche.
Post by G.B.
Ich verzichte gern auf "offenbar" zugunsten von "wenn", selbst wenn die
durchdachten Beiträge hier Hinweise sind, in denen berufserfahrene
Vollzeitprogrammierer durchblicken lassen, um was und auch um
wieviel Geld es bei Programmen gehen kann.
Was hat das Geld damit zu tun? Ich bestreite ja nicht dass es
bei Softwareentwicklung oft um viel Geld geht.
Ich bestreite nur, dass ein Einheiten-Typsystem so wichtig ist,
dass es in den Kern einer Sprache müsste.

Matthias
G.B.
2017-03-08 08:02:36 UTC
Permalink
Post by Matthias Frey
Post by G.B.
Post by Matthias Frey
Ich behaupte es ist "offenbar", dass man das in 99% der Anwendungen
nicht braucht.
Sag doch mal, welche Bereiche der Softwareentwicklung in deine 99%
nach ihrer relativen Größe eingehen. [...]
Ich dachte eigentlich an alle Bereiche.
Respekt, dann kennst dich gut aus.
Post by Matthias Frey
Ich bestreite nur, dass ein Einheiten-Typsystem so wichtig ist,
dass es in den Kern einer Sprache müsste.
Ein Bestreiten mit dem Spruch "99% aller Programme...", der nicht weiter
substantiiert, sondern nur selbstbewusst vorgetragen zu werden braucht...

Wie in den threads angenommen worden ist, hätte viel Geld durch (a)
die korrekte Verwendung von Dimensionen, (b) durch..., eingespart werden
können, weil bspw. ein teures Projekt nicht abstürzt wäre, sprichwörtlich.
Da wirkt der "99%"-Spruch zum Brauchtmannicht unsachlich.

Warum?

Über den Spruch hinaus deswegen, weil, nach vielfach geäußerter
Annahme, eine wie auch immer geartete Lösung für dimensionierte Größen
tatsächlich wie selbstverständlich genutzt werden muss. Sonst ist
sie nicht wirksam. Dieser Umstand lässt, z.B. wegen des Lernaufwands
und der komplexen technischen Verstrickung einen Büchereilösung wie
boost::unit suboptimal erscheinen. Zumal für die häufig verwendeten
Sprachen suboptimal, wie "Nicht-C++" oder "Nicht-GNAT" oder "Nicht-Haskell".
Matthias Frey
2017-03-08 12:32:48 UTC
Permalink
Post by G.B.
Post by Matthias Frey
Post by G.B.
Post by Matthias Frey
Ich behaupte es ist "offenbar", dass man das in 99% der Anwendungen
nicht braucht.
Sag doch mal, welche Bereiche der Softwareentwicklung in deine 99%
nach ihrer relativen Größe eingehen. [...]
Ich dachte eigentlich an alle Bereiche.
Respekt, dann kennst dich gut aus.
Gut genug um Deiner Aussage zu wiedersprechen, dass es "offenbar"
sei, dass ein Einheitensystem so wichtig sei, dass es in den Kern
von Programmiersprachen soll.
Post by G.B.
Post by Matthias Frey
Ich bestreite nur, dass ein Einheiten-Typsystem so wichtig ist,
dass es in den Kern einer Sprache müsste.
Ein Bestreiten mit dem Spruch "99% aller Programme...", der nicht weiter
substantiiert, sondern nur selbstbewusst vorgetragen zu werden braucht...
So selbstbewusst vorgetragen wie dein "offenbar"
Post by G.B.
Wie in den threads angenommen worden ist, hätte viel Geld durch (a)
die korrekte Verwendung von Dimensionen, (b) durch..., eingespart
werden können, weil bspw. ein teures Projekt nicht abstürzt wäre,
sprichwörtlich.
Wann und wo wurde hier das angenommen (außer von dir)?
Bei dem Projekt das hier erwähnt wurde handelt es sich um eine
Raumsonde - richtig? Das gehört dann zu dem einen Prozent.
(Bereich Raumfahrt)
Post by G.B.
Da wirkt der "99%"-Spruch zum Brauchtmannicht unsachlich.
Warum?
Über den Spruch hinaus deswegen, weil, nach vielfach geäußerter
Annahme,
Wo? Ich habe das bislang nur hier in de.comp.lang.misc gelesen.
(In den Foren, Zeitschriften und Blogs die ich lese ist derzeit
DevOps das meistgenannte Thema)
Post by G.B.
eine wie auch immer geartete Lösung für dimensionierte Größen
tatsächlich wie selbstverständlich genutzt werden muss. Sonst ist
sie nicht wirksam. Dieser Umstand lässt, z.B. wegen des Lernaufwands
und der komplexen technischen Verstrickung einen Büchereilösung wie
boost::unit suboptimal erscheinen. Zumal für die häufig verwendeten
Sprachen suboptimal, wie "Nicht-C++" oder "Nicht-GNAT" oder
"Nicht-Haskell".
"genutzt werden muss"? Damit würdest du die Sprache in vielen
Fällen für suboptimal machen.

Ich sage ja nicht dass ich generell für ein solches Konzept bin,
sondern wehre mich nur dagegen das als brauchbar für alle Fälle
zu definieren.
Da wo ich gerade bin könnten wir tatsächlich so ein System auch
gut gebrauchen. (Das gehört dann auch zu dem einen %)
Andererseits müsste es auch noch viel weiter gehen damit es den
vollen Nutzen bringen könnte.

Matthias
G.B.
2017-03-09 09:35:36 UTC
Permalink
Post by Matthias Frey
Post by G.B.
Post by Matthias Frey
Post by G.B.
Post by Matthias Frey
Ich behaupte es ist "offenbar", dass man das in 99% der Anwendungen
nicht braucht.
Sag doch mal, welche Bereiche der Softwareentwicklung in deine 99%
nach ihrer relativen Größe eingehen. [...]
Ich dachte eigentlich an alle Bereiche.
Respekt, dann kennst dich gut aus.
Gut genug um Deiner Aussage zu wiedersprechen, dass es "offenbar"
sei, dass ein Einheitensystem so wichtig sei, dass es in den Kern
von Programmiersprachen soll.
Wenn dimensionierbare Zahlen wichtig sind, dann bedeutet die projekt-
bezogene "Wichtigkeit" für mich kein Entscheidungskriterium für:
- Sprach-Kern
- Bücherei
Nach dem Motto: was "wichtig" ist, kommt in den Sprachkern.
Dann hätte C++ schon lange keine Library mehr.

Wichtig sind die Nutzungsfragen der Sprache: ist die Flexibilität
und DIY-Eigenschaft einer Bücherei à la C++ für normale
Anwendungsprogrammierer ein Vorteil? Sind die Benutzer-definierten
Suffixe in den Kern von C++ aufgenommen worden, weil sie wichtig
sind, also keine Büchereilösung erlaubt hätten?
Post by Matthias Frey
So selbstbewusst vorgetragen wie dein "offenbar"
das ich, wie gesagt, gern durch "wenn" ersetze. Ich bemerke nur,
dass hier und anderswo sich Programmierer und Unternehmer über
die Sache dimensionierte Zahlen eine Menge Gedanken gemacht haben.
Post by Matthias Frey
Wann und wo wurde hier das angenommen (außer von dir)?
Es lohnt sich, Beiträge darauf hin genauer zu studieren.
Post by Matthias Frey
(In den Foren, Zeitschriften und Blogs die ich lese ist derzeit
DevOps das meistgenannte Thema)
Das geht vorbei. Aber carpe diem.
Post by Matthias Frey
"genutzt werden muss"? Damit würdest du die Sprache in vielen
Fällen für suboptimal machen.
"wie selbstverständlich genutzt" und nicht: "nach hinreichender
Zusatzausbildung und nur bei Androhung von Peitschenhieben genutzt".
Auch nicht: "weil der Richtlinien-Moloch das will".
Post by Matthias Frey
Ich sage ja nicht dass ich generell für ein solches Konzept bin,
sondern wehre mich nur dagegen das als brauchbar für alle Fälle
zu definieren.
Eine Lösung, die für dimensionierte Zahlen da ist, wird ja weder
für Buchstäben, noch für "mathematische Zahlen" oder für
Zahlrepräsentationen da sein müssen. Variationen hiervon kann ich
mir grob vorstellen.
Post by Matthias Frey
Da wo ich gerade bin könnten wir tatsächlich so ein System auch
gut gebrauchen. (Das gehört dann auch zu dem einen %)
Andererseits müsste es auch noch viel weiter gehen damit es den
vollen Nutzen bringen könnte.
Na bestens, illustrierst du mal den vollen Nutzen im Unterschied zu
einem dann zu benennenden nicht-vollen Nutzen?
Matthias Frey
2017-03-09 12:12:45 UTC
Permalink
[...]
Post by G.B.
Post by Matthias Frey
Ich sage ja nicht dass ich generell für ein solches Konzept bin,
sondern wehre mich nur dagegen das als brauchbar für alle Fälle
zu definieren.
Eine Lösung, die für dimensionierte Zahlen da ist, wird ja weder
für Buchstäben, noch für "mathematische Zahlen" oder für
Zahlrepräsentationen da sein müssen. Variationen hiervon kann ich
mir grob vorstellen.
Post by Matthias Frey
Da wo ich gerade bin könnten wir tatsächlich so ein System auch
gut gebrauchen. (Das gehört dann auch zu dem einen %)
Andererseits müsste es auch noch viel weiter gehen damit es den
vollen Nutzen bringen könnte.
Na bestens, illustrierst du mal den vollen Nutzen im Unterschied zu
einem dann zu benennenden nicht-vollen Nutzen?
Na dann versuche ich es mal:

Wir verwenden viele Zahlen in unser Software. Meist geht es um Längen,
seltener um Winkel. Da wäre so ein System sinnvoll, damit man nicht
versehentlich eine Länge mit einem Winkel verrechnet.

zu "noch viel weiter gehen":

Sehr oft sind die Zahlen Bestandteil eines Vektors eines
kartesischen Raumes. Dabei handelt es sich (fast) immer um Längen
in der gleichen Einheit (mm). Trotzdem dürfen die nicht immer
verrechet werden sondern nur dann, wenn diese Vektoren im
selben Koordinatensystem sind.
Ein Compiler kann nicht wissen wie bei uns Koordinatensysteme
definiert sind. Eine Implementierung im Sprachkern scheint mir
nicht möglich.
Möglich ist es die Vektoren als Klassen zu implementieren und
die korrekten Koordinatensysteme zur Laufzeit zu prüfen. Per
Operatoren-Overloading ist die Handhabung recht bequem.

Matthias
G.B.
2017-03-10 10:26:43 UTC
Permalink
Post by Matthias Frey
Wir verwenden viele Zahlen in unser Software. Meist geht es um Längen,
seltener um Winkel. Da wäre so ein System sinnvoll, damit man nicht versehentlich eine Länge mit einem Winkel verrechnet.
Sehr oft sind die Zahlen Bestandteil eines Vektors eines
kartesischen Raumes. Dabei handelt es sich (fast) immer um Längen
in der gleichen Einheit (mm). Trotzdem dürfen die nicht immer
verrechet werden sondern nur dann, wenn diese Vektoren im
selben Koordinatensystem sind.
Ein Beispiel für Orthogonales, vermute ich, wenn die Wahl der
Einheiten für ein Koordinatensystem zunächst keine Rücksicht
auf weitere Koordinatensysteme und deren Einheiten nimmt.
Post by Matthias Frey
Ein Compiler kann nicht wissen wie bei uns Koordinatensysteme
definiert sind. Eine Implementierung im Sprachkern scheint mir
nicht möglich.
Möglich ist es die Vektoren als Klassen zu implementieren und
die korrekten Koordinatensysteme zur Laufzeit zu prüfen. Per
Operatoren-Overloading ist die Handhabung recht bequem.
Tatsächlich ist es möglich, die Vektoren als Typen zu definieren
und schon während der Übersetzung prüfen zu lassen, ob die Vektoren
das selbe Koordinatensystem haben. Und das mit sehr alten Mitteln.
Versehentliche Addition von Vektoren mit "+" ist dann bspw. nicht
möglich. Das können verschiedene Sprachen, hier ist eine.

Compiled at: 2017-03-10 10:59:47

pragma Source_Reference (000120, "coord.ada");
120.
121. with VectorOps.Spacey; use VectorOps.Spacey;
122.
123. procedure test_vector_ops is
124. v1 : VE;
125. v2 : VF;
126. z : VE;
127. begin
128. -- cannot add 3-dim vectors and 2-dim vectors:
129. z := v1 + v2;
|
Post by Matthias Frey
invalid operand types for operator "+"
left operand has type "VE" defined at coord.ada:48
right operand has type "VF" defined at coord.ada:55
130. end test_vector_ops;

VE und VF sind Typen, die beide zur Übersetzungszeit einen Typ
festlegen. Sie sind von einem varianten Typ abgeleitet und frieren
dabei die Variante mittels eines (immmer statischen) Aufzähltyps
ein (hier nach Wahl ohne OOP oder dynamisches dispatching, usf.):

--
-- Euclidean_3
--
type VE is new Vector (space => Euclidean_3);

function "+" (left, right: VE) return VE;

--
-- FlatEarth
--
type VF is new Vector (space => FlatEarth);

function "+" (left, right: VF) return VF;

Danach sind VE und VF zwar verwandt, können aber in der Nutzung
nicht versehentlich vermischt werden. Allein das Erfordernis von
"+" ist zovor abstrakt mit `Vector` festgelegt gewesen, sodass
abgeleitete Typen "+" zur Verfügung stellen müssen:

-- add two compatible vectors
function "+" (left, right: Vector) return Vector is abstract;

Das heißt aber noch nicht, dass die Komponenten der Vektoren
(hier array ... of Float) schon dimensionierte Größen wären.
Genau das wäre für mich die wünschenswerte Ergänzung. Die aber
muss nicht zwingend mit der Typtrennung der Vektoren verwoben sein,
sondern kann getrennt und separat bedacht werden.

Verschiedene Einheiten in verschiedenen Koordinatensystemen
können dann bedeutsam werden, wenn mehrere Vektortypen mit
ihren Koordinatensystemen in die Berechnung eingehen:

--
-- mixed operations
--
function project (item : VE) return VF;
Sieghard Schicktanz
2017-03-10 19:53:10 UTC
Permalink
Hallo G.B.,
Post by G.B.
-- Euclidean_3
...
Post by G.B.
function "+" (left, right: VE) return VE;
-- FlatEarth
...
Post by G.B.
function "+" (left, right: VF) return VF;
Danach sind VE und VF zwar verwandt, können aber in der Nutzung
nicht versehentlich vermischt werden. Allein das Erfordernis von
Verwandt? Das sind doch durchaus _verschiedene_ Typen, sie haben halt
gleich aussehende und gleichartig verwendbare Operatoren.
Post by G.B.
"+" ist zovor abstrakt mit `Vector` festgelegt gewesen, sodass
Ahso, d.h. sie haben eine gemeinsame Abstammung. Aber deswegen sind es
trotzdem _verschiedene_ Typen.
Post by G.B.
Das heißt aber noch nicht, dass die Komponenten der Vektoren
(hier array ... of Float) schon dimensionierte Größen wären.
Nee, das heißt das wirklich nicht. Der Begriff "Dimension eines Vektorraums"
hat mit dem Begriff "Dimension" als Einheit für Messwerte _NICHTS_ zu tun,
das sind _vollkommen verschiedene_ Konzepte!
Post by G.B.
Genau das wäre für mich die wünschenswerte Ergänzung. Die aber
Einheiten in Vektorräume einzuführen ist weitestgehend äquivalent zu deren
Einführung bei skalaren Größen (einfachen Zahlen). Normalerweise haben die
Komponentendimensionen von Vektorräumen dieselben Einheiten, aber es kann
auch Fälle geben, in denen das nicht der Fall ist. Das impliziert dann
zusätzlich, daß die Dimensionen nicht austauschbar sind, d.h.
Koordinatensystem in diesen Vektorräumen (so sie diese Bezeichnung
überhaupt verdienen) _nicht_ beliebig orientierbar sind.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
G.B.
2017-03-11 09:02:33 UTC
Permalink
Post by Sieghard Schicktanz
Post by G.B.
Das heißt aber noch nicht, dass die Komponenten der Vektoren
(hier array ... of Float) schon dimensionierte Größen wären.
Nee, das heißt das wirklich nicht. Der Begriff "Dimension eines Vektorraums"
hat mit dem Begriff "Dimension" als Einheit für Messwerte _NICHTS_ zu tun,
das sind _vollkommen verschiedene_ Konzepte!
Post by G.B.
Genau das wäre für mich die wünschenswerte Ergänzung. Die aber
Einheiten in Vektorräume einzuführen ist weitestgehend äquivalent zu deren
Einführung bei skalaren Größen (einfachen Zahlen). Normalerweise haben die
Komponentendimensionen von Vektorräumen dieselben Einheiten, aber es kann
auch Fälle geben, in denen das nicht der Fall ist. Das impliziert dann
zusätzlich, daß die Dimensionen nicht austauschbar sind, d.h.
Koordinatensystem in diesen Vektorräumen (so sie diese Bezeichnung
überhaupt verdienen) _nicht_ beliebig orientierbar sind.
Für den einfachen Fall der Projektion aus Euclidean_3 nach FlatEarth
ergibt sich bei zusätzlich verschiedenen Einheiten folgendes.

Der erste und zweite Raum sind, im erweiterten Typsystem (MKS der GCC),
nicht nur per Typverschiedenheit differenziert. Zusätzlich wird
der erste (3D) in Kubikwürfellänge von 1cm vermessen, der zweite (2D)
in Quadratläuselängen von 1mm. Nur zur Illustration: Würfel in der Luft,
maximale Messauflösung in Zentimeter, Schatten auf Millimeterpapier
darunter liegend, in Millimeter:

131. result.point := (0 => item.location(0),
1 2
Post by Sieghard Schicktanz
Post by G.B.
dimensions mismatch in array aggregate
expected dimension [L**(-4)], found [L**(-3)]
132. 1 => item.location(1));
|
Post by Sieghard Schicktanz
Post by G.B.
expected dimension [L**(-4)], found [L**(-3)]
`result` ist vom Typ VF, `item` ist vom Typ VE. Beide enthalten den
statisch ihren Typ differenzierenden Verweis auf ein Koordinatensystem
und ein array von Fließkommazahlen, die mit unterschiedlichem
MKS-Einheitenbezug im Typsystem vereinbart wurden. Hier also eine
doppelte Verwendung des Typsystems zu Differenzierung. Bei der
Projektion der Komponenten der Vektoren scheitert dann der naive
Versuch, von den drei Komponenten aus dem Raum die x- und y- Koordinaten
der cm-Würfelmessung einfach an die zwei Komponenten der mm-Ebene,
also deren x- und y- Koordinaten zuzuweisen.
(Was der Einheitenfehler wäre.)

Ob weiter gehende Flexibilität möglich ist, z.B. Nicht-MKS-Systeme
einfach zu bauen sind usf., weiß ich mangels Detailkenntnis nicht.
Es wird aber sichtbar, dass Typverschiedenheit und Dimensionalitäts-
Analyse ("dimensionality analysis" im Handbuch) in gewissem Umfang
nebeneinander gesteuert werden können.

Eine Sprachnorm gibt es für das Verfahren m.W. nicht.
Sieghard Schicktanz
2017-03-13 20:17:13 UTC
Permalink
Hallo G.B.,
Post by G.B.
Für den einfachen Fall der Projektion aus Euclidean_3 nach FlatEarth
ergibt sich bei zusätzlich verschiedenen Einheiten folgendes.
Der erste und zweite Raum sind, im erweiterten Typsystem (MKS der GCC),
nicht nur per Typverschiedenheit differenziert. Zusätzlich wird
der erste (3D) in Kubikwürfellänge von 1cm vermessen, der zweite (2D)
in Quadratläuselängen von 1mm. Nur zur Illustration: Würfel in der Luft,
Erstens hat ein "Kubikwürfel" keine _Länge_, sondern bestenfalls eine
_Kanten_länge, zweitens hat ein Kubikwürfel 9 Dimensionen (Kubik:
3-dimensionale Anordnung, Würfel: 3-dimensionales Gebilde), und drittens
hat die _Maßeinheit_ für die Achsen _nichts_, _überhaupt nichts_, mit der
Dimension des Raums zu tun, auch wenn man auch dabei von einer (Maß-)
"Dimension" spricht. Die Maß-Dimension ist eine _zusätzliche_ Eigenschaft
von Objekten _im_ Raum.

...
Post by G.B.
Projektion der Komponenten der Vektoren scheitert dann der naive
Versuch, von den drei Komponenten aus dem Raum die x- und y- Koordinaten
der cm-Würfelmessung einfach an die zwei Komponenten der mm-Ebene,
also deren x- und y- Koordinaten zuzuweisen.
(Was der Einheitenfehler wäre.)
Also haben Deine beiden Raumdefinitionen _unterschiedliche_ Dimensionen?
Dann kann eine direkte Transformation sowieso nicht funktionieren, dann
mußt Du dafür spezifisch eine _Projektion_ definieren, die einige
zusätzliche Informationen benötigt, wie die Orientierung der Achsen der
Räume zueinander und eine Projektionsrichtung, evtl. auch noch ein
Projektions-_Verfahren_. (Jetzt verstehe ich allerdings auch, warum Du
vorher was von "Schatten" geschrieben hast - die Dimension der Räume aus
Deiner Definition war für Außenstehende in keiner Weise erkennbar.)
Post by G.B.
Ob weiter gehende Flexibilität möglich ist, z.B. Nicht-MKS-Systeme
einfach zu bauen sind usf., weiß ich mangels Detailkenntnis nicht.
Das ist ein von der Projektion völlig unabhängiges Problem, und eigentlich
war _das_ asnfangs mal das Thema dieser Diskussion...
Post by G.B.
Es wird aber sichtbar, dass Typverschiedenheit und Dimensionalitäts-
Analyse ("dimensionality analysis" im Handbuch) in gewissem Umfang
nebeneinander gesteuert werden können.
Es wird aber sichtbar, daß die Begriffe (topologische) "Dimension" und
"Dimension" als Maßeinheit für Informatiker recht schwierig zu tzrennen zu
sein scheinen. Dabei soll die Informatik anfangs sogar mal ein Teilgebiet
der Mathematik gewesen sein. Anscheinend ist sie inzwischen in Richtung
Philosophie abgedriftet, einen künstlerischen Einschlag hatte sie ja imeer
schon...
Post by G.B.
Eine Sprachnorm gibt es für das Verfahren m.W. nicht.
Wäre auch verwunderlich - naja, sollte es eigentlich sein. Schließlich ist
das beschriebene _eigentlich_ normale Vektor-Rechnung, lineare Algebra und
so.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
G.B.
2017-03-14 07:14:59 UTC
Permalink
Post by Sieghard Schicktanz
Hallo G.B.,
Post by G.B.
Für den einfachen Fall der Projektion aus Euclidean_3 nach FlatEarth
ergibt sich bei zusätzlich verschiedenen Einheiten folgendes.
Der erste und zweite Raum sind, im erweiterten Typsystem (MKS der GCC),
nicht nur per Typverschiedenheit differenziert. Zusätzlich wird
der erste (3D) in Kubikwürfellänge von 1cm vermessen, der zweite (2D)
in Quadratläuselängen von 1mm. Nur zur Illustration: Würfel in der Luft,
Erstens hat ein "Kubikwürfel" keine _Länge_, sondern bestenfalls eine
_Kanten_länge, zweitens hat ein Kubikwürfel 9 Dimensionen
Wenn man insistiert, ein Hendidyoin wie "Kubikwürfel" im Zusammenhang
nicht zu erkennen… Im allgemeinen Sprachgebrauch, zudem, und in der
3D-Produktion haben die Dinge Länge, Breite und Höhe. Noch so eine
Herausforderung mit dem Wort "Länge"...
Post by Sieghard Schicktanz
drittens
hat die _Maßeinheit_ für die Achsen _nichts_, _überhaupt nichts_, mit der
Dimension des Raums zu tun,
Wer sagt das denn?

Das Wort "Dimension" wird nur mal in zwei Bedeutungen formal verwendet,
und beide Bedeutungen sind hier einschlägig.
Post by Sieghard Schicktanz
Die Maß-Dimension ist eine _zusätzliche_ Eigenschaft
von Objekten _im_ Raum.
Richtig. Darum geht es. (Sagen wir, von Orten im Raum, denn die Objekte
haben per se nur eine Ausdehnung, die wir i.d.R. nur relativ kennen
und denen wir die Eigenschaft für einen gegebenen Raum zuschreiben.)
Das Beispiel aus dem compiler hat gezeigt, dass ein Typsystem
(der GCC) sowohl Räume (3D-Luft, 2D-Tisch) festlegen als auch
zusätzlich die Maßeinheitem cm und mm an die Koordinatentypen binden
kann.
Post by Sieghard Schicktanz
Post by G.B.
Projektion der Komponenten der Vektoren scheitert dann der naive
Versuch, von den drei Komponenten aus dem Raum die x- und y- Koordinaten
der cm-Würfelmessung einfach an die zwei Komponenten der mm-Ebene,
also deren x- und y- Koordinaten zuzuweisen.
(Was der Einheitenfehler wäre.)
Also haben Deine beiden Raumdefinitionen _unterschiedliche_ Dimensionen?
Der eine hat eine Basis der Kardinalzahl 3, der andere eine Basis der
Kardinalzahl 2. Der eine hat Länge, Breite und Höhe in cm, der andere
hat Länge und Breite in mm.
Post by Sieghard Schicktanz
Dann kann eine direkte Transformation sowieso nicht funktionieren, dann
mußt Du dafür spezifisch eine _Projektion_ definieren, die einige
zusätzliche Informationen benötigt, wie die Orientierung der Achsen der
Räume zueinander und eine Projektionsrichtung, evtl. auch noch ein
Projektions-_Verfahren_. (Jetzt verstehe ich allerdings auch, warum Du
vorher was von "Schatten" geschrieben hast - die Dimension der Räume aus
Deiner Definition war für Außenstehende in keiner Weise erkennbar.)
O.K. und richtig: ich will erreichbar wissen, dass die Berechnung der
Projektion aus Koordinatensystem Euclidean_3 in das Koordinatensystem
FlatEarth nicht durch die Annahme einer falschen Längeneinheit (cm statt
mm) falsch wird, also dann um den Faktor 10 gestaucht. Der Faktor 10
ist, was der compiler für mich rechtzeitig als Fehler markiert hat,
unabhängig von der (hier: trivialen) Berechnung der Projektion. Er tut
das mit Bezug auf die Größensystem-Dimension mit Namen "Meter" (einer
der explizit so vorgegebenen formalen Askpekte der Typdefinition),
im genannten, ergänzten Typsystem der GCC:


131. result.point := (0 => item.location(0),
1 2
Post by Sieghard Schicktanz
Post by G.B.
dimensions mismatch in array aggregate
expected dimension [L**(-4)], found [L**(-3)]
...
L**(-4) ≘ mm
L**(-3) ≘ cm

Dass der compiler nicht durch Typkonversion die Orte des Schattenwurfs
eines Würfels auf dem Schreibtisch im Vorab berechnet, hatte ich
stillschweigend angenommen und in

Euclidean_3 -> FlatEarth

unzureichend spezifiziert.
Post by Sieghard Schicktanz
Post by G.B.
Ob weiter gehende Flexibilität möglich ist, z.B. Nicht-MKS-Systeme
einfach zu bauen sind usf., weiß ich mangels Detailkenntnis nicht.
Das ist ein von der Projektion völlig unabhängiges Problem, und eigentlich
war _das_ asnfangs mal das Thema dieser Diskussion...
Die Projektion ist von Maßeinheiten im Ergebnis gar nicht unabhängig, wenn
bswp. Koordinaten als Zahlen aus dem Nicht-USA-Gebiet in das USA-Gebiet
zur Interpretation abgebildet werden und wenn dort nicht metrisch gerechnet
wird.
Post by Sieghard Schicktanz
Post by G.B.
Es wird aber sichtbar, dass Typverschiedenheit und Dimensionalitäts-
Analyse ("dimensionality analysis" im Handbuch) in gewissem Umfang
nebeneinander gesteuert werden können.
Es wird aber sichtbar, daß die Begriffe (topologische) "Dimension" und
"Dimension" als Maßeinheit für Informatiker recht schwierig zu tzrennen zu
sein scheinen.
Die Dimension eines topologischen Raums ist m.W. nicht einmal
jedem Mathematiker geläufig. Anders als die Dimension eines Vektorraums.
Post by Sieghard Schicktanz
Post by G.B.
Eine Sprachnorm gibt es für das Verfahren m.W. nicht.
Wäre auch verwunderlich - naja, sollte es eigentlich sein. Schließlich ist
das beschriebene _eigentlich_ normale Vektor-Rechnung, lineare Algebra und
so.
Was denn jetzt schließlich?
- Vektorrechnung mit Zahlen für Komponentendarstellungen
oder vielmehr
-Vektorrechnung mit Zahlen-mit-Größensystem-Dimension für
Komponentendarstellungen?
M.W. gehört letztere nicht zum Ausbildungs-Kanon "Lineare Algebra",
sondern nur erstere.
G.B.
2017-03-14 07:17:23 UTC
Permalink
Post by Sieghard Schicktanz
Hallo G.B.,
Post by G.B.
Für den einfachen Fall der Projektion aus Euclidean_3 nach FlatEarth
ergibt sich bei zusätzlich verschiedenen Einheiten folgendes.
Der erste und zweite Raum sind, im erweiterten Typsystem (MKS der GCC),
nicht nur per Typverschiedenheit differenziert. Zusätzlich wird
der erste (3D) in Kubikwürfellänge von 1cm vermessen, der zweite (2D)
in Quadratläuselängen von 1mm. Nur zur Illustration: Würfel in der Luft,
Erstens hat ein "Kubikwürfel" keine _Länge_, sondern bestenfalls eine
_Kanten_länge, zweitens hat ein Kubikwürfel 9 Dimensionen
Wenn man insistiert, ein Hendiadyoin wie "Kubikwürfel" im Zusammenhang
nicht zu erkennen… Im allgemeinen Sprachgebrauch, zudem, und in der
3D-Produktion haben die Dinge Länge, Breite und Höhe. Noch so eine
Herausforderung mit dem Wort "Länge"...
Post by Sieghard Schicktanz
drittens
hat die _Maßeinheit_ für die Achsen _nichts_, _überhaupt nichts_, mit der
Dimension des Raums zu tun,
Wer sagt das denn?

Das Wort "Dimension" wird nur mal in zwei Bedeutungen formal verwendet,
und beide Bedeutungen sind hier einschlägig.
Post by Sieghard Schicktanz
Die Maß-Dimension ist eine _zusätzliche_ Eigenschaft
von Objekten _im_ Raum.
Richtig. Darum geht es. (Sagen wir, von Orten im Raum, denn die Objekte
haben per se nur eine Ausdehnung, die wir i.d.R. nur relativ kennen
und denen wir die Eigenschaft für einen gegebenen Raum zuschreiben.)
Das Beispiel aus dem compiler hat gezeigt, dass ein Typsystem
(der GCC) sowohl Räume (3D-Luft, 2D-Tisch) festlegen als auch
zusätzlich die Maßeinheitem cm und mm an die Koordinatentypen binden
kann.
Post by Sieghard Schicktanz
Post by G.B.
Projektion der Komponenten der Vektoren scheitert dann der naive
Versuch, von den drei Komponenten aus dem Raum die x- und y- Koordinaten
der cm-Würfelmessung einfach an die zwei Komponenten der mm-Ebene,
also deren x- und y- Koordinaten zuzuweisen.
(Was der Einheitenfehler wäre.)
Also haben Deine beiden Raumdefinitionen _unterschiedliche_ Dimensionen?
Der eine hat eine Basis der Kardinalzahl 3, der andere eine Basis der
Kardinalzahl 2. Der eine hat Länge, Breite und Höhe in cm, der andere
hat Länge und Breite in mm.
Post by Sieghard Schicktanz
Dann kann eine direkte Transformation sowieso nicht funktionieren, dann
mußt Du dafür spezifisch eine _Projektion_ definieren, die einige
zusätzliche Informationen benötigt, wie die Orientierung der Achsen der
Räume zueinander und eine Projektionsrichtung, evtl. auch noch ein
Projektions-_Verfahren_. (Jetzt verstehe ich allerdings auch, warum Du
vorher was von "Schatten" geschrieben hast - die Dimension der Räume aus
Deiner Definition war für Außenstehende in keiner Weise erkennbar.)
O.K. und richtig: ich will erreichbar wissen, dass die Berechnung der
Projektion aus Koordinatensystem Euclidean_3 in das Koordinatensystem
FlatEarth nicht durch die Annahme einer falschen Längeneinheit (cm statt
mm) falsch wird, also dann um den Faktor 10 gestaucht. Der Faktor 10
ist, was der compiler für mich rechtzeitig als Fehler markiert hat,
unabhängig von der (hier: trivialen) Berechnung der Projektion. Er tut
das mit Bezug auf die Größensystem-Dimension mit Namen "Meter" (einer
der explizit so vorgegebenen formalen Askpekte der Typdefinition),
im genannten, ergänzten Typsystem der GCC:


131. result.point := (0 => item.location(0),
1 2
Post by Sieghard Schicktanz
Post by G.B.
dimensions mismatch in array aggregate
expected dimension [L**(-4)], found [L**(-3)]
...
L**(-4) ≘ mm
L**(-3) ≘ cm

Dass der compiler nicht durch Typkonversion die Orte des Schattenwurfs
eines Würfels auf dem Schreibtisch im Vorab berechnet, hatte ich
stillschweigend angenommen und in

Euclidean_3 -> FlatEarth

unzureichend spezifiziert.
Post by Sieghard Schicktanz
Post by G.B.
Ob weiter gehende Flexibilität möglich ist, z.B. Nicht-MKS-Systeme
einfach zu bauen sind usf., weiß ich mangels Detailkenntnis nicht.
Das ist ein von der Projektion völlig unabhängiges Problem, und eigentlich
war _das_ asnfangs mal das Thema dieser Diskussion...
Die Projektion ist von Maßeinheiten im Ergebnis gar nicht unabhängig, wenn
bswp. Koordinaten als Zahlen aus dem Nicht-USA-Gebiet in das USA-Gebiet
zur Interpretation abgebildet werden und wenn dort nicht metrisch gerechnet
wird.
Post by Sieghard Schicktanz
Post by G.B.
Es wird aber sichtbar, dass Typverschiedenheit und Dimensionalitäts-
Analyse ("dimensionality analysis" im Handbuch) in gewissem Umfang
nebeneinander gesteuert werden können.
Es wird aber sichtbar, daß die Begriffe (topologische) "Dimension" und
"Dimension" als Maßeinheit für Informatiker recht schwierig zu tzrennen zu
sein scheinen.
Die Dimension eines topologischen Raums ist m.W. nicht einmal
jedem Mathematiker geläufig. Anders als die Dimension eines Vektorraums.
Post by Sieghard Schicktanz
Post by G.B.
Eine Sprachnorm gibt es für das Verfahren m.W. nicht.
Wäre auch verwunderlich - naja, sollte es eigentlich sein. Schließlich ist
das beschriebene _eigentlich_ normale Vektor-Rechnung, lineare Algebra und
so.
Was denn jetzt schließlich?
- Vektorrechnung mit Zahlen für Komponentendarstellungen
oder vielmehr
-Vektorrechnung mit Zahlen-mit-Größensystem-Dimension für
Komponentendarstellungen?
M.W. gehört letztere nicht zum Ausbildungs-Kanon "Lineare Algebra",
sondern nur erstere.
G.B.
2017-03-14 07:27:15 UTC
Permalink
Post by G.B.
...
L**(-4) ≘ mm
L**(-3) ≘ cm
Die -4 und -3 sind mein Fehlgriff der Potenz 1.
(Kommt vielleicht vom Alltag, der 4 Stellen in Millimeterangaben
für Holzbemaßung hatte. Symbolische Namen sind ein Segen.)

Matthias Frey
2017-03-13 13:59:41 UTC
Permalink
Post by G.B.
Post by Matthias Frey
Ein Compiler kann nicht wissen wie bei uns Koordinatensysteme
definiert sind. Eine Implementierung im Sprachkern scheint mir
nicht möglich.
Möglich ist es die Vektoren als Klassen zu implementieren und
die korrekten Koordinatensysteme zur Laufzeit zu prüfen. Per
Operatoren-Overloading ist die Handhabung recht bequem.
Tatsächlich ist es möglich, die Vektoren als Typen zu definieren
und schon während der Übersetzung prüfen zu lassen, ob die Vektoren
das selbe Koordinatensystem haben.
Leider Nein. Die Koordinatensysteme (d.h. die Lage und Rotation)
werden ja erst zur Laufzeit bestimmt

Matthias
G.B.
2017-03-13 18:20:28 UTC
Permalink
Post by Matthias Frey
Post by G.B.
Post by Matthias Frey
Ein Compiler kann nicht wissen wie bei uns Koordinatensysteme
definiert sind. Eine Implementierung im Sprachkern scheint mir
nicht möglich.
Möglich ist es die Vektoren als Klassen zu implementieren und
die korrekten Koordinatensysteme zur Laufzeit zu prüfen. Per
Operatoren-Overloading ist die Handhabung recht bequem.
Tatsächlich ist es möglich, die Vektoren als Typen zu definieren
und schon während der Übersetzung prüfen zu lassen, ob die Vektoren
das selbe Koordinatensystem haben.
Leider Nein. Die Koordinatensysteme (d.h. die Lage und Rotation)
werden ja erst zur Laufzeit bestimmt
Nur zum Verständnis:

- die Vektorraum-Dimension (Kardinalzahl der Basis, Anzahl der Koordinaten)
des Raumes steht also zur Übersetzungszeit fest?
- sind es euklidische Räume?
- hat die Lage eines Raumes Einfluss auf (a) seine eigenen Längeneinheiten
oder (b) die "Art" der Koordinaten (Polar bspw.)?
- Ändern sich mit der Rotation eines Koordinatensystem seine
Dimensionen wie Länge? Einheiten?
Sieghard Schicktanz
2017-03-13 20:36:33 UTC
Permalink
Hallo G.B.,
Post by G.B.
- die Vektorraum-Dimension (Kardinalzahl der Basis, Anzahl der
Koordinaten) des Raumes steht also zur Übersetzungszeit fest?
Sollte wohl tunlichst so sein, Räume, die im Laufe einer Berechnung ihre
Dimension verändern sind derzeit in der Mathematik nicht vorgesehen.
Post by G.B.
- sind es euklidische Räume?
Das kommt auf ihre Metrik an - der dreidimensionale Raum, der unseren
Lebensraum beschreibt, ist es z.B. nicht (Kugelkoordinaten).
Post by G.B.
- hat die Lage eines Raumes Einfluss auf (a) seine eigenen Längeneinheiten
oder (b) die "Art" der Koordinaten (Polar bspw.)?
Da erhebt sich die Frage, was "die Lage eines Raumes" bedeuten soll. Eine
"Lage" ist immer nur relativ zu erkennbaren Objekten angebbar. Meinst Du
damit aber vielleicht "die Orientierung eines Koordinatensystems im Raum"?
Das kommt auf seine Transformationseigenschaften an, bei Räumen mit lokal
euklidischer Metrik (und damit richtungsunabhängiger Maß-Dimension)
bestimmt das die Metrik, bei Räumen mit inhomogenen Maß-Einheiten sind die
Transformationen stark eingeschränkt.
Post by G.B.
- Ändern sich mit der Rotation eines Koordinatensystem seine
Dimensionen wie Länge? Einheiten?
Soweit beliebige Rotationen möglich sein sollen, müssen _alle_
Orientierungen dieselben Einheiten (im Sinne von "Länge" o.ä-) besizzen.
Da lokal _jeder_ solche Raum quasi-euklidisch angenähert werden kann, ist
die Antwort damit "lokal ändert sich nichts".
"Räume" mit "Dimensionen" unterschiedlicher Art (Maß-Einheit), wie bei
grafischen Darstellungen üblich (Position über Zeit, Spannung über
Strom u.ä.) lassen keine beliebigen Rotationen zu, sondern lediglich
Achsenvertauschungen und Skalierungen. Das sollte auch dafür die Frage
beantworten.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Thomas Koenig
2017-03-13 22:33:07 UTC
Permalink
Post by Sieghard Schicktanz
Hallo G.B.,
Post by G.B.
- die Vektorraum-Dimension (Kardinalzahl der Basis, Anzahl der
Koordinaten) des Raumes steht also zur Übersetzungszeit fest?
Sollte wohl tunlichst so sein, Räume, die im Laufe einer Berechnung ihre
Dimension verändern sind derzeit in der Mathematik nicht vorgesehen.
Post by G.B.
- sind es euklidische Räume?
Das kommt auf ihre Metrik an - der dreidimensionale Raum, der unseren
Lebensraum beschreibt, ist es z.B. nicht (Kugelkoordinaten).
Huh? Kugelkoordinaten beschreiben keinen euklidschen Raum... ?
Peter J. Holzer
2017-03-10 06:46:57 UTC
Permalink
Post by Matthias Frey
Post by G.B.
eine wie auch immer geartete Lösung für dimensionierte Größen
tatsächlich wie selbstverständlich genutzt werden muss. Sonst ist
sie nicht wirksam. Dieser Umstand lässt, z.B. wegen des Lernaufwands
und der komplexen technischen Verstrickung einen Büchereilösung wie
boost::unit suboptimal erscheinen. Zumal für die häufig verwendeten
Sprachen suboptimal, wie "Nicht-C++" oder "Nicht-GNAT" oder
"Nicht-Haskell".
"genutzt werden muss"? Damit würdest du die Sprache in vielen
Fällen für suboptimal machen.
Ich glaube, Du hast G.B. hier falsch verstanden. Es geht nicht darum,
den Programmierer zu zwingen, das Feature zu nützen, sondern das Feature
muss so gestaltet sein, dass es der Programmierer ganz
selbstverständlich nützt. Und da gebe ich G.B. recht: Nur wenn das der
Fall ist, ist das Feature sinnvoll. Sonst werden es die meisten
Programmierer einfach nicht nützen und daher auch nicht davon
profitieren.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Koenig
2017-03-09 21:37:19 UTC
Permalink
Post by Matthias Frey
Ich behaupte es ist "offenbar", dass man das in 99% der Anwendungen
nicht braucht.
103,4% aller Statistiken sind frei erfunden :-)
Post by Matthias Frey
Also bitte haltet das bitte aus dem Kern der üblichen Sprachen raus.
Was spricht denn dagegen, das z.B. in eine Sprache wie Fortran mit
reinzupacken? Die wir ja berüchtigterweise von Physikern und
Ingenieuren wieder ganz gerne verwendet, seitdem sie deutlich
modernisiert wurde.
Thomas Koenig
2017-02-06 23:34:38 UTC
Permalink
Post by G.B.
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Gramm ist eine Masse, kein Gewicht.
Post by G.B.
Eigentlich ist "Spannung" eine Bezeichnung für ein physikalisches Phänomen.
Spannung ist Energie pro Ladung (oder entsprechend Äquivalentes), kein
Phänomen.
G.B.
2017-02-07 08:31:24 UTC
Permalink
Post by Thomas Koenig
Post by G.B.
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Gramm ist eine Masse, kein Gewicht.
Es gibt einen Zusammenhang, in dem Gramm die Einheit von Masse ist.

Den Arzt erwähnte ich schon, der nach dem Gewicht fragt, und mit Recht,
und dem man mit "Kilo" antwortet, "Kilogramm" abkürzend.
Post by Thomas Koenig
Post by G.B.
Eigentlich ist "Spannung" eine Bezeichnung für ein physikalisches Phänomen.
Spannung ist Energie pro Ladung (oder entsprechend Äquivalentes), kein
Phänomen.
Phänomen i.S.v. Naturerscheinung:
https://de.wikipedia.org/wiki/Naturerscheinung

Den Nutzen von Äquivalenten für die Programmierung ordne ich dann
nochmal als eher nicht vorhanden ein.

Spannung ist, was wir den Polen einer Batterie zuschreiben
können, was ihnen i.d.S. eigentlich ist: Die Phänomene sind erlebbar
und messbar, z.B. Boolesch mit der Zunge. Programme sollen "5 Volt"
enthalten können. Besonders dann, wenn die Programme weder auf Ladung
noch auf Energie Bezug nehmen, aber an ein Voltmeter angeschlossen
sind oder eine Spannung an einer Leuchte anlegen.

Programmierer sollen Achslast in programm-definierten Tonnen-Achslast angeben
können, gemäß StVZO, ohne dass ihnen Überlegungen über die Angemessenheit
der Worte "Masse" oder "Gewicht" fachfremd aufgedrängt werden. Die
Wortwahl der StVZO ist dann maßgeblich für die Typdefinition.
Juergen Ilse
2017-02-07 10:22:14 UTC
Permalink
Hallo,
Post by G.B.
Post by Thomas Koenig
Post by G.B.
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Gramm ist eine Masse, kein Gewicht.
Es gibt einen Zusammenhang, in dem Gramm die Einheit von Masse ist.
Gramm (oder Kilogramm) ist *immer* die Einheit fuer die Masse, niemals eine
einheit fuer Gewicht.
Post by G.B.
Den Arzt erwähnte ich schon, der nach dem Gewicht fragt, und mit Recht,
und dem man mit "Kilo" antwortet, "Kilogramm" abkürzend.
Weil hier (umgangssprachlich) geschlampt wird bei den Begriffen.
Bei technischen und/oder wissenschalftlichen Themen sollte man derartige
Schlamperei mit den Begriffen tunlichst zugunsten der Exaktheit der dar-
gestellten Sachverhalte unterlassen.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
PS: Bzgl. deines Hinweises auf Achslast und STVzO muss man sagen, dass
letztere eben keine wissenschaftliche oder technische Dokumentation ist,
und daher die umgangssprachlich uebliche Schlamperei mit den Begriffen
durchaus in deren Kontext sinnvoll sein koennte.
G.B.
2017-02-07 12:32:48 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by G.B.
Post by Thomas Koenig
Post by G.B.
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Gramm ist eine Masse, kein Gewicht.
Es gibt einen Zusammenhang, in dem Gramm die Einheit von Masse ist.
Gramm (oder Kilogramm) ist *immer* die Einheit fuer die Masse, niemals eine
einheit fuer Gewicht.
Auf einem runden, meist metallenen Gewicht für Waagen stehen Angaben
in kg oder g drauf. Niemand kam oder kommt auf die Idee, dass damit ihre
produktive Verwendung Schaden nimmt, oder die Verständigung mit "Masse"
besser wäre, als mit "Prüfgewicht" oder "Feingewicht".

Zur Entspannung: "Ich hätt' gern 'ne Flasche Pommes Frites".
Post by Juergen Ilse
Post by G.B.
Den Arzt erwähnte ich schon, der nach dem Gewicht fragt, und mit Recht,
und dem man mit "Kilo" antwortet, "Kilogramm" abkürzend.
Weil hier (umgangssprachlich) geschlampt wird bei den Begriffen.
Die Scheuklappen tragenden unter den Physikern maßen sich
manchmal an, ihre vorteilhaft reduzierte Sicht auf die Welt
würde auch über die Reichweite von Physik und Technik hinaus
immer sinnvolle Festlegungen treffen, oder bestehende über
den Haufen werfen müssen. Das ist für sie auch bequem.
Post by Juergen Ilse
Bei technischen und/oder wissenschalftlichen Themen sollte man derartige
Schlamperei mit den Begriffen tunlichst zugunsten der Exaktheit der dar-
gestellten Sachverhalte unterlassen.
Richtig, nur sind eben Wissenschaften, auch wenn angewandt, manchmal mehr,
als Physik zu bieten hat und vor allem zu erfassen oder gar zu erklären
in der Lage ist. Deshalb ist ihr Begriffsapparat nicht immer angemessen.
Juergen Ilse
2017-02-07 14:34:09 UTC
Permalink
Hallo,
Post by G.B.
Post by Juergen Ilse
Post by G.B.
Post by Thomas Koenig
Post by G.B.
Ein halbes Pfund (Butter) -> Gewicht und nichts sonst
250 Gramm (Butter) -> Gewicht und nichts sonst
Gramm ist eine Masse, kein Gewicht.
Es gibt einen Zusammenhang, in dem Gramm die Einheit von Masse ist.
Gramm (oder Kilogramm) ist *immer* die Einheit fuer die Masse, niemals eine
einheit fuer Gewicht.
Auf einem runden, meist metallenen Gewicht für Waagen stehen Angaben
in kg oder g drauf.
Was damit bestimmt werden soll, ist ja auch die Masse. Die Methode zur
Bestimmung der Masse macht sich zu nutze, dass unter ansonsten gleichen
Randbedingungen Gewicht und Masse proportional sind. Trotzdem ist der
Zweck der Waage die Massenbestimmung, und daher sind die oben genannten
Objekte auch mit der Angabe ihrer Masse beschriftet.
Post by G.B.
Zur Entspannung: "Ich hätt' gern 'ne Flasche Pommes Frites".
"Haben sie denn auch die leeren Flaschen mitgebracht?"
Post by G.B.
Post by Juergen Ilse
Post by G.B.
Den Arzt erwähnte ich schon, der nach dem Gewicht fragt, und mit Recht,
und dem man mit "Kilo" antwortet, "Kilogramm" abkürzend.
Weil hier (umgangssprachlich) geschlampt wird bei den Begriffen.
Die Scheuklappen tragenden unter den Physikern maßen sich
manchmal an, ihre vorteilhaft reduzierte Sicht auf die Welt
würde auch über die Reichweite von Physik und Technik hinaus
immer sinnvolle Festlegungen treffen, oder bestehende über
den Haufen werfen müssen. Das ist für sie auch bequem.
Wenn man physikalische Vorgaenge mit Hilfe eines Digitalrechners voraus-
berechnen will, ist es vorteilhaft, die Zusammenhaenge zu kennen und sich
wirklich bewusst zu sein. Dazu ist es sinnvoll auf solche Schlampereien
wie das durcheinanderwerfen von Begriffen wie "Masse" und "Gewicht" zu
verzichten. Zumal man dann teils auch Fehler allein daran erkennen kann,
dass bei einer schriftlichen BErechnung (zwecks Kontrolle der verwendeten
Algorithmen) ploetzlich eine falsche Einheit dabei herauskaeme ...
Masse und Gewicht haben unterschiedliche Einheiten (ersteres kg, letzteres N).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Matthias Frey
2017-02-03 10:31:33 UTC
Permalink
Post by G.B.
Die IT-Entscheider wissen andererseits zu sagen, dass es auf wichtigere
Dinge ankommt, werden die Schultern zucken und weiter alle dieselben
Folgen in Kauf nehmen, oder nicht?
Ja, weil es heutzutage meitens auf "wichtigere Dinge" ankommt.
Dass man wirklich mit verschiedenen Einheiten rechnet ist doch
recht selten. Meistens gilt hat man Integer für eine Anzahl
und ein Festkommatyp für Währungen.

Wir hier haben auch das Problem mit verschiedenen Einheiten.
Mal sind es Millimeter mal Inch sind. Mal sind es Längen, mal
Winkel, mal was anderes.
Meist ist das kein Problem, weil bei Längen wird intern immer
in Millimeter gerechnet und nur in der UI wird dann entsprechend
gewandelt.
Aber wie gesagt, wir sind da eher eine Ausnahme. Und selbst damit
sind für uns andere Tehmen wichtiger (z.B. DevOps)

Matthias
G.B.
2017-02-03 11:58:14 UTC
Permalink
Post by Matthias Frey
Meist ist das kein Problem, weil bei Längen wird intern immer
in Millimeter gerechnet und nur in der UI wird dann entsprechend
gewandelt.
Dann wäre es vermutlich kein Problem, wenn die interne Rechnung
mit de facto Millimetern vom compiler durch Typprüfung bestätigt
werden könnte?
Peter J. Holzer
2017-02-03 18:35:37 UTC
Permalink
Post by G.B.
Post by Peter J. Holzer
Warum sträuben sich fast alle Sprachentwickler, so etwas wie
Zahlen ausdrücklich für Repräsentationen vorzusehen und
Programmierern nahe zu legen, für Meter usw, nur Typen,
nicht aber den Typ verwischende Repräsentation zu verwenden?
Du hast offenbar das Thema der letzten paar Postings in diesem Thread
nicht ganz mitbekommen: Genau darum ging es.
Dass die Sprachentwickler sich sträuben, Einheitensysteme
im Typsystem anzubieten, stimmt sehr wohl, das galt auch für C++,
s.u.
Das ist aber nicht das, was Du behauptet hast.

[...]
Post by G.B.
Was also kann bspw. den stereotypen Sprach-Fanatiker dazu bringen,
nicht mehr mit dem Finger auf die Norm zu zeigen, als müsse
man mit diesem Baseballschläger gegen jede technischen Veränderung
vorgehen? (Dann wären wir übrigens noch bei C with Classes...)
Zwei Dinge helfen immer, wenn man jemanden überzeugen will:
1) Nicht schwurbeln
2) Nicht beleidigend werden.

Auch sehr hilfreich ist ein konkreter Vorschlag, noch besser
existierender Code. "Jemand müsste doch irgendwas machen" und "das wäre
ja ganz einfach" ist eher ein Anzeichen dafür, dass derjenige, der da
was fordert, noch nicht mal ernsthaft darüber nachgedacht hat,
geschweige denn das Problem lösen könnte.

Im konkreten Fall bin ich nicht überzeugt, dass physikalische Einheiten
im Sprachkern einer general purpose Programmiersprache etwas verloren
haben. Sie sind zwar für einige Probleme praktisch, aber selbst dafür
nicht ausreichend (zwei Temperaturen in °C kannst Du nicht sinnvoll
addieren, obwohl sie die gleiche Einheit haben. Die Summe zweier
Temperaturdifferenzen (oder einer Temperatur und einer Differenz)
hingegen schon). Teilweise ist das sicher auch applikationsspezifisch
(siehe z.B. die Höhe in diesem Thread - in manchem Kontext ist eine
negative Höhe sinnvoll, in einem anderen nicht).

Für viele andere Probleme aber braucht man entweder nicht-physikalische
Einheiten (z.B. Währungen - viel Spaß, da ein allgemeingültiges
Einheitensystem zu basteln) oder hat ganz andere Kriterien dafür, welche
Operatoren auf welche Kombinationen von Werten angewendet werden können.
Z.B. ob ein Input aus einer vertrauenswürdigen Quelle oder vom User
stammt.

Im Sprachkern hätte ich also wohl gerne ein sehr flexibles System, aus
dem ich mir meine benötigten Typen selbst bauen kann. Wenn es dann für
ein paar Anwendungsgebiete Standardlibraries gibt, umso besser.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-02-05 08:21:55 UTC
Permalink
Post by Peter J. Holzer
Auch sehr hilfreich ist ein konkreter Vorschlag, noch besser
existierender Code. "Jemand müsste doch irgendwas machen" und "das wäre
ja ganz einfach" ist eher ein Anzeichen dafür, dass derjenige, der da
was fordert, noch nicht mal ernsthaft darüber nachgedacht hat,
geschweige denn das Problem lösen könnte.
Ein Typsystems, das dem unterstellten Sachwissen der Programmierer
angemessen wäre, in einer Sprache bereit zu stellen, wäre nicht einfach.
Aber es gibt durchaus schon Vorlagen zum Abkupfern.

Unternehmerische Unternehmer, die auf ihrer Seite einen
Kostennachteil erkennen, der ihnen ggf. durch Einsatz mangelhafter
IT-Werkzeuge entsteht, können, dadurch motiviert, anstreben,
die Mängel zu beheben. Hierbei ist nur eines besser, als
das tatenlose Warten auf ein fertiges Angebot von fingierten Dritten:
Kooperation für Infrastruktur. Nicht im Sinn eines Kartells, aber
in dem Sinn, in dem Maschinenbau-Unternehmen auch von weitgehend
einheitlichen Gewinde-Steigungen an Maschinenschrauben profitiert
haben:

Angenommen, fast allen der N IT-Unternehmen einer Volkswirtschaft
entstehen in jedem Geschäftsjahr durch Kauf oder durch Lizenznahme
suboptimaler Entwicklungs-Werkzeuge Kosten, z.B. durch crashes
der Produkte, dann durch Abschmelzen der Reputation, oder durch
nicht erbetene Migrationsarbeit (Windows 7 bei Daimler) die auf
die Suboptimalität der Entwicklungs-Werkzeuge zurück geführt werden
können. Ausgaben für Entwicklungs-Werkzeuge werden als Ausgaben
für Infrastruktur gewertet, insofern fast alle N IT-Unternehmen
Werkzeuge gleicher Art benötigen: C-compiler sind wie
Maschinenschrauben oder ein Wasseranschluss: nichts geht ohne.

Angenommen ferner, ein relevanter Mangel dieser IT-Infrastruktur
wird im dimensionslosen Typsystem identifiziert.

Was tun, um die Mängel zu beheben und so die Kosten zu vermeiden?

Wirtschaftlich unwahrscheinlich erscheint, dass das Warten auf
jemand, der sich allein hinsetzt und einen überzeugenden Entwurf
eines besseren Typsystems entwickelt. Denn Diese Person bedürfte
nicht nur eines plausiblen Anreizes, eines finanziellen Polsters,
sondern müsste auch Compiler-Herstellern die Lösung schmackhaft machen.
Ferner müssten auch diejenigen Programmierer das neue Typsystem
einzusetzen bereit sein, die vielleicht bisher eine eigene "Lösung"
verkaufen konnten, die auf hausinternen Konventionen ruht.

Also stehen viele Einzelinteressen und individuelle Opportunitäts-
Überlegungen den Erfolgsaussichten eines Vorschlags entgegen, der
auf einen Einzelkämpfer setzt, auf jemand, der aus eigenen Stücken
über die Sache nachdenkt, das Problem löst, anzubieten versucht.
Und dann "schauen wir mal", ob uns das überzeugt. Diese Haltung,
die man mit gewissem Recht als bequem und wenig unternehmerisch
bezeichnen darf, ist ja durchaus hier und da zu erleben.
Organisationswissenschaftlich würde ich sie unter höfliches
Schulterzucken subsumieren: eine Folge von im Aggregat zuckenden
Schultern ist offenkundig, dass nämlich dieses Stück der sich
so organisierenden IT-Produktion fortfährt, Geld, Zukunft, und
Chancen mit suboptimalen Werkzeugen zu verbrennen.
G.B.
2017-02-05 08:24:46 UTC
Permalink
Post by Peter J. Holzer
Im konkreten Fall bin ich nicht überzeugt, dass physikalische Einheiten
im Sprachkern einer general purpose Programmiersprache etwas verloren
haben.
Physikalische Einheiten sehe ich auch nicht als zielführend, auch nicht
als notwendig an: Die konkreten Fälle deuten im Abstrakten, also in für
den general purpose, auf ein allgemeines Typsystem, das fachlich blind
ist, das aber dimensionierte Größen auszudrücken ermöglicht.

Angenommen beispielsweise, jemand fände es sinnvoll, die Temperatur mehrerer
Gase an einer Stelle in einem Programm zu addieren, weil er oder sie
statistisch die mittlere Tagestemperatur im Sommer ausrechnen möchte.
Für diesen Fall würde ein Übersetzer voreilig entscheiden, der schon
eingebaut hätte, dass die Summe von Temperaturen aus dem Blickwinkel
nur einer bestimmten Theorie gesehen keinen Sinn hat.
Post by Peter J. Holzer
Im Sprachkern hätte ich also wohl gerne ein sehr flexibles System, aus
dem ich mir meine benötigten Typen selbst bauen kann. Wenn es dann für
ein paar Anwendungsgebiete Standardlibraries gibt, umso besser.
Ja, das ist die Idee.
Thomas Koenig
2017-02-02 20:57:42 UTC
Permalink
Post by Peter J. Holzer
'A' == 65
[...]
Dass diese Gleichung im Ausdrucksvorrat der Programmierer
weiter Bestand hat, statt für illegal erklärt und vom
compiler-Hersteller mit eineindeutiger, persistenter
Programmtransformation beseitigt zu werden, ist irgendwie
entlarvend.
C ist C. Es gibt genügend andere Sprachen, wo diese Gleichung nicht
gilt.
Es gibt auch C-Compiler, für die die Gleichung nicht gilt (bzw.
der Ausdruck den Wert 0 hat).

#ifdef NOSTALGIA

Ich habe auf so einer Maschine auch mal was in C programmiert,
auch wenn es sich irgendwie komisch anfühlte. Vor allem musste
man erstmal die Zeilennummern im Editor abschalten...

#endif
Peter J. Holzer
2017-02-03 18:15:52 UTC
Permalink
Post by Thomas Koenig
Post by Peter J. Holzer
'A' == 65
[...]
Dass diese Gleichung im Ausdrucksvorrat der Programmierer
weiter Bestand hat, statt für illegal erklärt und vom
compiler-Hersteller mit eineindeutiger, persistenter
Programmtransformation beseitigt zu werden, ist irgendwie
entlarvend.
C ist C. Es gibt genügend andere Sprachen, wo diese Gleichung nicht
gilt.
Es gibt auch C-Compiler, für die die Gleichung nicht gilt (bzw.
der Ausdruck den Wert 0 hat).
Hast Du die Anmerkung »(bei einem auf
ASCII aufbauendem runtime character set)« im nächsten Absatz übersehen?

Mit EBCDIC stimmt es natürlich nicht (da hat 'A' den Wert 193).
Post by Thomas Koenig
#ifdef NOSTALGIA
Ich habe auf so einer Maschine auch mal was in C programmiert,
auch wenn es sich irgendwie komisch anfühlte. Vor allem musste
man erstmal die Zeilennummern im Editor abschalten...
Ich schalte die im vi immer ein.

Ach Du meinst, der Editor hat Zeilennummern in den Code eingefügt? Das
ist natürlich unpraktisch, wenn man nicht in Basic programmiert :-).

Mich hat auf EBCDIC-Rechnern mehr der Mangel geschwungenen Klammern
gestört:

int main(void)
??<
printf("Hello, EBCDIC world!??/n");
??>

(wobei ich mir jetzt nicht mehr sicher bin, ob man auf den Terminals
keine geschwungenen Klammern eingeben konnte, oder ob der Compiler nur
eine andere EBCDIC-Variante erwartet hat als das Terminal geliefert hat.
Ist zu lange her und dort war ich nicht lang).

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Koenig
2017-02-03 19:18:08 UTC
Permalink
Post by Peter J. Holzer
Post by Thomas Koenig
#ifdef NOSTALGIA
Ich habe auf so einer Maschine auch mal was in C programmiert,
auch wenn es sich irgendwie komisch anfühlte. Vor allem musste
man erstmal die Zeilennummern im Editor abschalten...
Ich schalte die im vi immer ein.
Ach Du meinst, der Editor hat Zeilennummern in den Code eingefügt? Das
ist natürlich unpraktisch, wenn man nicht in Basic programmiert :-).
Noch besser.

Der Editor hat in den Spalten 73 bis 80 (die ja eh keiner braucht,
weil in FORTRAN hinter Spalte 72 alles Kommentar ist und die er
daher erst gar nicht angezeigt hat) automatisch Zeilennummern
eingefügt. Das hatte tatsächlich den Vorteil, dass man da nicht
aus Versehen etwas hereingschrieben hat (was ansonstem beim festen
Fortran-Format Probleme verursachen kann). Nachteil - naja, der
C-Compiler kam nicht so wirklich damit klar. LaTeX auch nicht :-)
Post by Peter J. Holzer
Mich hat auf EBCDIC-Rechnern mehr der Mangel geschwungenen Klammern
Waren auf dem Terminal drauf, das ich benutzt hatte. K.A., in welchen
EBCDIC - Code das damals umgewandelt wurde.
Loading...