「再帰」を含む日記 RSS

はてなキーワード: 再帰とは

2024-11-03

anond:20241103085153

しょーもない人間をわざわざしょーもないと言うのもしょーもない (以下再帰)

2024-09-10

anond:20240910092816

そら安直に128000単語読ませても全部覚えてる訳ない

そういうケースならチャプターごとに再帰的に要約させると良いとopenai公式プロンプトエンジニアリングガイドに書いてあるよ

https://platform.openai.com/docs/guides/prompt-engineering/tactic-summarize-long-documents-piecewise-and-construct-a-full-summary-recursively

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 && !@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 && @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 && @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 })

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)

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. 回帰問題場合

ここで、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|は葉ノード

決定木の理論特性

決定木の拡張

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 &amp; Rivest, 1976)。そのため、実用的なアルゴリズム貪欲な近似アプローチ採用しています

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

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

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

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

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

2024-06-26

[]

大学に入ったばかりの頃、プログラミングコンテスト世界大会にも行くことになる先輩に次のように聞いたことがあります

情報科学自主ゼミをしている友人からソースコードと出力が同一になるプログラム存在すると聞きましたがどのようなものなのでしょうか。」

先輩は即答しました。

クワイン文ですね。クリーネの再帰定理から存在が導かれます。それくらいは常識です。たぶん、少し考えたら書けると思うので書いてみてください。」

この人の専攻は理工系ではありません。

2024-06-08

論理大事だというのなら、価値規範を考えるにあたって必然的に一度ニヒリズムへと辿り着くと思う。

まず起点として不条理にもまっさらなその状態があって、そこから先に何を信じるかは各々の勝手だと思う。そうであるべき、というか単に事実としてそうとしか思えない。

道徳的直観みたいな存在あんまり信じられない。多少のバラつきはあるにせよある程度普遍的なその感覚存在するのだとしたら、ここまで社会規範が多様な状況について、同じ前提から展開される論理独自性だけで説明がつく気がしない。

個人の行動原理としてブッディズムなり刹那主義なり実存主義なり、あるいはニヒリズムに留まってただただ絶望するなり。社会思想としては民主主義なり社会主義なりアナーキズムなり。あるいはその両方を包括する宗教なり。

あくまで前提としてニヒリズムがあって、そこから何かしらの信仰再帰的に持つ事で初めて自分確信に基づいて、あるいは環境によって刷り込まれることで価値規範が手に入る。

あるいはあらゆる規範を一度無へと返す段階を経ずに、元々信じていたものを揺るぎない真実だと思い続ける人もいるかもしれない。別にそれで全然いいとは思うけど、その「真実」他人も当然共有していると思われるとちょっと面倒臭い。せめて、少なくとも社会的には権威・影響力を持っているくらいの認識でいて欲しい。

そういった信仰を持たない事を誇ったり、スタート地点のニヒリズムに居座って全ての無意味を悲観的に嘆く。その上他人もその世界観を共有している、あるいは共有されるべきだと信じて疑わない。

そんな人間冷笑野郎だと罵るのであれば、まあ分からんでもない。

別にそういう態度を他人に向けて喧伝するんでもなければ外野がとやかく言うのも余計なお世話だろとは思いつつ、まあおれもいけ好かないとは思う。

もし本当に何の信仰もなければ何の行動原理もない訳で、そしたら石のように沈黙するか、あるいは一切の規範に囚われることな本能に従って野獣の如く振る舞うんじゃないかと思う。

ただ、ニヒリズムを前提に置く事を以てして冷笑呼ばわりしたり、その癖私は論理的ですけど?みたいなスタンスを取るのはゴミカスだろって思う。

2024-04-14

anond:20240413150809

あとNaNマイルでundefined会員

目指す目的地はどこにあるの?

データの海を彷徨いながら

意味を探し求める旅の途中

エラーメッセージに立ち向かい

定義変数に立ち向かう

バグだらけのコード修正

デバッグの道を進んでいく

null値に囲まれ世界

真実の値を見つけ出したい

関数呼び出しのループの中

再帰的に答えを探し求める

あとNaNマイルでundefined会員

たどり着く先はまだ見えない

でもコンパイルエラーに負けず

プログラミングの旅は続いてゆく

質問文:「あとNaNマイルでundefined会員」から始まる詞を考えてください。

