新しいものを表示

アメリカ西部の砂漠というか乾燥地帯(の北の方)が冬になるとどうなるかわかりやすいかもしれない動画><

"BigRigTravels - US Highway 95 through Jordan Valley, Oregon recorded January 5, 2022" を YouTube で見る youtu.be/TbZ5sdbJCUw
ネバダ州ラスベガスとかモハベ砂漠とかもある超巨大乾燥地域(グレートベースン)の北端付近><(オレゴン州南部)

ピザ自作して以降では初めて冷凍食品のピザ(セブンイレブンのやつ)を食べて見たけど、オレンジ方式自作ミニマム構成クリスピーピザは生地が小麦の香ばしい風味が強いけど、冷凍ピザは生地が(意図的に?)完全に脇役というか裏方で風味が弱く、圧倒的に自作ピザの方が美味しいという結論に><

twitter.com/VessOnSecurity/sta

誰だか知らないけど逆の意味で同意というか、オレンジは昔から「アップデートすれば壊れるし、IT界隈はいままでもこれからもアップデートで壊した事に関して有償でも無償でも一般に全く責任を取らないので、アップデートしないほうがよい><」と言ってる><

スレッドを表示

さっき おささんが考えてたような極端に非対称なデータ容量の通信で擬似的に逆転させるやつ、もしかしたら軍用とか宇宙探査用途ではそういうの発明されてるような気がする><
軍用ならば、孤立してて隠密中であんまり電波発信したくない所との通信に使うとか、宇宙探査用途ならば、地球側の大容量送信に対して探査機側の貧弱で容量が少ない送信のアンバランスをどうにか改善するのに使うとか・・・><

orange さんがブースト

> This behavior can be customized, but it is complicated by ambiguities in recognizing numbers within strings (because they may be formatted according to different language conventions). Once each number is recognized, it can be preprocessed to convert it into a format that allows for correct numeric sorting, such as a textual version of the IEEE numeric format.
そっすよねー

スレッドを表示
orange さんがブースト

unicode.org/reports/tr10/
> Phonetic sorting of Han characters requires use of either a lookup dictionary of words or, more typically, special construction of programs or databases to maintain an associated phonetic spelling for the words in the text.
茨の道…

漢数字を完璧にソート出来るエンジンというか、日本で日常的に使われてるあらゆる表記の漢数字を数値に正しく変換するってかなり困難なのでは感><

でももし実際に数字用と汎用で符号位置わけたとして、例えば地名のn丁目は、「一丁目」という地名であり 数字+「丁目」ではない問題があるので、どっちで書けばいいのか難しくなって、「なんでhoge丁目はソート失敗するの!?」って混乱が起きたり、「『八丁堀四丁目』ってどれが数字!?」みたいな大混乱が・・・><;

orange さんがブースト

一 U+4E00
二 U+4E8C
三 U+4E09
四 U+56DB
五 U+4E94
六 U+516D
七 U+4E03
八 U+516B
九 U+4E5D

これだからメリケン人が決めた規格は…!!!!!

たぶん、漢字使わない文化圏の人から漢数字を見たら「ローマ数字のIと普通のIは別の符号位置なんだから、数字の一とそうじゃない一も別の符号位置にしやがれデース」って思ってるかもしれない><(思ってないかもしれない)

そもそも、漢数字以外の数字の体系で、数字としての用途に限らず数字を使う(例えば単語中の文字として使う)文化圏な単独の文字コードが割り当てられた「数字 かつ 文字」って、漢数字以外にもあるんだろうか・・・?><

orange さんがブースト

x音声データやの
o音声データの
(画像のってつけようとしたけど、画像では通常の手段より圧縮出来ない気がしてきてカットしたら「や」が残ってた><;)

スレッドを表示

実用上は意味無さそうだけど、音声データやの非リアルタイムな受信であれば、相互にいい感じのアルゴリズムで予想して、クライアント側では予想するデータを多数投げて(上り大容量)、サーバー側では一番近いものがどれであったか応答する(下り小容量)方式で絞りこんでく方式でもそこそこ圧縮できそうな気がする><

逆で、超巨大辞書をクライアント側に持たせてサーバーに応答してもらう事で仮想的に『大容量アップロード』を『大容量ダウンロード』かのように使うみたいな意味だと、圧縮の実用上たぶん無理があるし、実用化されてる方式で言うとVQ圧縮に近いものになる?><;

ということはオレンジが書いてる時分割カタログ方式も一応(実用性は謎だけど)、「1バイトのリクエストで巨大なカタログから巨大なひとつのデータを選び送ってもらう」って出来るので、一応クリアしてるっぽい?><;

orange さんがブースト

アップロードが無料の時、どういう方法をとればダウンロードするデータが予想できて、通信料を削減できるか、という問いだった。

古いものを表示
:realtek:

思考の /dev/null