2024年7月31日水曜日
構文木
というやつだ
答えは3なんだけど、
LRで構文木を作ると
まず、Rを探しに行く
右端は+ 1
PLUS
/ \
5/(8-3)*2 1
続いて、LからまたRを探すと、* 2
PLUS
/ \
MUL 1
/ \
5/(8-3) 2
さらにLの5/(8-3)にRを探すと/ (8-3)
PLUS
/ \
MUL 1
/ \
DIV 2
/ \
5 8-3
んで、今度はR側にまだ再帰できるところがあるので
PLUS
/ \
MUL 1
/ \
DIV 2
/ \
5 MINUS
/ \
8 3
これで構文木が完成
そんで、答えを出すには最下層から上に上がっていく
8-3=5なので
PLUS
/ \
MUL 1
/ \
DIV 2
/ \
5 5
続いて
5/5=1なので
PLUS
/ \
MUL 1
/ \
1 2
さらに続けて
1*2=2となり
PLUS
/ \
2 1
最後は
2+1=3
という事で、答えの3が導ける
ここで、数式とプログラミング言語を比べると、C言語なんて関数なので、
例えばif文
if (a==b) {
proc();
}
if
/ \
== proc()
/ \
a b
のようになるし、forも代入も似たようなもんで、構文木を作って解釈して行くことになる
このやり方はクヌース大先生が考案したもので、その後多くのアイデアが出てくるのだけど、基本はやはり構文木を作るというやり方になっている
そして、lexやyaccが生まれ、
構文木を自動生成するためにBNF記法が生まれ、C言語などのプログラミング言語が出来た
C++では構文定義をC++の記法で置き換えたboost::spiritsなども生まれ、すぐにこの変態的実装はなくなるかと思ったが、C++17でも残ってる
lexやyaccは
flexやbisonになったが
わたしが最近触っているANTLRは構文定義からGoやSwiftのコードも出力できる
好みの言語で新しい言語を作ることができるようになってきた
2024年7月20日土曜日
XML2Json再考
突然思い出したので
忘れないうちに書いておきます
Xerces Xalan
今はなかなか見かけない
この2つのプロジェクトは
XMLを扱っていた人ならご存知でしょう
実装の中身を見ていませんが
XMLをDOMとして扱っておらず
逐次的に処理をする実装になっていると聞いたことがあります
DOMについて
公式での解説も何だかパッとしないので改めて説明します
DOMと言うのは、XMLのツリー構造を構造体などを利用してメモリやファイルなどに保存しておいて、高速にアクセスすると言う仕組みです
例えばHTMLはブラウザでツリー構造が扱えるようになっていて、そのためにDocument.getElenentByIdのようなアクセスが可能となっています
これに対してDOMでは無いパースとは、XMLを単なるテキストとして扱い
上から順にパースして該当項目を探すので
あまりパフォーマンスは良くありません
このようにXerces Xalanは逐次的にパースするので
XMLを一度DOMとしてメモリやファイルなどに展開する時間はゼロです
巨大なXMLを扱う場合にはそれをDOMとしてメモリやファイルに保存しないため、メモリやファイルの消費を抑えることが出来ると言う利点もあります
なぜ突然この二つを思い出したのかと言うと、、、
わたしが以前Goで作ったXML2Jsonの実装を見ていて
DOMでは無い方が良いかも知れないと思い始めていたからです
当時の実装は逐次的にXMLのパースを行うGoのライブラリを使用して、XMLのTokenを取得しながら自前のDOMを作り、そのDOMからJSONに変換すると言う実装でした
しかもその変換関数は再帰ルーチンとなっていました
どうも無駄だらけに見えてきました
やはり一度作ったプログラムは何度か作り直さないとダメです
わたしは天才ではありません
2024年7月16日火曜日
2024年7月12日金曜日
地熱
G Mm/r^2
このエネルギーは潮の満ち引きなどを引き起こしている
そのエネルギーは地表の水だけでなく
地球中心と月中心間の距離の二乗に反比例し
互いの中心に絶えずエネルギーが発生していると考える
同じ事が地球と太陽でも起こり
金星と太陽でも起こっていると考える
金星の表面には太陽の熱エネルギーと金星の内部に溜まり続ける熱エネルギーによって絶えず嵐が吹き荒れている
太陽の吹き出す熱エネルギーも重力も断然金星の方が強い
2024年7月11日木曜日
GoによるJSONのパースについて
Go言語には、JSONのパースをする際に構造体が必要になるライブラリしかなかった
社員から、その点について質問があり
構造体のように枠が決まっていないと
セキュリティ上の問題になりやすいと言うことを説明した
パースする相手がXMLでも同じ状況だった
そこでわたしは以前、任意のXMLをパースして、汎用的な構造体を使ったメモリーマップに保存することにした
そして、そのマップからJSONを作り出すこともやった
その構造体メモリーマップにパースする事は、XMLでも出来たので、JSONにも対応可能だ
というか、JSONのが簡単だろう
それで最近の状況はどうなのか調べてみると、メルカリの技術者がJSONのパースについてライブラリを作っていたのを見つけた
gitの中身は見てないが、やり方は同じなんだろうと思ってる
わたしは以前自分が作ったものに少し不満があった
その不満を突き詰めるとXML Databaseになってしまうのもわかった
MongoDBのSQLite版的な位置付けの物で、内部データはXMLと言うものになり、XQueryを処理する形でデータを抜き出すと言う簡易データベースだ
こいつがかなり厄介で
XQueryの実装に難儀している
モチベも続かない
しかし、今回社員からマイクロサービスの用途でJSONのパースの話を聞かされて、以前作った物がそのまま使えそうなことに気がついた
冒頭で書いたJSONのパースについては、JavaScriptでフロントからのリクエストがあった時に、通信内容はJSONにした方がいいと意見した流れだったのだけど、XML HttpRequestならそのまま使える
JSONをパースする部分を作れば、相互変換もできる
さらに、ファイルシリアライズを実装すれば、あとはXQueryの実装にも使えるようになる
頭の中であれこれスッキリ繋がった気持ちになっている
やはり一人で考えているより、人と話している方が捗る
2024年7月9日火曜日
Unityのデータ指向には賛成(と言うかゲームはそういう作りにするべき)
https://game-ace.com/blog/unity-dots-system/
わたしが作っているゲームエンジンはデータ指向でありオブジェクト指向なのだけど、Unityはオブジェクト指向が嫌いなようだ
両者は対立するものではない
オブジェクトがデータに沿って動けば良いだけの話だ
わたしはGo言語もやっているので、モジュール指向で作ることには抵抗が無いし、オブジェクト指向に凝り固まったJavaは嫌いで仕方ない
Goの作者がC++はなんか違うと思い続けてGoが作られたのも納得している
確かにクソコードの作者はクソなクラスを山のように作り出す
それ、なんのため?
意味わからん
遅いだけじゃん!
ずーーーーっとそう思い続けていた
繰り返しになるがオブジェクト指向がクソになるのはクソコーダーの所為なのだ
クソコーダーはアセンブラからやり直せ!
Windowsのクラスがクソなのは間違いない
あのクソ構造なMSお作法のために何人の有能なプログラマがその道を諦めたことか、、、
わたしは全部見て来たが、見ていない人には何もわからないだろう
こうやって歴史は大きな勢力に上塗りされるのだ
ところで、この紹介ページの図
下手すぎ
なんだこのJobが沢山ありますよ的な図は、、、
わたしがUnityを嫌いなのはC#だからだ
C#はJavaが欲しかったMSが苦し紛れに作った言語で、生まれながらにポリシーが無い
C#はクソ真似言語だ
登場当時、C#はC++--(シープラプラマイナスマイナス)と言われていた
C++からオブジェクト指向以外のものを削除した言語という意味だ
こんな古い話、今では知っている人も居ないだろう
とにかく面白く無い言語で、ゲームに向いているとは思えない
あんなもんやるならSwiftやGoの方が何倍も素晴らしい
2024年7月5日金曜日
2024年7月4日木曜日
2024年7月2日火曜日
庭の手入れ
庭の一角を畑のようにしていたのだけど
管理できない
雨が降った後ぐちゃぐちゃになる
実は最近フェルトの鉢を多用している
この鉢はとても水捌けがよく
保肥力が強い土を用意すればかなり手間を無くせる
そのフェルト鉢の方を見ると
かなり良い土の状態を維持できていて
庭全体これで良いんじゃないのかとさえ思える
雑草も生えないように
防草シートを敷いて
上に砂利でも敷いてしまう方が管理が楽だと考えた
プールシートでも良いかも
フェルト鉢から出ていく水をプールシートに溜め
そこに生物も住まわせて
水の再利用をする
構想はまとまった
あとはやるだけだ
登録:
投稿 (Atom)
-
https://social.msdn.microsoft.com/Forums/vstudio/en-US/f0502813-9c4f-4b45-bab8-91f98971e407/popup-popupstaysopen-togglebutton-and-data-bindi...
-
どうも書かなくてはならないネタが出来てしまった。 マルチスレッドには欠かせないSleep(0)についてだ。 自分はSleep(0)を多用していた。 MSDNの記述 によると 「中断時間として 0ms を指定してこの関数を呼び出すと、現在のスレッドは自らに割り当てられている...