私見を変えるには遅すぎます。

これは、すべてのnumpyで最も広く使用されている関数の1つです（ assert_allcloseを介して）。これに対する唯一のパスは、別の名前を選択することです。

現在の実装はバグのように見えることを告白します。 注使用していることをmax(abs(a), abs(b))の代わりにabs(b) 、既存のテストを中断されません、それは単にある場合には条件を緩和abs(a) > abs(b) 。

少なくとも、これには、組み込みと一致しないというdocstring内の警告が必要です。

これを追加してみませんか？

from numpy.__future__ import isclose

ちなみに、それは乱数バージョン管理のアイデアかもしれません...

明確にするために、インポートは実際にはiscloseをインポートしませんが、新しいセマンティクスを有効にします。 それはモジュールにすくわれます。

アイデアは、人々が正しい機能を使用できるようにすると同時に、既存のコードを壊す必要がないということです。

、インポートは実際にはiscloseをインポートしませんが、新しいセマンティクスを有効にします

これをインポートしないようにすることは不可能だと思います。 mathlike_ufuncのような長い名前を選択するだけで、 remainderもカバーできます。

from __future__ import print_function実際にはprint_functionグローバルを生成することに注意してください

実際、ここではfrom __future__ import *スタイルのインポートは適切ではない可能性があります-Pythonでは、ファイルごとのレベルで_syntax_に影響し、numpyで同様のことを行うのは難しいでしょう

イテレータの例外は構文の変更ではありませんでした。 呼び出し元モジュールの名前空間を検査するために必要なのは小さなCモジュールだけです。 モジュールをキャッシュして、インポート時間だけを遅くすることもできます。

その通りです-そしてtrue_divisionは明らかにiscloseに類似しています。

これは、非推奨の機能を管理するためにwithステートメントを使用する代わりに、＃9444の問題を回避するための優れた方法です。

math.isclose作成者として@ ChrisBarker-NOAAをCCしましょう。

これはかなりマイナーな問題IMOです。 通常、 atolとrtolは、テストに合格するまでそれらをいじることによって選択されます。目標は、許容値よりも1桁大きいエラーをキャッチすることです。 @charrisが提案したようにrtol部分をリラックスするのは理にかなっているかもしれませんが、この小さな調整のためにスタックの内省のトリックを引き出す価値はないと思います。 また、 iscloseは、 assert_allcloseやさまざまなサードパーティのテストヘルパーなどによって間接的に呼び出されることが多いという問題があります。

StackOverflowで__future__スタイルのインポートの使用について質問しました： https ：

TLDR：それは可能ですが、簡単でもクリーンでもありません。

スタックイントロスペクションはこれだけではなく、関数の戻り値を変更するための一般的なポリシーとして提案されています。 問題は、原則として、これを変更する必要があるかどうかです。 答えが「はい」の場合、広く使用されていることを考えると、非推奨期間は少なくとも数年は必要だと思います。 Pythonに過去のモジュールが含まれることはありませんでしたが、必要に応じてAPIの安定性を向上させるための1つのオプションです。

もう1つの方法は、これをオプションisclose(...,symmetric=True)またはassert_allclose(symmetric=True)として追加することです。ここで、デフォルトはFalseで、現在の状況です。

@njsmithが述べているように、 rtolとatol値に意味を持たせず、ユニットテストに合格するように調整するだけで、これは小さな問題であることに同意します。

ただし、エラーが1％（ rtol=0.01 ）の範囲内であると言いたい場合があります。
この場合、 rtol測定に関する最悪の場合のエラーは100％です（ rtol * abs(b)はatolに近づき、次にatol + rtol * abs(b) ~= 2 * rtol * abs(b) ）。

一部の値が最大2％のエラーで渡される可能性があることを意味します。

atol = 1e-8 #default
rtol = 0.01 # 1%

b = 1e-6
a = 1.0199e-6 # ~ 2% larger comapared to b
abs(a - b) <= (atol + rtol * abs(b))
True

@charrisのアイデアを実装すると、比較がさらに緩和されるため、この特定のケースは非常にわずかに悪化しますが、対称性の問題がなくなり、実際に下位互換性があるため、それでも価値があります。

IMO NumpyがMath関数を使用したほうがよいのですが、変更があまりにも破壊的で、ほとんどのユーザーにとって重要ではない可能性があることを理解しています。 iscloseコア間で変更するオプションを作成すると便利です。

@njsmith ：私を連れてきてくれてありがとう。

少し歴史があります。私がstdlibに近いと提案したとき、私たちは確かにnumpyを先行技術と見なしていました。 それが私だけだったとしたら、互換性のために、互換性のあるアプローチを使用したかもしれません:-)。

しかし、コミュニティの残りの部分は、Pythonにとって「正しい」ことを行うことがより重要であると考えていたため、長い議論が続きました...見に行きたい場合は、PEPのほとんどのポイントをキャプチャしようとしました。

numpyへの参照は次のとおりです。

https://www.python.org/dev/peps/pep-0485/#numpy -isclose

この議論と同じことが指摘されていることがわかります。

結局、3つの重要なポイントが出てきました。

1）対称的なアプローチは、驚き最小の原則になります。

2）引数の大きさの順序について何も仮定しないように、デフォルトの絶対許容値はおそらくゼロである必要があります。

3）「弱い」テストと「強い」テストの違いは、予想されるユースケースと同様に、許容誤差が小さい場合は関係ありませんでした。

結局、math.iscloseの「最良の」解決策を思いついたと思います。

しかし、下位互換性を壊すのに十分「優れている」のでしょうか。 私はそうは思いません。

残念ながら、numpy（およびpython）の多くには、便利なために多くの機能が追加されていますが、現在の議論があまりないため、これらの機能は最適ではないデザインがたくさんあります。 これは若い図書館にとって期待されている（そして必要な）ものであり、私たちは今それと一緒に暮らす必要があります。

@njsmithは正しいです-厳密なFPエラー分析によって許容値が設定されているnp.isclose（）の使用法はほとんどないと思いますが、np.isclose（）自体を使用してエラーを試行します。

ただし、より大きな問題はデフォルトのatolだと思います-引数が1次であると想定しています-これは非常に間違った想定である可能性があり、テストに合格することが多いため、そうではありません、ユーザーは気付かないかもしれません。

In [85]: np.isclose(9.0e-9, 1.0e-9)
Out[85]: True

痛い！

はい、これを引き起こしているのはatolです。

In [86]: np.isclose(9.0e-9, 1.0e-9, atol=0.0)
Out[86]: False

ですから、前進する道を持っていることはおそらく良い考えです。

私はキーワード引数のアイデアが好きです-__ future__などをいじろうとするよりもはるかに簡単に思えます。

そして、非推奨の警告の発行を開始し、最終的にデフォルトの多くのバージョンをダウンストリームに変更するかどうかを決定できます...

@bashtageの提案を提案したいと思います：

