Softpicks.Net Deutsch

[Karl Donaubauer]

Ulrich Haarmeyer wrote:
> Ich erstelle folgende Funktion :
>
> Private Function ZeigeText(intNr as Integer) as String
> Dim strText(0 to 2) as String
> strText(1)="irgendwas"
> strText(2)="irgendwas anderes"
> Zeigetext=IIF(intNr<3,strText(intNr),"")
> End Function
>
> Ruf ich die Funktion auf und übergebe den Wert 3, erhalte ich einen "Index
> außerhalb des gültigen Bereich"-Fehler.
> Offensichtlich verarbeitet die IIF-Funktion den Truepart auch dann, wenn
> die Bedingung False liefert.
> Sieht mir nach einem Bug aus.

Sieht mir danach aus, als habe da jmd. die Doku nicht gelesen.
S. <F1> zur Iif-Funktion, in der dieses Verhalten beschrieben ist.

--
HTH
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com

.

Ulrich Haarmeyer wrote:

> Ich erstelle folgende Funktion :
>
> Private Function ZeigeText(intNr as Integer) as String
> Dim strText(0 to 2) as String
> strText(1)="irgendwas"
> strText(2)="irgendwas anderes"
> Zeigetext=IIF(intNr<3,strText(intNr),"")
> End Function
>
> Ruf ich die Funktion auf und übergebe den Wert 3, erhalte ich einen
> "Index außerhalb des gültigen Bereich"-Fehler.
> Offensichtlich verarbeitet die IIF-Funktion den Truepart auch dann,
> wenn die Bedingung False liefert.
> Sieht mir nach einem Bug aus.

Naa, das ist/war schon immer so.

Die Hilfe sagt:
IIf wertet immer sowohl den Teil truepart als auch den Teil falsepart aus,
auch dann, wenn nur einer von beiden Teilen zurückgegeben wird.
Aus diesem Grund kann es zu unerwünschten Nebeneffekten kommen.
Wenn z.B. die Auswertung von falsepart zu einem Fehler aufgrund
einer Division durch Null führt, tritt ein Fehler auch dann auf,
wenn expr den Wert True hat.


Da sollte man halt nehmen:

If intNr < 3 Then ZeigeText1 = strText(intNr) Else ZeigeText1 = ""

Gruß


.

[Karl Donaubauer]

Ulrich Haarmeyer wrote:
> "Jörg Ackermann schrieb:
> ....
>> Die Hilfe sagt:
>> IIf wertet immer sowohl den Teil truepart als auch den Teil falsepart
>> aus, auch dann, wenn nur einer von beiden Teilen zurückgegeben wird.
>> Aus diesem Grund kann es zu unerwünschten Nebeneffekten kommen.
>> Wenn z.B. die Auswertung von falsepart zu einem Fehler aufgrund
>> einer Division durch Null führt, tritt ein Fehler auch dann auf,
>> wenn expr den Wert True hat.
>
> Ich muß zugeben, die OH dazu noch nicht gelesen zu haben.
> Konnte mir allerdings nicht vorstellen, das es beabsichtigt ist.
> Macht zumindestens keinen Sinn, denn eine Bedingung die Wahr
> oder Falsch liefert, kann unmöglich etwas liefern, das beides zutrifft.
> Von daher ist es unlogisch, beide Teile auszuwerten.
> Aber naja, man kann eben nich alles verstehen.

Ach, die Welt ist doch nicht nur 0 oder 1 sondern beides und
alles dazwischen.

> Danke für euro Infos.

Vielleicht noch ergänzend, weil das oft zu Missverständnissen führt:

Was in der OH nicht erwähnt wird, ist, dass dieses Verhalten nur für
VBA-Code gilt. Wenn Wenn, ähh Iif, durch den Expression Service geht,
also an der Access-Oberfläche in Abfragen, Steuerelementinhalten etc.,
dann wird nur der zutreffende Teil ausgewertet. Dort gibt's also keine
Gefahr für Divisionen durch 0 etc. aus diesem Titel.

--
cu
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com

.

Ulrich Haarmeyer wrote:

> Ich muß zugeben, die OH dazu noch nicht gelesen zu haben.

Wer liest das Zeugs schon je komplett... ;-)

