月が変わったらネタとして使えなくなるので、特に書く事があるワケでも無いのだが半ば無理矢理につらつらと.

先日の高揚感はその後ものの見事に友人に駄目出しされ、3日程思いっきり凹む事に. まぁそんなに物事た易くないという所か(苦笑) ただ、計算上非常に微妙なバランスの元成立しているものなので、ピンポイントで改善できるものでも無く、もう暫くはまぁダラダラとみたいなそんなカンジ.

現状は少々気分を変えてよくあるテキストエディタ型の電卓などをつらつらいじる、まぁ煮詰まると電卓に走るのは僕の気分転換なワケで、シンプルでいてこれが中々奥が深い. 電卓というとどうしても初心者プログラマがつい嬉しくなって作ってみたもの的な印象はあるのだが、色々な電卓ソフトを使ってみるとそういった力量の差が思いっきり出ていたり (非礼を承知で言うと全然使い物にならないものも結構ある) 用途や想定によって余りにバリエーションが多かったり、それでいてこれだけソフトが沢山あるのにきっちり手に馴染むものは殆ど見つからなかったりというのも興味深い. そもそもが複雑な計算ならプログラム言語や表計算、数式処理などを使える状況では、せいぜい割り切った道具に過ぎないと言う事もあって、そういった割り切りのバランスと想定の切り分け、極端に単純化される必要があるデザイン上の必要性 (複雑で良いならもっと良い手段は幾らでもある) は非常に典型的な「道具」としてのコンピュータの在り方やソフトウェアの落とし所を問いかける箱庭的なものとして面白いというカンジ.

まーそんな所でもう少しダラダラする予定、まーよくあるテキスト電卓だけじゃ何の面白みも無いので、上手く以前からストックしているソルバー部分とかを活かせるデザインが見えれば少しは有意義なものが作れるのだが、これまた結構複雑なものなので、実装のデザインとして単純な電卓とのバランスは非常に難儀な所、みたいなそんな具合のお遊び ;-)

# なお余談だが、ここ暫く色々な電卓ソフトを触っていて、所謂数式型のキーボード入力では無く電卓をエミュレートするようなボタン型の入力の場合、複雑な計算をする上ではHP電卓で有名なRPN(逆ポーランド)方式ってのは非常に尤もな入力なのだなぁと改めて痛感、少し探した限りでは決定的なものが見当たらなかったので、これは作ってみても良いかも、まぁ技術的には何の面白みも無いしPCの前でそれだけ複雑な計算をマウスだけで肩肘をついて扱うのが想定としてアリなのかという、そもそもの疑問もあるので気が向いたら程度だけど(笑)

---------------

まー決して無為な事ばかりやってるワケでも無く、無理数の連分数展開による有理数近似 (例: pi≒355/113とか、この場合精度1e-6程度) のルーチンなんか書いてたり、とは言っても電卓程度の用途以外では、多倍長を実装しないと分数演算だけでは容易にオーバーフローを起こすので使い道は限定される、ただ有理数近似や素因数分解など日常的に使うものでも無いが、たまに使うので無いとそれはそれで不便みたいなそんなカンジ.

それ以外では自作言語の演算子で、汎用言語としてデザインしていた事からべき乗を一般的なものに習って** (最初の出典はFortranかな?) として、^はxor演算子としていたのだが、用途が数式のデザインと検証という事もあってべき乗の仕様頻度は高く、べき乗==^というのが体に染み付いており、1年以上使っていてもつい**では無く^と書いてしまう事が多くその度に血圧が跳ね上がる結果になっていた為、思い切ってべき乗を**と^の2つサポートとし、xor演算は^^という形にしてみた (意味論的には同一記号2つはショートカット演算子を連想させるので適切かどうかは疑問がある、ただ^|などとするよりはタイプし易かった(笑)のでその辺は妥協).