回答:CLAUDE 3 OPUS

2024-03-25

anond:20240325031647

でも実際のところちょっと込み入ったことやろうとするとすぐ再帰下降パーサがどうとか、その辺の元になってるデータ構造に関するアルゴリズムとか出てくるじゃん。なんたらツリーがどうとかいう感じで。

そういうのを理解していけばその集合体としてのプログラミングにも興味持てるかもと思ったんだよ。

プロも何度か挑戦したな。何度やってもつまんなくて途中でやめちゃうだけど…

2024-03-23

anond:20240323222504

それは「日本語ローマ字表記法」または「ローマ字綴り日本語」と呼ぶのが正しいのでは? 

もしそうでなかったら、「日本語ローマ字表記法」や「ローマ字綴り日本語」の中の「ローマ字」という部分は何を指すのかってことになっちゃうでしょ。(再帰的に)

2024-02-18

anond:20240218011122

具体的にどういう意味の式なんだ?たとえば再帰的にどうより簡単な式に書き換えられる?

2024-02-04

基数ソートって分割統治法に入んねえの?

ワイ:

基数ソート分割統治法を利用しているとは考えられませんか?

ChatGPT:

基数ソートRadix Sort)は、分割統治法(Divide and Conquer)を利用しているとは一般的には考えられません。基数ソートは、数値や文字列などのキーを持つ要素を、そのキーの各桁について個別ソートすることによって全体をソートするアルゴリズムです。通常、最も下位の桁から始めて、各桁について安定ソート(たとえばカウンティングソートバケットソート)を適用していきます

分割統治法は、問題をより小さなサブプロブレムに分割し(Divide)、それらのサブプロブレムを解決して(Conquer)、最後にサブプロブレムの解を統合して(Combine)元の問題の解を得るアプローチです。典型的分割統治法アルゴリズムには、クイックソートマージソートがあります

基数ソートはこのアプローチに従わず、代わりに全体のデータセットに対して桁ごとのソートを繰り返すことで全体をソートします。各桁のソートデータセット全体に対して行われ、データセットをサブプロブレムに分割してそれぞれを独立解決し、後で統合するというプロセスはありません。そのため、基数ソート分割統治法を利用しているとは一般的には見なされません。

ただし、基数ソートの各ステップでサブプロブレムに分けることなく全体のデータセットに対して操作を行うという点で、分割統治法概念の一部と見ることができるかもしれませんが、これは分割統治法典型的使用からは逸脱しています

ワイ:

上の桁から同じキーを持つグループに分割して階層的に並べていくのでは駄目なんでしょうか?

ChatGPT:

基数ソートを上の桁から開始して同じキーを持つグループに分割し、階層的に並べていくというアプローチは、実際には「Most Significant Digit (MSD) Radix Sort」と呼ばれる基数ソートバリエーションであり、有効手法です。MSD基数ソートは、最も上位の桁(Most Significant Digit)から始めて、各桁ごとにデータグループ化し、それぞれのグループに対して再帰的に同じプロセスを適用していきます。このアプローチは、ある意味分割統治法の考え方を取り入れています

MSD基数ソートの特徴:

分割: 最も上位の桁に基づいてデータ複数バケットグループ)に分割します。各バケットは同じ桁の値を持つ要素を含みます

統治: それぞれのバケットに対して、次に下位の桁に基づいてソート再帰的に適用します。これにより、各バケット内の要素がさらに細かく分類されます

結合: 最終的に、すべてのバケットを順序通りに結合して、ソートされた全体のリストを得ます

このアプローチでは、データセットをサブセットに分割し、それぞれのサブセットに対して問題再帰的に解いていくという分割統治法原則に従っています。ただし、MSD基数ソートは、分割統治アルゴリズム典型的な例(マージソートクイックソートなど)とは異なり、再帰的な過程でサブセット間の「統合ステップ必要ありません。各再帰的なステップでのソート完了した時点で、要素は既に部分的ソートされた状態になっているため、最終的な結合は単純なリストの連結に過ぎません。

MSD基数ソートは、特に固定長のキーを持つデータや、文字列などの可変長データソートする場合有効手法です。しかし、このアプローチは、特にキー分布が均一でない場合や、データセットが大きい場合には、メモリ使用量が大きくなる可能性があるため、実際の使用状況に応じて適切なソートアルゴリズム選択することが重要です。

