超大昔に一番最初にメガネ作った時以降、眼科行ってない><;(何度か作り直したときはメガネ屋さんで測った><;)
超大昔に一番最初にメガネ作った時以降、眼科行ってない><;(何度か作り直したときはメガネ屋さんで測った><;)
もしかして
近視→メガネ作った→「近視が進んでメガネ弱い><;」
じゃなく
近視→メガネ作った→乱視も追加された
だった説?><;
メガネ無しだと完全に花火で、メガネかけると花火度が減るけど、メガネ作ってから度が進んで完全にあったメガネでは無いので完全には矯正されてない><;
このアカウントは、notestockで公開設定になっていません。
近視で高コントラストで見えなくなるの、文字で表示でどうなるかを言葉で説明するの難しいけど、光点がどうなるかはわかりやすいかも><
電子機器とかのLEDインジケータとかが全部、点ではなく花火🎆みたいに見える><
なので、点で文字を書く代わりに花火のスタンプで文字を書けば、近視でよく見えない人の気分を味わえるかも><
薄い灰色とかベージュとかなら、黒背景だとわかんなくなる謎現象を避けつつ、近視で高コントラストで文字読むの困難現象も避けられる><;
テキストエディタは白背景にする事多いけど><;
((視力の問題とは別で)白じゃないとなに書いてるんだかわけわかんなくなる不思議><;)
ダークモードというか黒背景or白背景の現状、近視(の中でさらに人による)で高コントラストだとマジで文字読めない人には、好み云々じゃなくマジで実用高困るので、昔はわりとよくあったこういう灰色背景も用意してほしい><
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
結論><
PC用でC# で書く時でよほどメモリケチらなきゃならない場面じゃない場合には普通に書こう><;
最適化ありだと『普通っぽいけど参照渡しでstaticなやつ』が『bitツメツメなやつ』よりも速くなるっぽい><
C# でもビット弄る方でやった時にパフォーマンスどの程度変わるのかさっきのやつで試してみたけど、1億回試行で最適化なしビルドで、
bitツメツメのやつ: 約1650ms
C# の標準的なコード: 約1520ms
bitツメツメの解説用の無駄があったコード: 約2100ms
C# でわりと普通っぽいけどオブジェクトに値を持たせずに参照渡しでstaticなやつ: 約1720ms
だった><
こういう風にbitつめつめな事する時にも、より安全な設計ってある事はあるんだねって目からうろこ感><
そこまで意図してフォーマットを決めたわけじゃないけど、結果的にbitの割り当てのフォーマットが最も安全な形に偶然になってたっぽい><;
これ、ビットあふれ想定してない部分でアレで「じゃあ想定してない初期値である0サイクルを指定したらどうなるんだろ?><;」と思って実際に動かしてみたら、カウンタのあふれる先がLEDの状態フラグなので結果的に
「桁があふれたらLEDを消す命令を出す」になってつまり「128回に一回LEDをとにかく消そうとするプログラム」として動作するっぽい><
「こういう機能があったらいいのに・・・><」と思って、「まさかね><;」ってやってみたら既にその機能あったのに知らなかっただけという><;
さっきはがんばって電卓を2進モードにして打ち込んで16進モードに切り替えて、なるほど・・・2進モードにして、また入力して・・・って繰り返してた><;
Visual Studioに超便利な機能がある事いまさら発見した!><;
これ知ってたらビットマスクを電卓でがんばって16進変換する作業しないで済んだのに!><;
「1個じゃなく4個じゃん! 増えてるじゃん!?」ってツッコミがあるかもなので、解説向けの冗長な部分をカットしたバージョンも><;
あと、なにしてるか読みやすくするためと手っ取り早く書くために「一回分解して・・・」ってかきかたしてるけど、ほんとはそんなことしなくていい><
使い方の部分でforループで50回してるのは無限ループするのムカつくからであって(?)、普通にずっと点滅させるのであれば無限ループでおk><;(一応補足)
さっきの話題のLED点滅ライブラリのやつの変数1個だけ版の、しかもちゃんとマイコンプログラミングを想定してるやつをC# で書いたから褒めて!><;
ADS-B(MODE-S)のTC-29のデコーダが作れれば、それをしゃべってる飛行機(かなり最近の旅客機)のコクピットの状態(具体的にどう操縦してるのか)がリアルタイムにわかっておもしろいと思うんだけど、デコーダ作って配ってる人が少なくとも当時は居なかったし、ちゃんとした規格は規格書高くて読めないし・・・><
bit詰めまくりな上にバイトの境界またいでてめんどくさい事を嘆いてるツイート><;
"ADS-Bのコクピットの状態をブロードキャストするフレーム(TC29)のデコーダ作る為にフォーマットを書き出したけど、何でこんなぐちゃぐちゃなフォーマットなのか・・・><" https://t.co/kxCNa0DvNK https://twitter.com/orange_in_space/status/697037977537503232?s=20
orangeさん(@orange_in_space)のツイート orange(@orange_in_space)さんがツイートしました: 自作ADS-Bデコーダ><>< https://t.co/eGRsncbB1k https://twitter.com/orange_in_space/status/694837414062231552?s=20
bit詰め込みフォーマットのプログラミングで、詰め込みすぎててめんどくさかったけどその分面白かったのが、ADS-Bデコーダ自作><
あと、この文脈上の変数の1個2個って数え方謎で、signedな変数の正負を流用して減らすと一個減るのを減らしたそれはそうだけど、
じゃあ、例えば必要な変数がすべて16bitの範囲で収まるのであれば、16bitの変数一個をbit切り分けて使えば1個で済む訳だし、レギュレーション(?><;)が難しい・・・><
オレンジもビットいじくって詰め込むの大好きで、そのせいで珍妙なフォーマット作っちゃってあとでこんがらがるとかある><;
このアカウントは、notestockで公開設定になっていません。
<?php
$cnt = 1;
$max = 5;
while(true) {
if ($cnt > 0) {
printf("点灯:%d\n", $cnt);
$cnt += 1;
}
else {
printf("消灯:%d\n", $cnt);
$cnt -= 1;
}
if (abs($cnt) > $max) {
$cnt = $cnt / abs($cnt) * -1;
}
sleep(1);
}
このアカウントは、notestockで公開設定になっていません。
あわせて読みたい><
DD54 (でぃーでぃーごじゅうよん)とは【ピクシブ百科事典】 https://dic.pixiv.net/a/DD54
JR東海 在来線に新型車2種 杉山車両部長インタビュー「リスク排除、安全追求」 :中日新聞Web https://www.chunichi.co.jp/article/261272
少なくともその部分は完璧に正しい記事だと思うけど><
"推進軸はこれまで車両の下部でむき出しのまま回転していた部品。落下するリスクがあり、安全性能上の課題となっていたが、HC85系では、モーターが車輪を直接回すため不要になる。
杉山部長は「リスクをゼロにするためにメンテナンスするが、推進軸がなくなれば落下のリスク自体を完全に排除できる」と利点を強調する。"
このアカウントは、notestockで公開設定になっていません。
これ低い方から3県って紅白送電鉄塔すらないのかも?><; って思ったけど、そもそも送電鉄塔は調べてないランキング?><
"【タワー】47都道府県別「最も高い建造物」ランキング【電波塔】" を YouTube で見る https://youtu.be/_uLLXOYffTo