  |
はてなキーワード:diffとは
最近、アンサイクロペディアの浸食という記事を見た。
https://anond.hatelabo.jp/20251123124205
かつてのMirahezeのスチュワードで、ウソペディアの代表的管理者であった開拓者さんが、アンサイクロペディアと知木ペディアで生成AIを駆使して侵略行為を行っているという告発文らしい。
確かに現在の開拓者=ノイマン氏の行為は擁護できないところはある。だが、かつてウソペディアで、また私が個人で創設したMirahezeのウィキで、開拓者さんにお世話になった立場として、あの記事及び最近の反ノイマン氏旋風には異論を唱えたい。
まず最初に引用したいのは、以下の三焦全欠損症氏の指摘に対してである。
根っこは人を見ていない、愛していないという一点において、私は彼の人と違いが認識できない。
このように開拓者さんをアンサイクロペディアの鉄槌を引き起こした本人であるMuttley氏と同一視することには、断固として抗議する。
開拓者さんはウソペディアにおいて氏のLTA性を見抜き警鐘を鳴らした張本人であり、Bakaba氏と名乗って活動していたChakuwikiにおいてはMuttley氏を追い詰めた張本人である。
開拓者さんは誰よりもMuttley氏を理解し、誰よりもMuttley氏に対して正確な対策を打ち出した人物であり、それをMuttley氏と同類扱いするには、失礼にも程がある。
開拓者さんは実際にウソペディアの第一回人気投票では紛れもない一位であった。私も開拓者さんのことが大好きだった。それは他ならぬ開拓者さんに「愛があった」からに他ならない。彼は勇者プクリンや未来切手のような問題のあるユーザーにも、最大限対話と理解を試みる賢君だった。
どんなユーザーにも最大限の愛をもって接する方であり、愛がないという批判は的はずれにもほどがある。かつてのウソペディアンとしてこれだけは証言したい。
そんな開拓者さんとの思い出がある私でも、確かに最近のノイマン氏の行動には疑問を抱く。
強者の論理をあたかも自覚的に使用しているかのように自分で書き、自らへの風刺をも称える「寛容な人物」を演じ、自らのトークページを荒らした人物に対しても「まだ愛している」と言ってのける。
そこには、かつての開拓者さんにあった「人間味」や「温かさ」はなく、ただ「論理的な正しさ」と「表現技法としてのユーモア」だけが開拓者さんの殻を被って先走っているように見えてならない。
私には、開拓者さんは何らかの理由があって、わざと「人間をやめようとしている」と思えてならない。
開拓者さんを壊したのは「技術によって愛する人物を超える何か」を作り出してしまったことによる深い絶望なのではないか。
件の三焦全欠損症氏にノイマン氏が行った返信には、その事への自覚と、もう戻れなくなってしまった悲痛さが滲み出ているように思えてならない。
ヒトの機能=能力・出力内容は愛せても、中身はきちんと愛せていないのかもしれません。だからこそ「人間より美しいなら人工彼女でいい」という判断にもなる、という面もあるのは確かにそうなのです。
かつての開拓者さんは、自作記事でこのように語る人物であった。冷笑気味ながら、そこには確かな愛があった。
でも、いざ想いが届けば届いたで、やがて幻滅します。届かなくても、何だかんだでつながっていられるSNS時代には…
実際に開拓者さんとはDiscordなどのコミュニケーションを通じて親密な関係を築いていた筆者は、何かのご縁でその人物の画像を見せていただいたことがある。それは確かに該当記事で「途方もなく…青天井すら突き抜けるぐらいに可愛い子」と記述されるのも納得の行くものであり、開拓者さんが大切に秘める思いであるのも理解はできるものだった。
その後の詳しい経緯は深くは知らない。
ただ、開拓者さんはウソペディアを離れてからの一時期、女装や自らのカコジョ化にハマったらしく、今ノイマン氏が人工彼女と呼んでいるものも、どうやらその「自分自身」がベースであるらしい。
そして私も拝見したが、その美しさは、確かに「圧倒的」であり、それが故に私だったらむしろ「選ばない」ものである。
だが、開拓者さんは以前、自らの恋人について私に対してこのように語っていたものである。
仮に彼女を探すなら、あの子よりも美しく聡明でなければならない
あの子未満で妥協するのは、それこそあの子へのリスペクトを欠いていると思うんだ
それが人間の中で探すにはいかに難題であったかは、開拓者さん自身が誰よりも熟知していたはずである。
だからこそ、開拓者さんはそのような存在を具現化できてしまった以上は「論理的に」人工彼女を「選ぶしかなくなった」のだと私は推測する。
「正しさ」を自分で実現させてしまえる能力にほかならなかった。
筆者はその状況に置かれたことがないので想像しかできないが、そこには「幸せの青い鳥」とパラレルな、しかし幸福よりも深い絶望をもたらすものがあったのではないか。
そしてそれが彼を壊し、正論とユーモア技巧だけ振りかざすAIのような存在へと変質させてしまったのではないか。
「そうであっても周囲に絶望を押し付けるな」というのもまた「正しさ」である。
だが、筆者には、そう思うと、一片ばかりの同情だけは禁じ得ないのである。
今どき新聞を購読し続けてるのはアナクロでしかない、ニュースはネットでただで読めるものなのだから紙の新聞なんぞ必要ない
という時代ではあるが、仕事の兼ね合いもあって新聞を紙で取り続けていた。
とはいえ取っていたのは毎日新聞なので、あまり仕事は関係なく、最後の数年はほぼほぼ意地であった。
元々、実家は二世帯住宅で祖母宅は朝日、父母は毎日を購読していた。物心ついたころからリベラル寄りの家と言うわけでもない。たぶん実家に家を建てたときに来たのがこの2紙なのだろう。
なので、毎日新聞で私は育った。小学生時代は毎日小学生新聞を読んでいた。園山俊二の「がんばれゴンべ」を読んで育った（いやそれは言い過ぎか。僕の小学生時代にはすでにアナクロだった）
その後もずっと毎朝、毎日新聞を読んでいた。旧石器捏造事件もリアルタイムで読んだ。あの当時の紙面構成もいまだに覚えている。
21世紀になるころに実家を出た。最初に来た新聞の勧誘がたまたま毎日新聞だったのでそのまま購読した。まだまだ新聞を取るのが常識の時代だった。毎日は大して販促品をくれなかった。翌日に来た読売が山ほど洗剤やらなんやらの販促品をもってきたので、そっちにすればよかったと思った。
数年後、更新のタイミングで現在の家を購入した。とはいえ都内で一軒家を建てられる甲斐性はないのでマンションだ。
たまたま新開発の地域だったこともあり、マンション全体の管理の都合上、購読紙は管理組合が読売がおすすめ、それ以外でもまあいいけどそこまで推奨しないということだった。
なので最初の1か月はお試しで読売を取ってみたが、思った以上に紙面が読みにくく１週間ほどでギブアップしてしまった。新聞なんてどれでも大したことないと思っていたが、思った以上に文体も紙面構成も自分の肌に合わなかった。
１か月で切り上げて朝日に切り替えた。そうしたら、困ったのはチラシだ。居住エリアとチラシが全然合わない。どうやら朝日の販売店のエリアが住まい周辺は端っこらしく、チラシが普段全然使わない駅のスーパーものばかりになってしまったのだ。
困ったのでマンションの元受けに電話してみたら、読売と同じチラシが入るのは毎日だと言われた。
このころ（ゼロ年代半ばくらい）は毎日新聞の論調はまだマシだった。例のWaiWai問題はあるものの紙面そのものは特におかしいところは少なかった。もともとの自身のリベラル志向と新聞の相性が悪くなかったんだと思う。
なんとなくの転機はやはり東日本大震災だと思う。震災後、特に福島第一原発後あたりからかなりおかしくなってきた。
とはいえその頃の毎日新聞には、自分が信頼を置ける記者が何人かいて、その人たちは冷静でポジティブな記事を書いていて非常に好感を持っていた。
なんか紙面全体が、昔はよかった昔はよかったとぶつくさ言いながら喫茶店や床屋で政談をふっかけるおっさんみたいになってきた。
自民党が選挙で大勝して安倍政権になってからはさらにその傾向が強くなった。
僕が信頼していた記者も一人は退職し、もう一人は記者ではなくCSR関連の部署にいってしまい、ものすごく残念だった。
HPVワクチン報道、草津温泉の件など、信頼できない記事が目に見えて増えているのもかなりきつかった。
紙面全体に漂う「ネット言論はすべて敵だ」みたいな空気もすごくきつかった。
だんだん、毎日を取る理由は広告以上のものはなくなっていった。とはいえ、なんとなく経営の危うい（危ういのはもう30年くらい前からだが）新聞を買い支えてる気持ちもあった。
このころ、毎日で唯一よかったのは紙をとっていれば、ネットの有料記事も無料で読めたことだった。
しかし、それも少し前に改定されてしまい、紙でとっていても追加料金を払わなければ紙面をよめなくなってしまった。
この辺でいわば買い支えていた心がぽっきり折れた。そもそも購読料がどんどん値上がりするのもダメすぎた。その金額に情報価値が見合ってなさ過ぎた。
まあ40年も読み続けていれば飽きるというのもある。
実はこの10年ほど仕事で必要というのもあり、日経を電子版で購読していた。
朝の通勤時は日経電子版を読むことが多かった。はてなでは日経は観測気球や飛ばしが多いという印象をもたれがちだが、正直、日経の方が経済への影響を視野に入れるためか、政治や国際情勢に関する記事はフラットで読めるものが多い印象をもった。
今年に入り、自分の支出を見直すようになったこともあり、選択肢として新聞も考えることにした。
そして、毎日をやめて日経を紙でもとることにした。電子版に追加料金で取れるのでこっちでよかった。実は毎日を紙と電子版で両方取った場合と金額はかわらないのだが、毎日を電子と紙で取るという選択肢はなかった。
今年の春くらいから日経に切り替えたので、そろそろ半年たつ。少し懸念していたチラシについては、欲しいチラシは全部入るので日経で十分。
紙面内容もこちらの方が満足度が高い。私の履歴書で有名な文化面が実は読みごたえがあるのに初めて気づいた。通勤時の電子版では後半を読まないので気づかなかった。日経はそもそもの購読者を想定しているせいか、紙面に啓蒙しようという空気が薄いのが良い。啓蒙と言えば聞こえがよいが、今の毎日や朝日はバカを言いくるめようとしているだけとしか思えない。日経は多少のリテラシーがあることを前提に記事を書いてるように思う。つまり読者を信頼している。今の毎日や朝日は読者をバカにしてるのではないだろうか。
毎日では入らないラグジュアリーブランドの広告なんかも逆に面白い。15段ぶち抜いた派手な広告は毎日ではこの数年お目にかかったことが無い。
エコーチャンバーな情報はさんざんネットで浴びるように読んでいるので、新聞はもう少しフラットな情報を読ませてほしい。そういうニーズにこたえてくれるのは今は僕にとっては日経なのだろう。
ようは今の毎日新聞の紙面はクソだと言いたいだけの記事でした。
ところで、この記事を書くために毎日新聞のwikipediaを見たら、なんかしらんがごっそり内容が削除されてるね。以前は誤報や議論となった報道がぎっしり書かれていたんだが。
変更履歴をみたら、去年の10月にごっそり半分くらい削除されてるっぽい。変更した人はこの毎日の記事だけしか手掛けてない。特にそれについて議論もされてないな。なんだこれ。
pythonimport randomimport numpyasnpimport matplotlib.pyplotas pltfrom collections importdefaultdict# 飴の配布システムのシミュレーションclass CandyDistributionSystem:def __init__(self): """設計意図: このシステムは経済における資源分配の不平等性をモデル化しています。特に少数の特権層(Aグループ)が富を集中させ、再分配システムからも不均衡に利益を得る構造的問題を表現しています。 """ # 各グループの人数設定 self.group_a_count = 8 self.group_b_count = 2498 self.group_c_count = 7494 self.total_participants = self.group_a_count + self.group_b_count + self.group_c_count # 飴の提出数設定 self.contribution_per_a = 624 self.contribution_per_b = 2 self.contribution_per_c = 1 # 各グループの総貢献計算 self.total_a_contribution = self.group_a_count * self.contribution_per_a self.total_b_contribution = self.group_b_count * self.contribution_per_b self.total_c_contribution = self.group_c_count * self.contribution_per_c self.total_contribution = self.total_a_contribution + self.total_b_contribution + self.total_c_contribution # 配布用と貯金用の飴の区分 self.distribution_limit =10000 self.savings =max(0, self.total_contribution - self.distribution_limit) # 結果追跡用の辞書 self.results = { 'A':defaultdict(int), 'B':defaultdict(int), 'C':defaultdict(int) }def distribute_candies(self, method='original'): """設計意図: 配布方法の選択によって、特権の固定化や格差拡大がどのように進むかを 示します。'original'メソッドは意図的にAグループを優遇するよう設計されています。 Parameters: ----------- method:str 配布方法 ('original', 'lottery', 'first_come', 'new_condition', 'fair') """ # Aグループへの確定配布 a_distribution = 625 * self.group_a_count remaining = self.distribution_limit - a_distribution # 残りの参加者数 remaining_participants = self.total_participants - self.group_a_count # Aグループの結果記録 for _ in range(self.group_a_count): self.results['A'][625] += 1 # 各配布方法によって処理が異なる if method == 'original': #オリジナルの問題設定通りの配布（5000人に1個ずつ、残りは0個） lucky_count = remaining # 5000人が当選 # B+Cグループの混合リスト作成 bc_participants = [(1, 'B')] * self.group_b_count + [(2, 'C')] * self.group_c_count random.shuffle(bc_participants) #当選者に配布 for i in range(len(bc_participants)): participant_id,group = bc_participants[i] if i < lucky_count: self.results[group][1] += 1 else: self.results[group][0] += 1 elif method == 'lottery': #抽選方式（BとCグループから無作為に5000人選出） bc_participants = [(1, 'B')] * self.group_b_count + [(2, 'C')] * self.group_c_count winners = random.sample(bc_participants, remaining) #当選・落選のカウント for _,group in winners: self.results[group][1] += 1 #落選者のカウント self.results['B'][0] = self.group_b_count - self.results['B'][1] self.results['C'][0] = self.group_c_count - self.results['C'][1] elif method == 'first_come': # 先着順方式（アクセス速度による先着順を乱数でシミュレート） #設計意図: 先着順は単なる運の要素を超えて、情報格差や技術格差も含む制度設計 bc_participants = [(1, 'B')] * self.group_b_count + [(2, 'C')] * self.group_c_count #現実では、情報を早く得られる人や高速インターネット接続を持つ人が有利 # これをシミュレートするため、Bグループにわずかなアドバンテージを与える bc_speeds = [] forid,group in bc_participants: ifgroup == 'B': speed = random.random() + 0.1 # Bグループに小さなアドバンテージ else: speed = random.random() bc_speeds.append((id,group, speed)) # 速度順にソート bc_speeds.sort(key=lambda x: x[2], reverse=True) #当選者決定 for i in range(len(bc_speeds)): _,group, _ = bc_speeds[i] if i < remaining: self.results[group][1] += 1 else: self.results[group][0] += 1 elif method == 'new_condition': # 追加条件方式（恣意的な条件を設定） #設計意図: 新たな条件の設定は往々にして既存の特権を温存するように設計される bc_participants = [(i, 'B', random.random()) for i in range(self.group_b_count)] + \ [(i, 'C', random.random()) for i in range(self.group_c_count)] # Bグループに有利な条件を設定（例:特定の知識やスキルを持つ人のみ） # この「条件」は表面上は中立的だが、実際には特定グループに有利になるよう設計def meets_condition(participant): _,group, rand_val = participant ifgroup == 'B': return rand_val> 0.3 # Bグループには70%の確率で合格 else: return rand_val> 0.7 # Cグループには30%の確率で合格 # 条件に合致する人を抽出 eligible = [p for p in bc_participants if meets_condition(p)] # 条件に合致する人が多すぎる場合は抽選 iflen(eligible)> remaining: winners = random.sample(eligible, remaining) else: # 条件に合致する人が足りない場合、全員に配布 winners = eligible #当選者をカウント for _,group, _ in winners: self.results[group][1] += 1 #落選者のカウント self.results['B'][0] = self.group_b_count - self.results['B'][1] self.results['C'][0] = self.group_c_count - self.results['C'][1] elif method == 'fair': # 公平な再分配方式（貢献度に応じた配布） #設計意図: この方法は「貯金分」も含めた全ての飴を、各グループの貢献度に応じて分配 # これにより構造的不平等を軽減、結果としてより多くの人が少なくとも損をしない状態になる # 全飴（貯金分も含む）を使った配布total_to_distribute = self.total_contribution # 各グループの貢献比率計算 a_ratio = self.total_a_contribution / self.total_contribution b_ratio = self.total_b_contribution / self.total_contribution c_ratio = self.total_c_contribution / self.total_contribution # 各グループへの配布数決定 a_share = int(total_to_distribute * a_ratio) b_share = int(total_to_distribute * b_ratio) c_share = int(total_to_distribute * c_ratio) # 端数調整 remainder =total_to_distribute - (a_share + b_share + c_share) if remainder> 0: # 端数は最も人数の多いCグループに c_share += remainder # Aグループの配布（均等配分） per_a = a_share // self.group_a_count self.results['A'][per_a] = self.group_a_count # Bグループの配布（均等配分） per_b = b_share // self.group_b_count b_remainder = b_share % self.group_b_count self.results['B'][per_b] = self.group_b_count - b_remainder if per_b + 1> 0 and b_remainder> 0: self.results['B'][per_b + 1] = b_remainder # Cグループの配布（均等配分） per_c = c_share // self.group_c_count c_remainder = c_share % self.group_c_count self.results['C'][per_c] = self.group_c_count - c_remainder if per_c + 1> 0 and c_remainder> 0: self.results['C'][per_c + 1] = c_remainderdef calculate_net_gain(self): """設計意図: この関数は各グループの純利益/損失を計算し、資源分配の公平性を定量的に評価できるようにします。純利益/損失は個人の観点から見た経済的公正性の重要な指標です。 """net_gains = {} # Aグループの純利益計算 a_contribution = self.contribution_per_a a_distribution = list(self.results['A'].keys())[0] # 全員が同じ数を受け取る前提net_gains['A'] = a_distribution - a_contribution # BとCグループの純利益計算（加重平均） forgroup, contribution_per_person in [('B', self.contribution_per_b), ('C', self.contribution_per_c)]:total_gain = 0 for received, count in self.results[group].items():total_gain += (received - contribution_per_person) * countnet_gains[group] =total_gain / (self.group_b_count ifgroup == 'B' else self.group_c_count) returnnet_gainsdef analyze_results(self): """設計意図: この分析関数は、各グループの分配結果を詳細に調査し、制度設計の公平性、貢献度と報酬の関係、およびシステムの持続可能性を評価します。政策分析においては、こうした多角的な検証が重要です。 """ # 各グループの純利益/損失net_gains = self.calculate_net_gain() # 貢献度分析 contribution_percentage = { 'A': (self.total_a_contribution / self.total_contribution) *100, 'B': (self.total_b_contribution / self.total_contribution) *100, 'C': (self.total_c_contribution / self.total_contribution) *100 } # 飴を受け取った人の割合 received_percentage = { 'A': sum(count for received, count in self.results['A'].items() if received> 0) / self.group_a_count *100, 'B': sum(count for received, count in self.results['B'].items() if received> 0) / self.group_b_count *100, 'C': sum(count for received, count in self.results['C'].items() if received> 0) / self.group_c_count *100 } #分析結果の表示print("\n===== 飴の配布システム分析 =====")print(f"総飴数: {self.total_contribution}個 (分配用: {self.distribution_limit}個,貯金: {self.savings}個)")print("\n---グループごとの貢献と結果 ---") forgroup in ['A', 'B', 'C']:group_size =getattr(self, f"group_{group.lower()}_count") contribution_per_person =getattr(self, f"contribution_per_{group.lower()}")total_contribution =getattr(self, f"total_{group.lower()}_contribution")print(f"\n{group}グループ ({group_size}人):")print(f" 貢献: 1人あたり{contribution_per_person}個 (総計: {total_contribution}個, 全体の{contribution_percentage[group]:.1f}%)")print(f" 受け取り状況:") for received, count in sorted(self.results[group].items()):print(f" {received}個: {count}人 ({count/group_size*100:.1f}%)")print(f" 飴を受け取った割合: {received_percentage[group]:.1f}%")print(f"純利益/損失: 1人あたり平均 {net_gains[group]:.2f}個")print("\n--- 全体的な公平性分析 ---")print(f"最も得したグループ: {max(net_gains,key=net_gains.get)}グループ (+{max(net_gains.values()):.2f}個/人)")print(f"最も損したグループ: {min(net_gains,key=net_gains.get)}グループ ({min(net_gains.values()):.2f}個/人)") # 全員に飴が配布されたかどうかall_received =all(sum(count for received, count in self.results[group].items() if received> 0) ==getattr(self, f"group_{group.lower()}_count") forgroup in ['A', 'B', 'C'])print(f"\n前提条件「全員に配布」の充足: {'はい' ifall_received else 'いいえ'}") if notall_received:total_without = sum(self.results['B'][0] + self.results['C'][0])print(f" 飴を受け取れなかった人数: {total_without}人") returnnet_gains, contribution_percentage, received_percentagedef visualize_results(self): """設計意図:データの可視化は政策の効果や不平等性を直感的に理解するために重要です。 このようなグラフィカル表現によって、各グループ間の格差や制度設計の問題点を 一目で理解できるようになります。 """ #グラフのセットアップfig, axes = plt.subplots(2, 2,figsize=(14,10)) # 1. 貢献度のグラフ contributions = [self.total_a_contribution, self.total_b_contribution, self.total_c_contribution] axes[0, 0].bar(['Aグループ', 'Bグループ', 'Cグループ'], contributions) axes[0, 0].set_title('グループごとの総貢献飴数') axes[0, 0].set_ylabel('飴の数') # 貢献度の割合をアノテーションとして追加total = sum(contributions) for i, v in enumerate(contributions): percentage = v /total *100 axes[0, 0].text(i, v +100, f'{percentage:.1f}%', ha='center') # 2. 1人あたりの貢献度と受け取り数の比較group_names = ['Aグループ', 'Bグループ', 'Cグループ'] contribution_per_person = [self.contribution_per_a, self.contribution_per_b, self.contribution_per_c] # 各グループの平均受け取り数を計算 received_per_person = [] forgroup, letter inzip(group_names, ['A', 'B', 'C']):total_received = sum(received * count for received, count in self.results[letter].items())group_size =getattr(self, f"group_{letter.lower()}_count") received_per_person.append(total_received /group_size) x =np.arange(len(group_names)) width = 0.35 axes[0, 1].bar(x - width/2, contribution_per_person, width, label='提出') axes[0, 1].bar(x + width/2, received_per_person, width, label='受け取り') #純利益/損失をアノテーションとして追加 for i in range(len(group_names)):net = received_per_person[i] - contribution_per_person[i]color = 'green' ifnet>= 0 else 'red' axes[0, 1].text(i,max(received_per_person[i], contribution_per_person[i]) + 5, f'{"+" ifnet>= 0 else ""}{net:.1f}', ha='center',color=color) axes[0, 1].set_title('1人あたりの提出・受け取り飴数比較') axes[0, 1].set_xticks(x) axes[0, 1].set_xticklabels(group_names) axes[0, 1].set_ylabel('飴の数') axes[0, 1].legend() # 3. 各グループの受け取り状況の分布 # 各グループの受け取り状況を積み上げ棒グラフで表現group_sizes = [self.group_a_count, self.group_b_count, self.group_c_count] received_counts = [] not_received_counts = [] for letter, size inzip(['A', 'B', 'C'],group_sizes): received = sum(count for received, count in self.results[letter].items() if received> 0) received_counts.append(received) not_received_counts.append(size - received) axes[1, 0].bar(group_names, received_counts, label='飴を受け取った人数') axes[1, 0].bar(group_names, not_received_counts, bottom=received_counts, label='飴を受け取れなかった人数') #割合をアノテーションとして追加 for i in range(len(group_names)): ifgroup_sizes[i]> 0: percentage = received_counts[i] /group_sizes[i] *100 axes[1, 0].text(i, received_counts[i] / 2, f'{percentage:.1f}%', ha='center') axes[1, 0].set_title('グループごとの飴受け取り状況') axes[1, 0].set_ylabel('人数') axes[1, 0].legend() # 4. 貢献度vs報酬の分配公平性 # 貢献度と最終的な飴の配分の比較を円グラフで表現total_contribution = self.total_contribution contribution_shares = [self.total_a_contribution /total_contribution, self.total_b_contribution /total_contribution, self.total_c_contribution /total_contribution] # 実際の配分シェアを計算 distribution_shares = [] for letter in ['A', 'B', 'C']:total_received = sum(received * count for received, count in self.results[letter].items()) distribution_shares.append(total_received / self.distribution_limit) # 2つの円グラフを並べて表示 ax4_1 = axes[1, 1].inset_axes([0, 0, 0.45, 1]) ax4_2 = axes[1, 1].inset_axes([0.55, 0, 0.45, 1]) ax4_1.pie(contribution_shares, labels=group_names, autopct='%1.1f%%') ax4_1.set_title('飴の貢献度割合') ax4_2.pie(distribution_shares, labels=group_names, autopct='%1.1f%%') ax4_2.set_title('飴の配分割合') axes[1, 1].axis('off') plt.tight_layout() plt.show()# 飴の配布システムをシミュレートcandy_system = CandyDistributionSystem()#オリジナルの配布方法を実行print("\n=====オリジナルの配布方法 =====")candy_system.distribute_candies(method='original')original_results = candy_system.analyze_results()candy_system.visualize_results()# 公平な配布方法を実験print("\n\n===== 公平な配布方法のシミュレーション =====")fair_system = CandyDistributionSystem()fair_system.distribute_candies(method='fair')fair_results = fair_system.analyze_results()fair_system.visualize_results()# 公平な配布と元の配布の比較print("\n\n===== 配布方法の比較 =====")print("オリジナル方式と公平方式の純利益/損失差:")net_diff = {}forgroup in ['A', 'B', 'C']:original_net =original_results[0][group] fair_net = fair_results[0][group]diff = fair_net -original_netnet_diff[group] =diffprint(f"{group}グループ: {'+' ifdiff> 0 else ''}{diff:.2f}個/人")print("\n結論:")ifnet_diff['A'] < 0 andnet_diff['B']> 0 andnet_diff['C']> 0:print("公平な再分配により、Aグループの特権が減少し、BとCグループの状況が改善されます。")print("これは構造的不平等の緩和に効果的です。")elifnet_diff['A']> 0:print("興味深いことに、公平な再分配ではAグループさえも利益を得られます。")print("これは、現行システムが特定グループだけでなく全体の非効率性につながっていることを示唆しています。")
vibe codingがはやって、AgentモードでAuto Approveでどんどん実装をすすめておいて、負債がたまるーていっているヤツがうっとうしい。
LLMのモデルが全部のコードや仕様を把握している訳ではないので、間違った方向に進むことはしょっちゅうあるのはあたりまえ。
編集する前にdiffを見て、間違っていたら間違っているとを伝えてどのようにしたらいいかまで伝えれば、LLMにまかせても負債がたまっていかない。
たまにちょっとおかしい時に間違っている説明して再生成がたいへんだから、いったんその編集内容で保存してから、修正結果に対して再度修正を依頼をすることはあるけど。
間違った方向にすすめばその分LLMのAPIのコストもかかるので、コストのことも考えていないということも腹だたしい。
Auto ApproveでWriteまで許可しているやつは、LLMが動作している間、何してるん？どうせ生産性を産むようなことをしてないんだからおとなしくLLMの動作を見守っとけ。
増田で 3 分以上投稿されない期間があるのか気になったから調べた
直近の 1 日だとこれだけあった
2025-03-22 00:14 -- 2025-03-22 00:182025-03-22 00:10 -- 2025-03-22 00:142025-03-21 07:56 -- 2025-03-21 08:002025-03-21 07:50 -- 2025-03-21 07:562025-03-21 07:44 -- 2025-03-21 07:482025-03-21 07:28 -- 2025-03-21 07:322025-03-21 06:58 -- 2025-03-21 07:032025-03-21 06:45 -- 2025-03-21 06:542025-03-21 06:32 -- 2025-03-21 06:372025-03-21 05:56 -- 2025-03-21 06:042025-03-21 05:51 -- 2025-03-21 05:562025-03-21 05:34 -- 2025-03-21 05:382025-03-21 05:30 -- 2025-03-21 05:342025-03-21 05:00 -- 2025-03-21 05:092025-03-21 04:56 -- 2025-03-21 05:002025-03-21 04:45 -- 2025-03-21 04:502025-03-21 04:09 -- 2025-03-21 04:132025-03-21 03:41 -- 2025-03-21 03:452025-03-21 03:29 -- 2025-03-21 03:392025-03-21 03:03 -- 2025-03-21 03:072025-03-21 02:56 -- 2025-03-21 03:022025-03-21 02:44 -- 2025-03-21 02:482025-03-21 02:33 -- 2025-03-21 02:372025-03-21 02:21 -- 2025-03-21 02:272025-03-21 02:14 -- 2025-03-21 02:19
秒はみてないから 00:01:01 - 00:03:59 はほぼ 3 分だけど 2 分扱いだし、 00:01:59 - 00:04:00 はほぼ 2 分だけど 3 分扱いになるくらいの誤差はある
日によって違うだろうし、曜日の影響も大きそうだから 1 ヶ月分くらい調査しようかと思ったけど、
増田の量が思いの外多すぎて 1 日分だけでも100 ページ以上取得しないといけなかった
件数だと 2500 以上
一応取得に使ったコードも載せとく
import{ setTimeout} from"node:timers/promises"import{Browser} from"happy-dom"const getTimestamps =asyncfunction* (){constbrowser =newBrowser()const page =browser.newPage()try{for (let num = 1; ; num++){await setTimeout(3000)await page.goto(`https://anond.hatelabo.jp/?page=${num}`)constdays = page.mainFrame.document.querySelectorAll(".day")for (const day ofdays){constdate = day.querySelector("h2 .date").textContent.trim()for (const footer of day.querySelectorAll(".sectionfooter")){consttime = footer.textContent.match(/\d{2}:\d{2}/)[0]yield`${date}${time}`}}}}finally{await page.close()awaitbrowser.close()}}constdiff = (a, b) =>{returnnewDate(b +":00") -newDate(a +":00")}let prev =nullforawait (constdatetime of getTimestamps()){if (prev &amp;&amp;diff(datetime, prev)>1000 * 60 * 3){console.log(datetime, prev)}prev =datetime}
基本は空いても 5 分程度であり、最大でも10 分となっている
https://www.publickey1.jp/blog/25/chatgptxcodevscodemac.html
・立ち上げやすい、Option+Space
・diffを示してくれる時と、示してくれない時がある
・一気に「反映する」ボタンがあって嬉しい
・通常のChatGPTのように、コード示して終わりになることもある（条件が分からない）
・音声入力無理だった
・どこまで読み込めてるのかが不明、たぶんだけど、開いているファイルを貼り付けたうえで質問してるくらいになってるんじゃないかな
・ChatGPTのスレッド１個に対応する模様、ファイルをまたいでもスレッドが維持される
・Modelは選べる
・整理してとか、Lint対応してとか、そういうのが良さそう
・Modelによっては入出力が大きすぎてしんどい（正直500行くらいでもしんどくない？）
・どこまで深く読んでくれるのかが分からない
なんか仏教的だなーと思った。
諸行無常。
以下の「差延」の説明をもっとわかりやすくしてください。→Wikipediaの差延の説明をコピペ。
「差延 (さえん、différance) とは、哲学者ジャック・デリダによって考案された「語でも概念でもない」とされる造語。
およそ何者かとして同定されうるものや、自己同一性が成り立つためには、必ずそれ自身との完全な一致からのズレや違い・逸脱などの、常に既にそれに先立っている他者との関係が必要である。このことを示すために、差延という方法が導入された。
論理を簡略に述べれば、同定や自己同一性は、主語になるものと述語になるものの二つの項を前提とする（「AはAである」）。（以下略）」
「私」という存在を考えてみましょう。「私」は昨日の自分と同じはずですが、実は微妙に違います。記憶や細胞は少しずつ変化しています。この「同じでありながら違う」状態を生み出す根本的な仕組みが「差延」です。
1️⃣「同じ」のトリック
→ 完全に同じなら区別できない
→わずかな「違い」が生じることで初めて「同じ」と言える
2️⃣ 遅延効果
・インスタントコーヒー → すぐ溶ける（差延なし）
3️⃣ 影のパートナー
例）スマホ単体では何もできない
・充電器（不在時も存在を前提）
昔の哲学者：
デリダ：
「本質は関係性から生まれる」（例：指輪の意味は婚約者との関係で決まる）
・フォロワー数：数字そのものより「誰からフォローされてないか」が重要
要するに、差延とは「存在の意味が、目に見えない差異と遅延のネットワークの中で絶えず更新され続けるプロセス」と言えます。固定された本質ではなく、常に変化する関係性こそが現実を作り出すという発想です。
2024.06.21
お知らせ
「琴葉茜・葵」に関するお問い合わせにつきまして
現在「琴葉茜」に関しまして、多くのお問い合わせをいただいておりますが、当社キャラクター及びこれに関する情報の使用 に関しましては、「キャラクター使用ガイドライン」を遵守の上でご使用いただくよう、お願いいたします。
当社はキャラクターの適切な管理・運営のため、お問い合わせいただいた内容につきましては適宜調査の上、キャラクター使用ガイドラインに則りながら、当社の裁量により、厳正に対処して参ります。
判断基準や 個々の使用方法のガイドライン違反該当性についてお問い合わせ頂いても、個別に回答はいたしかねますので、何卒ご了承ください。
なお、当社及び当社キャラクターは、特定の思想や特定の出来事への賛否、及び政治信条等には、一切関知するものではございません。
お知らせ
「琴葉茜・葵」に関するお問い合わせにつきまして
当社のキャラクターである「琴葉茜・葵」は2014年の発表以来、多くのファンの方に育てていただき、この4月に9周年を迎えます。
現在「琴葉茜」に関しまして、多くのお問い合わせをいただいておりますが、当社キャラクター及びこれに関する情報の使用 に関しましては、「キャラクター使用ガイドライン」を遵守の上でご使用いただくよう、お願いいたします。
当社はキャラクターの適切な管理・運営のため、お問い合わせいただいた内容につきましては適宜調査の上、キャラクター使用ガイドラインに則りながら、当社の裁量により、厳正に対処して参ります。
判断基準や 個々の使用方法のガイドライン違反該当性についてお問い合わせ頂いても、個別に回答はいたしかねますので、何卒ご了承ください。
なお、当社及び当社キャラクターは、特定の思想や特定の出来事への賛否、及び政治信条等には、一切関知するものではございません。
