論理明日から人体モデリング入門します
ちなみにイラストは全くかけないので三面図は無しです
論理明日から人体モデリング入門します
ちなみにイラストは全くかけないので三面図は無しです
ちょうど実装中のライブラリと、それを使って実装する予定のライブラリと、それを使って作る予定のアプリケーションがあるので……
デジタルというのは数値 (digit) 化されているということ。
我々が扱いやすい性質の数値というのは、たとえば整数にしろ浮動小数点数にしろ、離散的で、精度に限りがあり、そしてほぼ直列である。
さて現実の物理的な情報というのは視点次第で多様な構造を持っているので、我々はその構造の中から残すものを選択して規約を作り、直列の中に押し込めねばならない
たとえばモナ・リザの絵の表面を、分解能が分子サイズの高精度なスキャナでスキャンして画像化したとしましょう。
この時点で我々は「絵の表面の色の配置を記憶し、残りは無視する」という取捨選択を行っている。
となると、後から「どうやら絵の下に別の絵が描かれていたが、塗りつぶされてモナ・リザが描かれたらしい」とか「今見るとこんな色だが、分子の状態を考慮すると昔は別の色に見えていたらしい」とかの情報は失われる
物理的な世界そのものはとにかく情報量が多く複雑なので、我々が何らかの目的を達するためには、人間や技術が扱える程度に情報量を減らして単純化しないといけない。
それをデジタル化の限界と言うなら、まあそうですねという感じはある
で、情報を記号化する時点で劣化が起きるのはそうなんだけど、そもそも人間も情報処理装置であるゆえ記号化による劣化からは逃れられないわけで。
人間が知覚不可能な特定の情報を残す意義があるのかというのを論じずに「劣化する!」と主張するのはちょっとアンフェアなわけですね
たとえば原子レベルでモナ・リザのイラスト複製しようというとき、元のイラストを構成する個々の陽子が誕生してから今まで過ごしてきた主観時間という情報は失われるけど。
その情報が本当に失って惜しい情報なのかというと、おそらくそんなことはないし、どうせ元のイラストを保存しても陽子は少しずつ崩壊していくわけで
このアカウントは、notestockで公開設定になっていません。
それはハイレゾとかでも言われてるけど、単に「情報を応用できる可能性がある」ということは「人間が感覚器や理性で情報を堪能できる」とは別の話なので
ハイレゾが不完全だと言いたいときに主張すべきなのは「マイクを通した時点で特性が完全には再現できなくなってるし、スピーカーを通すと更に歪むじゃん」であって「いつか人間が200kHzの音を感じ取れるようになるかもしれないじゃん」ではないという話です
デジタル化の致命的な欠点として前者を挙げるべきで、ただ、これはアナログについても似たようなことがいえる
たとえば「フィルム写真は解像度が分子レベルなのでデジタルより精細」みたいな話があって、まあたしかにそうかもしれないけど。
レンズで光が歪み、フィルムの表面の形状で映像が歪み、フィルムの劣化で映像が変化し、現像でまたノイズが入るし制度もどこまで高いやら、そんな状況で本当に「分子レベルの解像度」に価値があるのか、というところを問わないといけないのでは
私が言いたいのは、原点が重要である理由は「精度が無限に高いから」ではなく「情報の取捨選択が行われない状態だから」なのではないかという話です
精度が高くても劣化するものは劣化するし、劣化した瞬間に無限の精度は意味を持たなくなるだろうし。
「アナログだから良い」のではなく「状態を取捨選択しないから良い」で考えるのであれば、たとえばフィルム写真は「アナログだが状態を取捨選択した後のものなので、デジタル化した方が真に優れた記録になる」という主張もできるのでは、と
フィルム写真は既に「フィルムの特定の場所にどのような光がどれだけの強さで入ってきたか」という情報だけを残した媒体なので、それをデジタル化したところで失う情報はほとんどないわけです (フィルムの劣化具合とかも、まあ技術的には読み取れるだろうし、読み取れさえすればデジタル化して保存できる)
まあそういう意味で「デジタル」の弱点というよりも「デジタル化」の弱点があるというのは間違いなくて、同様に「アナログ化」(正確には「アナログ記録媒体への情報転写」) にも同様の弱点を想定しなければならない。
その「化」がないのは良好な状態で保存された原典ただひとつだけだし、原典の価値はアナログデジタル云々ではなく、その「化」がないところにある、とそういう話でした
端的に言えば「現実を完全には符号化できない」の一文で済む。デジタルかアナログかは問題ではない。
結局、現実的には「どこかでコストをかけて原典を管理して、ユーザは適宜必要な観点で符号化されたクリーンな情報を使う」というスタイルが効果的なのよね。
たとえば巻物の原典を博物館に置いておく。
文字情報で欲しい人も、スキャンした画像がほしい人も、放射線年代測定の結果がほしい人も、X線スキャンした結果がほしい人も、インクの分子組成がほしい人もいるかもしれない。
そういう人たちは、博物館に依頼して適宜自分たちが必要とする形に「符号化」をする。
ユーザにとってみれば本当に大事なのは「適切に符号化した情報を、ニーズが発生した後で得ることができる」という点であって、そして予測不可能なあらゆるニーズに対応するには原典を良好に保管しなければならない。
最近、なんかのマシンでアップグレードを掛けてから/etc/sudoersを編集しようとvisudoしたらパーミッションがないって言われるようになった。/etc/sudoers.d/をいじれってことなんだろうけど、過去に/etc/sudoersに入れた編集が戻せなくなって、これは辛い。
リスク許容するなら /etc/sudoers をエディタで開いて手編集。編集中の事故を避けたいなら USB boot とかして / をマウントして /etc/sudoers を開いて手編集、とかかなあ。
visudo って編集するファイルを指定できたはずなので、 USB boot したうえで visudo で編集するのが一番安全そう
visudo(8)、ロック取るのと直接 open しないのと syntax checker が走るのがポイントっぽいので、一人環境ならロックはわりとどうでもいいし、syntax check もまあ他のなんらかで代替できそうではある
visudo 以外の syntax check 手段を知らないけど、まあ確かに USB boot なら後からまとめてチェックできればそれでも良いか
ポヨグヤマとしては「visudo が終了した時点でファイルが妥当な状態であると保証される」という性質は大変ありがたいものだし迂回すべきでないと思うけど、十分にドジでない人間にとってはそうでない可能性はある……
こいつのせいで movable な型が即座の破棄を要求されないか或いは実質 empty 状態を持つことが要求されていてつらい
std::string くらいなら、まあ即座の破棄を遅延してもメモリがちょっと余計に長く使われるくらいだけど (それも嫌なら空文字列にして切り詰めればいいけど)、もっと貴重なハードウェア関係のリソースの抽象化とかどう足掻いても「リソース保持してません状態」を許容しないと movable にならないやんけ
まあ optional が 14 でやっと入ったという時点でその辺りの甘さはお察しみたいなところがある
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
パイプとか通されとき /dev/stdin と fd=0 に違いが出るのかとかはよく知らん
シェルスクリプトで標準入出力が端末なのかパイプなのかリダイレクトなのかを判定するには | hydroculのメモ
https://hydrocul.github.io/wiki/blog/2016/1012-is-pipe-or-terminal.html
パイプ入力だと /dev/stdin もパイプになるのか、へぇ
no tty かつ pipe 経由でない環境の可能性はあるし、それは直交する話では?
このアカウントは、notestockで公開設定になっていません。
・シェルから起動された場合オープン済みの fd=0,1,2 を引き継ぐ
・/dev/fd/{0,1,2} のエイリアスとして /dev/std{in,out,err} が存在する
ということがわかった
IQ1でもわかる決算周り入門 - タイトルって難しい。
http://can.hatenadiary.com/entry/2017/12/14/221211
この std某 を引き継ぐという挙動は exec で fd が引き継がれるという仕様がないとできないわけだけど普段コード書いててそんなの意識しないんだよな
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
relax | Origin and meaning of relax by Online Etymology Dictionary
https://www.etymonline.com/word/relax
不揃いの連理 第一話|コミックNewtype
https://comic.webnewtype.com/contents/fuzoroi/10/
いいぞ (書籍も3巻まで出てる)
図書館の本、紙のコピーだけでなく「ネットにも送信」…出版界への波紋 https://www.yomiuri.co.jp/culture/20201120-OYT1T50123/
書籍版カスラックでも作るつもりか?頭おかしいんじゃねえのか
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
GC 書いたことないしメモリアロケータも bump allocator しか書いたことないので、メモリ管理できません
そうだよな、ろくすっぽ malloc も実装したことのないトーシロがプログラマ名乗れないよな、深く反省した
OS もブラウザもコンパイラも malloc も GC も実装したことがない、私には何もない……
このアカウントは、notestockで公開設定になっていません。
HotSpotがある程度よしなにGCしてくれるから困ってなかった人たちが突然DalvikのゴミカスGCに翻弄された日々〜
ヒープのない世界で思い出した、 CASIO のプログラマブル関数電卓は Z だけ可変長の配列だったのでそこをヒープやらコールスタック代わりに使って……
ブロック崩しを作ろうとしていた (ブロックの管理が面倒すぎてボールをパッドで弾くところまで実装して投げ捨てた)
このアカウントは、notestockで公開設定になっていません。
/usr が user でないとか100万回くらい言われてそうだけど (user であるとも言われてそうだけど)
/usr ‐ 通信用語の基礎知識
https://www.wdic.org/w/TECH//usr
> 一応、「USeR」の略ではなく、User Service RoutineやUser System Resourceなどの略だとされてはいる。しかしこの話はどうやら後から作られたものであるらしく、最初からそのような意味を持たせていたわけではないようで、やはりuserがusrになったとする説が有力らしい。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Rust の Vec<T> 、ヒープにあるというのと可変長というのが特徴で、逆にそれらの特徴を必要としない操作 (探索、並べ替え、要素アクセスなどなど) は全部 Deref 経由で &[T] の操作を使うことになっているので、それを知っていると覚えることが減って楽になれる
&Vec<T> からイテレータを作ると &[T] から作るイテレータ (std::slice::Iter<'_, T>) が返されるとか
https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-Index%3CI%3E
一応 Index trait とかは Vec<T> そのものに対して定義されている (中身はリダイレクトされてるけど) ので、微妙に嘘吐いてる気がしてきた……
まあそれを言ったら std::slice::Iter を返す &Vec<T> のイテレータも IntoIterator for &Vec<T> で実装されてるので、 trait というのはそういうものなんだけど……
ここで「アクセス」で想定していたのは vec.get(i) とかですね (Vec::<T>::get は存在しなくて deref 経由で <&[T]>::get が利用される)
Coercions - The Rustonomicon
https://doc.rust-lang.org/nomicon/coercions.html
trait を Deref 任せにしないのは、 deref coercion が trait bound で型をマッチする場合に利用されないからという理由がある (はず)
Compile Times - The Rust Performance Book
https://nnethercote.github.io/perf-book/compile-times.html#linking
ローカルで Rust をビルドするだけなら、 ~/.cargo/config に
[target.x86_64-unknown-linux-gnu]
rustflags = ["-Clink-arg=-fuse-ld=lld"]
みたいなのを入れとくといいです (リンクが速くなる)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
WALKMAN を使うなら ID3v2.3 だけを使ってください、2.4 とか APE タグとかを使ってはいけない
「聞けよお前!」「家帰るど!」ひろゆき氏 GoTo見直し問題で意見相違の専門家を激怒させる(東スポWeb) - Yahoo!ニュース
https://news.yahoo.co.jp/articles/a2cae5767f58dc2c72609a3cb55f7195eb272d00
ひろゆきが話題になってるの、これか…… (お相手は可哀想ではあるが、耐性がなかったなら打倒な結末ではあるだろうね)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
10万円の給付金で PC or ディスプレイ or エヨゲ or ヘッドンホホ or WALKMAN が買えることを知っていたんだけど、古典論理しかわからないので全部買えた #直観主義論理は直観的
ちなみに直観主義論理はここでは全然関係なくて、アフィン論理です (どうでもいい (ほんまか))
任意のことがらに #直観主義論理は直観的 タグを付けることができる、なぜなら #直観主義論理は直観的 は完結した主張であり文脈と独立に主張することができるので #適当
Rust の async で複数の future を同時に駆動するには、 join 的な何かをしないといけないのではという気がする (あるいはランタイムのキューに突っ込むとか)
そういえば無線マウスであるところの ELECOM の EX-G (M-XGL20DL) の Fn1〜Fn3 ボタンが Linux で使えないんですが、これもしかすると同じメーカーの DEFT 用のドライバを流用できるのでは? つってる (パッチ読んでる)
cpetrov/deft: A Linux loadable kernel module for the Elecom DEFT series finger operated trackballs (M-DT1DRBK, M-DT2DRBK, M-DT1URBK, M-DT2URBK)
https://github.com/cpetrov/deft
4.12 からはもう main tree に入ってるんだけど、たぶん分離されたパッチの方が読むべき場所がわかりやすいので
こうして軽率にカーネルを弄って起動してみることができるのが Gentoo Linux のいいところなんですね〜
このアカウントは、notestockで公開設定になっていません。
本当にマズかったら郵送で通知くるだろうし、そっちチェックしとけば大丈夫でしょ (しらんけど)
このアカウントは、notestockで公開設定になっていません。
回らないトイレに行ける富豪じゃん
私は貧乏人なので回るトイレしか使ったことない (???)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ELECOM DEFT and the broken descriptor – Flameeyes's Weblog
https://flameeyes.blog/2017/04/24/elecom-deft-and-the-broken-descriptor/
読んでる
このアカウントは、notestockで公開設定になっていません。
リソース破棄のために (C++ でいうところの destructor を適切な順序で漏れなく呼び出すために) ブロックからの脱出で goto を使うみたいな例はよくあるね (個人的には無限にリソース破棄の関数呼び出しを複製するより goto 使った方がよほどマトモなコードだと思うけど)
https://fedibird.com/@atsushi015/105247902643700497
try-catch がある言語に dtor がないわけないでしょ!!!!!!
C言語の話なのは言うまでもないと思っていた (C か C++ 以外で合法的に goto を使える言語の方が逆に珍しいのでは)
hid_elecom がアンロードできないので再起動することになるの、仕方ないけど面倒だ
Linux 5.8.18 用の、 ELECOM EX-G (M-XGL20DLBK) の Fn1〜Fn3 ボタンを使えるようにするパッチ
https://gist.github.com/lo48576/4144f4e536b01db4304f1f7bde451b0a
とりあえず動くっぽいのでアッピヨードします、 ELECOM の無線マウス EX-G (M-XGL20DL) をお持ちの方は、今まで死んでいた Fn1〜Fn3 ボタンをご活用ください
ELECOM DEFT and the broken descriptor – Flameeyes's Weblog
https://flameeyes.blog/2017/04/24/elecom-deft-and-the-broken-descriptor/
この記事が有用すぎて拝んでいる
https://mastodon.cardina1.red/@lo48576/105248100617626004
で、次のステップはこれを linux のアップストリームに取り込んでもらうところなんだけど……そっちは全く経験ないのでまずはどこにどう投げるのか調べるところから始めないといけない…… (そもそもパッチの作りも雑だし)
Submitting Your First Patch to the Linux kernel and Responding to Feedback - Nick Desaulniers
http://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/
参考になる
このアカウントは、notestockで公開設定になっていません。