まー標準的な演算を変えるというのは、やましさのようなものもあるのだが、それに先立って自分のソースでxor演算を使っている部分をチェックしてみた所、それぞれ5〜8万行規模で、言語処理系ではそのままxorの実装部分のみ、ペイントソフトではチェッカーボードの描画部分のみであったので、まぁ使用頻度からしていーかな、みたいなそんなカンジ. ただwebや数値計算の書籍なんか見ていてもコード以外ではべき乗を^と書いている例も結構多く、そういう意味では昔はともかく最近は結構一般的な表記でむしろxorを^と表現する事の方が違和感がある気もするのだが、どうだろうか? (でも流石に結合規則は左結合 (殆どのBASIC系、Cobolもそーらしい) は耐え切れないので右結合 (それ以外の大抵の言語、多分ルーツはFortran) だったり(笑)

Web開発系の雑誌を読んでいたらJames GoslingのインタビューでJavaがCOBOLに例えられる事について、LL系の連中はWeb系の開発だけ見て能天気にそう言っているが、別分野、例えば携帯の組み込み開発や技術計算などではJavaに近付いてすらいない、みたいな事を言っていた、これってそのままC/C++の開発者がクライアント系の開発でJavaやC#について言っている事(※1)だよなーなんて苦笑いしてみたり、正に所変わればで、果たしてそれは真実かそれとも茶番かみたいなそんな具合(笑)

※1) とは言ってもC#に関して言えば一部の非常にリアルタイムな処理(工場や計測向けの端末など)を除けばVB6と同程度のアプリやよくあるインターナル系の「なんちゃって」アプリを記述する分には全く問題は無い. またJavaについてもこの程度のものであって想定ユーザーがシステム管理者などある程度コンピュータの不都合に慣れている層で、完全なエンドユーザーサイドでなければUnix上の管理アプリなどのGUIをでっち上げるのにも悪くは無いとは見ている、ここでの想定はあくまでちゃんとした所謂閉じたワークフローを提供する「アプリケーション」規模のソフトの開発についての話、ね ;-)

※2) と言っても簡単なアプリでも.NETを使うと初期状態でメモリを10MBとか食うので常駐アプリやWindowsサービス(これ、Nativeで書くのに対し若干使い辛いし) なんかに使うべきでは無いが、以前買ったLOOX Uではそういった下らぬ富士通製のアプリが大量に常駐していて、正直作ったヤツアホだろ (一応同業なんでここは遠慮なく言います、ええ. もうそんなプログラマが目の前にいたら雨に唄えばを歌いながら動かなくなるまでトルチョックものです、冗談抜きに) なんて思ってしまった部分も有り :-P

素晴らしいぃぃぃぃぃぃ！！ 完璧だッ！
…

もうだれも ぼくを とめることはできない
…
…
…

何度もの試行錯誤の末画面に出てきた計算結果を見て瞬間 「え？」みたいな、時間が一瞬止まったように感じられながらも、状況を実感できず別データで更に確認する、瞬間血の気が引きその後もの凄い勢いで神経伝達物質が分泌され思わず背筋に寒気が走るみたいなそんなカンジ.

世間的にはギャンブラーと似たようなロクデナシな状況かもしれないが、それでもやっぱりコレは余りにクセになる、たまらん(苦笑)

# でも詳細は企業秘密;-)

(自前ペイントソフトについて) ちゃんとキャラクターイラストにも使えるよという自己主張.

みたいな(笑)

もんだい

134.7 % 44.9 = ? ...(1)

※) %は剰余演算子、C,phpなどではfmod.

また例えば整数除算演算子を用意する場合
134.7 \ 44.9 = ? ...(2)

または整数除算演算を別途設けない場合でも
int(134.7 / 44.9) = ? ...(2)'

そして
(2)の商 * 44.9 + (1)の余り = ??

頭痛い :-< 誤差を補正するのは簡単だが、C++や他の汎用言語と演算式を共有するなら想定する挙動はおよそ殆どの言語でベースとなるfmodのもの(被除数と同符号)を想定するのがある意味妥当である為、正しければ全て解決というものでも無いのが難点.

無論実用上の正解は上のような相違が結果に影響するような演算式を作る/使うべきでは無いという所なのだが、言語実装となるとそういうワケにも行かず、また勝手な補正が入るのも演算によっては都合が悪く、ともすると半ば哲学的命題でもあるワケで、さて、どうしたものか X-<