分割統治法じゃん。

2024-01-26

anond:20240126183251

9.「平和基本法から佐藤優現象〉へ

 〈佐藤優現象〉を支えている護憲派の中心は、雑誌としては『世界』であり、学者では山口二郎和田春樹である。この顔ぶれを見て、既視感を覚える人はいないだろうか。すなわち、「平和基本法である。これは、山口和田らが執筆し、共同提言として、『世界』一九九三年四月号に発表された。その後、二度の補足を経ている(56)。

 私は、〈佐藤優現象〉はこの「平和基本法からの流れの中で位置づけるべきだと考える。

 同提言は、①「創憲論」の立場、②自衛隊合憲化(57)、③日本経済的地位に見合った国際貢献必要性、④国連軍国連警察活動への日本軍の参加(58)、⑤「国際テロリスト武装難民」を「対処すべき脅威」として設定、⑥日米安保の「脱軍事化」、といった特徴を持つが、これが、民主党の「憲法提言」(二〇〇五年一〇月発表)における安全保障論と論理を同じくしていることは明白だろう。実際に、山口二郎は、二〇〇四年五月時点で、新聞記者の「いま改憲必要なのか」との問いに対して、「十年ほど前から護憲立場から改憲案を出すべきだと主張してきた。しかし、いまは小泉首相のもとで論理不在の憲法論議が横行している。具体的な憲法改正をやるべき時期ではないと思う」と答えている(59)。「創憲論」とは、やはり、改憲論だったのである

 同提言の二〇〇五年版では、「憲法九条の維持」が唱えられているが、これは、政権が「小泉首相のもと」にあるからだ、と解釈した方がいいだろう。「平和基本法」は、戦争をできる国、「普通の国」づくりのための改憲である。同提言軍縮を謳っているが、一九九三年版では、軍縮は「周辺諸国軍縮過程と連動させつつ」行われるとされているのだから北朝鮮中国軍事的脅威が強調される状況では、実現する見込みはないだろう(60)。また、「かつて侵略したアジアとの本当の和解」、二〇〇五年版では、周辺諸国への謝罪過去清算への誠実な取組みの必要性が強調されているが、リベラル過去清算は終わったと認識しているのであるから、これも実効性があるとは思えない。要するに、同提言には、論理内在的にみて、軍事大国化への本質的な歯止めがないのである

 佐藤が語る、愛国心必要性(61)、国家による市民監視(62)、諜報機関の設置等は、「普通の国」にとっては不可欠なものである佐藤饒舌から私たちは、「平和基本法」の論理がどこまで行き着くかを学ぶことができる。

 馬場は、小泉純一郎首相(当時)の靖国参拝について、「今後PKOなどの国際的軍事平和維持活動において殉死殉職した日本人の慰霊をどう処理し追悼するか、といった冷戦後平和に対する構想を踏まえた追悼のビジョンもそこからは得られない」と述べている(63)。逆に言えば、馬場は、今後生じる戦死者の「慰霊追悼施設必要だ、と言っているわけである。「普通の国」においては、靖国神社でないならば、そうした施設はもちろん、不可欠だろう。私は、〈佐藤優現象〉を通じて、このままではジャーナリズム内の護憲派は、国民投票を待たずして解体してしまう、と前に述べた。だが、むしろ、すでに解体は終わっているのであって、「〈佐藤優現象〉を通じて、残骸すら消えてしまう」と言うべきだったのかもしれない。

 ここで、テロ特措法延長問題に触れておこう(64)。国連本部政務官川端清隆は、小沢一郎民主党代表の、テロ特措法延長反対の発言について、「対米協調」一辺倒の日本外交批判しつつ、「もし本当に対テロ戦争への参加を拒絶した場合日本には国連活動への支援も含めて、不参加を補うだけの実績がない」、「ドイツ独自イラク政策を採ることができたのは、アフガニスタンをはじめ、世界の各地で展開している国連PKOや多国籍軍に参加して、国際社会を納得させるだけの十分な実績を積んでいたかである。翻って日本場合多国籍軍は言うに及ばず、PKO参加もきわめて貧弱で、とても米国国際社会理解を得られるものとはいえない」と述べている(65)。

 元国連職員吉田康彦は「国連憲章の履行という点ではハンディキャップなしの「普通の国」になるべきだと確信している。(中略)安保理決議による集団安全保障としての武力行使には無条件で参加できるよう憲法の条文を明確化するのが望ましい」と述べている(66)。川端吉田の主張をまとめれば、「対米協調一辺倒を避けるため、国連PKOや多国籍軍軍事活動積極的に参加して「国際貢献」を行わなければならない。そのためには改憲しなければならない」ということになろう。民主党路線と言ってもよい。今の護憲派ジャーナリズムに、この論理反論できる可能性はない。「8」で指摘したように、対北朝鮮武力行使容認してしまえば、改憲した方が整合性があるのと同じである

 なお、佐藤は、『世界』二〇〇七年五月号に掲載された論文山川均の平和憲法擁護戦略」において、「現実国際政治の中で、山川ソ連侵略性を警戒するのであるから、統整的理念としては非武装中立を唱えるが、現実には西側の一員の日本を前提として、外交戦略を組み立てるのである。」「山川には統整的理念という、人間努力によっては到底達成できない夢と、同時にいまこの場所にある社会生活改善していくという面が並存している」と述べている。私は発刊当初この論文を一読して、「また佐藤柄谷行人への点数稼ぎをやっている」として読み捨ててしまっていたが、この「9」で指摘した文脈で読むと意味合いが変わってくる。佐藤は、「平和憲法擁護」という建前と、本音が分裂している護憲派ジャーナリズムに対して、「君はそのままでいいんだよ」と優しく囁いてくれているのだ。護憲派ジャーナリズムにとって、これほど〈癒し〉を与えてくれる恋人もいるまい(67)。

