impizite typanpassung vermeiden... aber wie?
michael paap
ich möchte eine
function istPrim (x:integer): boolean
definieren. diese function benutzt ihrerseits eine
function ganzeZahl (x:real): boolean.
nun soll z.b. istPrim folgendes aufrufen:
if ganzeZahl (x / 2) = true then ....
normalerweise wuerde jetzt eine implizite typanpassung erfolge, also x
durch x.0 ersetzt werden, und das ergebnis waere real, also alles in
ordnung.
nun will/soll ich aber die implizite typanpassung vermeiden...
gibt es eine möglichkeit, diese explizit auszuführen, also so etwas wie
eine funktion, die z.b. den integerwert 2 in den realwert 2.0 überführt:
intreal (2) = 2.0 ?
umgekeht waere es ja trunc ...
achja: mit metakritik ist mir nicht geholfen; ich suche NICHT nach einem
effizienten primzahlprog sondern nach einer lösung für genau DIESES
problem :-)
michael
--
michael ist michael paap
ihr erreicht mich auch per ICQ: 7024000
Frederic
> nun will/soll ich aber die implizite typanpassung vermeiden...
> gibt es eine möglichkeit, diese explizit auszuführen, also so etwas wie
> eine funktion, die z.b. den integerwert 2 in den realwert 2.0 überführt:
>
> intreal (2) = 2.0 ?
> umgekeht waere es ja trunc ...
Ich sehe folgende Möglichkeit:
function IntToReal(i: integer): real;
begin
IntToReal := i
end;
Ob das Standard-Pascal ist, weiß ich nicht...
michael paap
> Ich sehe folgende Möglichkeit:
>
> function IntToReal(i: integer): real;
> begin
> IntToReal := i
> end;
>
> Ob das Standard-Pascal ist, weiß ich nicht...
sieht windig aus :-)
das ist ja sozusagen eine explizit implizite typanpassung :-)
wobei standard-pascal ja implizite typanpassung von integer nach real
erlaubt.
aber ICH WILL NICHT !!
Marco Schmidt
wrote:
>sieht windig aus :-)
>das ist ja sozusagen eine explizit implizite typanpassung :-)
>wobei standard-pascal ja implizite typanpassung von integer nach real
>erlaubt.
>aber ICH WILL NICHT !!
Suchst Du vielleicht ein explizites Typecasting, also z.B.
var
R: Real;
I: Integer;
begin
I := 2;
R := Real(I);
end;
Gruß,
Marco
michael paap
> Suchst Du vielleicht ein explizites Typecasting, also z.B.
>
> var
> R: Real;
> I: Integer;
> begin
> I := 2;
> R := Real(I);
> end;
>
> Gruß,
> Marco
genau das suche ich... geht das so?
achja: noch eine frage ähnlicher art:
kann ich mit sqrt auf einer integerzahl operieren? ist das ggf. auch
implizite typanpassung? wie koennte ich die vermeiden?
und: kann ich MOD mit einer realzahl ausführen? also z.b. y = 30.0 MOD
4... wohl eher nicht?
ARGS. überall lauern implizite typanpassungen....
HIILFEE.
michael paap
ich finde es ganz prima, dass man hier so schnell und ohne gemaule
geholfen bekommt.
ist ein anderer stil als in linux-groups :-)
wenn ich erst der held bin, mach ich das auch so.
danke!
michael paap
> var
> R: Real;
> I: Integer;
> begin
> I := 2;
> R := Real(I);
> end;
habs mal getestet: leider kein standarpascal :-(
Marco Schmidt
wrote:
>genau das suche ich... geht das so?
Eigentlich schon. Free Pascal kompiliert es, Delphi nicht. Hätte ich
nicht gedacht! Das Beispiel, das ich gegeben habe, ist aber
einigermaßen sinnlos, da bei Zuweisung eines Integerwert an eine
Realvariable der Wert automatisch vom Compiler konvertiert wird (oder
implizit angepaßt).
Ich verstehe noch nicht genau das Problem bei der Zeile
>if ganzeZahl (x / 2) = true then ....
Der Operator / führt automatisch dazu, daß reelle Werte benutzt
werden, die ganzzahlige Division klappt nur mit 'div'. Wenn Du
möchtest, daß der Compiler 2 als Realwert erkennt, kannst Du 2.0
schreiben. Da Deine Funktion GanzeZahl einen Real-Parameter bekommt,
ist die Konvertierung aber doch in Ordnung, oder? X durch zwei wird
mit Realzahlen durchgeführt und das Ergebnis an die Funktion
übergeben.
>achja: noch eine frage ähnlicher art:
>
>kann ich mit sqrt auf einer integerzahl operieren? ist das ggf. auch
>implizite typanpassung? wie koennte ich die vermeiden?
Die Funktion ist nur für einen Real-Parameter definiert. Möchtest Du
sie nur für Quadratzahlen verwenden? Wenn Du sqrt(x) aufrufst mit x
vom Typ Integer, wird die Zahl wieder implizit konvertiert.
>und: kann ich MOD mit einer realzahl ausführen? also z.b. y = 30.0 MOD
>4... wohl eher nicht?
Nein, das wird nicht akzeptiert, mod ist nur für ganzzahlige Werte
definiert. Mit Int und Frac läßt sich so etwas evtl. simulieren... Was
mathematische Funktionen angeht, solltest Du vielleicht mal bei SWAG
oder einer ähnlichen im Netz verfügbaren Codesammlung nach Matheunits
suchen, die gibt es im Überfluß.
Vielleicht hilft für Dein Problem auch schon die Funktion Frac aus der
System-Unit - sie gibt für eine Realzahl den Nachkommateil zurück. Ob
eine Realzahl auch als Integerzahl nutzbar ist, kann man dann evtl.
so prüfen:
X := reeller_wert;
if (Frac(X) = 0.0) then Write('ganzzahlig) else Write('reell');
Gruß,
Marco
Klaus Loerke
>erlaubt.
>aber ICH WILL NICHT !!
Wieso denn nicht? *dummfrag* Hast du Angst um die Portabilität des
programms? Wenn es das ist, würd ich o.g. Funktion verwenden und im
Falle eines Falles nur diese Funktion nachbessern. Ein Pascaldialekt,
der kein impl. Typcasting erlaubt, muß dann eine entsprechende Funktion
bereitstellen, die Du in intreal kapseln kannst.
so far, klausi
--
Data: (in "Die neutrale Zone")
"Beruf: Hausfrau, vermutlich hat sie Häuser gebaut"
Frederic
> > var
> > R: Real;
> > I: Integer;
> > begin
> > I := 2;
> > R := Real(I);
> > end;
>
> habs mal getestet: leider kein standarpascal :-(
Und auch kein Borland Pascal: "invalid type cast".
Frederic
> sieht windig aus :-)
> das ist ja sozusagen eine explizit implizite typanpassung :-)
Für Real -> Integer kann man runden oder einfach nur Nachkommastellen
abschneiden. Insofern ist das Real -> Integer kein echtes Type-casting
weil die Zahl ja explizit kastriert wird. Aber was willst du machen, um
von Integer auf Real zu kommen?
Ein Integer wird nicht kastriert wenn es in ein Real verwandelt wird, das
ist echtes Type-casting. Wie willst du echtes Type-Casting explizit
machen?
Ich fürchte du musst uns das noch mal genauer erklären.
Matthias Büchse
>if ganzeZahl (x / 2) = true then ....
... das "= true" ist eine Tautologie, da das Ergebnis dieser
"booleschen Operation" sowieso entweder true oder false ist.
Der Sprung (Abzweig) erfolgt, wenn das Ergebnis true ist, also
kann eine Überprüfung entfallen.
In der Hoffnung, nichts verwurschtelt zu haben,
MB
--
[ http://home.t-online.de/~Matthias.Buechse/ ] - [ Matthias...@T-Online.de ]
[ Homepage contents: About Me - TP,TASM,Delphi descriptions - My projects - ... ]
[ Homepage German only - vote for an English version; use my E-Mail above ]
Ing. Franz Glaser
Darf ich mich auch melden?
Ich mach das so:
R := 1.0*I;
Und schon kennen sich alle aus, der Compiler und alle, die das
Programm lesen. Das ist doch pfiffig, oder?
:-)
--
Franz Glaser, Glasau 3, A-4191 Vorderweissenbach Austria +43-7219-7035-0
Muehlviertler Elektronik Glaser. Industrial control and instrumentation
http://members.eunet.at/meg-glaser/ http://members.xoom.com/f_glaser/
http://www.geocities.com/~franzglaser/ http://start.at/bedarf
michael paap
"Ing. Franz Glaser" wrote:
> Darf ich mich auch melden?
> Ich mach das so:
> R := 1.0*I;
> Und schon kennen sich alle aus, der Compiler und alle, die das
> Programm lesen. Das ist doch pfiffig, oder?
he, aber WAS ist denn die ach so böse implizite typanpassung, wenn nicht
DAS?
michael (sich die haare raufend)
ps.: schlagt michnicht; ich WILL doch garkein standardpascal ohne
implizite typanweisungen schreiben. perlist viel lustiger... aber ich
muss.
Klaus Loerke
Ing. Franz Glaser schrieb in Nachricht <37D975DC...@eunet.at>...
>Frederic wrote:
>
>Darf ich mich auch melden?
>Ich mach das so:
> R := 1.0*I;
>Und schon kennen sich alle aus, der Compiler und alle, die das
>Programm lesen. Das ist doch pfiffig, oder?
aber auch da ist wieder (rein formal betrachtet) ein Typecasting drinne.
Bevor der Compiler scheinbar real und integer multipliziert, wird der
integer in einen real umgewandelt; obiger Source wird
höchstwahrscheinlich zu r:=i "optimiert"
Schade :-) Aber pfiffig war es... *verbeug* lol
Arsčne von Wyss
> R: Real;
> I: Integer;
> begin
> I := 2;
> R := Real(I);
> end;
Das akzeptiert nicht jeder Pascal-Compiler, denn ein Typecast ist
normalerweise nicht eine Umwandlung der Variable sondern eine
unterschiedliche Interpretation! Und einen Integer als Real zu
interpretieren ist demnach sinnlos, wenn die Zahl nicht konvertiert wird.
Was Du suchst ist INT, eine eingebaute Funktion die den Ganzzahligen Teil
einer beliebigen Fliesskommazahl liefert (das Gegenstück zu FRAC). Also
macht es das selbe wie TRUNC, liefert aber eine Fliesskommazahl zurück. Ob
es Standard-Pascal ist weiss ich aber auch nicht sicher.
--
Arsčne von Wyss - avon...@gmx.net
Pascal, Delphi & Personal stuff: http://bsn.ch/avonwyss
Programming Contest Problems Archive: http://bsn.ch/contest
Webmaster von Roger's Equine Pages: http://bsn.ch/pferde
Ing. Franz Glaser
>
> "Ing. Franz Glaser" wrote:
>
> > Darf ich mich auch melden?
> > Ich mach das so:
> > R := 1.0*I;
> > Und schon kennen sich alle aus, der Compiler und alle, die das
> > Programm lesen. Das ist doch pfiffig, oder?
>
> DAS?
>
> michael (sich die haare raufend)
Ja - ich wollte sie ja nicht vermeiden :-)
Horst Kraemer
wrote:
> Frederic wrote:
>
> > Ich sehe folgende Möglichkeit:
> >
> > function IntToReal(i: integer): real;
> > begin
> > IntToReal := i
> > end;
> >
> > Ob das Standard-Pascal ist, weiß ich nicht...
>
> sieht windig aus :-)
> das ist ja sozusagen eine explizit implizite typanpassung :-)
Nein, eine implizite, genau wie bei einer Zuweisung eines Integer an
einen Real.
> wobei standard-pascal ja implizite typanpassung von integer nach real
> erlaubt.
> aber ICH WILL NICHT !!
...schrie das Baby und spuckte der Mama den Brei ins Gesicht ;-)
MfG
Horst
Horst Kraemer
wrote:
> hallo, ich habe folgendes problem (alles NUR in standardpascal):
>
> ich möchte eine
> function istPrim (x:integer): boolean
> definieren. diese function benutzt ihrerseits eine
> function ganzeZahl (x:real): boolean.
> nun soll z.b. istPrim folgendes aufrufen:
>
> if ganzeZahl (x / 2) = true then ....
Hier schreibt man
if ganzeZahl (x / 2) then ....
Aber so ein Aufruf ist voellig ueberfluessig.
Um zu testen, ob integer/2 eine ganze Zahl ist, reicht es, zu testen
ob integer eine gerade Zahl ist, also
if not odd(x) then
Der Uebergangs zu Reals ist voellig unnoetig und Dein Problem faellt
wegen Nichtvorhandensein unter den Tisch.
> normalerweise wuerde jetzt eine implizite typanpassung erfolge, also x
> durch x.0 ersetzt werden, und das ergebnis waere real, also alles in
> ordnung.
> nun will/soll ich aber die implizite typanpassung vermeiden...
Warum ?
> gibt es eine möglichkeit, diese explizit auszuführen, also so etwas wie
> eine funktion, die z.b. den integerwert 2 in den realwert 2.0 überführt:
Nein. Explizite "typecasts" gibt es in Standard-Pascal nicht.
Man kann es z.B. per
i+0.0
simulieren. Aber dies ist auch nur Schein, da ja eine implizite
Typanpassung _vor_ der Addition von 0.0 stattfindet.
Mit einer Kaffeemaschine kann man keinen Rasen maehen.
MfG
Horst
Horst Kraemer
wrote:
> Marco Schmidt wrote:
>
> > Suchst Du vielleicht ein explizites Typecasting, also z.B.
> >
> > var
> > R: Real;
> > I: Integer;
> > begin
> > I := 2;
> > R := Real(I);
> > end;
> >
> > Gruß,
> > Marco
>
> genau das suche ich... geht das so?
Nein, In Standard-Pascal nicht.
> achja: noch eine frage ähnlicher art:
>
> kann ich mit sqrt auf einer integerzahl operieren? ist das ggf. auch
> implizite typanpassung?
Ja. sqrt verlangt und erhaelt einen Real und gibt einen Real zurueck.
> wie koennte ich die vermeiden?
Indem Du persoenlich eine Ineger-sqrt-Funktion schreibst.
Eine primitive, uebersichtliche, die weder Multiplikationen noch
Divisionen verwendet ist diese:
function isqrt(i:integer):integer;
{
gibt die groesste ganze Zahl zurueck, deren Quadrat
nicht groesser als i ist.
}
var
n,x:integer;
begin
n:=0;
x:=1;
while x<=i do begin
n:=succ(n);
x:=succ(x)+n+n;
end;
isqrt:=n
end;
(Es gibt erheblich schnellere, aber bei denen braucht man drei Tage,
um zu verstehen, warum sie funktioniert, wenn man sie zum ersten mal
sieht).
Genau solch eine brauchst Du als Grenzwert fuer das Primzahlsieb, wenn
ich mal raten darf.
> und: kann ich MOD mit einer realzahl ausführen? also z.b. y = 30.0 MOD
> 4... wohl eher nicht?
Nee. Warum nicht 40 MOD 4 ?
MfG
Horst
Horst Kraemer
wrote:
> hallo leute,
>
> ich finde es ganz prima, dass man hier so schnell und ohne gemaule
> geholfen bekommt.
> ist ein anderer stil als in linux-groups :-)
Wer deutsche Linux-Gruppen liest, muss ein Masochist sein. So viele
arrogante A**** auf einen Schlag sind mir noch nirgends begegnet.
MfG
Horst
Ing. Franz Glaser
> >
> >Darf ich mich auch melden?
> >Ich mach das so:
> > R := 1.0*I;
> >Und schon kennen sich alle aus, der Compiler und alle, die das
> >Programm lesen. Das ist doch pfiffig, oder?
>
> Bevor der Compiler scheinbar real und integer multipliziert, wird der
> integer in einen real umgewandelt; obiger Source wird
> höchstwahrscheinlich zu r:=i "optimiert"
>
> Schade :-) Aber pfiffig war es... *verbeug* lol
Ich habe mehrmals in meinen Programmen Probleme mit dieser
dämlichen Real/Integer - Geschichte gehabt. Ich speichere gern
die Preise oder irgendwelche Rezeptwerte als Integer mit einem
"geheimen" Dezimalpunkt. Und da stellt es die Maschine schon beim
Writeln(0.0001*Prx*Menge:10:2) vor dieses Problem. Es gibt keine
"explizitere" Typumwandlung, zumindest mit dem TP 6 habe ich keine
gefunden. Es hängt auch damit zusammen, daß ich manchmal eben
wirklich 2 Integer dividieren möchte, aber ein Real - Ergebnis
will: R := 1.Ü*B/(1.0*C) oder so ähnlich, das gibt's doch einfach,
daß man das braucht, nicht wahr. Und da es keine Funktion gibt,
nehme ich das 1.0*I dafür. Ich habe das wirklich als "explizit"
gesehen, weil ich nix anderes, expliziteres gefunden habe.
MfG
Frederic
> Was Du suchst ist INT, eine eingebaute Funktion die den Ganzzahligen Teil
> einer beliebigen Fliesskommazahl liefert (das Gegenstück zu FRAC). Also
> macht es das selbe wie TRUNC, liefert aber eine Fliesskommazahl zurück.
Aber int akzeptiert als Parameter auch einen Integer, wobei der Compiler das
Integer bei der Übergabe implizit in ein Real umwandelt. Also wieder
impliziter type-cast.
Klaus Loerke
Ing. Franz Glaser schrieb in Nachricht <37DA3769...@eunet.at>...
>
>Ich habe mehrmals in meinen Programmen Probleme mit dieser
>dämlichen Real/Integer - Geschichte gehabt. Ich speichere gern
>die Preise oder irgendwelche Rezeptwerte als Integer mit einem
>"geheimen" Dezimalpunkt. Und da stellt es die Maschine schon beim
>Writeln(0.0001*Prx*Menge:10:2) vor dieses Problem. Es gibt keine
>"explizitere" Typumwandlung, zumindest mit dem TP 6 habe ich keine
>gefunden. Es hängt auch damit zusammen, daß ich manchmal eben
>wirklich 2 Integer dividieren möchte, aber ein Real - Ergebnis
>will: R := 1.Ü*B/(1.0*C) oder so ähnlich, das gibt's doch einfach,
>daß man das braucht, nicht wahr. Und da es keine Funktion gibt,
>nehme ich das 1.0*I dafür. Ich habe das wirklich als "explizit"
>gesehen, weil ich nix anderes, expliziteres gefunden habe.
gut, seh ich ein... Und ist sogar schneller als die verkappte
explizit-implizit-Funktion, die hier schon nen paar mal rumgeisterte...
;-)
so far, klausi
Wolf Behrenhoff
> nun will/soll ich aber die implizite typanpassung vermeiden...
> gibt es eine möglichkeit, diese explizit auszuführen, also so etwas wie
> eine funktion, die z.b. den integerwert 2 in den realwert 2.0 überführt:
>
> intreal (2) = 2.0 ?
> umgekeht waere es ja trunc ...
Hallo!
Eine einfache, aber _sehr_ _sehr_ _sehr_ sehr_ langsame Möglichkeit ist
diese:
program SlowIntToReal;
function IntToReal(i: Integer): Real;
var
ii: Integer;
Istep: Integer;
RStep: Real;
Ergebnis: Real;
begin
if i>0 then begin
IStep:=1;
RStep:=1.0
end else begin
IStep:=-1;
RStep:=-1.0
end;
ii:=0;
Ergebnis:=0;
while ii<>i do begin
Ergebnis:=Ergebnis+RStep;
ii:=ii+Istep;
end;
IntToReal:=Ergebnis;
end;
begin
WriteLn(IntToReal(-5));
end.
mfg
Wolf
Willi Marquart
>hallo, ich habe folgendes problem (alles NUR in standardpascal):
>
>ich möchte eine
>function istPrim (x:integer): boolean
>definieren. diese function benutzt ihrerseits eine
>function ganzeZahl (x:real): boolean.
>nun soll z.b. istPrim folgendes aufrufen:
>
>if ganzeZahl (x / 2) = true then ....
>
Wofuer denn dieser Umstand? Wenn Du herausfinden willst, ob x gerade
ist, wie waers dann mit
if not odd(x) then ...
Da wird dann auch nichts implizit typumgewandelt sondern auf
x and 1 = 1 getestet.
Gruss Willi
Klaus Loerke
Wolf Behrenhoff schrieb in Nachricht <37DA53D5...@gmxY.net>...
>[Umwandlung mit schleife]
ich hätte noch sowas im Ärmel: ;-)
function int2real(i:integer):real;
var s:string;
result:real;
code:integer;
begin
str(i,s);
val(s,result,code);
intreal:=result;
end;
äääh, was wollt ihr denn mit den weißen Westen mit den langen Ärmeln...
hiiiiiiilfe...
;-)
so far, klausi
Wilfried Kramer
<m.p...@gmx.de> für alle:
>Frederic wrote:
>
>> Ich sehe folgende Möglichkeit:
>>
>> function IntToReal(i: integer): real;
>> begin
>> IntToReal := i
>> end;
>>
>> Ob das Standard-Pascal ist, weiß ich nicht...
>
>sieht windig aus :-)
>das ist ja sozusagen eine explizit implizite typanpassung :-)
>wobei standard-pascal ja implizite typanpassung von integer nach real
>erlaubt.
>aber ICH WILL NICHT !!
>
Dann hast Du leider *Pech* gehabt. AFAIK *muß* der Compiler hier eine
Typen-Konversion vornehmen. Sonst ist es kein Pascal. Integer ist lt.
Definition zu einem Real zuweisungskompatibel (oder andersrum?). Auf
jeden Fall kann man immer eine ganze Zahl eine Real-Variablen
zuweisen.
Einzige Ausnahme könnte ein Überlauf sein, wenn also die Zahl nicht in
einen Real paßt. Ist aber eher unwahrscheinlich.
Was konkret stört Dich denn an der Umwandlung? Wenn Du die Zuweisung
machen willst, dann mußt Du doch den gleichen Programmcode verfassen,
den der Compiler freiwillig generiert.
>michael
Gruß
Wilfried (aus Hamburg)
--
Wer eMail-Adressen nachmacht oder verfälscht oder nachgemachte
oder verfälschte Adressen sich verschafft und in Umlauf bringt
wird mit ... nicht unter ... bestraft
michael paap
soeben hat mir jemand in einer newsgroup der fernuni-hagen, erklärt, wie
sich das gehört. und da es so gut aussieht, und weil gleichzeitig noch
eine nette lösung für ein anderes problemchen drinsteht, will ich euch
das posting nicht vorenthalten:
ich hatte sowas gestrickt:
repeat
if (x MOD i = 0) then
begin
done := true; { sorgt für Ende der while-Schleife,
da ein Teiler gefunden wurde}
istPrim := false
end;
i := i + 2
until (i > sqrt (i)) or (done = true);
(btw: sehe ich das richtig, das vor "until" kein ";" stehen muss?
logisch wär`s ja ...)
Herr Lange schrieb:
> Lieber Herr Paap,
>
> (1) Standard-Pascal kennt in der Tat keine Funktionen fuer explizite
> Typanpassungen. Auch chr, ord, trunc und round (siehe den Beitrag von
> Herrn Schimanko unten) sind keine solchen Funktionen, auch wenn ihr
> Werte-Typ ein anderer ist als der Argument-Typ - sie passen nicht
> einfach den Typ an, sondern machen etwas anderes.
>
> (2) Typanpassung kann erforderlich sein und deshalb nicht verboten
> werden - was der Kursbetreuer ja auch nicht tut (siehe seinen
> Beitrag).
>
> (3) Um die Verstaendlichkeit der Programme zu erhoehen und Fehler zu
> vermeiden, empfehle ich (allen Ernstes, auch wenn es aufwendig ist!),
> die implizite Typanpassung - ausser im trivialen Fall der Anpassung
> von einem Unterbereichstyp zum Wirtstyp - in Zuweisungen
> unterzubringen, um sie auffaellig zu machen. Bei Ihnen kommen ja z.B.
> ZWEI Typanpassungen vor, beim x und beim i, war Ihnen das klar? Also
> hier zusaetzliche Variablen
> iReal, xReal : real
> deklarieren und am Ende der Schleife einfuegen:
> iReal := i;
> xReal := x
>
> (4) Die Verwendung von real-Variablen ist sehr problematisch. Woher
> wissen Sie z.B., dass die Wurzel aus 4 nicht 1.99999999999 ergibt und
> kleiner als 2 ist?
>
> (5) Sie koennen sich den Uebergang zum Typ real aber sparen, indem Sie
> Ihre Bedingung i > sqrt (x) etwas geschickter formulieren:
> i > x div i
> Das kommt nicht nur der Forderung des Kursbetreuers nach, sondern ist
> m.E. die rundum angemessenere Programmierung. Dass diese Bedingungen
> aequivalent sind, kostet eine kleine mathematische Ueberlegung...
>
>
> Mit freundlichem Gruss
> Wilfried Lange
michael
Winfried Borchardt
michael paap schrieb:
> repeat
> if (x MOD i = 0) then
> begin
> done := true; { sorgt für Ende der while-Schleife,
> da ein Teiler gefunden wurde}
> istPrim := false
> end;
> i := i + 2
> until (i > sqrt (x)) or (done = true);
Warum soll ein Problem. was nur mit ganzen Zahlen zu tun hat,
mit Reals arbeiten.
until (i * i > x) or (done = true);
> (btw: sehe ich das richtig, das vor "until" kein ";" stehen muss?
> logisch wär`s ja ...)
; trennt Anweisungen.
> Herr Lange schrieb:
>
> > (5) Sie koennen sich den Uebergang zum Typ real aber sparen, indem Sie
> > Ihre Bedingung i > sqrt (x) etwas geschickter formulieren:
> > i > x div i
Warum teilen? Nachdenken: da x div i abrundet, ... , durch 0 teilen, ...
Ing. Franz Glaser
> until (i > sqrt (i)) or (done = true);
Michael,
darf ich da was sagen, obzwar es gar nix mit dem Thema zu tun hat.. :-)
was ist der "implizite" Unterschied zwischen
done = true
und
done
Ehrlich gesagt, das tut mir auf meinem formallogischen Weisheitszahn
weh, sonst nix.
;-))
Klaus Loerke
michael paap schrieb in Nachricht <37DE2071...@gmx.de>...
>
>ich hatte sowas gestrickt:
>
> repeat
> if (x MOD i = 0) then
> begin
> done := true; { sorgt für Ende der while-Schleife,
> da ein Teiler gefunden wurde}
> istPrim := false
> end;
> i := i + 2
>
*määäääp* auch da ist wieder mindestens eine implizites Typcasting
drinne! "i>sqrt(i)" Hier werden ganz eindeutig Äpfel (in Form eines
Integers) mit Birnen (aka Real) verglichen.
;-)
so far, klausi
Wilfried Kramer
<klaus....@muenster.de> für alle:
Mal ganz davon abgesehen, daß bereits sqrt(i) so etwas erzeugt :-)
Wenn man so was vermeiden will, dann ist die Lösung /ganz einfach/:
Real-Variablen sowie alle Funktionen mit diesen Typen als
Argument/Ergebnis sind einfach tabu.
>
>so far, klausi
michael paap
"Ing. Franz Glaser" wrote:
> Ehrlich gesagt, das tut mir auf meinem formallogischen Weisheitszahn
> weh, sonst nix.
schon recht :-)
michael paap
function istPrim (x:tNatZahlPlus): boolean;
var
i : integer;
done : boolean;
begin
istPrim := true; { Initialisierung }
if x > 3 then { x <= 3 wird im else-Zweig behandelt }
if x MOD 2 = 0 then { x durch 2 teilbar? --> false }
istPrim := false
else
begin { alle ungeraden Zahlen von Drei an aufsteigend, solange
sie nicht > wurzel (x) sind, als mögliche teiler pruefen }
done := false;
i := 3;
repeat
if (x MOD i = 0) then
begin
done := true; { sorgt für Ende der while-Schleife,
da ein Teiler gefunden wurde}
istPrim := false
end;
i := i + 2
until (i > x div i) or (done = true)
end
else { also wenn x <= 3 }
if x < 2 then
istPrim := false { wenn x = 2 oder x = 3, bleibt es bei
dem "true" der Initialisierung }
end; { istPrim }
Winfried Borchardt
> Es hängt auch damit zusammen, daß ich manchmal eben
> wirklich 2 Integer dividieren möchte, aber ein Real - Ergebnis
> will: R := 1.0*B/(1.0*C) oder so ähnlich, das gibt's doch einfach,
> daß man das braucht, nicht wahr.
Division (/) geht in Pascal nur mit Real Typen. Also hier 1.0 * B
"formallogisch" ueberfluessig.
Anders bei *:
R = B * C
und
R = (1.0 * B) * (1.0 * C)
koennen unterschiedliche Ergebnisse liefern (wenn ein Ueberlauf bei B*C
auftritt).
Ing. Franz Glaser
Ha? Wia? ???
Winfried Borchardt
> > Anders bei *:
> > R = B * C
> > und
> > R = (1.0 * B) * (1.0 * C)
> > koennen unterschiedliche Ergebnisse liefern (wenn ein Ueberlauf bei B*C
> > auftritt).
>
> Ha? Wia? ???
var r : real;
b , c : integer;
begin
b := 256;
c := 256;
r := b * c;
writeln (r); {0}
r := (1.0 * b) * (1.0 * c);
writeln (r); {65536}
end.
Ing. Franz Glaser
Hätte da nicht auch R := 1.0*B*C gereicht? Oder B*1.0*C. Das war es,
was ich gemeint habe mit dem "wie bitte?" :-)
Matthias Büchse
>> logisch wär`s ja ...)
>
>; trennt Anweisungen.
procedure Nop; assembler; {Bitte mache einer ein Inline daraus, das ist weit
effizienter ...}
asm
cli
end;
begin
repeat Nop until false;
end.
xyz gehört zur Repeat-"Anweisung" und braucht deshalb kein Semikolon.
Wilfried Kramer
<meg-g...@eunet.at> für alle:
>Winfried Borchardt wrote:
>>
>
>Hätte da nicht auch R := 1.0*B*C gereicht? Oder B*1.0*C. Das war es,
>was ich gemeint habe mit dem "wie bitte?" :-)
Die erste Variante ist noch Compiler-abhängig in der Auswertung. Wenn
zuerst B*C gebildet wird, dann *kann* das ja noch als
Integer-Arithmetik laufen. Bei der zweiten Variante muß der Compiler
erst einmal eine Wandlung durchführen.
Horst Kraemer
<WHDK...@POBoxes.com> wrote:
> Am Wed, 15 Sep 1999 19:08:14 +0200 schrieb "Ing. Franz Glaser"
> <meg-g...@eunet.at> für alle:
>
> >Winfried Borchardt wrote:
> >>
> >
> >Hätte da nicht auch R := 1.0*B*C gereicht? Oder B*1.0*C. Das war es,
> >was ich gemeint habe mit dem "wie bitte?" :-)
>
> Die erste Variante ist noch Compiler-abhängig in der Auswertung. Wenn
> zuerst B*C gebildet wird, dann *kann* das ja noch als
> Integer-Arithmetik laufen. Bei der zweiten Variante muß der Compiler
> erst einmal eine Wandlung durchführen.
Was der Compiler muss oder nicht muss. ist nicht in sein Belieben
gestellt - es sei denn, die Definition der Programmiersprache laesst
die Ausfuehrungsreihe offen.
Lt. Pascal-Standard gilt:
Sequences of operators of the same precedence are executed from left
to right.
(Zumindest fuer C und Fortran gilt dies ebenso).
D.h.
1.0*i*j
bedeutet. dass dieser Ausdruck als
(1.0*i)*j
_ausgefuehrt_ und nie als.
1.0*(i*j)
Dies reflektiert die Binsenweisheit, dass z.B. + und * zwar
mathematisch assoziativ sind, aber nicht assoziativ innerhalb der
Computerarithmetik - insbesondere deswegen, weil noch implizite
Typanpassungen vorkommen koennen. Daher darf sich auch der Compiler
nicht die Freiheit nehmen, eine nichtvorhandene Assoziativitaet
anzunehmen.
Dies wird haeufig mit _Auswertungsreihenfolge_ der Operanden eines
binaeren Operators verwechselt.
Der Compiler darf bei
a*b*c
zuerst c auswerten und dann erst (a*b) oder umgekehrt und auch
innerhalb von (a*b) darf er sich aussuchen, ob er den Ausdruck a oder
den Ausdruck b zuerst auswertet. Wenn z.B. a,b,c Funktionsaufrufe
sind, die ihren Namen auf den Bildschirm schreiben, ist jede der
folgenden Reihenfolgen moeglich
abc
bac
cab
cba
Dies und nur dies ist in diesem Zusammenhang compilerabhaengig alias
'unspezifiert'.
MfG
Horst
Winfried Borchardt
Horst Kraemer schrieb:
> > >Hätte da nicht auch R := 1.0*B*C gereicht? Oder B*1.0*C. Das war es,
> > >was ich gemeint habe mit dem "wie bitte?" :-)
> >
> > Die erste Variante ist noch Compiler-abhängig in der Auswertung. Wenn
> > zuerst B*C gebildet wird, dann *kann* das ja noch als
> > Integer-Arithmetik laufen. Bei der zweiten Variante muß der Compiler
> > erst einmal eine Wandlung durchführen.
>
> Was der Compiler muss oder nicht muss. ist nicht in sein Belieben
> gestellt - es sei denn, die Definition der Programmiersprache laesst
> die Ausfuehrungsreihe offen.
>
> Lt. Pascal-Standard gilt:
>
> Sequences of operators of the same precedence are executed from left
> to right.
>
> ....
>
> Dies reflektiert die Binsenweisheit, dass z.B. + und * zwar
> mathematisch assoziativ sind, aber nicht assoziativ innerhalb der
> Computerarithmetik - insbesondere deswegen, weil noch implizite
> Typanpassungen vorkommen koennen. Daher darf sich auch der Compiler
> nicht die Freiheit nehmen, eine nichtvorhandene Assoziativitaet
> anzunehmen.
>
> Dies wird haeufig mit _Auswertungsreihenfolge_ der Operanden eines
> binaeren Operators verwechselt.
>
> Der Compiler darf bei
>
> a*b*c
>
> zuerst c auswerten und dann erst (a*b) oder umgekehrt und auch
> innerhalb von (a*b) darf er sich aussuchen, ob er den Ausdruck a oder
> den Ausdruck b zuerst auswertet. Wenn z.B. a,b,c Funktionsaufrufe
> sind, die ihren Namen auf den Bildschirm schreiben, ist jede der
> folgenden Reihenfolgen moeglich
>
> abc
> bac
> cab
> cba
>
> Dies und nur dies ist in diesem Zusammenhang compilerabhaengig alias
> 'unspezifiert'.
Sequences of operators of the same precedence are executed from left
to right.
Bedeutet doch, was mit a / b / c gemeint sein soll. Hier ist (a / b) / c
und a / (b / c)
nicht gleich. Mit Assoziativitaet hat das noch nichts zu tun.
Horst Kraemer
<w.bor...@daetwyler-graphics.ch> wrote:
> Sequences of operators of the same precedence are executed from left
> to right.
>
> Bedeutet doch, was mit a / b / c gemeint sein soll. Hier ist (a / b) / c
> und a / (b / c)
> nicht gleich. Mit Assoziativitaet hat das noch nichts zu tun.
Hat niemand behauptet. Die Programmiersprache definiert, dass a/b/c
als (a/b)/c und nicht als a/(b/c) interpretiert wird.
Manche befuerchten aus mir nicht bekannten Gruenden, dass a*b*c als
a*(b*c) ausgefuehrt werde koennte - vielleicht weil _sie_ glauben,
dass der Compiler "Wissen" um die Assoziativitaet der mathematischen
Operation * ausnutzen koennte, oder warum auch immer.
Genau auf diese hier geaeusserte Befuerchtung habe ich geantwortet.
Die Ausfuehrungsreihenfolge von a*b*c ist _nicht_ compilerabhaengig.
MfG
Horst
Gottfried Helms
...
>
> procedure Nop; assembler; {Bitte mache einer ein Inline daraus, das ist weit
> effizienter ...}
> asm
> cli
> end;
>
> begin
> repeat Nop until false;
> end.
Besser geht's nicht. Diese Perlen des Programmierers!
:-)
Gottfried.