> Konnte mir allerdings nicht vorstellen, das es beabsichtigt ist.
> Macht zumindestens keinen Sinn, denn eine Bedingung die Wahr oder
> Falsch liefert,
> kann unmöglich etwas liefern, das beides zutrifft. Von daher ist es
> unlogisch, beide Teile auszuwerten.
> Aber naja, man kann eben nich alles verstehen.

Eigentlich schon logisch.

IIf ist eine Funktion mit drei Parametern, wobei
die Werte vor Übergabe ermittelt werden müssen.
Es gibt keine Vielleicht-Übergabe.
Scheitert das, gibt es einen entsprechenden
Fehler.

Wäre vielleicht eine Anregung für Office 13:

ByVal,
ByRef,
BySuccess,
ByFailure...

oder vielleicht:

IIF([Expression], ByLuck Truepart, ByLuck Falsepart) ;-)

Grruß

.

[Michael Zimmermann]

Hallo!

Ulrich Haarmeyer:
> Ich erstelle folgende Funktion :
>
> Private Function ZeigeText(intNr as Integer) as String
> Dim strText(0 to 2) as String
> strText(1)="irgendwas"
> strText(2)="irgendwas anderes"
> Zeigetext=IIF(intNr<3,strText(intNr),"")
> End Function

Ergänzend zu den Erklärungen, die Du bisher bekommen hast,
noch ein Hinweis zur Performance:

Iif innerhalb VB(A)-Prozeduren benötigt etwa 600% der
Laufzeit eines entsprechenden If ... Then ... Else ...

In Schleifen oder generischen Funktionen sollte man es
daher tunlichst vermeiden.

Als Einzelanweisung mag es aus Schreibfaulheit gelegentlich
durchgehen, aber im Grunde hat das Igitt-If in VB(A) meines
bescheidenen Dafürhaltens nichts verloren.

Gruß aus Mainz
Michael

.

[Lars P. Wolschner]

"Karl Donaubauer" <NoSpam [at] donkarl.com>:

> Ulrich Haarmeyer wrote:

>> Ich erstelle folgende Funktion :
>>
>> Private Function ZeigeText(intNr as Integer) as String
>> Dim strText(0 to 2) as String
>> strText(1)="irgendwas"
>> strText(2)="irgendwas anderes"
>> Zeigetext=IIF(intNr<3,strText(intNr),"")
>> End Function
>>
>> Ruf ich die Funktion auf und übergebe den Wert 3, erhalte ich
>> einen "Index außerhalb des gültigen Bereich"-Fehler.
>> Offensichtlich verarbeitet die IIF-Funktion den Truepart auch
>> dann, wenn die Bedingung False liefert.
>> Sieht mir nach einem Bug aus.
>
> Sieht mir danach aus, als habe da jmd. die Doku nicht gelesen.
> S. <F1> zur Iif-Funktion, in der dieses Verhalten beschrieben
> ist.

Doku? In der blöden Online-Hilfe wird ja nicht mal mitgeteilt, daß
boolesche Ausdrücke blödsinnigerweise immer vollständig evaluiert
werden, obwohl die meisten Programmiersprachen dem vernünftigen
Prinzip der lazy Evaluation folgen. Auch im Access-Handbuch wird
dieser wichtige Unterschied nicht erläutert.

CU
--
Lars P. Wolschner lars.wolschner [at] nexgo.de
Bernardstraße 11b lars.wolschner [at] gmx.de
D-63067 Offenbach am Main
Fon & Fax: +49 69 80068670 Mobil: +49 163 8122462 (eplus)
.

[Lars P. Wolschner]

Gerald Aichholzer <gary [at] sbox.tugraz.at>:

> Lars P. Wolschner wrote:

>> "Karl Donaubauer" <NoSpam [at] donkarl.com>:

>>> Sieht mir danach aus, als habe da jmd. die Doku nicht gelesen.
>>> S. <F1> zur Iif-Funktion, in der dieses Verhalten beschrieben
>>> ist.
>>
>> Doku? In der blöden Online-Hilfe wird ja nicht mal mitgeteilt,
>> daß boolesche Ausdrücke blödsinnigerweise immer vollständig
>> evaluiert werden, obwohl die meisten Programmiersprachen dem
>> vernünftigen Prinzip der lazy Evaluation folgen. Auch im
>> Access-Handbuch wird dieser wichtige Unterschied nicht
>> erläutert.
>
> dein Argument trifft hier nicht zu, denn Iif ist (wie bereits
> an anderer Stelle in diesem Thread erwähnt) eine Funktion (!).

