Compact manière d'écrire (a + b == c ou a + c == b ou b + c == a)

Est-il plus compact ou pythonic façon d'écrire l'expression booléenne

a + b == c or a + c == b or b + c == a

Je suis venu avec

a + b + c in (2*a, 2*b, 2*c)

mais c'est un peu étrange.

a + b + c == max(a, b, c) ne serait pas True à moins que les deux plus petites valeurs de la somme à 0.
Plus compact? Peut-être. Plus Pythonic? Peu probable.
Il semble que vous avez trois mutuellement exclusifs conditions - c'est sans doute pourquoi vous êtes or-ing eux. Semble que si il sont mutuellement exclusifs, vous ne seriez pas en mesure de les combiner et d'en simplifier l'expression.
Faites votre future auto une faveur et de les garder dans la forme originale: C'est la seule qui indique immédiatement le but de cette. Ne pas le modifier. “Simple est mieux que d'être compliqué.”, “La lisibilité compte.”. “Si la mise en œuvre est difficile à expliquer, c'est une mauvaise idée.”
Pythonic == illisible?
Pas un python personne mais n'a pas de python ont quelques frais de la liste des fonctions? Je voudrais essayer de la liste de toutes les permutations de [a,b,c] et de trouver un endroit où le dernier est la somme des autres, ou quelque chose comme ça.
Peut-être il peut être plus pythonic si vous dites d'abord dans la langue, ce que cette comparaison de la cible.
Ils ne sont pas mutuellement exclusives. Voir a = 0, b = 0, c = 0 😉
J'aime ce que vous est venu avec le meilleur.
Ce que @phresnel dit. Au lieu d'essayer de "simplifier" l'expression, de l'envelopper dans une fonction avec un nom descriptif.
Sinon, affecter la valeur de la comparaison d'une variable avec un nom descriptif. Dépend, quoi de plus logique 🙂
J'ai lu une fois que vous devriez écrire votre code source, comme si elle sera maintenue par un fou armé d'une hache plus tard. Je pense que le fou armé d'une hache préférez votre première version. Et @Alex Varga besoin de regarder par-dessus son épaule pour le fou armé d'une hache!
est (0,0,0) le seul trio qui sera True pour les trois conditions?
Oui, le problème peut être vu comme un système homogène d'équations linéaires et comme il y a 3 variables et 3 de l'indépendance linéaire des équations (en d'autres termes de la matrice est de plein rang), la seule solution qui satisfait à tous les trois est (0,0,0). Si vous avez besoin seulement 2 conditions sont remplies en même temps, il y aurait une infinité de solutions reposant sur une seule ligne dans 3D carthesian de l'espace. En changeant les conditions, vous obtiendrez 3 lignes que tous se coupent en (0,0,0)
Attention. Si a, b, c sont des nombres à virgule flottante, puis a + b == c or a + c == b or b + c == a n'est pas équivalent à a + b + c in (2*a, 2*b, 2*c), en général. Par exemple, avec a = 1 + 2*sys.float_info.epsilon, b = 1, et c = 2, l'expression est évaluée à False, tandis que le second évalue à True.

InformationsquelleAutor qwr | 2015-08-19

boolean python

204

Si l'on regarde le Zen de Python, c'est moi qui souligne:

Le Zen de Python, par Tim Peters

Belle est mieux que laid.

Explicite est mieux qu'implicites.

Simple est mieux que complexe.

Complexe est mieux que compliqué.

L'appartement est mieux que imbriqués.

Incomplet est mieux que dense.

Lisibilité compte.

Cas particuliers ne sont pas assez spécial pour briser les règles.

Bien que le côté pratique battements de pureté.

Les erreurs ne doivent jamais passer sous silence.

Sauf s'il est explicitement fait taire.

Dans le visage de l'ambiguïté, de refuser la tentation de le deviner.

Il devrait y avoir un, et de préférence seulement une façon évidente de le faire.

Bien que cette façon peut-être pas évident à première vue, sauf si vous êtes néerlandais.

Est maintenant mieux que jamais.

Bien que jamais est souvent mieux que droit maintenant.

Si la mise en œuvre est difficile à expliquer, c'est une mauvaise idée.

Si la mise en œuvre est facile à expliquer, il peut être une bonne idée.

Les espaces de noms sont un coup de klaxon grande idée, nous allons faire plus de ceux-là!

Les plus Pythonic solution est celle qui est la plus claire, la plus simple et la plus facile à expliquer:
```
a + b == c or a + c == b or b + c == a
```
Mieux encore, vous n'avez même pas besoin de savoir Python pour comprendre ce code! C'est que facile. C'est, sans réserve, la meilleure solution. Tout le reste est de la masturbation intellectuelle.

En outre, c'est probablement la solution la plus performante, car il est le seul de toutes les propositions que les courts-circuits. Si a + b == c, une seule addition et la comparaison est effectuée.
- Encore mieux, jeter dans certains parenthèse à l'intention de cristal clair.
- L'intention est déjà en cristal clair sans parenthèses. Entre parenthèses, il serait plus difficile à lire - pourquoi l'auteur à l'aide des parenthèses lorsque la priorité couvre déjà ce?
- Une autre remarque au sujet d'essayer d'être trop intelligent: vous pouvez introduire des bugs imprévus par l'absence d'une des conditions que vous n'avez pas envisager. En d'autres termes, vous pouvez pense votre nouvelle solution compacte qui est équivalent, mais il n'est pas dans tous les cas. À moins qu'il y est une raison impérieuse de code dans le cas contraire (performances, contraintes de mémoire, et ainsi de suite), la clarté est roi.
- Cette Zen s'applique à tous les code jamais.
- Cela dépend de ce que la formule est pour. Regardez Explicit est mieux qu'implicite, il se peut que le " tri première approche exprime plus nettement ce que le programme fait, ou l'un des autres. Je ne pense pas qu'on puisse en juger à partir de la question.
InformationsquelleAutor Barry
101

Résoudre les trois égalités pour un:
```
a in (b+c, b-c, c-b)
```
- Le seul problème avec ceci est que les effets secondaires. Si b ou c sont des expressions plus complexes, ils vont être exécutée plusieurs fois.
- lire plus court-circuit après compact"? Que voulez-vous dire?
- Mon point est que j'ai vraiment répondu à sa question, qui a demandé un "plus compact" de la représentation. Voir: en.m.wikipedia.org/wiki/Short-circuit_evaluation
- N'importe qui lisant ce code va probablement vous maudire pour être "intelligent".
- La même chose est vraie de l'original
- le point est que j'ai effectivement répondu à sa question". Vous avez; il utilise 30% moins de caractères (mettre des espaces entre les opérateurs). Je n'étais pas en train de dire que votre réponse était mal, il suffit de commenter sur la façon dont idiomatiques (pythonic) c'est. Belle réponse.
- C'est plus compact; toutefois, il n'est pas immédiatement clair ce que fait le code. Le code doit probablement être mis en fonction en tant que Cyphase recommande, ou au moins commenté.
InformationsquelleAutor Alex Varga
54

Python a une any fonction qui fait un or sur tous les éléments d'une séquence. Ici, j'ai converti votre déclaration dans un 3-élément d'un tuple.
```
any((a + b == c, a + c == b, b + c == a))
```
Noter que or est le court-circuit, donc, si le calcul de l'individu conditions est cher, il pourrait être préférable de conserver l'original de votre construction.
- any() et all() de court-circuit trop.
- Pas dans ce cas; les trois expressions seront évaluées avant le tuple existe, et le n-uplet existera avant any court même.
- Ah, je vois. Je suppose que c'est seulement quand il y a un générateur ou similaire paresseux itérateur là.
- any et all "court-circuit" le processus de examen l'objet iterable qu'ils sont donnés; mais, si c'est itérable est une séquence plutôt qu'un générateur, puis il a été déjà été pleinement évalués avant l'appel de la fonction se produit.
- Ceci a l'avantage qu'il est facile de diviser sur plusieurs lignes (double-tiret les arguments pour any, un seul tiret de la ): dans le if déclaration), ce qui aide beaucoup pour des raisons de lisibilité lorsque les mathématiques sont impliqués
- Je suppose qu'il n'y a pas assez de différents types de supports sur le clavier pour Python pour avoir générateur de littéraux 😉
- Sûr qu'il y a assez de. Juste besoin d'inventer de nouvelles manières de les mettre ensemble, comme quelque chose comme (: 1, 2, 3 :) ou (? 1, 2, 3).
- tout(eval(e) e de "a + b == c, a + c == b, b + c == a".split(", "))
- comment est-ce mieux que ma réponse? Et si vous ne pense que c'est mieux, pourquoi ne pas vous laisser votre propre réponse?
- C'est une solution de court-circuit problème mentionné par @poke. Bien sûr c'est le genre de plaisanterie, à cause de la laideur de la solution par rapport au code d'origine par l'OP.
InformationsquelleAutor Mark Ransom
40

