ばぐとらぶごる

開発者もすなるぶろぐといふものを、エンバグ野郎もしてみむとてするなり。

トップ > SHIORI

里々のユリウス日計算スクリプト（修正版）

SHIORI

id:Umihotaru:20081226 のスクリプトが整備班版里々で怪しい動きをしていたので、下記の通り修正です。

＠ユリウス日
（calc,
３６５＊（ユリウス日要素）+（ユリウス日要素）／４
＋３０５９＊(（if,（Ａ１）＞２,−２,１０）＋（Ａ１）)／１００
＋（ユリウス日要素）／４００
−（ユリウス日要素）／１００
＋（Ａ２）＋１７２１０８９）

＠ユリウス日要素
（（Ａ０）−（if,（Ａ１）＞２,０,１））

修正箇所は１箇所だけで「＠ユリウス日要素」の部分です。
A1パラメータ（年月日の月）が2以上の場合、旧版では、

  • (（Ａ０）（if,（Ａ１）>2,,-1）)
  • (（Ａ０）（if,5>2,,-1）)
  • (（Ａ０）)
  • (２０１４)
  • \s[2014]

というふうに、数値のみを括弧で再評価した結果、\sタグに化けて以降の演算を壊してしまう問題がありました。

修正分では、ダミーのゼロを入れているため、

  • （（Ａ０）−（if,（Ａ１）＞２,０,１））
  • （（Ａ０）−（if,５＞２,０,１））
  • （２０１４−０）
  • 2014

というふうに数値として扱われ、以降の演算で異常は起きなくなります。

里々改修版の互換バグか記述の不具合か怪しいところですけど、とりあえず修正まで。

小数点以下桁数指定

SHIORI

id:ionyan:20080512

それssuのsprintfでできるやろーとソースを追っていったら……

// サイズ指定子は未対応

// 変換文字に応じて挿入
int	n = atoi(str.c_str());
switch (*p) {
	case 's': os << str; break;
	case 'c': os << (char)n; break;
	case 'C': os << (unsigned short)n; break;
	case 'd': os << n; break;
	case 'i': os << oct << n; break; 
	case 'o': os << oct << n; break;
	case 'u': os << (unsigned int)n; break;
	case 'x': case 'X': break;
	case 'f': break;
	case 'e': case 'E': break;
	case 'p': break;
	default: return false;
}

ぎにゃ〜〜〜〜！！！
しかも全部手で変換ですか！！たぶんそうだろうと覚悟してはいたけど！！

09:00 追記

ssu.dllのみ更新しました。これで

 （sprintf、%.2f、実数）
 （sprintf、%.4f、実数）

で同じようなことができるはずです。

11:30 追記2

C書式指定っていってもなんのことだか確かにわかるわけありませんね！
簡単な解説記事とサンプルスクリプトぐらいはいるだろうなー。んー。
ちなみに、今日の更新分より前ではそもそも実数（小数点以下）を扱えません。

YAYAテンプレート/大改造劇的ビフォーアフター

SHIORI

紺野ややめ大改造中です。とりあえず文屋のTipsを取り込みまくった代物になりそう。
ちなみに、単体でもそこそこいけるようなのにしたいなあ。
テンプレートゴーストにキャラがついてたらまずいやろーという意見もあるとは思いますが…もう開き直って暴走します。うふふふふ。

シェルは id:SatoM さんです。どんな経緯で…とかは開発Lingrのログを参照のこと。奇跡の丸投げ/丸受けクロスカウンター！いやこれホント仕込みなしですから。

里々と配列と私。

SHIORI

http://lre.s165.xrea.com/uka/wps/archives/190
……よく考えたら、「単語の追加」で配列もどきを作る案は難しいかも。今のところ単語群は「重複した単語は登録できない」仕様なので。
そういう制限があってもかまわんよーということでしたら、配列操作もどきの命令を追加することは可能ですが……

12:30追記

id:wiz-stargazer:20071218
「壁」というより、単に重複チェックコードをひっぺがせば済む話なんですが、それで互換問題が出ないかなあと。
単語群ごとに可/不可を設定するのもアレですし。

Inside Mc134-90x "CODE:LimitBreak"

SHIORI

さて、2日前のリミットブレイク版里々の種あかしをば。当然、最適化でジャンプできる回数を増やしたとか小手先の話ではありません。
要するに実行部に手を入れて、ジャンプを「関数呼び出しの連続」から「ループ＋実行位置保存」に書き換えたわけです。
とりあえずスタックオーバーフローだの何だので落ちることはなくなったかと。
一応デフォルトではジャンプ2万回の制限を入れてありますが、無限ループで応答不能になるのを回避するためだけのもので、実際はジャンプ回数は青天井となります。
もう一つのメリットは、何度もジャンプしてループのような処理を行うスクリプトを組んでいる場合に、処理に要するメモリの量が劇的に少なくなった点です。何度ループしようがメモリ使用量は関数呼び出し1回分なので、単純に考えて100回ループする場合は1/100になってます。もしかしたらついでに多少の高速化も期待できるかも。


……さて、そろそろSSPの開発に戻らねば。Dice氏の仕様チェキ！に追いつかないと。