新たにフォークに手繰り寄せられるスパゲティが無くなった（巻ききった）所からさらに回転させてるかどうかで、フォークだと食べにくいよ派とフォークでおk派が分かれてるんだと思う＞＜
ちゃんと工学的にスパゲティの巻きつき強度（？）を解析する研究ってないのかな？＞＜（イグノーベル賞貰えそう＞＜）
検索しても、スパゲティが落ちにくいフォークの発明とかは出てくるけど、数値的/力学的にスパゲティがなぜちゃんと巻かれると降ってこないのか、あるいは逆にどうなると降ってしまうのかの研究見つからない・・・＞＜
「羽田－伊豆大島 全日空便、６０年の歴史に幕」 News i - TBSの動画ニュースサイト news.tbs.co.jp/newseye/tbs_ne…
軍用だと他の仕組みの高速船が使われ始めたりしてるけど、民生用で比較的小型の物ってジェットフォイル以外の新方式出てきてもよさそうだけど出ない・・・＞＜（開発しても信頼性的にジェットフォイル以上に需要無いんだろうけど・・・＞＜）
民間用のホバークラフトも消滅の危機だし、日本からはホバークラフト航路なくなっちゃったし高速旅客船って難しいのかな・・・＞＜（軍用の高速船ってコストを気にしていられない用途に使われるから成り立つみたいな面があるのかも？＞＜）
高速船と航空機の場合、直感的に航空機の方が旅客一人距離あたりのコスト高そうに感じるけど、実際にはどうなんだろう？＞＜
小笠原のテクノスーパーライナーが石油価格の問題でコケた話も、従来の航路の運賃と比べると論外になるとしても、空港作ってジェット機飛ばすよりは安いんじゃないの感があって謎＞＜；
意味がある計算かよくわからないけど、TSLの問題になったランニングコスト2500万円/1往復で、新種子島空港の総事業費を割り算すると、10年間使えるらしい・・・＞＜ 新石垣空港の総事業費なら19年間＞＜（ランニングコストとイニシャルコストを無理やり比較するのはアレだけど＞＜；）
船と飛行機問題って、ある意味、鉄道と道路の税金の使われ方がおかしいよ問題に近いのかも？＞＜（なぜか鉄道廃線をきっかけとした道路整備費用が、廃止までの鉄道への補助金よりも大幅に大きな額になっても、なぜか問題視されない不思議な状態になる問題＞＜）
『問題視されない問題』って問題なのか・・・？＞＜；（お役所が問題視しなくて、専門家とかがツッコミいれてるという状態といいたかった＞＜；）
@co1924616 オレンジが作った分直すにしても、現状使ってるプラグインどれとどれだかわかんなくなっちゃってる＞＜；（というかいっぱい作りすぎて何があるのかいくつ作ったのか覚えてない＞＜；）
安全の問題らしいから、崖から落として這い上がってきた車両だけ売ってるボルボトラックスの製品群が＞＜
シンプルなコーディングで大容量メモリを使うプログラムを並列に動かせちゃう21世紀・・・＞＜
Parallel.ForEach使ったこと無いけど、スレッド数とかどうなってるんだろう？＞＜（自動的に最適なスレッド数を判断するとかかも？＞＜）
@cuezaku はたらく車的にマニアックな知識的には、はたらく車のお仕事してる人的にはダンプは女性が運転する車らしい＞＜（なぜかというと重いから荒っぽく運転するとすぐ壊れるのでやさしく運転する傾向がある女性ドライバーの方が壊さない＆積み下ろしの肉体労働が無いかららしい＞＜）
Parallel.ForEachでてきとうに無意味に65536このデータを処理する実験コード書いて実行してみたら37スレッドも生成されたんだけどなんだこれ？＞＜；（作りすぎで遅くなるんじゃ？＞＜；）
このコードは密度高いからあんまりスレッド作らないほうがいいとかそういうのはParallelクラスは考慮してくれない？＞＜
c# - How can I limit Parallel.ForEach? - Stack Overflow stackoverflow.com/questions/9290…
16にしたら処理時間長くなったのちょっとだけで軽くなった＞＜（もしかしなくても、ちゃんととにかく早く終わるように監視しながら最適化して動的にスレッド数変えるような感じになってるのかな？＞＜）
スレッド数可変なのかな？＞＜って実験するためにわざと密度下げようと、無意味に排他処理するようにしたら、めちゃくちゃ早くなって、そりゃそうだなんだけどなんだろう・・・＞＜
シングルスレッド版のコードの実行時間と、無意味に排他処理して並列度落としたのの時間がほぼ同じ・・・＞＜
あ＞＜； 密度高いって言っておきながら実際はそうじゃなかった＞＜；（なおしたらちゃんと早くなった＞＜；） あっ＞＜； あっ＞＜；
並列化しない版：11秒くらい Parallel.ForEach版：3.3秒くらい Parallel.ForEach版並列数4指定：3.3秒くらいだけど、平均的には微妙に指定しないよりは早い傾向（でも指定しないほうが早い時もある程度の誤差）
ちゃんと密度を高めれば、Parallel.ForEachを普通に使うんで十分かもという結論＞＜（一方で、密度高めたコードを書いたのかどうなのかが、クラシカルなコードと比べるとわかりにくくて、間違えて遅いコードを書いてしまう危険性が微妙にあるかも＞＜（というか実際間違えた＞＜））
Threadクラス使ってクラシカルに書く方がそういう失敗無い気がするのは、クラシカルに書く時はコードが冗長になるせいで気をつけて書くってだけだろうから、めちゃくちゃ短くなるParallel.ForEach使ったコードの方が、短いコードの方がエラー少ないかもという点でアレだ＞＜
昔だったらめんどくて並列化しなかったような処理をちょこまか気軽に並列化するんであれば、クラシカルに書く意味無いかもで、一方、もっと大規模なコードが並列化される状態であれば、クラシカルに自分でスレッド作る感じに書く方がいいのかも＞＜
洋楽の古いロックだとマスターがアナログなおかげでちゃんと高域まであるという逆転現象が・・・＞＜（だからといって音質がいいとかそういうことじゃないけどでもデータは残ってるという＞＜）
ハイレゾ音源って、16bitでちゃんとマスタリング出来ない馬鹿が、量子化bit数が増えたら余裕があるように感じてクリッピングさせずにマスタリングするという改善の為にあるような気がしなくも無い＞＜（単にCDでのマスタリングが不良品なだけという＞＜）
24bitなハイレゾ配信で0xffffffと0x000000が長く並ぶデータを作る馬鹿がきっとそのうち現れる・・・＞＜
@cuezaku スタジオモニタヘッドホンの方がスペック上はハイレゾというか超音波を正しく再生する能力がある気が・・・＞＜（だからといって音がいいとかではないだろうけど＞＜；（ていうか超音波だし＞＜；））
@cuezaku ていうかDACに関しては、いまどきは、オンボのカニさんもハイレゾだよね・・・＞＜（ていうかハイレゾ配信とか始まる前からカニさんはハイレゾだった＞＜（実際に信号として出てるかすらしらないけど＞＜；））