Si vous savez que vous avez seulement à faire avec des nombres positifs, cela fonctionne, et il est assez propre:
```
a, b, c = sorted((a, b, c))
if a + b == c:
    do_stuff()
```
Comme je l'ai dit, cela ne fonctionne que pour les nombres positifs; mais si vous savoir ils vont être positif, c'est très lisible solution de l'OMI, même directement dans le code plutôt que dans une fonction.

Vous pourriez faire, ce qui pourrait faire un peu de calcul répété; mais vous ne spécifiez pas les performances de votre objectif:
```
from itertools import permutations

if any(x + y == z for x, y, z in permutations((a, b, c), 3)):
    do_stuff()
```
Ou sans permutations() et la possibilité de la répétition des calculs:
```
if any(x + y == z for x, y, z in [(a, b, c), (a, c, b), (b, c, a)]:
    do_stuff()
```
Je serais probablement mis, ou toute autre solution, dans une fonction. Ensuite, vous pouvez simplement et proprement appeler la fonction dans votre code.

Personnellement sauf à ce que j'avais besoin de plus de souplesse dans le code, je voudrais juste utiliser la première méthode dans votre question. C'est simple et efficace. Je peux toujours le mettre dans une fonction:
```
def two_add_to_third(a, b, c):
    return a + b == c or a + c == b or b + c == a

if two_add_to_third(a, b, c):
    do_stuff()
```
C'est assez Pythonic, et c'est très probablement le moyen le plus efficace de le faire (l'extra appel de fonction à part); bien que vous ne devriez pas trop vous inquiéter au sujet de la performance de toute façon, à moins que c'est en fait à l'origine d'un problème.
- surtout si nous pouvons supposer que a, b, c sont non-négatives.
- cela fonctionne avec des nombres négatifs?
- Je trouve l'expression "ne fonctionne pas toujours" un peu déroutant. La première solution ne fonctionne que si vous êtes certain que vos numéros sont non-négatives. Par exemple avec (a, b, c) = (-3, -2, -1), vous avez une+b != c b+c=a. Des cas similaires avec (-1, 1, 2) et (-2, -1, 1).
- vous savez, j'ai remarqué que plus tôt; je ne sais pas pourquoi je n'ai pas le corriger.
- Votre solution ne fonctionne pas pour une large classe d'entrées, alors que l'OP suggestion fonctionne pour toutes les entrées. Comment est "ne pas travailler" plus Pythonic que "travail"?
- Ooh, composant logiciel enfichable. "Si vous savez que vous avez seulement à faire avec des nombres positifs, cela fonctionne, et il est assez propre". Tous les autres travailler pour n'importe quel nombre, mais si vous savez que vous avez seulement à faire avec des nombres positifs, le haut est très lisible/Pythonic de l'OMI.
InformationsquelleAutor Cyphase
17

Si vous allez seulement à l'aide de trois variables, alors votre initiale de la méthode:
```
a + b == c or a + c == b or b + c == a
```
Est déjà très pythonic.

Si vous prévoyez sur l'utilisation de plusieurs variables, alors la méthode de votre raisonnement avec:
```
a + b + c in (2*a, 2*b, 2*c)
```
Est très intelligent, mais permet de réfléchir à la raison. Pourquoi ce travail?

Le biais de certains de l'arithmétique simple, nous voyons que:
```
a + b = c
c = c
a + b + c == c + c == 2*c
a + b + c == 2*c
```
Et ce sera le cas, soit a,b, ou c, ce qui signifie que oui, il sera égal à 2*a, 2*b, ou 2*c. Ce sera vrai pour un nombre quelconque de variables.

Donc une bonne façon d'écrire rapidement ce serait tout simplement avoir une liste de vos variables et vérifier leur somme par rapport à une liste de l'doublé valeurs.
```
values = [a,b,c,d,e,...]
any(sum(values) in [2*x for x in values])
```
De cette façon, pour ajouter plus de variables dans l'équation, tout ce que vous avez à faire est de modifier votre liste de valeurs par des 'n' de nouvelles variables, de ne pas écrire " n " équations
- Qu'en est a=-1, b=-1, c=-2, puis a+b=c, mais a+b+c = -4 et 2*max(a,b,c) est -2
- Merci c'est vrai, j'aurais besoin d'utiliser l'abs. Faire que l'ajustement maintenant.
- Après émaillant avec une demi-douzaine de abs() appels, c'est Pythonic que l'OP est extrait de code (je l'avais fait appel de manière significative moins lisible).
- C'est très vrai, je vais régler cela maintenant
- Désolé, faute de frappe: *it's less Pythonic.
- Cela ne fonctionne pas pour une large classe d'entrées, alors que l'OP suggestion fonctionne pour toutes les entrées. Comment est "ne pas travailler" plus Pythonic que "travail"?
- Barry, pourriez-vous nous expliquer pourquoi ce ne serait pas travailler pour une grande classe d'intrants. Il me semble que ce serait beaucoup plus rapide à écrire et plus facile à comprendre si vous avez eu de très grands ensembles de données.
- si vous savez que vous allez seulement utiliser des nombres positifs..." C'est la moitié du nombre que vous êtes à écarter. Aussi, vous voulez dire n équations, pas (n-1)!.
- Merci pour vos commentaires, ils m'ont motivé à penser d'une femme de ménage et de minerai de méthode efficace. S'il vous plaît dites-moi ce que vous pensez de ma réponse.
- Vous pouvez simplifier votre dernier bloc de code à sum(values) in [2*x for x in values].
- Merci beaucoup @IlmariKaronen C'est une excellente solution.
- Afin de court-circuit, vous souhaitez utiliser un générateur de... quelque chose comme any(sum(values) == 2*x for x in values), de cette façon, vous n'auriez pas à faire tout le doublement de l'avant, tout aussi nécessaire.
InformationsquelleAutor ThatGuyRussell
12

Le code suivant peut être utilisé de manière itérative comparer chaque élément avec la somme des autres, ce qui est calculé à partir de la somme de l'ensemble de la liste, à l'exclusion de cet élément.
```
 l = [a,b,c]
 any(sum(l)-e == e for e in l)
```
- Sympa 🙂 je pense que si vous retirez la [] crochets à partir de la deuxième ligne, ce sera même de court-circuit comme l'original avec or...
- ce qui est fondamentalement any(a + b + c == 2*x for x in [a, b, c]), assez proche de l'OP suggestion
- Qui est similaire, mais cette méthode s'étend à un nombre quelconque de variables. J'ai incorporé la suggestion de @psmears sur court-circuit.
InformationsquelleAutor Arcanum
10

N'essayez pas de les simplifier. Au lieu de cela, nom ce que vous faites avec une fonction:
```
def any_two_sum_to_third(a, b, c):
  return a + b == c or a + c == b or b + c == a

if any_two_sum_to_third(foo, bar, baz):
  ...
```
Remplacer la condition avec quelque chose "d'intelligent" pourrait faire plus court, mais il ne va pas le rendre plus lisible. Laissant la façon dont il est n'est pas très lisible soit cependant, parce qu'il est difficile de savoir pourquoi vous êtes à la vérification de ces trois conditions d'un coup d'oeil. Cela rend absolument limpide ce que vous êtes en contrôle pour le.

Ce qui concerne la performance, cette approche ajoute la surcharge d'un appel de fonction, mais de ne jamais sacrifier la lisibilité pour les performances sauf si vous avez trouvé un goulot d'étranglement vous devez absolument corriger. Et toujours une large mesure, comme certains intelligente implémentations sont capables d'optimisation de loin et inline certains appels de fonction dans certaines circonstances.
- Les fonctions doivent être écrit uniquement si vous prévoyez d'utiliser le même code dans plus d'un endroit ou si le code est complexe. Il n'y a aucune mention de la réutilisation de code dans la question d'origine, et l'écriture d'une fonction d'une seule ligne de code n'est pas seulement exagéré, mais il en altère la lisibilité.
- Venant de la FP de l'école de choses, j'ai à peu près pas d'accord complètement et de l'état que bien nommé une ligne, qui sont quelques-uns des meilleurs outils pour améliorer la lisibilité que vous trouverez jamais. Faire une fonction à chaque fois que les étapes que vous prenez à faire quelque chose de ne pas immédiatement apporter de la clarté à ce vous êtes en train de faire, comme le nom de la fonction vous permet de spécifier le ce, mieux que tout commentaire.
- Quelle que soit l'école que vous appelez il est mauvais d'adhérer aveuglément à un ensemble de règles. Avoir à passer à une autre partie de la source à lire qu'une seule ligne de code caché à l'intérieur d'une fonction juste pour être en mesure de vérifier qu'il fasse ce qu'il est dit dans le nom, et puis d'avoir à revenir à l'endroit d'un appel à assurez-vous que vous êtes de passage de paramètres corrects est complètement inutile commutation de contexte. À mon avis, faire qui compromet à la fois la lisibilité et le flux de travail. Enfin, ni le nom d'une fonction, ni les commentaires de code sont un bon remplaçant pour une documentation du code.
InformationsquelleAutor Jack
9

Python 3:
```
(a+b+c)/2 in (a,b,c)
(a+b+c+d)/2 in (a,b,c,d)
...
```
S'adapte au nombre de variables:
```
arr = [a,b,c,d,...]
sum(arr)/2 in arr
```
Cependant, en général je suis d'accord que si vous avez plus de trois variables, la version originale est plus lisible.
- Cela renvoie des résultats incorrects pour certains intrants à cause de la virgule flottante, des erreurs d'arrondi.
- La Division doit être évitée pour les performances et la précision des motifs.
- Ne sera pas de toute mise en œuvre de retourner des résultats incorrects à cause de la virgule flottante arrondi? Même a+b==c
- Si a, b et c sont des entiers, alors (a+b+c)/2 ne arrondi (et peut retourner des résultats incorrects), mais a+b==c est exacte.
- juste curieux, je ne connais pas python, mais serait division en 2.0?
- La Division par 2.0 est la même que la division par 2 en Python 3. Deux d'entre eux floating point de la division, qui est sujette à erreur, et peut retourner des résultats incorrects en raison de l'arrondissement.
- la division par 2 est la diminution de l'exposant par un, de sorte qu'il sera précis pour tout entier qui est à moins de 2^53 (la partie fractionnaire d'un flotteur en python), et pour les grands entiers que vous pouvez utiliser décimal. Par exemple, pour vérifier les entiers qui sont à moins de 2^30 exécuter [x for x in range(pow(2,30)) if x != ((x * 2)/ pow(2,1))]
InformationsquelleAutor Vitalii Fedorenko
6
```
(a+b-c)*(a+c-b)*(b+c-a) == 0
```
Si la somme des deux termes est égale à la troisième terme, l'un des facteurs sera de zéro, l'ensemble du produit zéro.
- Je pensais exactement la même chose, mais je ne peux pas nier que sa proposition initiale est plus propre...
- Certainement. C'est vraiment pas différent de (a+b<>c) && (a+c<>b) && (b+c<>a) == false
- C'est juste que la multiplication est plus cher que les expressions logiques et arithmétiques de base.
- Oui, même si c'est TRÈS prématuré d'optimisation de préoccupation. Est-ce que ça va être effectué des dizaines de milliers de fois par seconde? Si oui, alors vous auriez probablement eu envie de regarder autre chose.
- Pourquoi pensez-vous qu'il est prématuré? Code doit être écrit avec l'optimisation à l'esprit, pas optimisé comme une arrière-pensée. Un jour, stagiaire, va copier ce bout de code et le coller dans certains critiques pour les performances de la boucle sur une plate-forme intégrée qui fonctionne ensuite sur des millions d'appareils qui n'étaient pas forcément lent pour ce qu'il fait, mais peut-être perdre plus de puissance de batterie. Écrire un tel code encourage les mauvaises pratiques de codage. À mon avis, ce que l'OP devrait avoir posée est de savoir si il y a un moyen d'optimiser cette logique de l'expression.
- Je suis d'accord, c'est ce que l'OP doit ont demandé. Qui aurait conduit à des réponses différentes.
InformationsquelleAutor mbeckish
6

Que diriez-vous simplement:
```
a == b + c or abs(a) == abs(b - c)
```
Noter que cela ne fonctionnera pas si les variables ne sont pas signés.

Du point de vue de l'optimisation du code (au moins sur plate-forme x86) cela semble être la solution la plus efficace.

Moderne compilateurs inline à la fois abs() appels de fonction et d'éviter de signer des tests et suivantes branche conditionnelle à l'aide d'un intelligent séquence de CDQ, XOR, et SOUS les instructions. Le ci-dessus du code de haut niveau sera donc représenté avec seulement de faibles temps de latence, à haut débit ALU instructions et seulement deux conditions.
- Et je pense que fabs() peut être utilisé pour float types ;).
InformationsquelleAutor Igor Levicki
4

De la solution fournie par Alex Varga "a (b+c, b-c, c-b)" est compact et mathématiquement belle, mais je n'aurais pas fait d'écrire le code de cette façon parce que le prochain développeur à venir ne serait pas immédiatement comprendre le but de ce code.

Marque Rançon de la solution de
```
any((a + b == c, a + c == b, b + c == a))
```
est plus clair, mais pas beaucoup plus succincte que
```
a + b == c or a + c == b or b + c == a
```
Lors de l'écriture de code que quelqu'un d'autre à regarder, ou que je vais avoir à regarder un long moment plus tard, quand j'ai oublié ce que je pensais quand je l'ai écrit, d'être trop court ou intelligent tend à faire plus de mal que de bien. Le Code doit être lisible. Si succincts est bon, mais pas aussi succincte que la prochaine programmeur ne peut pas le comprendre.
- Honnête question: pourquoi les gens supposent toujours que la prochaine programmeur sera un idiot incapable de lire le code? Personnellement, je trouve que l'idée insultant. Si le code doit être écrit pour être flagrant à chaque programmeur, qui implique que nous, en tant que profession sont les vacances pour le plus petit dénominateur commun, les moins qualifiés d'entre nous. Si nous continuons de cette manière, comment sont-ils toujours à améliorer leurs compétences personnelles? Je ne vois pas cela dans les autres professions. Quand était la dernière fois que vous avez vu un compositeur écrit une simple partition de la musique juste pour que chaque musicien peut jouer quel que soit le niveau de compétence?
- Le problème est que même les programmeurs ont limité l'énergie mentale, alors voulez-vous passer vos limité mentale de l'énergie sur l'algorithme et de niveau plus élevé les aspects du programme, ou à comprendre ce que certains compliqué ligne de code signifie quand il peut être exprimé plus simplement? La programmation est dur, afin de ne pas rendre plus difficile sur vous-même inutilement, tout comme un coureur Olympique ne serait pas une course avec un lourd sac à dos sur seulement parce qu'ils peuvent. Comme Steve McConell dit dans le Code Complet 2, la lisibilité est l'un des aspects les plus importants de code.
InformationsquelleAutor Paul J Abernathy
2

Demande est plus compact OU plus pythonic - j'ai essayé ma main à plus compact.

donné
```
import functools, itertools
f = functools.partial(itertools.permutations, r = 3)
def g(x,y,z):
    return x + y == z
```
C'est 2 personnages moins que l'original
```
any(g(*args) for args in f((a,b,c)))
```
test avec:
```
assert any(g(*args) for args in f((a,b,c))) == (a + b == c or a + c == b or b + c == a)
```
en outre, compte tenu:
```
h = functools.partial(itertools.starmap, g)
```
C'est l'équivalent
```
any(h(f((a,b,c))))
```
- Eh bien, c'est deux personnages plus courte que l'original, mais pas celle que l'OP a donné droit par la suite, dont il a dit qu'il est en train d'utiliser. L'original comprend également beaucoup d'espaces, dont il omet chaque fois que possible. Il y a aussi la question de la fonction g() vous devez définir pour que cela fonctionne. Compte tenu de tout cela, je dirais que c'est nettement plus grande.
- Je l'ai interprété comme une demande pour une expression plus courte/ligne. voir modifier pour de plus amples améliorer.
- Très mauvais noms de fonction, ne convient que pour un code de golf.
- désolé je ne joue pas. Adapté peut être assez subjective et dépend des circonstances, mais je vais en remettre à la communauté.
- Je ne vois pas comment cela est-il plus compact quand il a plus de caractères que le code d'origine.
InformationsquelleAutor wwii
1

Je veux vous présenter ce que je considère comme le plus pythonic réponse:
```
def one_number_is_the_sum_of_the_others(a, b, c):
    return any((a == b + c, b == a + c, c == a + b))
```
Le cas général, la non-optimisé:
```
def one_number_is_the_sum_of_the_others(numbers):
    for idx in range(len(numbers)):
        remaining_numbers = numbers[:]
        sum_candidate = remaining_numbers.pop(idx)
        if sum_candidate == sum(remaining_numbers):
            return True
    return False 
```
En termes de Zen de Python, je pense que l'ont souligné les rapports sont plus suivies que d'autres réponse:

Le Zen de Python, par Tim Peters

Belle est mieux que laid.

Explicite est mieux qu'implicites.

Simple est mieux que complexe.

Complexe est mieux que compliqué.

L'appartement est mieux que imbriqués.

Incomplet est mieux que dense.

Lisibilité compte.

Cas particuliers ne sont pas assez spécial pour briser les règles.

Bien que le côté pratique battements de pureté.

Les erreurs ne doivent jamais passer sous silence.

Sauf s'il est explicitement fait taire.

Dans le visage de l'ambiguïté, de refuser la tentation de le deviner.

Il devrait y avoir un, et de préférence seulement une façon évidente de le faire.

Bien que cette façon peut-être pas évident à première vue, sauf si vous êtes néerlandais.

Est maintenant mieux que jamais.

Bien que jamais est souvent mieux que droit maintenant.

Si la mise en œuvre est difficile à expliquer, c'est une mauvaise idée.

Si la mise en œuvre est facile à expliquer, il peut être une bonne idée.

Les espaces de noms sont un coup de klaxon grande idée, nous allons faire plus de ceux-là!

InformationsquelleAutor sevenforce
1

Comme une vieille habitude de ma programmation, je pense que placer complexe de l'expression à droite dans une clause peut le rendre plus lisible comme ça:
```
a == b+c or b == a+c or c == a+b
```
Plus ():
```
((a == b+c) or (b == a+c) or (c == a+b))
```
Et je pense également que l'utilisation de multi-lignes peuvent faire plus de sens comme ça:
```
((a == b+c) or 
 (b == a+c) or 
 (c == a+b))
```
InformationsquelleAutor shA.t
0

De manière générique,
```
m = a+b-c;
if (m == 0 || m == 2*a || m == 2*b) do_stuff ();
```
si, de manipuler une variable d'entrée est OK pour vous,
```
c = a+b-c;
if (c==0 || c == 2*a || c == 2*b) do_stuff ();
```
si vous souhaitez exploiter à l'aide de peu de bidouilles, vous pouvez utiliser "!", ">> 1" et "<< 1"

J'ai évité la division si elle permet d'éviter deux multiplications pour éviter d'arrondir les erreurs. Cependant, vérifiez pour les dépassements

InformationsquelleAutor Padmabushan
0
```
def any_sum_of_others (*nums):
    num_elements = len(nums)
    for i in range(num_elements):
        discriminating_map = map(lambda j: -1 if j == i else 1, range(num_elements))
        if sum(n * u for n, u in zip(nums, discriminating_map)) == 0:
            return True
    return False

print(any_sum_of_others(0, 0, 0)) # True
print(any_sum_of_others(1, 2, 3)) # True
print(any_sum_of_others(7, 12, 5)) # True
print(any_sum_of_others(4, 2, 2)) # True
print(any_sum_of_others(1, -1, 0)) # True
print(any_sum_of_others(9, 8, -4)) # False
print(any_sum_of_others(4, 3, 2)) # False
print(any_sum_of_others(1, 1, 1, 1, 4)) # True
print(any_sum_of_others(0)) # True
print(any_sum_of_others(1)) # False
```
- Les fonctions doivent être écrit uniquement si vous prévoyez d'utiliser le même code dans plus d'un endroit ou si le code est complexe. Il n'y a aucune mention de la réutilisation de code dans la question d'origine, et l'écriture d'une fonction d'une seule ligne de code n'est pas seulement exagéré, mais il en altère la lisibilité.
- Je suis en désaccord qu'elle altère la lisibilité; si vous choisissez un nom approprié, il peut améliorer la lisibilité (mais je ne faisons aucune déclaration quant à la qualité du nom que j'ai choisi dans cette réponse). En outre, il peut être utile de donner un nom à un concept, qui vous aurez à faire aussi longtemps que vous vous forcez à donner un bon nom pour votre fonction. Les fonctions sont bonnes. Si la fonctionnalité est assez complexe pour avantage d'être encapsulé dans une fonction, c'est un jugement subjectif.
InformationsquelleAutor Hammerite

Vous devez vous connecter pour publier un commentaire.