原神	☑螺旋 ☑シアター ☑花神誕祭テーマイベ ☑戦闘イベ[ongoing] ☑魔神任務 ☑熱闘モード ☐鋳境の研鑽 ☑お試し ☑月次チケダスト交換 ☑5.1追加アチーブ ☑5.1追加レシピ
スタレ	☑末日 ☑裏庭 ☑叙事 ☑立本サンポイベ[ongoing] ☑音ゲーテーマイベ ☐不可知域(進捗:凡人集2/6,シミュレーション記録84%) ☑お試し ☑月次チケエンバー交換 ☑2.6追加アチーブ(宇宙以外)
ゼンゼロ	☑立本ショウルイベ[@1] ☑チートピアテーマイベ ☑激変ノード ☑お試し ☑月次チケ残響交換 ☐1.2追加アチーブ(@ポンペイ転倒とギアコイン3万)
3rd	☑花火 Webイベ ☑年次回顧Webイベ ☑メイン探索[エリア開放待] ☑牧場テーマイベ[ongoing/Lv7] ☑お試し ☑月次基地チケ交換

柳のPV、フェチ要素や蒼角の可愛さに気を取られそうになるけど普通に映像表現すごすぎないか？

ライティングやボケやアニメ的メガネ表現や小物の揺れとかどんだけ凝れば気が済むのか

原神ラジオのシカコ回おもろかったな

写真部はちょいちょい笑いの神が降りてくるな

魔神任務がかつてないほど重かったのも衝撃だけどそれに早速ガッツリネタバレトークで触れてくれたの珍しい

10年前から久保さん推しってお便りの人絶対ラブライバーでしょわかりみしかない

Permalink | 記事への反応(0) | 03:26

2024-10-27

■B層とは何か

「B層」という概念は、消費者行動理論とマーケティングにおいて特定の消費者群を指す。以下にB層の定義、特徴、数理的アプローチを考察する。

1. 定義

B層は、消費者の情報リテラシー、社会的影響、意思決定プロセスに基づく分類であり、以下の特性を持つ。

受動的な情報受容: B層の消費者は、自発的に情報を探求せず、主にマスメディアや社会的証明に基づいて意思決定を行う傾向がある。他者の意見や流行に影響を受けやすく、自己判断基準が乏しい。
感情的および社会的要因の優位性: B層は商品選択において感情的および社会的要因を重視し、広告の感情的アピールやブランドイメージが購買意欲に大きく影響する。

2. 特徴

B層消費者の行動には以下の特徴が見られる。

情報処理の非効率性: B層は情報評価や分析が非効率であり、情報の真偽を精査する能力が乏しいため、流行や他者推薦に基づく消費行動が多い。
社会的アイデンティティの重視: B層は自己の消費行動が社会的地位やアイデンティティを表現すると認識し、流行に従うことが多い。
低い情報リテラシー: 批判的分析能力が低いため、広告や口コミに依存しやすい。

3. 数理的アプローチ

B層特性を定量的に分析するためには数理モデルが有効である。

エージェントベースモデル: 各消費者（エージェント）の行動をシミュレートし、情報受容や選択を次の式で表現できる。

P_i = (I_m * W_m + I_s * W_s) / C

ここでP_iはエージェントiの購買選択確率、I_mはメディアからの情報強度、W_mはメディア情報信頼性、I_sは社会的影響強度、W_sは社会的情報信頼性、Cは情報選択コストを示す。このモデルでB層の情報受容と意思決定を分析できる。

ネットワーク理論: B層の情報伝播をモデル化し、各消費者をノードとし情報流れを次の式で表すことができる。

P(i → j) = k_j / Σk_l

ここでP(i → j)はノードiからjへの情報伝播確率であり、k_jはノードjの接続数を示す。このアプローチでB層消費者が社会的影響を受けるメカニズムを分析可能。

Permalink | 記事への反応(1) | 13:19

2024-09-29

■anond:20240929092551

計算機科学の知識体系とネットワーク 技術

計算機科学は、情報の理論的基盤から実用的な応用まで、広範な領域をカバーする学問です。以下に、計算機科学の主要な分野と、特にネットワークに関連するトピックを体系的にまとめます。

1. 計算機科学の主要分野

2. ネットワーク 技術

ネットワークは、情報の共有と通信を可能にする計算機科学の核心的な分野です。

2.1 ネットワークの基本概念

OSI参照モデル: ネットワーク通信を7つのレイヤーに分割し、それぞれの機能を定義。

物理層: 電気信号やビット伝送。

データリンク層: フレームの転送とエラー検出。

ネットワーク層: パケットのルーティング。

トランスポート層: エンドツーエンドの通信制御。

セッション層: コネクションの管理。

プレゼンテーション層: データ形式の変換。

アプリケーション層: ユーザーアプリケーションが使用するプロトコル。

TCP/IP モデル: 現実のインターネットで使用される4層モデル。

2.2 ネットワーク トポロジー

スター型: 中央のハブを介して各ノードが接続。

リング型: 各ノードが一方向または双方向に隣接ノードと接続。

バス型: すべてのノードが一本の通信ラインを共有。

メッシュ型: ノード間が多重に接続され、高い冗長性を持つ。

2.3 ネットワーク プロトコル

IP（Internet Protocol）: データのパケット化とアドレッシング。

TCP（Transmission Control Protocol）: 信頼性のある通信を提供。

UDP（User Datagram Protocol）: 信頼性よりも速度を重視した通信。

HTTP/HTTPS: ウェブデータの送受信。

FTP/SFTP: ファイル転送プロトコル。

SMTP/POP3/IMAP: 電子メールの送受信。

2.4 ネットワーク デバイス

ルーター: 異なるネットワーク間のパケット転送とルーティング。

スイッチ: 同一ネットワーク内でのフレーム転送。

ブリッジ: ネットワークセグメントの接続。

ゲートウェイ: 異なるプロトコル間の通信を可能にする。

2.5 ワイヤレス ネットワーク

Wi-Fi（802.11規格）: 無線LANの標準技術。

Bluetooth: 近距離間のデータ通信。

セルラーネットワーク: モバイル通信（3G、4G、5G）。

2.6 ネットワーク セキュリティ

ファイアウォール: 不正なアクセスを防止。

IDS/IPS（侵入検知/防止システム）: ネットワーク攻撃の検出と防御。

VPN（仮想プライベートネットワーク）: 安全なリモートアクセスを提供。

暗号化技術: データの機密性を保護。

2.7 クラウド ネットワーキング

クラウドサービスモデル: IaaS、PaaS、SaaS。

