(卒研中間発表のメモ)(10/04)
- 10/04 (卒研中間発表のメモ) #fnct
- 10/04 通信路のジャミングやリトライや通信遮断が、どの程度プログラム側が把握できるのか、実験が必要。 #fnct_卒研中間発表
- 10/04 成果として、 http://www.ei.fukui-nct.ac.jp/~t-saitoh/… が完成している。データストアの機能実装予定。農家の利用者側が見やすいWebインタフェースなモニタ環境作るぅ？ #fnct_卒研中間発表
- 10/04 @TohruSaitoh 安全マップネタに、他の卒研グループの人から、大量ダメ出し。例年の最終発表レベルが中間発表時点で完成していて、すばらしいんやけど… 私も鬼やけど、ほかの人も鬼やのぉ… #fnct_卒研中間発表
- 10/04 XBeeを用いたセンサーネットワークの構築：ビニールハウス制御システムなどを構築するために、組み込み機器用の無線ネットワークのXBeeを用いて、各所のセンサーを無線で収集し、それに応じた制御のシステムの構築を目標。 #fnct_卒研中間発表
- 10/04 緊急メールは現状で未実装。利用者側の一方的なメールアドレスの変更が大変かもね。緊急メール機能実装を期待。メール送信で写真付き記事投稿の機能実装を期待。(鬼と呼ばれそうだな…) #fnct_卒研中間発表
- 10/04 携帯で地図登録の際には、"現在位置取得"は可能？ 位置情報＆写真付きメールで地図登録ができると防災マップにも応用可能。緊急連絡メール機能の完成度は？ #fnct_卒研中間発表
- 10/04 地域安全マップの本格運用：Google Mapを用いた安全マップと緊急メールなどの今まで卒研でやってきた内容をGAE上で統合運用を目指す。 #fnct_卒研中間発表
- 10/04 外部DBのマルチSNS化は、SNSのグループなどを生かせなくなるかも。どういった落とし所が利便性が良いか？ #fnct_卒研中間発表
- 10/04 外部サーバDBに、事案情報・位置情報・グループ情報を記録し、Persistence API を使わなければ、外部サーバDB経由で、mixi,google,などのマルチSNS対応なシステムにできるんじゃねぇ？ #fnct_卒研中間発表
- 10/04 グループ管理の外部サーバに保存する情報は、Private流出の懸念から最小限が望ましい。んで、どこまで記録する？ このアプリ起動時に、どんなデータ参照許可を与える必要がある？ #fnct_卒研中間発表
- 10/04 地図の位置情報・事件事案情報は、PersistenceAPI保存？グループ管理の外部サーバのDBに保存？ #fnct_卒研中間発表
- 10/04 OpenSocialを用いたSNS上で動作する地域安全マップシステムの開発：SNSアプリのAPIであるOpenSocialを使って、利用者が地図上に安全情報を投稿できるようなシステムを目標、 #fnct_卒研中間発表
- 10/04 利用者の誘導ではカメラの条件が違うから、マッピングに失敗する可能性が高い。端末は固定の必要があるかも。 #fnct_卒研中間発表
- 10/04 マップ情報は、ファイルに吐き出すための関数などは実験済み？ #fnct_卒研中間発表
- 10/04 3Dデータを簡単に作れるようにするには？、カメラ内に動く物がどの程度あるとやばい？ #fnct_卒研中間発表
- 10/04 マーカレスARを用いた情報提示システム、PTAM拡張の複数マップ対応版PTAMMを使い、観光案内システムを作れないか… #fnct
この記事は、
の @TohruSaitohに掲載した #fnct タグ付き記事を、まとめたものです。
2分木の操作
先週の2分木の概念を分かってもらうための基本に引き続き、 今週は2分木の様々な操作プログラムを説明する。
2分木と再帰
先週の授業の最後では、データ数カウントを再帰で説明したので、 違う視点の再帰ということで、ループ版の代わりの再帰版を説明し、 今週は課題の合計と全データ表示などを演習とした。
int find( struct Tree* p , int key ) {
if ( p == NULL )
return 0 ; // 見つからない
else if ( p->data == key )
return 1 ; // みつかった
else if ( p->data > key )
return find( p->left , key ) ;
else
return find( p->right , key ) ;
}
ちなみに、上記のようなfindは、処理の末端に再帰呼び出しが書かれているため、 一般的に末尾再帰呼び出しと呼ばれ、コンパイラによっては最適化によって ループ処理に置き換えられるかもしれない…といった説明もしておく。
void print( struct Tree*p ) {
if ( p != NULL ) {
print( p->left ) ;
printf( "%d" , p->data ) ;
print( p->right ) ;
}
}
上記のprintを演習とした際には、「全データを表示せよ」としか説明しなかったので、 学生さんの解いてくれたプログラムの表示順序をトレースし、 改めて上記のプログラムを示し、表示順序が「小さいもの順」となることを説明する。
データの追加処理
struct Tree* top = NULL ;
void entry( int key ) {
struct Tree** tail = &top ;
while( *tail != NULL ) {
if ( (*tail)->data == key )
break ;
else if ( (*tail)->data > key )
tail = &( (*tail)->left ) ;
else
tail = &( (*tail)->right ) ;
}
if ( *tail == NULL )
*tail = tcons( key , NULL , NULL ) ;
}
データの追加処理として、上記プログラムを示す。 この動作トレースにて、昇順済みのデータを与えた場合、 一方向にだけ伸びる効率の悪いO(N)木が生成される可能性を説明する。 さらに、この対応としてバランスを修正したAVL木について、紹介する。
2分木の利点欠点とハッシュ
最後にまとめとして、2分木の利点欠点をまとめる。 2分木は、検索がO(log N),追加もO(log N)であることを示す。 しかし欠点として、メモリの使用効率が悪いことなども説明。 この際に、配列の2分探索法は、データ追加では挿入場所を作るために、 データを(平均N/2回)ループでずらす処理が必要であり、O(N)で効率が 悪いことを説明する。そして、この改善のための方法として、 ハッシュがあることを説明する。
+--+--+--+--+--+--+--+---+ index| 0| 1| 2| 3| 4| 5| 6|...| value|53|28|76|13|30|62|90|...| +--+--+--+--+--+--+--+---+ i番目のデータの 左の枝は、(i*2+1)番目 右の枝は、(i*2+2)番目