プロジェクト
ゼロと幅に収まる最大値を試し、真偽値、不正な幅、範囲外の値を拒否します。
● ● ●GraySorrel●
ワークフロー · 固定ビット幅のグレイコード変換 ×
def checked_word(value, width):
if type(width) is not int or not 1 <= width <= 16:
raise ValueError("word.width")
if type(value) is not int or not 0 <= value < (1 << width):
raise ValueError("word.value")
return value
def to_gray(value, width):
value = checked_word(value, width)
return value ^ (value >> 1)
def from_gray(value, width):
value = checked_word(value, width)
result = 0
while value:
result ^= value
value >>= 1
return result✳幅を1から16ビットで明示し、整数をグレイコードへ変換して元に戻します。
✓ 変更内容適用前に確認 ↗
ワークスペースのイメージ
適用前に確認
実際の動作を期待する結果と比較します。検証に失敗した場合は、次の変更を加える前に原因を調べてください。
モデル
OpenAI互換またはAnthropicのエンドポイントを、ベースURLと必要なAPIキーで設定し、接続をテストします。ローカルのモデルサーバーは起動が必要です。リモートツールは別途データを送信する場合があります。
ワークフロー
def checked_word(value, width):
if type(width) is not int or not 1 <= width <= 16:
raise ValueError("word.width")
if type(value) is not int or not 0 <= value < (1 << width):
raise ValueError("word.value")
return value
def to_gray(value, width):
value = checked_word(value, width)
return value ^ (value >> 1)
def from_gray(value, width):
value = checked_word(value, width)
result = 0
while value:
result ^= value
value >>= 1
return result変更の全過程でビット幅の前提を明確にする
GraySorrelは、開発中にデータ表現の前提を明確にするためのWindows向けAIコーディングワークスペースです。変換コードとその利用側をプロジェクトの対話に含め、インターフェースが受け付ける値と幅を示します。この文脈があれば、境界条件の異なる汎用ルーチンを提案するのではなく、具体的な変更についてモデルと検討できます。
固定幅のグレイコード変換を例に考えてみましょう。共通の入力チェックも含め、順変換と逆変換を一緒に確認するよう依頼します。既知の値をいくつかと幅の境界に当たるケースを提示し、意図した契約に必要な修正だけを求めます。この例によって、対話にテスト可能な目標ができます。
提案が指定幅を超える値をどう扱うか確認してください。通常の変換結果が同じでも、黙って切り捨てる場合と明示的に拒否する場合ではソフトウェアの動作が異なります。プロジェクトのテストを実行し、対応範囲内で往復変換を比較し、呼び出し側のエラー処理を調べます。可逆性の例だけでなく、期待する正確な符号化結果も残してください。
対応するOpenAI互換またはAnthropicのエンドポイント経由でモデルを接続し、必要に応じて認証情報を設定します。無検閲AIモデルの選択は、接続先がそのようなモデルを提供している場合に可能であり、実際の制限は引き続き適用されます。ツール対応とコンテキスト容量はモデルとサーバーに依存し、契約と最終的なパッチの責任は利用者が負います。
ビット表現の変更をレビューする
符号化の検証は往復変換だけで十分ですか？
いいえ。2つの関数が互いに逆変換できても、対応関係そのものが誤っている可能性があります。往復変換のチェックに加え、独立に確認された符号化例を含め、変更案を採用する前に利用側のコードが結果をどう解釈するか調べてください。
指定したワード幅より大きい値はマスクすべきですか？
契約上、それらを拒否するのか、意図的に切り捨てるのかを指定してください。既存の検証処理と呼び出し側の期待をモデルに追跡させます。従来は呼び出し側がエラーを受け取っていたなら、変換が簡単になっても、マスクの導入は動作の変更です。
利用側のコードはどの程度含めればよいですか？
変換した値を保存、比較、送信するコードと関連テストから始めます。幅と表現に関する前提が分かります。変更案を理解するために別の依存箇所が必要だと調査で判明した場合にだけ、コンテキストを広げてください。
選んだモデルによって、裏付けのない対応幅の主張が信頼できるようになりますか？
いいえ。対応範囲はコードとテストで確認してください。ツールの実行についても調べます。別途稼働するローカルモデルサーバーを利用しても、接続されたすべてのツールがローカルになるわけではなく、テストが実際にどこで実行されるかも確定しません。
GraySorrel · 更新日 2026-10-25
