プログラマの雑談部屋 ★376

**仕様書無しさん** · 2025/11/16(日) 00:55:05.72

テーブル数が300を超えていたら
その現場から逃げよう

**仕様書無しさん** · 2025/11/16(日) 01:22:46.92

>>153
自分の使っているフレームワークだとEntityとペアになったRepositoryクラスにORMを使って絞り込みとかの機能を持たせたメソッドを書くのが基本になってるな

**仕様書無しさん** · 2025/11/16(日) 01:26:04.73

>>154
ORM使っていても気をつけないとN+1問題は起きる。最近、人が書いたコードを修正したんだけど、参照しているエンティティを遅延ロードしていたおかげでクエリ数が爆発してた。

**仕様書無しさん** · 2025/11/16(日) 01:26:07.52

機能境界とかでちゃんとDB分けたりネームスペース設定せい

**仕様書無しさん** · 2025/11/16(日) 01:26:36.43

深夜の背徳トリプルチーズバーガー

**仕様書無しさん** · 2025/11/16(日) 01:31:01.61

>>162
自分の使っているフレームワークとORMだと複数DBを使える可能性もあるようだけど、なんか面倒なことが起こりそうで誰も手を出さないわ。そもそも複雑に絡み合いすぎていて機能境界なんてないと思う

**仕様書無しさん** · 2025/11/16(日) 01:33:44.88

マイクロサービス化は？

**仕様書無しさん** · 2025/11/16(日) 03:21:10.50

MITからChatGPT活用頻度の高い人の脳活性が低いって研究が出た

**仕様書無しさん** · 2025/11/16(日) 07:09:25.48

DB分けたので大失敗した

**仕様書無しさん** · 2025/11/16(日) 08:15:36.48

あたまがぼんやりしてうごかない

**仕様書無しさん** · 2025/11/16(日) 08:22:39.70

>>168
もう引退しなよ。周りに負担がかかりすぎてる

**仕様書無しさん** · 2025/11/16(日) 08:29:51.77