Natürlich nicht, denn da habe ich gar nicht gegenargumentiert. Es
wäre blöde, wenn es anders wäre.

Für Boolesche Ausdrücke gilt das allerdings nicht; da ist es schon
allein deshalb blöde, weil sonst lazy Evaluation gilt. So muß man
nun in VBA Kontrollstrukturen schachteln.
Noch blöder ist es, diese Überraschung nicht in die Online-Hilfe zu
schreiben. Im Access-Handbuch von Microsoft steht übrigens auch
nichts davon. Überhaupt fehlen an vielen Stellen der Online-Hilfe
elementare fachliche Informationen, obwohl manchmal durchaus viel
Text erscheint. Oft sind die Informationen aber auch veraltet.
Diejenigen, die das abgefaßt haben, sind nicht kompetent.

> Wenn du eine Funktion schreibst, die drei Parameter erwartet,
> dann werden alle drei vor dem Aufruf dieser Funktion ausge-
> wertet.

Klar.

CU
--
Lars P. Wolschner lars.wolschner [at] nexgo.de
Bernardstraße 11b lars.wolschner [at] gmx.de
D-63067 Offenbach am Main
Fon & Fax: +49 69 80068670 Mobil: +49 163 8122462 (eplus)
.

[Michael Zimmermann]

Hallo!

Lars P. Wolschner:
> Natürlich nicht, denn da habe ich gar nicht
> gegenargumentiert. Es wäre blöde, wenn es anders wäre.

Welch grobe Sprache! Und das, obwohl möglicherweise Damen
mitlesen. Wir sind doch hier nicht in m.p.d.g.windows*.*
sondern in der freundlichsten Kuschelgruppe der
MS-Hierarchie. ;-)

> Für Boolesche Ausdrücke gilt das allerdings nicht; da ist
> es schon allein deshalb blöde, weil sonst lazy Evaluation
> gilt.

Wenn ich Dir mit der Annahme, Du spielest darauf an, daß
bei logischen Operatoren immer beide Boolschen Ausdrücke
ausgewertet werden, nichts Falsches unterstelle, so hat
das auch seine Vorteile.

Daß in

Ausdruck1 Or Ausdruck2

wenn Ausdruck1 wahr ist, Ausdruck2 überhaupt noch
ausgewertet wird, mag vordergründig unsinnig erscheinen,
da /vermeintlich/ der Gesamtausdruck in jedem Fall wahr
werden müsse.

Es gibt aber durchaus etwas, das hierbei zwar nicht logisch,
aber algorithmisch stärker als Wahr ist, nämlich ein
Laufzeitfehler.

Daß If x<y Or x/0=7 auch wenn x kleiner als y ist, umgehend
einen Fehler verursacht, ist *gut*. Ich bemerke den Unfug,
den ich verzapft habe, dann sofort und nicht erst beim
Kunden, wo durch einen seltene Datenkonstellation die
erste Bedingung zum ersten Mal nicht zutrifft.

> So muß man nun in VBA Kontrollstrukturen schachteln.
^^^
"*Kann*" muß es heißen. Damit kannst Du das gewünschte
Verhalten ja problemlos und auch ohne Performance-Einbußen
nachstellen.

> Noch blöder ist es, diese Überraschung nicht in die
> Online-Hilfe zu schreiben.

Das Verhalten der logischen Operatoren ist aber m. W.
dokumentiert. Ich benutze die OH zwar nur noch selten;
das habe ich aber auch als weniger erfahrener Programmierer
schon gewußt, und dann muß es irgendwo gestanden haben.

> Überhaupt fehlen an vielen Stellen der Online-Hilfe
> elementare fachliche Informationen, obwohl manchmal
> durchaus viel Text erscheint.

Daß die OH nach 97 ihren Benutzer nicht gerade wie einen
König behandelt, steht außer Frage.

