{新しい選択肢}{Cμ 文字列処理改良}{Cμ 基礎改良}{地味な最適化}{本命視}{不要な函数}{不要な譜類}{old_rx.Hu.bak}{old_rx.Cu.bak}{xam.h}...=}(50)

{希哲15年7月11日の開発 K#F85E/A-E74C-C7B7}

休日のため,進捗記録は付けずに普段なかなか出来ないような作業をした。

全知検索窓に関する不具合修正出振るいから,昨日の開発でした s_T理腑想像以上高速化に繋がっていることに気付いた体感表示速度が明らかに向上した。昨日の時点ではそこまで期待していなかった。

この際,ずっと気になっていた文字列周りの譜類整理実装整理を進めてしまうことにした。最終的にだいぶ見通しが良くなり,思わぬ形でデライト高速化進展した。

デライト高速化に関しては KNEST 隠し実装本命視してきたが,この手の地味な最適化が想像よりずっと効くことに気付けたのも大きな収穫だった。

Cμ 文字列処理改良も含め,「Cμ 基礎改良」というデライト高速化新しい選択肢が出来たことになる。

全知検索窓に関する不具合修正安定化に繋がるので,この一日で決して小さくない品質向上になっただろう。


xam.hold_rx.Hu.bakold_rx.Cu.bak など不要な譜類削除し,不要な函数も多数削除出来た。換配時間短縮にもなるだろう。

小さい函数は極力頭譜に移した。

rgx_T実装見直し,無駄な一時客体生成しないようにした。


その他,細かい装体調整など。

{一日一文}{役立っている}{分かりやすい例}{広がり過ぎる}{見込める}{希哲15年8月}{10日分}{十分な時間}{言語設計}{希哲15年7月10日}...=}(69)

{希哲15年7月10日の日記 K#F85E/A-E74C-8E47}

状況を整理した結果,今月デライト収益目標達成こだわらず,雑務片付け9月の達成を目指すことにした。

組計スケジュール調整したとはいえ,6月までの収益目標達成を確実視して来たため,今月は何かと皺寄せが多い月になっていた。

それでも,今月中に達成しなければジリ貧になる,というような状況であれば他のことは一切無視してでも目指すところだが,だんだん状況も変わってきて,今月を乗り切れば9月まではデライト開発十分な時間確保出来る見通しになった。それも,今月は全部で10日分程度の消費で済むので,無理をするような状況ではなくなった。

収益目標にはほど遠いが,来月は多少の収益見込めるようになったことも大きい。

今日までに何とか一段落させたいと思っていたデラング整備も,良くも悪くも広がり過ぎてまだ時間がかかりそうだ。全く予定になかった「キラキラ星記法」が分かりやすい例だ。

生活律動が乱れ,一日一文など日課等閑になってきているのも気になっていたため,ここでいったん落ち着いて,また着実に「行進」するようにやっていきたい。

結局,昨年11月13日に収益目標達成の期限とした11月1日に近付いているが,そこまでは十分「早期成功」と言えるだろう。


デラング整備によりデライト文書整備見通し大きく改善し,最近では Dex技法 への応用を考え始めたり,全知検索検索演算子設計実装も考えやすくなったり,「デライト」というサービス名称SEO 上の欠点を補えそうなことに気付いたり,発展著しい

考えてみると,νS知機駒手などで言語設計経験を積んでいたことが大いに役立っている。つまり,それだけの蓄積が無ければここまで出来ないということだ。

こんなこともあり,もう少し時間をかけて育ててもいいか,という気になっている。

{希哲15年7月10日の開発}{Cμ 最初期}{小さい函数}{交語化マクロ}{libxtd 整備}{希哲15年7月10日}{希哲15年7月10日の進捗時限}{希哲15年7月10日の進捗}{希哲15年7月8日12歩}{デライト高速化}...=}(33)