仮想ネットワーク: ソフトウェアによるネットワーク構築。

SDN（Software-Defined Networking）: ネットワークの柔軟な管理と制御。

2.8 分散 システム

分散コンピューティング: 複数のノードでタスクを分散処理。

ブロックチェーン: 分散型台帳技術。

2.9 IoT（モノのインターネット）

センサーネットワーク: デバイス間の通信とデータ収集。

IoT プロトコル: MQTT、CoAPなどの軽量プロトコル。

2.10 ネットワーク 管理とモニタリング

SNMP（Simple Network Management Protocol）: ネットワークデバイスの管理。

ネットワークトラフィック分析: パフォーマンスとセキュリティの最適化。

3. ネットワーク 技術の最新動向

3.1 5Gと次世代 通信

高帯域幅と低遅延: リアルタイムアプリケーションの実現。

エッジコンピューティング: データ処理の分散化。

3.2 SD-WAN（Software-Defined Wide Area Network）

ネットワークの仮想化: 柔軟なWAN構築とコスト削減。

中央集中的な管理: ネットワークポリシーの一元管理。

3.3 ネットワークの自動化とAI

ネットワークオーケストレーション: 自動化された設定と管理。

AIによるトラフィック最適化: パフォーマンスの向上と障害予測。

3.4 ゼロ トラスト セキュリティ

信頼しない設計: 常に認証と検証を行うセキュリティモデル。

マイクロセグメンテーション: ネットワーク内部の細かなアクセス制御。

4. 学習 リソースと参考文献

4.1 推奨書籍

『コンピュータネットワーク』アンドリュー・S・タネンバウム著

『TCP/IP詳解』 W. リチャード・スティーブンス著

『ネットワークはなぜつながるのか』戸根勤著

4.2 オンライン コース

Coursera: 「コンピュータネットワーク」、「ネットワークセキュリティ」コース

edX: 「Computer Networking」、「Cybersecurity Fundamentals」

4.3 標準化 団体とリソース

IETF（Internet Engineering Task Force）: ietf.org

IEEE Communications Society: comsoc.org

W3C（World Wide Web Consortium）: w3.org

Permalink | 記事への反応(1) | 09:38

2024-08-17

■anond:20240817015407

依存関係は木で表現

ノードにロック持たせる

ロックに条件持たせる

やりたいことはできてるように見えるが、うーんしんどい

# Entity Relation Diagram
# ```mermaid
# ---
# title: Rental Office example
# ---
# erDiagram
#     OFFICE ||--|{ ROOM : x
#     OFFICE {
#         number office_id
#     }
#     ROOM {
#         number office_id
#         number room_id
#     }
#     ROOM ||--|{ SCHEDULE : x
#     SCHEDULE {
#       number room_id
#       datetime start_at
#       datetime end_at
#     }
#     OFFICE ||--|{ BUSINESS_HOUR : x
#     BUSINESS_HOUR {
#         number office_id
#         enum week_of_day
#         datetime start_at
#         datetime end_at
#     }
# ```

# Directed Acyclic Graph
#
# ```mermaid
# graph LR
#     A[OFFICE] --> B[ROOM]
#     B --> C[SCHEDULE]
#     A[OFFICE] --> D[BUSINESS_HOUR]
#     D --> C
#     A --> C
# ```


# 基底クラス: EntityLock
class EntityLock
  attr_accessor :entity_name, :entity_locked, :attribute_locks

  def initialize(entity_name)
    @entity_name = entity_name
    @entity_locked = false # エンティティ全体のロック状態を保持
    @attribute_locks = {}  # IDに対するロックを管理するハッシュ
  end

  def lock_entity
    @entity_locked = true
    puts "Entity '#{@entity_name}' is now locked."
  end

  def unlock_entity
    @entity_locked = false
    puts "Entity '#{@entity_name}' is now unlocked."
  end

  def lock(attributes)
    entity_id = attributes["#{@entity_name.downcase}_id"]
    if entity_id &amp;&amp; !@attribute_locks[entity_id]
      @attribute_locks[entity_id] = true
      puts "#{@entity_name} with ID '#{entity_id}' is now locked."
    end
  end

  def unlock(attributes)
    entity_id = attributes["#{@entity_name.downcase}_id"]
    if entity_id &amp;&amp; @attribute_locks[entity_id]
      @attribute_locks.delete(entity_id)
      puts "#{@entity_name} with ID '#{entity_id}' is now unlocked."
    end
  end

  def locked?(attributes)
    # まずエンティティ全体がロックされているかチェック
    return true if @entity_locked

    # 次に特定のIDがロックされているかチェック
    entity_id = attributes["#{@entity_name.downcase}_id"]
    if entity_id &amp;&amp; @attribute_locks[entity_id]
      return true
    end

    # ロックされていなければfalseを返す
    false
  end
end

# 子クラス: OfficeLock, RoomLock, ScheduleLock
class OfficeLock < EntityLock
  def initialize
    super("Office")
  end
end

class RoomLock < EntityLock
  def initialize
    super("Room")
  end
end

class ScheduleLock < EntityLock
  def initialize
    super("Schedule")
  end
end

# 子クラス: BusinessHourLock
class BusinessHourLock < EntityLock
  def initialize
    super("BusinessHour")
    @attribute_locks = [] # BusinessHour用のロックを配列で管理
  end

  def lock(attributes)
    start_at = attributes["start_at"]
    end_at = attributes["end_at"]
    if start_at &amp;&amp; end_at
      @attribute_locks << [start_at, end_at]
      puts "BusinessHour from '#{start_at}' to '#{end_at}' is now locked."
    end
  end

  def unlock(attributes)
    start_at = attributes["start_at"]
    end_at = attributes["end_at"]
    if @attribute_locks.include?([start_at, end_at])
      @attribute_locks.delete([start_at, end_at])
      puts "BusinessHour from '#{start_at}' to '#{end_at}' is now unlocked."
    end
  end

  def locked?(attributes)
    # まずエンティティ全体がロックされているかチェック
    return true if @entity_locked

    # 次に特定の時間範囲がロックされているかチェック
    start_at = attributes["start_at"]
    end_at = attributes["end_at"]
    if start_at &amp;&amp; end_at
      @attribute_locks.each do |(locked_start, locked_end)|
        if locked_start <= start_at &amp;&amp; end_at <= locked_end
          return true
        end
      end
    end

    # ロックされていなければfalseを返す
    false
  end
end