Aber: Eine OH erklärt die Syntax eines Programmes. Die
*fachlichen* Informationen sollte der Programmierer schon
selbst mitbringen. Wie soll denn eine OH ein einschlägiges
Studium, mehrere Semester mit Übungen, Klausuren,
Diskussionen zu Datenbankthemen und Algorithmen ersetzen?

Was soll denn alles drinstehen? Satz von Taylor? Mit Beweis?
Aufbau von Divide-Et-Impera-Algorithmen? Mit oder ohne
Formeln zur Zeitkomplexitätsberechnungen? Bei der
Gelegenheit, weil's dabei gebraucht wird, noch eine kleine
Auffrischung der Logarithmenrechnung, da man das in der
Schule verschludert hat, weil die Mädels interessanter
waren?

> Diejenigen, die das abgefaßt haben, sind nicht kompetent.

Du solltest Dich umgehend bei Microsoft bewerben, damit es
besser wird. ;-)

Gruß aus Mainz
Michael

.

[Michael Zimmermann]

Hallo!

Lars P. Wolschner:
> Im Ernst: Die Gruppe ist Bestandteil einer
> Firmenhierarchie, hier des Herstellers der von mir
> kritisierten Software. Da habe ich natürlich die schwache
> Hoffnung, daß der Unmut auch mal irgendwann bei den
> Entwicklern ankommt.

Zunächst mal bei den Leuten, mit denen Du hier diskutieren
willst und die mit MS nichts zu tun haben. Wenn Du was von
MS willst, solltest Du Dich direkt an die wenden.
....
> > [Vollständige Auswertung boolescher Ausdrücke]
> Deinem Beispiel fehlt jede praktische Relevanz, und damit
> meine ich nicht die Konstanten. Wenn eine Division durch
> Null droht, darf ich diese Null gar nicht erst in den
> Ausdruck gelangen lassen.

Es geht nicht um die 0 sondern ums Prinzip. Der zweite
boolesche Ausdruck könnte z. B. einen Bezug auf ein
Steuerelement enthalten, das mittlerweile nicht mehr
existiert oder umbenannt wurde. Der Phantasie sind keine
Grenzen gesetzt, wenn es um Fehlerverursachung geht.

> Und wozu war noch mal gleich die
> Laufzeitfehler-Behandlung mit Sprungmarken etc. pp.?

Um auf die Laufzeitfehler bei der Auswertung aller Terme
reagieren zu können?

> Ich hatte in Pascal, Modula2, C oder C++ jedenfalls noch
> nie Probleme mit sparsamen Auswertung boolescher
> Ausdrücke.

Ich auch nicht. Ich hatte aber auch noch nie Probleme mit
der vollständigen Auswertung, wie sie VB vornimmt. Es ist
mir eigentlich ziemlich egal, weil ich mit beidem umzugehen
weiß.

> ...Oder kannst Du einen mathematischen oder
> informationstheoretischen Lehrsatz zitieren, aus dem
> sich dieses Feature für VBA zwingend ergibt?

Mit etwas Pedanterie könnte man das Kommutativgesetz
bemühen, in der strengen Auslegung, daß die Reihenfolge
bei And und Or /keinerlei/ Rolle für die Behandlung des
Gesamtausdrucks spielt, da A Or B und B Or A völlig
äquivalent sein sollen. Wenn angenommen A mit 90%
Wahrscheinlichkeit zutrifft, wäre die Laufzeit bei
Teilauswertung nicht mit beiden Varianten völlig
identisch. Die völlig folgenlose Vertauschbarkeit von
A und B ist damit nicht mehr gegeben.

Das ist natürlich nicht praxisrelevant, aber es sollte ja
auch mathematisch und theoretisch sein.

> So könnte man dieses "Feature" auch knallhart als Fehler
> sehen, weil die durch das Handbuch gegebene Spezifikation
> nicht erfüllt wird.

Du scheinst Access/VB(A) nicht zu mögen. Nicht, daß ich das
jetzt schlimm fände, aber warum benutzt Du es dann?

> > > Überhaupt fehlen an vielen Stellen der Online-Hilfe
> > > elementare fachliche Informationen, obwohl manchmal
> > > durchaus viel Text erscheint.
> > Aber: Eine OH erklärt die Syntax eines Programmes. Die
> > *fachlichen* Informationen sollte der Programmierer
> > schon selbst mitbringen.
> > ...
> > [OH] Was soll denn alles drinstehen? Satz von Taylor?
> > Mit Beweis? Aufbau von Divide-Et-Impera-Algorithmen? ...
>
> Das lasse ich mal in Deinem Interesse weitgehend
> unkommentiert, ...

