c4se記:さっちゃんですよ☆

.。oO(さっちゃんですよヾ(〃l _ l)ノ゙☆)

.。oO(此のblogは、主に音樂考察Programmingに分類されますよ。ヾ(〃l _ l)ノ゙♬♪♡

音樂はSoundCloud等バラバラの場所に公開中です。申し訳ないがlinkをたどるなどして探してください。

考察は現在は主に此のblogで公表中です。

programmingは、GitHubで開発中です。

tacit programming : Point-free, Concatenatives & J

tacit programming は point-free style としても知られてゐる。函數適用を使って函數を組み立てるのではなく、函數合成を基本の部品とするやり方だ。見た目上では函數の定義から引數が消える。

tacit programming から連鎖性 programming 言語 (concatenative programming language) と J 言語へ繋がる理路が有る。それを書いた資料がこれだ。

tacit programming : Point-free, Concatenatives & J - Speaker Deck

先づ Haskell での例を擧げてある。例へば階乘は入門書的には

factorial n = n * factorial (n - 1)
factorial 0 = 1

factorial 9

とするだらう。ここには n と云ふ引數が見えてゐる。foldr を使ふとこれは tacit に出來る。

factorial = (foldr (*) 1) . (enumFromTo 1)

factorial 9

引數が消えた。平均の例も見る。

average xs = foldr (+) 0 xs / (fromIntegral . length $ xs)

average [2, 3]

これは tacit ではない。(->) に關する Applicative を使ふと tacit に出來る。

instance Applicative ((->) a) where
   pure = const
   (<*>) f g x = f x (g x)
   liftA2 q f g x = q (f x) (g x)

これで、

average = ((/) . foldr (+) 0) <*> (fromIntegral . length)

average [2, 3]

(<*>) の定義を好く見てみると、これは SKI combinatory 論理の S に成ってゐる。ここから combinatory 論理の紹介を資料ではしてある。

さて combinatory 論理を基に發想された programming 言語に、連鎖性 programming 言語と呼ばれる一群の言語が有る。Factor や Popr 等が皆さんの手元でも使へるだらう。

Factor programming language

HackerFoo/poprc: A Compiler for the Popr Language

Popr で平均はこうする。

average: dup sum swap length /f

[2 3] averge

階乘はこうする。Factor ではこう。

MEMO: factorial ( n -- n! )
  dup 1 > [ [1,b] product ] [ drop 1 ] if ;

9 factorial

1 から 9 までの數列を作り綜積をとってゐる。Popr ではこう。

factorial: [1 == 1 swap !] [dup dup 1 - factorial * swap 1 > !] | pushl head

9 factorial

| はその前の 2 つに同時に pushl head を作用させ、失敗した計算を捨て成功した計算を輯める。n True ! は成功し n False ! は失敗する。

fact と縮める事にして、2 fact は概ね下の樣に評價される。

2 fact
2 [1 == 1 swap !] [dup dup 1 - fact * swap 1 > !] | pushl head
[2 1 == 1 swap !] [2 dup dup 1 - fact * swap 1 > !] | head
[False 1 swap !] [2 dup dup 1 - fact * swap 1 > !] | head
[1 False !] [2 dup dup 1 - fact * swap 1 > !] | head
[2 dup dup 1 - fact * swap 1 > !] head
[2 2 dup 1 - fact * swap 1 > !] head
[2 2 2 1 - fact * swap 1 > !] head
[2 2 1 fact * swap 1 > !] head
[2 1 fact * 2 1 > !] head
[2 1 fact * True !] head
2 1 fact *
2 1 [1 == 1 swap !] [dup dup 1 - fact * swap 1 > !] | pushl head *
2 [1 1 == 1 swap !] [1 dup dup 1 - fact * swap 1 > !] | head *
2 [True 1 swap !] [1 dup dup 1 - fact * swap 1 > !] | head *
2 [1 True !] [1 dup dup 1 - fact * swap 1 > !] | head *
2 [1] [1 dup dup 1 - fact * swap 1 > !] | head *
2 [1] [1 1 dup 1 - fact * swap 1 > !] | head *
2 [1] [1 1 1 1 - fact * swap 1 > !] | head *
2 [1] [1 1 0 fact * swap 1 > !] | head *
2 [1] [1 0 fact * 1 1 > !] | head *
2 [1] [1 0 fact * False !] | head *
2 [1] head *
2 1 *
2

Factor に就いては昔書いた事が有る。

Unix の pipe & filter も仲間だ。Unix pipe & filter は一次元だが、連鎖性 programming 言語はこれを多次元化してゐる事に成る。

同じく combinatory 論理を基にしたが J 言語は連鎖性 programming 言語とは異なる拡張の仕方を行った。

Jsoftware

足し算の例。

  2+3
5

これでは tacit ではない。insert と云ふ adverb (副詞) を使ふと tacit に出來る。adverb は凡そ高階函數であり、insert は fold に當たる。

  +/2 3
5

平均はこうする。

  average:=(+/%#)

  average 2 3
2.5

連鎖性言語では combinatory 論理の規則は函數として見えてゐる。J 言語では combinatory 論理の規則は函數として見えてゐるものも有るが、多くは函數合成の規則に閉じ込められた。今囘登場する規則は二つだ。

  • monadic fork :  (fgh)x=(fx)g(hx)
  • monadic hook :  (fg)x=xf(gx)

"monadic" は「單項の」である。"dyadic" 「二項の」も J 言語では言ふ。

平均の評價を辿る。

(+/ % #) 2 3
(+/ 2 3) % (# 2 3)  NB. monadic fork
5 % 2
2.5

NB. は comment の始まりを示す。階乘の例。先づ J 言語には階乘を計算する函數が有る。

  !9
362880

數列を作って疊み込む例。

  */1+i.9
362880

評價手順を示す。

*/ 1 + i. 9
*/ 1 + 0 1 2 3 4 5 6 7 8  NB. `i.` creates a vector
*/ 1 2 3 4 5 6 7 8 9  NB. vector operation
1 * 2 * 3 * 4 * 5 * 6 * 7 * 8 * 9  NB. folds `*`
362880

再歸を使ふ例。

  factorial =: 1: ` (* factorial@<:) @. *

  factorial 9
362880

factorial 2 の評價手順を示す。

factorial 2
1: ` (* factorial@<:) @. * 2
(* factorial@<:) 2  NB. `@.` selects the second
2 * (factorial@<: 2)  NB. monadic hook
2 * (factorial 1)
2 * (1 * (factorial 0))  NB. same as `factorial 2`
2 * (1 * (1: ` (* factorial@<:) @. * 0))
2 * (1 * (1: 0))  NB. `@.` selects the first
2 * (1 * 1)
2 * 1
2

masawada ではないものって何? どれだけ在るの? 調べてみました!

masawada Advent Calendar 2019 - Adventar 12/11

masawada ではないものって何? どれだけ在るの? 調べてみました!

和田

和田(わだ)はどこ?Weblio 辞書

姓氏の一。関東御家人。三浦氏一族。義盛は早くから源頼朝に従い幕府内に重きをおいたが、和田合戦に敗れて滅亡。庶流はのち越後で勢力を伸ばした。

ホータン 【Khōtan】

中国、新疆ウイグル自治区タリム盆地南縁にあるオアシス都市。古代・中世には東西中継貿易で繁栄。玉の産地として有名。コータン。旧称、于闐(うてん)。 〔「和闐」 「和田」とも書く〕

和田さんの名字の由来や読み方、全国人数・順位|名字検索 No.1/名字由来 net |日本人の苗字・姓氏 99%を掲載!!

語源は、曲がっている田、輪のような地形の田、丸田から来ている。また、よい田、稔りのある田、吉田のことである。全国に姓氏・地名ともにきわめて多い。

家紋は木瓜、橘、月星など。

だわ

方言語尾。轉じて女性語尾。また方言から轉じて近年は男性も広く使ふやうに成ったと思はれる。斷定の助動詞「だ」に詠嘆の終助詞「わ」が附いたものではなからうか。

沢田、澤田

沢田(さわだ)はどこ?Weblio 辞書

沢田さんの名字の由来や読み方、全国人数・順位|名字検索 No.1/名字由来 net |日本人の苗字・姓氏 99%を掲載!!

山間地には、沢のつく地名は極めて多い。沢田は、文字通り山峡の水田という意味。

佐和田

佐和田町 - Wikipedia

佐和田町(さわたまち)は、かつて新潟県佐渡郡におかれていた町。佐渡島内のバス交通の要衝であり、経済の中心であった。2004 年 3 月 1 日に合併して佐渡市の一部になった。地元では「さわだ」と濁って発音されることも多く、店名などで「さわだ」の表現が使用されることも見られる。

"まさわだ".chars.permutation.map{ |cs| cs.join("") } - ["まさわだ"]

まさだわ

MSDW : Morgan Stanley Dean Witter

真砂だわ。何とも真砂だわ。

まわさだ

MWSD : Marine Wing Support Detachment 24

摩・和定

まわださ

MWDS : Metallic Wear Debris Sensor

まわわ…ダサッ…。

まださわ

MDSW : Maryland Sheep and Wool Festival

未だ沢にをんねん。迷ってぇな。

まだわさ

MDWS : https://www.youtube.com/channel/UCoxB3hVgCu2ZRKuj-FGkghg

www.youtube.com

未だだワサワサ。どしたの?

さまわだ

SMWD : Surigao Metropolitan Water District

サマワだ。

サマーワ - Wikipedia

サマーワ、あるいはアッ=サマーワ(السماوة al-Samāwa 英語表記は Samawah, as-Samawah など)は、イラク共和国ムサンナー県の都市。

さまだわ

SMDW : Swedish midsummer design weekend

樣だわ! 樣と御附けなさいっ。

さわまだ

SWMD : Solid Waste Management Department

サ、和間だ。

さわだま

SWDM : shortwave wavelength division multiplexing

茶話魂。茶話の靈。

さだまわ

SDMW : Secure Dynamic Middleware for Defeating Port and OS Scanning

定囘。定まった囘り方をする事。

さだわま

SDWM : Aldeia de Metuktire Airport

差だわ、マ―ッ。

わまさだ

WMSD : Work-related Musculoskeletal Disorders

ワッ、真砂だ!

わまださ

WMDS : Weapon of mass destruction

和間、ダサッ…(は?)

わさまだ

WSMD : World School Milk Day

輪様だ…。その者は輪と呼ばれた。

わさだま

WSDM : Web Search and Data Mining

山葵玉。

わだまさ

WDMS : World Digital Mining Summit

わ! 騙さ (ブツッ…)

わださま

WDSM : 710 AM 98.1 FM WDSM | The Talk of the North | Duluth, MN

和田樣。支配者。

だまさわ

DMSW : Drug Manufacturing SoftWare

打魔茶輪。茶の葉を輪に竝べて魔を打つ事。

だまわさ

DMWS : Defence Medical Welfare Service

默話差。默る事と話す事の差。

ださまわ

DSMW : FAO Digital Soil Map of the World

The サマーワ

ださわま

DSWM : Department of Solid Waste Management

だ伊那西部広域農道ま。え、何これ…。

伊那西部広域農道 - Wikipedia

伊那西部広域農道(いなせいぶこういきのうどう)は、長野県上伊那郡箕輪町沢(さわ)の国道 153 号との交差点から上伊那郡南箕輪村を経て、同県伊那市西春近(にしはるちか)までを結ぶ広域農道である。伊那市上伊那郡宮田村の境にて伊那中部広域農道に接続する。

だわまさ

DWMS : Data Warehouse Management System

駄話増さむ。どうでもよい話が増えること。

だわさま

DWSM : Dynamic Watershed Simulation Model

打羽 summer。

("masawada".chars.permutation.map{ |cs| cs.join("") } - ["masawada"]).size

40296

早稲田

早稲田 - Wikipedia

早稲田の地域は、古くは牛込村に属しており江戸牛込村字早稲田であったが、江戸時代初期には、別村になり「早稲田村」と呼ばれるようになった。1868 年(慶応 4 年、明治元年)、東京府の設置により、南豊島郡牛込早稲田村となった。1878 年(明治 11 年)、郡区町村編制法により東京府牛込区が発足し、早稲田村は牛込区に所属することになった。さらに、1889 年(明治 22 年)、市制、町村制の施行に伴う東京市の設置により、東京市牛込区は、南豊島郡牛込早稲田村編入した。 1943 年(昭和 18 年)、東京都制施行により、早稲田は東京都牛込区早稲田町牛込区早稲田鶴巻町等となった。

早稲田大学 - Wikipedia

早稲田大学教旨

早稲田大学は学問の独立を全うし、学問の活用を効し、模範国民を造就するを以て建学の本旨と為す。

早稲田大学は学問の独立を本旨と為すを以て、之が自由討究を主とし、常に独創の研鑽に力め、以て世界の学問に裨補せん事を期す。

早稲田大学は学問の活用を本旨と為すを以て、学理を学理として研究すると共に、之を実際に応用するの道を講じ、以て時世の進運に資せん事を期す。

早稲田大学は模範国民の造就を本旨と為すを以て、立憲帝国の忠良なる臣民として個性を尊重し、身家を発達し、国家社会を利済し、併せて広く世界に活動す可き人格を養成せん事を期す。

DWU

Deep Web Underground

MAZDA

アフラ・マズダー

善惡を越え善惡を可能にし、スプンタ・マンユアンラ・マンユの對立を可能にする者。後にスプンタ・マンユと同一視される。

ダエーワ

ダエーワ - Wikipedia

インドのサンスクリット語における Deva(デーヴァ、天部)と共通語源。しかし、古代インドでデーヴァが善神として崇拝の対象であり続けたのに対し、古代イランではダエーワは「悪神」「悪魔」という逆の意味になっている。ゲラルド・ニョリ(イタリア語版)などによれば、これはザラスシュトラ宗教改革の結果だという。より古い時代からの神々(デーヴァ)のうち、戦士機能を割り当てられていたインドラ、サウルウァ(ルドラ)、ワユ(ヴァーユ)などがダエーワとされた。いっぽう、インドのアスラが神々と敵対する存在とみなされる以前から知られていた古い神格である、アスラに属する神ヴァルナは、イランにおいてアフラ・マズダーに対応した。

悪神としてのダエーワという語は、さらにスラヴ語に借用された(古代教会スラヴ語で divu「悪魔」)。しかし後の時代になってもソグド語やアラム語の一部では善性の存在として使われることもあった。

ダエーバイト文明

SCP-140 - SCP 財団

SCP-140 は現在の南シベリア地方に起源を持つ、ダエーバイトと認識されている古代文明の詳細な記録です。他の全ての文明と同様にダエーバイト文明もまた時と共に進化し、変化を続けましたが、彼らは異常な一貫性を保ちました。ダエーバイト文化は全ての時代において、軍国主義、侵略傾向、祖先崇拝、多くの奴隷人口を持つ都市中枢、陰惨な人身御供、明らかに有効性を持つ秘跡儀式の実践、といった特徴を持ち続けました。この記述が信用できるとすれば、ダエーバイト文明の残した遺物と化物の多様さは異常かつ危険であり、それだけで十分に封じ込めに値します。

調べた結果、masawada ではないものとは何か解りませんでした! 全ては masawada なのかもしれませんね…。

如何でしたか??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

Elixir を何故採用したのか

Elixir Advent Calendar 2019 - Qiita 12/11

Kubernetes を何故採用したのかの續きだ。各項目の一般的な前提も前の記事に準ずる。よって讀んでくださってゐる事を期待する。

下記 slide 時期の昔話をする。何故技術撰定で Elixir を採用したのか。

ステートフルで大規模アクセスのある soft-realtime なゲームサーバーを easy につくる

採用後の具体的な運用の話はしない。それが今でも役立つ話題なら別にしやう。今でも個人的に Elixir を續けてゐる理由もここの話題ではない。

何が嬉しいか?

當時 game の rule や cycle は決まってゐなかった。しかし何人かで PvP を realtime に行ひたい、同時に行なはれる PvP は非常に多い (多くしたい) 事は判ってゐた。

組織內での第一の撰擇肢は Rails であったから先づは Rails を檢討した。求められる realtime 性が定かではない。rule や cycle を檢討してゐる途中なので出來るだけ柔軟性を保ちたかった。詰まり常時接續通信 (front は Web front であったから WebSocket の事である) で realtime PvP が行なへれば好ましい。勿論 realtime 性を減じれば Rails で實裝出來る。

  • realtime 性を減じて Rails で實裝する
  • RabbitMQ で client を仲介し、對戰 logic は client に持たせる。RabitMQ で MQTT を介し PvP する前例は經驗を有する。Web front で高速且つ派手な描画をする前例は無かったから描画するだけでも risk であり、更に複雜な logic と云ふ risk を client に持ち込む事に成る
  • Photon。これは組織內で現役であった。ただし Photon 側に對戰 logic は無く Unity で實裝した client 側に有る。それに WebSocket の實績は身近には無かった
  • Elixir / Phoenix。Elixir 自體の運用經驗は有ったが單純な HTTP API server である。Phoenix も同樣
  • node.js。この運用經驗も組織內には有る
  • Go。新規

柔軟性を保ち、安心して運用出來、手慣れてゐ、好みであり、組織內に知見が有る Elixir / Phoenix に決めた。

Phoenix.Channel の backend は Redis である。Redis の運用經驗は豊富であった。Redis で安定して性能が出せるかは不安であったから、随分後まで NATS や Kafka を檢討してゐたが、Redis で充分であった。

作り切れるか?

若し動く物が作れるなら必ず早目に動く物を作ってみなければならない。

既に dummy 的に作られた server が有った。これを模倣する事から始めた。docker-compose、lint、test を調へながらやり、二週間ほどで模倣出來た。dummy は chaos な實裝だったが、模倣はこの時既に函數型 paradigm で game logic を model 化してある。この model 化は假に Elixir を止めても役立つ筈だ。2 つの client で WebSocket を介して對戰出來る樣に成った。

Elixir が動く Erlang VM は實績の多い VM で、規模の大きな常時接續を捌く事で有名だ。

始めは全て Elixir で作る積りだったが、risk が大きく成り過ぎるので、Elixir は新しい PvP のみに限定し、手慣れた残りは手慣れた Rails で作る事に轉換した。これは話し合って決めた (他は決めてから話し合ってゐる……)。

これらから作り切れると判斷した。

また fallback 先としては、realtime 性を減じてでも Rails で實裝出來る見込みは有った。この場合經驗の豊富な者が組織內に多く、助けも借りられる。

運用出來るか?

TCP 接續はともかく、WebSocket をスマホから大量に繋ぎ維持する經驗は誰にも無かった。よってこれは實地試驗や負荷試験をする迄判らない。多分もっと早く實地試驗と負荷試驗をするべきであった。Erlang と Redis の實績は世間的にも豊富だったから油斷してゐたのだ。結果的にはうまくいったが、これは考へられたものではなかった。

Erlang, Elixir, library の ver.に就いて。minor ver.には即座に追隨する。Erlang, Elixir は經驗からすると minor ver.の互換性は安定してゐるから、即座に上げられないなら組織に問題が有る (Erlang, Elixir の話であり他には該当しないかもしれない)。minor ver.の更新で困る library は捨てるべきだ。major ver.の更新には 1 つ遲れ以內で着いてゆく。これらを早く決めた (明文化したのは大分後だが)。

開發を速く保ち續けられるかも大切だ。これは Elixir に依らない部分が大きい。開發の課題を繼續的に解決出來るか、その cost を如何に払うかは Elixir であってもなくても變はらない。作るものの genre に依る。Elixir が特別 refactoring しづらいなら考へるべきだが、函數型に依り明示的な programming を行なひ、test も書き、process の樣子も見易いならそれ以上特別に考へる事は無い。

人を増やせるか? team を作れるか?

これは難しい所だ。業界で Elixir が支配的に成る事は考へられない。

今から振り返るとこれは失敗したと言へる (更に未來の事はここで話題としない。失敗は一時的なものであり得る)。新しい開發が得意な者は難なく Elixir を習得した。他の product でも Elixir で開發が進んでゐ、組織の backup も得られると油斷した。一時的には成功したと言へる。業界的な圧力が無い所に私が Elixir を広めるのに失敗したと云ふ事だ。その面では Go を使ふのが好かっただらう。支配的には成らなくとも、もう少し魅力を増せれば好かったと思ふ。今後の課題である。

とは云へ巨大でもない組織 Go にも Elixir にも投資する事は無理だから、他の開發も進んでゐる事であったし Elixir を撰んだのは妥當だったと思ふ。

他の product に好い影響を與へられるか?

WebSocket で realtime PvP を實裝する、その函數型的な model 例を提供する、と云ふ意味で know how に成ったと思ふ。先鋒を司るぞ、位いに軽く考へてゐた。