Computer Algorithm and Information Technology
Reload
投稿者
メール
題名
内容
<OBJECT>タグが利用可能です。
(詳細)
URL
[
ケータイで使う
] [
BBSティッカー
] [
書込み通知
] [
teacup.コミュニティ
]
投稿募集! スレッド一覧
スレッド作成
他のスレッドを探す
[PR]
社員求人
食事券
愛媛の求人・転職
ファストフード店大阪府
GMO SEO
[
teacup.
] [
無料掲示板
] [
プレミアム掲示板
] [
teacup.コミュニティ
] [
ブログ
] [
チャット
]
【From teacup.】この掲示板は投稿が一定期間無いため、各記事中に広告を表示しています。
全73件の内、新着の記事から10件ずつ表示します。
1
2
3
4
5
6
7
8
|
《前のページ
|
次のページ》
後でまとめてやる
投稿者:
和
投稿日:2004年12月 5日(日)10時47分15秒
あとでまとめてやる、というのはいい考えかもしれません。
RDBMSを実装するときにトランザクションの多いときはインデックスは平衡でない2分木でつくり、CPUの空いているときに平衡させる。
あらかじめ追加されるデータ数がわかっていたら追加データのみソートしてマージするとか。
今のRDBMSはそれぐらいやっていそうですがね。複雑化しますがSTLなどのライブラリでもあるといいですね。
そうですねぇ。
投稿者:
DO++
投稿日:2004年11月24日(水)13時09分36秒
>地図は静的なので動的な追加、削除は必要ありませんね!アホでした。
>それとは別に知的好奇心として追加削除も興味は相変わらずありますが。
最近だと計算機資源がよほどのことじゃないかぎり潤沢なので大抵のものは静的にがりがりやってしまったほうがよいのでしょう。
googleのファイルシステムも追加には強いけど削除はすごく大変なシステムらしいですよ。追加削除もまとめてやると平均してよいということになる考え方もありますよね
編集済
あ、
投稿者:
和
投稿日:2004年11月22日(月)20時49分15秒
そうでした!地図は静的なので動的な追加、削除は必要ありませんね!アホでした。
それとは別に知的好奇心として追加削除も興味は相変わらずありますが。
なるほど
投稿者:
DO++
投稿日:2004年11月22日(月)16時34分12秒
SkipListを二次元に拡張すると途端にうまくいかなくなるのですか・・
>なんでR-Treeが気になるかというと最近国土地理院の地図のベクトルデータを手に入れたのでちょっとナビのようなプログラムを作りたいと思ったからなのです
そのようなデータだと、追加とか削除がないように思えるのですが、そうではないのですか。もし静的ならバランスをとるのはできそうですけど、、
ランダマイズツリー
投稿者:
和
投稿日:2004年11月19日(金)00時14分11秒
本来はR-Treeのバランスを簡単に取りたかったんです。まずは通常の1次元のツリーからやってみようかなと思いました。工夫により何とか通常のツリーと同じポインタ数で出来そう(まだ出来てない)ですが結構複雑になってしまいます。赤黒木と比べても重そうな予感。色を保持する領域がない分多少容量が少なくて済むかもしれませんがそこまではメリットなさそう。逆に赤黒木のアルゴリズムが良く理解できて来たのでこれをR-Treeに何とか生かせないか考えてみます。
なんでR-Treeが気になるかというと最近国土地理院の地図のベクトルデータを手に入れたのでちょっとナビのようなプログラムを作りたいと思ったからなのです。
Re:ランダマイズ版のツリー
投稿者:
DO++
投稿日:2004年11月15日(月)14時25分42秒
>これってノードがもつポインタがかなり多くなると思うのですが実装の仕方で通常のツリー並に減らすことが出来ないでしょうか?
ポインタの個数を動的に変えても、だめでしょうか
>でもこの程度だったら元々の確率表のサイズが小さいのでたいした差はでませんでした。>これをオーダ2に何とか適用できればいいんですが確率は正規分布のようにきれいにはな
>りません。これを解決できれば革命なのですが
音声の生成源のどのようにモデル化すればよいかを考えてみると、理想的なモデル化は一種のMIDIみたいな形で表現できればいいですよね。それで誤差だけを正規分布なりポアソン分布みたいので予測して符号化すればよさそうですし。
MIDIの音源のモデル(声も含めて)もユニバーサルにできたらおもしろいでしょうけど
ランダマイズ版のツリー
投稿者:
和
投稿日:2004年11月14日(日)18時21分35秒
実装しようとしてて疑問に思ったことがあります。
これってノードがもつポインタがかなり多くなると思うのですが実装の仕方で通常のツリー並に減らすことが出来ないでしょうか?
僕は音声版のStaticPPMでオーダ0の頻度は対数であらわすとほぼ正規分布になるようなのでそれは数式で表し値の上限、下限、0近辺あたりは例外的な値になるのでそれは別途用意します。オーダ1は前回出現した値から「歪度」をうまく計算することで確率表を用意することなく計算で確率を求めることが出来るようです。
でもこの程度だったら元々の確率表のサイズが小さいのでたいした差はでませんでした。これをオーダ2に何とか適用できればいいんですが確率は正規分布のようにきれいにはなりません。これを解決できれば革命なのですが。
Static PPM
投稿者:
DO++
投稿日:2004年11月14日(日)03時14分14秒
を実装したものを置いたのでみてみてください。
http://homepage3.nifty.com/DO/sp.htm
無圧縮オーディオ
投稿者:
DO++
投稿日:2004年10月18日(月)18時00分41秒
そのうち、また無圧縮画像、無圧縮映像なども再燃するのでしょうか。しそう。
>ロスレスオーディオで今熱いものらしいです。猿音に比べて非常に速いのが特徴でFLACよりは圧縮率が高く、猿音よりは低いらしいです。アルゴリズムは恐らく上位の大雑把なビットはLZ系で下位はそのまま出力しているらしいです。猿音は上位はRangeCoderで下位はそのまま出力しているような気がします。
まだまだ進歩しますね。
音楽ファイルとかはサイズが大きいから圧縮速度とかも重要になってくるのでしょうね。携帯用には、処理量はバッテリーの持ちとか、使うハードウェアとかの制約に処理量がきいてきますし。携帯用の動画圧縮とかもありますね
編集済
TTA
投稿者:
和
投稿日:2004年10月17日(日)09時58分55秒
ロスレスオーディオで今熱いものらしいです。猿音に比べて非常に速いのが特徴でFLACよりは圧縮率が高く、猿音よりは低いらしいです。
アルゴリズムは恐らく上位の大雑把なビットはLZ系で下位はそのまま出力しているらしいです。
猿音は上位はRangeCoderで下位はそのまま出力しているような気がします。
まだまだ進歩しますね。
可逆動画コーディックでモーションPNGがありますが非可逆に対するアドバンテージの一つに高速に処理しやすいのがありそうです。
http://www.true-audio.com/
以上は、新着順51番目から60番目までの記事です。
1
2
3
4
5
6
7
8
|
《前のページ
|
次のページ》
/8
新着順
投稿順