Das ist ganz reizend von Dir, wäre aber nicht nötig gewesen.
Um meine Interessen kümmere ich mich schon selbst.

> ...Du möchtest aber zwischen den Eigenschaften des
> Interpretierers und Algorithmik bzw.
> Berechenbarkeitstheorie unterscheiden.

Letzteres verstehe ich zumindest unter "fachlichen"
Informationen, die Du gefordert hattest. Du scheinst
darunter offenbar etwas anderes zu verstehen. Tant pis.

Die ganze Diskussion ist sowieso müßig. Mich stört
vollständige Auswertung nicht; daß sie Dich stört, ist
Dir unbenommen und mir egal, und da man es sich in VB
sowieso nicht aussuchen kann, erübrigt sich jeder
Disput. Es ist, wie's ist.

Gruß aus Mainz
Michael

.

[Michael Zimmermann]

Hallo!

Paul Rohorzka:
> > [Iif langsam]
> Also, ich steh drauf. ... :-)

Joa, die Weana Gmiadlichkeit! ;-)

Gruß aus Mainz
Michael

.

[Lars P. Wolschner]

"Michael Zimmermann" <Zimmermann [at] SZWeb.de>:

> Lars P. Wolschner:

>> Im Ernst: Die Gruppe ist Bestandteil einer
>> Firmenhierarchie, hier des Herstellers der von mir
>> kritisierten Software. Da habe ich natürlich die schwache
>> Hoffnung, daß der Unmut auch mal irgendwann bei den
>> Entwicklern ankommt.
>
> Zunächst mal bei den Leuten, mit denen Du hier diskutieren
> willst und die mit MS nichts zu tun haben. Wenn Du was von
> MS willst, solltest Du Dich direkt an die wenden.

Direkt? Ich schreibe doch auf einem Microsoft-Server.

Es hat wohl jeder verstanden, daß bei der Kritik Microsoft gemeint
ist. Und an wen soll ich mich denn wenden? Textbausteine kann ich
mir auch selber schreiben.

>> Deinem Beispiel fehlt jede praktische Relevanz, und damit
>> meine ich nicht die Konstanten. Wenn eine Division durch
>> Null droht, darf ich diese Null gar nicht erst in den
>> Ausdruck gelangen lassen.
>
> Es geht nicht um die 0 sondern ums Prinzip. Der zweite
> boolesche Ausdruck könnte z. B. einen Bezug auf ein
> Steuerelement enthalten, das mittlerweile nicht mehr
> existiert oder umbenannt wurde.

Äh - ja und? Das kann ich auch in C in einem einzigen
übersichtlichen Ausdruck abhandeln.

> ...Oder kannst Du einen mathematischen oder
>> informationstheoretischen Lehrsatz zitieren, aus dem
>> sich dieses Feature für VBA zwingend ergibt?
>
> Mit etwas Pedanterie könnte man das Kommutativgesetz
> bemühen, in der strengen Auslegung, daß die Reihenfolge
> bei And und Or /keinerlei/ Rolle für die Behandlung des
> Gesamtausdrucks spielt, da A Or B und B Or A völlig
> äquivalent sein sollen.

Nö, nirgendwo steht geschrieben, daß das so implementiert werden
muß. Auch die Mathematik kennt BTW nicht-kommutative Operatoren.
Warum macht es die Mehrheit der Progammiersprachen wohl anders?

> Die völlig folgenlose Vertauschbarkeit von A und B ist damit
> nicht mehr gegeben.

Die braucht an dieser Stelle niemand.

> Das ist natürlich nicht praxisrelevant, aber es sollte ja
> auch mathematisch und theoretisch sein.

Du hast keinen zwingenden Lehrsatz genannt, sondern eine disponible
Eigenschaft von Operatoren.

>> So könnte man dieses "Feature" auch knallhart als Fehler
>> sehen, weil die durch das Handbuch gegebene Spezifikation
>> nicht erfüllt wird.
>
> Du scheinst Access/VB(A) nicht zu mögen. Nicht, daß ich das
> jetzt schlimm fände, aber warum benutzt Du es dann?