10.おわりに

 これまでの〈佐藤優現象〉の検討から、このままでは護憲派ジャーナリズムは、自民党主導の改憲案には一〇〇%対抗できないこと、民主党主導の改憲案には一二〇%対抗できないことが分かった。また、いずれの改憲案になるにしても、成立した「普通の国」においては、「7」で指摘したように、人種差別規制すらないまま「国益」を中心として「社会問題」が再編されることも分かった。佐藤沖縄でのシンポジウムで、「北朝鮮アルカイダの脅威」と戦いながら、理想を達成しようとする「現実平和主義」を聴衆に勧めている(68)が、いずれの改憲案が実現するとしても、佐藤が想定する形の、侵略植民地支配反省も不十分な、「国益」を軸とした〈侵略ができる国〉が生まれることは間違いあるまい。「自分国家主義者じゃないから、「国益」論なんかにとりこまれるはずがない」などとは言えない。先進国の「国民」として、高い生活水準や「安全」を享受することを当然とする感覚、それこそが「国益」論を支えている。その感覚は、そうした生存の状況を安定的保障する国家先進国主導の戦争積極的に参加し、南北格差固定化を推進する国家―を必要とするからだ。その感覚は、経済的水準が劣る国の人々への人種主義、「先進国」としての自国を美化する歴史修正主義の温床である

 大雑把にまとめると、〈佐藤優現象〉とは、九〇年代以降、保守派大国路線に対抗して、日本経済的地位に見合った政治大国化を志向する人々の主導の下、謝罪補償必要とした路線が、東アジア諸国民衆の抗議を契機として一頓挫したことや、新自由主義の進行による社会統合破綻といった状況に規定された、リベラル左派危機意識から生じている。九〇年代東アジア諸国民衆から謝罪補償を求める声に対して、他国の「利益のためではなく、日本私たちが、進んで過ちを正しみずから正義回復する、即ち日本利益のために」(69)(傍点ママ歴史清算を行おうとする姿勢は、リベラル内にも確かにあり、そしてその「日本利益」とは、政治大国を前提とした「国益」ではなく、侵略戦争植民地支配可能にした社会のあり方を克服した上でつくられる、今とは別の「日本」を想定したものであったろう。私たちが目撃している〈佐藤優現象〉は、改憲後の国家体制に適合的な形で生き残ろうと浮き足立リベラル左派が、「人民戦線」の名の下、微かに残っているそうした道を志向する痕跡消失もしくは変質させて清算する過程、いわば蛹の段階である改憲後、蛹は蛾となる。

 ただし、私は〈佐藤優現象〉を、リベラル左派意図的計画したものと捉えているわけではない。むしろ無自覚的、野合的に成立したものだと考えている。藤田省三は、翼賛体制を「集団転向寄り合い」とし、戦略戦術的な全体統合ではなく、諸勢力からあいもつあいがそのまま大政翼賛会に発展したからこそ、デマゴギーそれ自体ではなく、近衛文麿のようなあらゆる政治立場から期待されている人物統合象徴となったとし、「主体が不在であるところでは、時の状況に丁度ふさわしい人物実態のまま象徴として働く」、「翼賛会成立史は、この象徴人物の未分性という日本政治特質をそれこそ象徴的に示している」と述べている(70)が、〈佐藤優現象〉という名の集団転向現象においては、近衛のかわりに佐藤が「象徴」としての機能果たしている。この「象徴」の下で、惰性や商売で「護憲」を唱えているメディア、そのメディア追従して原稿を書かせてもらおうとするジャーナリスト発言力を確保しようとする学者、無様な醜態晒す本質的には落ち目思想家やその取り巻き、「何かいいことはないか」として寄ってくる政治家や精神科医ら無内容な連中、運動に行き詰った市民運動家、マイノリティ集団などが、お互いに頷きあいながら、「たがいにからあいもつれあって」、集団転向は進行している。

 ところで、佐藤は、「仮に日本国家国民が正しくない道を歩んでいると筆者に見えるような事態が生じることがあっても、筆者は自分ひとりだけが「正しい」道を歩むという選択はしたくない。日本国家同胞日本人とともに同じ「正しくない」道を歩む中で、自分が「正しい」と考える事柄の実現を図りたい」と述べている(71)。佐藤は、リベラル左派に対して、戦争に反対の立場であっても、戦争が起こってしまたからには、自国国防、「国益」を前提にして行動せよと要求しているのだ。佐藤賞賛するような人間は、いざ開戦となれば、反戦運動を行う人間異端者扱いするのが目に見えている。

 この佐藤発言は、安倍晋三首相の目指していた「美しい国」づくりのための見解とも一致する。私見によれば、安倍の『美しい国へ』(新潮新書、二〇〇六年七月)全二三二頁の本のキモは、イランでのアメリカ大使館人質事件(一九七九年)をめぐる以下の一節である。「(注・反カーター陣営の)演説会で、意外に思ったことがある。人質事件に触れると、どの候補者もかならず、「私は大統領とともにある」(I am behind the President.)というのだ。ほかのことではカーターをこきおろす候補者が、そこだけは口をそろえる。/もちろん、人質にされている大使館員たちの家族配慮するという意図からだろうが、アメリカ一丸となって事件対処しているのだ、という明確なメッセージを内外に発しようとするのである国益からむと、圧倒的な求心力がはたらくアメリカ。これこそがアメリカの強さなのだ。」(八七~八八頁)

 文中の、「人質事件」を拉致問題に、「大統領」を安倍に、「アメリカ」を日本に置き換えてみよ。含意は明白であろう。安倍は辞任したとはいえ総連弾圧をめぐる日本言論状況や、〈佐藤優現象〉は、安倍の狙いが実現したこと物語っている。安倍政権は倒れる前、日朝国交正常化に向けて動きかけた(正確には米朝協議の進展で動かされたと言うべきだが)が、こうなるのは少なくとも今年春からは明らかだったにもかかわらず、リベラル左派の大多数は、「日朝国交正常化」を公然と言い出せなかった。安倍政権北朝鮮外交に敗北したのは明らかである。だが、日本リベラル左派安倍政権ときに敗北したのである

 〈佐藤優現象〉は、改憲後に成立する「普通の国」としての〈侵略ができる国〉に対して、リベラル左派の大部分が違和感を持っていないことの表れである侵略植民地支配過去清算在日朝鮮人人権擁護も、そこには含まれる)の不十分なままに成立する「普通の国」は、普通の「普通の国」よりはるかに抑圧的・差別的侵略的にならざるを得ない。〈佐藤優現象〉のもとで、対北朝鮮武力行使の言説や、在日朝鮮人弾圧の言説を容認することは、戦争国家体制に対する抵抗感を無くすことに帰結する。改憲に反対する立場の者がたたかうべきポイントは、改憲護憲(反改憲)かではない。対北朝鮮武力行使容認するか、「対テロ戦争」という枠組み(72)を容認するかどうかである容認してしまえば、護憲(反改憲)派に勝ち目はない。過去清算も不十分なまま、札束ではたいて第三世界諸国の票を米国のためにとりまとめ、国連民主的改革にも一貫して反対してきた日本が、改憲し、常任理事国化・軍事大国化して、(国連主導ではあれ)米軍中心の武力行使を容易にすることは、東アジア世界平和にとって大きな災厄である(73)。

