良いもの。悪いもの。

世の中のことをもっと知るにはどうしたら良いだろうと思うときがある。世の中の多くの事柄はログやデータに落とされる。Googleなどの検索サイトは良い例だろう。さて、そのログやデータをどうすれば良いのか? 多くの場合、視覚化が有効な手段となる。 まずは身の回りの日常的なデータやログを何とかしたい。ただ、日常のデータを視覚化するのに数十行以上のコードは書きたくない。まるで息をするかのごとく自然に視覚化を行いたいのだ。そのためには1～2行、長くて数行で済ませることが必要だ。そこでPythonとmatplotlibを使う。加えて、IPythonがあればなお良い。IPythonの導入については以前のブログ記事である IPythonの埋め込みプロットが素晴らしい を参考にして欲しい。 まずは事前にnumpyとmatplotlibをインポートしておく。できればscipyも。 >>> from numpy import * >>> from pylab import * 短いコードで視覚化を行うためには、Pythonの内包表記は必須だ。例えば、5, 2, 1, 5, 8をデータとするグラフを書きたいのならIPythonを使って以下の1行で実現できる。 >>> plot([5, 2, 1, 5, 8]) 数値が行ごとにinput.txtというファイルに書かれていた場合は以下の通り。 >>> plot([int(x) for x in file("input.txt")]) map関数を使えばもっとスマートに書ける。ファイル内の数値を文字列として配列で読み込み、それらの文字列をmap関数によりintで整数に変換する。 >>> plot(map(int, file("input.txt"))) さて、ログが2次元で書かれていた場合はどうするのか。例えば以下のデータがinput.txtに書かれていたとする。 2, 2.5 5, 6.2 6, 3.6 7, 6.3 10, 1.9 この場合、以下のようにすればプロットできる。ファイルから行ごとの文字列を読み出して、それを","を区切りとしてリス...