# TreeNodeクラス
class TreeNode
  attr_accessor :name, :children, :parents, :lock

  def initialize(name, lock)
    @name = name
    @children = []
    @parents = []  # 複数の親ノードを保持する配列
    @lock = lock   # TreeNodeにロックを持たせる
  end

  def add_child(child_node)
    child_node.parents << self  # 子ノードにこのノードを親として追加
    @children << child_node
  end

  def display(level = 0)
    indent = " " * (level * 4)
    puts "#{indent}#{@name}"
    @children.each { |child| child.display(level + 1) }
  end

  def has_dependency
    return false if @parents.empty?

    @parents.each do |parent|
      puts "#{@name} is dependent on #{parent.name}"
      return true
    end

    @parents.any?(&amp;:has_dependency)
  end

  def locked?(attributes = {})
    # 自身がロックされているか確認
    return true if @lock.locked?(attributes)

    # 親ノードがロックされているか再帰的に確認
    @parents.any? { |parent| parent.locked?(attributes) }
  end
end

# 木構造の組み立て

# ロックオブジェクトの作成
office_lock = OfficeLock.new
room_lock = RoomLock.new
schedule_lock = ScheduleLock.new
business_hour_lock = BusinessHourLock.new

# ノードの作成
office_node = TreeNode.new("Office", office_lock)
room_node = TreeNode.new("Room", room_lock)
schedule_node = TreeNode.new("Schedule", schedule_lock)
business_hour_node = TreeNode.new("BusinessHour", business_hour_lock)

# ノード間の依存関係の設定
office_node.add_child(room_node)           # Office -> Room
room_node.add_child(schedule_node)         # Room -> Schedule
office_node.add_child(business_hour_node)  # Office -> BusinessHour
business_hour_node.add_child(schedule_node) # BusinessHour -> Schedule

# 木構造の表示
office_node.display

# ロックの確認
puts "Case 1. Office全体がロックされた場合"
puts "Is office_node locked? #{office_node.locked?({})}"                 # false
puts "Is schedule_node locked? #{schedule_node.locked?({})}"             # false
office_lock.lock_entity
puts "Is office_node locked? #{office_node.locked?({})}"                 # true
puts "Is schedule_node locked? #{schedule_node.locked?({})}"             # true
office_lock.unlock_entity

puts "Case 2. Room id:1 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.lock({ "room_id" => 1 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.unlock({ "room_id" => 1 })

puts "Case 3. BusinessHour start_at:0 end_at:5 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}"  # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.lock({ "start_at" => 0, "end_at" => 5 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}"  # true 
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.unlock({ "start_at" => 0, "end_at" => 5 })

Permalink | 記事への反応(1) | 22:00

■anond:20240817001425

で・・・できたけど木の組み立てがしんどすぎるー

class TreeNode:
    def __init__(self, name, attributes=None):
        self.name = name
        self.attributes = attributes or {}
        self.children = []

    def add_child(self, child_node):
        self.children.append(child_node)

    def display(self, level=0):
        indent = "    " * level
        print(f"{indent}{self.name} {self.attributes}")
        for child in self.children:
            child.display(level + 1)

    def has_dependency(self):
        # ルートノードや属性を持たないノードは依存関係を判定しない
        if not self.children:
            return False

        for child in self.children:
            # 子ノードがBusinessHourかScheduleかをチェック
            if "start_at" in child.attributes and "end_at" in child.attributes:
                child_start = child.attributes["start_at"]
                child_end = child.attributes["end_at"]

                # 現在のノードがBusinessHourで、子がScheduleの場合
                if "start_at" in self.attributes and "end_at" in self.attributes:
                    self_start = self.attributes["start_at"]
                    self_end = self.attributes["end_at"]

                    if self_start &lt;= child_start and self_end &gt;= child_end:
                        print(f"{child.name} (start_at: {child_start}, end_at: {child_end}, room_id: {child.attributes['room_id']}) is dependent on {self.name} (start_at: {self_start}, end_at: {self_end})")
                    else:
                        print(f"{child.name} (start_at: {child_start}, end_at: {child_end}, room_id: {child.attributes['room_id']}) is NOT dependent on {self.name} (start_at: {self_start}, end_at: {self_end})")

                # 現在のノードがRoomで、子がScheduleの場合
                elif self.name.startswith("Room"):
                    print(f"{child.name} (start_at: {child_start}, end_at: {child_end}, room_id: {child.attributes['room_id']}) is dependent on Room {self.name[-1]}")
                else:
                    child.has_dependency()

            # 子ノードが属性を持たない場合、再帰的に依存関係をチェック
            else:
                child.has_dependency()

# ノードの作成
root = TreeNode("Root")
office_node = TreeNode("Office")

# Roomノードの作成
room1_node = TreeNode("Room1")
room2_node = TreeNode("Room2")

# BusinessHourノードの作成
business_hour1_node = TreeNode("BusinessHour1", {"start_at": 9, "end_at": 12})
business_hour2_node = TreeNode("BusinessHour2", {"start_at": 13, "end_at": 17})

# Scheduleノードの作成
schedule1_node = TreeNode("Schedule1", {"start_at": 10, "end_at": 11, "room_id": 1})
schedule2_node = TreeNode("Schedule2", {"start_at": 14, "end_at": 15, "room_id": 1})
schedule3_node = TreeNode("Schedule3", {"start_at": 10, "end_at": 11, "room_id": 2})
schedule4_node = TreeNode("Schedule4", {"start_at": 14, "end_at": 15, "room_id": 2})

# 木構造の構築
root.add_child(office_node)
office_node.add_child(room1_node)
office_node.add_child(room2_node)
office_node.add_child(business_hour1_node)
office_node.add_child(business_hour2_node)

# Room1にSchedule1, Schedule2を追加
room1_node.add_child(schedule1_node)
room1_node.add_child(schedule2_node)

# Room2にSchedule3, Schedule4を追加
room2_node.add_child(schedule3_node)
room2_node.add_child(schedule4_node)

# BusinessHour1にSchedule1, Schedule3を追加
business_hour1_node.add_child(schedule1_node)
business_hour1_node.add_child(schedule3_node)

# BusinessHour2にSchedule2, Schedule4を追加
business_hour2_node.add_child(schedule2_node)
business_hour2_node.add_child(schedule4_node)

# 木構造の表示
root.display()

# 依存関係のチェック
office_node.has_dependency()
room1_node.has_dependency()
room2_node.has_dependency()
business_hour1_node.has_dependency()
business_hour2_node.has_dependency()

