Di recente, ho riscontrato un problema che mi richiedeva di definire l'operatore logico "OR" a livello di codice, ma senza utilizzare l'operatore stesso.

Quello che mi è venuto in mente è questo:

OR(arg1, arg2)
  if arg1 = True and arg2 = True
     return True

  else if arg1 = True and arg2 = False
     return True

  else if arg1 = False and arg2 = True
     return True

  else:
     return False

Questa logica è corretta o mi sono perso qualcosa?

Direi che è corretto, ma non potresti condensarlo in qualcosa di simile?

or(arg1, arg2)
    if arg1 == true
        return true
    if arg2 == true
        return true

    return false

Dal momento che stai facendo un confronto o, non penso che tu debba davvero controllare la combinazione. Importa solo se uno di loro è vero per tornare vero. Altrimenti vogliamo restituire false.

Se stai cercando una versione più breve e meno dettagliata, funzionerà anche:

or(arg1, arg2)
    if arg1
        return arg1
    return arg2

Ecco una soluzione senza o, e, non, confronti e valori letterali booleani:

or(arg1, arg2)
  if arg1
    return arg1
  else
    return arg2

Probabilmente non è molto più fondamentale di così;)

Una riga di codice:

return not (not arg1 and not arg2)

Nessuna ramificazione, nessun OR.

In un linguaggio basato su C, sarebbe:

return !(!arg1 && !arg2);

Questa è semplicemente un'applicazione delle leggi di De Morgan :(A || B) == !(!A && !B)

Se hai solo ande not, puoi usare la legge di DeMorgan per girare and:

if not (arg1 = False and arg2 = False)
  return True
else
  return False

... o (ancora più semplicemente)

if arg1 = False and arg2 = False
  return false
else
  return true

...

E dal momento che apparentemente siamo tutti fissi sull'ottimizzazione di qualcosa che è quasi sempre disponibile come istruzione della macchina, ciò si riduce a:

return not(not arg1 and not arg2)

return arg1 ? true : arg2

ecc. ecc. ecc. ecc.

Poiché la maggior parte delle lingue fornisce un condizionale e, le probabilità sono l'operatore "e" implica comunque un ramo.

...

Se tutto ciò che hai è nand(vedi Wikipedia ):

return nand (nand (arg1, arg1), nand (arg2, arg2))

Funzioni (ECMAScript)

Tutto ciò che serve sono le definizioni delle funzioni e le chiamate di funzione. Non sono necessarie diramazioni, condizionali, operatori o funzioni incorporate. Dimostrerò un'implementazione usando ECMAScript.

Innanzitutto, definiamo due funzioni chiamate truee false. Potremmo definirli come vogliamo, sono completamente arbitrari, ma li definiremo in un modo molto speciale che presenta alcuni vantaggi, come vedremo più avanti:

const tru = (thn, _  ) => thn,
      fls = (_  , els) => els;

truè una funzione con due parametri che semplicemente ignora il suo secondo argomento e restituisce il primo. flsè anche una funzione con due parametri che semplicemente ignora il suo primo argomento e restituisce il secondo.

Perché abbiamo codificato true in flsquesto modo? Bene, in questo modo, le due funzioni non solo rappresentano i due concetti di truee false, no, allo stesso tempo rappresentano anche il concetto di "scelta", in altre parole, sono anche if/ then/ elseespressione! Valutiamo la ifcondizione e passiamo il thenblocco e il elseblocco come argomenti. Se la condizione viene valutata tru, verrà restituito il thenblocco, se viene valutato fls, restituirà il elseblocco. Ecco un esempio:

tru(23, 42);
// => 23

Questo ritorna 23e questo:

fls(23, 42);
// => 42

ritorna 42, proprio come ti aspetteresti.

C'è una ruga, tuttavia:

tru(console.log("then branch"), console.log("else branch"));
// then branch
// else branch

Questo stampa sia then branch e else branch! Perché?