{希哲15年7月10日16歩 K#F85E/A-E74C-2920}

libxtd 整備デライト高速化

久しぶりs_Tstr.cl.hstr.cl.u理腑をして終了。

先日の不具合修正で色々と問題を見つけていた。だいぶ見通しが良くなり,最適化しやすくなった。

廃止を決めていた希哲13年12月18日5歩もののまだ残っていた交語化マクロ排除し,なぜか素譜に書いていた小さい函数頭譜に移した。

文字列周りは特に Cμ 最初期手探りで作った部分なので何かと混乱している。少しずつ整理していきたい。

まだ出振るいするほどのことでもないので未出振るい

=}
{一日一文}{希哲15年5月の一日一文}{先が思いやられる}{関の山}{最終目標}{迷い込んだ}{良い暮らし}{立ち尽くす}{分かれ道}{選んだ}...=}(75)

{いくつかの岐路 K#F85E/A-E74C-05DC}

私にも,いくつか人生の岐路というべき場面があった。

私は12歳頃から変わったを歩むことになったので,これも岐路といえばそうかもしれない。ただ,意識的にこの道を選んだわけではないし,その後のことも全く想像出来なかった。なんとなく迷い込んだという感じだ。

分かれ道を前に立ち尽くすような人生の岐路という意味では,やはり17歳の頃を思い出す。「閃き」で輪郭法希哲館事業青写真が出来た頃だ。

希哲館事業に進むべきか,その気持ち押し殺して普通の人生に進むべきか。どちらを選んでも困難は目に見えていた。結局,決心して希哲館事業発足にいたるまで4年ほどかかった。希哲元(2007)のことだ。

次の岐路は,希哲6(2012)デルンの実用化直前のことだった。

当時の私は,何かと恵まれ個人事業主として好条件司組システム開発仕事をもらったりしていた。このまま無難に仕事を続けるか,思い切ってデルン開発注力するか,という岐路だ。

この時は,あまり迷いもなくデルン開発を取った。希哲館事業を始めた時点で,私の目標は,とりあえず世界史上最大の企業を創り知識産業革命実現することだった。それすら最終目標ではない。このまま無難にやっていれば,そこそこの大企業を創るのが関の山だろうと思った。

デルンの実用化成功とともにそれまでの仕事は全て止め,デルン育てることに注力するようになった。それから更に8年ほど経った希哲14(2020),デルンはデライトとして世に出る

そして今年開発が上手く行き,デライトの成功時間の問題という所まで来て,また一つの岐路があった。じっくり時間をかけてデライトを成功に導くか,多少リスクが増してもデライトの成功を急ぐか,という岐路だ。

もちろん,私はデライトの成功を急ぐことにした。デライトの成功は,希哲館事業の成功過程に過ぎない。デライトだけが成功しても意味がなかった。これは「デライトはなぜ成功を急ぐのか」でも書いた通りだ。

結局,私は無難な道を選ぶということが出来なかった。希哲館事業の成功への希望が残るかどうか。17歳の頃から,それだけが私にとっての死活問題だった。どんなに安全だろうとその希望がゼロなら私は生きていられないし,どんなに危険だろうとその希望がわずかにでもあれば生きていける。

今のところは環境のおかげで良い暮らしが出来ているし,見通しも良いが,生き方そのものがとんでもない綱渡りには違いない。そう考えてしまうと,具体的心配もないのに先が思いやられる

=}
{一日一文}{希哲15年5月の一日一文}{政治的合意}{代替策}{交通技術}{基礎所得保障}{人間への共感}{両立}{世界史上最大の企業}{階層的}...=}(73)