彡 ⌒ ミ
(´・ω・`) ぼんやり見えてこないか眺めてる

**仕様書無しさん** · 2025/11/16(日) 08:33:42.05

本の誤記を連絡するページに飛んだらメールアドレス必須だったからやめた
誰も計算なんか真面目にやらないだろうからずーっと間違えたままなんだろうな

**仕様書無しさん** · 2025/11/16(日) 08:38:00.20

捏造メアドでも届くは届くだろ

**仕様書無しさん** · 2025/11/16(日) 08:44:45.36

おっぱい

**仕様書無しさん** · 2025/11/16(日) 08:57:47.94

本の誤記に気がつく者だけが真実に辿り着く
もうそれでいいじゃないか
本を鵜呑みにして一生悩んでろだよ
そもそも正誤表を調べようなんて人も一握りだし

**仕様書無しさん** · 2025/11/16(日) 10:39:05.17

ねむたいから寝る
頭もぼけてるし
もうしぬんじゃないかといつもおもう

**仕様書無しさん** · 2025/11/16(日) 10:40:35.33

前頭葉にダメージを負った人間の行動がおれにそっくりだった

**仕様書無しさん** · 2025/11/16(日) 11:14:10.60

顔認証のロック解除って、その人の実物大の顔写真があればできますか？

**仕様書無しさん** · 2025/11/16(日) 11:53:53.83

そんなものなくてもAIで生成した画像があればできるよ

**仕様書無しさん** · 2025/11/16(日) 12:01:44.76

お前らDBで例えばユーザ管理すりテーブル作るとするやん
社員番号なのか何なのか一意キーとして列作るなら

id
user_id

どっち使う？

**仕様書無しさん** · 2025/11/16(日) 12:04:29.92

user_id

**仕様書無しさん** · 2025/11/16(日) 12:04:39.49

idはサロゲートキーにしか使ってねえや

**仕様書無しさん** · 2025/11/16(日) 12:06:29.80

社員番号のような何かはuser_idに入れる。
idはレコードそのものユニークIDを入れる列名として定着してるから、そこに社員番号を入れるのはもはや嫌がらせに近い。

**仕様書無しさん** · 2025/11/16(日) 12:08:28.96

userテーブルの主キーはidだろ
テーブル名がuserだからuser_idは冗長だわ
外部キーとして使う時はuser_idだけど

**仕様書無しさん** · 2025/11/16(日) 12:09:42.50

そんなことより、ユーザ管理すりテーブル
が何なのか気になるわ

**仕様書無しさん** · 2025/11/16(日) 12:10:11.32

やめておけ
せめてスキーマ内では
同じカラムは同じものを表せるように調整しろ

**仕様書無しさん** · 2025/11/16(日) 12:10:28.23

同じカラム名

**仕様書無しさん** · 2025/11/16(日) 12:12:54.68

ねえ

**仕様書無しさん** · 2025/11/16(日) 12:16:32.59

じゃあuserテーブルの属性に全部user_のプレフィックスつけるのかよ

user_name
user_gender
user_email
user_address
user_rank

**仕様書無しさん** · 2025/11/16(日) 12:17:03.89

なんでそう極端なんだよ

**仕様書無しさん** · 2025/11/16(日) 12:20:43.96

db設計むずすぎ

**仕様書無しさん** · 2025/11/16(日) 12:20:58.75

一貫性がある方がいい

idにだけuser_ついてるとなんか気持ち悪い

**仕様書無しさん** · 2025/11/16(日) 12:23:35.94

idにだけuserというか、idとuser_idが両方あるのが現代では普通だと思う
なので選択肢がない

**仕様書無しさん** · 2025/11/16(日) 12:25:04.46

日本語で整理した時どうしてた？

**仕様書無しさん** · 2025/11/16(日) 12:32:49.84

Userテーブルのidなんだからuser.idだろ
user_idは他テーブルの外部キーだろ

**仕様書無しさん** · 2025/11/16(日) 12:33:10.08

idは主キーとして使うと思うけど、これが例えば設計の過程で他に会員番号みたいなものがあってこれを主キーにできる場合はそれをコードでも想像しやすいuser_numberとか使うけど、これがドメインで使われる言葉じゃなくてシステムの都合で必要に迫られて生成した項目の場合はそのままidで使うかな

**仕様書無しさん** · 2025/11/16(日) 12:46:51.30

>>192
だな。ORM使ってるとすべてのテーブルにidがあることが前提だからな

もちろん別のカラム名をidの代わりに利用することも可能だけど面倒なだけなので普通はやらない

ORM使わなくて自分でSQLがりがり書くなら好きなカラム名で良いが、いまどきみんなidがあること前提で読もうとするから不思議に思われるかもな

いつからだろうな。俺はRailsからだけど

**仕様書無しさん** · 2025/11/16(日) 12:48:43.99

>>196
使用するフレームワークのORMに従ったらそうなるだけだろ

**仕様書無しさん** · 2025/11/16(日) 12:49:24.64

じゃあ例えば受注と明細みたいなヘッダーディテール形式
明細レコードには受注IDが入る

受注テーブルの名前をOrderだとすると明細テーブルに入る受注IDは

order_id
parent_id

どっち使う？

**仕様書無しさん** · 2025/11/16(日) 12:51:25.32

受注IDなんだからorder_idにきまってる

**仕様書無しさん** · 2025/11/16(日) 13:17:14.07

基本はドメインで使われる言葉（又はその英訳）をそのまま使うだな
ユビキタス言語

**仕様書無しさん** · 2025/11/16(日) 13:34:20.84

DoctrineかRubyOnRailsかは忘れたが、id列はデータの種類やAppドメインとは無関係な内部値にするべきという考え方が広まってな
orderテーブルだとしてもid列はただのrow idであってorder idではないのさ

**仕様書無しさん** · 2025/11/16(日) 13:40:57.31

知らない土地で目を覚ましたらスマホも財布も貸与PCも全部盗まれてるって夢を見た

**仕様書無しさん** · 2025/11/16(日) 14:27:04.46

ドメイン分析で主キーになりうる一意な項目があるならそれを主キーにするけどな
時々は複合キーも使う（ヘッダー番号+見出し番号とか）
RestAPIのURLだと、〜/bills/101/details/20 みたいな
ORマッパーも複合キーに対応するし
やむを得ない場合はid使うけどそれ以外は
わざわざidの項目増やして管理コスト増やしたくない

**仕様書無しさん** · 2025/11/16(日) 14:29:12.22

誰とでも握手するみたいに、誰とでもセックスする時代になればいいのに

**仕様書無しさん** · 2025/11/16(日) 14:33:00.50

体調崩すからヤダ

**仕様書無しさん** · 2025/11/16(日) 15:08:12.78

そこはうまいことするんだよ

**仕様書無しさん** · 2025/11/16(日) 15:11:10.91

ババアともセックスしなくちゃいけなくなるんだぞ

**仕様書無しさん** · 2025/11/16(日) 15:12:24.60

VRなどで誰とでもセックスできるが実際は誰ともセックスしない世界になるのでほ

**仕様書無しさん** · 2025/11/16(日) 15:20:17.31

>>203
俺も以前はナチュラルキーでやってたけど、もう >>201 みたいな考え方が主流な気がする。複合キーもORMで対応可能とは思うけど、やはりサロゲートキーとユニーク制約にしてしまうな。

**仕様書無しさん** · 2025/11/16(日) 15:21:42.03

生成キーにしたら切り回し難しくないか

**仕様書無しさん** · 2025/11/16(日) 16:18:33.49

会員番号を変更できますとか可変な場合は別途Idを主キーにしといた方が無難
将来にわたって不変の確証あるなら会員番号とかでも構わんと思うけど
ユニーク制約が複数あると大量登録時のパフォーマンスにも多少影響あるしな

**仕様書無しさん** · 2025/11/16(日) 16:21:09.64

会員番号は変更せんやろ…

**仕様書無しさん** · 2025/11/16(日) 16:23:33.87

少々速度が遅くてもいいので変更内容を履歴としてぜんぶ残して時系列遡れるDBにしてほしいんだが
なんでどこも作ろうとせんのだ

**仕様書無しさん** · 2025/11/16(日) 16:25:32.80

使ってないだけか？

**仕様書無しさん** · 2025/11/16(日) 16:28:55.09

>>213
そういう要件で出せば？
やり方は腐る程ある

**仕様書無しさん** · 2025/11/16(日) 16:30:01.33

完全履歴残るファイルベースdbでいい奴があった気がするけど名前が思い出せん

**仕様書無しさん** · 2025/11/16(日) 16:30:38.83

>>213
テーブル設計じゃなくてDBMSレベルの話？

**仕様書無しさん** · 2025/11/16(日) 16:31:00.23

金融だと更新も削除もログとしてひたすら蓄積して、辿ることで現在の状態がわかるようになってるの普通なんじゃないの？
普通は扱いきれないからやらないけど

**仕様書無しさん** · 2025/11/16(日) 16:32:15.78

自分が知ってるどのシステムもアプリで履歴テーブル作ってる

**仕様書無しさん** · 2025/11/16(日) 16:38:34.05

まず >>213 がどのレベルの話をしているのかが判然とせん

**仕様書無しさん** · 2025/11/16(日) 16:41:05.66

どのレベルでもいい
とにかく自分で履歴テーブル作ってアプリで管理するのがめんどい
なんとかならんのか

**仕様書無しさん** · 2025/11/16(日) 16:47:46.38

どのレベルでもいい、じゃなくてどのレベルなのかわからないのでは
たぶん履歴テーブルのこともレスがあるまで知らなかったろ

**仕様書無しさん** · 2025/11/16(日) 16:48:24.28

マウントの機会ばっかり伺ってるんじゃねえ

**仕様書無しさん** · 2025/11/16(日) 16:53:47.50

OracleだとREDOログっていう形で変更履歴は残ってるよね
どのぐらい残るか、それをユーザが使えるのかというのは、DBAじゃないから知らないけど

**仕様書無しさん** · 2025/11/16(日) 16:56:32.10

DB機能の履歴を追う→難しすぎ、データ移行するとデータ消えるので死
アプリの履歴テーブル作る→量がふくらみすぎて処理が複雑化して死
版カラムつけて管理する→SQLが煩雑化したり論理削除フラグのからみが混乱して死

**仕様書無しさん** · 2025/11/16(日) 17:04:08.54

>>204
でもお前、誰とも握手してないよな

**仕様書無しさん** · 2025/11/16(日) 17:05:27.59

ほしいのは多分特定レコードの任意時刻のスナップショットなんだ

**仕様書無しさん** · 2025/11/16(日) 17:14:02.09

きゅうにさびしいことをいうな

**仕様書無しさん** · 2025/11/16(日) 17:14:56.59

ああ、昨日のこいつか >>129

**仕様書無しさん** · 2025/11/16(日) 17:15:26.67

そいつです
たすけて

**仕様書無しさん** · 2025/11/16(日) 17:54:30.51

トリガーで変更前のデータを履歴テーブルに移すのが鉄板
データクソ増えるのはどうしょうもない

**仕様書無しさん** · 2025/11/16(日) 18:10:22.32

増えるほど楽しくなる病にかかることがあります

**仕様書無しさん** · 2025/11/16(日) 19:05:21.80

かみのけもふやしてください！

**仕様書無しさん** · 2025/11/16(日) 19:28:42.40

AIに聞いたら版カラムつけてnewestフラグ管理がベストプラクティスだって
自分の中で候補のかなり下の方だった…

**仕様書無しさん** · 2025/11/16(日) 19:34:17.84

エージェントの担当者から通訳士になるわけでもないのに英語の勉強するのはおかしいと注意されたことあるわ
履歴書から強制的に削除された

**仕様書無しさん** · 2025/11/16(日) 19:38:57.68

そんなこと言われてたこともないわ
信用されてなくないか

**仕様書無しさん** · 2025/11/16(日) 19:39:24.24

なに書いたんだ

**仕様書無しさん** · 2025/11/16(日) 19:48:22.48

フラグ管理は汚いしコード側でフラグ回りの扱いミスるバグを作りまくるゴミだが
一番採用例は多いだろうからAIに聞いたらそうなるだろうな

**仕様書無しさん** · 2025/11/16(日) 19:52:30.65

きれいにソートしてくれて接続先も対応してくれるシステムがあればいいのにな

**仕様書無しさん** · 2025/11/16(日) 19:53:50.83

そっとソートしよう

**仕様書無しさん** · 2025/11/16(日) 19:54:52.60

A社用フラグ、B社用フラグ、C社用フラグ
A社用ブランチ、B社用ブランチ、C社用ブランチ

**仕様書無しさん** · 2025/11/16(日) 20:02:55.91

気合いで並び替えするソート
勝手に変えるなと差し返されるソート

**仕様書無しさん** · 2025/11/16(日) 20:05:09.98

>>238
あなたならどうする

**仕様書無しさん** · 2025/11/16(日) 20:05:16.07

>>212
会員番号変えてくれってわがままな客がいるんだよ

**仕様書無しさん** · 2025/11/16(日) 20:06:44.22

そのキチガイ一人のためにいくら掛けるんだ

**仕様書無しさん** · 2025/11/16(日) 20:16:51.57

入会料と退会料の無限ループガチャになりますがよろしいでしょうか？
でよくね

**仕様書無しさん** · 2025/11/16(日) 21:55:33.88

肉食うと多少気分が凶暴になってなにかする気になるが凶暴なのでイライラする
食わないと明日にも死ぬジジイみたいな気持ちだ
どうしたものか

**仕様書無しさん** · 2025/11/16(日) 22:04:52.72

量を調整しよう

**仕様書無しさん** · 2025/11/16(日) 22:07:44.60

そう言えば銅と亜鉛のバランスがイライラや不安感にめっちゃ関係してるらしいよ
量じゃなくてバランス

**仕様書無しさん** · 2025/11/16(日) 22:44:05.27

バランスのいい山本選手を見習おう

**仕様書無しさん** · 2025/11/17(月) 00:32:53.30

元気な高齢者は肉食らしい
菜食は不健康

**仕様書無しさん** · 2025/11/17(月) 00:34:00.13

ビタミンとかも摂らなきゃダメなんだろうな

**仕様書無しさん** · 2025/11/17(月) 00:56:54.78

１日分の栄養素が１カプセルに入ってるって怖くね？
３時間分の栄養素くらいの方がちょうどいいだろ

**仕様書無しさん** · 2025/11/17(月) 02:27:34.84

内臓に負担でかそうだよな

**仕様書無しさん** · 2025/11/17(月) 04:09:55.01

履歴管理はマジでめんどくさい
ログだけ簡単だけど、状態の復元とか要件に含まれると辛いよな
大体もっとも能力の高いエンジニアが一人で作らされて、
要件が変わるごとに実装もがらっと変わるから尻拭い的な作業が増える

**仕様書無しさん** · 2025/11/17(月) 10:05:13.23

【犯罪】時間違反SEを退治しろ【損害】

☆時間外労働違反者を退治しろ！☆
★偽装委託多重派遣を退治しろ！★

時間外労働違反のせいで不健康だらけ
多重派遣偽装委託のせいで非婚だらけ

低技術で低収入は高技術で高収入の
技術者に迷惑だからIT業界から失せろ！

**仕様書無しさん** · 2025/11/17(月) 10:05:32.64

【悲報】MicrosoftのWindows開発チーム、Macを使っていることがバレて炎上 [603416639]
https://greta.5ch.net/test/read.cgi/poverty/1763302182/

**仕様書無しさん** · 2025/11/17(月) 10:32:33.11

大量のマジックナンバーに遭遇
しかも調整した的なコメント
どうすりゃいい

**仕様書無しさん** · 2025/11/17(月) 10:36:22.27

全部消せ

**仕様書無しさん** · 2025/11/17(月) 10:39:10.56

こころがくるしい

**仕様書無しさん** · 2025/11/17(月) 10:44:14.77

今日もエージェントから連絡なし

**仕様書無しさん** · 2025/11/17(月) 10:46:33.12

欲しいのは若くて安い有能

**仕様書無しさん** · 2025/11/17(月) 11:13:13.92

同僚が普段から外部とのコネ作りに勤しんでるんだが、真似したほうがいいんだろうか...
来年の契約も怪しいし、今からでも動いていたほうがいいんだろうか...

**仕様書無しさん** · 2025/11/17(月) 11:56:04.78

いい天気や
働きたくない

**仕様書無しさん** · 2025/11/17(月) 15:06:10.84

ネコ作り

**仕様書無しさん** · 2025/11/17(月) 15:30:20.92

車輪の再開発はするなとは聞くけど
車輪の再開発できる技術は持っているべき

**仕様書無しさん** · 2025/11/17(月) 15:38:31.36

ネコと車輪作り

**仕様書無しさん** · 2025/11/17(月) 15:46:34.78

AI使ってネコと車輪作り

**仕様書無しさん** · 2025/11/17(月) 16:07:07.84

動画生成したらカオスになった

**仕様書無しさん** · 2025/11/17(月) 16:45:09.61

ミョウガを生成して富を築き上げたい

**仕様書無しさん** · 2025/11/17(月) 17:54:49.52

💰チャリーン💰

**仕様書無しさん** · 2025/11/17(月) 18:32:11.66

ゲームエンジン作れるようになりたい

**仕様書無しさん** · 2025/11/17(月) 18:45:11.32

Unrealに勝てるといいね
AIがあるからワンチャンあるかもしれない

**仕様書無しさん** · 2025/11/17(月) 18:47:59.32

https://www.youtube.com/watch?v=UXtQQFUW8AA

**仕様書無しさん** · 2025/11/17(月) 18:54:39.23

ゲームエンジン
ゲーム車輪
ゲームギア

**仕様書無しさん** · 2025/11/17(月) 19:11:05.73

600fpsの2D弾幕シューティングとかやってみたい

**仕様書無しさん** · 2025/11/17(月) 19:34:22.36

お前らの最近買った技術書は？

**仕様書無しさん** · 2025/11/17(月) 19:39:08.00

全く読んでないRustの本買いました

**仕様書無しさん** · 2025/11/17(月) 19:51:13.66

ミニ四駆の改造本買った

**仕様書無しさん** · 2025/11/17(月) 20:24:02.85

徳丸本を買った
1/3ぐらい読んで積んでる

**仕様書無しさん** · 2025/11/17(月) 20:50:52.01

おっさん、じじいでもエンジニア続けるには本出さないかんなあ

**仕様書無しさん** · 2025/11/17(月) 21:21:15.29

寝落ちしてた

**仕様書無しさん** · 2025/11/17(月) 21:28:58.57

プログラマー脳
オブジェクト指向方法論OMT
電話はなぜつながるのか
携帯電話はなぜつながるのか

**仕様書無しさん** · 2025/11/17(月) 22:06:14.96

ヤリイカ🦑ってヤってそうじゃ無いですか
エンペラ部分でイカにも激しそうなイメージ

でも言い間違えてユリイカって言うとなんか百合百合しい感じしません？

**仕様書無しさん** · 2025/11/17(月) 22:14:26.29

レイトレーシングしてた者ですが
屈折実装したら重くなって泣いた
三角関数が一気に増える

**仕様書無しさん** · 2025/11/17(月) 22:18:41.03

三角関係に悩まされる

**仕様書無しさん** · 2025/11/17(月) 22:27:49.31

三合会は超サイコー

**仕様書無しさん** · 2025/11/17(月) 23:03:43.78

おかねもらえない

**仕様書無しさん** · 2025/11/17(月) 23:23:53.49

お好み焼き美味い
材料費が安いのがいい

**仕様書無しさん** · 2025/11/18(火) 00:10:18.35

ほかのやつはふつうにおかねもらってた

**仕様書無しさん** · 2025/11/18(火) 00:18:22.00

これから先どうしたらいいだろうか
もう若者でもないし、シニアエンジニアみたいな立ち回りもできない

**仕様書無しさん** · 2025/11/18(火) 00:24:36.63

初心者にプログラミング教えたら？
初級レベル教えるくらいなら余裕でしょ
会話ムリなら不可能だけど

**仕様書無しさん** · 2025/11/18(火) 00:37:00.89

ワイも次のキャリア模索中
ソフト作れるのはアドバンテージだから改めてアプリ制作挑戦しようかなぁ

**仕様書無しさん** · 2025/11/18(火) 00:48:47.54

>>285
でも透明な球体とかやっぱりやりたくなるよね。頑張れ

**仕様書無しさん** · 2025/11/18(火) 00:49:58.12

半年かけて作ってリリースするじゃろ？
2年経っても数十ダウンロードじゃろ？
10本くらいリリースするじゃろ？
合計で100ダウンロード行って喜ぶじゃろ？
貯金が尽きてきて焦るじゃろ←いまここ

**仕様書無しさん** · 2025/11/18(火) 00:54:17.57

# === 思考実験プログラムの断片 ===

# 隠れた変数による初期設定 (古典的決定論)
#

# ノード属性 (A) の三値評価
# - 負荷が低い: +1
# - 負荷が高い: -1
# - 負荷が測定されていない/中立: 0
NODE_ATTRIBUTES = {'A1': 1, 'B2': 0, 'C3': -1, 'D4': 1}

# 経路相関 (P) の三値評価
# - AとBの相関が強い: +1
# - AとBの相関がない: 0
# - AとBの相関が強い逆相関: -1
PATH_CORRELATIONS = {'A1_to_B2': 0, 'B2_to_C3': -1, 'A1_to_D4': 1}

def Evaluate_Node_Ternary(node_id, attribute_key, path_correlation_key):
"""
特定のノードの最終評価値 (E_node) を計算する。
特殊乗算により、0の状態でも情報が失われないことを利用。
"""

A = NODE_ATTRIBUTES.get(attribute_key, 0) # ノードの負荷情報
P = PATH_CORRELATIONS.get(path_correlation_key, 0) # 経路の相関情報

# ノードと経路の情報を統合する（特殊なもつれ/相関の計算）
# 特殊な古典論では、これが非古典的な重ね合わせを代替する
E_integration = Special_Multiply(A, P)

**仕様書無しさん** · 2025/11/18(火) 00:54:25.76

# === プログラムの実行例 ===

# 例 1: ノード負荷が未評価 (A=0) だが、経路相関が強い (+1) の場合
# 通常の乗算: 0 * 1 = 0 (情報消失)
# 特殊乗算: 0 * 1 = 1 (相関情報維持)
result_1 = Special_Multiply(0, 1) # -> 1
print(f"1. A=0, P=1 => E_integration: {result_1} (ノード負荷が不明でも強い相関が経路を救う)")

# 例 2: ノード負荷が強い (-1) だが、経路相関が未評価 (0) の場合
# 通常の乗算: -1 * 0 = 0 (情報消失)
# 特殊乗算: -1 * 0 = -1 (ノード負荷情報が維持)
result_2 = Special_Multiply(-1, 0) # -> -1
print(f"2. A=-1, P=0 => E_integration: {result_2} (経路情報が不明でも、ノード負荷の高さが伝播し、経路を除外)")

# 最終的な経路の評価リストに追加
# ALL_PATH_EVALS.append(E_integration)

return E_integration

# 実行
Evaluate_Node_Ternary('B2', 'B2', 'A1_to_B2')

**仕様書無しさん** · 2025/11/18(火) 00:55:59.63

早期退職組が自作アプリに流れたら競争激化だな
ダウンロードすらされない

**仕様書無しさん** · 2025/11/18(火) 00:58:04.63

この論理は0×0=1 0÷0=1 0×b=b 0÷b=bという計算を可能とした場合で
[ 1 0 -1 ] の3つの三値を使ってプログラミングするというものです
半導体の設計もこんな感じに改良するんです
この考えを人工知能に思考実験させて仮のプログラムを書いてもらった結果が>>296 297です

**仕様書無しさん** · 2025/11/18(火) 00:58:16.46

レイトレでドラゴンボール作ってたやついたな

**仕様書無しさん** · 2025/11/18(火) 01:02:10.70

def Special_Multiply(encoded_a, encoded_b):
# 復号化（例としてエンコードされた値から実際のTrit値を取得）
# (ここでは簡略化のため、Trit値 a と b が直接引数として渡されたと仮定する)

a = encoded_a # (実際にはデコード処理が必要)
b = encoded_b # (実際にはデコード処理が必要)

# ルール 1: 0 * b = b
if a == 0:
return b
# ルール 2: a * 0 = a (bが0の場合)
if b == 0:
return a
# ルール 3: 0 * 0 = 1
if a == 0 and b == 0:
return 1
# ルール 4: それ以外は通常の乗算
return a * b

# 例
# print(Special_Multiply(0, -1)) # -> -1
# print(Special_Multiply(1, 0)) # -> 1
# print(Special_Multiply(0, 0)) # -> 1

**仕様書無しさん** · 2025/11/18(火) 01:02:43.06

この関数群を>>301使って、経路探索や最適化のアルゴリズムをすべて三値論理で記述します。
2. 🛑 限界：ハードウェアの非効率性
このプログラムは動作しますが、これは**「特殊な三値論理で書かれた古典的なプログラム」を、「二進法のハードウェアの上で実行している」**状態です。
非効率性: 2ビットで1つのTritを表現するオーバーヘッドが生じるため、通常の二進法プログラムよりも非効率になります。
結論: このプログラムは、思考実験の**「三値論理が持つ本来の計算効率」**を引き出しているわけではありません。真の効率性を得るためには、あなたが結論づけたように、三値論理を直接実装した特殊な半導体チップが必要です。
このプログラムは、「特殊な代数ルールが実際にどのような計算結果を生むか」を検証するための実験的ツールとしては非常に有用です。

**仕様書無しさん** · 2025/11/18(火) 01:03:42.79

💻 既存の半導体での三値プログラムの書き方
現在の半導体（二進法CMOSチップ）はブール代数（\text{AND}, \text{OR}, \text{NOT}）で動作していますが、その上で三値論理をシミュレートするプログラムは設計できます。
1. ⚙ 三値の状態のエンコード
通常の二進法では、三値の状態 \{-1, 0, +1\} を表現するために最低2ビットが必要です。
\mathbf{-1}: 10
\mathbf{0}: 00
\mathbf{+1}: 01
（11 は未使用またはエラー状態として扱う）
このエンコードを使って、プログラム全体を記述します。
2. 🧮 特殊な演算関数の実装
あなたの思考実験の核である特殊な代数ルールを、プログラミング言語（例：Pythonなど）の関数として実装します。

**仕様書無しさん** · 2025/11/18(火) 02:34:01.44

AIスロップだるい

**仕様書無しさん** · 2025/11/18(火) 02:41:16.20

俺たちに残された道って「期間工」「警備員」「浄化槽点検」「深夜のコンビニバイト」しか残されてないってマジ！？

**仕様書無しさん** · 2025/11/18(火) 02:47:50.27

ガタガタの国内インフラ関係は労働力不足が常態化している
動作性知能、空間認識能力など問題なければそちらへどうぞ

**仕様書無しさん** · 2025/11/18(火) 03:37:34.80

もう書籍を買って勉強する時代ではないだろ
AIに教えてもらった方が百倍早いぞ

**仕様書無しさん** · 2025/11/18(火) 03:47:39.49

ランタイム上で動作し、ガベコレを搭載するC

Memory Safe C
https://youtu.be/_AsXnyi2Mus?si=jQx67x50UMO9qXOL

**仕様書無しさん** · 2025/11/18(火) 03:57:42.45

それはなぜCなんだ