  |
はてなキーワード: オブジェクトとは
意外なほど反応ついてたけど読まず返事せず続ける。というか言いたいことの１割も書いてないので返事してたら続けられない。
読み返しててアズレンとブルアカが混ざっててどっちの話だかわからなくなってるが、すまん。
神バハだって当時すごい盛り上がって楽しかっただろというのは自分もそうですはい。
三目並べだって楽しめれば別にゲームとして欠陥あっても関係ないというのもその通り。
この場合、ゲームデザインとして実際のゲーム内容とゲームのルックが嚙み合ってないのが、よろしくないと感じる理由になる。
つまり、なんか雰囲気がドルフロに似てるなあという類似が、ゲームの性質からくるのではないと考えるからだ。
ゲームジャンルが同じだと見た目が同じになるのはむしろ当たり前。ファイアーエムブレムとラングリッサーが見た目が似てると言って怒るのは…譬えが悪かった。
艦これとアズールレーンでいうと、艦これはジャンル分けが難しいオリジナルジャンルだがああいうゲームで、アーケード艦これは３Dのアクション？ゲーム。アズールレーンは２Dシューティング。アズレンがアーケード艦これのルックにあえて似せる必要は特にない。が、実際、なんかそれっぽくなってしまってる。
パクリではない。キャラクターは独自の２Dに落とし込んであるし、ゲームシステムも違う。別物である。
ただ、軍艦モチーフのヒット作の後追いで出た軍艦モチーフゲームのゲーム画面の全体のルックが、ゲームシステム上の要請によるものでなく、なんとなく似てる。
おそらくは、参考にしました、ということだろう。
アズレンの場合、一番近いのは二次創作同人ゲーだと思う。キャプテン翼のやおい同人誌を商業向けに絶愛にしました、みたいな…譬えが悪いか。
気にする奴は気にするが、気にしないやつは気にしない、ただネタ元へのリスペクトは本当にあるんか？ と思いたくなるような微妙な感じだ。
この場合、似てるから悪いのではなく、似てないことが気持ち悪さの原因になっている。別にネタ元のニュアンスをあえて残す必要がないのに残ってしまってるのが、単なる素材として雑に扱ってるんだろうなと感じるのである。自分は。
ブルアカでも、同様の、パクリではないけど…を感じ取ってしまう。
基本的にゲームシステムは生煮えである。２Ｄキャラがちょこまかと動きまわり、いろんなアクションを取るところが一番のセールスポイントであるのは間違いないが、それを使ってゲームシステムとしてうまくできてるかというと、見た目がちょっと豪華になっただけというのが正直なとこだろう。
プレイヤーが操作可能な範囲とゲーム画面のルックがうまく繋がってない。範囲攻撃の範囲指定ぐらいだろうか。回避指示はごく少数の特定キャラしか使えないし。ＡＩオートにすると本当に頭が悪すぎるのでスキル使用はプレイヤー操作するしかないのだが、正直、ここまでオートが使い物にならない理由がわからないぐらい使えなさすぎる。なんとかゲームっぽさを演出しようとして、プレイヤーのやることを無理やり残すためにオートをあえて役立たずにしたのではないかと疑っている。
美少女が実銃で銃撃する動作を頑張って作ろうという熱意は凄くある。あるが、ゲームにはならなかった。
銃と美少女という組み合わせだけが先行してて、後が続かなかった。
さて２D銃撃部分ではグラフィックが先行してゲームデザインが追い付かなかったという話なのだが、そうなると気になるのが「もう一方のゲーム画面」であるフロアマップ。
メインと銘打ったステージで見れるのだが、これは完全に、まったく、寸分の違いもなくドルフロそのまま。ユニットの動かしかたまで同じだし、マップ上のオブジェクトも似てる。
ドルフロでは、マップはゲームの中心部分として機能していた。最初に見ると艦これの海域マップみたいに見えるが上手くアレンジしてあって、要は戦術シミュレーションのマップの簡略化した形だ。ゲームデザインとしての中心部分なので先に進むほどマップが大きくなり難易度が上がり、そのうちスマホだとマップを見ることすら不可能みたいなことになり（ゲーム公式がPCエミュでのプレイを推奨してたぐらい）、ライトユーザーが引くぐらいなことになるのだが、そのぐらいゲームとしての意味がちゃんとあった。
ブルアカでのマップは、ドルフロの凶悪マップを反面教師としたのだろう、基本的に戦術シムみたいなことは一切ない。というかやらせてくれない。代わりにボタン押しギミックがやたら増えた。
結果、マップはあっても、実際のユニットの移動ルートは実質１つだけ、というのが現在のブルアカのマップである。この部分はトライアンドエラーで運営の用意した正解を引くパズルみたいなもので、プレイヤーのやれることはほぼない。こうなってくると、マップ攻略はほぼ作業でしかなく、こんなことやらせず戦闘だけ抜き出して置いておけばいいだろ、という気分になってくる。
書いてみて思ったが、自分がドルフロとブルアカを対比してしまうのは、かなりの部分ここだと思った。ドルフロは艦これフォロワーとして作られたがゲーム部分は独自性が強く、艦これから受け継いだように見える部分でも自作品に合わせるように作り変えてあり、ゲームのルックとゲームデザインの間に乖離がない。ブルアカはドルフロから全く変えずに完コピしたが、（おそらくソシャゲとして楽に遊べるようにするためにという思惑もあって）その完コピした部分はゲームとしての機能を失い煩雑なだけの盲腸となってしまってる（かといってマップをなくすのも微妙かもしれない。先述したように２Dキャラ銃撃部分はプレイヤーがやることがあるように見えて少ない、基本的にキャラを愛でるためのパートだ。形骸化してるとはいえマップをなくしてしまうと、ただでも少ないゲームっぽさがさらに失われてしまうことになる）
ドルフロと同じなことについて「真似した」以外の理由が思い浮かばなくなってしまっている。このへんの真似っぽさは「銃と美少女」というセールス部分からは外れたとこなので雑にやっつけちゃったんだろうが、ここがあるからこそ、「銃と美少女の組み合わせなんて過去にいくらでも前例がある、別にドルフロは関係ない」と言いづらくなっている。ゲームシステムとしての合理性がありプレイヤーのゲーム体験としてうまく昇華させていれば、同じジャンルだから似てるだけと言えてたはずだ。
自分がブルアカのゲームデザインが雑なのが、単に雑であるよりあかんとこだと思う理由は、上記となる。
まだまだ続きます。
見た通り基本お気持ち表明なのでそのように。
プログラミング言語側に組み込まれている「型」だけでなく、プログラマーが独自に「型」を定義する方法も用意されています。
struct、class、interface、type, enumなどを使って独自の「型」を定義します。
開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります。
多数の「型」を分類し、組織化するために名前空間を利用します。
近年「クラス」が「型」の定義であるという基本概念を理解していないエンジニアが増えているので、エンジニアを採用する際には注意しましょう。
ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています。
例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。
業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります。
これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます。
CPUは機械語しか理解できません。一方で人間は機械語でプログラミングすることは困難です。
人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。
CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまいます。
そこで、人間にとってプログラムを読みやすくすることと、CPUに意図しない演算をさせないために、データの種類を表す「型」という概念がプログラミング言語に用意されるようになりました。
金融やECサイトなどのお金の計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。
メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります。
例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。
オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。
これだから3Dオブジェクトのコピペゲーをなんとも思わず消費するSteamユーザーは嫌いなんだ
ゲームってのはパン作りのように粉からこねて自分で作ってこそクリエイターの思想が反映されるってもんだ
それすらこだわる気がないのに、見栄えのするゲームを手抜きで量産していくことに、意味はあるのか！
それは最終的に、人がゲームから受けるセンス・オブ・ワンダーを損ね、薄味なゲーム文化体験を推進してしまうことになる
ゲームにおけるQoLが下がればゲームという産業それ自体がパチンコのようなものに成り下がってしまうおそれがある！
事実、買い切りだからという紛い物の安心感のために、クリエイターたちの血と汗が数百円で安売りセールされる地獄がそこにあるだろ！
そういう環境を作ってるのはあんたらだ！ そうなれば作り手もいかに手抜きしつつ一発当てるかしか考えなくなる！ ソシャゲと同じだろ！！
同じ2Dスプライトやドットキャラ、聞いたことあるBGMを使いまわすようなRPGツクールゲーばかりになった世の中を想像してみろ！
それはDLsiteでは現実になってるが、同人だからこそ許されてるもんだろ
企業として多くの人が連携してものづくりをするなら、そんな域にとどまってコピペゲーで満足する志じゃいかん！
module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。
でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合は分岐コードが増えて共通関数の保守コストが上がる。
あとありがちなのは、php開発者が関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。
とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスのフィールドに関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドとメソッドを追加して、さらに進むとユーザーとは無関係な機能も含めすべてをユーザークラスに定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。
先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。
ingressを離れた諸氏は知らないだろうが、最近のingressには、OVER CLOCK HACKなるものがある。簡単にいえば3D版グリフハックだ。
お馴染みのグリフが3DのARオブジェクト上に表示されるので、それを解読・記憶して2Dのグリフを入力する。
そうすると、正解率に応じてとんでもない量のアイテムがもらえるというミニゲームだ。
私は元々ingressのグリフハックが好きで、グリフとそれらを組み合わせた頻出熟語（例：human + civilization）や、LV8のグリフハックのパターン（例：create + pure + future + human + civilization）も結構覚えてる。
しかし、そんなグリフハック好きな私でも、OC HACKだけは無理だ。
難易度が高いからこそリソースが沢山もらえるってことなんだろうが、ミニゲームとしての完成度が低過ぎて、やっててストレスしか溜まらない。本当につまらん。
石川の能登は冷やかしどころかボランティアすら断るほどインフラが壊滅していて、現地入りした人が色々と叩かれてるけど、ぶっちゃけSNSにあげるかどうかは別として震災直後の現地を観光してみたいって気持ちはある
311のときの東北は津波で街が流されていて壊滅した瓦礫ばかりである意味圧巻だったようだが、残念なことにそれを見ることなく終わってしまった
なお、そこから1年後に現地入りしてもまだ瓦礫が残っていて被災地としての風情があった(意訳)と知人が言っていたけどね
例の奇跡の一本松とかは今は立派な観光名所になってるがあれはただのレプリカで、本物は震災直後の数週間でしか見れなかった(塩害で死んだので)
岩手の大槌町では建物上に乗り上げた船とか風光明媚なオブジェクトもあったがあえなく解体されたんだが、むしろああいうの残しておけば観光地として生きながらえて過疎地にならずすんだはず
まだ産まれてないが阪神・淡路大震災の崩壊した高速道路とかああいうのもさっさと解体撤去されたけど、ああいう非現実的なものを見れた人が羨ましい
石川の被災地は風情のある古民家が多いしプチ京都みたいな町並みだったが、それが倒壊しまくってる姿は、まさに東京大空襲や関東大震災のときの東京を彷彿とさせてくれるのではないか
これは見たい・・・是非とも見てみたい・・・そういう思いがムクムクと元旦からこみあげてくる
というので連休はまだまだ続くので、被災地入りしてみようかなと思っている
今は関西の某所に住んでいるが、石川の首都である金沢はほとんど無傷でインフラは生きているので、そこまで車や公共交通機関で行ったあとあとは自転車あたりで能登半島まで行ってみたい
例の倒壊した輪島塗の五島屋とか特に立ち入り制限されてないらしいから真っ先に見て写真とってこようと思う
でも炎上はしないだろうね
僕はプログラミング歴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()
コードを書く上で重要なことは？という質問に対して、アスペならば「実行できること」と答えるだろう。
当たり前なことしか言っていない。「実行できること」という文からは全く有益な知見を得られない。
実行できることは重要性ではなく、必要性である。重要性とは、必要なことをすべてやった上でなおやる価値のあることを意味する。
そう考えた時に私がよく思うのは「最短時間で理解可能」であることが重要であると思うわけである。
しかしここに宗教がある。そもそも、人間が物事を理解するプロセスは人それぞれである。
私は一度、関数やモジュールで適切に分離するためのリファクタリングというものを行ったことがある。
というのも、一つの関数に万を超える行が書かれていたため、上司がリファクタリングを命令したためである。
具体的詳細はprivateメソッドに、公開する必要のあるものはpublicメソッドに移した。
そして当初働いていた職場での反応はどうだったかというと、「スパゲッティコード」だというのだ。
スパゲッティコード？一つの関数に万を超える行があるほうがスパゲッティだと普通は思うだろう。
ところが、彼らの脳内では、「常にコードの詳細が見えていなければ気がすまない」という、カプセル化を無視する思想で動いていたため、関数化すると関数の最下層まで辿らないと気がすまないらしかったのである。
このようにして、教育の無い人間はコードの読み方もカプセル化も知らないので、非生産的な方法が最短の方法になってしまうのである。
コードを最短で理解するためにはどうするのか。基礎知識を教育された集団の中に身を置くのがまず先決である。
例えばcalc_monthly_salary_yen(Person p)という行が存在した時、いちいちcalc_monthly_salary_yenの中身を常に見に行くような人たちはダメだ。
「人間のデータを入力すれば円単位で月の給料を計算してくれるんだろう」とざっくりと自然言語的に読み進められる人たちでなければ「最短理解」は難しい。
つまり最短理解するためのコードを書いた時に、それが本当に最短理解されるためには事前の教養が必要なのである。
開発手法でしっくり来てるのがAndy HuntさんのTracer Bullet Developmentで、開発の方向性を示すのに試作を作る方法。
1. 主要なシステム オブジェクトを定義。UI、サーバー、ロジックビット、データベース抽象化レイヤー等。
3. データフローを実現するために API とその戻り値をコーディング。
4. 単体テストを使用して API の予想される使用法を文書化。
5. 各 API に必要な量の既定のデータ (別名、ダミー データ、偽のデータ、ハードコーディングされたデータ) を追加して、API が「実行」されるようにする。
6. あらかじめ用意されたデータを実際の機能に段階的に置き換える。
7. コードをリファクタリングし、システム オブジェクトを調整し、完了するまでこれを続ける。
お前のいう通り書いたったわ(C#だが)。
//宇宙 namespace Universe { //あらゆる神の根底に存在する唯一神とその司る運(スーパークラス) public class GodLuck { public string Name { get; } //神の名前 public string Power { get; } //神の力 public string Plan { get; } //神の計画 public string Factor { get; } //運の要因 public GodLuck(string name, string power, string plan, string factor) { Name = name; //神の名前 Power = power; //神の力 Plan = plan; //神の計画 Factor = factor; //運の要因 } //神が何かを創造するメソッド public void Create(string thing) { Console.WriteLine($"{Name} created {thing}."); } //神が何かに対して支配や介入をするメソッド public void Control(string thing, string action) { Console.WriteLine($"{Name} {action} {thing}."); } //運が何かに対して影響を与えるメソッド public void Affect(string thing, string outcome) { Console.WriteLine($"{Name} affected {thing} and the outcome was {outcome}."); } } //恵比須様 public class EbisuSama : GodLuck { public EbisuSama() : base("恵比須様", "商売繁盛や五穀豊穣の力", "人々に幸せを与える計画", "商売繁盛や五穀豊穣の要因") { } //作物を守る public void Save(string crops) { Control(crops, "守る"); } //人間を成功させる public void MakeSuccessful(string person) { Affect(person, "成功"); } } }
(大いなる力を別のクラスに移譲したくなったが、神と大いなる力は同一のオブジェクトという要件があるからやめた)
//宇宙 namespace Universe { //神の振る舞いを定義したインターフェイス public interface IGodLuck { public string Name { get; } public string Power { get; } public string Plan { get; } public string Factor { get; } //神が何かを創造するメソッド public void Create(string thing); //神が何かに対して支配や介入をするメソッド public void Control(string thing, string action); //運が何かに対して影響を与えるメソッド public void Affect(string thing, string outcome); } //恵比須様 public class EbisuSama : IGodLuck { public string Name { get; } //神の名前 public string Power { get; } //神の力 public string Plan { get; } //神の計画 public string Factor { get; } //運の要因 public EbisuSama() { Name = "恵比須様"; //神の名前 Power = "商売繁盛や五穀豊穣の力"; //神の力 Plan = "人々に幸せを与える計画"; //神の計画 Factor = "商売繁盛や五穀豊穣の要因"; //運の要因 } //神が何かを創造するメソッド public void Create(string thing) { Console.WriteLine($"{Name} created {thing}."); } //神が何かに対して支配や介入をするメソッド public void Control(string thing, string action) { Console.WriteLine($"{Name} {action} {thing}."); } //運が何かに対して影響を与えるメソッド public void Affect(string thing, string outcome) { Console.WriteLine($"{Name} affected {thing} and the outcome was {outcome}."); } //物を守る public void Save(string thing) { Control(thing, "守る"); } //人間を成功させる public void MakeSuccessful(string person) { Affect(person, "成功"); } } }
馬鹿がオブジェクト指向をやると一つのクラスに全部の機能を突っ込んだりする
そういう状態になったものを神クラスといい、インスタンス化したものは神オブジェクトという
EchsSee(仮)という謎のクラスに全機能が詰め込まれていた
最初はHTMLの表示をデバイスごとに振り分けるヘルパークラスでしかなかったが、馬鹿が「便利だから」などといって無関係のフィールドとメソッドをどんどんEchsSeeに詰め込んだ
EchsSeeは高頻度に更新される上に、更新による失敗が全システムに影響を与えたため、開発者は「EchsSee触るの怖いんですよね」などと言うようになった
万物に神が宿り、万物が神になる世界なので、神が人や世界を支配しない
『西洋宗教において神と運は別のオブジェクトだが、日本の古典な宗教観においては神や大いなる力は同一のオブジェクト』、これを生成させるまではうまくいったんだけどね
bingちゃん:
西洋宗教では、神と運は、プログラムでたとえると、別々のオブジェクトとして存在すると考えられます。神は、人間や自然に対して意志や計画を持つ創造者や支配者として表現されます。運は、人間や自然に対して予測や制御ができない偶発的な要因として表現されます。
# 神と運のオブジェクトを定義する class God: def __init__(self, name, power, plan): self.name = name # 神の名前 self.power = power # 神の力 self.plan = plan # 神の計画 def create(self, thing): # 神が何かを創造するメソッド print(f"{self.name} created {thing}.") def control(self, thing, action): # 神が何かに対して支配や介入をするメソッド print(f"{self.name} {action} {thing}.") class Luck: def __init__(self, name, factor): self.name = name # 運の名前 self.factor = factor # 運の要因 def affect(self, thing, outcome): # 運が何かに対して影響を与えるメソッド print(f"{self.name} affected {thing} and the outcome was {outcome}.")このコードでは、神と運は、それぞれ異なる属性や機能を持つオブジェクトとして定義されています。神は、名前、力、計画という属性と、創造、支配という機能を持ちます。運は、名前、要因という属性と、影響という機能を持ちます。神と運は、それぞれの機能を使って、人間や自然に対して作用することができます。例えば、以下のようなコードが考えられます。
# 神と運のオブジェクトを作成する god = God("Zeus", "lightning", "maintain order") luck = Luck("Tyche", "chance") # 神と運が人間に対して作用する god.create("human") luck.affect("human", "good") god.control("human", "bless") luck.affect("human", "bad") god.control("human", "punish")しかし、日本の古典的宗教観では運と神や大いなる力は同じオブジェクトです。神が運を司っています。
# 神と運は同一のオブジェクトとして定義する class GodLuck: def __init__(self, name, power, plan, factor): self.name = name # 神の名前 self.power = power # 神の力 self.plan = plan # 神の計画 self.factor = factor # 運の要因 def create(self, thing): # 神が何かを創造するメソッド print(f"{self.name} created {thing}.") def control(self, thing, action): # 神が何かに対して支配や介入をするメソッド print(f"{self.name} {action} {thing}.") def affect(self, thing, outcome): # 運が何かに対して影響を与えるメソッド print(f"{self.name} affected {thing} and the outcome was {outcome}.")このように、神と運は同一のオブジェクトとして扱われます。例えば、恵比寿さまは商売繁盛や五穀豊穣の神であり、同時にそのような運をもたらす要因でもあります。以下がその例です。
# 恵比寿さまのオブジェクトを作る ebisu = GodLuck("恵比寿さま", "商売繁盛や五穀豊穣の力", "人々に幸せを与える計画", "商売繁盛や五穀豊穣の要因") # 恵比寿さまが何かを創造する ebisu.create("鯛") # 恵比寿さまが何かに対して支配や介入をする ebisu.control("農作物", "守る") # 恵比寿さまが何かに対して影響を与える ebisu.affect("商人", "成功")恵比寿さま created 鯛. 恵比寿さま 守る 農作物. 恵比寿さま affected 商人 and the outcome was 成功.
日本語で聞いてるのになんでその回答になるんだよ、面倒くせぇ
ぜんぜん中立じゃないじゃんな
具体的にはBingちゃんが神の計画・神の支配の文言含んだ回答を生成しちゃったら
日本は八百万の神がいる世界。万物に神が宿り、万物が神になる世界なので、神が人や世界を支配しない
『西洋宗教において神と運は別のオブジェクトだが、日本の古典な宗教観においては神や大いなる力は同一のオブジェクト』、これをBingちゃんに生成させるまではうまくいったんだけどね
bingちゃん：
西洋宗教では、神と運は、プログラムでたとえると、別々のオブジェクトとして存在すると考えられます。神は、人間や自然に対して意志や計画を持つ創造者や支配者として表現されます。運は、人間や自然に対して予測や制御ができない偶発的な要因として表現されます。
# 神と運のオブジェクトを定義する class God: def __init__(self, name, power, plan): self.name = name # 神の名前 self.power = power # 神の力 self.plan = plan # 神の計画 def create(self, thing): # 神が何かを創造するメソッド print(f"{self.name} created {thing}.") def control(self, thing, action): # 神が何かに対して支配や介入をするメソッド print(f"{self.name} {action} {thing}.") class Luck: def __init__(self, name, factor): self.name = name # 運の名前 self.factor = factor # 運の要因 def affect(self, thing, outcome): # 運が何かに対して影響を与えるメソッド print(f"{self.name} affected {thing} and the outcome was {outcome}.")このコードでは、神と運は、それぞれ異なる属性や機能を持つオブジェクトとして定義されています。神は、名前、力、計画という属性と、創造、支配という機能を持ちます。運は、名前、要因という属性と、影響という機能を持ちます。神と運は、それぞれの機能を使って、人間や自然に対して作用することができます。例えば、以下のようなコードが考えられます。
# 神と運のオブジェクトを作成する god = God("Zeus", "lightning", "maintain order") luck = Luck("Tyche", "chance") # 神と運が人間に対して作用する god.create("human") luck.affect("human", "good") god.control("human", "bless") luck.affect("human", "bad") god.control("human", "punish")しかし、日本の古典的宗教観では運と神や大いなる力は同じオブジェクトです。神が運を司っています。
# 神と運は同一のオブジェクトとして定義する class GodLuck: def __init__(self, name, power, plan, factor): self.name = name # 神の名前 self.power = power # 神の力 self.plan = plan # 神の計画 self.factor = factor # 運の要因 def create(self, thing): # 神が何かを創造するメソッド print(f"{self.name} created {thing}.") def control(self, thing, action): # 神が何かに対して支配や介入をするメソッド print(f"{self.name} {action} {thing}.") def affect(self, thing, outcome): # 運が何かに対して影響を与えるメソッド print(f"{self.name} affected {thing} and the outcome was {outcome}.")このように、神と運は同一のオブジェクトとして扱われます。例えば、恵比寿さまは商売繁盛や五穀豊穣の神であり、同時にそのような運をもたらす要因でもあります。以下がその例です。
# 恵比寿さまのオブジェクトを作る ebisu = GodLuck("恵比寿さま", "商売繁盛や五穀豊穣の力", "人々に幸せを与える計画", "商売繁盛や五穀豊穣の要因") # 恵比寿さまが何かを創造する ebisu.create("鯛") # 恵比寿さまが何かに対して支配や介入をする ebisu.control("農作物", "守る") # 恵比寿さまが何かに対して影響を与える ebisu.affect("商人", "成功")恵比寿さま created 鯛. 恵比寿さま 守る 農作物. 恵比寿さま affected 商人 and the outcome was 成功.
人生、宇宙、そしてすべての意味とは何か？「銀河ヒッチハイク ガイド」では、答えは 42となっている。
科学の質問の範囲は、一部の分野では縮小し、他の分野では急増した。
宇宙がある意味数学的であるという考えは、少なくとも古代ギリシャのピタゴラス派にまで遡り、物理学者や哲学者の間で何世紀にもわたる議論を生み出してきた。
マックス・テグマークはこの考えを極限まで推し進め、宇宙は単に数学によって記述されるのではなく、数学自体であると主張している。
この議論の基礎は、人間とは独立した外部の物理的現実が存在するという仮定である。
これはそれほど物議を醸すものではない。物理学者の大多数はこの長年の考えを支持していると思うが、まだ議論されている。
形而上学的独我論者はそれをきっぱり拒否し、量子力学のいわゆるコペンハーゲン解釈の支持者は、観察のない現実は存在しないという理由でそれを拒否するかもしれない。
外部現実が存在すると仮定すると、物理理論はそれがどのように機能するかを説明することを目的としている。
一般相対性理論や量子力学など、最も成功した理論は、この現実の一部、たとえば重力や素粒子の挙動のみを説明している。
対照的に、理論物理学の聖杯はすべての理論、つまり現実の完全な記述である。
現実が人間とは独立して存在すると仮定する場合、記述が完全であるためには、人間の概念をまったく理解していない、人間以外の存在、つまりエイリアンやスーパーコンピューターなどに従って、現実が明確に定義されていなければならない。
言い換えれば、そのような記述は、「粒子」、「観察」、またはその他の英語の単語のような人間の負担を排除した形で表現可能でなければならない。
対照的に、教えられてきたすべての物理理論には 2 つの要素がある。
それは数式と、その方程式が私たちが観察し直観的に理解しているものとどのように関連しているかを説明する言葉である。
理論の結果を導き出すとき、陽子、分子、星などの新しい概念を導入するが、それは便利だからである。
原理的には、このようなバゲッジがなくてもすべてを計算できる。
たとえば、十分に強力なスーパーコンピューターは、何が起こっているかを人間の言葉で解釈することなく、宇宙の状態が時間の経過とともにどのように進化するかを計算できる。
もしそうなら、外部現実における物体とそれらの間の関係のそのような記述は完全に抽象的でなければならず、あらゆる言葉や記号は何の事前の意味も持たない単なるラベルにならざるを得ない。
代わりに、これらのエンティティの唯一のプロパティは、エンティティ間の関係によって具体化されるものになる。
ここで数学が登場する。
現代数学は、純粋に抽象的な方法で定義できる構造の正式な研究である。つまり、数学的構造を発明するのではなく、それらを発見し、それらを記述するための表記法を発明するだけである。
人間から独立した外部の現実を信じるなら、テグマークが数学的宇宙仮説と呼ぶもの、つまり物理的現実は数学的構造であるということも信じなければならない。
そのオブジェクトは、十二面体よりも精巧で、おそらくカラビ・ヤウ多様体、テンソル束、ヒルベルト空間などの恐ろしい名前のオブジェクトよりも複雑である。
世界のすべてのものは、あなたも含めて純粋に数学的であるはずだ。
それが本当であれば、万物の理論は純粋に抽象的で数学的でなければならない。
理論がどのようなものになるかはまだわからないが、素粒子物理学と宇宙論は、これまでに行われたすべての測定が、少なくとも原理的には、数ページに収まり、わずか 32 個の未説明の数値定数を含む方程式で説明できる段階に達している。
したがって、すべての正しい理論は、T シャツに書ける程度の方程式で説明できるほど単純であることが判明する可能性さえある。
しかし、数学的宇宙仮説が正しいかどうかを議論する前に、外部の物理的現実を見る 2 つの方法を区別することができる。
1 つは、上空から風景を観察する鳥のような、数学的構造を研究する物理学者の外側の概要。
もう一つは、鳥によって見渡される風景の中に住むカエルのように、構造によって記述される世界に住む観察者の内面の視点。
これら 2 つの視点を関連付ける際の 1 つの問題は時間に関係する。
数学的構造は、定義上、空間と時間の外側に存在する抽象的で不変の存在である。
宇宙の歴史を映画に例えると、その構造は 1 コマではなく DVD 全体に相当する。
したがって、鳥の視点から見ると、4 次元時空内を移動する物体の軌跡は、スパゲッティのもつれに似ている。
カエルには一定の速度で動く何かが見えますが、鳥には調理されていないスパゲッティのまっすぐな束が見える。
カエルが地球の周りを回る月を見ると、鳥は絡み合った2本のスパゲッティが見える。
カエルにとって、世界はニュートンの運動と重力の法則によって記述される。
2 つの視点を関連付ける際のさらなる微妙な点には、観察者がどのようにして純粋に数学的になることができるかを説明することが含まれる。
この例では、カエル自体は厚いパスタの束で構成されている必要がある。
その非常に複雑な構造は、おなじみの自己認識の感覚を引き起こす方法で情報を保存および処理する粒子に対応している。
まず、自然界ではさらなる数学的規則性がまだ発見されていないことが予測される。
ガリレオが数学的宇宙の考えを広めて以来、素粒子の小宇宙と初期宇宙の大宇宙における驚くべき数学的秩序を捉える素粒子物理学の標準モデルなど、その系譜に沿った発見が着実に進歩してきた。
長年にわたって多くのタイプの「多元世界」が提案されてきましたが、それらを 4 つのレベルの階層に分類することが役立つ。
最初の 3 つのレベルは、同じ数学的構造内の非通信の並行世界に対応します。レベル I は単に、光がまだ到達していない遠い領域を意味する。
レベル II は、介在する宇宙の宇宙論的膨張により永遠に到達できない領域をカバーする。
レベル III は「多世界」と呼ばれることが多く、特定の量子事象中に宇宙が「分裂」する可能性がある、量子力学のいわゆるヒルベルト空間の非通信部分が含まれる。
レベル IV は、根本的に異なる物理法則を持つ可能性がある、異なる数学的構造の並行世界を指す。
現在の最良の推定では、膨大な量の情報、おそらく Googolビットを使用して、観測可能な宇宙に対するカエルの視点を、すべての星や砂粒の位置に至るまで完全に記述する。
ほとんどの物理学者は、これよりもはるかに単純で、T シャツには収まらないとしても、本に収まる程度のビット数で特定できるすべての理論を望んでいる。
数学的宇宙仮説は、そのような単純な理論が多元宇宙を予測するに違いないことを示唆している。
なぜなら、この理論は定義上、現実の完全な記述であるからである。
宇宙を完全に特定するのに十分なビットが不足している場合、星や砂粒などの考えられるすべての組み合わせを記述しなければならない。
そのため、宇宙を記述する追加のビットは単にエンコードするだけである。
多世界の電話番号のように、私たちがどの宇宙にいるのか。このように、複数の宇宙を記述することは、単一の宇宙を記述するよりも簡単になる可能性がある。
極限まで突き詰めると、数学的宇宙仮説はレベル IV の多元宇宙を意味し、その中に他のすべてのレベルが含まれる。
宇宙である特定の数学的構造があり、その特性が物理法則に対応している場合、異なる特性を持つそれぞれの数学的構造は、異なる法則を持つ独自の宇宙である。
実際、数学的構造は「作成」されるものではなく、「どこか」に存在するものではなく、ただ存在するだけであるため、レベル IV の多元宇宙は必須である。
スティーヴン・ホーキング博士はかつてこう尋ねた。
「方程式に火を吹き込み、それらが記述できる宇宙を作り出すものは何でしょうか?」
数学的宇宙の場合、重要なのは数学的構造が宇宙を記述することではなく、それが宇宙であるということであるため、火を噴く必要はない。
レベル IV の多元宇宙の存在は、物理学者のジョン・ウィーラーが強調した混乱する疑問にも答える。
たとえ宇宙を完全に記述する方程式が見つかったとしても、なぜ他の方程式ではなく、これらの特定の方程式が使われるのか?
他の方程式が並行宇宙を支配しており、観察者をサポートできる数学的構造の分布を考慮すると、統計的に可能性が高いため、宇宙にはこれらの特定の方程式があるということだ。
並行世界が科学の範囲内なのか、それとも単なる推測に過ぎないのかを問うことは重要である。
並行宇宙はそれ自体が理論ではなく、特定の理論によってなされた予測である。
理論が反証可能であるためには、そのすべての予測を観察および検証できる必要はなく、少なくともそのうちの 1 つだけを検証できれば十分である。
たとえば、一般相対性理論は、重力レンズなど、私たちが観察できる多くのことを予測することに成功しているため、ブラックホールの内部構造など、私たちが観察できないことについての予測も真剣に受け止めている。
多くの並行宇宙に存在するのであれば、我々は典型的な宇宙にいると予想されるはずです。
ある量、たとえば、この量が定義されている多元宇宙の一部の典型的な観測者によって測定された暗黒エネルギー密度や空間の次元の確率分布を計算することに成功したと仮定する。
この分布により、我々自身の宇宙で測定された値が非常に非典型的なものになることが判明した場合、多宇宙、したがって数学的宇宙仮説が除外されることになる。
生命の要件を理解するまでにはまだ程遠いが、暗黒物質、暗黒エネルギー、ニュートリノに関して私たちの宇宙がどの程度典型的であるかを評価することで、多元宇宙の予測のテストを始めることができる。
なぜなら、これらの物質は銀河形成など、よりよく理解されているプロセスにのみ影響を与えるからである。
これらの物質の存在量は、多元宇宙のランダムな銀河から測定されるものとかなり典型的なものであると測定されている。
しかし、より正確な計算と測定では、そのような多元宇宙は依然として除外される可能性がある。
おそらく最も説得力のある反対意見は、直感に反して不安を感じるということである。
数学的宇宙仮説が真実であれば、科学にとって素晴らしいニュースであり、物理学と数学の洗練された統合により、深い現実を理解できるようになる可能性がある。
実際、多元宇宙をもつ数学的宇宙は、期待できるすべての理論の中で最良のものであるかもしれない。
なぜなら、規則性を明らかにし、定量的な予測を行うという科学的探求から現実のいかなる側面も立ち入れないことを意味するからである。
どの特定の数式が現実のすべてを記述するのかという問題は見当違いであるとして放棄し、その代わりに、鳥の視点からカエルの宇宙観、つまり観察をどのように計算するかを問うことになる。
それは、宇宙の真の構造を明らかにしたかどうかを決定し、数学的宇宙のどの隅が私たちの故郷であるかを理解するのに役立つ。
