  |
はてなキーワード: 引数とは
まず前提として、俺はstaticおじさんではない
pythonがメインなので、仕事上でstaticを使ったことはない
しかし前職で巨大なユーティリティモジュールを書く機会があったが、引数にのみ依存していればいい関数しか存在しなかったので、staticを使ったことはある
mathライブラリはあくまでも例だが、引数にのみ依存するツールボックス的な用途でモジュールを作ることはある
pythonであれば単にクラスを使わないで書けば実現できるが、javaで同じことをやろうとするとstaticおじさんのやり方になる
ジョン・フォン・ノイマンのミニマックス定理は、ゲーム理論の数学的な領域で、最大-最小不等式が等式でもあることを保証する条件を提供する定理。
この定理は、1928年に発表されたゼロサムゲームに関するフォン・ノイマンのミニマックス定理が最初であり、ゲーム理論の出発点と考えられている。
具体的には、フォン・ノイマンのミニマックス定理は次のように述べられる：
$$
\text{Let } X \text{ and } Y \text{ be compact convex sets. If } f \text{ is a continuous function that is concave-convex, i.e. } f \text{ is concave for fixed } y, \text{ and } f \text{ is convex for fixed } x. \text{ Then we have that }
$$
$$
\sup_{y \in Y} \inf_{x \in X} f(x, y) = \inf_{x \in X} \sup_{y \in Y} f(x, y)
$$
特に、fがその両方の引数に対して線形関数（したがって双曲線）である場合、定理は成り立つ。したがって、有限行列Aに対して、次のようになる：
$$
\sup_{y \in Y} \inf_{x \in X} x^T A y = \inf_{x \in X} \sup_{y \in Y} x^T A y
$$
上記の形式では、Aはペイオフ行列。この特殊なケースは、各プレイヤーの戦略セットが行動（混合戦略）のロッタリーであり、ペイオフが期待値によって誘導されるゼロサムゲームに特に重要。
コードを簡潔に保つにはモジュール化が必須である。しかし同じモジュールに関係のない機能が含まれていたりすると混乱の元になる。
一方で、関数というのは引数の細かな仕様に依存せずに、汎用的に呼び出せた方が何かと好都合だ。引数になんらかのオブジェクトを渡し、そのオブジェクトしか持ち得ないような特殊な情報で処理を行なったりすると、関数とオブジェクトが互いに依存しあってしまう。
これはモジュールの結合度と呼ぶ。
高い凝集度、低い結合度によってモジュールを作れば、保守性は上がる。
さらにモジュール内では、公開する必要のない関数はprotectedまたはprivateにするべきだ。
そのためにはモジュールが公開すべき関数についてインターフェイスを作り、公開関数に対するユニットテストを書いておくのが良いだろう。
標準ライブラリのすべての関数のありとあらゆる引数に対する挙動を把握している？
標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、
入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます
「ゾウリムシよりも蟻は大きい」を「蟻は大きい」で切って引用するのはやめましょう
規模が大きくなると信頼できない、その場しのぎ的な技術であるのはpythonなどのスクリプトの実行環境も同様です
すべての処理、すべてのプログラムをRustで書くような行為はきわめて非生産的ですし、シェルスクリプト以上に危険です
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
メンテナの数、レビューする人数、実際に動作している環境etc
僕はプログラミング歴2週間の初心者です。キーと値を入力できるデータベースを作っています。
以下のコードを実行してデータを追加し続けると、一定のサイズを超えるとエラーが出てしまうみたいです。
理想は、データが追加された後にサイズが足りなくなったら動的に自動拡大されることです。
もし詳しい人がいたらご教示お願い致します。
import sys import os import mmap import hashlib def h(x): return int(hashlib.sha512(x.encode()).hexdigest(), 16) def create_db(filename): with open(filename, 'wb') as f: f.write(b'\0' * 1024 * 1024) # 1MBの空ファイルを作成 def set_key(filename, key, value): with open(filename, 'r+b') as f: mm = mmap.mmap(f.fileno(), 0) pos = h(key) % mm.size() while mm[pos:pos+1] != b'\0': pos = (pos + 1) % mm.size() if pos == h(key) % mm.size(): f.seek(0, os.SEEK_END) f.write(b'\0' * mm.size()) # ファイルサイズを2倍にする mm = mmap.mmap(f.fileno(), f.tell()) # ファイルサイズを反映させる pos = h(key) % mm.size() # ハッシュ値を再計算する data = key + '\0' + value + '\0' data = data.encode() mm[pos:pos+len(data)] = data mm.close() # mmapオブジェクトを閉じる def get_key(filename, key): with open(filename, 'r+b') as f: mm = mmap.mmap(f.fileno(), 0) pos = h(key) % mm.size() while mm[pos:pos+1] != b'\0': end = mm.find(b'\0', pos, mm.size()) # 第2引数と第3引数を指定する if end == -1: end = mm.size() if mm[pos:end].decode() == key: pos = end + 1 end = mm.find(b'\0', pos, mm.size()) # 第2引数と第3引数を指定する if end == -1: end = mm.size() value = mm[pos:end].decode() mm.close() # mmapオブジェクトを閉じる return value pos = (pos + 1) % mm.size() if pos == h(key) % mm.size(): break mm.close() # mmapオブジェクトを閉じる return None def main(): cmd = sys.argv[1] if cmd == 'create': create_db(sys.argv[2]) elif cmd == 'set': set_key(sys.argv[2], sys.argv[3], sys.argv[4]) elif cmd == 'get': print(get_key(sys.argv[2], sys.argv[3])) if __name__ == '__main__': main()
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか？同じものを表すのに関数ごとに別の変数名を付けているとか？
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか？
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
自分には6年付き合った年上の彼女がいた。名前はPHP。学生の時からの付き合いで、自分にとっては初めての彼女だった。付き合った当初は全てが新鮮で、オブジェクト指向やSOLID原則、大事なことは全て彼女から教えてもらった。（そう思われるかもしれないが、）時間が経って彼女の魅力が感じられなくなってしまったということはなくて、彼女は歳をとっても魅力的なままだった。むしろreodonlyプロパティやEnum、null safe演算子など、新しい機能が導入されてますます綺麗になっていったように思う。最近ではジェネリクスさえ導入されたようだ。彼女は本当に努力家だ。
（褒められた話ではないが一応、彼女以外の女性を全く知らなかったわけではなく、TypeScriptという若い子と少し遊んでいたこともある。TypeScriptは昔からの知り合いのJavaScriptの妹で、大雑把な姉と違って几帳面で、少しオタク気質もある個性的な子だった。よく新しい型パズルを考案して楽しそうに話してくれたが、自分には正直よく分からなかった笑。）
そんな中でも基本的には6年間PHPとずっと一緒に過ごしてきた。前述の通り彼女に何か不満があったわけではない。ただ、彼女との将来に不安を覚えるようになってしまっていた。周囲に彼女と付き合っていることを話すと、「え、まだPHPと付き合ってたんだ？（昔は人気だったけど、最近はそうでもないよね）」みたいなことを、彼女のことをよく知らない人から言われたりもした。そこまで直接的ではなかったけれど。自分も、彼女以外の女性のことをほとんど知らずにずっと彼女と付き合っていて大丈夫なのかななんて思ってしまったりしていた。
結局自分はPHPと別れて、新しい女性と付き合う決断をした。新しい彼女の名前はGo。彼女は若いのに自分の芯がしっかりしていて、みんなの憧れの格好良い女性といった人だった。そんな彼女と付き合いだして、最初は戸惑うことも多かった。
例えばこんな感じだ。
また、今まで当たり前だと思っていたPHPの良さに気づくことも多い。PHPStanを使えば静的型付け言語と同じように型安全性を担保できていたし、彼女のWeb FWには歴史が長いだけあって痒いところまで手が届く様々な機能が完備されていた。経験豊富でこちらの要望をなんでも受け止めてくれるような包容力があったことに今更気づいた。
とはいえ、いつまでも昔の彼女を引きずっていてもしょうがない。Goにはこちらに積極的に合わせてくれるような包容力はないが、彼女なりの哲学を持っていてそれ故の美しさがあると思う。そして正直、まだ彼女の10分の1も理解できていない。彼女が得意だという並行処理や、実行速度が求められるような処理も、自分はまだ実際に実装したことはない。でもこれからしっかり向き合って、Goのことをもっと理解して、実りのある交際にしていきたいと考えている。PHPと別れてGoと付き合う決断したのは自分なのだから。
オブジェクト指向とかかっこいい言い方をしても無駄だ。従来の構造化プログラミングから進歩したことなど一つもない。オブジェクト指向がなぜダメであるのか、それを今から話すぜ。
1. データと処理をまとめるという発想。
データと処理をまとめてクラスとして置くという発想がある。しかし、このようなことをしなくとも、モジュールという単位で利用データと処理の集合をまとめればよかったので、クラスを使う必要はない。しかもクラスはインスタンス化のときに、不要な情報まで持ってくるのでメモリ効率が明らかに悪い。コンピュータが進化しているからメモリのことはあまり考える必要がないとはいえ、必要ない処理をまとめて閉じ込めるのは無駄が多い。なぜクラスという名詞で概念分類できると考え始めたのかは不明だが、アルゴリズムとデータ構造という構造化プログラミングの手法を、クラスと型というパラダイムに変換することで型にうるさいC++馬鹿を生み出し、彼らが発狂することになってしまった。しかもデータと処理にわざわざ依存関係を持たせて、変更に対する柔軟性を失わせている。
2. 継承
継承によって既存の構造を持ってこようとする必要性が全く無い。それどころか、継承を使うことによってプログラムがスパゲティ化し、依存関係のグラフがややこしくなってしまう。継承など使わず、必要な情報はスコープの限られた共通の変数、または関数の引数として用意しておけば良い。もしクラスをどうしても使いたければ、共通のインターフェイスをもたせたほうがマシである。インターフェイスを使えば、クラス利用者が意識すべきpublicメソッドがなんであるか把握できる。
3. カプセル化
オブジェクト指向の中で役立つ概念はカプセル化だけである。しかし、カプセル化はクラスなしで構造化プログラミングの方法で実装できる。pythonでは、モジュールの中でアンダースコアから始まる関数を用意しておけば、それがprotectedやprivateと似たように機能させることができる。オブジェクト指向がなぜカプセル化が独自の概念だと言い始めたかは謎。
4. ポリモーフィズム
同じ名前のメソッドを、入力に応じて処理の内容を変える。このようなことはオブジェクト指向などと誇大宣伝をするほどのことでもない。構造化プログラミングで似たようなことができる。
ChatGPT
1対1のトーナメント戦を行います、例えばサッカーのワールドカップみたいなものですね。
引き分けは無しとするよ。
1対1のトーナメント形式で、引き分けがない場合、各試合には勝者が1人おり、その勝者が次のラウンドに進みます。したがって、チーム数がnの場合、全試合数はn-1となります。なぜなら、トーナメントの最後には1チームだけが残るため、n-1チームが敗退しなければならないからです。
def calculate_total_matches(n):
if isinstance(n, int) and n ＞= 2:
return n - 1
else:
return "チーム数は2以上の整数で入力してください。"
try:
teams = int(input("トーナメントに参加するチーム数を入力してください: "))
print("全試合数:", calculate_total_matches(teams))
except ValueError:
でもさ、未だに Python2 しか書けない残念なアラフィフもいるのさ。EOL 来ていても中途半端に需要もあるせいか、引退時期を間違えるやつも多いのがこの業界の悪いところなんだよ。そいつさ、未だに Private な関数の書き方がわかんないみたいだし、is とか使うのだぜ？オブジェクト指向とかいうレベルでないし、引数の型を指定する意味とかも「めんどくさいよね」とか言って勉強しないんだよ。はっきり言って、消えてほしい。だから、ほんとうは勉強しないと消えざるを得ない世界のがまともなんだよ。おそらく彼は３年以内には仕事がなくなるだろうけど、年金をもらえるまで20年ぐらい無職かもしれない。リカレント教育とかも、年齢制限あるからな。コンバートは早めにだな。