"" "
もう1つの方法は、これをオプションisclose（...、symmetric = True）またはassert_allclose（symmetric = True）として追加することです。ここで、デフォルトは現在の状況であるFalseです。
"" "

これは新しい関数名よりも優れたオプションであり、将来の非推奨やデフォルトの変更につながる可能性があると思います（またはそうでない）。

（強力な）対称テストに加えて、 atolデフォルトでゼロになるはずだと思います。

それを考えると、悪くはありませんが、パラメータにはsymmetricよりも適切な名前が必要かもしれません...

ああ-そしてassert allclose()に加えてisclose()がnumpyの他の場所で呼び出されていないことを確認するのは良いことかもしれません。

これを行う最も簡単な方法は、おそらく非推奨の警告を
次に、マージする前にそれを削除します。 私たちは先に進んで置くことができます
既存のコードをに変更するように指示する非推奨の警告
symmetric = False; デフォルトである必要があると言う理由はありません
警告があってもすぐに変更されます。

assert_allcloseも追加する必要がありますか、それともサイレントに変更するだけですか？ 警告を消すためにすべてのテストを更新するようにすることは、許容範囲を減らすためにテストを更新することと実際には何の違いもありません

@xoviat @ eric-wieser assert_allcloseへの後方互換性のない変更や、それからの非推奨の警告はあり得ません。 非推奨の警告を表示したい場所がない場合を除きますか？

これはまだ極小の苦痛のように聞こえるのではないかと思います
ゲイン、私に。

デフォルトでatolをゼロ以外にすることは、偶然ではありません。 取得する必要があります
期待される結果に含まれるすべてのテストの適切なデフォルトの動作
正確なゼロ。

に更新されるため、assert_allcloseを変更する必要はありません。
古い動作を使用するために内部的に。

IMOのサイレント変更は厄介です！ 非推奨の警告は、
人々は最終的にインタラクティブなプロンプトでフラグを入力する必要はありません
新しい動作を取得します。それ以上はありません。

IMOのサイレント変更は厄介です！

同意しました。 ただし、変更はありません。 広く使用されている機能の非推奨警告も、ユーザー（少なくとも実際にメンテナンスを行うユーザー）に変更を強制します。

@charrisが提案したような修正するのはどうですか？ これにより、ドキュメントスペースが解放され、 atol != 0.0ときに発生する可能性のある悪いことについての警告が表示される可能性があります。

変更について人々に知らせずにその問題を修正することはできません
動作。 それを行う方法を私が知っている唯一の方法は、警告を出すことです。

本当に素晴らしいのは、フラグを挿入する自動リファクタリングツールです
古いコードに。 次に、「メンテナンス」はあなたのスクリプトを実行するだけです
コード; 5分の作業。

申し訳ありませんが、これは新しいフラグを使用するだけで修正できます。

@charrisが提案したような修正するのはどうですか？

その提案（https://github.com/numpy/numpy/issues/10161#issuecomment-349384830）は実行可能のようです。

変更された動作について人々に知らせずにその問題を修正することはできません。

修正していません。 これは、セマンティックバージョニングの問題で議論されている変更のコスト/メリットに関するものです。 これは間違いなく、広く使用されているテスト機能から変更を加えたり警告を発したりしない場合です。 現在の動作はバグではないことに注意してください（ただし、おそらく最適ではない選択です）。

明確にするために、私はiscloseへの変更を提案していましたが、assert_allcloseではありませんでした。
ソースを見ると、その変化は破壊的なものの3分の1になります。
ただし、メリットはまだ小さすぎる可能性があります。 誰もいないと思います
しかし、フラグを追加することに反対しますよね？

でも、フラグを追加することに反対する人はいないと思いますよね？

わからない、詳細によって異なります。 @charrisの提案はフラグを必要としない場合があり、これを導入するフラグは配列にとって少し疑わしいものです。

In [1]: import math

In [2]: math.isclose(0, 1e-200)
Out[2]: False

具体的な動機やユースケースなしでフラグを追加することに反対しています。 有用なリトマス試験：初心者の開発者がこのフラグが存在する理由を尋ねた場合、どのように説明しますか？

どのように説明しますか？

1. math.iscloseへの呼び出しをベクトル化する場合は、 symmetric=Trueフラグを使用します
2. 既存のコードを壊さないように、フラグである必要がありました。

実際に問題が解決されている状況をもっと探しています。

おそらくここで解決されている唯一の実際の問題は初心者を作ることです
浮動小数点の精度についてもっと考えてください。 つまり、@ rgommersによる例
それは間違っているように見えますが、あなたが本当に小さいものを扱っている場合はどうなりますか
数字？ IMO math.iscloseの実装の方が優れていますが、私も
それについてはコンセンサスがあると思います。 残念ながら、実際にはありません
数値が「近い」かどうかを判断するための万能ソリューション。 だが
他の人からの応答に基づいて（それは間違っていません！）、私は本当に間違っていません
今後のAPIへの変更。 取るべき行動は
おそらくドキュメントが更新されます（有名な最後の言葉、私が
以前は旗は大丈夫だと思っていました）？

確かに、 math.iscloseと比較し、必要に応じてrtolとatolを設定することで、同一のベクトル化された動作を取得する方法を文書化したメモは問題ありません。

また、私が正しく理解していれば、 @ charrisは許可するための解決策を提案しました
現在よりも耐性が
任意のテスト。 私はまだ（警告を発するように良いアイデアだと思います
警告が1回出される必要があります）近くにある状況がある場合
以前はそうではなかった場合、数値は「近い」と見なします。 それは非常にありますよりも
それが彼らに影響を与えるとき、誰もがそれについて知っています。

ここで私たちが議論していることについて、いくらかの説明が必要だと思います。 math.isclose違いは2つあります。

• atol別のデフォルト
• rtol別の定義