Root {}
    Office {}
        Room1 {}
            Schedule1 {'start_at': 10, 'end_at': 11, 'room_id': 1}
            Schedule2 {'start_at': 14, 'end_at': 15, 'room_id': 1}
        Room2 {}
            Schedule3 {'start_at': 10, 'end_at': 11, 'room_id': 2}
            Schedule4 {'start_at': 14, 'end_at': 15, 'room_id': 2}
        BusinessHour1 {'start_at': 9, 'end_at': 12}
            Schedule1 {'start_at': 10, 'end_at': 11, 'room_id': 1}
            Schedule3 {'start_at': 10, 'end_at': 11, 'room_id': 2}
        BusinessHour2 {'start_at': 13, 'end_at': 17}
            Schedule2 {'start_at': 14, 'end_at': 15, 'room_id': 1}
            Schedule4 {'start_at': 14, 'end_at': 15, 'room_id': 2}
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on Room 1
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on Room 1
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on Room 2
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on Room 2
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on BusinessHour2 (start_at: 13, end_at: 17)
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on BusinessHour2 (start_at: 13, end_at: 17)
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on Room 1
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on Room 1
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on Room 2
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on Room 2
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on BusinessHour2 (start_at: 13, end_at: 17)
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on BusinessHour2 (start_at: 13, end_at: 17)

Permalink | 記事への反応(1) | 00:35

■anond:20240816235943

高さ3の有向木で根からAという節点が生えAからBという葉が生える

class TreeNode:
    def __init__(self, name, attributes=None):
        self.name = name
        self.attributes = attributes or {}
        self.children = []

    def add_child(self, child_node):
        self.children.append(child_node)

    def display(self, level=0):
        indent = "    " * level
        print(f"{indent}{self.name} {self.attributes}")
        for child in self.children:
            child.display(level + 1)

    def has_dependency(self):
        # ルートノードや属性を持たないノードは依存関係を判定しない
        if not self.children or "start" not in self.attributes or "end" not in self.attributes:
            return False

        # Aノードのstartとendを取得
        start = self.attributes["start"]
        end = self.attributes["end"]

        # すべての子ノード（Bノード）に対して依存関係をチェック
        for child in self.children:
            if "position" in child.attributes:
                position = child.attributes["position"]
                if start &lt;= position &lt;= end:
                    print(f"{child.name} (position: {position}) is dependent on {self.name} (start: {start}, end: {end})")
                    return True
                else:
                    print(f"{child.name} (position: {position}) is NOT dependent on {self.name} (start: {start}, end: {end})")
        return False

# ノードの作成
root = TreeNode("Root")
a_node = TreeNode("A", {"start": 10, "end": 20})
b1_node = TreeNode("B1", {"position": 15})
b2_node = TreeNode("B2", {"position": 25})

# 木構造の構築
root.add_child(a_node)
a_node.add_child(b1_node)
a_node.add_child(b2_node)

# 木構造の表示
root.display()

# 依存関係のチェック
a_node.has_dependency()

こうかー

Permalink | 記事への反応(1) | 00:08

2024-08-08

■[経済メモ] いくつかの数学 理論の統合

1. 無差別曲線 分析

効用関数 U: X → ℝ が消費者の選好を定義し、効用空間 X 上のレベルセットが無差別曲線を形成する。無差別曲線 U⁻¹(c) は効用関数 U のレベルセットとして定義される。

効用関数: U(x) = c, ここで x ∈ X は消費の組み合わせ。
無差別曲線: U⁻¹(c) = {x ∈ X | U(x) = c} は X 上のサブマンフォルド。

無差別曲線は効用空間内でのプレーンに対応し、その勾配 ∇U は無差別曲線に直交する。

2. ゲーム理論

ゲーム理論では、プレイヤー i の戦略空間を多様体 S_i とし、全プレイヤーの戦略空間を S = ∏_i S_i とする。プレイヤーの利得関数 π_i: S → ℝ はゲームの結果として得られる。

戦略空間: S = ∏_i S_i、ここで S_i はプレイヤー i の戦略空間。
利得関数: π_i(s) = 利得、ここで s ∈ S は戦略の組み合わせ。

プレイヤーの戦略の選択は戦略空間 S 上の点で表現され、ゲームの均衡は戦略空間上での最大化問題としてモデル化される。

3. 完全ベイズ均衡

完全ベイズ均衡では、情報の不完全性を考慮し、プレイヤーの信念と戦略を統合する。プレイヤー i のタイプ空間を Θ_i とし、信念空間を Δ(Θ_i) とする。信念 μ_i はプレイヤー i のタイプ θ_i に対する確率分布を示す。

信念: μ_i ∈ Δ(Θ_i)。
均衡条件: プレイヤー i の戦略 σ_i が、信念に基づく利得の期待値を最大化する場合、均衡が成立する。すなわち、σ_i(θ_i) ∈ argmax_{s_i ∈ S_i} E[π_i(s_i, s_{-i}) | θ_i]。

4. 情報 理論との統合

情報理論の要素をゲーム理論に統合するために、以下のように対応させる：

1. エントロピーと不確実性:

エントロピー: プレイヤーの信念 μ_i のエントロピー H(μ_i) は情報の不確実性を示す。エントロピー H(μ_i) = -Σ P(θ_i) log P(θ_i) で定義される。
情報の多様体: 確率分布 P は情報空間の多様体 ℙ 上の点として表現される。

2. ゲームの情報構造:

情報構造: プレイヤー i の信念 μ_i を用いて、ゲームの戦略空間 S_i 上での利得の期待値 E[π_i(s_i, s_{-i}) | θ_i] を最適化する。ここで、信念 μ_i によるエントロピーは、ゲームの戦略選択に影響を与える。

3. 情報量と戦略の選択:

情報量: プレイヤーの選択する戦略は、情報空間 ℙ 上の点としてモデル化され、エントロピー H(μ_i) がこの選択に影響を与える。戦略の選択は、情報量を最大化するように調整される。

統合的枠組み

ゲーム理論と情報理論を統合するために、以下の枠組みを考える：

1. 共通の多様体: 効用空間 X、戦略空間 S、信念空間 Δ(Θ)、情報空間 ℙ を統一的な多様体としてモデル化する。

2. ファイバーバンドル: 各理論の構造をファイバーバンドルとして表現し、効用、戦略、信念、情報を抽象的に結びつける。

3. リーマン計量: 各多様体上のリーマン計量を用いて、効用、戦略、信念、情報の変化を統一的に扱う。

graphvizによる視覚化