Es wird halt eine Access-Datenbank benötigt. Access ist vorhanden,
Filemaker oder etwas anderes leider nicht.

>> ...Du möchtest aber zwischen den Eigenschaften des
>> Interpretierers und Algorithmik bzw.
>> Berechenbarkeitstheorie unterscheiden.
>
> Letzteres verstehe ich zumindest unter "fachlichen"
> Informationen, die Du gefordert hattest. Du scheinst
> darunter offenbar etwas anderes zu verstehen. Tant pis.

Wer nicht einsieht, daß man eine wichtige Eigenschaft wie die hier
ja nur beispielhaft diskutierte lazy Evaluation bei booleschen
Ausdrücken in die Dokumentation einer standardlosen formalen
Sprache aufnehmen muß, den kann ich leider nicht besonders ernst
nehmen. Und das steht ja nur beispielhaft für die zahllosen
wortreichen Artikel in der Online-Hilfe, die mehr Fragen aufwerfen
als beantworten.

CU
--
Lars P. Wolschner lars.wolschner [at] nexgo.de
Bernardstraße 11b lars.wolschner [at] gmx.de
D-63067 Offenbach am Main
Fon & Fax: +49 69 80068670 Mobil: +49 163 8122462 (eplus)
.

[Michael Zimmermann]

Lars P. Wolschner:
> Äh - ja und? Das kann ich auch in C in einem einzigen
> übersichtlichen Ausdruck abhandeln.

Dann mach das. Ich will Dich nicht davon abhalten.

> > > ...Oder kannst Du einen mathematischen oder
> > > informationstheoretischen Lehrsatz zitieren, aus dem
> > > sich dieses Feature für VBA zwingend ergibt?
> >
> > Mit etwas Pedanterie könnte man das Kommutativgesetz
> > bemühen, in der strengen Auslegung, daß die Reihenfolge
> > bei And und Or /keinerlei/ Rolle für die Behandlung des
> > Gesamtausdrucks spielt, da A Or B und B Or A völlig
> > äquivalent sein sollen.
>
> Nö, nirgendwo steht geschrieben, daß das so implementiert
> werden muß.

Es steht auch nirgendwo geschrieben, daß es anders
implementiert werden muß.

> Auch die Mathematik kennt BTW nicht-kommutative
> Operatoren.

Wir reden gerade von And und Or. Wenn die bei Dir nicht
kommutativ sind...

> > Letzteres verstehe ich zumindest unter "fachlichen"
> > Informationen, die Du gefordert hattest. Du scheinst
> > darunter offenbar etwas anderes zu verstehen. Tant pis.
>
> Wer nicht einsieht, daß man eine wichtige Eigenschaft wie
> die hier ja nur beispielhaft diskutierte lazy Evaluation
> bei booleschen Ausdrücken in die Dokumentation einer
> standardlosen formalen Sprache aufnehmen muß, den kann
> ich leider nicht besonders ernst nehmen.

Laß diese billige Polemik. Niemand hat etwas dagegen, daß
das Verhalten von Operatoren in der OH erläutert wird.

Ich habe gesagt, daß "fachliche" Informationen, die nach
meinem Verständnis nicht die Programmiersprache sondern
das, was man damit macht, betreffen, von einer OH zuviel
erwartet sind.

Außerdem habe ich gesagt, daß ich eine vollständige
Auswertung nicht störend sondern letztlich sogar sinniger
als die optimierte Auswertung finde, wiewohl ich auch mit
zweiterer keinerlei weltanschauliches Problem habe.
Dieses zweite Thema hat mit dem Inhalt der OH /gar nichts/
zu tun.

Ich habe nicht gesagt, daß ich die Art der Auswertung als
in der OH nicht erwähnenswert finde.

Was veranstaltest Du denn wegen etwas, worauf keiner
der hier Anwesenden irgendeinen Einfluß hat, so ein
Affentheater?

Was mich betrifft, habe ich von Deiner unterschwelligen
Aggressivität endgültig die Nase voll. EOT und an weiteren
Unterhaltungen nicht mehr interessiert.

Gehab Dich wohl
Michael

