2016年10月01日

9月度概況

access1609.jpg9月度の弊社HPへのアクセス状況は図のようになりました。本年6月に個人的に作成しておりましたブログをこちらに移しましたことから、アクセスが急増していたのですが、徐々に落ち着きつつあります。

blog1609.jpgこちらの図はブログのアクセス状況で、ユニークユーザ数(紺と緑)が開設当初の10/日から20/日程度に増加、ページビュー(水色と黄緑)はその1.5〜2倍程度となっておりますが、楽天ブログ時代に示されておりました500/日からは、はるかに隔たった値となっております。なお、アクセス解析は二つの手法で行っており、青系統はSlinStat、緑系統はアクセス解析研究所による測定結果ですが、双方の値は、ほぼ同等となっております

楽天ブログのアクセス数に関しては、システムが表示する数値(薄赤:目盛はこれだけ右側)とアクセス解析研究所の数値(オレンジがユニークユーザ、黄色がページビュー)と全く乖離した数値を示しており、楽天のシステムに異常があることはほぼ確定的です。

楽天ブログのアクセス数が大きいことから、ネットビジネスも成り立つのでは、と考えたのですが、どうやらこれは当面諦めたほうが良さそうです。とはいえ、この3か月でアクセスが倍増しておりますので、今後、ビジネスとして成り立つ可能性もゼロではなく、当面は、このままのスタイルで運用を続けることといたします。私の個人的ブログは、小難しいことばかり書いておりますので、どの程度一般受けしてくれるか、はなはだ怪しいものではあるのですが、、、

さて、業務の方ですが、コンサルティング業務が今月も立て込み、CodeSqueezer2.0の開発はほとんど進んではおりません。しかしながら、月末ごろには多少の時間もとれるようになりましたので、こちらの開発もいよいよスタートすることといたしました。

CodeSqueezer2.0は、これまでに公開しているCodeSqueezerに対して次のような改善を施すことを計画しております。

(1) 誤差キャンセルにも配慮した、精度の高い演算論理を形成すること

(2) 今後の展開やメンテナンスが容易な見通しの良いコーディングと文書化

(3) リンクリストの概念を拡張した新しいmhdl言語仕様への対応

この内、(2)に関しては、アルゴリズムをきちんと考えて文書化し、これに対応する形でコーディングをおこなうことで、見通しの良いコードが書けると考えております。(3)に関しては、なにをするにしても、コーディングを行う以上は対応する必要があります。

一方、当初から計画しておりました誤差キャンセルへの対応ですが、シミュレーションによって必要な桁数を求める手法は原理を確認済みで既に発表もしているのですが、実際のツールに組み込む際には次のような問題があります。

・すべての入力値の組合せについてシミュレーションをおこなうと非常に時間がかかる

・アルゴリズムを固定して誤差キャンセルに対応しようとすると、非常に大きな無効桁を伝達する必要が生じる場合がある

・これらの問題に対処しようとすると、人手による設定が必要となり、簡便な操作とのツールのコンセプトから外れてしまう

この問題に関しては、以前から頭を悩ませていたのですが、一旦、より完全な手法で構成することを試みたいとの考えに至りました。この手法、以前から考えてはいたのですが、関数などが含まれますと簡単にはいかないという問題があります。でも、これに対する対応策も浮かんでまいりましたので、こちらで検討すべきとの結論に至りました。これにつきまして、以下、簡単にご紹介しておきます。

ます、数式は、誤差キャンセルが含まれない形に変形することができます。数式を変形するソフトウエアとして、リデュースなどのソフトウエアが知られており、微積分や、多項式の因数分解などを式を変形する形で行うことができます。

これと同様の処理により、誤差キャンセルが生じないように式を変形するか、誤差キャンセルが入力値の異なる領域で生じるように式を変形して入力値の組合せに応じて異なる式を用いるように演算論理を組めば、誤差キャンセルの問題は回避することができます。

CodeSqueezerの場合、演算論理は一旦ブロックダイアグラムに変換されますので、この段階で値と誤差の伝達状態をチェックして誤差キャンセルの生じる可能性を判定し、これが問題とならない形にブロックダイアグラムを組みなおせばよいということになります。

簡単な例では、以下のような演算式がある場合

x = a + b
y = x - b

次のような形に式を変形してしまえばよいのですね。

y = (a + b) - b = a

多少ややこしい点は、双方の演算が異なるブロックの内部で行われていた場合ですが、この場合には、下位のブロックを上位のブロック内部に展開してしまう手法もとり得ますし、上の例でxを出力するブロックの代わりにx - bを出力するブロックを作成して、こちらを用いることで誤差のキャンセルを一つのブロック内部に押し込めることができます。

ユーザ定義のブロックであればこのような変形をすることができるのですが、標準関数ではどうするかという点がもう一つの問題となります。これに関しても、例えばsin(x)と、sin(x)±xという関数を用意することで、誤差のキャンセルが生じる場合に、他の関数を用いる形にブロックダイアグラムを変形することで誤差のキャンセルを回避することができます。

一般に、関数を含む演算で誤差のキャンセルが発生するのは、傾きが一致する部分での減算が行われる場合に生じます。したがって、これらを減算する形で新たな関数を定義してやれば、誤差のキャンセルは生じないこととなります。

関数には多々ありますので、それぞれの組合せ関数を作る必要がありますが、全ての関数を表引きで行うこととすれば、必要な関数を自動で形成することも可能であり、さほど難しい作業でもなさそうです。

と、いうわけで、開発の方向はほぼ定まりました。HPCSの論文受け付け締め切りは、昨年と同じであれば来年1月となります。まずはこれを目標にCodeSqueezer2.0の開発を進めることといたします。

誤差キャンセルの問題は、少々時間がかかりそうですので、もしもここまでできない場合は、HPCSでの発表はリンクリストの概念を拡張した新しいmhdl言語仕様までとし、来年6月ごろが締め切りとなるはずのDAシンポジウムでより完成度の高い形での発表を行うことといたします。

いずれにいたしましても、この先もかなり忙しくなりそうです。
posted by 管理人 at 15:12| Comment(0) | TrackBack(0) | 日記
Powered by さくらのブログ