ラムダ式で、"+","*"はx,yをy,xと変えても結果は同じですので、問題ないのですが、(計算だとして)
"-","/"は逆だと意味が違います。?がついているとこはほぼ理解不能です。計算はしてくれますけど。
上の例では、漏れてましたが、初期値が0だと問題になるのが"/"でした。多分*では0になるだけで
エラーにはならないでしょう。
"-"の場合は状況に応じて、-(-100)が+100になってる場合もあるのかも知れません
こうなっている原因が不明だと、分かったとは言えませんね。
ラムダ式で、"+","*"はx,yをy,xと変えても結果は同じですので、問題ないのですが、(計算だとして)
"-","/"は逆だと意味が違います。?がついているとこはほぼ理解不能です。計算はしてくれますけど。
上の例では、漏れてましたが、初期値が0だと問題になるのが"/"でした。多分*では0になるだけで
エラーにはならないでしょう。
"-"の場合は状況に応じて、-(-100)が+100になってる場合もあるのかも知れません
こうなっている原因が不明だと、分かったとは言えませんね。
そうですね。そもそも「畳み込む」必要がないですし(笑)。
ただし、まぁ、練習はあくまで練習ですよ(笑)。
> 分からないのは、何使うんだろうか?ですね。こんな場面が想像できません。
まぁ、これも「練習だから」って言ってはおきますが・・・。
原則、forを使って何か書きたい、って思った時に毎回reduceが使えないか?って自問することです。
厳密に言うと、Pythonの場合、forで繰り返しを書きたい、って思った際、
1. まずはリスト内包表記が使えないか考える。
2. リスト内包表記が不適切臭い、って思った時、reduceが使えないか考える。
の2つを必ず候補として考える、って事です。殆どの場合リスト内包表記があればどーにかなる。「どーにかならなかった」ケースの時、reduceが使える可能性がある。
実際やってみれば、恐ろしいくらい素のforの登場確率は減っていきます。
よく見ると、同じですね。少しは分かったかも。分からないのは、何使うんだろうか?ですね。こんな場面が想像できません。
K: reduce(lambda x, y: y/ x, [100, 200, 300], 10) =>
300/(200/(100/10))
Q: reduce(lambda x, y: y - x, [100], 0) => 100 - 0 => 正解!
Q1: reduce(lambda x, y: y - x, [100], 50) => 100 - 50 => 正解!
R: reduce(lambda x, y: y - x, [100, 200], 0) => 200 - (100 - 0)
R1: reduce(lambda x, y: y - x, [100, 200], 50) => 200 - (100 - 50)
R2: reduce(lambda x, y: y - x, [100, 200, 300], 0) => 300 - (200 - (100 - 0))