.

Am Mon, 25 Apr 2005 03:54:01 -0700 schrieb Lars P. Wolschner:

> Oder kannst Du einen mathematischen oder informationstheoretischen
> Lehrsatz zitieren, aus dem sich dieses Feature für VBA zwingend
> ergibt?

Ich bin zwar hier nicht gemeint, aber trotzdem ...

IMHO steht normalerweise das Ergebnis eines mathematischen Ausdrucks
in der Mathematik erst dann fest wenn er komplett
berechnet/ausgewertet wurde.

Das es bei der Berechnung auch Abkürzungen geben kann steht außer
Frage.

> Wohl kaum, denn ich kann selbst Auswerter mit oder ohne
> lazy Evaluation schreiben und Pascal, C, C++ u.v.a. existieren.

Bei diesen Sprachen steht (jedenfalls in den Büchern, die ich besitze)
auch explizit drin, dass dort bei AND und OR vom mathematisch
üblichen Weg abgewichen wird und die Auswertung nur unvollständig
ausgeführt wird.

Na gut, im C++-Buch steht dazu nichts, die verweisen da eher auf C.

Aber auch in meinem Modula II-Buch und dem Lisp-Buch wird an der
entsprechenden Stelle ausdrücklich erwähnt dass bei der Auswertung
von AND und OR vom mathematisch üblichen Weg abgewichen wird.

> So könnte man dieses "Feature" auch knallhart als Fehler sehen,
> weil die durch das Handbuch gegebene Spezifikation nicht erfüllt
> wird.

Wenn in der Doku nirgendwo steht dass von der mathematisch üblichen
Vorgehensweise abgewichen wird und VBA auch nicht von der
mathematisch üblichen Vorgehensweise abweicht, dann habe ich damit
kein Problem.

Wobei mir "lazy Evaluation" auch besser gefällt und die OH von Access
2002 auch wirklich unvollständig ist.


> Das lasse ich mal in Deinem Interesse weitgehend unkommentiert, Du
> möchtest aber zwischen den Eigenschaften des Interpretierers und
> Algorithmik bzw. Berechenbarkeitstheorie unterscheiden. Ersteres
> bestimmt allein der Hersteller bei so einer frei erfundenen
> Sprache, so daß er sie auch vollständig dokumentieren muß, wenn das
> Produkt brauchbar sein soll.

Was IMHO bei den Sprachen die vom üblichen Verhalten abweichen auch
gemacht wird.

Ciao,
Andreas
.

[Lars P. Wolschner]

"Michael Zimmermann" <Zimmermann [at] SZWeb.de>:

> Lars P. Wolschner:

>>> Mit etwas Pedanterie könnte man das Kommutativgesetz
>>> bemühen, in der strengen Auslegung, daß die Reihenfolge
>>> bei And und Or /keinerlei/ Rolle für die Behandlung des
>>> Gesamtausdrucks spielt, da A Or B und B Or A völlig
>>> äquivalent sein sollen.
>>
>> Nö, nirgendwo steht geschrieben, daß das so implementiert
>> werden muß.
>
> Es steht auch nirgendwo geschrieben, daß es anders
> implementiert werden muß.

Eben, *benau* *deshalb* hat man ins Handbuch zu schreiben, was man
implementiert hat. Und oben - es steht noch im Zitat - hast Du noch
behauptet, man müsse das kommutativ implementieren.

>> Auch die Mathematik kennt BTW nicht-kommutative Operatoren.
>
> Wir reden gerade von And und Or. Wenn die bei Dir nicht
> kommutativ sind...

Bei mir? Sie sind es bei der Mehrzahl prozeduraler Sprachen nicht,
"bei mir" konnte man das konfigurieren.

>> Wer nicht einsieht, daß man eine wichtige Eigenschaft wie
>> die hier ja nur beispielhaft diskutierte lazy Evaluation
>> bei booleschen Ausdrücken in die Dokumentation einer
>> standardlosen formalen Sprache aufnehmen muß, den kann
>> ich leider nicht besonders ernst nehmen.
>
> Laß diese billige Polemik.

Ich erkenne hier keinerlei Polemik. Ich sehe allerdings einen sich
windenden Microsoftler, wenn auch nicht mehr lange.