最初の問題については、 `math.iscloseとは異なるものとして文書化する以外に、何もできないと思います。

2番目の問題は、デフォルトでFalse設定されているsymmetric引数を追加することで最もよく修正されると思います。 これで、ドキュメントに書き込むことができます_ " np.isclose(x, y, symmetric=True, atol=0)はmath.isclose(x, y) " _のベクトル化されたバージョンであり、私にはこれを解決しようとしているようです。

ここから、3つのオプションがあります。

1. 追加の引数を文書化し、他に何もしません
2. 引数なしでiscloseを呼び出すことを非推奨にし、警告なしで古い動作を取得するためにユーザーにisclose(..., symmetric=False)を書き込むように強制します（ allcloseについても同様です）。 これはあまり多くのコードにヒットしないと思いますが、結果はあまり読みにくく、大きな利益はありません。 assert_closeは、内部でisclose(..., symmetric=False)を呼び出すように変更されるため、そのユーザーは影響を受けません。
3. 上記と同様ですが、 symmetricへのassert_close symmetric引数も必要です。 これは下流で大規模な解約になります
4. 行動を静かに変える

これらのうち、オプション1は問題ないと思いますが、残りは混乱させる価値のあるもののようには聞こえません。

編集：2は、動作が変化する場合にのみ警告が発せられる場合に許容される可能性があり、ノイズがはるかに少なくなります。

@ eric-wieser 3つ目の違いがあります。それは、 atolとrtolを組み合わせる方法です。 （ math.iscloseはmax 、 numpy.iscloseは+ ）。 つまり、 atolまたはrtolがゼロでない限り、 math.isclose呼び出しをnumpy.isclose呼び出しと一致させる一般的な方法はありません。

ただし、ユーザーに表示されるAPIを追加する価値はまだないと思います。

私はオプション2に賛成でした。 私はまだそのオプションに賛成
numpyが自動化されたものを提供するという追加の規定
自分で実行できるリファクタリングツール（entry_pointsに追加）
それらを修正するための既存のプロジェクト。 他の人が言ったことに基づいて、それは
このオプションは他の人には好まれません。

私はそうではなく、オプション3または4のいずれかに賛成したことはありません。 に
さらに、警告が出るまで関数の動作を変更することに賛成しません
少なくとも4つのメジャーリリースでリリースされています。

他の人がオプション2（彼らが持っている）に同意しないと仮定すると、私は
オプション1を支持します。 しかし、他の人（特に@njsmith）は賛成していません
あなたがここで与えたオプションのいずれか。 少なくともそれが私の認識です。

@njsmithそれは正しくありません。 フラグを使用して関数の動作を変更できます。

私はその3番目の違いを手の波に折りたたんでいます_ "rtolは異なります" _

"" "
実際に問題が解決されている状況をもっと探しています。
"" "
私はドーナツにドルを賭けます（それが何を意味するのかわからないので、私はそうします）。あるべきです。

現在の実装には3つの「問題」があるようです。

1）対称ではありません

• それは残念ですが、実際には大したことではないと思います。値が実際に近い場合はほとんど違いはありません:-) rtol <1e-8の場合（少なくともatolが0.0の場合）、文字通り違いはないと思います。

2）atolは、ゼロと比較しなくても結果に影響します（これは避けられません）が、許容誤差を約2倍に効果的に変更します。atolが大きい場合は、それ以上になります。大きさの値。

3）atolはデフォルトではゼロ以外です-これは（特に両方を追加する現在のアルゴリズムでは）最大の問題だと思います。テストに合格するのは非常に簡単ですが、そうではないことがよくあります。少し怠惰です-デフォルトの許容値でテストを作成します。合格した場合は、完了したと思います。 （それがどのように機能するかを理解したとき、私はyコードに戻り、DIDはそれらのいくつかを見つけました-おっと！

このスレッドの誰かが、「次の場合に何か問題が発生する可能性があります。

isclose（1e-200、0.0）

デフォルトでFalseを返しました。 私は同意しません-はい、それは驚くべきことですが、それはユーザーに何が起こっているのかを考えさせるでしょうが、現在の実装は（例えば）結果になります：

[8]の場合：np.isclose（1e-20、1e-10）
Out [8]：True

本当に？ 1つはMAGNITUDEの10桁が他よりも大きく、Trueに戻りますか????

私のポイントは、atolがゼロ以外の場合、ゼロと比較する一般的なケースではおそらくそれほど驚くべき結果は得られませんが、小さい数で作業する場合ははるかに危険で間違った結果になります（小さいと実際には1桁未満です。

また、1e8より大きいなど、多数を処理している場合は、デフォルトのatolよりも不適切です。

また、（2）と組み合わせると、デフォルトのatolも驚くべき方法で相対許容誤差テストを台無しにする可能性があることを意味します。

つまり、いいえ、それはバグではなく、「壊れた」ものでもありませんが、かなり最適ではないので、より良い実装に進む方法があるといいでしょう。

私はフラグアプローチが好きでしたが、私は考えを変えていると思います-問題は、それを廃止し、ある時点でデフォルトのフラグを変更しない限り、ほとんどすべての人が「古い」アルゴリズムを使用することになるということですほぼ永遠に。 そして、おそらくそれを非推奨にできない理由については、多くの良い議論がありました。

したがって、新しい名前の新しい関数が必要になる可能性があります。 人々に新しいものを使用するように勧めるドキュメントを追加したり、人々が新しいものを使用したときに警告を追加したりすることもできますが、誰かのコードを壊すことは決してありません。

誰かが新しい関数の良い名前のアイデアを持っていますか????

たぶんnp.math.iscloseと友達？ 知りません。

これにより、 np.remainder違いも解決され、 from numpy import mathを使用してコードを簡単にベクトル化することもできます。

私は次のようになりますので、 +1のnp.mathモジュール

10年間そのように機能してきた他の関数とはわずかに異なる動作で新しい関数を導入することは、一般的に非常に悪い考えです。 この場合、ドキュメントで適切に解決できない問題は実際にはそれほど多くありません。 したがって、新しい関数では-1です。 そして、まったく新しいサブモジュールでは間違いなく-1です。

本当に？ 1つはMAGNITUDEの10桁が他よりも大きく、Trueに戻りますか????

あなたの期待が真か偽かは完全に文脈に依存します。 それが[0、1）の連続分布から得られる数値の場合、そうです、おそらくTrueを期待するでしょう。 ユーザーは、絶対/相対公差と関数が実際に何をするかを本当に理解する必要があります。それがドキュメントの目的です。

symmetric_isclose()は少し長めですが、私の目には不快ではありません。：bikeshed：絵文字>

2017年12月10日午後8時9分、RalfGommersの[email protected]は次のように書いています。

他とは動作がわずかに異なる新機能のご紹介
10年間そのように機能してきた機能は、一般的に非常に貧弱です
考え。

私もそれが好きではありませんが、変更を加えて人々のコードを壊すのはもっと悪いことです。
単純なもの以外に、numpyを改善しないという考えはありますか？

この場合、十分にできない問題は実際にはあまりありません。
ドキュメントで解決しました。

私は同意しません—デフォルトは重要です—たくさん。

そして、私はあなたに与えるためにパラメータを調整する方法はないと思います
対称比較。

そして、まったく新しいサブモジュールでは間違いなく-1です。

私も。 numpyのない数学モジュールに他のものがある場合
便利な同等のもの、それらはnumpyの名前空間に追加できます
他のすべてのように。

本当に？ 1つは他よりも大きいMAGNITUDEの10桁であり、戻ってきます
本当????

あなたの期待が真か偽かは完全に文脈に依存します。

正確に—それがatolに「合理的な」デフォルトがない理由です。

それが[0、1）の連続分布から来る数の場合
そうです、おそらくTrueを期待するでしょう。

しかし、iscloseは相対的な比較であると宣伝されています—そしてここでは
相対性は完全に洗い流されています絶対的な比較です、
ユーザーがそれについて考える必要はありません。

それが私の要点です-デフォルトはあなたがあなたを期待する場合にのみ適切です
値は1桁になります。一般的なケースですが、確かにそうではありません。
ユニバーサル。

これはどちらが悪いかということになります—偽陰性または偽陽性。
また、テストの一般的な使用例では、誤検知ははるかに悪化します。

（つまり、すべきではないテストに合格する）

ユーザーは、絶対/相対公差と何を本当に理解する必要があります
関数は実際に行います、

絶対に-しかし、関数には妥当なデフォルトと
理解しやすい堅牢なアルゴリズム。

私はドキュメントを改善し、機能をそのままにしておく傾向があります。 対称性の欠如は、「isclose（a、b）は、aがbに近いことを意味しますが、浮動小数点の絶対精度が変化するため、bがaに近いとは限りません。テストでは、 bは期待される結果であり、aは実際の結果である必要があります。」 これはテストにとって意味があることに注意してください。対称関数の場合は、実際には正当化するのが少し複雑です。 除算を含む相対誤差は対称的ではありません。

私もそれが好きではありませんが、変更を加えて人々のコードを壊すのはもっと悪いことです。 単純なもの以外に、numpyを改善しないという考えはありますか？

ここでは、新しい関数を追加する方が新しい関数を追加しないよりも優れているという価値判断をすでに通過しています。 それは私見ではありません。 3つのオプション：

1. 重大な変更-受け入れられない、あなたはそれについて議論するのをやめることができます。
2. より良いドキュメントを追加するだけ
3. 関数の追加

2は全体的に3よりも良い選択です。したがって、それがnumpyを「より良い」ものにします。 また、このatol / rtolは単一の関数に限定されないことも無視しているので、次は何をしますか？新しくて少し「優れた」 assert_allclose ？ これにより、ドキュメントのみの場合がさらに明確になります。

これは非常に深刻な欠陥です。基本的に、コードをテストするコードにはバグがあります...良くありません。 numpy.iscloseとデフォルトのatolでテストされたものを月に送信しますか？ 私はよく考えます...そしてそれが、これらの落とし穴をドキュメントで目立たせる必要がある理由です。
エイリアス関数を追加すると、ユーザーに強制されない限り（発生しない限り）、コードベースが乱雑になります。

私は対称性がマイナーであることに同意しますが、それでも修正する必要があります。 そのままにしておくと、ユーザーが実際の落とし穴から気をそらす可能性があります。

@rgommersは書いた：
"" "
ここでは、新しい関数を追加する方が新しい関数を追加しないよりも優れているという価値判断をすでに通過しています。 それは私見ではありません。
"" "
さて、私はmath.iscloseについて考え、議論することに多くの時間を費やしました、そして私たちはとりわけ厄介な実装を見ることから始めました。 そうです、そうです、私はアプローチがより良いと思います。 そして、この議論から、それはほぼコンセンサスだと思いました。

そして、より良いアルゴリズム/インターフェースをnumpyに取り入れることで、より良くなります。

おそらく、古い（おそらくより適切に文書化された）関数をそのままにしておくよりも、古い関数と新しい関数の両方をnumpyに含める方が良いわけではないことを意味します。 確かに、それは完全に有効なポイントですが、私はその議論をしようとしていました、そして「10年間そのように機能してきた他の関数とわずかに異なる動作で新しい関数を導入することは一般的に非常に悪い考えです」という以前のコメント議論を締めくくったように見えた-私のポイントは、新しい方法がそれだけの価値があるよりも「十分に優れている」場合だということです。 私たちが明らかにコンセンサスを持っていないのは、この特定のオプションが「より良い」かどうかではなく、「十分に良い」かどうかです。

ちなみに、個人的には変える価値があるとは思っていませんが、話し合いたいと思います。

ここで重要なのは、私の側のいくつかの仮定です。 それらが正しいかどうかを確実に知ることができるかどうかはわかりませんが、次のようになります。

1）np.isclose（）の最大の使用法はテストです-あなたの答えはあなたが期待するものに十分近いですか？ -これは、np.assert_all_closeを介して、またはより直接的に、pytestテストで、または...

2）ほとんどの人は、ほとんどの場合、厳密な浮動小数点エラー分析のようなことをして、答えがどれだけ良いと期待されるかを判断しません。 むしろ、彼らは値を試し、失敗した場合は結果を見て、それが本当にエラーであるかどうか、またはテストの許容範囲を調整する必要があるかどうかを判断します。

• これは、atolとrtolがマージされるかどうか、およびテストが対称であるかどうかはそれほど重要ではないことを意味します。

3）多くの人は、多くの場合、（2）のプロセスをデフォルトの許容値で開始し、テストが失敗した場合にのみ許容値の調整を検討します。

• これは、デフォルトのatolを持つことは非常に危険であることを意味します-そうではないはずのテストに合格することは本当に悪いことです。

4）人々はドキュメントを読まない（最初の「これをどのように呼ぶか」の段階を超えて）-少なくとも混乱する行動を見つけるまでは、混乱を解消するために何かが実際にどのように機能するかを理解しようとするかもしれません。 しかし、（3）を参照してください-テストが失敗しない場合、彼らは理由を理解するためにドキュメントを見に行くことを知りません。

これらすべてから、math.iscloseのようなFP近接性テストを行うとnumpyの方が「優れている」という結論に至ります。

そして、なぜより良いドキュメントが素晴らしいアイデアであるのに、十分ではないのか。

たぶん私は完全に間違っていて、ほとんどの人はドキュメントを注意深く読み、ほとんどの場合、問題に対してrtolとatolの両方を慎重に選択します-しかし、私も、私のチームの6人の人々も、私がこれらの問題を認識しています。

：bikeshed ：（くそー、それはうまくいきませんでした-気の利いた絵文字はありません）

多分relatively_close 、またはrel_close ？

追加の「楽しい」しわ：assert_allcloseは実際にはatol = 0を使用します
デフォルト。 修正できるかどうかを議論している別のスレッド全体がどこかにあります
その矛盾。 （私の電話では簡単に見つけることができません。）

2017年12月11日14:58、「ChrisBarker」 [email protected]は次のように書いています。

@rgommers https://github.com/rgommersの書き込み：
"" "
あなたはすでにここであなたの新しい関数を追加するという価値判断を通過しています
新しい機能がないよりはましです。 それは私見ではありません。
"" "
さて、私は多くの時間を考え、議論しました
math.isclose、そして私たちはnumpyの実装を見ることから始めました
とりわけ。 そうです、そうです、私はアプローチがより良いと思います。 そして私は思った
この議論から、それはほとんどコンセンサスでした。

そして、より良いアルゴリズム/インターフェースをnumpyに取り入れることで、より良くなります。

おそらくあなたは、古いものと新しいものの両方を持っていることを意味します
numpyは、単に古いものを残すよりも優れているわけではありません（おそらくより良い
文書化された）そこで機能します。 確かに、それは完全に有効なポイントですが、私は
その議論をしようとすると、前のコメントは「紹介
他の関数とは動作がわずかに異なる新しい関数
10年間そのように機能してきたことは、一般的に非常に貧弱な考えです。」
議論を締めくくったように見えた-私のポイントは、新しい方法が
それだけの価値があるよりも「十分に良い」。 私たちが明らかに持っていないもの
コンセンサスは、この特定のオプションが「十分に優れている」かどうかであり、
それが「より良い」かどうか。

ちなみに、私は個人的にそれが価値があると自分自身に確信していません
変化しますが、話し合いたいと思います。

ここで重要なのは、私の側のいくつかの仮定です。 できるかわからない
それらが正しいかどうかを確実に知っていますが、：

1.1。

np.isclose（）の最大の用途はテストです-あなたの答えです
あなたが期待するものに十分近いですか？ -これはnp.assert_all_close経由、または
より直接的に、pytestテストで、または....
2.2。

ほとんどの人は、ほとんどの場合、厳格なことをしません
答えがどれだけ良いかを判断するための浮動小数点エラー分析
なると予想されます。 むしろ、彼らは値を試し、それが失敗した場合、彼らは
結果を出し、それが本当にエラーであるかどうか、またはtehyを調整する必要があるかどうかを判断します
テストの許容範囲。

• これは、アトールとアトルかどうかはそれほど重要ではないことを意味します
  rtolがマージされ、テストが対称であるかどうか。

• 多くの人は、多くの場合、（2）のプロセスを次のように開始します。
  デフォルトの許容値であり、テストが失敗した場合にのみ許容値の調整を確認します。

• これは、デフォルトのatolを持つことは非常に危険であることを意味します-テスト
  それを通過することは本当に悪いことです。

• 人々はドキュメントを読みません（最初の「これをどのように呼ぶか」を超えて
  ステージ）-少なくとも彼らが混乱する行動を見つけるまでは、そして彼らは
  入って、何かが実際にどのように機能して解決するのかを理解しようとするかもしれません
  混乱。 しかし、（3）を参照してください-テストが失敗しない場合、彼らは
  理由を理解するためにドキュメントを見てください。

これはすべて、numpyが「より良い」という結論に私を導きます
より多くのmath.iscloseのようなFP近接テスト。

そして、なぜより良いドキュメントが素晴らしいアイデアであるのに、十分ではないのか。

多分私は完全に間違っています、そしてほとんどの人は注意深くドキュメントを読んで
ほとんどの場合、問題に対してrtolとatolの両方を慎重に選択してください-
しかし、私も、私のチームの5ダースの人々も、私がそうするまでそれをしていました。
これらの問題に気づきました。

：bikeshed ：（くそー、それはうまくいきませんでした-気の利いた絵文字はありません）

多分比較的_close、またはrel_close？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/10161#issuecomment-350886540 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAlOaNquy47fsOkvBlxcSa-Mxyhgdimlks5s_bORgaJpZM4Q2J-P
。

＃3183のことですか？

assert_allcloseは、実際にはデフォルトでatol = 0を使用します。

興味深い-それは私が気分が良くなるのです。

これは、2つの違いについての過去の議論のぼんやりとした記憶を呼び戻しています-それは唯一のものでしたか？

こんにちは、
私のthermo、fluids、およびhtライブラリは、numpyのassert_allcloseを広範囲に使用しているため、関連するいくつかの考えをここで共有します。 このスレッドは、動作の違いを非常に憂慮すべきものに見せます。対称性の欠如や、デフォルトのatol（assert_allcloseには存在しない）との組み合わせの違いのために、コードにバグが見つかることを期待する必要があります。 、 知っている）。 そのため、ライブラリにバグがあるかどうかを確認し、assert_allcloseの非常に大雑把な実装をハックして、代わりに一時的に使用するようにテストを変更しました。

私のassert_allcloseの使用は代表的なものだと思います。個別に選択した値を比較し、関数の結果をパラメトリックにファズしてassert_allcloseを呼び出すテストを行います。 私はあらゆる種類の大きさのintとfloatを比較します。 私は、rtolまたはatolの選択についてはほとんど考えていませんが、atolを追加したり、rtolをそれほど厳密でないデフォルトに変更したりすることはめったにありません。 ライブラリは、assert_allclose 13159、1178、および4243をそれぞれ呼び出します。

そこで、変更を加えて、テストテストを実行しました。 新しいバグやテストの失敗は見つかりませんでした。 私が見つけた唯一のテストの失敗は、assert_allcloseの実装によるものでした。

幸運に恵まれず、assert_allcloseまたはiscloseのいずれかが変更されると、問題が発生する人が他にもいることを私は知っています。 別の関数であろうとsymmetricフラグであろうと、math.allcloseの動作を複製するassert_allcloseモードがあれば、個人的にはテストの作成がより快適になります。 しかし、それは誰かがやるべきことはたくさんあり、PRもまだありません。 一度でもこの欠陥がないかコードをチェックできてうれしいです！

4880は私が考えていたものです。

2017年12月11日には、午前5時01分PMで、ナサニエル・J.スミス[email protected]
書きました：

4880https ：//github.com/numpy/numpy/pull/4880は私が考えていたものです

の。

おかげで、statsmodelの例は私の主張をうまくしていることに注意してください
atolのデフォルト—0.0以外は危険です。

これが数年ごとに発生するという事実は、私たちがすべきであることを示していますか？
最後にそれについて何かしますか？

多分そうです。 それは小さな疣贅ですが、時々それらの小さな迷惑が追加されます
時間の経過とともに上昇します。

そして、assert_allcloseのデフォルトがゼロになっていることに満足しています。
（あなたがそうしなくても、それは許容できるオプションであるという私の主張を支持します
それが最良の選択肢であることに同意します）私たちの多くは-そしてもっと常に-そうではありません
unittestを使用するため、テストでnp.all_closeを直接使用できます。

はい、ラルフ、変更を加える場合は、3つすべてを変更したいと思います
密接に関連する関数:-(。しかし、それは私たちにそれらを作る機会を与えてくれます
より一貫性のある、ボーナス？

py2-3の移行はあまりうまくいっていませんが、何かあるべきことがあります
ある時点で「いぼを片付けても大丈夫」バージョンがあると言った:-)

別のオプションがあります。実際にis_closeをatol=0の（実際にはより良い）数学バージョンに移動します。デフォルトをNoneに変更し、 atol=0試してください。 ; すべてのTrueが戻ってきた場合; False場合は、標準のatol再試行し、結果が変更された場合は非推奨の警告を発します（そして「古い」結果を返します）。

悲しいことに、対称性とatolの両方を同時に実行することはできません。これは、それらが異なる方向に進むためです（つまり、常に両方のケースを実行する必要があり、少し多いようです）。 しかし、私は対称性の欠如よりもはるかにatolデフォルトが嫌いです...

機能がない限り、機能を変更することに賛成しません。
古い動作をしているものを使用できます。 さらに、
完了した場合にこの変更を行うための自動リファクタリングツール。 しかしそれはそうではありません
今でもテーブルの上に。

py3kトランジションは、私たちが再び望んでいるものではありません。
ロールモデルではありません。 クリーンアップを1つの大きなリリースにまとめるのは良くありません
IMOにアプローチします。

py2-3の移行はあまりうまくいっていませんが、ある時点で「いぼをクリーンアップしても大丈夫」バージョンがあると言われることがあります:-)

ただ、特別なバージョン番号が変更にOKを壊すことができますことを、この一般的な考え方に対処するには：一般的なルールは、痛みの許容できないレベルを回避明確な移行計画があります場合には、いぼをクリーンアップしても大丈夫ですし、利益が正当化するのに十分であるということですコスト。 ここで重要なのは、「ルールに従ったか」ではなく、ユーザーへの影響で判断する必要があるということです。 （あなたが空想になりたいのなら、私たちはデントロジストではなく結果主義者です。）したがって、特定のバージョンを「これは物事を壊すものです」と宣言する唯一の理由は、ユーザーが物事を実質的に扱いやすくするかどうかです。 壊れた変更をまとめてロールアップするIMOの利点は、それらが存在する場合は一般にわずかです。壊れたコードは壊れたコードです。たとえ存在したとしても、費用便益分析を「いいえ」から「」に変えることは非常にまれです。はい"。

atolはデフォルトではゼロ以外です-これは（特に両方を追加する現在のアルゴリズムでは）最大の問題だと思います。テストに合格するのは非常に簡単ですが、合格しないはずです。怠惰-デフォルトの許容値でテストを記述します。合格した場合は、完了したと見なします。 （それがどのように機能するかを理解したとき、私はyコードに戻り、DIDはそれらのいくつかを見つけました-おっと！

statsmodelの例は、デフォルトのatolについて私の主張をよく示していることに注意してください。0.0以外のものは危険です。 [...]私たちの多く（そして常に）はunittestを使用していないため、テストで直接np.all_closeを使用する可能性があります。

「他のパッケージとの一貫性を高めるためにユーザーコードを解読する必要があります」は、費用便益のスケールではあまり得点がありません。 方法がより説得力がある「だけで混乱が、直接ユーザーコードでサイレントバグにつながり、そして我々がいることを解決できるような方法で混乱していないnumpyの内部矛盾があります」。 私自身はまだ意見を述べていませんが、ここで進歩を遂げたいのであれば、これが私が推進していることです。

注：

「」「rtolまたはatolの選択については、あまり考えていません。
atolを追加することはめったにありません
-をちょきちょきと切る-

$ assert_allclose 13159、1178、および4243をそれぞれ呼び出します。

-をちょきちょきと切る-

新しいバグやテストの失敗は見つかりませんでした。

「」

朗報ですが、assert_allcloseのatolのデフォルトはゼロです。 そして
これが理由です ：-）

@njsmithは書いた：

「他のパッケージとの一貫性を高めるために、ユーザーコードを壊す必要があります」

このスレッドの誰もがそれを支持しているとは思いません—私は確信していません。 誰もが主張している唯一の一貫性は、関連するnumpy関数間の一貫性です。

「numpyの内部には、混乱を招くだけでなく、ユーザーコードのサイレントバグに直接つながる方法で混乱を招く不整合があります。これを修正できます。」

それが私が少なくとも主張していることです。 そして、私は他のほとんどだと思います。

問題は、次のいずれかがないと修正できないことです。

下位互換性を破ること。これは、非推奨のサイクルがあっても、これが十分に深刻であるとは誰も考えていないと思います。

または

新しいフラグまたは関数を作成します。

新しい関数はそれを行うためのよりクリーンな方法になると思います。 古いコードは必要な限り変更されないままで、新しいコードは新しい関数を使用でき、検索と置換（または呼び出しとしてのいくつかのインポート）により、一度に1つのファイルを簡単に切り替えることができます。

（私はあなたがあなたのテストコードでモンキーパッチnumpyさえできると思います...）

私たちはすでに持っています：

• allclose
• assert_allclose
• assert_almost_equal
• assert_approx_equal
• assert_array_almost_equal
• assert_array_almost_equal_nulp
• assert_array_max_ulp

このリストにオプションを追加しても、実際のユーザーに大きな違いはないと思います。

さて、私はmath.iscloseについて考え、議論することに多くの時間を費やしました。そして、とりわけ、numpyの実装を調べることから始めました。 そうです、そうです、私はアプローチがより良いと思います。

私もそうしました、そして私はnumpy.testingの主要なメンテナの一人

おそらく、古い（おそらくより適切に文書化された）関数をそのままにしておくよりも、古い関数と新しい関数の両方をnumpyに含める方が良いわけではないことを意味します。 確かに、それは完全に有効なポイントですが、私はその議論をしようとしていました、

確かに、それが私が意図したことであることは明らかです。

「10年間そのように機能してきた他の機能とはわずかに異なる動作の新しい機能を導入することは、一般的に非常に悪い考えです」と議論は締めくくられたようです

いいえ、無視されたり、十分な重みが与えられなかったりする新しい関数を追加する際の実際の問題を指摘しています。 この場合、多くのコア開発者にとってはかなり明白に思えます-この船が@ njsmith 、 @ pv 、 @ charris 、そして私から出航したという判断を得ているようです。

これを再ハッシュすることを事前に謝罪しますが、 assert_allcloseは正しい動作です（または少なくともそれに十分に近いです）。 ただし、 iscloseは、他の人が指摘しているように絶対的な許容範囲を想定しているため、人々を困らせる可能性があります。 np.iscloseドキュメントページに大きな赤いボックスを配置して、この動作について人々に警告するPRを提出することを検討しています。 それはどのように聞こえますか？

これを再ハッシュすることを事前に謝罪しますが、assert_allcloseは
正しい動作（または少なくともそれに十分近い）。 ただし、iscloseは取得する可能性があります
他の人が持っているように絶対的な許容範囲を想定しているため、人々はトラブルに巻き込まれます
了解しました。 大きな赤いボックスを置くためのPRを提出することを検討しています
この動作について人々に警告するためのnp.iscloseドキュメントページ。 どうやって
あの音？

+1

ドキュメントの方が良いはずだというコンセンサスがあります。

ありがとう、

-CHB

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/10161#issuecomment-351182296 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AA38YDw4sdhRWYmeeyr4met1RCwWsjMQks5s_uBmgaJpZM4Q2J-P
。

私はドキュメントの改善を支持しますが、提案された変更はそれができるほど役に立たないと思います。

..警告::デフォルトのatolは、次のような数値には適していません
1よりはるかに少ないです。

第一に、この警告は一般的には真実ではありません。 デフォルトのatolは、 1e-8より小さい数値をゼロに等しいものとして扱いたい場合に適しています。 これは相対公差では不可能です。そのため、絶対公差が存在します。 逆に、 1e-8より小さい数値を意味のあるものとして扱いたい場合は、デフォルトのatol適切ではありません。 1つのサイズですべてに対応できるとは限りません。

したがって、 @ xoviatは、深い敬意を持って、あなたの主観的な発言に強く反対します。

... assert_allclose _は正しい動作です（または少なくともそれに十分近い動作です）。

現在のドキュメントの問題は、 atolが何であるかを説明するのに非常に優れているが、なぜそこにあるのかを説明していないため、ユーザーがデフォルト値をいつ変更するかを理解できない可能性があることです。 。

私は次の線に沿って何かを提案します：

「ゼロ以外の小さな値をatol設定すると、ゼロに非常に近い数値を実質的にゼロに等しいものとして扱うことができます。したがって、デフォルト値のatolは使用に適さない場合があります。ケース。選択atolより大きい数ようにatolあなたが意味のある（ゼロとは異なる）であることによって考慮され、そしてより少ない数atol使用すると、無視できるとによって考えられています（ゼロと同じ）。」

最後に、 iscloseとallcloseのdocstringに同じメモを追加します。

これが私の提案です。 それを取るか、それを残す。
乾杯。

PRにレビューフィードバックを残してください。 特に、あなたの提案は冗長すぎるIMOです。

煩わしすぎて申し訳ありませんが、まだコンセンサスが得られていないと思いました。

@xoviat ：ドキュメントに取り組んでくれてありがとう。

これが再び出てくるので、私は（おそらく）拒否されるように設計されたNEPのミニバージョンでこの議論を終わらせるつもりです-提案と拒否の理由を要約してください。 記録のために-前の号がちょうどちょっとペタリングされたので。

py2 / 3の問題を提起して申し訳ありません-numpyの疣贅をクリーンアップするかどうか/方法は、別の場所と時間の議論です。

isclose()

この問題（および参照されている他の問題）は、 numpy.isclose()とその友人が最適とは言えないアルゴリズムを使用し、atolのデフォルトが競合し、関連するさまざまな関数のデフォルトが異なるという観察結果です。 これは全体的にユーザーに混乱をもたらし、最悪の場合、ユーザーがatol値の設定について考えていない場合の誤検知テストになります。

特に、stdlibの実装： math.isclose()は、異なる、おそらくより優れたアルゴリズムとデフォルトを提供します。これは対称テストであり、rtolとatolを混合せず、デフォルトのatolは0.0です。

状況が理想的ではないというコンセンサスはほぼありますが、それについて何かをするのに十分悪いというコンセンサスはありません。

考慮されるオプション：

アルゴリズムやデフォルトの変更：

非推奨期間と警告があっても、下位互換性の問題のために普遍的に拒否されました-これらの関数はテストで広く使用されているため、少なくとも大きな迷惑になります。

別のアルゴリズムを選択するためのフラグ付きのパラメーターを追加する

これは既存のコードを壊すことはありませんが、醜くて紛らわしいAPIで永遠に存続します。

__future __- typeディレクティブの追加

TLDR：それは可能ですが、簡単でもクリーンでもありません。 誰もこれを追求したいとは思わなかった。

さらに別の関数を作成する

これは牽引力を得た唯一のオプションのようでしたが、議論に参加したコア開発者によってサポートされていませんでした。

これを「修正」する最もクリーンな方法は、新しいアルゴリズムとデフォルト（おそらくmath.isclose使用されているもの）を使用してnp.rel_close() [または他の名前]を追加することです。 新しい関数は、将来のコードで使用するための「推奨」関数として文書化されます。 将来、古い警告に非推奨の警告を追加することは可能ですが、現時点では、ノイズがそれだけの価値があるとは誰も考えていないようです。

交換を行うためにリファクタリングツールを構築することもできますが、この1回の使用で誰がそれを行うのでしょうか。

これにより、当面は2つの非常によく似た関数が作成され、「10年間そのように機能してきた他の関数とは動作がわずかに異なる新しい関数を導入することは、一般に非常に悪い考えです」。

結論：

わずかな利益のためにそれは価値がありませんが、より良いドキュメントが整い、それはここで行われます：＃10214

私はまだ1つの質問が残っています：

@njsmithは書いた：

"" "
私たちはすでに持っています：

allclose
assert_allclose
assert_almost_equal
assert_approx_equal
assert_array_almost_equal
assert_array_almost_equal_nulp
assert_array_max_ulp

このリストにオプションを追加しても、実際のユーザーに大きな違いはないと思います。
"" "

新しいものを追加するのは大丈夫だということですか？

私も注意します：

これらのほとんどはアサーションであり、アサーションの急増は単体テストアーキテクチャの副作用です。

私たちの多くが他のテストアーキテクチャ（例：pytest）に移行すると、アサーションの必要性がなくなります。

したがって、 numpy.testingをどうするかは、numpyコアをどうするかとは別の質問です。

私たちの多くが他のテストアーキテクチャ（例：pytest）に移行すると、アサーションの必要性がなくなります。

実際、これはそれ自体が危険です。 テストはassert_allclose(...)からassert np.allclose(...)に変更される可能性があり、サイレントに厳しさが緩和されます。これは悪いことです。

有用な失敗メッセージが表示されるため、pytest環境ではまだassert_allcloseを使用しています。

    def test_shs():
        a = [0.1, 0.2, 0.3, 0.4]
        b = [0.2, 0.3, 0.3, 0.4]

>       np.testing.assert_allclose(a,b)
E       AssertionError: 
E       Not equal to tolerance rtol=1e-07, atol=0
E       
E       (mismatch 50.0%)
E        x: array([ 0.1,  0.2,  0.3,  0.4])
E        y: array([ 0.2,  0.3,  0.3,  0.4])

vs assert np.allclose()

    def test_shs():
        a = [0.1, 0.2, 0.3, 0.4]
        b = [0.2, 0.3, 0.3, 0.4]
>       assert np.allclose(a, b)
E       assert False
E        +  where False = <function allclose at 0x7f20b13c9840>([0.1, 0.2, 0.3, 0.4], [0.2, 0.3, 0.3, 0.4])
E        +    where <function allclose at 0x7f20b13c9840> = np.allclose

pytest_assertrepr_compare実装することでそれを修正することは可能かもしれませんが、それを関数呼び出しに適用する方法がわからず、pytestがどこでそれを呼び出すかさえわかりません。

@ eric-wieser：書いた：

「実際、これはそれ自体が危険です。テストはassert_allclose（...）からassert np.allclose（...）に変更される可能性があり、サイレントに厳しさが緩和されます。これは悪いことです。」

まさに私のポイント-誰もがテストにアサートを使用することを想定するのは「悪い考え」であり、したがって、デフォルトのisclose（）とallclose（）がテストに適しているかどうかは関係ありません-理想的には彼らは確かにあるべき世界。

新しいものを追加するのは大丈夫だということですか？

いいえ、ほぼ同等のテストを表現するためのわずかに異なる方法の全体的な管理がすでにあることを考えると、残念ながら、ほとんどのユーザーはまだ気づいたり理解したりすることはありません-別の追加。

私も注意します：
これらのほとんどはアサーションであり、アサーションの急増は単体テストアーキテクチャの副作用です。
私たちの多くが他のテストアーキテクチャ（例：pytest）に移行すると、アサーションの必要性がなくなります。

それらはたまたまアサートとして記述されていますが、AFAICTはこれらの関数のすべてが、実際には「ほぼ等しい」という異なる定義をエンコードしています。 （私は思います。いくつかの区別は非常にあいまいなので、それらが本物かどうかはわかりません。）

アルゴリズムやデフォルトの変更：
非推奨期間と警告があっても、下位互換性の問題のために普遍的に拒否されました-これらの関数はテストで広く使用されているため、少なくとも大きな迷惑になります。

私はそれをそのように完全には言いません。 私にとって、これはコストを正当化するのに十分な利益をもたらす可能性がある唯一のアプローチです。 私は彼らがそうすると言っているので

たとえば、誰かが現れて「3つの大きなプロジェクトで提案された変更を試したところ、10,000回のテストのうち12回の追加の失敗につながり、そのうち8回は古いものによって隠されていた実際のサイレントバグでした。悪いデフォルト」...それはかなり説得力があるでしょう。 特にこれは、対象を絞った警告を行う技術的能力がある場合です。 実際の数字はそれほど有利ではないと思いますが、誰かがチェックするまでは、誰が知っていますか。

2017年12月18日月曜日午後3時57分、ナサニエルJ.スミス<
[email protected]>書き込み：

いいえ、私たちはすでに私たちが
残念ながら、ほぼ等しいテストを表現するわずかに異なる方法
ほとんどのユーザーはまだ気づいたり理解したりするつもりはありません-別の追加。

さて、1つの大きな違いがあります-それがしたのでそれらのそれぞれが追加されました
何か違う、そして浮動小数点の気まぐれで、それら
違いが重要になる場合があります。

新しい相対近接関数は本質的に同じことをしますが、
それを「より良く」しなさい。 そして目標は、新しいものを使用することを推奨することです
古いものの代わりに（そしておそらく最終的に古いものを非推奨にする）。

正直なところ、それがアイデアの賛成か反対かはわかりませんが、
しかし。

たとえば、誰かが現れて「提案された変更を3つの大きなもので試しました

プロジェクト、そしてそれは10,000のテストのうち12の追加の失敗につながりました、そしてそれらの
12、8は、古い悪者によって隠されていた実際のサイレントバグでした
デフォルト」...それはかなり説得力があるでしょう。特にこれは
対象を絞った警告を行う技術的能力がある場合。
実際の数字はそれほど有利ではないと思いますが、
誰かがチェックします、誰が知っていますか。

うーん、私のコードベースには約1500のテストがあります-10,000ではありませんが、私はそれを与えます
ショット。 他に何もなければ、私はバグまたは貧弱なテストを見つけるかもしれません。 またはもっと得る
安心！

やあみんな、

同僚がこの問題に遭遇した後、ここでチャイムを鳴らしたかった。

_免責事項：「ホールで火事」と叫び、これをフェンスに投げ込む前は、論理についてあまり考えていませんでした。 恥ずかしいハッシュを作ったのなら、親切にしてください。_

私には、これはすべて、古典的なアーキテクチャ/設計の「鶏が先か卵が先か」の問題、つまりセマンティクスと実装の問題によく似ています。 すべてのバグがコード内に存在するわけではなく、セマンティクス内に存在する場合もあります。 これは、アルゴリズムに欠陥があることを発見するためだけに完璧に実装されているアルゴリズムと（あるとしても）それほど違いはありません。バグはコードになく、アルゴリズムにありますが、どちらにしてもまだバグです。 基本的に、この議論は、「バグではなく、機能である」という古典的なジョークのように聞こえます。 もちろん、「選択」はそれだけですが、IMHOは通常、理論的根拠の終わりを示します。セマンティクスが実装されたままであるように選択された場合、実装はすべてクールで、議論の終わりです。

では、 isclose()の「望ましい」および/または「期待される」セマンティクスとは何ですか。これを考えると、ユーザー定義のセマンティクスに容赦なく収束することになります。つまり、ユーザーはセマンティクスを定義できる必要があります。 「閉じる」の定義。

デフォルト

デフォルトに関しては、これは最終的にセマンティクスを壊すことはありません。 ただし、不適切な選択は危険です。 ゼロ以外のデフォルトがabs(a - b) == 0場合に妥当な動作を与えるために選択された場合、これは間違いなく間違った解決策のように聞こえます。 この特定の状態は、意味的に特殊なケースであるため、特殊なケースである方がよいでしょう。 差分がゼロの場合、「閉じる」の定義に「小刻みに動く部屋」はありません。これは自己定義のコーナーストーンです。つまり、「閉じる」ではなく、「正確」です。ここで、「閉じる」は正確からの相対偏差です。 。 （_注：_条件付きの特別なケーシングは、パフォーマンスに影響を与える場合と影響を与えない場合があります。）

+ vs max

maxではなくsumを使用した実装による、 rel_tolとa_tolの混合または「シャドウイング」は、上記の関数のセマンティクスを破壊します。 ユーザーの「閉じる」の定義は、「相対的」と「絶対的」のセマンティクスを壊すため、自明ではない方法でバインドされます。上記のセマンティクスのみを考慮すると、この側面はバグです。 @ gasparkaを見つけ例を開くと、この点について反駁できない議論があります。

可換性（すなわち対称性）

唯一の2事業者は、ここでは本当にあります。 -でa-b 、および<=で|a-b| <= f(a, b, atol, rtol) 。 減算は反交換的ですが、 |a - b|はそうではありませんが、定義上、交換可能です。 ただし、これだけではf(a, b, atol, rtol)可換性を示すのに十分ではない場合があります。 しかし、ここには強い議論と弱い議論があります。

• 弱点は最も単純であり、関数分離のカプセル化または欠如ですが、算術的に|a - b|の可換性は、プログラム的にf(a, b, atol, rtol)の可換性を強制しない可能性がありますが、 f(a, b, atol, rtol)は実際にはそうではありません質問ですがisClose(a, b, atol, rtol) 。 ここで、計算|a - b|は、関数の内部で実行されます。つまり、 isClose() := |a-b| <= f(a, b, atol, rtol)です。 これは内部であり、 aとbが渡されるため、 |a-b|が可換であるためには、 isClose()も通過する必要があります。 そうでない場合、 |a-b|の可換性はすべての意味を失います。
• 強力な引数は：比較opが、厳密ではない、すなわち、それはある<=ではない<したがって、比較の平等部分のためにあなたが満足する必要があり、 |a-b| = f(a, b, atol, rtol)暗示たf(a, b, atol, rtol) _must_も可換でなければなりません（私は思いますか？）。 そうしないと、上記の等式が真ではない（これを満たすaとbの値がない）か、厳密な不等式<が実際に意味的に定義されていますよね？

これのすべてまたはいずれかについてあなたがする（またはしない）ことは、完全に別の質問です。