digraph G {
    // グラフの設定
    rankdir=LR;
    node [shape=box, color=lightgrey];

    // ノードの定義
    UtilitySpace [label="効用空間\n(X, U)", shape=ellipse];
    StrategySpace [label="戦略空間\n(S, π)", shape=ellipse];
    BeliefSpace [label="信念空間\n(Δ(Θ), μ)", shape=ellipsel];
    InformationSpace [label="情報空間\n(ℙ, H)", shape=ellipse];

    // ノード間の関係
    UtilitySpace -&gt; StrategySpace [label="効用関数\nU(x)"];
    StrategySpace -&gt; BeliefSpace [label="戦略の期待値\nE[π_i | θ_i]"];
    BeliefSpace -&gt; InformationSpace [label="エントロピー\nH(μ)"];
    InformationSpace -&gt; UtilitySpace [label="情報の多様体\nℙ"];

    // フォーマット設定
    edge [color=black, arrowhead=normal];
}

digraph G {
    rankdir=LR;
    node [shape=ellipse, style=filled, color=white, fontcolor=black, penwidth=2, fillcolor=white, color=black];

    // Nodes
    UtilitySpace [label="Utility Space (X)"];
    StrategySpace [label="Strategy Space (S)"];
    BeliefSpace [label="Belief Space (Δ(Θ))"];
    InformationSpace [label="Information Space (ℙ)"];
    FiberBundle [label="Fiber Bundle"];
    RiemannMetric [label="Riemannian Metric"];
    KL_Divergence [label="Minimize D_{KL}(μ_i || ν_i)"];
    ParetoOptimality [label="Pareto Optimality"];
    Constraints [label="Constraints"];
    Optimization [label="Optimization"];

    // Edges
    UtilitySpace -&gt; FiberBundle;
    StrategySpace -&gt; FiberBundle;
    BeliefSpace -&gt; FiberBundle;
    InformationSpace -&gt; FiberBundle;
    FiberBundle -&gt; RiemannMetric;
    RiemannMetric -&gt; KL_Divergence [label="Measure Change"];
    KL_Divergence -&gt; Optimization;
    Constraints -&gt; Optimization;
    Optimization -&gt; ParetoOptimality [label="Achieve"];

    // Subgraph for constraints
    subgraph cluster_constraints {
        label="Constraints";
        node [style=filled, color=white, fontcolor=black, penwidth=2];
        StrategyChoice [label="Strategy Choice"];
        BeliefUpdate [label="Belief Update"];
        StrategyChoice -&gt; BeliefUpdate;
        BeliefUpdate -&gt; Constraints;
    }
}

Permalink | 記事への反応(0) | 22:27

2024-07-28

■「全ての間の関係」とはどういうことか

偉い人に「全ての間の関係を保存するシステムを作れねぇか」と言われたことがある

要件がざっくりしすぎてなんのことを言っているか全くわからないだろう、俺もわからん

で、数学的に分析した結果、関係とは、ノード集合Vがまず存在し、

r: ∪(V^{q+1}) → R

を意味する。要するに、この世の森羅万象を表すノードを任意個引っ張ってきて、そこに数値(あるいはラベル)を割り当てるわけだ。

ところが、森羅万象など事前に知ることは出来ない。どうするのか。

と、アイデアはいくつかあった。

ノードや関係を利用者が追加できる仕組みを作ること。
クロールなどを行い、そこから自動的に関係を見つける。
既存のナレッジ DBを起点にし、起点の関係から関係抽出モデルを学習させて新たな関係を見つける。

結局、ビジネスの衰退によりそのようなシステムを作ることはなくなったが、以下のようなツールはそれに近いと思う。

Compare anything: https://www.diffen.com/

このツールでは、「関係性」を見つける代わりに、ノードの属性や説明を比較させるような仕組みになっている。

なーるほど、こういうやり方があったかぁ、とこれを見たときは思ったね。

でも日本では流行らない可能性が高い。というのも、こういうツールは、Wikipedia 編集レベルで熱意がなければ知識が全然増えていかないのである。

使い方としては、2つのアイテム名を入力してポチッとボタンを押し、記事があればそれを表示、なければノードの属性を表示、なければ編集ボタンを表示、となっている。

森羅万象のノードの編集を誰が行うのか、という話である。

だが、最近のLLMの進化により、関係や説明や属性の抽出を自動的に行える可能性が出てきた。

その場合、「○○(ジャンル)の属性はA1,...,Anです。これらをインターネット上の情報から抽出してください」といったプロンプトになるかもしれない。

少なくとも「インターネット上に存在する」様々な物事の関係性を、LLMを用いて自動抽出し、それを保存できるわけである。

Diffbotというツールがあるが、LLMはそれよりも高価な代替案であり、成功すればかなり便利な知識グラフを構築できる可能性がある (ただしLLMとサーバーの利用コストは高い)

追記: 次のリンクのような議論は関連性が高い。https://community.openai.com/t/entity-and-relation-extraction-fine-tuning/35464

追記2:

いいか、まず関係抽出ってのは知識 DBの任意のエンティティ間の関係ラベルを予測するような問題なんよ
で、ネット情報などをクロールして関係ラベルを見つけるってタスクがあるんだけど、LLMが出る前は精度の低い方法で文書を構造化するような方法しかなかったわけ
で今思い出したんだけど、「じゃあLLMつかえるじゃん」ってね
過去にできなかったことができるようになったという思いつきを書いたまでよ

Permalink | 記事への反応(2) | 08:07

2024-07-21

■決定木とは何か

レベル1: 小学生向け

決定木は、質問を使って答えを見つけるゲームのようなものです。木の形をした図を使って、質問と答えを整理します。例えば、「今日は外で遊べるかな？」という大きな質問から始めます。

まず「雨が降っていますか？」と聞きます。「はい」なら「家で遊ぼう」、「いいえ」なら次の質問に進みます。次に「宿題は終わっていますか？」と聞きます。「はい」なら「外で遊ぼう」、「いいえ」なら「宿題をしてから遊ぼう」となります。

このように、質問を重ねていくことで、最終的な答えにたどり着きます。決定木は、こうした「もし〜なら」という考え方を使って、物事を順序立てて考えるのに役立ちます。

レベル2: 大学生向け

決定木は、機械学習における重要な分類・回帰アルゴリズムの一つです。データを特定の特徴に基づいて分割し、ツリー構造を形成することで、新しいデータの分類や予測を行います。

決定木の構造は以下の要素から成り立っています：

1. ルートノード：最初の分割点

2. 内部ノード：中間の分割点

3. 葉ノード：最終的な予測や分類結果

4. 枝：各ノードを結ぶ線、条件を表す