> Ich habe gesagt, daß "fachliche" Informationen, die nach
> meinem Verständnis nicht die Programmiersprache sondern
> das, was man damit macht, betreffen, von einer OH zuviel
> erwartet sind.

Von solchen Informationen war hier nicht die Rede, die Auswer-
tungsfolge boolescher Ausdrücke ist eine Information über den
Interpretierer ("die Sprache") bzw. Compiler.

> Ich habe nicht gesagt, daß ich die Art der Auswertung als
> in der OH nicht erwähnenswert finde.
>
> Was veranstaltest Du denn wegen etwas, worauf keiner
> der hier Anwesenden irgendeinen Einfluß hat, so ein
> Affentheater?

Du weißt nicht, wer "anwesend" ist; Du weißt nur, wer schreibt.
Nichts sagen hilft jedenfalls genau gar nichts, mal was sagen hilft
dagegen vielleicht. Keine Angst, Du kannst auch trotz meiner Kritik
MVP werden.

CU
--
Lars P. Wolschner lars.wolschner [at] nexgo.de
Bernardstraße 11b lars.wolschner [at] gmx.de
D-63067 Offenbach am Main
Fon & Fax: +49 69 80068670 Mobil: +49 163 8122462 (eplus)
.

"Michael Zimmermann" threw this exception:

Hi,

>> Überhaupt fehlen an vielen Stellen der Online-Hilfe
>> elementare fachliche Informationen, obwohl manchmal
>> durchaus viel Text erscheint.
>
>Daß die OH nach 97 ihren Benutzer nicht gerade wie einen
>König behandelt, steht außer Frage.
>
>Aber: Eine OH erklärt die Syntax eines Programmes. Die
>*fachlichen* Informationen sollte der Programmierer schon
>selbst mitbringen. Wie soll denn eine OH ein einschlägiges
>Studium, mehrere Semester mit Übungen, Klausuren,
>Diskussionen zu Datenbankthemen und Algorithmen ersetzen?
>
>Was soll denn alles drinstehen? Satz von Taylor? Mit Beweis?
>Aufbau von Divide-Et-Impera-Algorithmen? Mit oder ohne
>Formeln zur Zeitkomplexitätsberechnungen? Bei der
>Gelegenheit, weil's dabei gebraucht wird, noch eine kleine
>Auffrischung der Logarithmenrechnung, da man das in der
>Schule verschludert hat, weil die Mädels interessanter
>waren?

Zu den logischen Operatoren:
Des is halt so. Ob diese Variante oder die Andere sinnvoller
ist mag wohl im Auge des Betrachters liegen.

Zu den Hilfsmitteln möchte ich mal die Hilfe (MSDN) die zu
VisualStudio ausgeliefert wird heranziehen. Es ist wohl ein
sehr umfassendes Werk mit sehr viel Information. Es wird
auch versucht eine einheitliche Struktur darin beizubehalten.
Tja aber eben nur versucht, und solche Erwägungen haben mit
Programmierkenntnissen ja ned wirklich was zu tun .

Aber das grösste Manko ist (die online-MSDN inkludiert) und
dabei stimme ich dem OP zu, das bei vielen Funktionen diverse
Eigenarten (damit meine ich jetzt nicht die logischen Op. ) nicht
in der zugehörigen Beschreibung stehen.

Und das hat mit 'fachlicher Info' nichts zu tun, oder willst Du
behaupten es gäbe einen (Windows)Programmierer der in
Basic und C/C++ und JAVA programmiert und alle erdenklichen
Funktionen a) zumindest im Überblick hat b) im Detail kennt.
Man sollte nie nie sagen, aber ich denke diese Person ist noch
nicht geboren worden.

Es würde bei manchen Funkionserläuterungen ein einziger Satz
genügen um sich tagelange Recherchen, wieso etwas, obwohl
korrekt codiert, nicht funtioniert, zu sparen.

Aber dies ist wohl nicht die Stärke von M$. Da kann ich nur wieder
die opensource-gemeinde loben, wenns nicht in der Beschreibung
einer Funtkion steht, war zumindest der Programmierer so vernünftig
diverse Eigenarten in den header-Dateien zu kommentieren.


Gruss
Anton
--
Aber wieso? Gestern ging's doch noch!
.