余談だが検索していると (特にLL系の解説などで) floor,ceilを切り捨て,切り上げと紹介しているもの結構があり正直ゾッとする、まぁ単機能なので直ぐに気付く事であるし、瑣末な事に目を向けて殊更にあげつらうものでもないのだが、何かこういうのって見た後で見てはいけないものを見てしまったような妙な気分の悪さが残るなぁというカンジ.

※1) (2)'の演算結果も更にタチ悪いなぁ (無論それ以前にそんな演算するなって話は置いといて) この辺の内部演算精度って言語ごとにどの程度規格化されているんだろう？(要調査、でも少なくともCについては多分翻訳表現でよくある「たかだか〜n bit」とかそんな具合な気もする)

夜分追記) 色々調べてたらこんな話があった、x87FPUの場合コントロールレジスタで内部精度をどう設定しても影響されるのは仮数部のみでレジスタスタック上で扱う限りは指数部は15bitのままだそーな、この話は知らなかったので結構楽しんで読めたカンジ(嬉)

更に追記) 上のリンクで1998年頃に複素数や行列クラス (その他にもリンク先にはBLASに対するインターフェイス等も) に対するproposalがあったという内容があるが、それから10年経った現在勿論Javaには複素数も行列も標準では採用されていない、まー現実は結構そんなものだ、実際CもC99でようやく非数などの扱いがある程度真っ当に考慮されるようになったワケで、まーそんなだから未だにFortran77 (LAPACKがある限りどうにもならんかも) やCobol (想像を絶する言語構造の酷さは正直死んでも係わり合いたくないが、悲しいかな変数宣言による制約など含めたBCD演算精度のコントロールについてはこんなに言語が増えているにも関わらずCobolに比べ遥かにおざなりなものが殆ど) が生き残っていると言えるのかもしれないが(苦笑)

---------------

見てしまった系といえば、ふとネット上の掲示板で見つけたとてもおかしなIT業界 (って何って話は置いといて) な話 ここに書かれている一連のやり取りって、コンピュータ業界の外のごく普通の人の感覚から見るともの凄く奇妙な光景に映るんじゃないだろうか、、、恐いのは良くあるそういうネタ話ではなくごく普通の掲示板でこういうやり取りが出てそれに対し真面目に回答が返って議論されているという事実、実際自分もここまで明確なのは稀だが、業界内にこういった気質が蔓延しているのはよく見てきた事.

逆に上の話を見て「変だ」と感じないとすれば、感覚が麻痺しているんじゃないかなーんて思ったりするのだが、はてさて (無論それを感じる僕の方が変だという可能性も成立し得るのであくまで可能性の提起のみ、ね ;-)

# でもね、こういうのを見るにつけITバブル崩壊とか言うけど結局自分たちの蒔いた種だったんじゃないかなぁなど思うようなそんな気がするんだが(※1) これもまた単なる僕の妄想だろーか？

※1) 2003〜2005年頃(若干不確か)のアメリカの調査会社の統計で企業内のプロジェクトで納期と予算の両方で成功したものはおよそ20%、残り20%は完全に失敗、60%は納期割れもしくは予算割れの状態で継続だけしているというような話があった、結果自体はアメリカでの話だが、自分の体感的には企業内で見てきた比率も大体同じようなものだと思う、つまり全体の80%が失敗するのが常態であるなら、もしかしたらコンピュータ業界で我々が信じている常識・セオリーなどと呼ばれているそのものが何か根本的に間違っている可能性は無いだろーか？なんてふと思ってみたりもする ;-)

※2) ま、こんな事を書いている事自体言葉遊び的な所があるのは否定しない、議論において白いものを黒だという事もその逆も実際はそんなに難しい事では無いのだから、ただそれでも実際にモノは存在し、それは白か黒かのいずれかの色を持つ (一部の哲学論者は否定の余地を差し挟むかもしれないが、ここではあくまで一般的な認識の立場を取る) ならば我々が見ているものは果たして何だろうか、たまにそう己に問い直すのも悪くない :-P