Orz日記 by Akio Morita

_ [IPv6]WindowsのIPv6アドレス

Windowsではインターフェースアドレス部は、MACアドレスベースのEUI64ではなく使い捨ての匿名アドレスが採用されるので、RAによる自動設定+AAAAレコードでの運用がうまくいかない

匿名アドレスがデフォルトなのはプライバシーのためだが、個人でプロバイダー経由の接続では、プロバイダーが配布する48bit prefixがほぼ固定なので、48bit prefixで契約者が特定されてしまう現実があり、LAN上の固定端末にはあまり意味が無い(複数端末がある場合の使用端末を特定させない効果や移動端末でネットワークを越えた特定を避ける効果はある)

で、匿名アドレスをoffにする方法を調べてみた

netsh interface ipv6 set privacy state=disabled

で無効にできる模様

PowerShellからだと、

Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

らしい

ホスト部ランダム化(2021/08/10追記)

匿名アドレスをOFFにしても、Global Unicast Addressのホスト部はランダム化されているので、MACから誘導されるEUI64アドレスを使わせるにはこれをoffする必要がある

netsh interface ipv6 set global randomizeidentifiers=disabled

_ [SAD]Long List Support

seq_utils.hを使ったJoinの再実装を作成

インタープリタスタックと関係なく、メモリがある限り長いListを組み立てられるようになった。

実用上、次に必要なのはMap1/Scan1の再実装

多分、コードを読むとイテレーション動作の実装が微妙に違うのだが、定義的にはイテレーションのカーネルが違うだけなので、for_allイテレータとカーネルの形で実装するのが素直か？

実行効率優先なら、現行実装と同様にカーネルをイテレーションループ内にinline展開した方がいいのだが…

テンプレートライブラリ使いたい…Orz

_ [SAD]Map1/Scan1実装

Joinに続き、Map1/Scan1の実装完了

で、データ操作系の典型的なユースケースを試していると以下のケースで、スタックを踏み抜く

• MapThread[f, {long-list, long-list}]
  • Map[f@@#&, Thread[{long-list, long-list}]]はOK
  • 多分、Threadは、いきなりリストコンテナを組み立てているからOKの模様
  • ScanThreadはテストしていないが、おそらくスタックに積み上げた出力列が溢れている
• f@@long-list (fは、Reduction operator)
  • fの評価式をApplyで組み立てる際に、引数列としてlong-listをスタック上に展開する(式をスタック上に展開して評価する関数評価呼び出しシステム上の問題)
  • Applyが、fがReduction演算であることを知っていれば、イテレータ処理に移譲できるが、ユーザー定義のReduction演算子には無力
    • 評価器のスタックベースの評価を止める or sequence containerによる式評価を導入する
      • 関数評価時の引数参照インターフェースの変更が必要
        • Apply等からの運用を想定すると、Head + Argument Containter渡しが現実解か？
      • 実装過渡期は、引数列参照渡しとStack渡しの両方をサポートする必要有り
        • 関数テーブルに引数型式属性を持たせて、評価時の呼び出しプロトタイプをDispatchさせる
    • Reduction演算を行う高階関数を導入する
      • 例えば、左再帰なReduction演算 LeftReduce[f, {arg1, arg2, args...}] := LeftReduce[f, {f[arg1, arg2], args...}] := f[f[...f[f[arg1, arg2], arg3]...], argn]
        • LeftReduce[f, {}] := f[], LeftReduce[f, {arg1}] := f[arg1] == f[f[], arg1] であるべきか…
      • 浮動小数点処理の場合、評価木の組み方で処理結果が異なる
      • 短縮評価可能な論理演算の場合、評価木の組み方で処理時間が異なる
      • n要素に分岐する再帰的な評価木もありえる

_ [SAD]tfefunrefとtflevalが違う罠

on-stackからtfefunrefで評価するのと、containerを組み立ててtflevalするので結果が違う模様

tflevalでも関数評価にtfefunrefを使っているので、前処理絡みの挙動の違いか？

どうやら、tfefun系を on-heapで処理できるように再設計して作り直すのが正解ぽぃ(そして、Applyの問題も解決される)

設計上留意すべきは点は、

• 引数列を受け渡すプロトタイプの設計
• 改修途上のインターフェースの多重化・自動変換フレームワーク
• 引数列の一部を編集して再帰呼び出し評価の再実装