決定木の構築プロセスは、以下のステップで行われます：

1. 最も情報量の多い特徴を選択

2. その特徴に基づいてデータを分割

3. 各サブセットに対して1と2を再帰的に繰り返す

4. 停止条件（深さ制限や最小サンプル数など）に達したら終了

決定木の利点は、解釈が容易で直感的であること、非線形の関係性も捉えられること、特徴量の重要度を評価できることなどです。一方で、過学習しやすい傾向があり、小さなデータの変化に敏感に反応する欠点もあります。

レベル3: 大学院生向け

決定木は、分類および回帰問題に適用可能な非パラメトリックな監督学習アルゴリズムです。特徴空間を再帰的に分割し、各分割点で最適な特徴と閾値を選択することで、データを階層的に構造化します。

決定木の構築プロセスは、以下の数学的基準に基づいて行われます：

1. 分類問題の場合：

情報利得（Information Gain）: ΔI = H(S) - Σ((|Sv| / |S|) * H(Sv))
ジニ不純度（Gini Impurity）: G = 1 - Σ(pi^2)

2. 回帰問題の場合：

平均二乗誤差（Mean Squared Error）: MSE = (1/n) * Σ(yi - ŷi)^2
平均絶対誤差（Mean Absolute Error）: MAE = (1/n) * Σ|yi - ŷi|

ここで、H(S)はエントロピー、Svは分割後のサブセット、piはクラスiの確率、yiは実際の値、ŷiは予測値を表します。

過学習を防ぐために、以下の手法が用いられます：

1. 事前剪定（Pre-pruning）：成長の早期停止

2. 事後剪定（Post-pruning）：完全に成長した木を後から刈り込む

決定木の性能向上のために、アンサンブル学習手法（ランダムフォレスト、勾配ブースティング木など）と組み合わせることが一般的です。

レベル4: 専門家向け

決定木は、特徴空間の再帰的分割に基づく非パラメトリックな監督学習アルゴリズムであり、分類および回帰タスクに適用可能です。その理論的基盤は、情報理論と統計学に深く根ざしています。

決定木の構築アルゴリズムとして最も一般的なのは、CART（Classification and Regression Trees）です。CARTは以下の手順で実装されます：

1. 特徴選択：各ノードで最適な分割特徴を選択

分類：ジニ不純度または情報利得を最小化
回帰：平均二乗誤差を最小化

2. 分割点の決定：連続値特徴の場合、最適な閾値を決定

二分探索アルゴリズムを用いて計算効率を向上

3. 木の成長：再帰的に子ノードを生成

停止条件：最大深さ、最小サンプル数、不純度の減少量など

4. 剪定：過学習を防ぐために木を最適化

コスト複雑度剪定（Cost-Complexity Pruning）： α(T) = (R(t) - R(T)) / (|T| - 1) ここで、R(t)は根ノードtの誤差、R(T)は部分木Tの誤差、|T|は葉ノード数

決定木の理論的特性：

VC 次元：決定木のVC 次元は、葉ノード数に比例
一貫性：十分な訓練データがある場合、決定木は一貫推定量となる
計算複雑性：構築時はO(nlog(n))、予測時はO(log(n))（nはデータ点数）

決定木の拡張：

1. 多変量決定木：複数の特徴の線形結合を用いて分割

2. 軟判別木：確率的な分割を行い、滑らかな決定境界を生成

3. 条件付き推論木：統計的仮説検定に基づく特徴選択を行う

これらの高度な手法により、決定木の表現力と汎化性能が向上し、より複雑なパターンの学習が可能となります。

レベル5: 廃人向け

決定木は、特徴空間Xの再帰的分割に基づく非パラメトリックな監督学習アルゴリズムであり、その理論的基盤は統計的学習理論、情報理論、および計算学習理論に深く根ざしています。

決定木の数学的定式化：

Let D = {(x₁, y₁), ..., (xₙ, yₙ)} be the training set, where xᵢ ∈ X and yᵢ ∈ Y. The decision tree T: X → Y is defined as a hierarchical set of decision rules.

For classification: P(y|x) = Σᵢ P(y|leaf_i) * I(x ∈ leaf_i)

For regression: f(x) = Σᵢ μᵢ * I(x ∈ leaf_i) where I(·) is the indicator function, leaf_i represents the i-th leaf node.

決定木の最適化問題： min_T Σᵢ L(yᵢ, T(xᵢ)) + λ * Complexity(T) where L is the loss function, λ is the regularization parameter, and Complexity(T) is a measure of tree complexity (e.g., number of leaves).

特徴選択と分割基準：

1. エントロピーと相互情報量：

H(Y|X) = -Σᵧ Σₓ p(x,y) log(p(y|x))

I(X;Y) = H(Y) - H(Y|X)

2. ジニ不純度：

Gini(t) = 1 - Σᵢ p(i|t)²

3. 平均二乗誤差（回帰）：

MSE(t) = (1/|t|) * Σᵢ (yᵢ - ȳ_t)²

高度な理論的考察：

1. 一致性と収束速度：決定木の一致性は、Breiman et al. (1984)によって証明されました。収束速度はO(n^(-1/(d+2)))であり、dは特徴空間の次元です。

2. バイアス-バリアンストレードオフ：深い木は低バイアス・高バリアンス、浅い木は高バイアス・低バリアンスとなります。最適な深さは、バイアスとバリアンスのトレードオフによって決定されます。

3. 決定木の表現力：任意のブール関数は、十分に深い決定木で表現可能です。これは、決定木がユニバーサル近似器であることを意味します。

4. 計算複雑性理論：最適な決定木の構築はNP完全問題であることが知られています（Hyafil & Rivest, 1976）。そのため、実用的なアルゴリズムは貪欲な近似アプローチを採用しています。

5. 正則化と構造リスク最小化：L0正則化（葉ノード数のペナルティ）やL2正則化（葉ノードの予測値に対するペナルティ）を用いて、構造リスク最小化原理に基づいたモデル選択を行います。

6. 情報幾何学的解釈：決定木の学習過程は、特徴空間上の確率分布の漸進的な分割と見なすことができ、情報幾何学の観点から解析可能です。

7. カーネル決定木：非線形カーネル関数を用いて特徴空間を暗黙的に高次元化し、より複雑な決定境界を学習する手法です。

8. 量子決定木：量子コンピューティングの原理を応用し、古典的な決定木を量子系に拡張した手法です。量子重ね合わせを利用して、指数関数的に多くの分岐を同時に評価できる可能性があります。

