200x-Phänomen

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

|> PYR >= 1999 and PER &s?
|> eine Umstellung der beiden Terme wuerde das Ergebnis womoeglich
|> veraendern (nicht getestet).
|
|
| Tut sie tatsächlich: PER &s? and PYR>=1999 wirft diese Einzelbände weg.

bei naeherem Nachdenken ist das starker Tobak: Schliesslich begegnet
man sonst nie einem Operator der "and" heisst und nichtkommutativ ist.
Man sollte ihn vielleicht der Korrektheit besser in "nkand" umbenennen
oder in "a9and".

Die avanti-Konstruktion des vorher einzustellenden Filters als
Befehls-Verkettung
find PYR>=1999 ; find PER &s?
finde ich da viel ehrlicher.

Macht man die Filter-Operation durch die Restriktion und die SR-
Operation explizit, so stellt sich der von a99 gebildete
Suchbegriff (in Pseudonotation) so dar:

EXPAND( FILTER( PYR>=1999, find PER "s?"))

und der umgestellte als

FILTER( PYR>=1999, EXPAND( find PER "s?"))

Im Find-Menue kann man in jeder der drei Zeilen separat "Expansion"
einstellen, daher ist m.E. auch hier eigentlich nahegelegt, dass die
Expansion "nahe" am jeweiligen Teil-Find auszufuehren ist.
Die Semantik, dass sich ein voreingestellter oder vorangestellter Filter
"find PYR>=1999" zwischen das "find" und "&" der nachfolgenden Terme
schmuggelt, ist also nicht nur vom Resultat her irritierend (wie Frau
Koczian bewiesen hat), sondern auch im Konflikt zum Layout des
Find-Menues.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBLZBjENVh3bB0lwMRAg7jAJ416Va+lHig6wqvFz8FytbahL+PbgCfZc7E
BGCCvnglnYqegtZMAf/MB6Y=
=Lsf7
-----END PGP SIGNATURE-----