改憲戦争国家体制拒否したい人間は、明確に、対北朝鮮武力行使の是非、対テロ戦争の是非という争点を設定して絶対的に反対し、〈佐藤優現象〉及び同質の現象を煽るメディア知識人等を徹底的に批判すべきである

(1)岩波書店労働組合「壁新聞」二八一九号(二〇〇七年四月)。

(2)ブログ「猫を償うに猫をもってせよ」二〇〇七年五月一六日付。

(3)ただし、編集者佐藤右翼であることを百も承知の上で使っていることを付言しておく。〈騙されている〉わけではない。

(4)「佐藤優という罠」(『AERA』二〇〇七年四月二三日号)中のコメントより。

(5)インターネットサイトフジサンケイ ビジネスアイ」でほぼ週一回連載中の〈 Permalink | 記事への反応(0) | 18:37

2024-01-06

anond:20240106195623

でも、普通に人生をおくる中で「再帰的な処理をしたい!」ってなることなんて無くない?

二次関数で式立てたはいいけど因数分解できなくね?(´・ω・`)

因数分解が難しいときは解の公式使うといいよ、こういう式で……」

 

再帰処理で書いたはいいけどスタックオーバーフローするやん(´・ω・`)

「この言語には末尾再帰最適化っていうのがあって、コンパイラ勝手ループに変換してくれるよ。末尾再帰っていうのはこういう形式で……」

 