これらの高度な理論と技術を組み合わせることで、決定木アルゴリズムの性能と適用範囲を大幅に拡張し、より複雑な学習タスクに対応することが可能となります。

Permalink | 記事への反応(0) | 11:39

2024-06-27

■anond:20240627150149

1つの CPUコアでの逐次処理を高速化することには限界があるため、コア数を増やし並列化させることで性能を向上させる必要がある、という考え方について、市販のサーバコンピュータとスーパーコンピュータで違いはありますか？

この考え方に関して、市販のサーバコンピュータとスーパーコンピュータの間には基本的な違いはありません。両者とも、シングルコアの性能向上に限界がある中で、並列化によって全体的な処理能力を高めるという方向性を共有しています。しかし、その実現方法や規模には大きな違いがあります。

サーバコンピュータとスーパーコンピュータの並列化アプローチの比較
1. 並列化の規模

サーバコンピュータ: 数個から数百個のコアを使用
スーパーコンピュータ: 数万から数百万個のコアを使用

2. 並列化の方法

サーバコンピュータ:

主にSMP（対称型マルチプロセッシング）やNUMA（非一様メモリアクセス）アーキテクチャを採用
比較的少数のプロセッサを密結合


スーパーコンピュータ:

大規模な分散メモリシステムを採用
多数のノードを高速ネットワークで接続



3. 相互接続技術

サーバコンピュータ:

一般的なネットワーク技術（イーサネットなど）を使用


スーパーコンピュータ:

専用の高速相互接続技術（InfiniBand、Tofu Interconnectなど）を使用



4. ソフトウェアとプログラミングモデル

サーバコンピュータ:

OpenMPやpthreadsなど、比較的シンプルな並列プログラミングモデルを使用


スーパーコンピュータ:

MPIなどの複雑な分散メモリプログラミングモデルを使用
ハイブリッド並列化（MPI+OpenMP）などの高度な技術も適用



5. スケーラビリティ

サーバコンピュータ:

中規模までの並列化に適しているが、大規模になるとスケーラビリティに課題


スーパーコンピュータ:

極めて大規模な並列化に対応できるよう設計されている



6. 用途

サーバコンピュータ:

ウェブサービス、データベース、ビジネスアプリケーションなど、比較的汎用的な用途


スーパーコンピュータ:

気象予報、宇宙物理学シミュレーション、分子動力学計算など、極めて計算負荷の高い科学技術計算

Permalink | 記事への反応(0) | 15:15

2024-06-18

■プロジェクトX、出演NGなのでは。あるいは富士通 半導体の敗北の歴史

富士通に忖度してるとか言ってるけど、あれ、普通に取材 NGだったんじゃないかな。

当時の経緯を知ってると「私の名前は出さないでください」ってなったとしても不思議じゃないと思う。そうなれば当然NHKも富士通も触れないし、本人が拒否したんですなんて発表するわけもないし（例え親族が声を上げたとしても）

京コンピュータって、富士通半導体の最後の打ち上げ花火だったんだよ。

当時の話

京の開発が進み、実際に生産されるころは、経営方針として富士通は半導体撤退をするかどうかで揉めていたころだった。

京コンピュータは、富士通が自社工場で作った最後のスパコンであると同時に、国のトップ開発のHPCにおいて、富士通が単体で作り上げた初めてのHPCでもあった。

これは、富士通が優れている、というよりも、逃げ遅れたと表現してもよいかもしれない。HPCのプロジェクトからは、NECと東芝が次々と撤退していたのだ。

当時半導体の重い投資に堪えられなくなった電機各社とその銀行団は、自社から半導体部門、少なくとも工場を切り離したがっていた。まさに、それどころではなかったのだ。

しかし富士通はまだ撤退を決断せず、他社とは一線と画した対応をしていた。

ようにみえた。

富士通も撤退戦を開始

京コンピュータのCPUは、45nmのプロセスで作ると言うことで言っていたためか、富士通はなんとか自社で開発した。けれど、京に乗せたプロセッサで最後になった。次のプロセスは開発されていない。

https://news.mynavi.jp/techplus/article/architecture-467/

さらに、当時、45nmのプロセスは安定して無い状況で無理矢理作ったと言う話もあったはずだ。これは京コンピュータ以降はTSMCに委託することが決まっていたため、既に投資が絞られていたためでもある。

（後にTSMC版の進んだプロセスで製造されたSPARCを使ったミニ京コンピュータが何個か作られたのだが、ノード辺りの性能が30％以上アップしたと言う。これはプロセスが細分化された以上の性能向上であった）

富士通が、自社の半導体部門を富士通セミコンとして切り離したのが2008年。京コンピュータ用のプロセッサを生産したのが2010年の三重工場であった。

その三重工場は2013年にさらに別会社として切り離され、現在は完全に売却されて富士通に残ってない。

また、同じく半導体工場としては福島県の會津富士通があったんだが、その時の工場撤退のエピソードは、今でも大企業は黒字でも簡単に工場を撤退させる事例として有名になった。かなり悲惨な事態だったと言える。

そうして重荷になっていたとされる工場を切り離しファブレスに近い業態にしたのは、富士通半導体を残すためだったと思われる。

しかし、そうした建前などなかったかのように2014年にはシステム LSI/SoCの開発部隊の分社化を決定。それが現在のソシオネクストである。PanasonicのLSI 部隊と合弁した会社で、分離した当時、富士通は設立当初40％の株式を保持していたが、現在は完全に売却してしまった。

現在、富士通の半導体部門はFeRAMや光回路用の超特殊なものを除いて完全売却で撤退している。

なお、その後、ルネサステクノロジ（※富士通は合弁に参加していない）が組込向け半導体でほぼ世界首位と同率2位まで上り詰め、国内半導体の必要性が新たに叫ばれTSMCが国内に半導体工場を建設。Rapidusという日米政府が関わる半導体企業ができる流れになっている。もし将来、RapidusがプロジェクトXになるときには、大手電機産業からリストラされた技術者達の奮起という文脈が語られそうな気がする。閑話休題。

2012年。京が世界一を取ってその後、富士通 半導体の敗北が確定した年

件の方がご退任をされたと言う2012年は、半導体のさらなる切り離し、売却などの決断と、次期スパコン（つまり富岳）がSPARCを捨ててARMになるという決断が行われた年であったと考えられる。（発表は後になる）

半導体を専門にされてずっとやってきた方には堪えられないもだったのではないかと拝察する。仮に、思い出したくもないし、宣伝にも使われたくないと判断されても仕方がないことでは無いかと思う。（もちろん 出演NGされたと言うのはワイの妄想なので注意)

