最近、スマホ携帯を机に置き忘れることが増えた(大抵はすぐに取りに戻るんだけど)。 この原因を改めて自分なりに考えたら、ネット端末を使うときの「適材適所」の 意味が「この仕事にはこのネット端末を使う」という意味から、 ユビキタスの恩恵なんだけど「いま居る場所で一番使いやすいネット端末を使う」 という適*在*適所に変わってる。

携帯は当たり前ながらネット端末

以前だったら、なんだかんだと席を離れる時にも常に携帯は肌身離さずだった。 しかしながら、ガラケーよりも格段に便利になったスマホ携帯なんだけど、 ガラケーよりも触る時間は減っているかもしれない。

携帯電話って、一番の売りは当然ながら「即時性」だろう。 だけどスマホになって、バイブ用のモータも小さくなったのか、 着信に気づかない時も増えた。だから、電話も着信を後で気づいて後に対応。 メールと同じじゃん、即時性が無い！
# それに触れば触るほど、バッテリー持たないし…

適在適所

んで、ネット端末も携帯電話、タブレット端末、ノートパソコン、デスクトップ（自宅＆職場）と色々なパソコンを使うけど、Gmail,Dropbox,メールもIMAP…どのネット端末でも、 クラウドのおかげで、それなりに情報が共有され、それなりに仕事が継続できる。

さらに、視力の低下もあるもんだから、手元にタブレット端末があれば、見やすい方を使う、 つまり「いまそこにある端末で一番使いやすいネット端末」という使い方。

以前だったら、学生さんへの連絡は携帯。仕事はデスクトップみたいに、 相手や仕事に応じて端末を使い分けるという「適材適所」だったけど、 「材」が「在」に変わってる…

今日の４年の授業は、他の先生に授業風景を見てもらう公開授業であった。 たった３名とはいえ、チェック目線でしゃべりを見られるのは、 緊張であった…

授業風景では、 (a)授業の程度、(b)学生の理解度、(c)黒板の使い方、(d)シラバスとの一致、 (e)学生参加意欲の向上のさせ方、(f)その他… という点で評価を受ける。

