negative Zufallszahlen mit Turbo Pascal?
Alexander Schestag
gibt es in Turbo Pascal die Möglichkeit, negative Zufallszahlen zu
erzeugen? Es gäbe zwar die Möglichkeit, mit einer zweiten
Zufallsvariable der Zufallszahl ein positives oder negatives Vorzeichen
zu verpassen, aber das dürfte die Zufälligkeit der Folge beeinflussen,
so daß es mir lieber wäre, das durch ein random(x) zu erledigen. Weiß
jemand eine Lösung?
Grüße,
Alex
Florian Kreidler
äh, sorry, aber ist das ne ernstgemeinte Frage?
function myrandom(x:integer):integer;
begin
if random(2)=1 then
myrandom:=random(x)
else myrandom:=-random(x);
end;
ist genauso zufällig wie
random(2*x)-x
Sebastian Suchanek
man Mathe-Grundlagen. :-)
Wenn Du z.B. Zufallszahlen zwischen -50 und +50 haben willst:
x := random(100) - 50;
HTH,
Sebastian
--
"Katana, Wakizashi, Katana - so mag ich meine Frauen!"
O-Ton "EvilTechno"
Florian Kreidler
> Alexander Schestag <imh...@gmx.de> spoke thusly:
>
>> gibt es in Turbo Pascal die Möglichkeit, negative
>> Zufallszahlen zu erzeugen? Es gäbe zwar die Möglichkeit,
>> mit einer zweiten Zufallsvariable der Zufallszahl ein
>> positives oder negatives Vorzeichen zu verpassen, aber das
>> dürfte die Zufälligkeit der Folge beeinflussen, so daß es
>> mir lieber wäre, das durch ein random(x) zu erledigen. Weiß
>> jemand eine Lösung?
>
> man Mathe-Grundlagen. :-)
>
> Wenn Du z.B. Zufallszahlen zwischen -50 und +50 haben willst:
>
> x := random(100) - 50;
hmmm....
den Fehler habe ich in meinem Schnellschuß im Nachbarposting auch
gemacht. Das ergibt Zahlen von einschließlich -50 bis einschließlich 49.
randvalue:=random(2*x+1)-x;
muß es heißen, damit -x und x dabei sind.
Sebastian Suchanek
> [...]
*in_der_Hilfe_nachschau*
Tatsächlich, die Obergrenze ist nicht inbegriffen.
*hmpf*
Wer ist denn auf die blödsinnige Idee gekommen, das Ergebnis von
random nur in [0,1[ und nicht in [0,1] zu legen?
Tschüs,
Florian Kreidler
>
> *hmpf*
>
> Wer ist denn auf die blödsinnige Idee gekommen, das Ergebnis von
> random nur in [0,1[ und nicht in [0,1] zu legen?
war wohl ein C-Programmierer
Alexander Schestag
danke für die Antworten. Natürlich sind das alles praktikable Lösungen.
Ich bin mir aber nicht sicher, ob sie nicht die Güte der Zufallsfolge
(die man z.B. statistisch mit dem Runs-Test überprüfen kann) verändern,
da sie ja beide an der zuvor mit einem Pseudozufallszahlenalgorithmus
ermittelten Zufallsfolge Veränderungen vornehmen. Von daher wäre es mir
lieber gewesen, wenn man mit random(x) von vornherein negative Zahlen
hätte erzeugen können. Aber wie ich vermutet hatte, geht das nicht. :-(
Grüße,
Alex
Sebastian Suchanek
> danke für die Antworten. Natürlich sind das alles
> praktikable Lösungen. Ich bin mir aber nicht sicher, ob sie
> nicht die Güte der Zufallsfolge (die man z.B. statistisch
> mit dem Runs-Test überprüfen kann) verändern, da sie ja
> beide an der zuvor mit einem Pseudozufallszahlenalgorithmus
> ermittelten Zufallsfolge Veränderungen vornehmen.
> [...]
Willst Du uns veräppeln?
random produziert (hoffentlich gleichmäßig) verteile
Zufallszahlen aus dem Intervall [0,1[. (Das Komfort-Feature, das
gleich per Multiplikation auf ein größeres Intervall zu
strecken, lassen wir mal weg.)
Es ist sch***egal, ob Du anschließend das Intervall *als ganzes*
nach "oben" oder "unten" verschiebst. Das ändert nichts an der
Verteilung.
Tschüs,
Stefan Reuther
Sebastian Suchanek <spa...@suchanek.de> wrote:
> Wer ist denn auf die blödsinnige Idee gekommen, das Ergebnis von
> random nur in [0,1[ und nicht in [0,1] zu legen?
Jemand, der Ahnung von der Materie hatte? *duck*
Nur so lassen sich wirklich gleichverteilte Zufallszahlen
erzeugen.
Aufgabe: schreibe einen Zufallsgenerator, der 1..6
gleichverteilt liefert (Würfel, W6).
Wenn "Random" [0,1[ liefert:
function wuerfel : integer;
begin
wuerfel := Trunc(6*Random) + 1;
end;
Wenn "Random" [0,1] liefern würde, käme da gelegentlich 7 raus.
Workaround 1:
function wuerfel : integer;
begin
wuerfel := Trunc(5.9999*Random) + 1;
end;
funktioniert vielleicht für ein 08/15 Spiel, ist aber nicht mehr
gleichverteilt.
Workaround 2:
function wuerfel : integer;
var tmp : integer;
begin
repeat
tmp := Trunc(6*Random) + 1;
until tmp<>7;
wuerfel := tmp;
end;
funktioniert, ist auch gleichverteilt, macht dir aber alle
schönen Eigenschaften, die du sonst noch haben könntest, kaputt
(konstante Laufzeit, Weitersetzen des "seed" um N Schritte ohne
die Zufallszahlen direkt abzufragen, ...).
Daß "Random(n)" Zahlen aus [0,n[ liefert, ist da nur die
logische Fortsetzung; das ist dann einfach "Trunc(Random * n)".
Auch wenn es ketzerisch klingt: halboffene Intervalle sind für
mehr zu gebrauchen, als der durchschnittliche Pascal-
Programmierer glaubt. Ich habe jahrelang ausschließlich Pascal
programmiert und konnte es auch erst nicht glauben :-) In Pascal
sind ja schließlich Array- und Schleifengrenzen immer inklusive.
Jetzt mache ich auch C++ und finde halboffene Intervalle die
beste Erfindung seit geschnittenem Brot.
Wenn du beispielsweise ein geschlossenes Intervall [a,b] bei "m"
aufspalten willst, mußt du immer aufpassen, wo noch 1 addiert
oder abgezogen werden muß: [a,m-1] und [m,b]. Bei halboffenen
Intervallen kein Problem: [a,b[ wird zu [a,m[ und [m,b[. Im
Gegensatz zu den geschlossenen Intervallen sogar mit real als
Grenze, nicht nur mit integer.
Stefan
Vinzent Hoefler
>Auch wenn es ketzerisch klingt: halboffene Intervalle sind für
>mehr zu gebrauchen, als der durchschnittliche Pascal-
>Programmierer glaubt.
Ich glaube, mit Pascal hat das nicht sooo viel zu tun.
>Ich habe jahrelang ausschließlich Pascal
>programmiert und konnte es auch erst nicht glauben :-) In Pascal
>sind ja schließlich Array- und Schleifengrenzen immer inklusive.
In C aber auch. Nur, dass sie da immer bei 0 anfangen muessen, was die
daemlichste Erfindung ist, seit es die 0 ueberhaupt gibt.
>Jetzt mache ich auch C++ und finde halboffene Intervalle die
>beste Erfindung seit geschnittenem Brot.
-v, denn
|int a[5], b[5];
und bei einem Zugriff auf a[5] wird dann automatisch bei b[0]
weitergemacht, wirst Du wohl nicht meinen, oder? ;->
Vinzent.
--
Parents strongly cautioned -- this posting is intended for mature
audiences over 18. It may contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.
Alexander Schestag
Sebastian Suchanek schrieb:
> Alexander Schestag <imh...@gmx.de> spoke thusly:
> > danke für die Antworten. Natürlich sind das alles
> > praktikable Lösungen. Ich bin mir aber nicht sicher, ob sie
> > nicht die Güte der Zufallsfolge (die man z.B. statistisch
> > mit dem Runs-Test überprüfen kann) verändern, da sie ja
> > beide an der zuvor mit einem Pseudozufallszahlenalgorithmus
> > ermittelten Zufallsfolge Veränderungen vornehmen.
> > [...]
> Willst Du uns veräppeln?
Ich bitte doch um etwas mehr Höflichkeit!
> random produziert (hoffentlich gleichmäßig) verteile
> Zufallszahlen aus dem Intervall [0,1[.
Gleichverteilung ist KEINE notwendige Voraussetzung für die Zufälligkeit
einer Folge. Da gibt es ganz andere Kriterien wie Redundanzen usw.
> Es ist sch***egal, ob Du anschließend das Intervall *als ganzes*
> nach "oben" oder "unten" verschiebst. Das ändert nichts an der
> Verteilung.
Wenn ich zufällig irgendwelche Minuszeichen verteile, wie bei der ersten
Lösung vorgeschlagen, ändert das sehr wohl was daran. Beispiel:
Die Originalfolge lautet:
4 5 5 2 1 3 0 9 6 2 2
Wenn die nun durch zufällige Verteilung von Minuszeichen umgewandelt
wird in:
4 -5 5 2 1 -3 0 -9 6 -2 2
ist die Anzahl der Redundanzen verändert, was sich sehr wohl auf die
Zufälligkeit auswirkt.
Grüße,
Alex
Vinzent Hoefler
>Sebastian Suchanek schrieb:
>
>> random produziert (hoffentlich gleichmäßig) verteile
>> Zufallszahlen aus dem Intervall [0,1[.
>
>Gleichverteilung ist KEINE notwendige Voraussetzung für die Zufälligkeit
>einer Folge.
Das sollte wohl eher "keine hinreichende" heissen, oder?
>Da gibt es ganz andere Kriterien wie Redundanzen usw.
>
>> Es ist sch***egal, ob Du anschließend das Intervall *als ganzes*
>> nach "oben" oder "unten" verschiebst. Das ändert nichts an der
>> Verteilung.
>
>Wenn ich zufällig irgendwelche Minuszeichen verteile, wie bei der ersten
>Lösung vorgeschlagen, ändert das sehr wohl was daran.
Das Posting, auf welches Du geantwortet hast, enthielt allerdings
nicht den Vorschlag fuer zufaellige Minuszeichen (das war naemlich
Dein eigener Ansatz), sondern schlicht und einfach den Vorschlag der
Verschiebung des Bereiches, was vollkommen korrekt ist und an einer
Gleichverteilung oder sonstigem *nichts* aendert.
Wenn Du allerdings ohnehin extrem hohe Ansprueche an einen
Zufallsgenerator hast, solltest Du Dir vielleicht besser einen eigenen
bauen.
Stefan Reuther
>>Auch wenn es ketzerisch klingt: halboffene Intervalle sind für
>>mehr zu gebrauchen, als der durchschnittliche Pascal-
>>Programmierer glaubt.
> Ich glaube, mit Pascal hat das nicht sooo viel zu tun.
Es hat insofern mit Pascal zu tun, als daß in
var x : array[1..SIZE] of integer;
und
for i:=1 to SIZE do irgendwas;
die Grenzen jeweils inklusive sind, in den C-ähnlichen Sprachen
aber mit
int x[SIZE];
und
for (int i = 0; i < SIZE; ++i) irgendwas;
nicht.
>>Ich habe jahrelang ausschließlich Pascal
>>programmiert und konnte es auch erst nicht glauben :-) In Pascal
>>sind ja schließlich Array- und Schleifengrenzen immer inklusive.
> In C aber auch. Nur, dass sie da immer bei 0 anfangen muessen, was die
> daemlichste Erfindung ist, seit es die 0 ueberhaupt gibt.
Nein. Ein Feld mit Grenze 10 läuft von 0 bis 9, nicht von 0 bis
10. Ob man die Untergrenze auf 0 festnageln will oder nicht, ist
Geschmackssache.
>>Jetzt mache ich auch C++ und finde halboffene Intervalle die
>>beste Erfindung seit geschnittenem Brot.
> -v, denn
Ich hatte doch Beispiele angegeben.
Angenommen, du hast ein C-Feld "int x[1000]". Dann kannst du den
Indexbereich des Feldes ausdrücken als "[0, 1000[". Wenn du das
Feld nun in der Mitte aufspalten willst, sind die beiden
Teilfelder nun "[0, 500[" und "[500,1000[". Man beachte: wieder
zwei halboffene Intervalle, die "innere" Grenze ist jeweils die
gleiche.
Nun das gleiche in handelsüblichem Pascal: "x : array[1..1000]
of integer". Der Indexbereich ist "[1,1000]", beim Aufspalten in
der Mitte erhalten wir "[1,500]" und "[501,1000]". Mab beachte
die unterschiedliche innere Grenze.
Die Anzahl Elemente eines halboffenen Intervalls [a,b[ ist
einfach b-a. Die Anzahl Elemente eines geschlossenen Intervalls
[a,b] ist b-a+1.
Die Obergrenze des halboffenen Intervalls, welches bei a beginnt
und 10 Elemente enthält, ist a+10. Bei einem geschlossenen
Intervall a+10-1.
Ein leeres halboffenes Intervall ist [a,a[. Ein leeres
geschlossenes Intervall ist [a,a-1] ("bitte? die rechte Grenze
kleiner als die linke?").
Man muß also ständig irgendwelche Einsen addieren oder abziehen.
Das vergesse ich zu oft. Außerdem funktionieren halboffene
Intervalle nicht nur mit natürlichen, sondern auch mit reellen
Zahlen, Iteratoren, ... Ich halte das einfach für die
"natürlichere" Darstellung von Intervallen. Inzwischen verwende
ich diese Dinge auch in meinen Pascal-Programmen. Nur die
Pointer-Arithmetik ist immer so umständlich ~>8-)
> |int a[5], b[5];
> und bei einem Zugriff auf a[5] wird dann automatisch bei b[0]
> weitergemacht, wirst Du wohl nicht meinen, oder? ;->
Also bei mir ist a[5] der frame pointer des Aufrufers *duck*
Stefan
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>
>>>Auch wenn es ketzerisch klingt: halboffene Intervalle sind für
>>>mehr zu gebrauchen, als der durchschnittliche Pascal-
>>>Programmierer glaubt.
>
>> Ich glaube, mit Pascal hat das nicht sooo viel zu tun.
>
>Es hat insofern mit Pascal zu tun, als daß in
> var x : array[1..SIZE] of integer;
>[...]
Nichts hindert mich daran, ein
|type Index is Integer range 0 .. SIZE - 1;
|x: array(Index)
zu deklarieren. Auch in Pascal fangen die Arrays nicht immer mit 1 an.
Gelegentlich fangen sie sogar mit 'A' an.
>und
> for i:=1 to SIZE do irgendwas;
>die Grenzen jeweils inklusive sind, in den C-ähnlichen Sprachen
>aber mit
> int x[SIZE];
>und
> for (int i = 0; i < SIZE; ++i) irgendwas;
>nicht.
Aber sicher doch.
Den Unterschied zu
|for i in x'Range loop
zu obigem sehe ich naemlich nicht.
>> In C aber auch. Nur, dass sie da immer bei 0 anfangen muessen, was die
>> daemlichste Erfindung ist, seit es die 0 ueberhaupt gibt.
>
>Nein. Ein Feld mit Grenze 10 läuft von 0 bis 9, nicht von 0 bis
>10. Ob man die Untergrenze auf 0 festnageln will oder nicht, ist
>Geschmackssache.
Wenn ich die Untergrenze bei nicht 0 brauche, dann ist es Krampf,
keine Geschmackssache. Wenn sie negativ sein soll, genauso.
>Angenommen, du hast ein C-Feld "int x[1000]". Dann kannst du den
>Indexbereich des Feldes ausdrücken als "[0, 1000[".
Richtig, wie das in Pascal und verwandten Sprachen ebenso geht. In C
wird die Anzahl der Elemente angegeben, in Pascal lieber der
indizierbare Bereich. Einen wirklichen Unterschied sehe ich da nicht.
>Wenn du das
>Feld nun in der Mitte aufspalten willst, sind die beiden
>Teilfelder nun "[0, 500[" und "[500,1000[". Man beachte: wieder
>zwei halboffene Intervalle, die "innere" Grenze ist jeweils die
>gleiche.
Intervall 1: Low (x) to High (x) div 2
Intervall 2: High (x) div 2 + 1 to High (x)
In C drueckst Du das doch prinzipiell auch nicht anders aus.
>Nun das gleiche in handelsüblichem Pascal: "x : array[1..1000]
>of integer". Der Indexbereich ist "[1,1000]",
Genauer, der Indexbereich ist Low (x) .. High (x) bzw. x'First ..
x'Last.
>beim Aufspalten in
>der Mitte erhalten wir "[1,500]" und "[501,1000]". Mab beachte
>die unterschiedliche innere Grenze.
Auf Maschinenebene gesehen ist das exakt die gleiche Grenze.
>Die Anzahl Elemente eines halboffenen Intervalls [a,b[ ist
>einfach b-a. Die Anzahl Elemente eines geschlossenen Intervalls
>[a,b] ist b-a+1.
Das ist allerdings richtig. Du vergisst dabei aber, dass auch in C das
b eigentlich nicht mehr zum Intervall gehoert, sondern ausschliesslich
die Anzahl der Elemente angibt. (Die bekomme ich uebrigens mit
x'Length.)
>Die Obergrenze des halboffenen Intervalls, welches bei a beginnt
>und 10 Elemente enthält, ist a+10. Bei einem geschlossenen
>Intervall a+10-1.
Nicht, wenn Du das jetzt auf Arrays beziehst.
Der Index eines a[10] mit Intervallgrenze 10 hat auch in C eine
Obergrenze von 10 - 1. Alles andere waere UB.
>Ein leeres halboffenes Intervall ist [a,a[. Ein leeres
>geschlossenes Intervall ist [a,a-1] ("bitte? die rechte Grenze
>kleiner als die linke?").
Durchaus korrekt. Der C-Compiler wird Dich dann aber ohnehin mit
"unused variable"-Warnungen nerven.
>Man muß also ständig irgendwelche Einsen addieren oder abziehen.
Komisch, dass ich das dann so selten tue. ;)
>Das vergesse ich zu oft.
Korrekterweise muesstest Du ja auch den untersten Indexwert addieren
bzw. abziehen, nicht einfach bloss 1.
>Inzwischen verwende
>ich diese Dinge auch in meinen Pascal-Programmen.
Du meinst:
|const
| MAX_CHAR = Succ ('Z');
|
|type
| Char_Index = 'A' .. Pred (MAX_CHAR);
|
|x : array[Index] of Integer;
Naja, wer sich's denn antun will... :->
>Nur die
>Pointer-Arithmetik ist immer so umständlich ~>8-)
Pointer? Was ist das? ;)
Ansonsten:
|type
| PtrInt =
| record
| case Boolean of
| False:
| Ptr : pointer;
| True:
| Int : LongInt;
| end {case};
| end {PtrInt};
|
|var
| x : PtrInt;
|
|...
|
| x.Int := x.Int + SizeOf (...);
Was ist daran umstaendlich? Ausser natuerlich, dass Dir die oft
unleserliche, abkuerzende Pre- oder Postfixnotation ohnehin nicht zur
Verfuegung steht?
>> |int a[5], b[5];
>
>> und bei einem Zugriff auf a[5] wird dann automatisch bei b[0]
>> weitergemacht, wirst Du wohl nicht meinen, oder? ;->
>
>Also bei mir ist a[5] der frame pointer des Aufrufers *duck*
Oh, ich vergass. Es gibt ja auch C-Programmierer, die das Konzept von
lokalen Variablen kennen. :->
Sebastian Suchanek
> Sebastian Suchanek <spa...@suchanek.de> wrote:
>> Wer ist denn auf die blödsinnige Idee gekommen, das
>> Ergebnis von random nur in [0,1[ und nicht in [0,1] zu
>> legen?
>
> Jemand, der Ahnung von der Materie hatte? *duck*
>
> Nur so lassen sich wirklich gleichverteilte Zufallszahlen
> erzeugen.
Glaube ich Dir nicht. :-)
Siehe unten...
> Aufgabe: schreibe einen Zufallsgenerator, der 1..6
> gleichverteilt liefert (Würfel, W6).
>
> Wenn "Random" [0,1[ liefert:
> function wuerfel : integer;
> begin
> wuerfel := Trunc(6*Random) + 1;
> end;
>
> Wenn "Random" [0,1] liefern würde, käme da gelegentlich 7
> raus.
Bei dieser Methode klar.
> Workaround 1:
> function wuerfel : integer;
> begin
> wuerfel := Trunc(5.9999*Random) + 1;
> end;
> funktioniert vielleicht für ein 08/15 Spiel, ist aber nicht
> mehr gleichverteilt.
>
> Workaround 2:
> function wuerfel : integer;
> var tmp : integer;
> begin
> repeat
> tmp := Trunc(6*Random) + 1;
> until tmp<>7;
> wuerfel := tmp;
> end;
> funktioniert, ist auch gleichverteilt, macht dir aber alle
> schönen Eigenschaften, die du sonst noch haben könntest,
> kaputt (konstante Laufzeit, Weitersetzen des "seed" um N
> Schritte ohne die Zufallszahlen direkt abzufragen, ...).
> [...]
"Workaround" 3:
| function wuerfel: integer;
|
| begin
| wuerfel := random(5) + 1;
| end;
Wäre gleichverteilt und würde Zahlen aus [1,6] liefern.
Können C-Programmierer nicht mehr an das Naheliegende denken?
;->
Sebastian Suchanek
> Hallo,
>
> Sebastian Suchanek schrieb:
>
>> Alexander Schestag <imh...@gmx.de> spoke thusly:
>
>>> danke für die Antworten. Natürlich sind das alles
>>> praktikable Lösungen. Ich bin mir aber nicht sicher, ob
>>> sie nicht die Güte der Zufallsfolge (die man z.B.
>>> statistisch mit dem Runs-Test überprüfen kann)
>>> verändern, da sie ja beide an der zuvor mit einem
>>> Pseudozufallszahlenalgorithmus ermittelten Zufallsfolge
>>> Veränderungen vornehmen. [...]
>
>> Willst Du uns veräppeln?
>
> Ich bitte doch um etwas mehr Höflichkeit!
Noch mehr? ;-)
>> random produziert (hoffentlich gleichmäßig) verteile
>> Zufallszahlen aus dem Intervall [0,1[.
>
> Gleichverteilung ist KEINE notwendige Voraussetzung für die
> Zufälligkeit einer Folge. Da gibt es ganz andere Kriterien
> wie Redundanzen usw.
>
>> Es ist sch***egal, ob Du anschließend das Intervall *als
^^^^
>> ganzes* nach "oben" oder "unten" verschiebst. Das ändert
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> nichts an der Verteilung.
>
> Wenn ich zufällig irgendwelche Minuszeichen verteile,
^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
> [...]
Lies mein Posting nocheinmal und sage mir dann bitte, wo die
Diskrepanz in unserer beider Aussagen steckt.
(Ich habe Dir die entscheidenden Stellen zur Sicherheit nochmal
unterstrichen...)
HTH,
Florian Kreidler
>
> Workaround 2:
> function wuerfel : integer;
> var tmp : integer;
> begin
> repeat
> tmp := Trunc(6*Random) + 1;
> until tmp<>7;
> wuerfel := tmp;
> end;
> funktioniert, ist auch gleichverteilt, macht dir aber alle
> schönen Eigenschaften, die du sonst noch haben könntest, kaputt
> (konstante Laufzeit, Weitersetzen des "seed" um N Schritte ohne
> die Zufallszahlen direkt abzufragen, ...).
<troll>
Ist denn sicher, dass das terminiert?
</troll>
Vinzent Hoefler
>Stefan Reuther schrieb im Artikel <1052483457.irz750%sr...@inf.tu-dresden.de>:
>>
[...]
>> repeat
>> tmp := Trunc(6*Random) + 1;
>> until tmp<>7;
[...]
>
><troll>
>Ist denn sicher, dass das terminiert?
></troll>
Wahrscheinlich schon. :)
Alexander Schestag
Vinzent Hoefler schrieb:
> Alexander Schestag <imh...@gmx.de> wrote:
>>Gleichverteilung ist KEINE notwendige Voraussetzung für die Zufälligkeit
>>einer Folge.
> Das sollte wohl eher "keine hinreichende" heissen, oder?
Nein, "keine notwendige" ist schon richtig:
"Der zweite Unterschied zwischen realen und ausgedachten Zufallsfolgen
ist nicht
ganz so auffällig. Menschen neigen dazu, innerhalb kurzer Zeit alle
Ziffern gleich
häufig zu nennen; sie achten also auf eine Gleichverteilung der
Würfelergebnisse.
Zwar nähert sich der Anteil einer Zahl auf längere Sicht auch beim
realen Würfeln
einem Erwartungswert. Es gibt aber keinen Zwang zum Ausgleich."
(http://www.quarks.de/dyn/5296.phtml)
>>Da gibt es ganz andere Kriterien wie Redundanzen usw.
>>
>>
>>>Es ist sch***egal, ob Du anschließend das Intervall *als ganzes*
>>>nach "oben" oder "unten" verschiebst. Das ändert nichts an der
>>>Verteilung.
>>
>>Wenn ich zufällig irgendwelche Minuszeichen verteile, wie bei der ersten
>>Lösung vorgeschlagen, ändert das sehr wohl was daran.
>
>
> Das Posting, auf welches Du geantwortet hast, enthielt allerdings
> nicht den Vorschlag fuer zufaellige Minuszeichen (das war naemlich
> Dein eigener Ansatz),
Na ja, das war auch der erste Vorschlag von Florian Kreidler.
sondern schlicht und einfach den Vorschlag der
> Verschiebung des Bereiches, was vollkommen korrekt ist und an einer
> Gleichverteilung oder sonstigem *nichts* aendert.
Wie gesagt, die Gleichverteilung ist hier nicht so sonderlich relevant.
Aber ansonsten stimmt das natürlich.
> Wenn Du allerdings ohnehin extrem hohe Ansprueche an einen
> Zufallsgenerator hast, solltest Du Dir vielleicht besser einen eigenen
> bauen.
Och, zumindest für positive Zahlen habe ich den von TP schon des öfteren
getestet, mit zufriedenstellenden Ergebnissen. Und die
Gleichverteilungsannahme war dabei schon des öfteren verletzt...
Grüße,
Alex
Jochen
Sebastian Suchanek wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> spoke thusly:
>> Sebastian Suchanek <spa...@suchanek.de> wrote:
>>> Wer ist denn auf die blödsinnige Idee gekommen, das
>>> Ergebnis von random nur in [0,1[ und nicht in [0,1] zu
>>> legen?
>>
>> Jemand, der Ahnung von der Materie hatte? *duck*
Keine Panik. Du passt scho'.
>>
>> Nur so lassen sich wirklich gleichverteilte Zufallszahlen
>> erzeugen.
>
> Glaube ich Dir nicht. :-)
> Siehe unten...
>
[...]
> "Workaround" 3:
>
> function wuerfel: integer;
>
> begin
> wuerfel := random(5) + 1;
> end;
>
> Wäre gleichverteilt und würde Zahlen aus [1,6] liefern.
Nicht ganz. Sondern von 1..5;
Du meintest bestimmt : random(6) + 1;
Und genau das ist der Grund warum random [0..1[ liefert.
Denn random(5) ist grob eigentlich nix anderes als trunc(random * 5);
Eine paar gute Erklärungen dafür hat Stefan schon gegeben.
Stell dir das mal anders vor: Dass bei einer zufälligen Bitkombination
genau 1 rauskommt ist schon sehr selten und das wird noch komplizierter,
wenn du die Anzahl der Bits zur Darstellung der Zahl veränderst.
Wenn du die 1 aber rausnimmst, sieht es schon viel besser aus.
Ein etwas anderer Ansatz:
Du willst Zufallszahlen von [1..4]
1. Version von random [0..1[:
[0..25[ -> 1
[0,25..0,5[ -> 2
[0,55..0,75[ - 3
[0,75..1[ -> 4
2. Version von random [0..1]
[0..25[ -> 1
[0,25..0,5[ -> 2
[0,55..0,75[ - 3
[0,75..1] -> 4 ... sind hier die intervalle noch gleich gross?
>
> Können C-Programmierer nicht mehr an das Naheliegende denken?
> ;->
Das weiss ich auch nicht. ;-)
gruss
jochen
Sebastian Suchanek
>>> Nur so lassen sich wirklich gleichverteilte Zufallszahlen
>>> erzeugen.
>>
>> Glaube ich Dir nicht. :-)
>> Siehe unten...
>>
> [...]
>> "Workaround" 3:
>>
>> function wuerfel: integer;
>>
>> begin
>> wuerfel := random(5) + 1;
>> end;
>>
>> Wäre gleichverteilt und würde Zahlen aus [1,6] liefern.
>
> Nicht ganz. Sondern von 1..5;
> Du meintest bestimmt : random(6) + 1;
Nein, eben genau das meine ich nicht. Zur Erinnerung: Obiges
steht unter der Prämisse, daß random Ergebnisse aus [0,1] bzw.
[0,n] liefert.
Test der obigen Routine auf Extremwerte:
* random(5) liefert 0 => 0 + 1 = 1. Paßt.
* random(5) liefert 5 => 5 + 1 = 6. Paßt auch.
Unter der Annahme, daß random an sich geeignet verteilte
Zufallszahlen liefert, erhalten wir durch obigen Algorithmus
Zufallszahlen aus dem Intervall [1,6]. q.e.d.
> [...]
> Stell dir das mal anders vor: Dass bei einer zufälligen
> Bitkombination genau 1 rauskommt ist schon sehr selten und
> das wird noch komplizierter, wenn du die Anzahl der Bits
> zur Darstellung der Zahl veränderst.
Die Wahrscheinlichkeit, daß z.B. ein Byte "11111111" als Inhalt
hat, ist genau so groß wie für "00000000", "10101010" oder sonst
eine Kombination.
Das natürlich nur unter der Voraussetzung, daß die Werte der
einzelnen Bits unabhängig untereinander und vom Rest der Welt
sind. Alles andere wäre für echte Zufallszahlen aber ohnehin
nicht zu gebrauchen.
> Wenn du die 1 aber rausnimmst, sieht es schon viel besser
> aus.
>
> Ein etwas anderer Ansatz:
>
> Du willst Zufallszahlen von [1..4]
>
> 1. Version von random [0..1[:
>
> [0..25[ -> 1
> [0,25..0,5[ -> 2
> [0,55..0,75[ - 3
> [0,75..1[ -> 4
>
> 2. Version von random [0..1]
>
> [0..25[ -> 1
> [0,25..0,5[ -> 2
> [0,55..0,75[ - 3
> [0,75..1] -> 4 ... sind hier die intervalle noch gleich
> gross?
> [...]
Irgendwie verstehe ich nicht, was Du mir damit sagen willst...
Vinzent Hoefler
>Hallo Vinzent,
>
>Vinzent Hoefler schrieb:
>> Alexander Schestag <imh...@gmx.de> wrote:
>
> sondern schlicht und einfach den Vorschlag der
>> Verschiebung des Bereiches, was vollkommen korrekt ist und an einer
>> Gleichverteilung oder sonstigem *nichts* aendert.
>
>Wie gesagt, die Gleichverteilung ist hier nicht so sonderlich relevant.
Was denn dann, dass Du Dir solche Gedanken ueber die "zufaellige"
Einfuegungen von Vorzeichenaenderungen Gedanken machst?
>Och, zumindest für positive Zahlen habe ich den von TP schon des öfteren
>getestet, mit zufriedenstellenden Ergebnissen.
Mag sein, fuer ernsthafte statistische Anwendungen ist er
nichtsdestotrotz nicht zu gebrauchen.
>Und die
>Gleichverteilungsannahme war dabei schon des öfteren verletzt...
Ueber die maximale Periode des Generators bei passend gegebenem
Startwert? Das bezweifle ich.
Alexander Schestag
Vinzent Hoefler schrieb:
> Alexander Schestag <imh...@gmx.de> wrote:
>>Wie gesagt, die Gleichverteilung ist hier nicht so sonderlich relevant.
> Was denn dann, dass Du Dir solche Gedanken ueber die "zufaellige"
> Einfuegungen von Vorzeichenaenderungen Gedanken machst?
- Die richtige Anzahl von Redundanzen nter Ordnung (66 666 6666 usw.
müssen für alle Zahlen mit bestimmter Häufigkeit auftreten)
- Das Vermeiden kurzer Folgen (632104 632104 ...), wie sie bei älteren
RNGs öfters auftraten.
>>Och, zumindest für positive Zahlen habe ich den von TP schon des öfteren
>>getestet, mit zufriedenstellenden Ergebnissen.
> Mag sein, fuer ernsthafte statistische Anwendungen ist er
> nichtsdestotrotz nicht zu gebrauchen.
Da ist meine Erfahrung ganz anders. Es kommt drauf an, wofür.
Grüße,
Alex
Vinzent Hoefler
>Vinzent Hoefler schrieb:
>> Alexander Schestag <imh...@gmx.de> wrote:
>>>Wie gesagt, die Gleichverteilung ist hier nicht so sonderlich relevant.
>
>> Was denn dann, dass Du Dir solche Gedanken ueber die "zufaellige"
>> Einfuegungen von Vorzeichenaenderungen Gedanken machst?
>
>- Die richtige Anzahl von Redundanzen nter Ordnung (66 666 6666 usw.
>müssen für alle Zahlen mit bestimmter Häufigkeit auftreten)
Ohne jetzt eine tiefgruendigere Analyse durchzufuehren: Da die
Aenderung des Vorzeichens genaugenommen nur ein Bit aendert (ja,
eigentlich zwei...), sollte sich auch daran nichts aendern. Unter der
Praemisse, dass auch diese Modulation einer Zufallsverteilung gehorcht
(was sie eher nicht tut, da sie ja auch aus einem PRNG stammt). Ich
kann mich taeuschen. Aber wie schon gesagt, die einfachere Loesung ist
ja ohnehin schon genannt worden.
>- Das Vermeiden kurzer Folgen (632104 632104 ...), wie sie bei älteren
>RNGs öfters auftraten.
Wenn Du einen PRNG suchst, der gar keine Wiederholungen zeigt, dann
waere ein LFSR eventuell die bessere Wahl. Mit den richtigen
Parametern kommt in seiner Periode jede moegliche Zahl nur einmal vor.
Allerdings widerspricht das auch schon wieder ueblichen
Zufallszahlenverteilungen.
>>>Och, zumindest für positive Zahlen habe ich den von TP schon des öfteren
>>>getestet, mit zufriedenstellenden Ergebnissen.
>
>> Mag sein, fuer ernsthafte statistische Anwendungen ist er
>> nichtsdestotrotz nicht zu gebrauchen.
>
>Da ist meine Erfahrung ganz anders. Es kommt drauf an, wofür.
Bei einer maximalen Periode im Bereich bis max. 2**32 reicht der
vorhandene Generator in Rohform meist nicht.
Ich rede von Perioden >> 2**128. Als bloedes Beispiel ein einfaches
Kartenmischen von 52 Karten, dort z.B. sollte die Periode mindestens
52! betragen, damit auch wirklich alle moeglichen Kombinationen
abgedeckt werden koennen, 2**226 waere da also gerade mal ausreichend.
Alexander Schestag
Vinzent Hoefler schrieb:
> Alexander Schestag <imh...@gmx.de> wrote:
>>Vinzent Hoefler schrieb:
>>>Alexander Schestag <imh...@gmx.de> wrote:
>>>>Wie gesagt, die Gleichverteilung ist hier nicht so sonderlich relevant.
>>>Was denn dann, dass Du Dir solche Gedanken ueber die "zufaellige"
>>>Einfuegungen von Vorzeichenaenderungen Gedanken machst?
>>- Die richtige Anzahl von Redundanzen nter Ordnung (66 666 6666 usw.
>>müssen für alle Zahlen mit bestimmter Häufigkeit auftreten)
> Ohne jetzt eine tiefgruendigere Analyse durchzufuehren: Da die
> Aenderung des Vorzeichens genaugenommen nur ein Bit aendert (ja,
> eigentlich zwei...), sollte sich auch daran nichts aendern.
Doch. Wieviele Bits hier verändert werden, ist völlig Wurscht. Relevant
ist, daß die statistischen Eigenschaften der Folge verändert werden.
Beispiel: 6 6 ist nicht das Gleiche wie 6 -6. Hier wird die Redundanz
aufgelöst.
> Unter der
> Praemisse, dass auch diese Modulation einer Zufallsverteilung gehorcht
> (was sie eher nicht tut, da sie ja auch aus einem PRNG stammt).
Ähm, deine Argumentation ist zirkulär. Über die Redundanzen will ich
doch grade *testen*, ob eine Folge zufällig ist! Es macht also gar
keinen Sinn, die Prämisse einer Zufallsverteilung anzunehmen, wenn ich
auf diese testen will.
> Ich kann mich taeuschen. Aber wie schon gesagt, die einfachere Loesung ist
> ja ohnehin schon genannt worden.
Stimmt, und die funktioniert auch gut.
>>- Das Vermeiden kurzer Folgen (632104 632104 ...), wie sie bei älteren
>>RNGs öfters auftraten.
> Wenn Du einen PRNG suchst, der gar keine Wiederholungen zeigt, dann
> waere ein LFSR eventuell die bessere Wahl. Mit den richtigen
> Parametern kommt in seiner Periode jede moegliche Zahl nur einmal vor.
> Allerdings widerspricht das auch schon wieder ueblichen
> Zufallszahlenverteilungen.
Aber ganz gewaltig.
>>>>Och, zumindest für positive Zahlen habe ich den von TP schon des öfteren
>>>>getestet, mit zufriedenstellenden Ergebnissen.
>>>Mag sein, fuer ernsthafte statistische Anwendungen ist er
>>>nichtsdestotrotz nicht zu gebrauchen.
>>Da ist meine Erfahrung ganz anders. Es kommt drauf an, wofür.
> Bei einer maximalen Periode im Bereich bis max. 2**32 reicht der
> vorhandene Generator in Rohform meist nicht.
> Ich rede von Perioden >> 2**128. Als bloedes Beispiel ein einfaches
> Kartenmischen von 52 Karten, dort z.B. sollte die Periode mindestens
> 52! betragen, damit auch wirklich alle moeglichen Kombinationen
> abgedeckt werden koennen, 2**226 waere da also gerade mal ausreichend.
Na ja, besser als herkömmliches Mischen per Hand dürfte ein normale PRNG
auf jeden Fall sein.
Ich brauche für meine Arbeit meist wesentlich weniger Zufallszahlen. Da
funktioniert das mit normalen PRNG ganz gut.
Grüße,
Alex
Stefan Reuther
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>und
>> for i:=1 to SIZE do irgendwas;
>>die Grenzen jeweils inklusive sind, in den C-ähnlichen Sprachen
>>aber mit
>> int x[SIZE];
>>und
>> for (int i = 0; i < SIZE; ++i) irgendwas;
>>nicht.
> Aber sicher doch.
> Den Unterschied zu
> |for i in x'Range loop
> zu obigem sehe ich naemlich nicht.
An der Stelle ist tatsächlich kein großer Unterschied.
Außer, daß die Pascal/Ada-Schleife für den Compilerbauer
schwieriger zu implementieren ist.
procedure x(a, b:byte);
var i:byte;
begin
for i:=a to b do write(i);
end;
Ist nicht ganz trivial.
In C muß man das explizit hinschreiben,
if (a <= b)
do
irgendwas;
while (a++ <= b);
damit hat der Compiler weniger Arbeit :-)
>>Wenn du das
>>Feld nun in der Mitte aufspalten willst, sind die beiden
>>Teilfelder nun "[0, 500[" und "[500,1000[". Man beachte: wieder
>>zwei halboffene Intervalle, die "innere" Grenze ist jeweils die
>>gleiche.
> Intervall 1: Low (x) to High (x) div 2
> Intervall 2: High (x) div 2 + 1 to High (x)
^^^
> In C drueckst Du das doch prinzipiell auch nicht anders aus.
Doch, ich spare mir das blöde "+1" Rumgerechne. Wenn ich mit
Strings operiere, ist das Aufspalten einer Sequenz in zwei Teile
zufällig eine recht häufige Operation.
Wenn ich keine 1 addieren muß, kann ich das nicht vergessen.
Also mache ich weniger Fehler.
>>Die Obergrenze des halboffenen Intervalls, welches bei a beginnt
>>und 10 Elemente enthält, ist a+10. Bei einem geschlossenen
>>Intervall a+10-1.
> Nicht, wenn Du das jetzt auf Arrays beziehst.
> Der Index eines a[10] mit Intervallgrenze 10 hat auch in C eine
> Obergrenze von 10 - 1. Alles andere waere UB.
Ich kann aber in C die Iteration über ein halboffenes Intervall
besser ausdrücken. In Pascal kann ich mit "for" nur über
geschlossene Intervalle iterieren. Vorteil C: flexibler. Vorteil
Pascal: ich brauche kein "one-past-end" Element.
>>Ein leeres halboffenes Intervall ist [a,a[. Ein leeres
>>geschlossenes Intervall ist [a,a-1] ("bitte? die rechte Grenze
>>kleiner als die linke?").
> Durchaus korrekt.
Mathematisch aber Blödsinn.
>>> und bei einem Zugriff auf a[5] wird dann automatisch bei b[0]
>>> weitergemacht, wirst Du wohl nicht meinen, oder? ;->
>>
>>Also bei mir ist a[5] der frame pointer des Aufrufers *duck*
> Oh, ich vergass. Es gibt ja auch C-Programmierer, die das Konzept von
> lokalen Variablen kennen. :->
Ja, ich behaupte, daß man schöne C Programme schreiben kann.
Genauso, wie man Windows sicher konfigurieren kann. Und genauso,
wie man Personal Firewalls sinnvoll einsetzen kann. Es machen
nur viel zu wenige ~:-)
Stefan
Horst Kraemer
<imh...@gmx.de> wrote:
> Hallo Vinzent,
>
> Vinzent Hoefler schrieb:
> > Alexander Schestag <imh...@gmx.de> wrote:
>
> >>Gleichverteilung ist KEINE notwendige Voraussetzung für die Zufälligkeit
> >>einer Folge.
Das ist wohl trivial. Es gibt auch noch andere Verteilungen als die
Gleichverteilung.
> > Das sollte wohl eher "keine hinreichende" heissen, oder?
>
> Nein, "keine notwendige" ist schon richtig:
>
> "Der zweite Unterschied zwischen realen und ausgedachten Zufallsfolgen
> ist nicht
> ganz so auffällig. Menschen neigen dazu, innerhalb kurzer Zeit alle
> Ziffern gleich
> häufig zu nennen; sie achten also auf eine Gleichverteilung der
> Würfelergebnisse.
> Zwar nähert sich der Anteil einer Zahl auf längere Sicht auch beim
> realen Würfeln
> einem Erwartungswert. Es gibt aber keinen Zwang zum Ausgleich."
>
> (http://www.quarks.de/dyn/5296.phtml)
Diese Zitat hat wohl nichts mit dem zu tun, wovon hier die Rede ist.
Es sagt, dass viele Menschen den Begriff "Gleichverteilung" falsch
interpretieren. Das ist keine Neuigkeit und hat nicht die geringste
mathematische Relevanz.
MfG
Horst
Alexander Schestag
Horst Kraemer schrieb:
> On Fri, 09 May 2003 22:18:18 +0200, Alexander Schestag
> <imh...@gmx.de> wrote:
>>>>Gleichverteilung ist KEINE notwendige Voraussetzung für die Zufälligkeit
>>>>einer Folge.
> Das ist wohl trivial. Es gibt auch noch andere Verteilungen als die
> Gleichverteilung.
So trivial dann anscheinend doch nicht. Denn viele sitzen immer noch
diesem Irrtum auf.
>>>Das sollte wohl eher "keine hinreichende" heissen, oder?
>>Nein, "keine notwendige" ist schon richtig:
>>"Der zweite Unterschied zwischen realen und ausgedachten Zufallsfolgen
>>ist nicht
>>ganz so auffällig. Menschen neigen dazu, innerhalb kurzer Zeit alle
>>Ziffern gleich
>>häufig zu nennen; sie achten also auf eine Gleichverteilung der
>>Würfelergebnisse.
>>Zwar nähert sich der Anteil einer Zahl auf längere Sicht auch beim
>>realen Würfeln
>>einem Erwartungswert. Es gibt aber keinen Zwang zum Ausgleich."
>>(http://www.quarks.de/dyn/5296.phtml)
> Diese Zitat hat wohl nichts mit dem zu tun, wovon hier die Rede ist.
> Es sagt, dass viele Menschen den Begriff "Gleichverteilung" falsch
> interpretieren. Das ist keine Neuigkeit und hat nicht die geringste
> mathematische Relevanz.
Nein, es ist auch ein Indiz dafür, daß Menschen Gleichverteilung als
notwendige Voraussetzung für die Zufälligkeit einer Folge ansehen,
obwohl es keine ist.
Grüße,
Alex
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>>>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>und
>>> for i:=1 to SIZE do irgendwas;
>>>die Grenzen jeweils inklusive sind, in den C-ähnlichen Sprachen
>>>aber mit
>>> int x[SIZE];
>>>und
>>> for (int i = 0; i < SIZE; ++i) irgendwas;
>>>nicht.
>
>> Aber sicher doch.
>
>> Den Unterschied zu
>
>> |for i in x'Range loop
>
>> zu obigem sehe ich naemlich nicht.
>
>An der Stelle ist tatsächlich kein großer Unterschied.
>
>Außer, daß die Pascal/Ada-Schleife für den Compilerbauer
>schwieriger zu implementieren ist.
Ehrlich gesagt, bin ich da gemein und es ist mir vollkommen
scheissegal, wie schwierig das fuer den Compilerbauer ist.
>In C muß man das explizit hinschreiben,
> if (a <= b)
> do
> irgendwas;
> while (a++ <= b);
>damit hat der Compiler weniger Arbeit :-)
Dafuer *ich* und das ist es, was im Endeffekt zaehlt. Fuer den
Compiler zahlt man naemlich bestenfalls einmal (Versionshascherei
lasse ich mal aussen vor), dafuer bin ich derjenige, der die Firma
monatlich eine eventuell nicht ganz unerhebliche Menge Geld kostet.
>> Intervall 1: Low (x) to High (x) div 2
>> Intervall 2: High (x) div 2 + 1 to High (x)
> ^^^
>> In C drueckst Du das doch prinzipiell auch nicht anders aus.
>
>Doch, ich spare mir das blöde "+1" Rumgerechne.
Lediglich, weil Du ein < statt eines <= verwendest, oder?
>>>Ein leeres halboffenes Intervall ist [a,a[. Ein leeres
>>>geschlossenes Intervall ist [a,a-1] ("bitte? die rechte Grenze
>>>kleiner als die linke?").
>
>> Durchaus korrekt.
>
>Mathematisch aber Blödsinn.
Nein, wieso? Eine Menge, die die Elemente 0 bis 0 beinhaltet, ist doch
keine leere Menge:
|for Some_Hardware_Variable use
| Empty_Flag range 4 .. 4;
| ...
Stefan Reuther
> Stefan Reuther <sr...@inf.tu-dresden.de> spoke thusly:
>> Sebastian Suchanek <spa...@suchanek.de> wrote:
>>> Wer ist denn auf die blödsinnige Idee gekommen, das
>>> Ergebnis von random nur in [0,1[ und nicht in [0,1] zu
>>> legen?
>>
>> Jemand, der Ahnung von der Materie hatte? *duck*
>>
>> Nur so lassen sich wirklich gleichverteilte Zufallszahlen
>> erzeugen.
> Glaube ich Dir nicht. :-)
[...]
> "Workaround" 3:
> | function wuerfel: integer;
> |
> | begin
> | wuerfel := random(5) + 1;
> | end;
> Wäre gleichverteilt und würde Zahlen aus [1,6] liefern.
Es ging darum, warum "random" [0,1[ liefert und nicht [0,1].
Meine Argumentation: weil man nur aus [0,1[ einen vernünftigen
Zufallsgenerator bauen kann, der N gleichverteilte diskrete
Werte liefert.
Wenn du schon einen Zufallsgenerator hast, der gleichverteilte
diskrete Werte lieferst, ist diese Argumentation natürlich
hinfällig. Dann ist mir auch egal, ob diese Funktion "random(5)",
"random(6)", "spring_im_dreieck" oder "((void(*)())"ð\17ÇÈ")()"
aufgerufen wird.
Stefan
Stefan Reuther
Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>>> Aber sicher doch.
>>
>>> Den Unterschied zu
>>
>>> |for i in x'Range loop
>>
>>> zu obigem sehe ich naemlich nicht.
>>
>>An der Stelle ist tatsächlich kein großer Unterschied.
>>
>>Außer, daß die Pascal/Ada-Schleife für den Compilerbauer
>>schwieriger zu implementieren ist.
> Ehrlich gesagt, bin ich da gemein und es ist mir vollkommen
> scheissegal, wie schwierig das fuer den Compilerbauer ist.
Mir ist das nicht egal. Erstens: ich bin Compilerbauer :-)
Zweitens: der Code, den zumindest Turbo Pascal dafür erzeugt,
ist alles andere als optimal, da eine Menge Sprünge drin sind.
Wie wir aus dclax wissen, sind Sprünge teuer.
>>> Intervall 1: Low (x) to High (x) div 2
>>> Intervall 2: High (x) div 2 + 1 to High (x)
>> ^^^
>>> In C drueckst Du das doch prinzipiell auch nicht anders aus.
>>
>>Doch, ich spare mir das blöde "+1" Rumgerechne.
> Lediglich, weil Du ein < statt eines <= verwendest, oder?
Ja. Weil ich (in C(++)) "<" verwenden kann; in Pascal muß ich
"<=" verwenden oder manuell mit "while" rummachen.
Disclaimer: ich bin nicht der Meinung, daß C/C++ die Rundum-
Wohlfühl-Sprache ist. Pascal aber auch nicht. Und die C/C++
for-Schleife ist einfach genial :-)
>>>>Ein leeres halboffenes Intervall ist [a,a[. Ein leeres
>>>>geschlossenes Intervall ist [a,a-1] ("bitte? die rechte Grenze
>>>>kleiner als die linke?").
>>
>>> Durchaus korrekt.
>>
>>Mathematisch aber Blödsinn.
> Nein, wieso? Eine Menge, die die Elemente 0 bis 0 beinhaltet, ist doch
> keine leere Menge:
> |for Some_Hardware_Variable use
> | Empty_Flag range 4 .. 4;
> | ...
Ja. Eine Menge, die alle Elemente enthält, die ">=5" und "<=4"
sind, ist eine leere Menge. Dennoch finde ich das etwas
kontra-intuitiv ("bring bitte fünf oder mehr, aber vier oder
weniger Brötchen mit").
Ich finde halt halboffene Intervalle schöner *schulterzuck*
Stefan
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>
>> Ehrlich gesagt, bin ich da gemein und es ist mir vollkommen
>> scheissegal, wie schwierig das fuer den Compilerbauer ist.
>
>Mir ist das nicht egal. Erstens: ich bin Compilerbauer :-)
Selbst schuld. :-> Aber genau genommen ist fuer Compilerbauer ohnehin
nur Assembler einfach. Im uebrigen habe ich zumindest bei meinem
Ressourcencompiler keine Probleme mit Schleifen gehabt, auch wenn die
nicht bei Null anfingen. Gut, optimieren muss man da nicht, die
Dateioperationen nehmen >99% der Laufzeit ein.
>Zweitens: der Code, den zumindest Turbo Pascal dafür erzeugt,
>ist alles andere als optimal, da eine Menge Sprünge drin sind.
Turbo Pascal ist ohnehin nicht gerade die Referenz, was Optimierung
betrifft. Und der Code fuer nullbasierte Schleifen sollte da, wenn
ueberhaupt, auch nur marginal besser sein.
Ansonsten scheint es zumindest dem hier werkelnden Ada-Compiler
ziemlich egal zu sein, ob er in einer Schleife nun den Abbruch bei 9
(0 .. 9) oder bei 10 (1 .. 10) initiiert. Bei rueckwaerts laufenden
Schleifen, wo er auf Null testen kann, mag das evt. ein klein wenig
anders aussehen.
Insofern scheint er meine Sichtweise zu teilen, dass die realen
Indizes fuer die Arrays eigentlich egal sind, weil ich die ohnehin mit
"minimaler" und "maximaler" Index abstrahiere.
>Wie wir aus dclax wissen, sind Sprünge teuer.
Schon richtig, tut aber eigentlich nicht allzuviel zur Sache, da in
einer Schleige so oder so x-mal gesprungen werden muss.
>Disclaimer: ich bin nicht der Meinung, daß C/C++ die Rundum-
>Wohlfühl-Sprache ist. Pascal aber auch nicht.
ACK.
>Und die C/C++ for-Schleife ist einfach genial :-)
Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
des Konzepts der "for"-Schleife.
Ein vorzeitiges exit uebrigens auch. :->
Ansonsten ueberlasse ich mittlerweile bei nicht sonderlich
zeitkritischem Code ohnehin dem Compilerbauer die Entscheidung, wie er
die Schleife nun implementiert. Von mir aus darf er ja gern einfach
die Indizierung des Arrays intern wieder so umbauen, dass er bei Null
anfaengt, zu zaehlen.
>>>>>Ein leeres halboffenes Intervall ist [a,a[. Ein leeres
>>>>>geschlossenes Intervall ist [a,a-1] ("bitte? die rechte Grenze
>>>>>kleiner als die linke?").
>>>
>>>> Durchaus korrekt.
>>>
>>>Mathematisch aber Blödsinn.
>
>> Nein, wieso? Eine Menge, die die Elemente 0 bis 0 beinhaltet, ist doch
>> keine leere Menge:
>
>> |for Some_Hardware_Variable use
>> | Empty_Flag range 4 .. 4;
>> | ...
>
>Ja. Eine Menge, die alle Elemente enthält, die ">=5" und "<=4"
>sind, ist eine leere Menge.
Exakt. Wieso also Bloedsinn?
>Dennoch finde ich das etwas
>kontra-intuitiv ("bring bitte fünf oder mehr, aber vier oder
>weniger Brötchen mit").
Andererseits: "Bringe bitte vier bis hoechstens weniger als vier
Broetchen mit." klingt auch nicht gerade intuitiver, oder? Ich haette
mir doch glatt die Geldboerse geschnappt und waere loesgestiefelt. :)
>Ich finde halt halboffene Intervalle schöner *schulterzuck*
Das schoene an Pascal und Nachfolgern ist, dass ich die da eben *auch*
haben kann. Ich finde C und Konsorten da lediglich zu restriktiv, weil
ich sie dort eben *ausschliesslich* habe.
Stefan Reuther
Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>Und die C/C++ for-Schleife ist einfach genial :-)
> Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
> des Konzepts der "for"-Schleife.
Es ist halt eine Schleife zur Iteration über beliebige Mengen.
Das können Integer-Bereiche sein, aber eben auch Listen, und
vieles mehr.
`For i In <menge>' ist ja gewissermaßen auch "Vergewaltigung des
Konzeptes". In C hat man aber eben die Freiheit bzw. die
Pflicht, die Menge und die Iteration dadurch selbst zu
spezifizieren.
>>Ich finde halt halboffene Intervalle schöner *schulterzuck*
> Das schoene an Pascal und Nachfolgern ist, dass ich die da eben *auch*
> haben kann. Ich finde C und Konsorten da lediglich zu restriktiv, weil
> ich sie dort eben *ausschliesslich* habe.
Halboffene Intervalle ohne "+1"/"-1" rumgerechne?
In Schleifen habe ich in Pascal *ausschließlich* geschlossene
Intervalle ("for i:=a to b"), in Arrays auch (array[a..b]). In
der C-Ecke habe ich für Felder nur halboffene Intervalle, aber
für Schleifen kann ich mir's raussuchen ("for (i=a; i<b; ++i)"
und "for (i=a; i<=b; ++i)").
Wenn du eine Pascal-For-Schleife kennst, die durch ein
halboffenes Intervall rennt, immer her damit, kann ich gut
gebrauchen. C++-Felder mit Aufzählungstyp als Index (also das
Äquivalent zu "type a = (Apfel,Birne,Citrone); b = array[a] of
integer") suche ich aber auch noch :-)
Stefan
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>Und die C/C++ for-Schleife ist einfach genial :-)
>
>> Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
>> des Konzepts der "for"-Schleife.
>
>Es ist halt eine Schleife zur Iteration über beliebige Mengen.
>Das können Integer-Bereiche sein, aber eben auch Listen, und
>vieles mehr.
Das Problem ist, dass sie zu vielen anderem missbraucht werden kann
und deswegen natuerlich auch wird.
>`For i In <menge>' ist ja gewissermaßen auch "Vergewaltigung des
>Konzeptes".
Nein, es ist nach wie vor eine Iteration ueber einen spaetestens zum
Ausfuehrungszeitpunkt bekannten Bereich. "Zur Ausfuehrungszeit" z.B.
wegen der Moeglichkeit dynamisch angelegter Arrays.
Ein
|for (i = 0; s[i]; i++) ...
ist das aber schon nicht mehr.
Das 'Range-Attribut gibt Dir lediglich den Bereich an, ueber den der
Typ definiert ist, spart also Tipparbeit und ist nebenher auch noch
typsicher. Genausogut darfst Du natuerlich
|for i in Typ'First .. Typ'Last loop
oder gleich
|for i in 0 to 319 loop
schreiben. Worin das Problem beim letzten Ansatz besteht, duerfte klar
sein.
BTW, weil wir letztens bei leeren Mengen waren: Was macht
|for (unsigned int i = 0; i < MAX_BUF; i++)
eigentlich, wenn MAX_BUF == 0? Ich kann mir einfach nicht merken, wann
die Bedingung abgefragt wird...
Bei den leeren Mengen in Pascal/Ada/$whatever wird die Schleife
jedenfalls korrekt gar nicht ausgefuehrt, wenn es ja nichts zu
iterieren gibt (try: for i := 1 to 0 do).
>In C hat man aber eben die Freiheit bzw. die
>Pflicht, die Menge und die Iteration dadurch selbst zu
>spezifizieren.
Freiheit, nunja. Ich lasse mir diese Freiheit lieber vom Compiler
einschraenken, falls und weil ich dadurch weniger Fehler mache.
>> Das schoene an Pascal und Nachfolgern ist, dass ich die da eben *auch*
>> haben kann. Ich finde C und Konsorten da lediglich zu restriktiv, weil
>> ich sie dort eben *ausschliesslich* habe.
>
>Halboffene Intervalle ohne "+1"/"-1" rumgerechne?
Klar:
|for i := Succ ((High (x) - Low (x)) div 2) to High (x) do
;-)
Siehst Du da irgendwo ein +1/-1?
>In Schleifen habe ich in Pascal *ausschließlich* geschlossene
>Intervalle ("for i:=a to b"), in Arrays auch (array[a..b]).
Klar, aber das ist rein eine Frage, wie nun der Indexbereich angegeben
wird.
>In
>der C-Ecke habe ich für Felder nur halboffene Intervalle, aber
>für Schleifen kann ich mir's raussuchen ("for (i=a; i<b; ++i)"
>und "for (i=a; i<=b; ++i)").
Ehrlich gesagt, koennte ich mir jetzt beim Vergleich "<" und "<="
annaehernd die gleiche Fehlerrate wie bei einem vergessenen +1/-1
vorstellen. Gut versteckt ist es auf jeden Fall.
>Wenn du eine Pascal-For-Schleife kennst, die durch ein
>halboffenes Intervall rennt, immer her damit, kann ich gut
>gebrauchen.
Siehe oben. Succ() und Pred() sind Dein Freund. ;)
>C++-Felder mit Aufzählungstyp als Index (also das
>Äquivalent zu "type a = (Apfel,Birne,Citrone); b = array[a] of
>integer") suche ich aber auch noch :-)
Gefaellt Dir
|enum {Apfel, Birne, Citrone};
|int b[Citrone];
(oder so) etwa nicht? ;-> Du musst natuerlich aufpassen, dass Du
"Dattel" dann an der richtigen Stelle in der Deklaration einfuegst.
Freiheit hat halt ihren Preis, nicht?
Und apropos Compilerbau, weil Dir nicht nullbasierte Schleifen schon
suspekt zu sein scheinen:
|type Obst is (Apfel, Birne, Citrone, Dattel);
|
|for Obst use
| (Apfel => 1, Birne => 3, Citrone => 10, Dattel => 23);
|
|type Obstmenge is array (Obst) of Integer;
Ja, natuerlich will ich ueber das Array auch iterieren. *Das* ist doch
auch ohne ein "Pragma Pack (Obstmenge);" fast schon gehaessig, oder?
Sebastian Suchanek
> Sebastian Suchanek <spa...@suchanek.de> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> spoke thusly:
>>> Sebastian Suchanek <spa...@suchanek.de> wrote:
>>>
>>>> Wer ist denn auf die blödsinnige Idee gekommen, das
>>>> Ergebnis von random nur in [0,1[ und nicht in [0,1] zu
>>>> legen?
>>>
>>> Jemand, der Ahnung von der Materie hatte? *duck*
>>>
>>> Nur so lassen sich wirklich gleichverteilte Zufallszahlen
>>> erzeugen.
>
>> Glaube ich Dir nicht. :-)
> [...]
>> "Workaround" 3:
>
>> | function wuerfel: integer;
>> |
>> | begin
>> | wuerfel := random(5) + 1;
>> | end;
>
>> Wäre gleichverteilt und würde Zahlen aus [1,6] liefern.
>
> Es ging darum, warum "random" [0,1[ liefert und nicht
> [0,1]. Meine Argumentation: weil man nur aus [0,1[ einen
> vernünftigen Zufallsgenerator bauen kann, der N
> gleichverteilte diskrete Werte liefert.
Moment, Du hast Deine abenteuerlichen Workarounds als Begründung
dafür angeführt, daß die Ergebnisse aus [0,1[ und nicht aus
[0,1] kommen müssen. Zumindest hat sich das so für mich so
dargestellt.
Und eben das wollte ich Dir mit obigem Beispiel wiederlegen.
Davon abgesehen hast Du keine weitere *Begründung* (<>
Behauptung) geliefert, warum nun ausgerechnet [0,1[ besser zu
implementieren sein soll.
(Bevor Du Dir Mühe machst: Vermutlich fehlt mir das nötige
Grundlagenwissen, um Pros und Contras diverser Implementierungen
diskutieren zu können.)
> [...]
> Dann ist mir auch egal,
> ob diese Funktion "random(5)", "random(6)",
> "spring_im_dreieck" oder "((void(*)())"ð\17ÇÈ")()"
> aufgerufen wird.
:-)
Stefan Reuther
Sebastian Suchanek <spa...@suchanek.de> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> spoke thusly:
>> Sebastian Suchanek <spa...@suchanek.de> wrote:
>>> Wäre gleichverteilt und würde Zahlen aus [1,6] liefern.
>>
>> Es ging darum, warum "random" [0,1[ liefert und nicht
>> [0,1]. Meine Argumentation: weil man nur aus [0,1[ einen
>> vernünftigen Zufallsgenerator bauen kann, der N
>> gleichverteilte diskrete Werte liefert.
> Moment, Du hast Deine abenteuerlichen Workarounds als Begründung
> dafür angeführt, daß die Ergebnisse aus [0,1[ und nicht aus
> [0,1] kommen müssen. Zumindest hat sich das so für mich so
> dargestellt.
Genau. "Nur aus [0,1[ kann man einen vernünftigen
Zufallsgenerator bauen, der N gleichverteilte diskrete Werte
liefert".
> Und eben das wollte ich Dir mit obigem Beispiel wiederlegen.
Du hast das Vorhandensein eines Zufallsgenerators, der diskrete
Werte liefert, vorausgesetzt. Problem gelöst durch Lösung, die
vom Himmel fällt.
> Davon abgesehen hast Du keine weitere *Begründung* (<>
> Behauptung) geliefert, warum nun ausgerechnet [0,1[ besser zu
> implementieren sein soll.
Ich habe eine Begründung geliefert, warum man "[0,1[" besser
anwenden kann.
Man kann es in der Tat besser implementieren. Angenommen, du
hast einen Zufallsgenerator, der dir 16 Zufallsbits liefert, zum
Beispiel diese hier: 0100010100101110. Dann ist deine
Zufallszahl einfach 0.0100010100101110 (binär natürlich). Um
diskrete Werte aus [0,n[ zu erhalten, multipliziere das ganze
mit "n" und wirf die letzten 16 bit weg.
Solche Zufallsgeneratoren gibt's wie Sand am Mehr. Ich verwende
z.B. den hier:
var seed : word;
function rand : word;
begin
seed := 13489 - 259 * seed;
rand := seed;
end;
Der in Turbo Pascal 6.0/7.0 eingebaute Generator ist der hier:
var randseed : longint;
function rand : longint;
begin
randseed := 1 + $8088405 * randseed;
rand := randseed;
end;
(falls dich das Prinzip dahinter interessiert, suche nach dem
Stichwort "linear congruential sequence").
Wenn du Zufallszahlen aus [0,1] haben wölltest, müßtest du das
noch irgendwie skalieren, z.B. durch Floating Point Division
durch 2^16-1.
MS BASIC bietet z.B. als einzigen Zufallsgenerator eine Funktion
"RND", die Zufallszahlen aus [0,1] gleichverteilt liefert. Die
übliche Anwendung ist "INT(RND * 100)" ("INT" ist das, was
"Trunc" in Pascal ist). Dieser Ausdruck liefert meistens (d.h.
laut Murphy beim Debuggen "immer") Werte zwischen 0 und 99. Nur
in einem von 2^16 Fällen kommt mal 100 raus. Ergebnis: Programm
liefert unerwartete Ergebnisse oder stürzt ab, weil der
Programmierer diesen Fall nie zu Gesicht bekam und ihn daher
auch nicht behandelt hat. Keine Polemik, sondern traurige
Realität.
Stefan
Stefan Reuther
Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>>Und die C/C++ for-Schleife ist einfach genial :-)
>>
>>> Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
>>> des Konzepts der "for"-Schleife.
>>
>>Es ist halt eine Schleife zur Iteration über beliebige Mengen.
>>Das können Integer-Bereiche sein, aber eben auch Listen, und
>>vieles mehr.
> Das Problem ist, dass sie zu vielen anderem missbraucht werden kann
> und deswegen natuerlich auch wird.
Die soll ja nicht Idioten helfen, sondern Geniearbeit
unterstützen :-)
> BTW, weil wir letztens bei leeren Mengen waren: Was macht
> |for (unsigned int i = 0; i < MAX_BUF; i++)
> eigentlich, wenn MAX_BUF == 0? Ich kann mir einfach nicht merken, wann
> die Bedingung abgefragt wird...
C-"for" ist eine verkappte "while"-Schleife, die Bedingung wird
also vorher getestet.
>>> Das schoene an Pascal und Nachfolgern ist, dass ich die da eben *auch*
>>> haben kann. Ich finde C und Konsorten da lediglich zu restriktiv, weil
>>> ich sie dort eben *ausschliesslich* habe.
>>
>>Halboffene Intervalle ohne "+1"/"-1" rumgerechne?
> Klar:
> |for i := Succ ((High (x) - Low (x)) div 2) to High (x) do
> ;-)
> Siehst Du da irgendwo ein +1/-1?
ja, in der Hilfe zu "succ".
template<class T> T succ(T t) { ++t; return t; }
>>In der C-Ecke habe ich für Felder nur halboffene Intervalle,
>>aber für Schleifen kann ich mir's raussuchen ("for (i=a; i<b;
>>++i)" und "for (i=a; i<=b; ++i)").
> Ehrlich gesagt, koennte ich mir jetzt beim Vergleich "<" und "<="
> annaehernd die gleiche Fehlerrate wie bei einem vergessenen +1/-1
> vorstellen. Gut versteckt ist es auf jeden Fall.
Naja, die Praxis zeigt, daß *ich* mich bei C-For-Schleifen
inzwischen so gut wie nie vertue, bei den "+1/-1"-Geschichten
allerdings doch. Offenbar einfach Gewöhnungssache, obwohl ich
Pascal bereits doppelt so lange wie C(++) mache.
Ich leite hier aber auch ein paar C-Praktika, und meine
Praktikanten machen da durchaus Fehler. Auch, wenn ich als
"Kochrezept" nur die Schleife mit "<" angegeben habe, sehe ich
immer wieder mal "<=".
>>C++-Felder mit Aufzählungstyp als Index (also das
>>Äquivalent zu "type a = (Apfel,Birne,Citrone); b = array[a] of
>>integer") suche ich aber auch noch :-)
> Gefaellt Dir
> |enum {Apfel, Birne, Citrone};
> |int b[Citrone];
> (oder so) etwa nicht? ;->
Nein, denn das Feld ist eins zu klein.
| enum a { Apfel, Birne, Citrone, LAST };
| int b[LAST];
wäre noch möglich, dann bekomme ich aber bei einem "switch"
immer eine Warnung, daß ich LAST nicht behandeln würde.
| enum a { Apfel, Birne, Citrone };
| enum { OBST = Citrone+1; }
| int b[OBST];
geht, gefällt mir aber nicht.
> Du musst natuerlich aufpassen, dass Du
> "Dattel" dann an der richtigen Stelle in der Deklaration einfuegst.
> Freiheit hat halt ihren Preis, nicht?
ja.
> Und apropos Compilerbau, weil Dir nicht nullbasierte Schleifen schon
> suspekt zu sein scheinen:
erm, nein. Mir sind Schleifen wie diese suspekt
for i:=a to b do ...
weil man die weder als "while", noch als "repeat" implementieren
kann, wenn man sowohl den Fall "a=MININT, b=MAXINT", als auch
den Fall "a=MAXINT,b=MININT" behandeln muß.
> |type Obst is (Apfel, Birne, Citrone, Dattel);
> |
> |for Obst use
> | (Apfel => 1, Birne => 3, Citrone => 10, Dattel => 23);
> |
> |type Obstmenge is array (Obst) of Integer;
> Ja, natuerlich will ich ueber das Array auch iterieren. *Das* ist doch
> auch ohne ein "Pragma Pack (Obstmenge);" fast schon gehaessig, oder?
jo. Aber sicherlich praktisch.
Stefan
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>>>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>>>Und die C/C++ for-Schleife ist einfach genial :-)
>>>
[...]
>
>Die soll ja nicht Idioten helfen, sondern Geniearbeit
>unterstützen :-)
Nunja. Wenn ich mir so supertoll genialen C-Code ansehe, sieht der
manchmal eher wie eine Arbeitssicherungsmassnahme[0] aus. Nein, ich
beziehe das jetzt nicht auf Dich.
>>>Halboffene Intervalle ohne "+1"/"-1" rumgerechne?
>
>> Klar:
>
>> |for i := Succ ((High (x) - Low (x)) div 2) to High (x) do
>
>> ;-)
>
>> Siehst Du da irgendwo ein +1/-1?
>
>ja, in der Hilfe zu "succ".
|type etwas = (nichts, einbisschen, mehr, alles);
|
|var
| a : etwas;
| ...
| a := a + 1;
*oops* Typfehler? Kann nicht sein. ;)
Zur Kontrolle, BP7 meint:
|Succ (Funktion)
|________________
| Liefert den Nachfolger des Arguments zurück.
|
| Deklaration:
| function Succ(X): (Same type as parameter);
|
| Zielsystem:
| Windows, Real, Protected
| Bemerkungen:
| X ist ein ordinaler Ausdruck beliebigen Typs. Das Ergebnis der
| Funktion hat denselben Typ und stellt den Nachfolger von X dar.
Da steht Nachfolger, was durchaus nicht unbedingt +1 heisst.
>template<class T> T succ(T t) { ++t; return t; }
Das klappt nicht mit enums, wenn ich aspect clauses (oder wie auch
immer ihr das in C++ nennt) angebe.
Ehrlich mal, manchmal koennen die C++er einem schon leid tun, muessen
alles selbst definieren. Ist ja huebsch, aber oft genug zuviel Arbeit,
die man sich spart bzw. ohne den Verzicht auf solche Features sogar
sparen koennte.
>Naja, die Praxis zeigt, daß *ich* mich bei C-For-Schleifen
>inzwischen so gut wie nie vertue,
"So gut wie nie" reicht nicht. :)
>bei den "+1/-1"-Geschichten
>allerdings doch. Offenbar einfach Gewöhnungssache, obwohl ich
>Pascal bereits doppelt so lange wie C(++) mache.
Ehrlich gesagt muss ich einfach selten mit halben Arrays rechnen. Und
dort, wo mich Start- und End-Index anders interessieren als fuer die
Bereichsangabe, schaffe ich das auch.
>Ich leite hier aber auch ein paar C-Praktika, und meine
>Praktikanten machen da durchaus Fehler. Auch, wenn ich als
>"Kochrezept" nur die Schleife mit "<" angegeben habe, sehe ich
>immer wieder mal "<=".
Sind sie vorher zufaellig mit M0 versaut worden?
>> Gefaellt Dir
>
>> |enum {Apfel, Birne, Citrone};
>> |int b[Citrone];
>
>> (oder so) etwa nicht? ;->
>
>Nein, denn das Feld ist eins zu klein.
Stimmt. Klassischer Fehler.
Und spaetestens, wenn Du dann noch das Aequivalent zu Adas aspect
clauses angibst, wuerdest Du damit wahrscheinlich ohnehin auch
kraeftigst auf die Schnauze fallen.
>| enum a { Apfel, Birne, Citrone, LAST };
>| int b[LAST];
>wäre noch möglich, dann bekomme ich aber bei einem "switch"
>immer eine Warnung, daß ich LAST nicht behandeln würde.
Stimmt ja, die neueste Errungenschaft, die man aus der Ada-Welt
geklaut hat. Ausserdem muesstest Du das LAST immer mit einem passenden
Zusatz versehen[2], da es ja keine Typen mit sich traegt...
>| enum a { Apfel, Birne, Citrone };
>| enum { OBST = Citrone+1; }
>| int b[OBST];
>geht, gefällt mir aber nicht.
Lass mich raten, da ist ja schon wieder ein +1 drin? Und ein sizeof()
hilft auch nicht wirklich. You are lost.
>> Und apropos Compilerbau, weil Dir nicht nullbasierte Schleifen schon
>> suspekt zu sein scheinen:
>
>erm, nein. Mir sind Schleifen wie diese suspekt
> for i:=a to b do ...
>weil man die weder als "while", noch als "repeat" implementieren
>kann, wenn man sowohl den Fall "a=MININT, b=MAXINT", als auch
>den Fall "a=MAXINT,b=MININT" behandeln muß.
Mmh?
|i = a;
|while (i <= b) do { ...; i++; }
Uebersehe ich etwas oder was genau klappt daran nicht?
>> |type Obst is (Apfel, Birne, Citrone, Dattel);
>> |
>> |for Obst use
>> | (Apfel => 1, Birne => 3, Citrone => 10, Dattel => 23);
>> |
>> |type Obstmenge is array (Obst) of Integer;
>
>> Ja, natuerlich will ich ueber das Array auch iterieren. *Das* ist doch
>> auch ohne ein "Pragma Pack (Obstmenge);" fast schon gehaessig, oder?
>
>jo. Aber sicherlich praktisch.
Nunja, troeste Dich, das ist sowieso eher eine der weniger genutzten
Moeglichkeiten[1]. Aber praktisch, wenn man es denn mal braucht.
Vinzent.
[0] Der einzige, der den Code jemals verstanden hat, war der, der ihn
schrieb. Zwanzig Minuten lang.
[1] Wie es ein "type Hash is integer mod 13;" wahrscheinlich auch ist.
[2] Gut, es gaebe ja namespaces...
Georg Richter
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
Hallo ihr beiden,
endlich ist hier wieder 'mal 'was los.
>> Naja, die Praxis zeigt, daß *ich* mich bei C-For-Schleifen
>> inzwischen so gut wie nie vertue,
Der Stefan schreibt Compiler für Mickrosoft ;-)
> "So gut wie nie" reicht nicht. :)
Das wäre doch Fuzzy-Logik, oder?
> [0] Der einzige, der den Code jemals verstanden hat, war der, der ihn
schrieb. Zwanzig Minuten lang.
Das ist wohl wahr, seufz.
Gruss,
Georg
--
Georg O.F. Richter
alias Hourdi
hourdi_@_t-online.de
Horst Kraemer
<JeLlyFish...@gmx.net> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>
> >Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
> >> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
> >>>Und die C/C++ for-Schleife ist einfach genial :-)
> >
> >> Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
> >> des Konzepts der "for"-Schleife.
Das C-for hat nichts mit dem Pascal-for zu tun. Das C-for ist nichts
als ein aufgemotztes while
for (expr1;expr2;expr3) statement
ist (bis auf die Wirkung von 'continue' innerhalb von 'statement' )
eine Kurzschreibweise fuer
expr1;
while (expr2)
{
statement
expr3;
}
Wenn expr2 leer ist, wird es implizit durch die Konstante 1 ("true")
ersetzt.
so what?
Aus einer Namensgleichheit mit Konstrukten anderer Programmiersprachen
eine Vergewaltigung abzuleiten, empfinde ich als ausgesprochen
unelegant ;-)
> >Es ist halt eine Schleife zur Iteration über beliebige Mengen.
> >Das können Integer-Bereiche sein, aber eben auch Listen, und
> >vieles mehr.
>
> Das Problem ist, dass sie zu vielen anderem missbraucht werden kann
> und deswegen natuerlich auch wird.
Ich bin zwar mit Pascal aufgewachsen, aber ich werde nie verstehen,
warum manche Pascal-Parteigaenger bei jeder sich bietenden Gelegenheit
dieses laue Argument auspacken...
Lehn Dich zurueck und geniesse die Vielfalt ;-)
MfG
Horst
Vinzent Hoefler
>On Mon, 12 May 2003 19:48:46 +0200, Vinzent Hoefler
><JeLlyFish...@gmx.net> wrote:
>
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>
>> >Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> >> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>> >>>Und die C/C++ for-Schleife ist einfach genial :-)
>> >
>> >> Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
>> >> des Konzepts der "for"-Schleife.
>
>Das C-for hat nichts mit dem Pascal-for zu tun. Das C-for ist nichts
>als ein aufgemotztes while
Ja, weiss ich (naja, mehr oder weniger ;-). Und eben deswegen ist es
Vergewaltigung. Es hat mit einer for-Schleife nichts zu tun, also soll
man das Ding gefaelligst auch nicht so nennen.
>Aus einer Namensgleichheit mit Konstrukten anderer Programmiersprachen
>eine Vergewaltigung abzuleiten, empfinde ich als ausgesprochen
>unelegant ;-)
So?
|function "+" (Left, Right : Integer) return Integer is
|begin
| return (Standard."*" (Left, Right));
|end "+";
*Ich* wuerde *das* als Vergewaltigung des "+" Operators auffassen.
Oder sollte ich aus der Namensgleichheit nichts schliessen duerfen?
>> Das Problem ist, dass sie zu vielen anderem missbraucht werden kann
>> und deswegen natuerlich auch wird.
>
>Ich bin zwar mit Pascal aufgewachsen, aber ich werde nie verstehen,
>warum manche Pascal-Parteigaenger bei jeder sich bietenden Gelegenheit
>dieses laue Argument auspacken...
Das haengt bei mir einfach damit zusammen, dass ich zuviel von solchen
Vergewaltigungen sehe.
>Lehn Dich zurueck und geniesse die Vielfalt ;-)
Wenn ich diese Vielfalt nicht immer mal wieder debuggen muesste, waere
das *gar* kein Problem.
Horst Kraemer
<spa...@suchanek.de> wrote:
Jedem "Zufallszahlengenerator" liegt ein ganzzahliger
Zufallszahlengenerator der eine Folge aus den N Zahlen
{0,1,2,3,...,N-1} asugibt.
Ueblicherweise ist N eine 2er-Potenz. Das kleine Problem ist nun die
Abbildung dieses ganzzahligen Generators auf ein Intervall von
Gleitkommazahlen. Wenn man nun die generierten ganzen Zahlen k per
k/N abbildet, so ist der entspechende Gleitkommawert i.d.R. exakt.
Selbst bei N=2^32 lassen sich die Gleitkommazahlen exakt als
IEEE-double abbilden mit exakt N Werten <1.
Wenn man durch k/(N-1) abbilden wuerde, ist dieser Bruch i.d.R. nie
exakt abbildbar. D.h. fuer den moeglichen Wert k=N-1 ist der
entsprechende Gleitkommawert entweder >1 oder <1, aber nie =1.
Auch ist die Abbildung k/N unempfindlich gegen Skalierungen.
Wenn man den Gleitkommawert z.B. per z' = m*z+a skaliert, ist
ebenfalls garantiert, dass alle Werte von z' im halboffenen Intervall
[a,m+a) liegen.
Dies ist ein Argument dafuer, warum der Umgang mit halboffenen oder
offene Intervallen oft bequemener und numerisch weniger problematisch
als der Umgang mit beidseitig abgeschlossenen Intervallen. Es
entfaellt die bei numerischen Problemen laestige "Endpunktphobie".
MfG
Horst
Stefan Reuther
Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>>Halboffene Intervalle ohne "+1"/"-1" rumgerechne?
>>
>>> |for i := Succ ((High (x) - Low (x)) div 2) to High (x) do
>>
>>> Siehst Du da irgendwo ein +1/-1?
>>
>>ja, in der Hilfe zu "succ".
[...]
> |Succ (Funktion)
> |________________
> | Liefert den Nachfolger des Arguments zurück.
Hmmm, ja, grummel :-)
>>template<class T> T succ(T t) { ++t; return t; }
> Das klappt nicht mit enums, wenn ich aspect clauses (oder wie auch
> immer ihr das in C++ nennt) angebe.
enum Bernd { x=1, y=2984, z=39 };
Da ist eh nicht ganz klar, was denn nun der "Nachfolger" von x
ist. Liefert "Succ(x)" in Ada dann wirklich y? Das kann ich
irgendwie nicht glauben. Insbesondere dann nicht, falls jemand
das Äquivalent zu
enum { x=1, y=1, z=2 };
("for y use 1" oder so?) schreibt.
>>bei den "+1/-1"-Geschichten
>>allerdings doch. Offenbar einfach Gewöhnungssache, obwohl ich
>>Pascal bereits doppelt so lange wie C(++) mache.
> Ehrlich gesagt muss ich einfach selten mit halben Arrays rechnen. Und
> dort, wo mich Start- und End-Index anders interessieren als fuer die
> Bereichsangabe, schaffe ich das auch.
Naja, man braucht es halt für String-Operationen. Oder
Speicher-Allokatoren. Etc.
>>Ich leite hier aber auch ein paar C-Praktika, und meine
>>Praktikanten machen da durchaus Fehler. Auch, wenn ich als
>>"Kochrezept" nur die Schleife mit "<" angegeben habe, sehe ich
>>immer wieder mal "<=".
> Sind sie vorher zufaellig mit M0 versaut worden?
Nein. Aber viel zu viele der Anwesenden scheinen in der
Vorlesung nur körperlich anwesend zu sein und programmieren dann
per "trial and error" (solange Sonderzeichen in den Editor
streuen, bis der Compiler nicht mehr schimpft. Linken? Ausführen?
Wozu?). Und wenn den Leuten dann ihr ICQ-Fenster wichtiger ist
als meine Erklärung, dann sag ich irgendwann auch mal "Pech
gehabt. Ihr müßt die Prüfung schreiben, nicht ich".
Aber es gibt zum Glück auch Leute, die tatsächlich mitdenken und
auch schöne Programme zustande bekommen.
>>> Gefaellt Dir
>>
>>> |enum {Apfel, Birne, Citrone};
>>> |int b[Citrone];
>>
>>> (oder so) etwa nicht? ;->
>>
>>Nein, denn das Feld ist eins zu klein.
> Stimmt. Klassischer Fehler.
> Und spaetestens, wenn Du dann noch das Aequivalent zu Adas aspect
> clauses angibst, wuerdest Du damit wahrscheinlich ohnehin auch
> kraeftigst auf die Schnauze fallen.
Wie groß würde das Feld "b" mit
enum Bernd { x=1, y=2984, z=39 };
Insofern ist Pascal ganz nett, weil es da diese Spielereien
schlicht nicht gibt und damit machen sie auch keine Probleme :)
>>| enum a { Apfel, Birne, Citrone, LAST };
>>| int b[LAST];
>>wäre noch möglich, dann bekomme ich aber bei einem "switch"
>>immer eine Warnung, daß ich LAST nicht behandeln würde.
> Stimmt ja, die neueste Errungenschaft, die man aus der Ada-Welt
> geklaut hat. Ausserdem muesstest Du das LAST immer mit einem passenden
> Zusatz versehen[2], da es ja keine Typen mit sich traegt...
Es fehlen halt alle möglichen Dinge, Informationen zu Typen
abzufragen. Das gipfelt in
template<class T>
bool is_polymorphic() {
static bool answer;
typeid(((answer=true, T()));
return answer;
}
Ja, das Kraut muß ziemlich stark gewesen sein, was derjenige
geraucht hat. Das ist aber die einzige Möglichkeit, zu einem
Typen "T" rauszufinden, ob er virtuelle Methode hat.
Pascal löst dieses Problem wieder mal durch weglassen :)
>>erm, nein. Mir sind Schleifen wie diese suspekt
>> for i:=a to b do ...
>>weil man die weder als "while", noch als "repeat" implementieren
>>kann, wenn man sowohl den Fall "a=MININT, b=MAXINT", als auch
>>den Fall "a=MAXINT,b=MININT" behandeln muß.
> Mmh?
> |i = a;
> |while (i <= b) do { ...; i++; }
> Uebersehe ich etwas oder was genau klappt daran nicht?
Du übersiehst, daß im Falle "b = MAXINT" die Schleife nicht
terminiert, da "MAXINT+1" entweder (a) MININT, (b) einen
Laufzeitfehler, oder (c) irgendwas anderes liefert.
Die korrekte Lösung ist
i = a;
if (i <= b) {
while (true) {
...
if (i >= b) break;
++i;
}
}
Stefan
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>
>>>template<class T> T succ(T t) { ++t; return t; }
>
>> Das klappt nicht mit enums, wenn ich aspect clauses (oder wie auch
>> immer ihr das in C++ nennt) angebe.
>
>enum Bernd { x=1, y=2984, z=39 };
Jup. Gibt's dafuer auch einen Namen?
>Da ist eh nicht ganz klar, was denn nun der "Nachfolger" von x
>ist. Liefert "Succ(x)" in Ada dann wirklich y?
Ja, weil Succ auf dem Typen definiert ist, nicht auf seiner internen
Repraesentation. Siehe auch dem Unsinn, der gleich folgen wird...
>Das kann ich
>irgendwie nicht glauben. Insbesondere dann nicht, falls jemand
>das Äquivalent zu
> enum { x=1, y=1, z=2 };
>("for y use 1" oder so?) schreibt.
Doch, genau dann, die interne Repraesentation hat nichts mit dem Typen
zu tun. Das passende 'Val gibt es aber natuerlich auch noch.
Aber spielen wir doch mal ein bisschen mit Aspect clauses herum:
|with Ada.Exceptions,
| Ada.Text_IO,
| Ada.Unchecked_Conversion;
|
|procedure t is
| type Strange is new Integer range 3 .. 5;
| for Strange'Size use 2;
|
| type Representation is new Integer range 0 .. 3;
| for Representation'Size use 2;
|
| type Just_For_Show is
| record
| s : Strange;
| r : Representation;
| end record;
|
| for Just_For_Show use
| record
| s at 0 range 0 .. 1;
| r at 0 range 2 .. 3;
| end record;
|
| x : Just_For_Show;
|
| function To_Int is new
| Ada.Unchecked_Conversion (Strange, Representation);
|
|begin
| x.s := Strange'Last;
| x.r := To_Int (x.s);
|
| Ada.Text_IO.Put ("This is number");
| Ada.Text_IO.Put (Integer'Image (Integer (x.s)));
| Ada.Text_IO.Put (" represented in");
| Ada.Text_IO.Put (Integer'Image (x.s'Size));
| Ada.Text_IO.Put_Line (" bits.");
|
| Ada.Text_IO.Put ("After unchecked conversion this looks like");
| Ada.Text_IO.Put (Integer'Image (Integer (x.r)));
| Ada.Text_IO.Put (", these are");
| Ada.Text_IO.Put (Integer'Image (x.r'Size));
| Ada.Text_IO.Put_Line (" bits, too.");
|
| -- check range constraints
| x.r := x.r + 1; -- shouldn't fail (3 is still in range)
|
| Ada.Text_IO.Put ("Still here? This is ok...");
| Ada.Text_IO.Put (Integer'Image (Integer (x.r)));
| Ada.Text_IO.Put_Line (" equals three? (It really should!)");
|
| x.s := x.s + 1; -- this should fail (6 is out of range)
| Ada.Text_IO.Put (Integer'Image (Integer (x.s)));
| Ada.Text_IO.Put ("still here? Hey, you fucked up the compiler!");
|exception
| when E : Constraint_Error =>
| Ada.Text_IO.Put_Line ("Yippie, I catched a constraint error!");
| Ada.Text_IO.Put (Ada.Exceptions.Exception_Information (E));
| Ada.Text_IO.Put_Line ("I hope it is the right one...");
|end t;
Ausgabe des ganzen:
|This is number 5 represented in 2 bits.
|After unchecked conversion this looks like 2, these are 2 bits, too.
|Still here? This is ok... 3 equals three? (It really should!)
|Yippie, I catched a constraint error!
|Exception name: CONSTRAINT_ERROR
|Message: t.adb:52 range check failed
|I hope it is the right one...
Sieht fuer meine Begriffe richtig aus. Ja gut, Pascal ist das
natuerlich auch nicht mehr, aber es ist naeher dran als C++.
>> Ehrlich gesagt muss ich einfach selten mit halben Arrays rechnen. Und
>> dort, wo mich Start- und End-Index anders interessieren als fuer die
>> Bereichsangabe, schaffe ich das auch.
>
>Naja, man braucht es halt für String-Operationen. Oder
>Speicher-Allokatoren. Etc.
Bah. Alles Zeugs, womit ich mich selten rumschlagen muss. :)
>Nein. Aber viel zu viele der Anwesenden scheinen in der
>Vorlesung nur körperlich anwesend zu sein und programmieren dann
>per "trial and error" (solange Sonderzeichen in den Editor
>streuen, bis der Compiler nicht mehr schimpft.
So funktioniert ein grosser Teil der C-Programmierer, die ich kenne.
"Warning: implicit cast from int to void*" (oder aehnliches)? Na dann
machen wir halt ein int*, damit der Compiler zufrieden ist. BTST.
Und ich frage mich tatsaechlich, wie man das schafft, dass da
ueberhaupt noch etwas Brauchbares herauskommt.
>Linken? Ausführen? Wozu?).
"Don't give the coder a compiler." -- Rod Chapman
Naja, gut, SPARK halt. Was klaglos durch den Examiner geht, kann
eigentlich nur noch richtig sein. ;-)
*Das* ist Hardcore. Guter Hardcore.
>Aber es gibt zum Glück auch Leute, die tatsächlich mitdenken und
>auch schöne Programme zustande bekommen.
Die Hoffnung, solche Leute persoenlich zu treffen, habe ich
mittlerweile aufgegeben. Hier arbeiten eh fast nur Physiker und die
haben offensichtlich eine ganz andere Beziehung zu C.
Obwohl, einem wuerde ich es zutrauen. Der war hier Lehrling und den
hab' ich mir passend erzogen. ;)
>> Und spaetestens, wenn Du dann noch das Aequivalent zu Adas aspect
>> clauses angibst, wuerdest Du damit wahrscheinlich ohnehin auch
>> kraeftigst auf die Schnauze fallen.
>
>Wie groß würde das Feld "b" mit
> enum Bernd { x=1, y=2984, z=39 };
Das haette ich Dich gefragt. Ich schaetze mal, das Aequivalent waere
b[40]. Deswegen sagte ich, Du faellst damit wahrscheinlich auf die
Schnauze.
>Insofern ist Pascal ganz nett, weil es da diese Spielereien
>schlicht nicht gibt und damit machen sie auch keine Probleme :)
Naja, Free-Pascal kann das wohl (oder soll es koennen, wenn ich mich
an ein paar Nachrichten von der Mailingliste recht entsinne). Hoffen
wir, dass das dann genauso problemlos wie in Ada funktioniert. :-)
>Es fehlen halt alle möglichen Dinge, Informationen zu Typen
>abzufragen. Das gipfelt in
> template<class T>
> bool is_polymorphic() {
> static bool answer;
> typeid(((answer=true, T()));
> return answer;
> }
>Ja, das Kraut muß ziemlich stark gewesen sein, was derjenige
>geraucht hat. Das ist aber die einzige Möglichkeit, zu einem
>Typen "T" rauszufinden, ob er virtuelle Methode hat.
>
>Pascal löst dieses Problem wieder mal durch weglassen :)
Mmh. Wofuer braucht man das eigentlich? Mir entzieht sich auf den
ersten Blick der Sinn der Frage zur Laufzeit, ob ein Objekt virtuelle
Methoden hat. Die Typisierung ist ja ohnehin statisch, also kann man
zur Laufzeit sowieso nicht einfach mal ein paar Methoden
ueberschreiben. Wozu also?
>> |i = a;
>> |while (i <= b) do { ...; i++; }
>
>> Uebersehe ich etwas oder was genau klappt daran nicht?
>
>Du übersiehst, daß im Falle "b = MAXINT" die Schleife nicht
>terminiert, da "MAXINT+1" entweder (a) MININT, (b) einen
>Laufzeitfehler, oder (c) irgendwas anderes liefert.
Hmm ja, dann habe ich Dich falsch verstanden. Du bezogst Dich hier
eher auf Endlosschleifen a la:
|for (char c = 0; c < 256; c++) {...};
(wenn CHAR_BIT == 8, selbstredend)?
>Die korrekte Lösung ist
> i = a;
> if (i <= b) {
> while (true) {
> ...
> if (i >= b) break;
> ++i;
> }
> }
*wuerg*
Vinzent.
Stefan Reuther
Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>>>template<class T> T succ(T t) { ++t; return t; }
>>
>>> Das klappt nicht mit enums, wenn ich aspect clauses (oder wie auch
>>> immer ihr das in C++ nennt) angebe.
>>
>>enum Bernd { x=1, y=2984, z=39 };
> Jup. Gibt's dafuer auch einen Namen?
Scheint nicht so.
3.9.2p1:
# Compound types can be constructed in the following ways: [...]
# -- enumerations, which comprise a set of named constant
# values. Each distinct enumeration constitutes a
# different enumerated type, 7.2;
7.2p1:
# An enumerator-definition with = gives the associated enumerator
# the value indicated by the constant-expression.
Wozu auch ein Name? Wir wollen programmieren, und nicht Buzzword
Bingo spielen :-)
>>Da ist eh nicht ganz klar, was denn nun der "Nachfolger" von x
>>ist. Liefert "Succ(x)" in Ada dann wirklich y?
> Ja, weil Succ auf dem Typen definiert ist, nicht auf seiner internen
> Repraesentation. Siehe auch dem Unsinn, der gleich folgen wird...
Meinetwegen. In C++ ist ein Aufzählungstyp ein typisierter
Integer. Rechnen kannst du mit den Dingern nicht, nur casten,
und da ein Integertyp zugrunde liegt, ist das sogar
wohldefiniert. Das ist dann quasi "poor man's subrange-Typ".
>>Das kann ich
>>irgendwie nicht glauben. Insbesondere dann nicht, falls jemand
>>das Äquivalent zu
>> enum { x=1, y=1, z=2 };
>>("for y use 1" oder so?) schreibt.
> Doch, genau dann, die interne Repraesentation hat nichts mit dem Typen
> zu tun.
Huch? Wenn "x" und "y" gleich repräsentiert werden, wie kann
Succ sie dann auseinanderhalten?
> |procedure t is
> | type Strange is new Integer range 3 .. 5;
> | for Strange'Size use 2;
[Schnipp]
Damit hast du nur demonstriert, daß es in Ada Unterbereichs-
Typen gibt, und daß deren Bereichsgrenzen durchgesetzt werden.
Wie in Pascal.
>>> Ehrlich gesagt muss ich einfach selten mit halben Arrays rechnen. Und
>>> dort, wo mich Start- und End-Index anders interessieren als fuer die
>>> Bereichsangabe, schaffe ich das auch.
>>
>>Naja, man braucht es halt für String-Operationen. Oder
>>Speicher-Allokatoren. Etc.
> Bah. Alles Zeugs, womit ich mich selten rumschlagen muss. :)
Naja, ein Linker braucht einen Allokator für Speicher in der
".exe-Datei" des Programms. Ein Compiler braucht einen Allokator
für lokale Variablen im Stackrahmen einer Funktion. Ein Grafik-
Programm muß vielleicht Texturspeicher der Grafikkarte
verwalten. Es kommt also durchaus vor.
>>Nein. Aber viel zu viele der Anwesenden scheinen in der
>>Vorlesung nur körperlich anwesend zu sein und programmieren dann
>>per "trial and error" (solange Sonderzeichen in den Editor
>>streuen, bis der Compiler nicht mehr schimpft.
> So funktioniert ein grosser Teil der C-Programmierer, die ich kenne.
Ja :-( Aber "A tool in the hand of a fool is still a tool".
> Naja, gut, SPARK halt. Was klaglos durch den Examiner geht, kann
> eigentlich nur noch richtig sein. ;-)
> *Das* ist Hardcore. Guter Hardcore.
<http://os.inf.tu-dresden.de/vfiasco/>
Wir bauen hier gerade "sowas wie SPARK" für C++. *Das* ist
Hardcore.
>>> Und spaetestens, wenn Du dann noch das Aequivalent zu Adas aspect
>>> clauses angibst, wuerdest Du damit wahrscheinlich ohnehin auch
>>> kraeftigst auf die Schnauze fallen.
>>
>>Wie groß würde das Feld "b" mit
>> enum Bernd { x=1, y=2984, z=39 };
> Das haette ich Dich gefragt. Ich schaetze mal, das Aequivalent waere
> b[40]. Deswegen sagte ich, Du faellst damit wahrscheinlich auf die
> Schnauze.
In C++ gibt es kein "int b[Bernd]". Was würde Ada draus machen?
Drei Elemente? 2984 Elemente aber nur 3 davon zugreifbar?
>>Es fehlen halt alle möglichen Dinge, Informationen zu Typen
>>abzufragen. Das gipfelt in
>> template<class T>
>> bool is_polymorphic() {
>> static bool answer;
>> typeid(((answer=true, T()));
>> return answer;
>> }
>>Ja, das Kraut muß ziemlich stark gewesen sein, was derjenige
>>geraucht hat. Das ist aber die einzige Möglichkeit, zu einem
>>Typen "T" rauszufinden, ob er virtuelle Methode hat.
>>
>>Pascal löst dieses Problem wieder mal durch weglassen :)
> Mmh. Wofuer braucht man das eigentlich? Mir entzieht sich auf den
> ersten Blick der Sinn der Frage zur Laufzeit, ob ein Objekt virtuelle
> Methoden hat. Die Typisierung ist ja ohnehin statisch, also kann man
> zur Laufzeit sowieso nicht einfach mal ein paar Methoden
> ueberschreiben. Wozu also?
Eigentlich will man es zur Compilezeit wissen, um diese Funktion
implementieren zu können:
template<class T>
void* beginning_of_storage(T* t) {
if (is_polymorphic<T>())
return dynamic_cast<void*>(t);
else
return static_cast<void*>(t);
}
Diese Funktion liefert zu einem Objekt "t" die Speicheradresse,
sozusagen ein eindeutiges Handle. Das ist für allerlei nette
Sachen nützlich, nicht zuletzt z.B. Garbage Collection. Die Norm
sagt halt, daß man um die Speicheradresse zu erhalten bei
polymorphen Typen "dynamic_cast" und bei nichtpolymorphen Typen
"static_cast" zu verwenden. Leider gibt mir C++ nicht die
nötigen Mittel in die Hand, herauszufinden, was "T" denn nun ist.
Pascal löst das mal wieder durch Weglassen. Ada IIRC auch (oder
gibt's da neuerdings Klassen mit virtuellen Methoden und
Mehrfachvererbung?). Wenn man keine Mehrfachvererbung hat,
braucht man solche Spielchen ja nicht.
[for i:=a to b do ...]
>>Die korrekte Lösung ist
>> i = a;
>> if (i <= b) {
>> while (true) {
>> ...
>> if (i >= b) break;
>> ++i;
>> }
>> }
> *wuerg*
Siehst du, was für häßlichen Code der Compiler aus deiner
schönen FOR-Schleife macht? :-)
Stefan
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>
>Wozu auch ein Name? Wir wollen programmieren, und nicht Buzzword
>Bingo spielen :-)
Um zu wissen, worueber man redet.
>>>Da ist eh nicht ganz klar, was denn nun der "Nachfolger" von x
>>>ist. Liefert "Succ(x)" in Ada dann wirklich y?
>
>> Ja, weil Succ auf dem Typen definiert ist, nicht auf seiner internen
>> Repraesentation. Siehe auch dem Unsinn, der gleich folgen wird...
>
>Meinetwegen. In C++ ist ein Aufzählungstyp ein typisierter
>Integer. Rechnen kannst du mit den Dingern nicht,
Wenn das so ist, dann ist das nur in C++ so.
>wohldefiniert. Das ist dann quasi "poor man's subrange-Typ".
Klar, es ist halt nur doof, damit Subrange-Typen a la
|type
| Ratemultiplier = 0 .. 16777215;
definieren zu wollen:
|enum {
| rmZero, rmOne, rmTwo, rmThree, rmFour, ...,
| rmSixteenmillionsevenhundredseventyseventhousandtwohundredfifteen
|}
;->
>>>Das kann ich
>>>irgendwie nicht glauben. Insbesondere dann nicht, falls jemand
>>>das Äquivalent zu
>>> enum { x=1, y=1, z=2 };
>>>("for y use 1" oder so?) schreibt.
>
>> Doch, genau dann, die interne Repraesentation hat nichts mit dem Typen
>> zu tun.
>
>Huch? Wenn "x" und "y" gleich repräsentiert werden,
*oops* Uebersehen. Wer macht denn auch so einen Unsinn? ;)
>wie kann Succ sie dann auseinanderhalten?
Mmh. Mal sehen:
|t.adb:14:41: enumeration value for "Second_One" not ordered
Gar nicht. Die Repraesentation ist nicht erlaubt. Notfalls sollte
renaming helfen.
>> |procedure t is
>> | type Strange is new Integer range 3 .. 5;
>> | for Strange'Size use 2;
>[Schnipp]
>
>Damit hast du nur demonstriert, daß es in Ada Unterbereichs-
>Typen gibt,
Nein. Damit habe ich repraesentiert, dass auch die Zahlen 3 bis 5 in
zwei Bits dargestellt werden koennen. Sonst wuerde nach der
Konvertierung nicht das Ergebnis herauskommen, was herausgekommen ist.
>und daß deren Bereichsgrenzen durchgesetzt werden.
Das war ein allerdings ein nettes Zusatzfeature. Bot sich gerade an,
schliesslich war die Bitkombination "11" auf dem ersten Typen nicht
erlaubt.
>>>Naja, man braucht es halt für String-Operationen. Oder
>>>Speicher-Allokatoren. Etc.
>
>> Bah. Alles Zeugs, womit ich mich selten rumschlagen muss. :)
>
>Naja, ein Linker braucht einen Allokator für Speicher in der
>".exe-Datei" des Programms. Ein Compiler braucht einen Allokator
>für lokale Variablen im Stackrahmen einer Funktion. Ein Grafik-
>Programm muß vielleicht Texturspeicher der Grafikkarte
>verwalten. Es kommt also durchaus vor.
Sicher. Aber selten. Und dort kann ich auch gut mit geschlossenen
Intervallen arbeiten. ;)
>>>Nein. Aber viel zu viele der Anwesenden scheinen in der
>>>Vorlesung nur körperlich anwesend zu sein und programmieren dann
>>>per "trial and error" (solange Sonderzeichen in den Editor
>>>streuen, bis der Compiler nicht mehr schimpft.
>
>> So funktioniert ein grosser Teil der C-Programmierer, die ich kenne.
>
>Ja :-( Aber "A tool in the hand of a fool is still a tool".
Durchaus richtig.
><http://os.inf.tu-dresden.de/vfiasco/>
>
>Wir bauen hier gerade "sowas wie SPARK" für C++. *Das* ist
>Hardcore.
Glaub ich Dir. Praxis Critical Systems hat das wohl mal fuer ein
Subset von C versucht und aufgegeben. Und die Guidelines von MISRA-C
sind in dieser Hinsicht auch nicht das Gelbe vom Ei.
Fragt sich nur, warum ihr nicht einfach eine hoehere
Programmiersprache benutzt... ;->
>>>Wie groß würde das Feld "b" mit
>>> enum Bernd { x=1, y=2984, z=39 };
>
>> Das haette ich Dich gefragt. Ich schaetze mal, das Aequivalent waere
>> b[40]. Deswegen sagte ich, Du faellst damit wahrscheinlich auf die
>> Schnauze.
>
>In C++ gibt es kein "int b[Bernd]".
Du muesstest dann schon int b[z + 1] schreiben. --- Ja. Eben. Boese
Falle.
>Was würde Ada draus machen?
Mmh... schauen wir mal:
|with Ada.Text_IO;
|
|procedure t is
| type Hole_Enum is (One, Two, Three);
| for Hole_Enum use (One => 1, Two => 39, Three => 2984);
|
| type Hole_Array is array (Hole_Enum) of Integer;
|
| h : Hole_Array;
|
|begin
| h := Hole_Array'(1, 2, 3);
| Ada.Text_IO.Put_Line (Integer'Image (h'Size));
|end t;
Ausgabe:
|96
>Drei Elemente? 2984 Elemente aber nur 3 davon zugreifbar?
In diesem Fall also drei Elemente. Wobei das nun allerdings
compilerspezifisch ist und evt. auch von Array-Groesse u.ae. abhaengig
sein mag. Die interne Repraesentation interessiert mich vordergruendig
aber natuerlich nicht.
>>>Es fehlen halt alle möglichen Dinge, Informationen zu Typen
>>>abzufragen. Das gipfelt in
>>> template<class T>
>>> bool is_polymorphic() {
[...]
>Die Norm
>sagt halt, daß man um die Speicheradresse zu erhalten bei
>polymorphen Typen "dynamic_cast" und bei nichtpolymorphen Typen
>"static_cast" zu verwenden. Leider gibt mir C++ nicht die
>nötigen Mittel in die Hand, herauszufinden, was "T" denn nun ist.
Muss ja ein Klasse-Standard sein, der Wissen ueber Dinge verlangt, die
ich nicht wissen kann.
>Pascal löst das mal wieder durch Weglassen. Ada IIRC auch (oder
>gibt's da neuerdings Klassen mit virtuellen Methoden
Ja.
>und Mehrfachvererbung?).
Nein.
Das ist ohnehin ziemlich umstritten, man loest das anders. Stichwort
"A contains B" und "A is of (class) B".
>[for i:=a to b do ...]
>>>Die korrekte Lösung ist
>>> i = a;
>>> if (i <= b) {
>>> while (true) {
>>> ...
>>> if (i >= b) break;
>>> ++i;
>>> }
>>> }
>
>> *wuerg*
>
>Siehst du, was für häßlichen Code der Compiler aus deiner
>schönen FOR-Schleife macht? :-)
Dafuer ist der Compiler ja schliesslich da. :) Ich ziehe mir gerade
Compilerbau Teil 2 rein, da wimmelt es nur so von gotos...
Franz Glaser (NLx300)
>
> |function "+" (Left, Right : Integer) return Integer is
> |begin
> | return (Standard."*" (Left, Right));
> |end "+";
>
> *Ich* wuerde *das* als Vergewaltigung des "+" Operators auffassen.
> Oder sollte ich aus der Namensgleichheit nichts schliessen duerfen?
... habe nun ... ach ;-)))
da kann ich dir nur FORTH empfehlen, _meine_ Leib- und Seelen-
Sprache.
Weißt schon, die mit dem Doppelpunkt am Beginn und dem Semicolon
am Ende. Da läßt du alles andere liegen und stehen.
MfG
--
Franz Glaser MEG Glasau 3 A-4191 Vorderweissenbach
http://www.meg-glaser.com +43-7219-7035-0 Fax: -4
Markus Humm
> Stefan Reuther schrieb im Artikel <1052483457.irz750%sr...@inf.tu-dresden.de>:
>
>>Workaround 2:
>> function wuerfel : integer;
>> var tmp : integer;
>> begin
>> repeat
>> tmp := Trunc(6*Random) + 1;
>> until tmp<>7;
>> wuerfel := tmp;
>> end;
>>funktioniert, ist auch gleichverteilt, macht dir aber alle
>>schönen Eigenschaften, die du sonst noch haben könntest, kaputt
>>(konstante Laufzeit, Weitersetzen des "seed" um N Schritte ohne
>>die Zufallszahlen direkt abzufragen, ...).
>
>
> <troll>
> Ist denn sicher, dass das terminiert?
> </troll>
Genaugenommen nicht, aber was auf dieser Welt ist schon sicher?
Markus Humm
> Ja. Eine Menge, die alle Elemente enthält, die ">=5" und "<=4"
> sind, ist eine leere Menge. Dennoch finde ich das etwas
> kontra-intuitiv ("bring bitte fünf oder mehr, aber vier oder
> weniger Brötchen mit").
Erkläre das mal einem KIler. Der hantiert nämlich u.U. mit sowas... ;-)
=> für den kann's sowas schon geben, der kann dir das dann sogar
grafisch darstellen :-)
Kann dich bei Bedarf ja gerne an jemanden verweisen...(Dozent)
Gruß
Markusb Humm
Horst Kraemer
<JeLlyFish...@gmx.net> wrote:
Aus derartigen Vergleichen koennte man auf eine gewisse verbohrte
Voreingenommenheit schliessen. Es besteht wohl ein kleiner Unterschied
zwischen der Bedeutung eines seit Jahrhunderten eingefuehrten
mathematischen Symbols und dem Schluesselwort einiger
Programmiersprachen - insbesondere deswegen, weil man das C-for im
Gegensatz zu Deinem '+' auch so verwenden kann wie das for dieser
anderen Sprachen.
MfG
Horst
Franz Glaser (NLx300)
>>
>>*Ich* wuerde *das* als Vergewaltigung des "+" Operators auffassen.
>>Oder sollte ich aus der Namensgleichheit nichts schliessen duerfen?
>
> Aus derartigen Vergleichen koennte man auf eine gewisse verbohrte
> Voreingenommenheit schliessen. Es besteht wohl ein kleiner Unterschied
> zwischen der Bedeutung eines seit Jahrhunderten eingefuehrten
> mathematischen Symbols und dem Schluesselwort einiger
> Programmiersprachen - insbesondere deswegen, weil man das C-for im
> Gegensatz zu Deinem '+' auch so verwenden kann wie das for dieser
> anderen Sprachen.
Deswegen habe ich mir ('tschuldigung :-) auch den Hinweis auf das
umgekehrt polnische FORTH erlaubt, in welchem es überhaupt keine
Hierarchien mehr gibt, keine Schlüsselwörter und keine Bedeutungen.
Nur mehr commands, in FORTH schlicht sogar wertfrei (!) "word"
genannt.
Da ist das + genau so viel wert wie das IF und das BEGIN und LOOP
und eine Zahl. Klammern gibt's nur zum Kennzeichnen von Kommentaren.
Selbst eine Zahl bedeutet nur den command: lege die Zahl nnn auf den
Stack! Sonst nix.
Stefan Reuther
>>Wozu auch ein Name? Wir wollen programmieren, und nicht Buzzword
>>Bingo spielen :-)
> Um zu wissen, worueber man redet.
Naja, das ist die normalste Sache der Welt, daß ein enum einen
Initialisierer hat. Deswegen heißt das auch nur "enum mit
Initialisierer".
>>>>Da ist eh nicht ganz klar, was denn nun der "Nachfolger" von x
>>>>ist. Liefert "Succ(x)" in Ada dann wirklich y?
>>
>>> Ja, weil Succ auf dem Typen definiert ist, nicht auf seiner internen
>>> Repraesentation. Siehe auch dem Unsinn, der gleich folgen wird...
>>
>>Meinetwegen. In C++ ist ein Aufzählungstyp ein typisierter
>>Integer. Rechnen kannst du mit den Dingern nicht,
> Wenn das so ist, dann ist das nur in C++ so.
Du kannst Werte eines Aufzählungstypes addieren, das wird dann
implizit in einen passenden Ganzzahltyp konvertiert. Die Rück-
Konversion in den Aufzählungstyp macht nur C automatisch, C++
nicht.
>>wohldefiniert. Das ist dann quasi "poor man's subrange-Typ".
> Klar, es ist halt nur doof, damit Subrange-Typen a la
> |type
> | Ratemultiplier = 0 .. 16777215;
> definieren zu wollen:
> |enum {
> | rmZero, rmOne, rmTwo, rmThree, rmFour, ...,
> | rmSixteenmillionsevenhundredseventyseventhousandtwohundredfifteen
> |}
enum { rmZero, rmBlub = 16777215 };
Da dem enum immer ein ganzzahliger Typ zugrundeliegt (per
Definition), kann eine Variable dieses Types auch alle Werte
dazwischen darstellen.
C++-enum != Ada/Pascal-enum.
C++: typisierter Integer
Ada/Pascal: was anderes :-)
>>>>Das kann ich
>>>>irgendwie nicht glauben. Insbesondere dann nicht, falls jemand
>>>>das Äquivalent zu
>>>> enum { x=1, y=1, z=2 };
>>>>("for y use 1" oder so?) schreibt.
> |t.adb:14:41: enumeration value for "Second_One" not ordered
ok.
>><http://os.inf.tu-dresden.de/vfiasco/>
>>
>>Wir bauen hier gerade "sowas wie SPARK" für C++. *Das* ist
>>Hardcore.
> Glaub ich Dir. Praxis Critical Systems hat das wohl mal fuer ein
> Subset von C versucht und aufgegeben. Und die Guidelines von MISRA-C
> sind in dieser Hinsicht auch nicht das Gelbe vom Ei.
> Fragt sich nur, warum ihr nicht einfach eine hoehere
> Programmiersprache benutzt... ;->
Früher hätte man gefragt, warum wir überhaupt Mikrokerne bauen,
wo Monolithen doch so viel schneller sind. Dann, warum man Kerne
überhaupt in C++ schreibt, wo das doch so langsam ist. Nun fragt
man also, warum wir nicht Ada verwenden :-)
Selbst wenn wir Ada o.ä. verwenden würden, müßten wir das auf
einen Subset abspecken, der performant ist und trotzdem
verifizierbar. Das gleiche Problem haben wir mit C++. Oder
Pascal. Oder C. Die C-Sprachen haben aber eben eine bessere
Verbreitung bei "Kernel-Hackern". Der C++ Compiler läßt mehr
durchgehen ("int i = (int) new char[3]"), aber das kann man bei
der Verifikation ja verbieten.
>>>>Wie groß würde das Feld "b" mit
>>>> enum Bernd { x=1, y=2984, z=39 };
>>Was würde Ada draus machen?
> Mmh... schauen wir mal:
> |with Ada.Text_IO;
[..]
> |96
>>Drei Elemente? 2984 Elemente aber nur 3 davon zugreifbar?
> In diesem Fall also drei Elemente.
Horror für Compilerbauer.
Entweder:
- 2984 nicht die Repräsentation von y sein, sondern nur
der Wert, der bei 'Val oder wie auch immer das heißt
rauskommt. Ada generiert also eine Mappingtabelle. Das kann
ich notfalls aber auch selber.
- bei jedem Arrayzugriff, Succ, Pred, ... wird eine
Rücktransformation gemacht (1->0, 2948->1, 39->2).
Nonperformance pur.
> Die interne Repraesentation interessiert mich vordergruendig
> aber natuerlich nicht.
Komisch. Kontrolle über interne Repräsentation wird immer wieder
als Vorteil von Ada angeführt :-)
>>>>Es fehlen halt alle möglichen Dinge, Informationen zu Typen
>>>>abzufragen. Das gipfelt in
>>>> template<class T>
>>>> bool is_polymorphic() {
> [...]
>>Die Norm
>>sagt halt, daß man um die Speicheradresse zu erhalten bei
>>polymorphen Typen "dynamic_cast" und bei nichtpolymorphen Typen
>>"static_cast" zu verwenden. Leider gibt mir C++ nicht die
>>nötigen Mittel in die Hand, herauszufinden, was "T" denn nun ist.
> Muss ja ein Klasse-Standard sein, der Wissen ueber Dinge verlangt, die
> ich nicht wissen kann.
Natürlich kannst du die wissen. Wenn du eine polymorphe Klasse
schreibst, weißt du, daß sie polymorph ist. Du kannst diese
Information nur nicht per Programm abfragen (im Sinne wie du die
Größe mit sizeof abfragen kannst). Damit kannst du keinen
generischen Code bauen, der sowas abfragt.
Stefan
Horst Kraemer
Danke fuer die Erinnerung. Wird Zeit, mal wieder eine ballastfreie
Programmiersprache zu geniessen...
MfG
Horst
Vinzent Hoefler
>da kann ich dir nur FORTH empfehlen, _meine_ Leib- und Seelen-
>Sprache.
Ja. Sollte ich mir wahrscheinlich auch mal wieder antun. Meine letzte
Erfahrung damit datiert auf ca. 1986 auf einem KC85/3. *hach*
Vinzent.
Vinzent Hoefler
>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>[enum { foo = 9 } in C]
>>>Wozu auch ein Name? Wir wollen programmieren, und nicht Buzzword
>>>Bingo spielen :-)
>
>> Um zu wissen, worueber man redet.
>
>Naja, das ist die normalste Sache der Welt, daß ein enum einen
>Initialisierer hat.
Was ist schon normal? Gebraucht habe ich es so in der Art bisher noch
nicht, einfach deshalb, weil ich mich auf die compilerspezifische
Implementation "zaehlt ab 0" verlassen musste. Unschoen, funktioniert,
aber erfordert einen Heidenaufwand, wenn das Embedded System mal
wieder ein paar neue Funktionen verpasst bekommt und andere obsolet
werden. Kompatibel zum alten ist es dann natuerlich auch nicht mehr.
>>><http://os.inf.tu-dresden.de/vfiasco/>
>>>
>>>Wir bauen hier gerade "sowas wie SPARK" für C++. *Das* ist
>>>Hardcore.
>
>[...]
>> Fragt sich nur, warum ihr nicht einfach eine hoehere
>> Programmiersprache benutzt... ;->
>
>Früher hätte man gefragt, warum wir überhaupt Mikrokerne bauen,
>wo Monolithen doch so viel schneller sind.
Ach, ich fand Mikrokernel schon immer huebsch.
>Dann, warum man Kerne
>überhaupt in C++ schreibt, wo das doch so langsam ist.
Jaja, langsame Sprachen... Wir wissen, dass das Unsinn ist.
>Selbst wenn wir Ada o.ä. verwenden würden, müßten wir das auf
>einen Subset abspecken, der performant ist und trotzdem
>verifizierbar.
SPARK.
>Das gleiche Problem haben wir mit C++. Oder
>Pascal. Oder C.
Richtig. Und wenn man sich die Geschichte von SPARK mal anschaut,
sieht man, was daraus geworden ist. Die Ursprungsidee von SPADE war
ein Pascal-Subset.
Du kannst dazu ja mal
<http://www.sparkada.com/downloads/misracatsil4reader.pdf> lesen.
Aber Vorsicht, ist ein relativ persoenlicher Rant von Rod. :)
>Die C-Sprachen haben aber eben eine bessere
>Verbreitung bei "Kernel-Hackern". Der C++ Compiler läßt mehr
>durchgehen ("int i = (int) new char[3]"), aber das kann man bei
>der Verifikation ja verbieten.
Moeglicherweise werdet ihr am Ende viel zu viel verbieten muessen.
>>>>>Wie groß würde das Feld "b" mit
>>>>> enum Bernd { x=1, y=2984, z=39 };
>
>>>Was würde Ada draus machen?
>
>> Mmh... schauen wir mal:
>
>> |with Ada.Text_IO;
>[..]
>> |96
>
>>>Drei Elemente? 2984 Elemente aber nur 3 davon zugreifbar?
>
>> In diesem Fall also drei Elemente.
>
>Horror für Compilerbauer.
:-)
>Entweder:
>- 2984 nicht die Repräsentation von y sein, sondern nur
> der Wert, der bei 'Val oder wie auch immer das heißt
> rauskommt. Ada generiert also eine Mappingtabelle. Das kann
> ich notfalls aber auch selber.
Man kann notfalls alles selber machen, was Dir in diversen Sprachen
der Compiler abnehmen koennte. IIRC, nennt man das dann "in Assembler
programmieren". Und selbst das ist in dieser Richtung noch nicht
absolut sauber (Sprungoptimierung, symbolische Namen fuer
Speicheradressen, etc. pp.).
>> Die interne Repraesentation interessiert mich vordergruendig
>> aber natuerlich nicht.
>
>Komisch. Kontrolle über interne Repräsentation wird immer wieder
>als Vorteil von Ada angeführt :-)
Ja. Wenn ich es brauche. Und der Vorteil liegt vor allem darin, dass
eine Aenderung der internen Repraesentation nichts am Code aendert.
>>>Die Norm
>>>sagt halt, daß man um die Speicheradresse zu erhalten bei
>>>polymorphen Typen "dynamic_cast" und bei nichtpolymorphen Typen
>>>"static_cast" zu verwenden. Leider gibt mir C++ nicht die
>>>nötigen Mittel in die Hand, herauszufinden, was "T" denn nun ist.
>
>> Muss ja ein Klasse-Standard sein, der Wissen ueber Dinge verlangt, die
>> ich nicht wissen kann.
>
>Natürlich kannst du die wissen. Wenn du eine polymorphe Klasse
>schreibst, weißt du, daß sie polymorph ist.
Unter dieser Nebenbedingung.
>Du kannst diese
>Information nur nicht per Programm abfragen (im Sinne wie du die
>Größe mit sizeof abfragen kannst). Damit kannst du keinen
>generischen Code bauen, der sowas abfragt.
Das aendert jetzt aber nichts an meiner Aussage, oder?
Vinzent Hoefler
>Aus derartigen Vergleichen koennte man auf eine gewisse verbohrte
>Voreingenommenheit schliessen.
Ja. :)
Aber so schlimm ist es nicht. Letzte Woche habe ich mich das erste Mal
in meiner Programmiererkarriere sogar zu einem goto hinreissen lassen.
Markus Humm
>>*Ich* wuerde *das* als Vergewaltigung des "+" Operators auffassen.
>>Oder sollte ich aus der Namensgleichheit nichts schliessen duerfen?
>
>
> Aus derartigen Vergleichen koennte man auf eine gewisse verbohrte
> Voreingenommenheit schliessen. Es besteht wohl ein kleiner Unterschied
> zwischen der Bedeutung eines seit Jahrhunderten eingefuehrten
> mathematischen Symbols und dem Schluesselwort einiger
> Programmiersprachen - insbesondere deswegen, weil man das C-for im
> Gegensatz zu Deinem '+' auch so verwenden kann wie das for dieser
> anderen Sprachen.
Hm, ich halte Überladen für ein eher überflüssiges feature, da die
meisten Programmiersprachen sowieso so wenige Symbole und
Schlüsselwörter haben, das einem PROBLEMLOS auch ein anderes Wort als
Bezeichner einfallen dürfte. Oder sind da manche Leute etwas bequem?
Es führt jedenfalls nicht zu besser wartbarem/lesbarem Code, da der
Normalleser nicht annimt, das z.B. + oder FOR in dem speziellen programm
plötzlich eine andere bedeutung hat, als er es in der verwendeten
Programmiersprache erwarten würde...
=> dient sicherlich der verwirrung, v.a. wenn öfters im selben Programm
benutzt. Man kann sich halt nicht so viel im Kurzzeitgedächtnis behalten.
Mfg.
Markus Humm
Franz Glaser (NLx300)
> Horst Kraemer wrote:
>
>>Aus derartigen Vergleichen koennte man auf eine gewisse verbohrte
>>Voreingenommenheit schliessen.
>
> Ja. :)
>
> Aber so schlimm ist es nicht. Letzte Woche habe ich mich das erste Mal
> in meiner Programmiererkarriere sogar zu einem goto hinreissen lassen.
Ich werde das der Ratzingerkongregation melden.
Du weißt schon, das ist die Nachfolgefirma von der Inquisition.
Inzwischen sammle ich das Holz für den Scheiterhaufen.
Sieghard Schicktanz
Du schriebst am Mon, 12 May 2003 13:47:01 +0000 (UTC):
> >>Außer, daß die Pascal/Ada-Schleife für den Compilerbauer
> >>schwieriger zu implementieren ist.
Sorry für die Einmischung - aber ich verstehe hier partout nicht, was an der
_einfachen_ Algol-Pascal-Ada-Zählschleife _kompliziert_ sein sollte?
Dafür haben viele Prozessoren direkt geeignete Befehle, in der Art
"(De|In)kremtiere und springe, wenn nicht (0|gleich anderem (Register|..))"
Und wenn nicht, dann gibt's praktisch ("bei allen nichttrivialen
Prozessoren";) sowohl "(In|De)krement" als auch ein "Springe bei gleich" und
"Springe bei (kleiner|größer)". Alles in allem genügend Zutaten, um die
Vorbereitung (ex Speicheransprache;) auf einen Aufwand von nicht mehr als
einem halben Dutzend Befehlen kommen zu lassen.
> > egal, wie schwierig das fuer den Compilerbauer ist.
>
> Mir ist das nicht egal. Erstens: ich bin Compilerbauer :-)
Und kennst solche Möglichkeiten nicht? =:-O
> Zweitens: der Code, den zumindest Turbo Pascal dafür erzeugt,
> ist alles andere als optimal, da eine Menge Sprünge drin sind.
Turbo Pascal erzeugt nach einhelliger Meinung aller Programmierer egal
welcher Provinienz (wenigstens soweit sie das überhaupt kennen) einen
deutlich _sub_optimalen Code. (BTW: Borland Pascal und Delphi sind besser;)
> Wie wir aus dclax wissen, sind Sprünge teuer.
^^^^^
Was'n das?
Naja, Sprünge teuer. Wie sonst implementierst Du dann eine
Bedingungsbearbeitung? Flag setzen, wenn ein nicht zu bearbeitender Pfad
beginnt, diesen "unsichtbar" abarbeiten und Flag an passender Stelle wieder
rücksetzen?
Schaut mir eher _noch_ teurer aus, obwohl's sowas angeblich geben soll...
> >>> Intervall 1: Low (x) to High (x) div 2
> >>> Intervall 2: High (x) div 2 + 1 to High (x)
> >> ^^^
> >>> In C drueckst Du das doch prinzipiell auch nicht anders aus.
> >>
> >>Doch, ich spare mir das blöde "+1" Rumgerechne.
Nicht, wenn Du das "anständig" schreibst, mit den passenden Operatoren:
vvvv
Intervall 2: succ (High (x) div 2) to High (x)
Außerdem: das schreibst Du doch eh nur _einmal_ in der Bearbeitungsprozedur,
dann stimmt das für alle Aufrufe.
> > Lediglich, weil Du ein < statt eines <= verwendest, oder?
>
> Ja. Weil ich (in C(++)) "<" verwenden kann; in Pascal muß ich
> "<=" verwenden oder manuell mit "while" rummachen.
Und? Was ist so schlimm an "<="? Du mußt so oder so wissen, was das
impliziert - mit oder ohne Vergleichswert...
> Disclaimer: ich bin nicht der Meinung, daß C/C++ die Rundum-
> Wohlfühl-Sprache ist. Pascal aber auch nicht.
Ok, darauf könnte man sich einigen. Welche isses denn? <;^)
> Und die C/C++
> for-Schleife ist einfach genial :-)
Die "for"-Schleife von C(pp) ist _die_ Vergewaltigung eines Konzepts
schlechthin. Da ist nur ein unpassender Name für ein vollkommen anderes
Konzept mißbraucht worden.
Ob ein allgemeiner Iterator*) im Grundumfang einer Programmiersprache
implementiert werden sollte, wäre sicher zu überlegen. Ihn mit dem
allgemeingebräuchlichen Namen für eine einfache sequentielle Zählschleife zu
belegen, ist sicher keine gute Idee. (gewesen.) (Jetzt gilt: Zuu späät..)
> Ich finde halt halboffene Intervalle schöner *schulterzuck*
Da hat ja auch niemand was dagegen - Deine persönliche Meinung ist durchaus
in Ordnung. Du solltest halt auch ein paar andere daneben bestehen lassen...
<;^)
*) Um mal so'ne Fußnote anzubringen:
Das "for"-Konstrukt von C ist eine sogar gegenüber "WHILE" und "REPEAT"
verallgemeinerte Schleifenkonstruktion und hat rein garnichts mit (Auf-)
Zählen zu tun. Sie ließe sich etwa beschreiben als:
_Anfangszustand_ herstellen
Solange die _Arbeitsbedingung_ erfüllt ist,
_Schleifenausdruck_ abarbeiten,
dann _Fortschaltausdruck_ bearbeiten.
Dabei kann jeder Teil des Ausdrucks (in "_" gesetzt) auch leer sein.
Es soll sogar ganze C-Programme geben, die aus einer einzigen "for"-Schleife
bestehen...
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet)
--
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
- acht zwei fuenf vier sieben Achmuehle / Eurasburg
mailto:Sieg...@Schicktanz.schs.de
-----------------------------------------------------------
Sieghard Schicktanz
Du schriebst am Mon, 12 May 2003 15:25:52 +0000 (UTC):
> > Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
> > des Konzepts der "for"-Schleife.
>
> Es ist halt eine Schleife zur Iteration über beliebige Mengen.
> Das können Integer-Bereiche sein, aber eben auch Listen, und
> vieles mehr.
Eben, fast jedenfalls - es müssen _geordnete_ Mengen sein, die in einer
vorgegebenen _Reihenfolge_ bearbeitet werden können.
Ungeordnete Mengen gehen (gingen) nicht (wenn man diese in der inhärent
linearen Darstellungsweise eines Adressraums überhaupt ausdrücken könnte).
...
> In Schleifen habe ich in Pascal *ausschließlich* geschlossene
> Intervalle ("for i:=a to b"), in Arrays auch (array[a..b]). In
Falsch. In _Zähl_schleifen - ja. Die anderen Schleifenkonstrukte kannst Du
sowahl in Pascal als auch in C (und fast allen anderen Programmiersprachen)
beliebig halten, die sind praktisch vollkommen äquivalent (soweit
vorhanden).
> der C-Ecke habe ich für Felder nur halboffene Intervalle, aber
> für Schleifen kann ich mir's raussuchen ("for (i=a; i<b; ++i)"
> und "for (i=a; i<=b; ++i)").
C-"for" golt nicht, da andere Baustelle!
> Wenn du eine Pascal-For-Schleife kennst, die durch ein
> halboffenes Intervall rennt, immer her damit, kann ich gut
Wie wär's mit
FOR i:= Anfang TO pred (Weiter) DO ...
oder ^^^^^^^
FOR i:= Decke DOWNTO succ (Fußboden) DO ...
? ^^^^^^^^^^^
BTW: Geht mit beliebigen ordinalen Typen...
Sieghard Schicktanz
Du schriebst am Sat, 10 May 2003 08:45:28 +0200:
> >>> Nur so lassen sich wirklich gleichverteilte Zufallszahlen
> >>> erzeugen.
> >>
> >> Glaube ich Dir nicht. :-)
Ihr habt beide recht.
Lediglich die Tatsache, daß die IEEE einen Standard für die Darstellung von
Gleitkommazahlen entwickelt und veröffentlicht hat, hat zur Folge, daß alle
üblichen Zufallszahlengeneratoren von Computern den oberen Grenzwert _nicht_
ausgeben. Der einfache Grund ist der, daß sie ihn nicht erreichen können.
Eine Gleitkommazahl in IEEE-Darstellung besteht aus einem Exponenten mit
einer bestimmten Anzahl von Bits, der im Intervall von 0..1 0 ist, einer
_impliziten_, d.h. nicht gespeicherten, 1 vor dem Binärkomma und einer
bestimmten Anzahl von Bits hinter diesem (der Mantisse). Eine Ausnahme
bildet die exakte 0.0, die durch Darstellung mit Exponent _und_ Mantisse
gleich 0 definiert ist.
Um eine beliebige Gleitkommazahl im Intervall von [0, 1.0[ zu erhalten,
reicht es also, ein beliebiges Bitmuster für die Mantisse einzusetzen und
das dann als Zahl zu interpretieren.
Geeignete gleichverteilte Bitmuster liefern diverse gut bekannte
Algorithmen, und diese kann man einfach in die Implementation "einpflanzen"
- voila, ein Zufallsgenerator.
Ja, und warum denn dann erst der Umweg über die Gleitkommazahlen?
Eine direkte Erzeugung scheint doch dann viel einfacher?
Ja, _scheint_ - die Algorithmen sind leider deutlich nichttrivial auf andere
Intervalle umzustellen, so daß man am Ende für jedes einen eigenen Generator
brauchte, was implementationstechnisch etwas reichlich aufwendig wäre...
Durch den Umweg über die Gleitkommazahlen ist eine Skalierung mit minimalem
Verlust an Gleichförmigkeit der Verteilung aber trivial, und deshalb führt
der zunächst umständlich erscheinende Umweg schließlich zu einer deutlich
einfacheren und allgemeineren Implementierung.
--
Sieghard Schicktanz
Du schriebst am Sun, 11 May 2003 14:23:41 +0200:
> Horst Kraemer schrieb:
...
> >>>>Gleichverteilung ist KEINE notwendige Voraussetzung für die
> >Zufälligkeit>>>einer Folge.
> > Das ist wohl trivial. Es gibt auch noch andere Verteilungen als die
> > Gleichverteilung.
Gleichverteilung ist eher ein orthogonales Konzept zu Zufälligkeit - die
Verteilung kann i.a. umgerechnet werden, ohne die Kriterien für Zufälligkeit
zu beeinflussen.
> So trivial dann anscheinend doch nicht. Denn viele sitzen immer noch
> diesem Irrtum auf.
>
> >>>Das sollte wohl eher "keine hinreichende" heissen, oder?
> >>Nein, "keine notwendige" ist schon richtig:
Überhaupt keine. Es ist was anderes.
> >>"Der zweite Unterschied zwischen realen und ausgedachten Zufallsfolgen
> >>ist nicht
> >>ganz so auffällig. Menschen neigen dazu, innerhalb kurzer Zeit alle
> >>Ziffern gleich
...
> Nein, es ist auch ein Indiz dafür, daß Menschen Gleichverteilung als
> notwendige Voraussetzung für die Zufälligkeit einer Folge ansehen,
> obwohl es keine ist.
Es ist eher ein Indiz dafür, daß die meisten Menschen Zufälligkeit nur in
einem bestimmten Rahmen "erleben" und versuchen, diesen im Bedarfsfall
möglichst genau einzuhalten.
Dzf. ist die Behauptung in der gegebenen Allgemeinheit einfach falsch.
Jemand der sich in ständig mit einem Gebiet befasst, das z.B. laufend
normalverteilte Werte produziert, wird dazu neigen, die Normalverteilung
(nach C.F.Gauß;) nachzubilden und zu suchen. (Dazu gibt's einen Thread in
der Physik-Gruppe, allerdings unter wesentlicher Beteiligung eines
Dsikutanten mit etwas ungewöhnlichen Ansichten... (und vielen Abtriften))
Florian Kreidler
> Hallo Stefan,
>
> Du schriebst am Mon, 12 May 2003 15:25:52 +0000 (UTC):
>
>> > Nunja. Fuer mich ist das, was man daraus gemacht hat, Vergewaltigung
>> > des Konzepts der "for"-Schleife.
>>
>> Es ist halt eine Schleife zur Iteration über beliebige Mengen.
>> Das können Integer-Bereiche sein, aber eben auch Listen, und
>> vieles mehr.
>
> Eben, fast jedenfalls - es müssen _geordnete_ Mengen sein, die in einer
> vorgegebenen _Reihenfolge_ bearbeitet werden können.
> Ungeordnete Mengen gehen (gingen) nicht (wenn man diese in der inhärent
> linearen Darstellungsweise eines Adressraums überhaupt ausdrücken könnte).
Nein. Nur der Iterator (Java-Slang) muß einen Weg kennen, die Menge zu
ordnen. Wenn auf der Menge keine Ordnung definiert ist, ist auch keine
gewählte Auswertungsreihenfolge falsch. Da for-Schleifen nur auf
endlichen Mengen sinnvoll definiert sind, existiert auch immer eine
Wohlordnung, die der Iterator verwenden kann.
> ...
>> In Schleifen habe ich in Pascal *ausschließlich* geschlossene
>> Intervalle ("for i:=a to b"), in Arrays auch (array[a..b]). In
>
> Falsch. In _Zähl_schleifen - ja. Die anderen Schleifenkonstrukte kannst Du
> sowahl in Pascal als auch in C (und fast allen anderen Programmiersprachen)
> beliebig halten, die sind praktisch vollkommen äquivalent (soweit
> vorhanden).
Nein, richtig. Die Intervalle, die in diesem Thread als offen oder
halboffen bezeichnet werden, sind sämtlich geschlossen, da sie endlich
sind. [3..7[ ist eine äquivalente Schreibweise für das geschlossene
Intervall [3..6].
>> der C-Ecke habe ich für Felder nur halboffene Intervalle, aber
>> für Schleifen kann ich mir's raussuchen ("for (i=a; i<b; ++i)"
>> und "for (i=a; i<=b; ++i)").
>
> C-"for" golt nicht, da andere Baustelle!
>
>> Wenn du eine Pascal-For-Schleife kennst, die durch ein
>> halboffenes Intervall rennt, immer her damit, kann ich gut
>
> Wie wär's mit
> FOR i:= Anfang TO pred (Weiter) DO ...
> oder ^^^^^^^
> FOR i:= Decke DOWNTO succ (Fußboden) DO ...
> ? ^^^^^^^^^^^
> BTW: Geht mit beliebigen ordinalen Typen...
Das hat die erwähnte Beschränkung, daß pred(Weiter)=32767 sein kann für
Weiter=-32768. (für 16bittige int's)
Thomas 'PointedEars' Lahn
in diesem Thread immer mehr den Bezug zu Pascal (ungefähr seit
<b9g9tp$ih2cm$1...@ID-175126.news.dfncis.de>). Bitte diskutiert das
in .misc weiter/aus, da finden sich auch sicher noch mehr Leute,
die das interessiert. Danke.
PointedEars, X-Post & F'up2, TOFU beabsichtigt
Vinzent Hoefler
>Hm, ich halte Überladen für ein eher überflüssiges feature, da die
>meisten Programmiersprachen sowieso so wenige Symbole und
>Schlüsselwörter haben, das einem PROBLEMLOS auch ein anderes Wort als
>Bezeichner einfallen dürfte. Oder sind da manche Leute etwas bequem?
Ja. Mal so aus dem Aermel geschuettelt:
|type Altitude is 0 .. 80_000;
|type Vertical_Speed is -10 .. 10;
|
|function "*"(Left : Vertical_Speed, Right: Time) return Altitude;
|
| ...
|
|Estimated_Altitude_Delta := Current_Vertical_Speed * Boost_Time;
Du moechtest lieber ein:
|Estimated_Altitude_Delta :=
| Multiply_Vertical_Speed_With_Time (Current_Vertical_Speed,
| Boost_Time);
?
Nein, ich baue keine Flugzeuge, aber die Idee sollte klar sein... ;-)
Ansonsten:
<http://www.iks-jena.de/mitarb/lutz/ada/units/> und dort ganz unten
mal das "units.adb" anschauen.
>Es führt jedenfalls nicht zu besser wartbarem/lesbarem Code,
Kommt darauf an. Die Wunderwaffe[0] dynamisches OOP basiert immerhin
darauf.
>da der
>Normalleser nicht annimt, das z.B. + oder FOR in dem speziellen programm
>plötzlich eine andere bedeutung hat, als er es in der verwendeten
>Programmiersprache erwarten würde...
Richtig. Deswegen sollte man das Overloading auch so machen, dass es
die Bedeutung nicht aendert.
Vinzent.
[0] Zumindest in den 90ern[1] war das ja *die* Loesung der
Softwarekrise.
[1] Des letzten Jahrhunderts[2].
[2] Des letzten Jahrtausends.
Vinzent Hoefler
Nicht ganz:
|program Test;
|
|type
| MyInteger = -32768 .. 32767;
|
|begin
| WriteLn (SizeOf (MyInteger));
| WriteLn (Pred (Low (MyInteger)));
| WriteLn (Succ (High (MyInteger)));
|end {Test}.
ergibt:
|2
|-32769
|32768
Ein Versuch, das in einer Schleife mit einem Typen MyInteger zu
verwenden, laesst sich mit einem "Constant out of Range" erst gar
nicht kompilieren. Ja, man kann das natuerlich mittels einer lausigen
Typisierung umgehen. In Ada gaebe es dann die Quittung in Form eines
Constraint_Error dafuer.
Stefan Reuther
f'up wo's hingehört.
Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
> Stefan Reuther wrote:
>>Vinzent Hoefler <JeLlyFish...@gmx.net> wrote:
>>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>[enum { foo = 9 } in C]
>>>>Wozu auch ein Name? Wir wollen programmieren, und nicht Buzzword
>>>>Bingo spielen :-)
>>
>>> Um zu wissen, worueber man redet.
>>
>>Naja, das ist die normalste Sache der Welt, daß ein enum einen
>>Initialisierer hat.
> Was ist schon normal? Gebraucht habe ich es so in der Art bisher noch
> nicht, einfach deshalb, weil ich mich auf die compilerspezifische
> Implementation "zaehlt ab 0" verlassen musste.
s/compilerspezifische/garantierte/
>>>><http://os.inf.tu-dresden.de/vfiasco/>
>>[...]
>>> Fragt sich nur, warum ihr nicht einfach eine hoehere
>>> Programmiersprache benutzt... ;->
>>
>>Früher hätte man gefragt, warum wir überhaupt Mikrokerne bauen,
>>wo Monolithen doch so viel schneller sind.
> Ach, ich fand Mikrokernel schon immer huebsch.
Dito.
>>Selbst wenn wir Ada o.ä. verwenden würden, müßten wir das auf
>>einen Subset abspecken, der performant ist und trotzdem
>>verifizierbar.
> SPARK.
Weiß ich nicht, ich kenne SPARK nicht gut genug. Unser Ziel ist,
unmodifiziertes C++ in eine Logiksprache zu übersetzen, und
diese Logik dann zu beweisen, halbautomatisch. SPARK fordert,
wenn ich das richtig sehe, daß ich meinen Code annotiere ("diese
Funktion verwendet Variable X"), und der Examiner testet all
diese Annotationen auf Konsistenz. Da frage ich mich, warum man
den Compiler diese Annotationen nicht selber generieren läßt.
Die Informationen hat er ja, sobald wir ihm das komplette
Projekt vorsetzen.
Klar ist da ein Unterschied. Eine Anmerkung der Form "diese
Funktion wird immer und in alle Ewigkeit einen Wert zwischen 1
und 10 zurückliefern" bekommst du aus dem Code nicht raus. Im
Code siehst du nur "diese Funktion liefert momentan immer 3 oder 5".
Wie relevant sowas für unseren Kern ist, weiß ich nicht.
>>Die C-Sprachen haben aber eben eine bessere
>>Verbreitung bei "Kernel-Hackern". Der C++ Compiler läßt mehr
>>durchgehen ("int i = (int) new char[3]"), aber das kann man bei
>>der Verifikation ja verbieten.
> Moeglicherweise werdet ihr am Ende viel zu viel verbieten muessen.
Das interessante an Forschung ist, daß man vorher nicht weiß,
was man finden wird :-) Bis jetzt sieht es ganz gut aus.
Allerdings kommen die Theoretiker immer mal mit so Kleinigkeiten
wie "ach übrigens, Rekursion kann unser Beweiser nicht
handhaben". Ein Glück, daß ich nur für den C++-Parser zuständig
war/bin :-)
[C++ "is_polymorphic"]
>>>>Die Norm sagt halt, daß man um die Speicheradresse zu
>>>>erhalten bei polymorphen Typen "dynamic_cast" und bei
>>>>nichtpolymorphen Typen "static_cast" zu verwenden. Leider
>>>>gibt mir C++ nicht die nötigen Mittel in die Hand,
>>>>herauszufinden, was "T" denn nun ist.
>>
>>> Muss ja ein Klasse-Standard sein, der Wissen ueber Dinge verlangt, die
>>> ich nicht wissen kann.
[...]
>>Du kannst diese Information nur nicht per Programm abfragen
>>(im Sinne wie du die Größe mit sizeof abfragen kannst). Damit
>>kannst du keinen generischen Code bauen, der sowas abfragt.
> Das aendert jetzt aber nichts an meiner Aussage, oder?
Definiere "wissen" :-) Einigen wir uns auf "vom Compiler
erfahren"?
Stefan
~
Sieghard Schicktanz
Du schriebst am Sat, 17 May 2003 23:06:47 +0200:
> Deswegen habe ich mir ('tschuldigung :-) auch den Hinweis auf das
> umgekehrt polnische FORTH erlaubt, in welchem es überhaupt keine
> Hierarchien mehr gibt, keine Schlüsselwörter und keine Bedeutungen.
> Nur mehr commands, in FORTH schlicht sogar wertfrei (!) "word"
> genannt.
Nananana - hast Du Dich da auch mal mit dem "Compiler" befasst?
Oder wenigstens ein compilierendes Wort zusammengenagelt?
(Sowas wie ": +x , DOES> @ + ;" - seehr schlechtes Beispiel;)
In FORTH _gibt_ es durchaus unterschiedliche Arten von Objekten -
genaugenommen genau 3: Zahlen, einfache Worte und kompilierende Worte,
wobei letztere einfach durch die Eigenschaft gekennzeichnet sind, beim
Kompiliervorgang ausgeführt zu werden.
> Da ist das + genau so viel wert wie das IF und das BEGIN und LOOP
> und eine Zahl.
Durchaus _nicht_. "+" ist ein einfaches Wort, das beim Auftreten innerhalb
einer Definition einfach compliziert - äh, kompiliert, wird, während "BEGIN"
oder "LOOP" kompilierende Worte sind, die in ihrer Gesamtheit den "Compiler"
(der eher ein Tokenizer ist) selbst darstellen. Deshalb ist der auch vom
Anwendungsprogrammierer und ggfs. sogar vom Anwender selber erweiter- und
anpassbar.
Bei allen "normalen" klassischen Programmiersprachen gibt's die letzte Art
von Objekten nicht - der Compiler ist in seiner Funktion vom Compilerbauer
im Umfang vollkommen festgelegt.
Erst mit Aufkommen der objektorientierten Sprachen gibt's wieder zaghafte
Ansätze, eine gewisse Erweiterbarkeit der Compilerfunktionen zu
implementieren - u.a. durch die Möglichkeit zur Definition
anwendungsbezogener Operatoren. (Wobei diese Möglichkeit bei C++ schon
wieder dadurch recht beschnitten ist, daß nur bereits als Operatoren
_vorhandene_ Zeichenfolgen überladen werden können.)
(Dazu ist nebebei auch anzumerken, daß die Definition anwendungsspezifischer
Operatoren bereits in den 60er Jahren "des letzten Jahrhunderts" in der
Programmiersprache Algol68 vorgesehen war;)
(BTW: Algol68 kannte auch das Überladen von Funktionen und Prozeduren.)
> und eine Zahl. Klammern gibt's nur zum Kennzeichnen von Kommentaren.
> Selbst eine Zahl bedeutet nur den command: lege die Zahl nnn auf den
> Stack! Sonst nix.
Intern schon - der äußere Interpreter geht vom Vorhandensein einer Zahl
genau dann aus, wenn er die Zeichenfolge nicht im aktiven Dictionary finden
kann. Wenn die Konvertierung der Zeichenfolge mit der aktiven Basis nicht
gelingt, gibt's einen Fehler.
Schreib' mal folgendes:
HEX : 123 CAFE ; DECIMAL 1 123 + U.
51967 ok
Verwundert? ;-)
(Ja, ok, schon gut. Gehört eigentlich nicht hierher...)
Franz Glaser (NLx300)
> Hallo Franz,
>
> Du schriebst am Sat, 17 May 2003 23:06:47 +0200:
>
>>Deswegen habe ich mir ('tschuldigung :-) auch den Hinweis auf das
>>umgekehrt polnische FORTH erlaubt, in welchem es überhaupt keine
>>Hierarchien mehr gibt, keine Schlüsselwörter und keine Bedeutungen.
>>Nur mehr commands, in FORTH schlicht sogar wertfrei (!) "word"
>>genannt.
>
> Nananana - hast Du Dich da auch mal mit dem "Compiler" befasst?
> Oder wenigstens ein compilierendes Wort zusammengenagelt?
> (Sowas wie ": +x , DOES> @ + ;" - seehr schlechtes Beispiel;)
Habe ich mir erlaubt : +CONST: ... zu nennen.
Und die Kinder davon habe, in Erinnerung an meine Pascal Freude,
mit einem Pünktchen benannt, zB:
12 +CONST: .MMG für die Mischmenge im record
16 +CONST: .ERR für den Fehler-Akkumulator.
und es ist in 32-Bit Assembler geschrieben, der speed halber.
>>Da ist das + genau so viel wert wie das IF und das BEGIN und LOOP
>>und eine Zahl.
>
> Durchaus _nicht_. "+" ist ein einfaches Wort, das beim Auftreten innerhalb
> einer Definition einfach compliziert - äh, kompiliert, wird, während "BEGIN"
> oder "LOOP" kompilierende Worte sind, die in ihrer Gesamtheit den "Compiler"
> (der eher ein Tokenizer ist) selbst darstellen. Deshalb ist der auch vom
> Anwendungsprogrammierer und ggfs. sogar vom Anwender selber erweiter- und
> anpassbar.
Das stimmt schon, bloß - das betrifft erst den Unterschied zwischen
dem compilierten code und dem Text.
Mein Compiler hat übrigens nicht 8 kB sondern ca. 140kB und das was
normalerweise FORTH heißt, das heißt in meinem ATLAN Computer
4TH DEFINITIONS. Ich tu gern Worte, die wo was createn, mit einem
colon kennzeichnen. VAR: und CONST: beispielsmaßig. Ich habe mir
die Freiheit herausgenommen, mein eigenes 4TH zu schreiben, weit
weg von jeder Norm, auch nicht PC-kompatibel sondern für meine
eigene Hardware, Multitasking und Multiuserfähig, 1:1 EPROM-bar,
Hardwareinterrupt- und Netzwerkfähig.
Wie du siehst, habe ich mich mit dem Compiler _befaßt_ ;-)))
Aber jetzt genug des OT hier.
Sieghard Schicktanz
Du schriebst am Mon, 19 May 2003 07:33:31 +0200:
> Da es keiner von euch zu merken scheint: Ich vermisse jedenfalls
> in diesem Thread immer mehr den Bezug zu Pascal (ungefähr seit
...
Hier wird doch aber genau über die _spezifischen_, "distinktiven"
Eigenschaften von Pascal diskutiert - dazu ist halt auch der Vergleich mit
Du könntest allenfalls ein inzwischen nicht mehr passendes Subject bemängeln
- zugestanden.
> PointedEars, X-Post & F'up2, TOFU beabsichtigt
Unangenehm registriert.
BTW: Du zitierst als unangebracht genau das, wofür Du eintrittst:
> >> Wie wär's mit
> >> FOR i:= Anfang TO pred (Weiter) DO ...
> >> oder ^^^^^^^
> >> FOR i:= Decke DOWNTO succ (Fußboden) DO ...
> >> ? ^^^^^^^^^^^
Sowas kann man eher nicht oft genug erwähnen, weil's scheint's kaum einer
kennt. Da fehlt's wohl an Grundlagendiskussionen...
--
Sieghard Schicktanz
Du schriebst am 19 May 2003 00:36:33 GMT:
> >> Es ist halt eine Schleife zur Iteration über beliebige Mengen.
...
> > Eben, fast jedenfalls - es müssen _geordnete_ Mengen sein, die in einer
> > vorgegebenen _Reihenfolge_ bearbeitet werden können.
...
> Nein. Nur der Iterator (Java-Slang) muß einen Weg kennen, die Menge zu
> ordnen.
Na eben, d.h. die Menge muß geordnet sein.
> ordnen. Wenn auf der Menge keine Ordnung definiert ist, ist auch keine
> gewählte Auswertungsreihenfolge falsch. Da for-Schleifen nur auf
Damit wird eben, fall keine Ordnung von demjenigen, der die Menge definiert
hat, vorgegeben wurde, nach einem "Standardschema" angeordnet - auch wenn
das dem Problem durchaus unangemessen ist.
> endlichen Mengen sinnvoll definiert sind, existiert auch immer eine
> Wohlordnung, die der Iterator verwenden kann.
Eine solche Ordnung würde ich dann allerdings _nicht_ als "Wohlordnung"
bezeichnen.
Wie ordnest Du denn z.B. die simple Menge der Raumrichtungen "wohl"?
TYPE
spatial_direction = (left, right, up, down, forward, backward);
Oder wie ordnest Du Mikroprozessoren "wohl"?
> >> In Schleifen habe ich in Pascal *ausschließlich* geschlossene
> >> Intervalle ...
> > Falsch. In _Zähl_schleifen - ja. Die anderen Schleifenkonstrukte kannst
...
> Nein, richtig. Die Intervalle, die in diesem Thread als offen oder
> halboffen bezeichnet werden, sind sämtlich geschlossen, da sie endlich
> sind. [3..7[ ist eine äquivalente Schreibweise für das geschlossene
> Intervall [3..6].
Ok, so gesehen natürlich - auf kardinalen Mengen gibt es insoweit eh keinen
prinzipiellen Unterschied zwischen offenen und geschlossenen Intervallen.
...
> Das hat die erwähnte Beschränkung, daß pred(Weiter)=32767 sein kann für
wo? ^^^^^^^^
> Weiter=-32768. (für 16bittige int's)
Dann hat der Compiler einen Fehler. In dem Fall hat er eine
Bereichsüberschreitung zu melden (falls das der Herr Programmierkünstler
nicht als Sonderoption zur Überoptimierung abgeschaltet und als irrelevant
vernachlässigt hat. Aua.)
(Sorry für die längliche Verzögerung)
--
Florian Kreidler
Sieghard Schicktanz schrieb im Artikel <20030525115728.3...@Schicktanz.SchS.de>:
> Hallo Florian,
>
> Du schriebst am 19 May 2003 00:36:33 GMT:
>
>> >> Es ist halt eine Schleife zur Iteration über beliebige Mengen.
> ...
>> > Eben, fast jedenfalls - es müssen _geordnete_ Mengen sein, die in einer
>> > vorgegebenen _Reihenfolge_ bearbeitet werden können.
> ...
>> Nein. Nur der Iterator (Java-Slang) muß einen Weg kennen, die Menge zu
>> ordnen.
>
> Na eben, d.h. die Menge muß geordnet sein.
nicht von vornherein
>> ordnen. Wenn auf der Menge keine Ordnung definiert ist, ist auch keine
>> gewählte Auswertungsreihenfolge falsch. Da for-Schleifen nur auf
>
> Damit wird eben, fall keine Ordnung von demjenigen, der die Menge definiert
> hat, vorgegeben wurde, nach einem "Standardschema" angeordnet - auch wenn
> das dem Problem durchaus unangemessen ist.
Oft ist die Reihenfolge egal, zum Beispiel bei den Raumrichtungen oder
bei einer Liste verschiedener Mikroprozessoren.
>> endlichen Mengen sinnvoll definiert sind, existiert auch immer eine
>> Wohlordnung, die der Iterator verwenden kann.
>
> Eine solche Ordnung würde ich dann allerdings _nicht_ als "Wohlordnung"
> bezeichnen.
Darum wird kein Mathematiker mit dir streiten wollen.
> Wie ordnest Du denn z.B. die simple Menge der Raumrichtungen "wohl"?
>
> TYPE
> spatial_direction = (left, right, up, down, forward, backward);
naja, zum Beispiel: left < right < up < down < forward < backward
> Oder wie ordnest Du Mikroprozessoren "wohl"?
in der Reihenfolge, in der sie mir einfallen
[...]
>> Das hat die erwähnte Beschränkung, daß pred(Weiter)=32767 sein kann für
> wo? ^^^^^^^^
^^^
neulich irgendwo in diesem Thread, es ging darum, wie man die
for-Schleife von Pascal in C implementiert.
>> Weiter=-32768. (für 16bittige int's)
>
> Dann hat der Compiler einen Fehler. In dem Fall hat er eine
> Bereichsüberschreitung zu melden (falls das der Herr Programmierkünstler
> nicht als Sonderoption zur Überoptimierung abgeschaltet und als irrelevant
> vernachlässigt hat. Aua.)
Wenn Weiter eine Konstante ist. Wenn Weiter eine Variable ist, wird der
Überlauf (zumindest von meinem alten Turbo-Pascal) ignoriert.
Thomas 'PointedEars' Lahn
> Hallo Thomas,
Hier ist eine öffentliche Newsgroup, nicht private Mail.
>> PointedEars, X-Post & F'up2, TOFU beabsichtigt
>
> Unangenehm registriert.
>
> BTW: Du zitierst als unangebracht genau das, wofür Du eintrittst:
Wie meinen?
F'up2 PointedEars
Vinzent Hoefler
>Sieghard Schicktanz schrieb im Artikel <20030525115728.3...@Schicktanz.SchS.de>:
>
[Semantik von Succ (...) und Pred (...) bei Bereichsueberschreitung]
>> Dann hat der Compiler einen Fehler. In dem Fall hat er eine
>> Bereichsüberschreitung zu melden (falls das der Herr Programmierkünstler
>> nicht als Sonderoption zur Überoptimierung abgeschaltet und als irrelevant
>> vernachlässigt hat. Aua.)
>
>Wenn Weiter eine Konstante ist. Wenn Weiter eine Variable ist, wird der
>Überlauf (zumindest von meinem alten Turbo-Pascal) ignoriert.
Was bestenfalls beweist, dass Turbo Pascal keinen Overflow check
kennt.
Kleiner Test gefaellig?
Borland Pascal:
|C:\WINDOWS\Desktop\test>cat t.pas
|program Test;
|
|var
| i : -32768 .. 32767;
|
|begin
| WriteLn ('size is ', SizeOf (i), ' bytes.');
|
| i := Low (i);
| WriteLn (Pred (i), ' ', i, ' ', Succ (i));
|
| i := High (i);
| WriteLn (Pred (i), ' ', i, ' ', Succ (i));
|end {Test}.
|
|C:\WINDOWS\Desktop\test>bpc t
|Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland International
|T.PAS(14)
|14 lines, 2736 bytes code, 672 bytes data.
|
|C:\WINDOWS\Desktop\test>t
|size is 2 bytes.
|32767 -32768 -32767
|32766 32767 -32768
Kein Check, also macht es logischerweise *bumm*.
|C:\WINDOWS\Desktop\test>bpc -$Q+ t
|Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland International
|T.PAS(14)
|14 lines, 0.4 seconds, 2768 bytes code, 672 bytes data.
|
|C:\WINDOWS\Desktop\test>t
|size is 2 bytes.
|Runtime error 215 at 0000:006E.
Mit Check macht es auch *bumm*, aber natuerlich wie erwartet.
Das ganze nochmal mit einem modernen Compiler:
|C:\WINDOWS\Desktop\test>\fpc\bin\go32v2\ppc386 t
|Free Pascal Compiler version 1.0.6 [2002/04/23] for i386
|Copyright (c) 1993-2002 by Florian Klaempfl
|Target OS: GO32 V2 DOS extender
|Compiling t.pas
|Linking t.exe
|14 Lines compiled, 0.2 sec
|
|C:\WINDOWS\Desktop\test>t
|size is 2 bytes.
|32767 -32768 -32767
|32766 32767 -32768
Crash.
|C:\WINDOWS\Desktop\test>\fpc\bin\go32v2\ppc386 -Co t
|Free Pascal Compiler version 1.0.6 [2002/04/23] for i386
|Copyright (c) 1993-2002 by Florian Klaempfl
|Target OS: GO32 V2 DOS extender
|Compiling t.pas
|Linking t.exe
|14 Lines compiled, 0.2 sec
|
|C:\WINDOWS\Desktop\test>t
|size is 2 bytes.
|Runtime error 215 at 0x0000F143
| 0x0000F143
| 0x00002049
Und bingo. Was genau wolltest Du noch mal sagen? Dass man
Runtimechecks auch abschalten kann, um C-Semantik zu bekommen?
Thomas 'PointedEars' Lahn
> Florian Kreidler wrote:
>>Wenn Weiter eine Konstante ist. Wenn Weiter eine Variable ist, wird der
>>Überlauf (zumindest von meinem alten Turbo-Pascal) ignoriert.
>
> Was bestenfalls beweist, dass Turbo Pascal keinen Overflow check
> kennt.
Das ist zum Glück Unfug. Auch Turbo Pascal hat eine Option sowie einen
Compilerswitch für Overflow-Checking. Man muss sie nur benutzen.
Allerdings kann ich hier nur für Turbo Pascal 6.0 und 7.0 TPX sprechen.
PointedEars
--
> ECMAScript ist somit nicht mit dem W3C-DOM kompatibel. Richtig?
Hunde sind zu Fischsuppe nicht kompatibel. Nachts ist es kälter als
draußen. Wo ist der Zusammenhang zwischen W3C-DOM unter z.B. Java oder
PHP und ECMA-Script? (Georg Maaß in dcljs <3D118071...@vnett.de>)
Vinzent Hoefler
>Vinzent Hoefler wrote:
>
>> Florian Kreidler wrote:
>>>Wenn Weiter eine Konstante ist. Wenn Weiter eine Variable ist, wird der
>>>Überlauf (zumindest von meinem alten Turbo-Pascal) ignoriert.
>>
>> Was bestenfalls beweist, dass Turbo Pascal keinen Overflow check
>> kennt.
>
>Das ist zum Glück Unfug.
Fuer TP6 leider nicht. Q+ (Overflow check, nicht zu verwechseln mit
R+, Range Check) wurde ebenso wie auch die Low/High-"Funktionen" erst
bei TP7 eingefuehrt[0] und R+ handelt diesen Fall eben weder in TP6
noch in BP/TP7 ab:
|C:\WINDOWS\Desktop\test>cat t.pas
|program Test;
|
|var
| i : -32768 .. 32767;
|
|begin
| WriteLn ('size is ', SizeOf (i), ' bytes.');
|
| i := -32768; {Low (i);}
| WriteLn (Pred (i), ' ', i, ' ', Succ (i));
|
| i := 32767; {High (i);}
| WriteLn (Pred (i), ' ', i, ' ', Succ (i));
|end {Test}.
|
|C:\WINDOWS\Desktop\test>\tp6\tpc -$R+ t
|Turbo Pascal Version 6.0 Copyright (c) 1983,90 Borland International
|T.PAS(14)
|14 lines, 2496 bytes code, 658 bytes data.
|
|C:\WINDOWS\Desktop\test>t
|size is 2 bytes.
|32767 -32768 -32767
|32766 32767 -32768
Leider, leider. Oder gibt es eine mir unbekannte (aka undokumentierte)
Option? "-$Q+" wird erwartungsgemaess mit "Invalid command line
option" quittiert.
>Auch Turbo Pascal hat eine Option sowie einen
>Compilerswitch für Overflow-Checking. Man muss sie nur benutzen.
Richtig, wie auch im Beispiel gezeigt.
>Allerdings kann ich hier nur für Turbo Pascal 6.0 und 7.0 TPX sprechen.
Nein, den Overflow Check gibt es AFAIK erst ab den 7er Versionen. Den
Range Check wiederum kannte wahrscheinlich schon die 1.0 Version.
Vinzent.
[0] Die 7er Version hat ohnehin einige deutliche Verbesserungen wie
z.B. auch die Moeglichkeit, Funktionsparameter als const zu
deklarieren.
Franz Glaser (NLx300)
> Da es keiner von euch zu merken scheint: Ich vermisse jedenfalls
> in diesem Thread immer mehr den Bezug zu Pascal (ungefähr seit
> <b9g9tp$ih2cm$1...@ID-175126.news.dfncis.de>). Bitte diskutiert das
> in .misc weiter/aus, da finden sich auch sicher noch mehr Leute,
> die das interessiert. Danke.
>
> PointedEars, X-Post & F'up2, TOFU beabsichtigt
>
F'up2 sender remove /invalid-/
Der Vergleich von non-Pascal-Schleifen in Pascalianer-Köpfen hat
mit Pascal zu tun. Wenn du das nicht kapierst, dann ist das
schade.
Daß du jetzt auch noch anfängst, deine Moralregeln wie ein Pfaff
"Hier ist eine öffentliche Newsgroup, nicht private Mail."
einzuführen, das macht mich
Fuxteufelswild!
Vertschüß dich. Kauf dir deine eigene NG
Servas!
Franz Glaser (NLx300)
> Da es keiner von euch zu merken scheint: Ich vermisse jedenfalls
> in diesem Thread immer mehr den Bezug zu Pascal (ungefähr seit
> <b9g9tp$ih2cm$1...@ID-175126.news.dfncis.de>). Bitte diskutiert das
> in .misc weiter/aus, da finden sich auch sicher noch mehr Leute,
> die das interessiert. Danke.
>
dein F'up ignored
F'up2 poster remove /invalid-/
Horst Kraemer
Wir bedauern, Ihre Bewerbung als Hilfspolizist für de.comp.lang.pascal
mangels Bedarf nicht beruecksichtigen zu koennen und wuenschen Ihnen
fuer Ihren weiteren Lebensweg alles Gute.
mfg
Horst "was muss ich hier reinschreiben?" Kraemer
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn schrieb:
>> Da es keiner von euch zu merken scheint: Ich vermisse jedenfalls
>> in diesem Thread immer mehr den Bezug zu Pascal (ungefähr seit
>> <b9g9tp$ih2cm$1...@ID-175126.news.dfncis.de>). Bitte diskutiert das
>> in .misc weiter/aus, da finden sich auch sicher noch mehr Leute,
>> die das interessiert. Danke.
>>
>
> dein F'up ignored
Dito,
> F'up2 poster remove /invalid-/
da ich keinen Wert auf Bounces lege.
> Der Vergleich von non-Pascal-Schleifen in Pascalianer-Köpfen hat
> mit Pascal zu tun. Wenn du das nicht kapierst, dann ist das
> schade.
>
> Daß du jetzt auch noch anfängst, deine Moralregeln wie ein Pfaff
Es sind nicht meine Moralregeln. Geh Dich in de.newusers.infos
informieren, was die Netiquette ist.
> "Hier ist eine öffentliche Newsgroup, nicht private Mail."
> einzuführen, das macht mich
> Fuxteufelswild!
Heul doch!
> Vertschüß dich. Kauf dir deine eigene NG
Schreibt ein asozialer Adressfälscher.
---> http://www.gerlo.de/falsche-email-adressen.html
PointedEars, X-Post eingegrenzt, F'up2 passend gesetzt
Thomas 'PointedEars' Lahn
Horst Kraemer wrote:
> On Mon, 26 May 2003 13:11:05 +0200, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
>
>> Sieghard Schicktanz wrote:
>>
>> > Hallo Thomas,
>>
>> Hier ist eine öffentliche Newsgroup, nicht private Mail.
>>
>> >> PointedEars, X-Post & F'up2, TOFU beabsichtigt
>> >
>> > Unangenehm registriert.
>> >
>> > BTW: Du zitierst als unangebracht genau das, wofür Du eintrittst:
>>
>> Wie meinen?
>>
>>
>> F'up2 PointedEars
^^^^^
Und warum hast Du das ignoriert? Aha.
> Wir bedauern, Ihre Bewerbung als Hilfspolizist für de.comp.lang.pascal
> mangels Bedarf nicht beruecksichtigen zu koennen und wuenschen Ihnen
> fuer Ihren weiteren Lebensweg alles Gute.
Danke.
> mfg
> Horst "was muss ich hier reinschreiben?" Kraemer
"Ich will eine Froschpille. Jetzt. Gleich".
PointedEars, F'up2 passend gesetzt
--
[...] aber ein bißchen tiefer in die Materie einzutauchen ist einfach notwendig
wenn man mehr als nur Programmiersklave auf einer Codegallere werden will die
sowieso alle 2 Jahre ihren Code über Bord wirft...
(Achim Friedland in fem.comp.coding <as01hh$rll$1...@hadar.fem.tu-ilmenau.de>)
Linus Van Pelt
>[X] Fullquote zwecks Einweisung
Aha, schon wieder eine deiner schwachsinnigen Einweisungen.
>Horst Kraemer wrote:
>
>> On Mon, 26 May 2003 13:11:05 +0200, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
>>
>>> Sieghard Schicktanz wrote:
>>>
>>> > Hallo Thomas,
>>>
>>> Hier ist eine öffentliche Newsgroup, nicht private Mail.
>>>
>>> >> PointedEars, X-Post & F'up2, TOFU beabsichtigt
>>> >
>>> > Unangenehm registriert.
>>> >
>>> > BTW: Du zitierst als unangebracht genau das, wofür Du eintrittst:
>>>
>>> Wie meinen?
>>>
>>>
>>> F'up2 PointedEars
> ^^^^^
>Und warum hast Du das ignoriert? Aha.
Er hat dein Fup2 'poster' nicht befolgt und dafür weist du ihn nach
dag° ein? Spitzohr langsam machst du dich nur noch lächerlich.
>> Wir bedauern, Ihre Bewerbung als Hilfspolizist für de.comp.lang.pascal
>> mangels Bedarf nicht beruecksichtigen zu koennen und wuenschen Ihnen
>> fuer Ihren weiteren Lebensweg alles Gute.
>
>Danke.
>
>> mfg
>> Horst "was muss ich hier reinschreiben?" Kraemer
>
>"Ich will eine Froschpille. Jetzt. Gleich".
Bedien dich. Du bist ja eh die ganze Zeit hier in dag°
MfG
Linus
--
Klage nicht ueber die Finsternis - zünde ein Licht an!
[Chinesische Weisheit]
Markus Humm
Wenn die Diskussionen nicht weiter vom Thema abgehen wie diese hier (=
bleibt einigermaßen im Rahmen) denke ich braucht man nicht so ein Trara
um Umgangsformen und gegenseitiger "anmotze" veranstalten. Das ist
glaube ich fast mehr off-topic als die Themenabweichung. Wen's nicht
interessiert kann ja genügend andere Themen hier lesen/diskutieren.
Nur der Umgangston dürfte sachlich bleiben!
=> Cool down, sonst kommt ihr im Sommer gar nicht mehr aus dem Schwitzen
heraus! Es gibt Dinge wegen denen man sich eher stressen dürfte (okay,
aus dem Dipl. Arbeit schreiben ist ein Dipl. Ing wohl schon raus... ;-)
) als wegen so was.
Grüße
Markus Humm
Sieghard Schicktanz
Du schriebst am Wed, 21 May 2003 13:05:18 +0200:
> >>umgekehrt polnische FORTH erlaubt, in welchem es überhaupt keine
...
> > Nananana - hast Du Dich da auch mal mit dem "Compiler" befasst?
> > Oder wenigstens ein compilierendes Wort zusammengenagelt?
> > (Sowas wie ": +x , DOES> @ + ;" - seehr schlechtes Beispiel;)
>
> Habe ich mir erlaubt : +CONST: ... zu nennen.
Vonmiraus - eigentlich ist das so ja garnicht vollständig, ein CREATE fehlt
noch...
> > Durchaus _nicht_. "+" ist ein einfaches Wort, das beim Auftreten
> > innerhalb einer Definition einfach compliziert - äh, kompiliert, wird,
> > während "BEGIN" oder "LOOP" kompilierende Worte sind, die in ihrer
...
> Das stimmt schon, bloß - das betrifft erst den Unterschied zwischen
> dem compilierten code und dem Text.
Das betrifft den Unterschied zwischen _Syntax_ und _Semantik_.
Bei FORTH kannst Du genau wie bei Pascal einen Haufen "Worte" bzw. "Tokens"
nehmen, kräftig umrühren und das Ergebnis dem Compiler vorwerfen.
Bei FORTH wirst Du, aufgrund der sehr schwachen syntaktischen Vorgaben, in
vielen Fällen etwas compilierbares erhalten - "sinnvoll" laufen wird
allerdings eher wenig davon.
Bei Pascal verweigert der Compiler aufgrund der sehr restriktiven Syntax
wesentlich mehr Unsinn, da ist die Chance, daß ein kompilierbares Programm
eine erkennbare Funktion aufweist, schon besser. ("Funktion" hier im
wesentlichen als "terminiert ohne fatale Folgen" gemeint;)
> Wie du siehst, habe ich mich mit dem Compiler _befaßt_ ;-)))
Hätte ich eigentlich bei Deinem fachlichen Hintergrund auch erwartet - warum
provozierst Du dann eigentlich immer Diskussionen um solche grundlegenden
Dinge?
> Aber jetzt genug des OT hier.
Deshalb habe ich auch den letzten Abschnitt "entsorgt"...
Sieghard Schicktanz
Du schriebst am 25 May 2003 21:00:40 GMT:
> > Na eben, d.h. die Menge muß geordnet sein.
...
> Oft ist die Reihenfolge egal, zum Beispiel bei den Raumrichtungen oder
> bei einer Liste verschiedener Mikroprozessoren.
Sicher, solche Fälle gibt's. Aber es gibt auch durchaus Fälle, in denen
_keine_ Anordnung sinnvoll ist. Z.B. bei den Raumrichtungen.
> > Eine solche Ordnung würde ich dann allerdings _nicht_ als "Wohlordnung"
> > bezeichnen.
> Darum wird kein Mathematiker mit dir streiten wollen.
:-)
...
> naja, zum Beispiel: left < right < up < down < forward < backward
Durch was gerechtfertigt? Doch _ausschließlich_ durch die völlig
_willkürliche_ Aufzählung.
> > Oder wie ordnest Du Mikroprozessoren "wohl"?
>
> in der Reihenfolge, in der sie mir einfallen
Das wird _wohl_ nicht jedem wohlgefallen...
> [...]
> >> Das hat die erwähnte Beschränkung, daß pred(Weiter)=32767 sein kann für
> > wo? ^^^^^^^^
> ^^^
> neulich irgendwo in diesem Thread, es ging darum, wie man die
> for-Schleife von Pascal in C implementiert.
Naja, der Kontext war nicht ganz der - derjenige hatte das aus Sicht eines
C-Programmiers als Beispiel für ein Pascal-Problem genannt, offenbar ohne
Nachprüfung, weil in direkter Folge bestritten...
> >> Weiter=-32768. (für 16bittige int's)
...
> Wenn Weiter eine Konstante ist. Wenn Weiter eine Variable ist, wird der
> Überlauf (zumindest von meinem alten Turbo-Pascal) ignoriert.
Bitte Version angeben - zumindest bei TP/BP7 steht das in der Dokumentation:
"The standard function /Pred/ can be applied to any ordinal type
value to return the predecessor of the value. If applied to the
first value in the ordinal type and if range checking is enabled
*{$R+}*, /Pred/ produces a run-time error."
Desgl. für /Succ/. Evtl. könnten die älteren TPs da ein Lücke haben.
Oder - wie ich ja geschrieben hatte - der Herr Programmierkünstler hat sich
an der Stelle verkünstelt... =,-)
(In der Technik ist derjenige, der eine Sicherheitseinrichtung außer
Funktion setzt, für etwaige Unfälle eben selber verantwortlich.)
Georg Richter
> [gegenseitige Follow-ups etc. gesnippt]
Das ist aber 'man dreist ;-)
> Wenn die Diskussionen nicht weiter vom Thema abgehen wie diese hier (=
> bleibt einigermaßen im Rahmen) denke ich braucht man nicht so ein Trara
> um Umgangsformen und gegenseitiger "anmotze" veranstalten. Das ist
> glaube ich fast mehr off-topic als die Themenabweichung. Wen's nicht
> interessiert kann ja genügend andere Themen hier lesen/diskutieren.
Markus,
das ist doch (scheinbar?) "ganz normal" in DE:
Einer stellte 'ne Frage
Fünf massregeln den Fragesteller
Der sechste vielleicht beantwortet die Frage (und wird ggf. von den fünfen
dafür getadelt).
> Nur der Umgangston dürfte sachlich bleiben!
Es sind immer die gleichen. Und wer z.B. "... Codegallere ..." zitiert
sollte sich nicht wundern, wenn einigen irgendwann die Galle ...
> => Cool down, sonst kommt ihr im Sommer gar nicht mehr aus dem Schwitzen
> heraus! Es gibt Dinge wegen denen man sich eher stressen dürfte (okay,
> aus dem Dipl. Arbeit schreiben ist ein Dipl. Ing wohl schon raus... ;-)
> ) als wegen so was.
Darf man gratulieren?
--
Georg O.F. Richter
alias Hourdi
hourdi_@_t-online.de
(Beim programmieren auf Rechtsschreibung achten: Das ist Quältext)
Franz Glaser (NLx300)
>
>>=> Cool down, sonst kommt ihr im Sommer gar nicht mehr aus dem Schwitzen
>>heraus! Es gibt Dinge wegen denen man sich eher stressen dürfte (okay,
>>aus dem Dipl. Arbeit schreiben ist ein Dipl. Ing wohl schon raus... ;-)
>>) als wegen so was.
>
> Darf man gratulieren?
irgendwie isses in einer Rekursion gemündelt. das gefällt mir
jetzt aber. der loop zieht sich praktisch sein Ende unterm
Hintern selber wech und wundert sich, wieso es wieder im Kreis
herum geht. ad infi - ähhhh
Pascal issa scheene Sprach'!
Btw: heißt es nicht
{$IFDEF Oberlehrer}
wegen derer
{$ELSE}
wegen denen
{$ENDIF}
fraachjanuuur?
MfG
--
Franz Glaser MEG Glasau 3 A-4191 Vorderweissenbach
http://www.meg-glaser.com n...@meg-glaser.com
http://www.meg-glaser.biz <-replaces the EUnet-domain
+43-7219-7035-0 Fax: -4 mobil: +43-664-2225893
Markus Humm
>
>
> Darf man gratulieren?
>
Jein: Noch nicht. Habe jedoch gerade die technischen Probleme im
benoteten Java-Gruppenprojekt gelöst (incl. Fehler im Testdatenset) und
bin daher einigermaßen glücklich (war bis ca. 20 Uhr an der BA, u.a.
wegen des Projekts - also typisch Wirtschaftsinformatiker [sag' das mal
einer den BWLlern...])
Grüße
Markus Humm / Wirtschaftsinformatikassistent(BA)
Georg Richter
> > Darf man gratulieren?
>
> irgendwie isses in einer Rekursion gemündelt. das gefällt mir
> jetzt aber. der loop zieht sich praktisch sein Ende unterm
> Hintern selber wech und wundert sich, wieso es wieder im Kreis
> herum geht. ad infi - ähhhh
>
> Pascal issa scheene Sprach'!
>
> Btw: heißt es nicht
> {$IFDEF Oberlehrer}
> wegen derer
> {$ELSE}
> wegen denen
> {$ENDIF}
>
> fraachjanuuur?
Hallo Franz,
sachjanur. Da gibt's endlich 'mal (sonst nur totes Beinkleid) 'n feinen
Srett über n(eg)ative Zufallszahlen, und irgendein Dollbohrer muss auf
einmal (auch hier) Pozilei spielen. Es heisst nicht grundlos "Wegen des
Schildes" statt "Wegen dem Schild". Aber da stelle 'mer uns janz domm: De
Dampfmaschin' is e'ne jrosse schwarze Loch, und de' Rest kriejen 'mer
später".
Lass Dich nicht unterkriegen,
wir (ich) lese(n) gerne von Dir (behaupte ich 'mal im Namen der NG),
Gute Gesundheit,
Gehorch
Markus Humm
Na also, der Umgangston wird ja schon wieder viel freundlicher... :-)
Grüße am Feiertag (zumindest in BaWü)
Markus
PS: wir können alles, außer Hochdeutsch!
Georg Richter
> > Darf man gratulieren?
Oops (huppela), pass' bitte in ausserdeutschen NG's auf mit dem "(BA)".
Könnte mit "Bachelor of Arts" verwuchselt werden.
Gruss,
Gehorch
--
Georg O.F. Richter
alias Hourdi
hourdi_@_t-online.de
(Hätten mich meine Eltern Dragoslav getauft, könnte ich meinen Vornamen mit
"Dr." abkürzen)
Sieghard Schicktanz
Du schriebst am Mon, 26 May 2003 13:11:05 +0200:
> > BTW: Du zitierst als unangebracht genau das, wofür Du eintrittst:
>
> Wie meinen?
Jomei. Wannst'as ned liest...
Andrerseits... Deinen Spruch find' ich richtig gut:
[...] aber ein bißchen tiefer in die Materie einzutauchen ist einfach
notwendig
wenn man mehr als nur Programmiersklave auf einer Codegallere werden will
die
sowieso alle 2 Jahre ihren Code über Bord wirft...
(Achim Friedland in fem.comp.coding <as01hh$rll$1...@hadar.fem.tu-ilmenau.de>)
[von der Falschreibweise der Galeere und der neuen deutschen recht Schrei
Bung mal abgeseh'n:]
(Entschuldigung Horst - SCNR... ;)
Markus Humm
>>Markus Humm / Wirtschaftsinformatikassistent(BA)
>
>
> Oops (huppela), pass' bitte in ausserdeutschen NG's auf mit dem "(BA)".
> Könnte mit "Bachelor of Arts" verwuchselt werden.
>
Grüße
Markus
Vinzent Hoefler
>Ja, und in dt. Newsgroups mit der BA: Bundesanstallt für Arbeit... ;-)
Keine Gefahr, korrekt heisst das BfA. :-P
Vinzent.
Markus Humm
Falsch! Neulich erst in VWL aufgetaucht, da hat jemand genau den
gleichen Fehler wie du gemacht: die BfA ist die
Bundesversicherungsanstallt für Angestellte, sitz in Berlin!
Puh und diese tolle gedankliche Leistung auch noch bei dieser Hitze!
Mfg.
Markus Humm
Vinzent Hoefler
>Vinzent Hoefler schrieb:
>> Markus Humm wrote:
>>
>>>Ja, und in dt. Newsgroups mit der BA: Bundesanstallt für Arbeit... ;-)
>>
>> Keine Gefahr, korrekt heisst das BfA. :-P
>
>Falsch! Neulich erst in VWL aufgetaucht, da hat jemand genau den
>gleichen Fehler wie du gemacht: die BfA ist die
>Bundesversicherungsanstallt für Angestellte,
Jetzt, wo Du es sagst... Stimmt, die haben seinerzeit meine Rente
bezahlt.
>Puh und diese tolle gedankliche Leistung auch noch bei dieser Hitze!
*nach Entschuldigung such* ... War es, als ich das Posting schrieb,
hier schon warm genug...? ;-) Ich erinnere mich nicht.
Vinzent.
Sieghard Schicktanz
Du schriebst am Wed, 04 Jun 2003 14:57:55 +0200:
> >>Ja, und in dt. Newsgroups mit der BA: Bundesanstallt für Arbeit... ;-)
**
> > Keine Gefahr, korrekt heisst das BfA. :-P
> >
> > Vinzent.
> Falsch! Neulich erst in VWL aufgetaucht, da hat jemand genau den
> gleichen Fehler wie du gemacht: die BfA ist die
> Bundesversicherungsanstallt für Angestellte, sitz in Berlin!
** ^t
> Puh und diese tolle gedankliche Leistung auch noch bei dieser Hitze!
Naja, _so_ toll war die Leistung eher nicht...
Andererseits... eine_gewisse_ Verwandtschaft zu der Einrichtung, die
tatsächlich _mit_ zwei "l" geschrieben wird, könnte durchaus vermutet
werden... ];-) (Bei beiden =):-] ) [SCNR]