その後、富士通はSPARCを使ったUNIX サーバーを作り続けてはいたが、大きくアーキテクチャを改善する開発は行われないまま（保守設計は続けられていたが）メインフレームとともに撤退が発表された。これはやむを得ないことだろう。

また、ARM化された富岳は、確かに性能面や利用面、汎用性では高い成果を出したが、富士通のビジネス的にはさっぱりだったと思われる。

アーキテクチャをARMに切り替えた理由は、ビジネス面でもあった。高性能タイプのARMを作ることによって、旺盛なクラウド DC 需要などに対して食い込んでARM サーバを大きく拡販していくことだったと思われる。

が。富岳に乗せたARM プロセッサを利用した波及製品はみられなかった。

なぜか。それはAWS、MS Azure、Googleなど膨大な需要を持つ企業は、需要が巨大すぎてARMが搭載されたコンピュータを買うのではなく、自社でARMのIPを購入し独自開発することを選んだためである。

彼ら相手には商売にならなかった。それ以外のクラウドベンダーは無きに等しい。ARMなどアーキテクチャが影響しないのはPaaS以上の象徴度を持つサービスだが、寡占状態にある大手以外まともに提供出来ていないため、市場が無いのだ。

ただし、この時富士通とARMの競業によってARMは成果をあげた。アウトオブオーダー実行など、ARMは高性能コンピュータで必要な技術を富士通から取り込んで現在に至る。

それ故、富士通の商売は上手くいかなかったが、世の中的には良かったとは言えるのではあるのだ。そのIPで大手クラウド各社は自社向け半導体を作って商売をしているのだから。

エピローグ　または今後について

今、富岳の次のHPCが予算要求の山場を迎えている。

https://newswitch.jp/p/41595

だから今のタイミングでプロジェクトXに乗ったのだと思うが、綺麗事では語れない話がたくさんありすぎる。

受注はまず間違い無く富士通だと言われている。と言うのは、開発の一部は既に行われているから。

https://monoist.itmedia.co.jp/mn/articles/2310/12/news074.html

そして、国内にもう国産でHPCを作ることの出来る会社はNECと富士通ぐらいになってしまったためである。

富士通は新しいHPCは1位を目指さないかもしれないという考えから、計算効率の方に大きく振った開発を進めおり、国内トップのHPCに採用されたという実績を背景に売り出そうというつもりではあると思われる。富岳の夢再び、だ。

しかし、富士通は今年1月、ハードウエア会社を分離した

https://cloud.watch.impress.co.jp/docs/special/1560540.html

この新会社、分離時には綺麗事を書いてあるが、

https://www.fsastech.com/about/

ご覧の通り、富士通のブランドを一切使っていないのだ。既存の商品からも富士通マークを取り払っている。さらに、会社概要に株主欄がなく、富士通の名前が出てこない。（他の関連会社はそういった記載がある）

半導体がどうなったかの流れを知っていると、暗い予感しかしない。

そして、HPCはレイヤーの低い、ハードウエアに近い部分、さらにメカニカルな設計や冷却など物理的な部分のノウハウが多く必要とされる。それを富士通が分社化して製造能力を失っていく中で、果たしてまともにHPCが作れるのだろうか？

さらに、確かに 2010年代半ばのころはワークロード不足に陥ってコンピュータは安売りに陥っていたが、現在 AIと言う巨大な需要が生み出され、価格も回復、ハードウエアが再び重要と考えられ始めている。ハードウエアと同時に提案できる能力が強みになりつつある。

しかし、既に富士通はそれらに対応するための強みを、はした金と決算の数字をよくするためだけに売り払った後である。案の定、粉飾紛いの異様に高い目標に対して、結果が出ないと言う発表を繰り返している。

富士通はアクセンチュアを真似ていると言われる。以下の記事にはこうある

https://xtech.nikkei.com/atcl/nxt/column/18/00848/00049/

目指す先はアクセンチュア、富士通が主力工場を総務に移管する理由
時田社長は2019年 9月に開いた初の記者会見で「開発製造拠点をどう整理するのか」という質問に「既に方向は定まっている。後は状況判断と時期の問題。富士通はサービスに集中する企業になる」と応じていた。
時田社長の方針は「アクセンチュアにないものは富士通もいらない」とみてよい。

そこまでやったのに、ここ3年ほど株価は伸び悩みが続いている。アクセンチュアの真似をしますと言ったときは撥ねたがが、その後は同業他社や業界全体の株価上昇率に及ばない状況が続く。
それはそうだ。アクセンチュアの真似をしていてはアクセンチュアには勝てない。まして工場売却を通じ、元々の強みを捨て弱みまでアクセンチュアの真似をしているのだ。富士通がこの先生きのこるにはどうすればいいのか？

これがプロジェクトXの真のエピローグではないかとワイは思いました。

Permalink | 記事への反応(13) | 12:29

■ビットコインは悪意を前提にシステム設計されたがまだ悪意に対する認識が甘かった

全世界で1ノードのみがブロック生成の報酬を得られるという仕組みは牧歌的すぎたし、

マイニングプールを運用するメリットが無くなるような仕組みが必要だった。

Permalink | 記事への反応(3) | 14:53

2024-01-07

■anond:20240107192256

きみは一回既存企業のフルマネージド化みたいな現実のサービス構造に触れた方がいいと思うよ。

世の中きみが思ってる程小規模でもなければ単純でもないし、たかだか200ノード程度の"小規模システム"でも現実に向き合ってればそんな発言は出てこないからさ。

Permalink | 記事への反応(2) | 19:41

■DavinciResolveって勿体ないよな

Fusion触っていて思うのは、これはノーコードエディタなのでプログラミングの感覚で触れる反面、そういう素養がない人にはとてつもなく使いづらいってことだ

画像やデータをノードでつないでエフェクトやマスクをかけるというのは、プログラミング的だと思う

けど一般的には画像や映像を暗くしたりするにはちょっとパラメータいじるとか、そういうことを前提にしているだろうから、ノード中心の仕様はとっつきにくいよな

でも18.5でマルチマージによってレイヤー表現がでてきたし、よりわかりやすくなってはきている

DRは海外勢に人気だけど、日本だとYMM4やAviUtilみたいなアニメーションに強いソフトが台頭している。DRでも再現は可能だけどデフォルトにはあまりないしプラグインも少ない。けど海外でも日本のような立ち絵やアニメを多用する映像作品をDRで作りたいという要望はあるらしく、そういう機能を今後どんどん追加していって欲しいな