こういう時に、新しい授業方法の模索的な方法を公開授業で見せる人もいるかも知れないけど、 いつもどおりを評価してもらうべきとの思いもあり、 いつも通りのやり方での授業で望んだ。 唯一違うのは、授業メモの blog への記録は、授業後なんだけど、今回は ネタのヌケも恥ずかしいし、昨日中に記載しておいて、blog メモを見ながら…(^_^;

見学してくれた先生からの指摘は、長年慣れた科目でもあり大きな問題の指摘は なく無事に終わった。あったとすれば、テンポが早いかな…という点と、プログラムのコードを示すためやむ終えない だろうとの指摘の上で、字が小さいとのアドバイス。 でも、こればかりは、大講義室の上げ下げできる黒板じゃなきゃ、無理っす。 後は、黒板のチョークの色使い。といっても、テンポよく復習を説明した後に、 自分でも気づいていたけども、黄色のチョークで書き始めてしまったのよ…(T_T; んで、テンポが乱れるのもイヤだったので、 説明が一区切りするまで、黄色で通したのがまずかった。 見学が終わった後の後半でも、ちょろちょろ色使いは困ったりしたけど、 処理前後の違いを強調するために、色を替えても、白・黄・赤と使いきれば、 そろそろ限界。改めて、同じ図を書きなおしたりしながらの説明だった。(それまたいつもどおり…)

いつもどおりの授業の進め方で、それなりに好評化をもらえたので一安心でしたが、 いつもになく緊張した２コマ授業であった。 さて、この後は、指摘された改善点を、改善＆実践したというレポートを含め、 提出しなければいけないのが、ちょっと面倒だけれども、いい刺激にはなったかな。

データベースの内部構造の説明を行う。

最初に、元概念となる2分木の説明を交え、O(log N)にて検索できる利点を説明し、 そのN分木のようなものということで、4年情報構造論での"B木"の説明を行う。

しかし、2分木ではデータ追加の際に、末端にデータが次々と追加され、 追加順番によっては、左右の木の段数が不均衡となった木が生成される可能性がある。

B木は、この問題に対応し、位数(d)の場合、１つの節は2d個のデータ保存場所と、 2d+1個の次の節へのポインタで構成する。 データを収納する場合には、d個以上2d個以内を収納する。 さらに、データを追加してオーバーフローが起こった場合、 中央値のデータを上部ノードに移行し、節を２つに分割する方法をとる。 中央値で分割するため、不均衡が発生しづらい点が特徴。

B+木

B木では、節が下に行くにつれ分割される。このため、全データに対する逐次処理 を行う場合には、再帰呼び出しが必須となる。しかしながら、再帰は処理も大変であり、 これらを簡単にするためにB+木が使われる。

B+木は、末端の節の先に逐次処理のための線形リストを設け、末端の節を横断できる ようにリストでつないでおく。

動的メモリの管理手法として、参照カウンタ法・ガベージコレクタ法の説明の最後として、 ヒープメモリの管理手法について説明する。 いつもはこういった講義メモは、授業後に作成しているけど、 今回は他の先生に授業方法開演のために見てもらう『公開授業』となるため、 授業前にメモを記載しておく。

ヒープメモリの必要性

必要に応じてメモリ領域を確保する場合、一般的にはmalloc()+free()を用いる。 メモリは有限でもあり、free()で返却されたメモリ空間の再利用が重要となる。 確保したメモリが不要となるタイミングが『最後に確保したメモリが最初に不要となる』という条件を満たすのであれば、スタックを用いればいい。 スタックを用いるメモリ確保命令は、alloca(int) であり、その仕組みを my_alloca() にて 説明すると、内部はおおよそ、以下のような処理である。

#define HUGE_SIZE (大きな領域サイズ)
char u_stack[ HUGE_SIZE ] ;
char *u_sp = stack + HUGE_SIZE ; // 領域の末尾アドレスで初期化
char* my_alloca( int size ) {
u_sp -= size ;
return u_sp ;
}

あとは、関数呼び出し時に、戻り番地(プログラムカウンタ:PC)の保存と共に u_sp を保存し、関数を終え元処理に復帰する(PCの復帰)の際に u_sp を復帰すればいい。

ヒープメモリのブロックが固定サイズなら

alloca() では、「最後に確保したメモリが最初に不要となる』の条件が重要であり、 不要となるタイミングが予測できない場合は、どうすればいいか？ 基本は、free() で開放したメモリを再利用すればいいのだから、 free() で開放したメモリをリスト構造で連結したスタック(free_list)としておいて、 malloc()の際は、free_listに保存しておいたメモリ領域のリストの先頭を使えばいい。

動作原理を説明する、模式的なプログラムを以下にしめす。 ただし、malloc() の引数で指定するメモリブロックサイズが不均一だと、 処理が分かりにくいので、ブロックサイズは固定で説明する。

#define BLK_SIZE (適当な大きさ)
struct MemList {
struct MemList* next ;
char memory_block[ BLK_SIZE - (nextのサイズ) ] ;
} ;
// heap内は全てがリストで繋がるように初期化する。
struct MemList heap[ HUGE_SIZE ] ;
struct MemList* free_list = (heapの先頭) ;
char* my_malloc() {
char* ans = free_list ; // 型キャストは省略
free_list = free_list->next ;
return ans ;
}
void my_free( char* p ) {
p->next = free_list ; // リストの先頭に入れる
free_list = p ;
}

可変長ブロックのヒープメモリ管理

上記のプログラムでは、説明のために確保するメモリブロックは固定サイズとしたが、 実際には色々なサイズが使われる。この場合、おおまかに以下のような方法がとられる。

ヒープメモリで管理する個々のメモリブロックには、 管理用にそれぞれ (1)次のメモリブロックへのポインタと、 (2)メモリブロックのサイズ を記録する。

struct HeapList {
struct HeapList* next ;
int              size ;
char*            memory[ (size) ] ; // 説明用の記述、C言語ではエラー
} ;

管理するメモリ領域は、最初１つの巨大なメモリブロックとして初期化し、 そのブロックの先頭を free_list に入れておく。

malloc() では、

1. free_list の先頭から、要求サイズよりも十分な大きさのメモリブロックを探す。
2. そのメモリブロックの大きさと要求サイズが同じなら、free_list からそのブロックを切り離し、そのブロックをユーザに使ってもらう。
3. 十分に大きい場合は、そのメモリブロックの末尾を、要求サイズ分に切り分ける。
   • つまり、そのブロックのsizeを、要求サイズ分だけ減らし、
   • 分割した末尾部分のアドレスをmallocの返り値として、ユーザに使ってもらう。

free()で、メモリブロックが返却された場合は、 基本的に free_list に連結すればいい。 ただし、このままでは、freeとmallocを繰り返すうちに、メモリブロックは小さく細切れになる一方で、最終的に大きなメモリブロックが使えなくなる。

この対策として、不要となったブロックを free_list につなぐ場合、ブロックはメモリアドレス順に並ぶようにする。 さらに、free_list につなぐ際に、リストの前後のメモリブロックと隣接する場合は、 next と size を調整して1つの大きなメモリブロックとなるように併合を行う。

ヒープホールと断片化

上記のようなmallocとfreeであれば、mallocの呼び出しで細切れにされたメモリブロックも、freeの呼び出し時の併合により、大きなメモリブロックに戻る。 しかしながら、最悪の順序でmallocとfreeを繰り返すと、一連のヒープ領域が「使用・不要・使用・不要・使用」のように交互になった場合、全体では不要メモリの総量は大きくても、mallocの要求メモリサイズの領域を見つけられなくなる可能性がある。

このような、細切れになった状態を断片化(フラグメンテーション)と呼び、 その細分化された不要領域はメモリ領域の小さな穴ということで、ヒープホールと呼ばれる。

毎年、このネタでは鉄板なんだけど、フラグメンテーション解消のデフラグ ということで、ハードディスクのフラグメンテーションの説明とデフラグ処理の 説明を行う。

冬休み明けだけど、今日が授業としては最初となった。 プログラミング応用の授業は、前回が2次元グラフィックスの回転移動などの演習であり、 今日はその簡単な応用について説明する。

グラフィックスの説明といいながら、実質は関数との値の受け渡しのネタを、 グラフィック座標のポインタ渡し・配列渡しで説明したような状態であった。

後半は、配布資料を元に最適化について説明する。 最適化とはプログラムの高速化のために、プログラマが行う書き換えであったり、 コンパイラが機械語を効率よく書き換えることを指す。

例として、ループ内の同じ処理をループ前に移動する例や、実数演算を整数演算に置き換える例、 整数の２のべき乗の乗除算を2進数シフトに置き換える例などを紹介する。 また、最近のグラフィクスのための特殊な機械語(MMXなど)の事例も紹介した。

とくに最近の事例として、グラフィックス計算を行う専用プロセッサ(GPU)を紹介し、 これを物理計算に利用する取組みなども説明を行った。

@EchizenBot のプログラムを、 ほとんどそのままで対象を変えた @FukuiKousen というBOTを 作ってみた。 福井高専HPのニュース速報をそのままつぶやくようにしてある。

ただ、@EchizenBot を動かして分かるのは、読み捨て系のTwitterでは、 新しい記事を探すタイミングを夜中にしかけておいても、 Tweetが見過ごされる可能性がある点。

その点を踏まえ、記事更新時間を8,10,13,15,18時といった休憩時間タイムに変更してみた。

また、@FukuiKousen のネタは、Facebookページの”福井工業高等専門学校”にも取り込まれるように設定しておいた。

• 01/10 Docomoに続いてau/sbでもか…スマホでも対応するのかな? "災害情報一斉メール：新たにａｕ、ソフトバンクが配信 ? 毎日ｊｐ(毎日新聞)" http://mainichi.jp/select/biz/news/20120… @mainichijpnewsさんから #fnct

この記事は、 の @TohruSaitohに掲載した #fnct タグ付き記事を、まとめたものです。

今日は、新年を迎えて最初の授業日。

お昼休みには、校長の年始挨拶などもありました。 簡単にまとめると、 受験倍率の維持。 教職員のActivity(科研等)および学生のActivityの向上。 国際化(外国工科大学との提携,留学生)。 その他(B科棟改修…) といった点に力を入れて取り組みたいとの目標であった。