Bene, restituisce il valore di ritorno del primo argomento, ma valuta entrambi gli argomenti, poiché ECMAScript è rigoroso e valuta sempre tutti gli argomenti in una funzione prima di chiamare la funzione. IOW: valuta il primo argomento che è console.log("then branch"), che semplicemente ritorna undefinede ha l'effetto collaterale della stampa then branchsulla console, e valuta il secondo argomento, che ritorna undefinede stampa anche sulla console come effetto collaterale. Quindi restituisce il primo undefined.

Nel calcolo λ, dove è stata inventata questa codifica, non è un problema: il calcolo λ è puro , il che significa che non ha effetti collaterali; pertanto non noteresti mai che anche il secondo argomento viene valutato. Inoltre, λ-calculus è pigro (o almeno, viene spesso valutato in ordine normale), il che significa che in realtà non valuta argomenti che non sono necessari. Quindi, IOW: nel calcolo λ il secondo argomento non verrebbe mai valutato, e se lo fosse, non lo noteremmo.

ECMAScript, tuttavia, è rigoroso , ovvero valuta sempre tutti gli argomenti. Bene, in realtà, non sempre: if/ then/ else, ad esempio, valuta il thenramo solo se la condizione è truee valuta il elseramo solo se la condizione è false. E vogliamo replicare questo comportamento con il nostro iff. Per fortuna, anche se ECMAScript non è pigro, ha un modo per ritardare la valutazione di un pezzo di codice, allo stesso modo quasi tutte le altre lingue: racchiudilo in una funzione, e se non la chiami mai, il codice non essere mai eseguito.

Quindi, avvolgiamo entrambi i blocchi in una funzione e alla fine chiamiamo la funzione che viene restituita:

tru(() => console.log("then branch"), () => console.log("else branch"))();
// then branch

stampe then branche

fls(() => console.log("then branch"), () => console.log("else branch"))();
// else branch

stampe else branch.

Potremmo implementare il tradizionale if/ then/ in elsequesto modo:

const iff = (cnd, thn, els) => cnd(thn, els);

iff(tru, 23, 42);
// => 23

iff(fls, 23, 42);
// => 42

Ancora una volta, abbiamo bisogno di alcune funzioni extra quando si chiama la ifffunzione e la funzione extra chiama parentesi nella definizione di iff, per lo stesso motivo di cui sopra:

const iff = (cnd, thn, els) => cnd(thn, els)();

iff(tru, () => console.log("then branch"), () => console.log("else branch"));
// then branch

iff(fls, () => console.log("then branch"), () => console.log("else branch"));
// else branch

Ora che abbiamo queste due definizioni, possiamo implementare or. Innanzitutto, oresaminiamo la tabella della verità per : se il primo operando è vero, allora il risultato dell'espressione è lo stesso del primo operando. Altrimenti, il risultato dell'espressione è il risultato del secondo operando. In breve: se il primo operando è true, restituiamo il primo operando, altrimenti restituiamo il secondo operando:

const orr = (a, b) => iff(a, () => a, () => b);

Diamo un'occhiata che funziona:

orr(tru,tru);
// => tru(thn, _) {}

orr(tru,fls);
// => tru(thn, _) {}

orr(fls,tru);
// => tru(thn, _) {}

orr(fls,fls);
// => fls(_, els) {}

Grande! Tuttavia, questa definizione sembra un po 'brutta. Ricorda, true flsgià agisci come un condizionale da solo, quindi davvero non ce n'è bisogno iff, e quindi tutta quella funzione che si avvolge affatto:

const orr = (a, b) => a(a, b);

Ecco qua: or(oltre ad altri operatori booleani) definiti con nient'altro che definizioni di funzione e chiamate di funzione in poche righe:

const tru = (thn, _  ) => thn,
      fls = (_  , els) => els,
      orr = (a  , b  ) => a(a, b),
      nnd = (a  , b  ) => a(b, a),
      ntt = a          => a(fls, tru),
      xor = (a  , b  ) => a(ntt(b), b),
      iff = (cnd, thn, els) => cnd(thn, els)();

Sfortunatamente, questa implementazione è piuttosto inutile: non ci sono funzioni o operatori in ECMAScript che restituiscono truo fls, tutti ritornano trueo false, quindi non possiamo usarli con le nostre funzioni. Ma c'è ancora molto che possiamo fare. Ad esempio, questa è un'implementazione di un elenco collegato singolarmente:

const cons = (hd, tl) => which => which(hd, tl),
      car  = l => l(tru),
      cdr  = l => l(fls);

Oggetti (Scala)

Potresti aver notato qualcosa di strano: true flssvolgono un doppio ruolo, agiscono sia come valori di dati trueche false, ma allo stesso tempo, fungono anche da espressione condizionale. Sono dati e comportamenti , raggruppati in un ... uhm ... "cosa" ... o (oserei dire) oggetto !

Anzi, true flssono oggetti. E, se hai mai usato Smalltalk, Self, Newspeak o altri linguaggi orientati agli oggetti, avrai notato che implementano i booleani esattamente allo stesso modo. Dimostrerò una tale implementazione qui a Scala:

sealed abstract trait Buul {
  def apply[T, U <: T, V <: T](thn: ⇒ U)(els: ⇒ V): T
  def &&&(other: ⇒ Buul): Buul
  def |||(other: ⇒ Buul): Buul
  def ntt: Buul
}

case object Tru extends Buul {
  override def apply[T, U <: T, V <: T](thn: ⇒ U)(els: ⇒ V): U = thn
  override def &&&(other: ⇒ Buul) = other
  override def |||(other: ⇒ Buul): this.type = this
  override def ntt = Fls
}

case object Fls extends Buul {
  override def apply[T, U <: T, V <: T](thn: ⇒ U)(els: ⇒ V): V = els
  override def &&&(other: ⇒ Buul): this.type = this
  override def |||(other: ⇒ Buul) = other
  override def ntt = Tru
}

object BuulExtension {
  import scala.language.implicitConversions
  implicit def boolean2Buul(b: ⇒ Boolean) = if (b) Tru else Fls
}

import BuulExtension._

(2 < 3) { println("2 is less than 3") } { println("2 is greater than 3") }
// 2 is less than 3

Questo BTW è il motivo per cui Sostituisci condizionale con polimorfismo Il refactoring funziona sempre: puoi sempre sostituire qualsiasi condizionale nel tuo programma con l'invio di messaggi polimorfici, perché come abbiamo appena mostrato, l'invio di messaggi polimorfici può sostituire i condizionali semplicemente implementandoli. Lingue come Smalltalk, Self e Newspeak ne sono la prova dell'esistenza, perché quelle lingue non hanno nemmeno i condizionali. (Inoltre, non dispongono di loop, BTW o di alcun tipo di strutture di controllo integrate nel linguaggio, ad eccezione dell'invio di messaggi polimorfici, ovvero chiamate di metodo virtuali.)

Pattern Matching (Haskell)

Puoi anche definire orusando la corrispondenza del modello, o qualcosa come le definizioni di funzione parziale di Haskell:

True ||| _ = True
_    ||| b = b

Naturalmente, la corrispondenza dei modelli è una forma di esecuzione condizionale, ma anche in questo caso lo è anche l'invio di messaggi orientato agli oggetti.

Ecco un altro modo per definire OR, o addirittura qualsiasi operatore logico, usando il modo più tradizionale di definirlo: usare una tabella di verità.

Questo è ovviamente abbastanza banale da fare in linguaggi di livello superiore come Javascript o Perl, ma scrivo questo esempio in C per mostrare che la tecnica non dipende dalle caratteristiche del linguaggio di alto livello:

#include <stdio.h>

