2012年8月29日水曜日

プログラミングとメモ

僕がプログラミングする時
設計やTODOの洗い出しをするのは向いてないかもしれません

「時間のやりくりがうまくなる本」という雑誌の診断で
「夢や理想を追い求め、やるべきことはすべて後回し」タイプ
と診断され
TODOがやりたいことリストになってしまって
消化していかないタイプみたいです
設計したアウトプットもやりたいことリストになってしまいます
TODOは頭の中で
設計はメモ形式で
このやり方があってると思います

メモを書いて参考にしながらプログラミングをするのもいいですが
今回のメモとは別の考え方

今、HSPLetでPASSWORD機能を作成していて
暗号処理に入る手前です
ノートパッドにメモを構成して
メモを変化させながら
保存したいbytesを準備しています
普通にbytesを準備せず
メモを変化させながらbytesを準備した方が
論理が合いやすいと思うんです
暗号処理は初めてなので
メモを変化させながらやっているのであって
慣れれば普通にbytesを準備した方が楽かもしれませんが

で、そんなことをしていたら
恒常的にメモを保持するのはどうだろうか?と思ったんです
考えているうちに
それはヘッダファイルみたいなものだって思いましたが
ヘッダファイルを更に詳しくさせたものを想定しています

とりあえず今のメモ形式は
ID 変数の名前 型 size 値 記述欄
で構成しています
せっかくメモを変化させながらやっていますが
メモからデータは取り出していませんw
ちなみに型がわかっても(文字列とか)sizeが決定する訳ではないので
size項目は存在価値がありそうです

他にもHSPLetはモジュール機能がないので
データの集まりをまとめて、その集まりを何個か用意することが出来ません
なのでデータの集まりをメモとして表現するのも価値がありそうです
ソースコードを読めばデータが把握出来る
わからない時はprintデバッグすればいい
ではなく
メモを恒常的に保持し
それを参照しながらコーディングする手法も価値があると思うんですけど
そういう意味ではヘッダファイルに近い考え方で
ヘッダファイルがあれば参照しながらコーディング出来る訳で
なのに存在しないプログラム言語も多いのはどういう訳なのでしょうね

2012年8月7日火曜日

収穫逓減の法則の現代の例

収穫逓減の法則とは
農地に労働時間を加える時
一定の農地に加える労働の量が多いほど
労働によって得られる財の平均は減る
という法則です

僕が考えた例として
資本の収穫逓減の法則として
一人の労働者に資本を使用すると
加えれば加えるほど
資本によって増える財の
平均は減るというものです

例えば一人の労働者に
一カ月10万円の資本を使用して
得られるマネーが千円増えるなら
一カ月20万円の資本を使用すると
得られるマネーは2千円以下だろうという仮定です
理由は資本を増やすために使う時間が減るからです
10万円の資本を使用するなら
一人の労働者は全ての労働時間を10万円の資本を使用するのに
20万円の資本を使用するなら
一人の労働者は労働時間を10万円づつの資本を使用するのに
半分づつの労働時間をかけるからです

ただこれは資本から見た視点であり
労働者一人が増やした財は増えるため
労働者の賃金も増えるでしょう

またこれは
国内の資本の増える率が
使用する資本が増えれば増える程
率は減るということであり
先進国ほど利子が低いという現象の
理由の一つとしても考えられます

他の例として
機械のコストパフォーマンスという収穫逓減の法則も考えられます
理由は生産財がどれくらい生産されるか?という観点から見たものであり
生産する量が多ければ多いほどコストパフォーマンスが高いという観点です

生産財の価格が低い時は
賃金と生産財の価格の比率から
コストパフォーマンスは良いでしょう
さらに高価な生産財を使用することに変更していって
皆が使用している生産財であるほど
生産効率が良くてコストパフォーマンスも良いです
更に高価な生産財に変更していくと
生産財の使用している割合が減少し
生産する量が少ないという理由で
コストパフォーマンスが悪くなっていきます

と言っても、先進国においては
賃金が高いので
高価な生産財も割合安価であり
それによりちゃんと生産効率があがるなら
十分使用価値はありますが

2012年8月6日月曜日

回路的プログラミング言語

今、日経ソフトウェアの付録を読んでるんですけど
(既に読破したやつw)
演算の回路について読んで
(ANDとかORとかNOTとか)
回路的プログラミング言語ってのもあってよいかと思いました
ググればありそうですけど

例えばBIGNUMを書こうとした時
回路的プログラミングをした方が簡単に書けるのではないかと
例えば1桁をBYTEにして
10を越えれば上のBYTEに接続して加算
10かけるとかして上の桁に代入する時も
上のBYTEに接続して代入とか
桁はスタックで管理して
桁増やす時はスタックに積んで
代入するなら接続とか
代入って演算もいいけど
接続って演算があってもいい気がします
同じ動作だとしても別名でも嬉しそう
リテラルの代入が代入で
変数からの代入が接続とか

簡単にBIGNUMのフローチャートを書いてみようか

toString
文字列に代入
toBIGNUM
BYTE配列に代入

加算
桁の数だけ繰り返し
同じ桁を足して10の商を一つ上の桁に加算

大小比較
符合がプラスとプラスなら
桁が大きい方が大きい
符合がマイナスとマイナスなら
符合が大きい方が小さい
符合がプラスとマイナスなら
符合がプラスの方が大きい
桁が同じなら
桁の数だけ繰り返し
桁の数が異なる場合
数が大きい方が大きい
全部等しい時のみ等しい

符合無視大小比較
桁が大きい方が大きい
桁が同じなら
桁の数だけ繰り返し
桁の数が異なる場合
数が大きい方が大きい
全部等しい時のみ等しい

減算
お互い0以上
減算A
引かれる数の方がプラスで
引く数がマイナスだと
加算
引かれる数の方がマイナスで
引く数がプラスだと
加算(符合はマイナス)
お互いマイナス
減算B

減算A
大小比較して
引く数が大きいなら
引く数引く引かれる数
符合はマイナス
引かれる数が大きいなら
引かれる数引く引く数
符合はプラス

減算B
大小比較して
引く数が大きいなら
引く数引く引かれる数
符合はプラス
引かれる数が大きいなら
引かれる数引く引く数
符合はマイナス

10の乗数Xの掛け算
桁の数だけ繰り返し
それぞれの桁のX上の桁に代入

掛け算
演算結果変数宣言
掛けられる数の桁の数だけ繰り返し
掛ける数の桁の数だけ繰り返し
掛ける数の桁をX数値をIとする
掛けられる数の桁をY数値をJとする
K=I*J
K掛ける10のX+Y乗(10の乗数Xの掛け算)
演算結果変数宣言+=K

割り算
演算結果変数宣言=0
i=1
while 1
割られる数<割る数*10のi乗(10の乗数iの掛け算):break
i++
wend
i--
tmp=割られる数
for iii i回
for ii 1~10
tmp<割る数*ii*10のiii乗(10の乗数iiiの掛け算):break
next
ii--
tmp-=割る数*ii*10のiii乗(10の乗数iiiの掛け算)
演算結果変数宣言+=割る数*ii*10のiii乗(10の乗数iiiの掛け算)
next

フローチャートのはずがだんだんHSPっぽくなっていったとかw