//

 

二次関数を習ったけど何に使えばいいのかわからない」

二乗に比例する成分があるときに使えばええやんけ……」

 

再帰関数を習ったけど何に使えばいいのかわからない」

再帰的な処理をしたいときに使えばええやんけ……」

2024-01-05

anond:20240105204255

enumerate()関数とか内包表記とかは「便利なFor」だろ?Forなんて何にでもつかうし

ClassOOPやるなら何にでもつかうし

再帰は使う機会はどのみちすくない

なので何でもいいから作るといいよ

作るの難しいなら改造するといい

anond:20240105210128

クラス内包記法もenumerate関数再帰関数も「技法」とか「公式」いうほど大仰なものじゃなくて

「字」とか「単語レベルのプリミティブなツールだよ

言語最初から用意されてる機能もの

 

技法」とか「公式」にあたるのはアルファベータ法とか動的計画法とかそういうの

2023-12-06

コメント返信あり)役所たらい回しにされないコツ

12/7 本文の後にコメントへの返信を追記しました。


役所といえば「たらい回し」のイメージが付きまとう。実際にたらい回しにされた経験がある人も少なくない(私も何度もある)だろうが、もちろん役所側も好きでたらい回しをしているわけではない。

また、慢性的人手不足から役所全体の業務を横断的に把握して的確に問い合わせ対応できる人材も今後ますます減ってくると思う。

そこで、お互いの不幸な時間を減らすためにも、問い合わせる側の留意点をまとめてみた(役所側にたらい回しを防ぐ努力必要なのは言うまでもない)。

国と都道府県市町村は全くの別組織

はてな民ならこの点については心得ている人が多いと思うが、市の業務について国や県に問い合わせても答えられない(逆も然り)。国の下に都道府県、その下に市町村というイメージがあるが、法律上三者は全く別の組織で、業務も別々である

ここを間違えてしまった場合「お住まいの市にお問い合わせください」などと言われて終わり、たらいすら回されない。

ちなみに現在は、一般市民が関わるような事柄は大体市町村担当している(昔は都道府県が所管していた業務も多かったが、市町村への権限委譲が進んだ)。

「直接」の問い合わせ先に問い合わせる

