Kleiner Denksport- (und Logik?-) Thread

[FireBird]

Deine Lebenserfahrungen sind bei dem Test nicht gefragt.

[TV-Junkie]

Och schade, ich dachte, ich könnte mal was sinnvolles Beitragen

[Anthea]

Die Gegenstände sind nur zufällig gewählte Namen für irgendetwas. Völlig Realitätsfern, wie jede reine Logik

[alex]

dementsprechend kann man über 6 genauso diskutieren.

Stimmt, war mir noch gar nicht aufgefallen. In jedem Fall bin ich beruhigt, dass du das mit 3 und 9 genauso siehst. Ich hab es jedenfalls nicht geschafft, die (allesamt "logisch" nicht vorbelasteten) Mitdiskutierer davon zu überzeugen, dass die Musterlösung an dieser Stelle nicht korrekt ist. Selbst ein praktisches Gegebeispiel mit Glas- und Kunststoffflaschen hat nicht geholfen

[karlek]

Ich hätte es ja mit Mengenlehre versucht.
Am Beispiel 3)

- Die Menge der Zangen ist eine Teilmenge der Künstler. (Alle Frauen sind Menschen.)
- die Menge der nicht malen könnenden Künstler ist ebenso eine Teilmenge der Künstler.
(Manche Menschen können nicht Auto fahren.)
Sind die beiden Mengen disjunkt, ist die Aussage (Also können Frauen nicht Auto fahren.) falsch.

[TV-Junkie]

Ich hätte es ja mit Mengenlehre versucht.
Am Beispiel 3)

- Die Menge der Zangen ist eine Teilmenge der Künstler. (Alle Frauen sind Menschen.)
- die Menge der nicht malen könnenden Künstler ist ebenso eine Teilmenge der Künstler.
(Manche Menschen können nicht Auto fahren.)
Sind die beiden Mengen disjunkt, ist die Aussage (Also können Frauen nicht Auto fahren.) falsch.

soll ich da wieder von meiner Lebenserfahrung berichten
Ne, ich lasse es mal

[ewgh]

Ich verstehe die Argumentationen z.T. nicht. Anthea sagt:

Über 3 kann man diskutieren. ...

Bei diesen "Logikspielereinen" handelt es sich um Folgerungen. Diese sind zwingend richtig oder falsch; ein "Könnte-sein" hat keinen Platz.

zu 3:

"Einige Vögel sind Schraubenzieher. Einige Schraubenzieher spielen Flöte. Also spielen einige
Vögel Flöte."

"Einige Vögel" impliziert, dass es Vögel gibt, welche die Schraubenzieher-Eigenschaft besitzen. Die Schnittmenge zwischen der Menge der Vögel und der Menge der Schraubenzieher ist also nicht leer.
Die gleiche Überlegung gilt für die Menge der Vögel und die Menge der Flötisten.

Da die beiden Schnittmengen disjunkt (siehe karlek) sein können, ist die Folgerung falsch!

Ähnliche Überlegungen gibt es auch für andere dieser Folgerungen.


zu 2:

"Alle Stöcke lieben Hunde"

Was ist hier Subjekt, was Objekt?!

Doch, unabhängig davon, gibt es auch hier entweder ein wahr oder falsch!

[alex]

[quote="ewgh"]gibt es auch hier entweder ein wahr oder falsch![/quote]

Stimmt, die c)-Antworten sind alle überflüssig. Was sind denn bitte immer die "beiden Antworten" von denen da die Rede ist? Es gibt immer zwei Bedingungen und eine Schlussfolgerung, letztere kann dann falsch oder richtig sein.

[ewgh]

Was sind denn bitte immer die "beiden Antworten" von denen da die Rede ist? Es gibt immer zwei Bedingungen und eine Schlussfolgerung, letztere kann dann falsch oder richtig sein.

Antwort 1: wahr
Antwort 2: falsch

NB:

Ich hab' nochmals nachgesehn. Richtigerweise müsste ich schreiben:

Antwort 1: stimmt
Antwort 2: stimmt nicht

[hagge]

Mal eine kleine Programmierknobelaufgabe.

Gesucht ist eine Funktion (in C), die in einem String alle führenden Slashes und alle führenden einzelnen Punkte überspringt, wenn diese von Slashes gefolgt werden, und den Reststring zurückgibt. So etwas kommt zum Beispiel beim Parsen von Pfadnamen vor.

Das Ganze soll so effizient wie möglich sein, also möglichst keine doppelten Auswertungen. Ein Zugriff auf den String gilt somit als "teuer" (langsamer Speicherzugriff) und soll möglichst nicht mehrfach auf das gleiche Zeichen erfolgen. Lokale Variablen sind "billig" (schnelle Prozessorregisterzugriffe) und können beliebig genutzt werden. Dass der Compiler ggf. von sich aus mehrfache Speicherzugriffe wegoptimieren kann, soll hier mal vernachlässigt werden. Es soll also schon vom C-Code aus möglichst optimal sein.

Beispiele:

Code: Alles auswählen

1.  ///abc/def      --> abc/def         führende Slashes entfernen
2.  ./abc/def       --> abc/def         führende einzelne Punkte entfernen
3.  .abc/def        --> .abc/def        aber nur wenn sie zwischen Slashes stehen
4.  ./abc//./def    --> abc//./def      Nur am Anfang entfernen
5.  /.//././abc/def --> abc/def         Auch beliebige Mischungen müssen wegfallen
6.  /./.abc/def     --> .abc/def        Hier darf der Punkt vor abc nicht wegfallen
7.  /./.././abc/def --> .././abc/def    Mehrfache Punkte müssen auch bleiben 
8.  .////.          --> (leerer String) Ein Punkt kann auch am Ende des Strings stehen
9.  ./////          --> (leerer String) ebenso ein Slash