{基礎所得保障ベーシック インカムから基礎雇用保障ベーシック ウェルカム K#F85E/A-E74C-B5DA}

一昨日の一日一文で私の変わった“金銭欲”ついて少し触れたが,これが実は希哲館事業核心に近い要素かもしれない。

希哲館事業にはもともと,“資本主義共産主義綜合”という目標が含まれている。その新しい経済思想を「相通主義」と呼んでいた。この名前も最後に見直したのがだいぶ前なので,もう少し良い名前がある気もするが,しばらく仮称としておこう。

相通主義というのは,資本主義流儀に則って共産主義理想(本来の共産主義とは別の形で)実現してしまおうという考え方だ。そのになるのが「相通化技術」と呼ぶ技術で,情報技術交通技術に大別される。希哲館事業では,その情報技術を「虎哲」,交通技術を「竜力」と呼び,開発計画を「竜虎計画」と呼んでいた。

その虎哲の核心となるのが輪郭法で,デルンデライトとなっていく。こう階層的整理してみると,希哲館事業構想がいかに巨大か分かる。「人類史上最大の事業構想」というのも伊達ではない。事業の全体像を簡単に説明しておこうと思うだけで,本題について忘れそうになる。

ベーシック ウェルカムとは

そんな希哲館事業で私がやりたいことは,簡単に言ってしまえば,“世界史上最大の企業”を作って雇用万人開放することだ。これを「基礎雇用保障ベーシック ウェルカム」(BW)と呼んでいる。「基礎所得保障ベーシック インカム」(BI)の代替策だ。

BI は昔から考えられてきたことだが,小規模な実験以外で実現見通しは立っていない。いくつかの理由で,一定規模以上の国家で実現することは困難と私は見ている。

BI は社会の構成員に大きな考え方転換を迫る。それも,持続的でなければ意味がない。やってみたが,やっぱり戻そう,という動きも当然考えておかなければならない。その割に,哲学的弱さがある。利点とされていることも大半は希望的観測でしかない。

それに対し,BW は思想転換も政治的合意も必要としないという大きな利点を持つ。その代わり,万人に雇用を提供出来る企業を創り出さなければならない。

私はよく GAFAM意識したようなことを語っているが,実際,この構想は GAFAM を大きく越えるような企業でなければ実現出来ない。しかし,それは不可能なことではない。

知識産業はこれまで考えられなかったような格差を生み出す。企業間も例外ではない。ついこの間まで,GAFAM の株価東証一部上場企業全体を上回り,米国政府と対立することなど考えられなかった。その GAFAM 全体を一社で上回る企業が出てこないとも言えない。

究極の格差を制することで世界に平等をもたらす。この BW という考え方は,世界史上最大の富を生み出そうという意欲と,人並の収入があれば満足に暮らしていけるという価値観両立させた人間にしか生み出せないものだと思う。

=}
{Dex 改良}{記法処理範枠}{記法処理}{記法実装}{行処理}{希哲15年5月18日}{リスト記法実装}{デバッグ出力整備}{埒が明かない}{デラング不具合修正}...=}(28)

{希哲15年5月18日の開発 K#F85E/A-E74C-8B00}

デラング整備Dex 改良

今日から「Dex 改良」に入った。

デラング不具合修正から視野を広げて記法実装に入った理由に,Dex_T整理方針がまとまらない,ということがあった。

Dex はあらゆる記法処理範枠フレームワークでもあるため,特定の記法の不具合だけを見ていても埒が明かない。そこである程度全体像を明らかにするために記法実装を進めてきた。リスト記法実装がある程度の所まで来て必要なものが見えてきた。デバッグ出力整備を経たのも大きい。

最初は Dex_T の中心的な行処理改良しようとしたが,今日は結果的に全体的な理腑リファクタリングとなった。混沌とし始めていた Dex_T がかなりすっきりし,見通しは大きく改善した。

{希哲15年5月13日の開発}{DBG_DB()}{PASS}{希哲15年5月13日の進捗時限}{希哲15年5月13日}{希哲15年5月13日の進捗}{デバッグ出力整備}{デバッグ出力}{DBG()}{LOG_ERR()}...=}(36)

{希哲15年5月13日14歩 K#F85E/A-E74C-7EF9}

デバッグ出力整備

いったん終了。

これまで DBG()変数等を与える場合,先頭に << が必要だったが,これを廃止した文字列リテラルの連結規則を利用し,文字列リテラルはそのまま書けるようになっていた) 初期の慎重方針による仕様だったが,流石に煩わしいと感じることが多くなってきていた。

これにより,あちこち書き換える必要が出てきたが,元々無駄デバッグ出力が多過ぎたこと,新たに追加したマクロ書き分けたいこともあり,ここで整理してしまうことにした。

結局,LOG()LOG_ERR()DBG()DBG_DB()DBG_DEX()PASS分割することになった。

無駄なデバッグ出力も削除し,概ね整理出来た。

出力の見通しは非常に良くなり,絞り込みやすくなった。デルン出力録再開にも寄与しそうだ。

=}
{見通し}
{}