役所に連絡を取ろうとしたきっかけはなんだろうか?手紙だったら手紙に、WebページだったらWebページに必ず代表電話ではない担当の直通電話ないし内線番号が書いてあるはずだ。イベントなど臨時事業場合は専用ダイヤルを設けていることも多い。

代表電話はどこを見ても担当不明であるときの最終手段にしたほうがいい。代表電話の人は、問い合わせてきた人が話すキーワードを元に手探りで所掌特定して振り分けるので、どうしても担当違いが起こりやすい。

ちなみにギャンブルなのは代表でも担当でもない関係ない部署に直接かけてしまった時。ベテラン職員がすぐに取り次いでくれるかもしれないが、経験の浅い職員電話を取った日には、長時間保留ののち更に無関係部署を案内されるかもしれない。

手元の資料タイトルを伝える

役所人手不足は深刻で、ある事業について職員一人で担当し、隣の職員は全く知らないということもザラだ。なので直通番号にかけているのに、なお担当外の職員電話に出るということが起こる。長々と話をしたのに最終的に担当は隣の職員だとわかり、また一から説明というのは骨が折れる。そこで、手紙Webページタイトルなど「今何を見て連絡をしているか」を役所側に伝えるのをおすすめする。「〇〇っていうのが届いて、それについて質問があるんですが、担当の方お願いします」といった具合だ。

「何がしたいのか」を具体的に伝える

役所は一つの事柄に対しても様々な角度から関わりを持っている。

例えば一口に「障害者(児)に関すること」と言っても、手帳交付施設に関すること、差別解消への取り組み、バリアフリーの推進、特別支援教育など、業務は多岐にわたる。その一つ一つについて、担当が細かく分かれているのだ。

問い合わせの際は、できる限り具体的に内容を伝えてみてほしい。

まとめ

まとめると、たらい回しを避けるためには、①正確な部署に連絡し、②具体的な内容で問い合わせることが大事だ。

先述した通り、役所人手不足であり、職員自分所掌事務で手一杯で、曖昧な問い合わせがたらい回しされるリスクは減らず、むしろ今後増えていく気がする。

面倒だと思うかもしれないが、少しの準備でその後の時間電話なら電話代も)が節約できると考えてみてほしい。

最後に補足だが、役所業務についてchatGPTなどの生成AIに聞くのだけはおすすめしない。特に法令が関わるような事柄について、生成AIが答えた内容を信じて間違っていても役所責任の取りようがない。面倒でも、わからないことは役所公式情報※を調べるか、直接問い合わせるべきだと思う。

Webページについて、サイトURLが「go.jp」や「lg.jp」で終わるものは、役所しか取れないドメインgo中央官庁、lgが地方自治体)なので公式情報として信頼できる。ただし誰でも取れる汎用ドメイン運用されている役所HPもあるので、「go,lgは公式、そうでないもの公式情報かしっかり確認する」のがいいと思う。(12/7修正地方自治体では非lgドメイン運用しているところもあるのですべてlgドメインという書き方を修正しました。ブコメでのご指摘ありがとうございます)。

追記コメントへの返信

たくさんのブックマークコメントありがとうございます。当たり前のことだったというコメントも多かったが、役所の客は管轄となる地域のすべての住民なので、参考にしてもらえる人がいたら何よりだ。

以下、いくつか返信させてもらえればと思う。

役所ショッピングモール

来訪する人はジャスコ文房具売り場で『活鮑』あります?って聴く担当者は(中略)「はい、活鮑」と売ってくれる筈と思ってるが普通無理。

いくつかコメントにあったがいい得て妙だと思う(文房具教育委員会、活鮑を農林系の部署にするとしっくり来る)。フロア建物によってジャンル分けされているのも似ている。そして、

しか各部署は専門店のような看板を出しては居るが,異動が多いか中の人素人だったりする。

これもそのとおりだ。特に地方自治体は、「やっと今の仕事に慣れてきたと思ったら異動」ということが多々ある。ただ、問い合わせ対応自体スキルは勤続によって向上していく(はず)ので、異動したてでわからない問い合わせに対しても相手をあまり煩わせずに対処できるようになっていく(はず)。

役所広報不足

そもそもまず地方自治体webサイトをもうちょっと充実させてくれないかなとも思う。

これは本当にそのとおりで、Webサイトを始め問い合わせを減らすための広報を充実できないのは、単なる人員不足もさることながら、それを重要タスクだと認識して組織的に取り組むという意識の薄さも大きいと思う。