あけましておめでとうございます。 新年を迎えて、ふと、今年の西暦である2013を素因数分解したらどんな数に分解されるのか気になったので考えてみた。桁をすべて足し合わせると 2+0+1+3=6 と3の倍数になり、3で割り切れることは明白だ。3で割ると671となる。671に対し桁を一つ飛ばしにして足し合わせた数の差が (6+1)-7=0 で11の倍数(0を含む)なので11で割り切れることも簡単にわかる。671を11で割ると61の素数となる。つまり、2013の素因数分解は 3×11×61 となる。 大きな素数同士による合成数の素因数分解は非常に困難であることが知られている。この性質を利用して多くの暗号アルゴリズムで大きな素数による合成数が利用されている。現在のところ、素因数分解アルゴリズムとしては、楕円曲線法(ECM; Elliptic Curve Method)や複数多項式二次ふるい法(MPQS; Multiple Polynomial Quadratic Sieve)がよく使われているらしい。で、手軽にこれらを利用できるライブラリがないかと軽く調べたところ NZMATH(ニジマス) という数論のためのPythonモジュールがあることを知ったので、早速インストールして使ってみた。 ところで、大きな素数といえばメルセンヌ素数が有名だが、 マラン・メルセンヌ は、2 n -1 に対してnが257以下のとき、n = 2, 3, 5, 7, 13, 17, 19, 31, 67, 127, 257のときにのみ素数となると主張した。しかし、一部に間違いがあり、n = 61, 89, 107のときも素数であり、また、n = 67, 257は素数ではなく合成数であった。 そこで、誤って素数としていたn = 67のときの 147573952589676412927 について楕円曲線法(ECM)で解かせると、すぐに 193707721×761838257287 と結果が出力された。 >>> import nzmath.factor.methods as methods >>> methods.factor(147573952589676412927, method="ecm") [(193707721L, 1),...

先日、「 『フカシギの数え方』 おねえさんといっしょ！ みんなで数えてみよう！ 」という動画を見た。格子状のマスの左上から右下までの経路が何通りあるのかを調べて、格子が多くなればなるほど組み合わせの数が爆発的に増えることを教えてくれる動画だ。これは 自己回避歩行(Self-avoiding walk) と呼ばれている問題らしい。 これだけ聞いてもそれほどインパクトはないのだが、動画に出てくるおねえさんの経路を調べあげる執念がもの凄く、ネット上でも結構な話題になっている。執念と言うよりも狂気に近い。しかし、話題になった割には動画内で言及されている高速なアルゴリズムを実装したという話を聞かなかったので、自分で確かめることにした。 動画のおねえさんは深さ優先探索によるプログラムを使っていると思われるが、それだとスパコンを使っても10×10マスの格子を解くのに25万年も掛かってしまう。そこで、高速化のためにゼロサプレス型二分決定グラフ(ZDD; Zero-Suppressed Binary Decision Diagram)と呼ばれるアルゴリズムを利用することにした。このアルゴリズムを開発したのは北大の 湊先生 で、ZDDによりすべての経路を見つけ出すアルゴリズムとして クヌース先生 のSIMPATHを使った。ZDDについてはクヌース先生も強い関心を持っていて、 The Art of Computer Programming Volume 4, Fascicle 1 (TAOCP 4-1)ではBDD/ZDDの詳細な解説を読むことができる。演習問題の解説だけで書籍の半分を使っていることからしても気合の入れようがわかるだろう。 実際に自分のノートPCでZDDアルゴリズムを使ったコードを走らせたら、ほんの10秒程度で10×10マスの問題を解いてしまった。おねえさんがスパコンで25万年かかった問題をノートPCでたった10秒である。約8千億倍の高速化だ。これだけ劇的に変わるとやっぱり楽しい。そして、アルゴリズムの重要性を再認識させられた。 さて、以下におねえさんが利用したであろう自作の深さ優先探索(DFS)プログラムと高速な解法であるZDDアルゴリズムの両方を載せておく。ZDDについては4つのプログラムを1つのPythonスクリプトで統合している。これは、クヌー...

今回は興味を持ってもらえる人が限定される記事だと思うけど、以前作ったコードを腐らせてしまうのも勿体無いので敢えて晒してみる。 生体内のタンパク質構造をX線回折やNMRで解析したデータの多くは PDB (Protein Data Bank)データ として登録される。以下に示すように原子タグ、原子の通し番号、原子名、アミノ酸名、アミノ酸の通し番号、原子の座標などがテキストで書かれている。そして、機能の解明などのために 分子動力学(MD; molecular dynamics) 計算プログラムなどでそれらのPDBデータは利用される。MD計算プログラムは世に沢山あるが、自分がよく使っていたのは Amber というソフトウェアだ。 PDBデータの一部 ATOM 1439 N ILE 212 52.408 -3.243 59.013 1.00 40.03 N ATOM 1440 CA ILE 212 52.511 -3.151 57.556 1.00 33.72 C ATOM 1441 C ILE 212 51.464 -2.243 56.911 1.00 34.65 C ATOM 1442 O ILE 212 51.733 -1.619 55.886 1.00 38.03 O ATOM 1443 CB ILE 212 52.482 -4.572 56.921 1.00 38.88 C ATOM 1444 CG1 ILE 212 53.615 -4.703 55.919 1.00 40.75 C ATOM 1445 CG2 ILE 212 51.129 -4.901 56.281 1.00 39.55 C ATOM 1446 CD1 ILE 212 54.931 -4.446 56.550 1.00 46.31 C ATOM 1447 N HIS ...

東日本大震災(東北関東大震災)により被害を受けられた方々には心よりお見舞い申し上げます。 以前、 日本全国コンビニ店舗分布地図 を Processing で作ったが、今回の地震の震源とその大きさについて視覚的に表した地図を作成した。少しでも何かの役に立てば良いのだが。 震源とその大きさを 日本地図 上に円として表現している。円の大きさはマグニチュードと震源の深さに依存している(これは大まかな目安であり、揺れた地域や震度・エネルギーに正確に対応しているわけではない)。また、震源の深さによって円の色が変わり、浅ければ赤に、深ければ緑に近づく。海の色は時刻を現しており、正午が最も明るい青で表現され、深夜であれば真っ黒となる。データについては、 日本気象協会 が提供している3月9日から20日までの 地震情報 を利用させて頂いた。 操作方法は、スペースキーでポーズ、'N'キーで3時間進め、'B'キーで3時間戻る。'+'キーで時間の進みが速くなり、'-'キーで遅くなる。マウスの左クリックでドラッグすれば地図を動かすことができ、右クリックで上下にドラッグすれば拡大・縮小となる。 This browser does not have a Java Plug-in. Get the latest Java Plug-in here. 可視化地図から、3月11日14時46分のマグニチュード9.0の地震の起こる二日ほど前から、三陸沖で中規模の地震が頻発していることが分かる。ところが、M9.0の地震の数時間前からは揺れが全て途絶え、嵐の前の静けさの様相となる。そして、M9.0の地震の直後からはひっきりなしに揺れが続き、数日してやや沈静化してきている。ただ、M6程度の地震は未だに起こっているので、安心するにはまだ早いかもしれない。最近の地震では福島県沖や茨城県沖に多く、ややと南下している様子が分かる。 以下、ソースコードを示す。 earthquake.pde /* earthquake.pde by nox, 2011.3.22 */ String convData ...

範囲(-0.005, -0.005, 0.005, 0.005)のマンデルブロ集合を描画サイズ4,800x4,800、繰り返しの上限10,000として計算させてみた。C++でコードを書いてXeon X5650 1コアで走らせたところ942.97秒かかった(SIMD最適化はしていない)。TBBを利用した12論理コアの並列計算では88.68秒だった。次いでCUDAを使ってTeslaで走らせてみたが7.45秒まで短縮された。Teslaパない。そして贅沢にも2枚のTeslaをスレッドで並列化して使ってみたら4.26秒で計算できた。実にXeon 1コアの220倍の速度が出たわけだ。カリカリチューンをしなくてもこの程度の高速化ができるということが重要だ。 因みにマンデルブロ集合の上記の範囲は数値が発散しない集合部分であり、描画させてみても真っ黒なので面白くはない。これは並列化した際に計算が偏らないようにしたかったのでこのような範囲を指定している。プログラムで出力させたファイルは色の生データなのでそのままでは表示できない。一応、画像表示するためのPythonコードも付け加えておく。 以下に、GPU2枚を利用してマンデルブロ集合を計算するCUDAコードを示しておく。 mandelbrot_thread.cu // Mandelbrot set using GPGPU by nox, 2011.02.12 // nvcc -lcutil_x86_64 -arch sm_13 -use_fast_math -prec-sqrt=false -keep -L ~/NVIDIA_GPU_Computing_SDK/C/lib -I ~/NVIDIA_GPU_Computing_SDK/C/common/inc -g mandelbrot_thread.cu -o mandelbrot_thread #include <iostream> #include <fstream> #include <cutil_inline.h> #include <multithreading.h> using namespace std; const int BLOCK_SIZE_X = 16; const int BLOCK_SIZ...

2状態の2次元 セルオートマトン(Cellular Automaton) をActionScript 3.0 (AS3)で作ってみた。2次元セルオートマトンで最も有名なのは ライフゲーム(Conway's Game of Life) だろう。プログラムでは初期ルールをライフゲームとしている。初めにC++で書こうと思ったのだけど、Web上でグラフィカルに操作できないとつまらないと思い、AS3でFlashとして作成し wonderfl に登録することにした。ついでに時間的なエントロピー変化を視覚的に認識できたら面白そうだと思ったので、それについても実装した。 今回、セルオートマトンのコードを書こうと思ったのは TCO Marathon Round 2 の問題として出されたからだ。2次元セルオートマトンのサイズと初期配置、それにルールが与えられ、指定した世代で生存セルが最大になるように初期配置を変更しろという問題だ。そして、問題を解くために色々と調べているうちにセルオートマトンが面白く感じられたのでブログ記事にしてみた。とは言っても今回のコードはコンテストのような特別なチューンなどはしていない。ビット配列や剰余テーブルなどは使っているがどちらかというと読みやすさを優先させている。 作成したプログラムを以下に示す。 Cellular Automaton - wonderfl build flash online 1-9 : ルール設定 - セルの周りの生存セル数(0-8)に対応 : '.' 死亡, '&' 変化, '+' 誕生, '=' 維持 SPACE : 一時停止 ENTER : リセット V : メッセージ表示/非表示 Z : 初期生存セルの割合を減少 X : 初期生存セルの割合を増加 最初に実行されるルールはライフゲームだ。つまり、セルの回りに2つの生存セルがあった場合、そのセルは現状「維持」となり、3つの生存セルがあればそこに生存セルが「誕生」する。生存セルが1つ以下か4つ以上の場合は死亡セルとなる。また、上端と下端、右端と左端は繋がっていて周期境界条件となっている。現在のルール設定はFlash画面の左下に [..=+.....

世の中には星の数ほどのプログラミング言語があるかもしれないが、スーパーコンピュータで利用するとなるとかなり限られてくる。ライフサイエンス分野のデータの処理にはPython、Ruby、Perlなどのいわゆるスクリプト言語はよく使われるし、データベース関連だとJavaなどもあるだろう。しかし科学技術計算に限れば、FortranやC/C++が多数を占めると思う。やはり実行効率と既存資産の存在は大きい。 数値計算プログラムでは、とにかく速さが求められる。どれだけの速さがあれば十分かだって? この質問はナンセンスだと思う。たとえ現在の最高速度を誇るスーパーコンピュータの1億倍の速度があったとしても十分ではない。使える資源でできる範囲の計算をするだけなのだから。 自分の携わる分野では一回の計算に半年かかることもざらなので、計算速度は死活問題だ。1分で終わる処理なら倍に高速化したとしても差は30秒でしかない。しかし、半年となるとその差は3ヶ月にもなる。だから、Fortranを使うにしても、よりモダンなFortran90/95だけではなく、 古めかしいが実行速度の速いFORTRAN77 もよく使われる。まあ、最近は速度差も縮まってきているのでそこまでFORTRAN77にこだわらなくなってきているけど。本当にクリティカルな部分にはアセンブリ言語なども使われている。 また、汎用コンピュータのコンパイラに比べてスーパーコンピュータに最適化されたコンパイラではバグの入っていることが多く、C++でもBoostなどの外部ライブラリは避けた方が無難だ。使うにしても GoogleのC++コーディング規約 のように一部に限定して使う方が良い。実際にBoost絡みのコンパイラバグによる混乱を見るに、STLなどの標準ライブラリのみをシンプルに利用していた方がまだ安全だ(それでもバグるけど)。そうは言ってもBoostは便利なのでできるだけ早くC++0xの標準化がされてほしい。標準化されていればコンパイラベンダも言い訳できないしね。 そういえば Fortress なんて言語もあるね。面白い試みではあるけれど現状で利用するのは難しいような気がするなぁ。特に冒頭でも述べた、Fortranと同程度の実行効率が出せるかという点と既存資産の代替が存在するのかという点で。因みにFortressでの...

以前に、 はじめてのCUDAプログラミングで分子動力学計算 というブログ記事を書いたことがある。最近このなんちゃって分子動力学計算(MD)プログラムのソースコードを読み直してみたのだが、かなりひどい。しかも、「CUDAプログラミング」でググってみると、この記事が2番目にくる。こんないい加減なコードを参考にされたら読んだ人にも迷惑が掛かるので修正することにした。それほどCUDAに慣れているわけではないが、前回のコードよりはましだと思う。 それにしてもコードの内容がひどい。意味もなく__syncthreads()が入っているし、複数のスレッドから同じグローバルメモリに書き込みしてるし、レジスタを活用してないし、計算の順序は非効率だし、ダメダメだ。 そこでまず、CUDA Visual Profilerで関数のパフォーマンス測定を行った。因みにこのプロファイラは CUDAプログラミングツールキット に含まれているもので、CUDAでプログラミングを行うには必須だと思う。使い方は簡単で、Windowsであればcudaprof.exeを実行して、FileメニューからNew...を選び、プロジェクトの名前と場所を設定して、実行するCUDAプログラムを指定するだけだ。引数が必要ならそれも指定しておく。デフォルトでは4回実行され解析される。それぞれの関数がどれだけ時間がかかったのかプロットされるので、どこがボトルネックになっているのか一目瞭然だ。 まあ、予想していた通り、Calc関数が全体の99.8%を占めていたので、ここから修正を行った。まず、iとjを使っていたループをjだけにした。iはスレッド数で分割されていたが、ブロックと合わせてそれを消した。次に、jのループ内で不必要にグローバルメモリにアクセスしないようにした。例えばchg[i]というグローバル変数はループ外でローカル変数に入れてそれを使うようにする。あとは、できるだけ除算などの演算を減らすようにした。 次に、系全体を中心に戻す関数があるのだが、中心座標を求める部分はホスト側の関数で実装し、系全体を戻す関数のみをCUDAの関数とした。もともとこの処理は毎回やらなくてもよいものなので、指定したステップ毎に1回行うようにした。今回は100ステップに1回としている。なので、全体の処理時間から見れば無視しても良く、頑張...

先日の事業仕分けによる次世代スーパーコンピュータ(次世代スパコン)の予算見直しで事実上の「凍結」との結論が出たことで、多くの人々から次世代スパコンについて注目が集まることになったが、情報不足のためか、一部誤解があるようだ。そこで、自分の知っている範囲で次世代スパコンについて記したいと思う。もし自分の知識が至らず間違っている場合は指摘して頂けると有り難い。 次世代スーパーコンピュータ 次世代スパコン は富士通のCPU、 "Vinus" SPARC64 VIIIfx か、その後継CPUで構成する公算が高いが、このCPUはスカラ型だ。もともと、NECと日立がベクトル型のCPUを開発する予定であったが、撤退によりベクトル型とスカラ型の混成システムから、スカラ型のみのシステムに変更された。因みに、この富士通のCPU "Vinus"は現時点で世界最高速のCPUであり、国産で高速なCPUを開発できるのかという疑問も払拭できている。 ところで、この撤退により次世代スーパーコンピュータ開発について危惧する声が出たのだが、実のところ次世代スパコン開発に関わるユーザや開発者の一部では、開発がしやすくなったとして喜んでいたりする。もともとの混成システムでは、 実用的に使う場合 、ベクタ部はベクタ部のみの利用、スカラ部ではスカラ部のみの利用でしかパフォーマンスが出せず、これでベクタ部とスカラ部を一台に入れる意味があるのかというもっともな疑問が出ていたようだ。また、次世代スーパーコンピュータ開発実施本部のプロジェクトリーダーである渡辺氏がNEC出身であることからのあらぬ疑いもされずに済むようになったと思う。 NECと日立が撤退した理由として、 百数十億円の負担が重荷になった と答えている。しかし、実際はそんな負担額では済まなかったというのが関係者間での通説だ。つまり、それ以上の巨額の開発資金を企業は自腹で負担しなくてはならなかったのだ。では何故そのような負担をしてまでも次世代スパコンに参加したかったのか。それは「世界一高速なコンピュータを作りました」という事実が企業にとって非常に大きな宣伝になるから。世間一般ではそれで世界一の技術があると見なしてくれるのだ。それに、売り上げももちろん重要だが、技術者の士気も上がることのメリットが大きい。技...

迷路の描かれた画像に対して、ピクセルの座標で指定したスタート地点とゴール地点の最短経路を求めるプログラムをPython+PILで書いてみた。使用する画像は、デジカメで撮ったものでも、ウェブから拾ってきたものでも、ペイントソフトで自作したものでも構わない。 まずは使用例を見て欲しい。この画像は携帯カメラで撮った自作の簡単な迷路だ(画像上)。それに対して指定した2点間の最短経路を赤線で示してみた(画像下)。ピクセル単位で計測しているので赤線が若干ガタガタしていて完全な最短経路ではないがほぼ最短と考えていいだろう。迷路画像(画像上)をmaze01.jpgとし、スタート地点の座標が(240, 160)、ゴール地点の座標が(210, 400)の場合、コマンドラインで以下のように実行する。 maze_solver.py maze01.jpg -s 240 160 -g 210 400 これで最短経路を求めることができ、画像ビューアが立ち上がって経路の描かれた画像が表示される(画像下)。画像ビューアではなく画像ファイル(ここではmaze01out.jpgとする)に出力したい場合は、以下のようにする。 maze_solver.py maze01.jpg -s 240 160 -g 210 400 -o maze01out.jpg このプログラムは2つのパートで成り立っていて、一つは画像認識を使った画像データの領域分けであり、もう一つはその領域内の2点間の経路探索である。それぞれ、 連結成分ラベル付け(connected component labeling, CCL)アルゴリズム と A*探索アルゴリズム を利用して処理している。詳細についてはそれぞれのリンク先と最後に示したソースコードを参照して欲しい。 次の例は、Wikipediaの è¿·è·¯ の項目で例示されている迷路画像(画像上)を解いてみたものだ(画像中、下)。いずれも迷路の真ん中の小部屋(270, 130)をスタート地点とし、画像中段ではゴールを左上(0, 0)、下段では右下(490, 268)とした。スタートとゴールまでの経路は複数あるが、いずれも最短経路を示している。 画像上段をmaze02.pngとした場合、画像中段、下段は、それぞれ以下のように実行して作成した。 maze_solv...

最近、 大人の科学マガジン で 4ビットマイコン(GMC-4) が付いていると聞いて早速購入してみたのだが、ここまで面白いものだとは思わなかった。本物のコンピュータが付いて2,500円というのもの非常にリーズナブルだ。自分は純粋に楽しめたが、教育用に使うのも良さそうだ。雑誌自体はかなり薄い作りだが、内容はとても興味深いものだった。コンピュータの歴史から、ハードの仕組み、インタビュー、4ビットマイコンの説明など。読んでいるだけでワクワクする。 付録の4ビットマイコンにはGMC-4という名前が付いているが、これはGakken Micro Computerの略なんだそうだ。メモリはかなり貧弱で、プログラムメモリで00～4F番地まで、データメモリで50～5F番地までしかない。しかも、それぞれの番地は4ビットしか情報量を持たない。つまり1バイトを8ビットとすると、プログラムメモリで40バイト、データメモリで8バイトしかない。また、レジスタは補助レジスタをあわせて8種類あるが、同時に扱えるレジスタはAレジスタとYレジスタしかない。しかし、これだけの制約があると逆に挑戦してやろうと思ってしまうから不思議だ。 そこで、今回は素数を求めるプログラムを作ってみることにした。最初に考えた方法は、求めた素数をメモリに保存し、その素数を使って新たな素数を求めていくものだった。しかし、当然のように除算命令などないし、メモリが貧弱のため、求めた素数を取り置くのも難しい。そこで、求めた素数は使わずに、素数候補の数値を奇数で割っていき、その奇数が素数候補となるまで割り切れなければ素数とした。ここでは「割る」と書いたが、プログラム上では素数候補から奇数を引いていき、0になれば割り切れるとしている。このようにして求めた素数は数字LEDにそれぞれ一秒間表示される。今回は3～15(F)までの素数を求めた。それほど難しいプログラムであるわけでもないのに、数字LEDに3, 5, 7, b(11), d(13)と順次表示されるのを確認したときには妙に嬉しくなった。 久々のハンドアセンブルであったが、非常に楽しいものだった。当時もこのようにして夢中になったことを思い出した。もっとも、今回の4ビットマイコンは当時のZ80と比べてもかなり貧弱な環境だったが。素数を求めるプログラムもプログラムメモリ領域ぎり...

ブログなどでちょっとしたグラフを表示させたい場合、 Google Chart API を使っていた。しかし、手作業で入力するのはかなり面倒だ。ウェブ上にはグラフやチャートを作成するサービスなどもあるが、登録が必要だったり、手順が面倒だったりと、個人的にはあまり手軽だと思えない。数値をコピー&ペーストしてクリック一つでグラフを作成したいのだ。そこで、使いたいサービスは自分で作ってしまえということで、 Google App Engine (GAE)とGoogle Chart APIを使って簡単にグラフ・チャートを作成するウェブアプリを作ってみた。 簡易グラフ・チャート作成 即席で作成したウェブアプリなので不備な点もあるが、取り敢えず自分で使う分にはこの程度で十分なのでGAEに登録しておいた。気が向いたら機能を拡張していくかもしれない。 以下に使い方を示す。 使い方 まず、以下のデータをテキストエリアに入れてみる。 1.2 2.2 3.5 5.6 2.8 次に、「作成」ボタンを押す。チャートの種類が「折れ線グラフX」になっていれば、入力データをもとに以下のようなグラフが描かれる。 グラフのX軸、Y軸の下限と上限、およびその目盛り分割は自動で行われる。もちろん、手動での設定もできるし、自動で設定された数値を修正することも可能だ。また、出力画像ファイルの大きさも、グラフの色(16進数6桁[RGB]で表示)も変更できる。タイトルを表示したければタイトル欄に入力すればよい。因みにタイトルを改行させるには | を入れる。さらに、下記のようなGoogle Chart APIによるURLも表示するようにした。このURLを画像URLとしてブログなどで利用すれば、上のグラフを表示させるのも簡単だ。 http://chart.apis.google.com/chart?chs=300x200&chd=t:1.2,2.2,3.5,5.6,2.8&chds=1,6&cht=lc&chco=4d89f9,c6d9fd&chxt=y&chxl=0:|1|2|3|4|5|6 現時点で利用できるグラフの種類は、「折れ線グラフX」、「折れ線グラフXY」、「スパークライン」、「積上横棒グラフ」、「積上縦棒...