int main (void) {
    // Define truth table for OR:
    int OR[2][2] = {
        {0,   // false, false
         1},  // false, true
        {1,   // true, false
         1}   // true, true
    }

    // Let's test the definition
    printf("false || false = %d\n",OR[1==2]['b'=='a']);
    printf("true || false = %d\n",OR[10==10]['b'=='a']);

    // Usage:
    if (OR[ 1==2 ][ 3==4 ]) {
        printf("at least one is true\n");
    }
    else {
        printf("both are false\n");
    }
}

Puoi fare lo stesso con AND, NOR, NAND, NOT e XOR. Il codice è abbastanza pulito da sembrare una sintassi in modo da poter fare cose come questa:

if (OR[ a ][ AND[ b ][ c ] ]) { /* ... */ }

Un altro modo per esprimere gli operatori logici come espressioni aritmetiche intere (ove possibile). In questo modo è possibile evitare molte ramificazioni per un'espressione più ampia di molti predicati.

Let True be 1 Let False be 0

se la somma di entrambi è maggiore di 1, allora è vero o falso essere restituito.

boolean isOR(boolean arg1, boolean arg2){

   int L = arg1 ? 1 : 0;
   int R = arg2 ? 1 : 0;

   return (L+R) > 0;

}

Le due forme:

OR(arg1, arg2)
  if arg1
     return True
  else:
     return arg2

O

OR(arg1, arg2)
  if arg1
     return arg1
  else:
     return arg2

Hanno il vantaggio simile al golf del codice di essere un po 'più piccolo degli altri suggerimenti finora, un ramo in meno. Non è nemmeno così sciocca una micro-opt per ridurre il numero di rami se stiamo considerando la creazione di un primitivo che sarebbe quindi molto usato.

La definizione di Javascript di ||è simile a questa, che combinata con la sua digitazione libera significa che l'espressione false || "abc"ha il valore "abc"e 42 || "abc"ha il valore 42.

Sebbene se hai già altri operatori logici, simili nand(not(arg1), not(arg2))potrebbero avere il vantaggio di non ramificarsi affatto.

Oltre a tutte le soluzioni programmate usando if build, è possibile costruire un gate OR combinando tre gate NAND. Se vuoi vedere come è fatto su Wikipedia, clicca qui .

Da questo, l'espressione,

NOT [NOT (A AND A) AND NOT (B AND B)]

che utilizza NOT e AND fornisce la stessa risposta di OR. Si noti che l'uso di NOT e AND è solo un modo oscuro di esprimere NAND.

Tutte le buone risposte sono già state date. Ma non lascerò che ciò mi fermi.

// This will break when the arguments are additive inverses.
// It is "cleverness" like this that's behind all the most amazing program errors.
or(arg1, arg2)
    return arg1 + arg2
    // Or if you need explicit conversions:
    // return (bool)((short)arg1 + (short)arg2)

In alternativa:

// Since `0 > -1`, negative numbers will cause weirdness.
or(arg1, arg2)
    return max(arg1, arg2)

Spero che nessuno avrebbe mai usato approcci come questi. Sono qui solo per promuovere la consapevolezza delle alternative.

Aggiornare:

Poiché i numeri negativi possono interrompere entrambi gli approcci di cui sopra, ecco un altro suggerimento terribile:

or(arg1, arg2)
    return !(!arg1 * !arg2)

Questo utilizza semplicemente le leggi di DeMorgan e abusa del fatto che *è simile a &&quando truee falsesono trattati come 1e 0rispettivamente. (Aspetta, stai dicendo che questo non è codice golf?)

Ecco una risposta decente:

or(arg1, arg2)
    return arg1 ? arg1 : arg2

Ma questo è essenzialmente identico ad altre risposte già fornite.

Un modo per definire orè tramite una tabella di ricerca. Possiamo renderlo esplicito:

bool Or( bool a, bool b } {
  bool retval[] = {b,true}; // or {b,a};
  return retval[a];
}

creiamo un array con i valori che il valore restituito dovrebbe avere in base a ciò che aè. Quindi facciamo una ricerca. In C ++ come i linguaggi, boolpromuove un valore che può essere usato come indice di array, con trueessere 1e falseessere 0.

Possiamo quindi estenderlo ad altre operazioni logiche:

bool And( bool a, bool b } {
  bool retval[] = {false,b}; // or {a,b};
  return retval[a];
}
bool Xor( bool a, bool b } {
  bool retval[] = {b,!b};
  return retval[a];
}

Ora un aspetto negativo di tutti questi è che richiede la notazione del prefisso.

namespace operators {
  namespace details {
    template<class T> struct is_operator {};
    template<class Lhs, Op> struct half_expression { Lhs&& lhs; };
    template<class Lhs, class Op>
    half_expression< Lhs, Op > operator*( Lhs&&lhs, is_operator<Op> ) {
      return {std::forward<Lhs>(lhs)};
    }
    template<class Lhs, class Op, class Rhs>
    auto operator*( half_expression<Lhs, Op>&& lhs, Rhs&& rhs ) {
    return invoke( std::forward<Lhs>(lhs.lhs), Op{}, std::forward<Rhs>(rhs) );
    }
  }
  using details::is_operator;
}

struct or_tag {};
static const operators::is_operator<or_tag> OR;

bool invoke( bool a, or_tag, bool b ) {
  bool retval[] = {b,true};
  return retval[a];
}

e ora puoi digitare true *OR* falsee funziona.

La tecnica sopra descritta richiede un linguaggio che supporti la ricerca e i modelli dipendenti dall'argomento. Probabilmente potresti farlo in una lingua con generici e ADL.

A parte questo, puoi estendere quanto *OR*sopra per lavorare con i set. Basta creare una funzione gratuita invokenello stesso spazio dei nomi di or_tag:

template<class...Ts>
std::set<Ts...> invoke( std::set<Ts...> lhs, or_tag, std::set<Ts...> const& rhs ) {
  lhs.insert( rhs.begin(), rhs.end() );
  return lhs;
}

e ora set *OR* setrestituisce l'unione dei due.

Questo mi ricorda le funzioni charasteristic:

or(a, b)
    return a + b - a*b

Questo vale solo per le lingue che possono trattare i booleani come (1, 0). Non si applica a Smalltalk o Python poiché booleano è una classe. In smalltalk vanno ancora oltre (questo sarà scritto in una specie di pseudocodice):

False::or(a)
    return a

True::or(a)
    return self

E i doppi metodi esistono per e:

False::and(a)
    return self

True::and(a)
    return a

Quindi la "logica" è perfettamente valida nell'istruzione OP, sebbene sia dettagliata. Attenzione, non è male. È perfetto se hai bisogno di una funzione che agisce come un operatore matematico basato, per esempio, su una specie di matrice. Altri implementerebbero un cubo reale (come un'istruzione Quine-McCluskey):

or = array[2][2] {
    {0, 1},
    {1, 1}
}

E valuterai o [a] [b]

Quindi sì, ogni logica qui è valida (tranne quella pubblicata come usando l'operatore OR in lingua xDDDDDDDD).

Ma la mia preferita è la legge di DeMorgan: !(!a && !b)

Guarda la libreria standard di Swift e controlla la loro implementazione del collegamento OR e delle operazioni AND di collegamento, che non valutano i secondi operandi se non necessari / consentiti.

La logica è perfettamente corretta, ma può essere semplificata:

or(arg1, arg2)
  if arg1 = True
     return True
  else if arg2 = True
     return True
  else
     return False

E presumibilmente la tua lingua ha un operatore OR così - a meno che non sia contro lo spirito della domanda - perché no

or(arg1, arg2)
  if arg1 = True or arg2 = True
     return True
  else
     return False