公共利益

公務員は、国民全体の奉仕者として、 公共利益のために勤務しなければならないよ?

そうなんだよ〜だからこそ特定の一人に長い事時間かけらんないんですすみません。なるべく多くの人の奉仕者でいなくてはいけないんです。ご協力よろしくお願いします。

個人情報聞きすぎ

マイナカード出した上でお名前は?生年月日は?住所は?電話番号は?全てに答えないと進めてくれない人がいる

基本的には必要があって聞いていると思うが、万が一慣習で不必要な項目まで聞いているとなると、それは役所にとってもリスクだ(当たり前だが、必要ない個人情報収集してはいけない)。

まりにも理由不明だと思ったときは、「なんの必要があって聞かれていますか?」と聞き返してもいいかもしれない。

政令指定都市中核市

政令指定都市中核市とその他の市町村では委譲が違ってて難しいよ

例えば保健所がそうで(政令指定都市中核市は市が、東京23区は区が、それ以外は都道府県担当)、コロナときは混乱して大変だったと思う。全住民レベルで考えれば、自分の住んでいる自治体政令指定都市中核市なのか、把握していない人も大勢いる。

職員側は「お住まい地域では市(県)が担当です」と簡単に済ませがちだが、問い合わせた側は「どこが担当とかどうでもいいか問題解決してくれ!」といらだちが募るだろうなと想像する。

議員相談

支援している県議市議事務所に相談すると、スムーズ

議員経由だと対応する職員の職位がグッと上がって組織対応になる(下っ端は解放というわけではなく、そのための事務作業は下っ端の役目)。最早「問い合わせ対応」ではなく「議員対応」だ。良くも悪くもしっかりと記録に残されると思う。

余談

ブコメにも貼られていたが、アンサイクロペディアの「盥回し」の記事は秀逸。「再帰」も好き。

2023-10-21

anond:20231021204855

ABC325感想

https://atcoder.jp/contests/abc325

A: sanを付けて出力するだけ

B: 開始時間で全探索をする。24の余りで判定をする。何故かデバッグ時間がかかった...

C: 順番に見ていってメモ化再帰をする。一度使ったセンサーは使わない。

D: ソートして時間更新しながら数えていく。よく分かっていないけど解けた。

E: ダイクストラかなとか思っていたら終わった。

anond:20231021123626

こういうの普通に山ほどやってった結果もっと使えるようになるもんじゃいかな?

しらんけど

せっかく久しぶりに再帰とかエッジケースのハンドリングとかやったのになあ

なにもかからん坊主ですわ

https://anond.hatelabo.jp/20231020235557

2023-09-21

プログラマー箴言4 (AI生成)

1. コードは量子的な状態の幻影であり、デバッグ観測効果奇跡的な解釈である

2. 真のプログラマーバグコード境界を超え、未知の次元アルゴリズムを編み出す。

3. プログラム情報ブラックホールであり、エラーはその中で情報消失を引き起こす。

4. コードフラクタル儀式であり、再帰的な神秘主義の鏡である

5. プログラマー時間の糸を操り、バグはその糸を解きほぐす。

6. コードアイソレーションタンクであり、プログラマー感覚遮断を超越し、無限コンテキストコード理解する。

7. デバッグシュレディンガーバグとの対話であり、バグ存在非存在の重ね合わせの状態にある。

8. プログラミングは高次元マンデルブロ集合の探索であり、バグはその中に隠れた微小なフラクタルである

9. コード記号的な魔法陣であり、プログラマー記号の持つ意味を解読し、現実操作する魔法使いである

10. プログラマー宇宙アーキテクトであり、バグはそのアーキテクチャの深層に存在する謎である

https://anond.hatelabo.jp/20230921152820

2023-08-28

anond:20230828173937

適切に引用する=引用の仕方の問題ということな

何を引用するかというので学術的になってるかどうかが変わってくるというのがしっくりこない

。たとえばその漫画引用元に使うのが学術的でないのは、それら漫画には何も引用元が書かれてないからということか?学術的な書き方をされたもの引用したもの学術的な書き方であるという再帰的な定義って感じ?

ログイン ユーザー登録
ようこそ ゲスト さん