Klingt einfach? Dachte ich auch. Bis ich nach einer halben Stunde immer noch keine so wirklich elegante Lösung hatte. Also probiert es mal aus. Hier als Beispiel die Funktion, wenn man nur alle führenden Slashes entfernen wollte, das wäre in der Tat einfach.

Code: Alles auswählen

char *skip(char *p)
{
    while (*p == '/')
        p++;

    return p;
}

Der zweite Teil mit dem Punkt und die Effizienzanforderung machen das Ganze kompliziert.

Anmerkung: Wie in C üblich ist der String mit einem 0-Byte abgeschlossen.

Gruß,

Hagge

[FireBird]

Zumindest liefert das folgende das von Dir gewünschte Ergebnis. Ob es Dir aber gefällt...

Code: Alles auswählen

char *skip(char *p)
{
    while((*p == '/') || (p[0] == '.' && (p[1] == '/' || p[1] == '\0')))
        p++;

    return p;
}

Man könnte p[0] und p[1] noch in zwei lokale Var schreiben, dann gibt es jeden Speicherzugriff nur ein Mal.

Code: Alles auswählen

char *skip(char *p)
{
  char a, b;

  while(((a = *p) == '/') || (a == '.' && ((b = p[1]) == '/' || b == '\0')))
    p++;

  return p;
}

[hagge]

Schon mal ein guter Ansatz. Das mit den beiden Variablen wäre dann der nächste Schritt (ah, OK, sehe gerade dass Du nacheditiert hast).

Was hier aber noch ein Problem ist, ist dass ein Slash hinter einem Punkt im nächsten Schleifendurchlauf nochmal ausgewertet wird, also insgesamt zweimal.

Hagge

[FireBird]

Die optimierte Routine wurde noch nacheditiert.

[FireBird]

Irgendwelche Doppelzugriffe wird man nicht verhindern können. Hier sorgt die innere Schleife für den Sonderfall "Mehrere-Slashes" für ein schnelles Incrementierens des Pointers.

Code: Alles auswählen

char *skip(char *p)
{
  char a, b;

  while(((a = *p) == '/') || (a == '.' && ((b = p[1]) == '/' || b == '\0')))
  {
    if(a == '/')
      while(p[1] == '/')
        p++;
    p++;
  }

  return p;
}

[hagge]

Irgendwelche Doppelzugriffe wird man nicht verhindern können.

Ah, jetzt dringst Du langsam zum eigentlichen Problem der Aufgabe durch. Doch, es geht.

Hagge

[FireBird]

Ich ändere meine Behauptung. Wenn a == '/' ist, dann wird der zweite Teil der äusseren while-Schleifenabfrage - und somit das p[1] - nicht mehr ausgeführt. Damit gibt es auch keinen Doppelzugriff auf die selbe Speicherstelle. Das fällt sicher nicht unter Deine Compiler-Optimierungsregel .

[hagge]

Ok, wieder etwas besser. Zwei Dinge stören mich noch: einmal wird das a zweimal auf Gleichheit mit '/' abgefragt, was zwar laut meiner Bedingungen erlaubt wäre, was man aber auch noch vermeiden kann. Aber das wichtigere ist, dass in Deiner Version eine '\0' hinter einem Punkt immer noch zweimal abgefragt wird, nämlich nochmal im nächsten Schleifendurchlauf.

Edit: halt stopp, Deine Änderung löst das Problem mit der doppelten Auswertung von / hinter einem Punkt ja auch noch nicht. Wenn man ./ im String hat, dann erkennt die äußere while-Schleife das und geht in die Schleife rein, aber da das erste Zeichen ja kein / ist, wird p einfach nur um 1 erhöht. Somit wird das / im nächsten Schritt nochmal neu abgefragt.

Hagge

[hagge]

Auch bei mir Kommando zurück. Diese neue Version von Dir ist *nicht* besser. Je länger ich es mir überlege ist die innere Schleife bei Deiner letzten Version völlig unnötig da und verlangsamt alles nur. Denn genau wie Du sagst wird die while-Bedingung kurz ausgewertet, also nur der Vergleich von a mit / ausgeführt, wenn a tatsächlich ein / enthält. Dann war der vorherige Teil, der einfach in der Schleife nur p inkrementiert hat, schneller als jetzt eine zusätzliche Abfrage mit der inneren Schleife.

Beispiel: ////

vorheriger Ablauf ohne innere Schleife:
if ((a = *p)=='/'), p++, if ((a = *p)=='/'), p++, if ((a = *p)=='/'), p++, if ((a = *p)=='/'), p++, if ((a = *p)=='/'), return p

jetziger Ablauf mit innerer Schleife:
if ((a = *p)=='/'), if (a=='/'), if (p[1]=='/'), p++, if (p[1]=='/'), p++, if (p[1]=='/'), p++, p++, if ((a = *p)=='/'), return p

Vorher: 5 Vergleiche, jetzt: 6 Vergleiche. Insofern: diese Optimierung ist gar keine.

Hagge

[hagge]

Na, will noch jemand anders ran oder soll ich auflösen?

Hagge

[Anthea]

Hm.

Code: Alles auswählen

char *skip ( char *p)
{
  int source=0;
  while(1)
  {
    switch(p[source])
    {
      case '.':
      case '/':
        break;
      default:
        return &p[source];
    }
    source++;
  }
}