Since June 16, 2000

STUDIO KAMADA

Japanese to English by @nifty

富士通テンがタイムドメイン理論のスピーカーを
やっと発売するのですね。

実は、私持ってます。
これのオリジナルともいえるタイムドメイン社のＹｏｓｈｉｉ９
というセットを。

音の特徴を簡単に書けば、すばらしい音源の再現力、
まあまあよい音像定位、少し狭い音域となります。

音源に含まれる、今まで聞こえなかった音が聞こえるように
なります。ただ、その分悪い録音は悪いとはっきりわかるので、
興ざめする音源も出てきます。逆も多いですけど。
（最近のゲームの音の細かさなんてのもよくわかります。
ＤＣのグランディア２なんて結構こってます。）

簡単な設置で、結構良い音像定位が得られます。
従来のスピーカーのようにミリ単位で厳密に設置しないと
だめ、ということはないです。

でも、１つのスピーカーで全ての音域をカバーする
フルレンジなので、高音および低音に弱さを感じます。
気になる時は気になります。

かって損はないセットですが、３０万は決して安くはないです
から、一度視聴してから買うのが良いと思われます。

私も稚拙ながらいくつかフリーウエアを出してますが、
その支えはユーザーの反響だったりします。
反響の多いものは改良が進みますし、そうでないものは
そのまま。

で、建設的意見に対しては積極的に対応しようと思いますが、
そうでない意見は、やはり無視するのが一番と思っています。
幸い、私の場合そういう意見はもらってないですが。

「改良も不具合についても責任はない」とは書きますが、
出来れば何とかしたいと思ってもいます。
ユーザーも、作者のその気持ちをくんでほしいものです。
敬意を表したお願いの仕方をしてくれ、ということです。

一度でも発表した人なら、そのあたりのことは
わかると思うのですが、どうも無い物ねだり、
しかも「自分で出来ないから出来そうな奴に頼んでるんだ。」
「出来る奴はやるのが当たり前だ。」などと考えているように
見える人がいるのが残念です。

・・・ただし、金を取っているなら話は別。
Windows上ではシャアウエアが非常に多いですが、
こういっちゃなんですけど、くだらないものにまで
お金を取っているのを見ると、少し腹が立つことがあります。
それはそうと、金取る以上、サポートは「義務」です。
フリーウエアとははっきり区別する必要があります。
（バグ採りに配布の実費以上の金をさらに取るなんて
詐欺だと思うぞ＞某社。）

LeDAさん、こんにちは。

> その支えはユーザーの反響だったりします。

同感です。

> で、建設的意見に対しては積極的に対応しようと思いますが、
> そうでない意見は、やはり無視するのが一番と思っています。

私の場合は原則として最初から無視することはしません。
あまりいい感じのしない要望でも、メールをいただいた
以上はお返事を書いて、真意や熱意を確かめます。
そこで相手が応答しなければ却下。
メールに応答してくれないとお友達になれませんから。

> 「改良も不具合についても責任はない」とは書きますが、
> 出来れば何とかしたいと思ってもいます。
> ユーザーも、作者のその気持ちをくんでほしいものです。
> 敬意を表したお願いの仕方をしてくれ、ということです。

そうですね。
敬意とまでは言いませんが、最低限、見ず知らずの人に
対する礼儀くらいはわきまえて欲しいものです。

ときどき、不具合の報告に余計な言葉を添える人がいて、
非常に不快な思いをすることがあります。
「恥ずかしいバグですね」とか。

それから、何の根拠もなく、自分の思った通りに動かな
かったというだけで「バグ報告」をしてくる人もいます。
作者が欲しい情報は「バグの有無」ではなくてどういう
条件で何をしたらどうなったのか、という具体的なことです。

> しかも「自分で出来ないから出来そうな奴に頼んでるんだ。」
> 「出来る奴はやるのが当たり前だ。」などと考えているように
> 見える人がいるのが残念です。

なんといいますか、言語道断ですね。

> こういっちゃなんですけど、くだらないものにまで
> お金を取っているのを見ると、少し腹が立つことがあります。

「マンデルブロ集合を表示するだけで金取るな」って
思いました。

フリーウエアの話では、御指摘すみませんでした。m_(__)_m

本題：
（今のところ）分かった矛盾。
＞△ADEと△ADFは斜辺と2つの角が等しい直角三角形
…これは、合っている。

＞△ADE≡△ADF。
…「∠ADE＝∠ADF」である証明がないので、「△ADE≡△ADF」とはいえない。
（三角形の合同条件の１つは、「１辺の長さと、その１辺から出る２つの角度が同じ」であること）

ここまでは分かったけど、他にもあるのかな…？

はぐれこかとりすさん、こんにちは。

> （今のところ）分かった矛盾。
> ＞△ADE≡△ADF。
> …「∠ADE＝∠ADF」である証明がないので、「△ADE≡△ADF」とはいえない。
> （三角形の合同条件の１つは、「１辺の長さと、その１辺から出る２つの角度が同じ」であること）

数学のテストではこれを証明しないと×になりそうですね。
この場合は直角三角形で∠DAE＝∠DAFで三角形の内角の和は
常に一定（180度）なので、∠ADE＝∠ADFになります。

> ここまでは分かったけど、他にもあるのかな…？

他にもあるのです。

>深井さんのページを発見しました。リンクありがとうございますぅ。まるくてかわいいものは私も好きです（笑）。

あ、見つかってしまいました。昨日から公開して、今日あちこちリンク報告してまわってるんですが、報告にきたら既に発見されてました（笑）。
まだなにもないページなのでおはずかしいかぎりです。半年前くらいから考えていたのですが、作成が遅々として進まないため、早めに公開して自分にプレッシャーをかけるという手段に出ました。

あ、あとカウンタ使わせていただいてます。ありがとうございます。

深井さん、こんにちは。

> あ、見つかってしまいました。昨日から公開して、今日あちこちリンク報告してまわってるんですが、報告にきたら既に発見されてました（笑）。

ほほほ。早いのがとりえでございます。

> まだなにもないページなのでおはずかしいかぎりです。半年前くらいから考えていたのですが、作成が遅々として進まないため、早めに公開して自分にプレッシャーをかけるという手段に出ました。

うちもそんな感じです。
いきなりどかんと現れてその後ほったらかしというよりも、
少しずつ大きくしていったほうが見てもらえると思います。
たくさん見てもらえると更新する気力もわいてきます。

> あ、あとカウンタ使わせていただいてます。ありがとうございます。

どういたしましてです。使ってもらえて嬉しいにょ。

おそらく点Dは三角形ABCの内側に入ることはないはずです。
三角形ABCが二等辺三角形のときのみ角Aの二等分線と辺BCの垂直二等分線が一致して、それ以外の場合は点Dが三角形ABCの外側になります。
そうすると、点EとFは、どちらかが三角形ABCの辺上に乗らない？ので、たとえば
AB=AE-BE、AC=AF+CFみたいになるのでは？

というあたりだと思うのですが。
会社からなので詳しい検討ができません。

深井さん、こんにちは。

> おそらく点Dは三角形ABCの内側に入ることはないはずです。

ご明察です。
正確な図を描いてみればすぐにわかることですが、
点Dが三角形の内側にくることはあり得ません。
直角の記号などが入ったもっともらしい図を出されると
信用してしまいがちなところが落とし穴の問題でした。
先日の正方形と長方形の面積の問題もそのたぐいですね。

＞サマータイム
仕事で作った機器でサマータイム対応をやったのですが、
はっきり言っていやです。
バグの素を増やすだけ。
（ちなみに、サマータイムと呼ぶのはヨーロッパで、
アメリカではDaylight Saving Time=DSTと呼びます。）

日本くらいの中緯度の国では無意味と思います。
それ以上に、日本人のように時間に正確な
民族の国家では混乱が生じすぎてだめだと。
サマータイムを挟む日のエアチェックで失敗続出で
ＴＶ局に文句殺到とか(^_^;)。
（サマータイム時の時刻更新は、夜中の1:00<->2:00または
2:00<->3:00で行われます。）

資源節約には他の方法を考えた方が良いかと。
ということで、私も大反対派（反論無用）。

LeDAさん、こんにちは。

> バグの素を増やすだけ。

まったくその通りだと思います。
ローカルタイムを基準にして動いているものをすべて
サマータイムに対応させるのは大変なことですし、
対応していないものが混ざっているとさらに混乱を招く
と思います。

> （ちなみに、サマータイムと呼ぶのはヨーロッパで、
> アメリカではDaylight Saving Time=DSTと呼びます。）

そうですね。
CNNのニュースも原文はDaylight-saving timeです。
カタカナで書くときはサマータイムが一般的だと思います。
CNNの訳もサマータイムですし。

> 日本くらいの中緯度の国では無意味と思います。
> それ以上に、日本人のように時間に正確な
> 民族の国家では混乱が生じすぎてだめだと。

同感です。
コンピュータなどをサマータイムに対応させるのは大変ですが、
すべての国民を対応させるのはさらに困難だと思います。

私の所は、物がちょっと落下しただけで、（家の者は）全員無事です。

とりあえず、速報という事で。

注意：私のところは、静岡中部（震度的に、一番強い所）

はぐれこかとりすさん、こんにちは。

> 私の所は、物がちょっと落下しただけで、（家の者は）全員無事です。
>
> とりあえず、速報という事で。
>
> 注意：私のところは、静岡中部（震度的に、一番強い所）

情報ありがとうございます。

外部からの問い合わせは緊急通報の妨げになるので、
情報を発信していただけるとみんな安心できますね。

はぐれこかとりすさん、こんにちわ。

> 私の所は、物がちょっと落下しただけで、（家の者は）全員無事です。
>
> とりあえず、速報という事で。
>
> 注意：私のところは、静岡中部（震度的に、一番強い所）

お見舞い申し上げます。
被害が無くて良かったですね。

このところ日本の至る所で地震があるので、ちょっとゾワゾワしています。

鎌田さん、ZooMarkさん、（お見舞い）レスありがとうございます。

＞このところ日本の至る所で地震があるので、ちょっとゾワゾワしています。

私の所全般（静岡県）は、今回より大きい地震が発生する巣があるため、恐々としています。
ただ、巣が発見されてから２０年以上も経つため、（県民の間で）気が抜け気味になっているのが、問題になっています。

（今回の件で、仕切り直しするかどうかは、まだ「？」というところ）

ZooMarkさん、はぐれこかとりすさん、こんにちは。

> ＞このところ日本の至る所で地震があるので、ちょっとゾワゾワしています。

最近、震度3以上の地震が立て続けに起きていますね。

> 私の所全般（静岡県）は、今回より大きい地震が発生する巣があるため、恐々としています。
> ただ、巣が発見されてから２０年以上も経つため、（県民の間で）気が抜け気味になっているのが、問題になっています。

「一番危ないのは東海地方」と言われ続けている間に、他の
地域で発生した地震によって多くの人が犠牲になっています。
その度に「実はここも危なかったのです」なんて言われて、
「そういうことは早く言ってよ」と思う人も多いと思います。
地震予知の精度が高くなるのを待つのではなく、
いざというときに役に立つ備えをしておくことが重要ですね。

こんにちは、みなさま。まさちくです。
鎌田さんのHPは四六時中(!)拝見しておりまして、今日の日記では大変ショックでした。
わたしも３月半ばにマシン環境を変えてから２週間アクセスしていなかったのですが、その間に無くなってしまい、大変残念です。
HashiMさんのHPでも紹介されておりましたが、最後のほうはたしかに残念なことばかりでしたね。

また、どこかでまさに謎のごとく復活されることを期待しております。

>鎌田さんのHPは四六時中(!)拝見しておりまして、今日の日記では大変ショックでした。

実をいうと，かくいう私もたまにですが見ています．毎日あれだけの内容が書ける
という事実に私自身尊敬だったりします(^^;

>わたしも３月半ばにマシン環境を変えてから２週間アクセスしていなかったのですが、その間に無くなってしまい、大変残念です。
>HashiMさんのHPでも紹介されておりましたが、最後のほうはたしかに残念なことばかりでしたね。

いきなり日記にHPが紹介されていてびっくり(苦笑)．意外と見に来る人っている
んだ…(^^;

ちなみに満開の移転が告知されたのは確か21日の夜だったと思います．移転先の
電話番号が決まったのが一時閉局の一日前(30日)．移転先は…都内ということ
だけは分かっています．「1週間以内に運営再開できると思う」といっていたん
ですけど，まだ満開HPの方には書かれてないようですね．

HashiMさん、こんにちは。

> 実をいうと，かくいう私もたまにですが見ています．毎日あれだけの内容が書ける
> という事実に私自身尊敬だったりします(^^;

ありがとうございます。恐縮です。
日々、気になったことがあればどんなジャンルでも
書くようにしているので、ネタは尽きないようです。

> いきなり日記にHPが紹介されていてびっくり(苦笑)．意外と見に来る人っている
> んだ…(^^;

満開ネットのほうでご意見を拝見していたので、
参考にさせていただきました。

> ちなみに満開の移転が告知されたのは確か21日の夜だったと思います．移転先の
> 電話番号が決まったのが一時閉局の一日前(30日)．移転先は…都内ということ
> だけは分かっています．「1週間以内に運営再開できると思う」といっていたん
> ですけど，まだ満開HPの方には書かれてないようですね．

21日ということは、私ももう1回アクセスしていれば
見落とさずに済んだかも知れない。
それにしても、移転先の告知期間はたったの1日ですか。
私も含めて移転先を知らない人のほうが多そうですね。
満開HPには「誰が」書くんだろう。

まさちくさん、こんにちは。

> 鎌田さんのHPは四六時中(!)拝見しておりまして、今日の日記では大変ショックでした。

私もショックでした。
ネゴが始まらないと思ってモデムのボリュームを上げてみたら
「お客様がお掛けになった電話番号は現在使われておりません」
という声が聞こえたとき、むなしい気持ちになりました。

> わたしも３月半ばにマシン環境を変えてから２週間アクセスしていなかったのですが、その間に無くなってしまい、大変残念です。
> HashiMさんのHPでも紹介されておりましたが、最後のほうはたしかに残念なことばかりでしたね。

以前から事実上シスオペ不在だったように思います。
だいぶ前に私もそのことでつっついてみたことはあるのですが…

> また、どこかでまさに謎のごとく復活されることを期待しております。

そうですね。どこにあるかわからないのは困るけど。

こんにちは。
気になる半壊ネットの電話番号ですが、

５９１５−２２８１
５９１５−２２９５

となっております。
３０日に書きこまれて、前回のようなトラブルが無ければ１週間程度とか書かれていたので、予定道理なら今日明日中には開いている……筈ですが。

みかぜさん、こんにちは。

> 気になる半壊ネットの電話番号ですが、
>
> ５９１５−２２８１
> ５９１５−２２９５
>
> となっております。

情報ありがとうございます。
満開製作所のHPにも既に告知が出ていますね。
掛けるときは市外局番の東京０３を忘れずに。

> ３０日に書きこまれて、前回のようなトラブルが無ければ１週間程度とか書かれていたので、予定道理なら今日明日中には開いている……筈ですが。

確認しました。既に開いています。

ついでにキーボードアダプター対策のＨＰのアドレスです。

http://bbs5.otd.co.jp/xsel68/bbs_tree

となっています。
ただし荒らし対策という理由で、パスワードでのクローズドになっています。
……が現実問題として書きこまれたのが２９日という遅すぎる日付という事もあり、余りに必要な人たちに見られていないと思われます。
満開ネットには誰でも見られる場所にパスワードも書いてありましたので、パスワードも転載しておきます。ID,パスワード共にxsel68です。

初めまして。毎日拝見させてもらってます。

満開ネットとキーボードアダプタサポート掲示板の件、すごく助かりました。昨年の6月に満開ネットにアクセス後、X68kが起動しなくなってしまい、それ以後アクセスできていませんでした。

申込者全員に葉書が届くにもかかわらず、私のところには「申込者名簿が不完全」という理由で届かず、コナン氏の連絡先も「相手に迷惑がかかる」という一方的な理由で不明のまま。正直どうしようかと思っていたところでした。

というわけで、どなたかキーボードアダプタがどのような状況になっている(た?)のか教えていただけませんか。サポート掲示板にも書き込んでみましたが、「あの」コナン氏ではまともな返事は期待できないので。

最初の書き込みがこんな書き込みで申し訳ありません。

Aki.さん、こんにちは。

> 毎日拝見させてもらってます。

ありがとうございます。

> X68kが起動しなくなってしまい、それ以後アクセスできていませんでした。

そういう人、結構いるのではないでしょうか。

> というわけで、どなたかキーボードアダプタがどのような状況になっている(た?)のか教えていただけませんか。

私はあまりよく把握していないので、状況を把握している
人は *XSEL68サポートボードへ* 書き込んであげてください。
そのような情報交換もXSEL68サポートボードの役目のはずです。

鎌田さん、こんにちは。

>簡略化によって普通の15パズルよりもずっと
>解きやすくなっているので、プログラミングの
>練習にちょうどよいですね。

日記で紹介していただき、ありがとうございます。
幅優先探索にはぴったりの例題、といったところですね。

>問題の局面の最小手数は48手かな？

ピンポーン！ 正解です。実は、これが START からの
最長手数だったりします。簡単なように見えて、けっ
こう長い手数かかるので、パズルとして出題しました。

ではでは。

広井さん、こんにちは。

> 幅優先探索にはぴったりの例題、といったところですね。

そうですね。
到達可能な状態が10万ちょっとしかないので、幅優先探索
だけで解けます。

> >問題の局面の最小手数は48手かな？
>
> ピンポーン！ 正解です。実は、これが START からの
> 最長手数だったりします。簡単なように見えて、けっ
> こう長い手数かかるので、パズルとして出題しました。

わりとてきとーなプログラムで求めたのですが、あって
いましたか。よかったよかった。
思っていたよりも手数が多かったです。
ブロックの種類を少しずつ増やしていったらどうなるかな。

long long・・・今のBOLAND C++は知りませんが、
少なくともTurbo-C++ V4.0では使えませんね。
X68のソースを移植する時に苦労した思い出が。
結局doubleで計算させました。
まあ、使えない処理系の方が多そうですけど、少なくとも
マイコン（組み込み系）クラスでは。

LeDAさん、こんにちは。

> long long・・・今のBOLAND C++は知りませんが、
> 少なくともTurbo-C++ V4.0では使えませんね。
> X68のソースを移植する時に苦労した思い出が。

64ビットの整数が使えないというのはイタイですよね。
移植の際に64ビットの整数を32ビットずつ2つに分割する
作業は面倒ですし、エンバグする危険性も増すので大変です。

GCCの「複文を含む式」も便利なのでつい使ってしまいます。
http://homepage2.nifty.com/m_kamada/fractalp.htm
のcomplex.hをBCC用に書き換えようと思って……ぐぅ。

> GCCの「複文を含む式」も便利なのでつい使ってしまいます。
> http://homepage2.nifty.com/m_kamada/fractalp.htm
> のcomplex.hをBCC用に書き換えようと思って……ぐぅ。

GCCの便利な構文に慣れてしまって、他のCで困ることは何度か。
移植性を高めるつもりでtypeof()を使ってかえってだめとか。

現在、JPEGライブラリを作成しようと、JPEG.Xのソースを
逆コンパイルして移植しようとして格闘中。
ここでもGCCの問題？が。
（最初から移植がわかっているならGCCの構文使わなければ
良いはずだけど、やっぱり、ねぇ。）

LeDAさん、こんにちは。

> GCCの便利な構文に慣れてしまって、他のCで困ることは何度か。
> 移植性を高めるつもりでtypeof()を使ってかえってだめとか。

GCCに慣れてしまうと、GCCで拡張された構文であることを忘れて
（あるいは知らなくて）使ってしまうことってありますよね。

長さが0の配列や可変長配列を使われると移植が面倒だったり。

KQです。おひさしぶりです。

おそらくANSI Cで定義されてないので Windows系のコンパイラで
はつかえないと思うのですが、WINDOWS(BORLAND?)独自に
__int64, unsigned __int64という似たような型があります。

> LeDAさん、こんにちは。
>
> > GCCの便利な構文に慣れてしまって、他のCで困ることは何度か。
> > 移植性を高めるつもりでtypeof()を使ってかえってだめとか。
>
> GCCに慣れてしまうと、GCCで拡張された構文であることを忘れて
> （あるいは知らなくて）使ってしまうことってありますよね。

そうですね。非常に不便に感じます。

>
> 長さが0の配列や可変長配列を使われると移植が面倒だったり。

C99対応のコンパイラなら使えるようになるので今後は楽になるでしょう。

KQさん、こんにちは。

> おそらくANSI Cで定義されてないので Windows系のコンパイラで
> はつかえないと思うのですが、WINDOWS(BORLAND?)独自に
> __int64, unsigned __int64という似たような型があります。

情報ありがとうございます。
そういえばどこかで見たような……MSDNに書いてありますね。
http://www.microsoft.com/japan/developer/library/vccore/_langref___int8.2c_.__int16.2c_.__int32.2c_.__int64.htm
ここには「Microsoft 独自の仕様」と書かれていますが、
BCC 5.5でも使えました。

__int32などの表記はビット数が明示的でわかりやすいのですが、
「レジスタが24ビットのプロセッサに移植するとき気持ち悪い」
という（思わぬ）欠点があったりします。

> > 長さが0の配列や可変長配列を使われると移植が面倒だったり。
>
> C99対応のコンパイラなら使えるようになるので今後は楽になるでしょう。

C99にはlong long intや複素数型も入っていますね。
C99準拠のCコンパイラが早く一般的になることを期待したいです。

鎌田さん、こんにちは。

１のビットを数える方法ですが、日記で取り上げていただき、
ありがとうございました。いろいろな方法があって面白いで
すね。鎌田さんの numofbits の方が、わかりやすいように
思いました。

ではでは。

広井さん、こんにちは。

> １のビットを数える方法ですが、日記で取り上げていただき、
> ありがとうございました。いろいろな方法があって面白いで
> すね。鎌田さんの numofbits の方が、わかりやすいように
> 思いました。

レジスタ内の分割統治はアセンブラ寄りの発想だと思います。
でも、動作速度についてはテーブルにはかないません。

パリティ計算も同じような感じですね。
そういえば、Z80にはパリティ/オーバーフローフラグという
ものがありました。

1のビットの数のテーブルは非常にシンプルなのでこれ以上
工夫のしようがありませんが、テーブルを使ったアルゴリズム
というのも面白いですよね。
パスカルの三角形なども一種のテーブルですし。

鎌田さん、こんにちは。

> テーブルを使ったアルゴリズムというのも面白いですよね。
> パスカルの三角形なども一種のテーブルですし。

ほんと、そうですよね。テーブル（表）を使うアルゴリズム
というと、有名なところでは「動的計画法」でしょうか。
ナップザック問題や多角形の三角形分割問題は、動的計画法
使って解くことができます。

パズルでも、表を使うと高速に解ける場合があるようです。
そこで問題です！

[問題]
各桁の階乗の和が、元の数と等しくなるような整数を
すべて求めよ。

例： 145 = 1! + 4! + 5 !

出典：松田晋「実践アルゴリズム戦略 解法のテクニック」
Ｃマガジン '93 年 7 月号より

最新のＰＣをであれば、単純な解法でもそれほど時間は
かからないと思います。表を上手に使って解いてみてく
ださい。

ではでは。

広井さん、こんにちは。

> ほんと、そうですよね。テーブル（表）を使うアルゴリズム
> というと、有名なところでは「動的計画法」でしょうか。
> ナップザック問題や多角形の三角形分割問題は、動的計画法
> 使って解くことができます。


ああ、懐かしい響き。（笑）
動的計画法の場合は、部分問題の解をテーブルにしておいて
問題全体を解きますね。
広井さんのＺしーモンキーで解説されているので参考にしましょ。

> パズルでも、表を使うと高速に解ける場合があるようです。
> そこで問題です！
>
> [問題]
> 各桁の階乗の和が、元の数と等しくなるような整数を
> すべて求めよ。
>
> 例： 145 = 1! + 4! + 5 !
>
> 出典：松田晋「実践アルゴリズム戦略 解法のテクニック」
> Ｃマガジン '93 年 7 月号より
>
> 最新のＰＣをであれば、単純な解法でもそれほど時間は
> かからないと思います。表を上手に使って解いてみてく
> ださい。

おー、問題ありがとうございます。早速…

桁数が1桁少ない場合の計算結果を使って桁数を増やしてゆけば
速そうですね。

答えは4つかな。

掲示板ではお初の小寺です。こんにちは。
numofbits いいですね。私だったらビットクリア
を eor で書いてしまうところでした。
算術でやることで、一段目が

bits = bits - (num >> 1);

に最適化かかりますね、たぶん。
今後、この処理書くときに使わせてもらいます(^^;

ちなみに、ターゲット環境によっては、テーブル引く
よりこのルーチンの方が速い事はままありんす。

小寺さん、こんにちは。

> 掲示板ではお初の小寺です。こんにちは。

NVXの件ではどうもでした。(^^;

> numofbits いいですね。私だったらビットクリア
> を eor で書いてしまうところでした。
> 算術でやることで、一段目が
> bits = bits - (num >> 1);
> に最適化かかりますね、たぶん。

「どう最適化されるか」を意識して書いたわけではないのですが、
一般的なプロセッサでは排他的論理和よりも引き算のほうが命令
の種類やアドレッシングモード（CISCの場合）が多く、スーパー
スカラなどの制約で引き算のほうが速い場合もあるので、引き算
で書けるときは引き算を使うようにしています。
特にこのルーチンのようにマスクを反転してデータを2つに分ける
場合は、引き算を使うのが常套手段だと思います。

> ちなみに、ターゲット環境によっては、テーブル引く
> よりこのルーチンの方が速い事はままありんす。

それはそうかも。
このようなテーブルのアクセスはプリフェッチできないので、
パイプラインが長いプロセッサだと遅くなりそうですね。
メモリをバイト単位でアクセスできないプロセッサの場合は、
テーブルをcharではなくてintにしたほうが速いかも。

鎌田さん、こんにちは。

ただいまカウンタが 60014 でした。
おめでとうございます！

いよいよ 68000 にむけてカウントダウンですね（笑）。

でわでわ。

広井さん、こんにちは。

> ただいまカウンタが 60014 でした。
> おめでとうございます！
> いよいよ 68000 にむけてカウントダウンですね（笑）。

ありがとうございます。
現在、10000visits/monthくらいです。
このペースを維持できるように頑張りますので、
これからもよろしくお願いいたします。

かまださんこんにちは。
色々お騒がせしておりました『空の浮動産』ですが、４／１８を持ってマスターアップする事が出来ました。
発売日は５／４……っていうかオリゲーフェスタ（＋フェスタ６８）となります。
取り急ぎ用件のみですが、また。

みかぜさん、こんにちは。

> 色々お騒がせしておりました『空の浮動産』ですが、４／１８を持ってマスターアップする事が出来ました。

お疲れ様でした！

> 発売日は５／４……っていうかオリゲーフェスタ（＋フェスタ６８）となります。

発売日が待ち遠しいです。

> 取り急ぎ用件のみですが、また。

まずはゆっくり休んでくださいね。

かまださんこんにちは。

> > 色々お騒がせしておりました『空の浮動産』ですが、４／１８を持ってマスターアップする事が出来ました。
> お疲れ様でした！

応援のおかげです。
ＨＰのトップにも情報書いて頂いてありがとうございます。

> > 発売日は５／４……っていうかオリゲーフェスタ（＋フェスタ６８）となります。
>
> 発売日が待ち遠しいです。

準備が山の様にあるので、もうちょっとフェスタまで時間があると有り難いのですけどね（笑
……でも時間があったらあっただけいじってただろうから、結局一緒か（汗

> > 取り急ぎ用件のみですが、また。
> まずはゆっくり休んでくださいね。

……全然休めないです……（涙

みかぜさん、こんにちは。

> 応援のおかげです。
> ＨＰのトップにも情報書いて頂いてありがとうございます。

どういたしましてです。
発売日が決定したと聞いて、「このニュースはトップページ
モノだな」と。（笑）

かまださんこんにちは。

> どういたしましてです。
> 発売日が決定したと聞いて、「このニュースはトップページ
> モノだな」と。（笑）

人様のページのトップを飾れるとは、うちのゲームもえらくなったもんです(笑
しかし公開後数時間後には書かれてましたね。はやっ。

鎌田さん皆さんお久しぶりです。
私のところでもやっとADSL開通です。
会社はイーアクセスプロバイダはサンネットです。
@nifty:FISDNS5番会議室で紹介されたサイトで、
スピードを計ってみたのですがプロバイダ上流の
違いなのか、紹介されている数字とだいぶ違います。

http://catv.lib.net/speed/
読み込み時間　0.201 sec
回線速度(Kbit/秒)1496 Kbps
回線速度(Kbyte/秒)187.06 Kbyte/Sec

http://www.cnet.com/internetservices/g/bm/msn/0001.html
300.7 kbps

http://member.nifty.ne.jp/oso/speedtest/avg1M.html
データサイズ = 1 M バイト
受信時間 = 0.17 秒
平均速度（バイト/秒） = 5.882 M バイト/秒
平均速度（ビット/秒） = 47.059 M bps

http://www.hinoki.sakura.ne.jp/~test1/
測定サイト http://www.hinoki.sakura.ne.jp/~test1/
測定時刻 2001/04/20(金) 03:49:02
回線種類 ADSL
回線業者 eaccess
プロバイダ sannet
データサイズ 586.586kB
伝送時間 5.83秒
ホスト1 www2.ocn.ne.jp 808kbps
ホスト2 www2.ocn.ne.jp(2) 805kbps
ホスト3 WebARENA 766kbps
ホスト4 WebARENA(2) 669kbps
ホスト5 WebARENA(3) 732kbps
推定スループット 101kB/s
推定スループット 805kbps
コメント eaccessとしては標準的な速度です。

速いのか遅いのかよくわかりませんね
私の家は局から１km程度あります。

はんかつさん、こんにちは。

> @nifty:FISDNS5番会議室で紹介されたサイトで、
> スピードを計ってみたのですがプロバイダ上流の
> 違いなのか、紹介されている数字とだいぶ違います。

公称値（最大値）と大きく違うのは、ADSLでは珍しくないこと
らしいです。

私も試してみました。

http://member.nifty.ne.jp/oso/speedtest/avg1M.html
データサイズ = 1 M バイト
受信時間 = 13.35 秒
平均速度（バイト/秒） = 75 k バイト/秒
平均速度（ビット/秒） = 599 k bps

http://www.hinoki.sakura.ne.jp/~test1/
測定サイト http://www.hinoki.sakura.ne.jp/~test1/
測定時刻 2001/04/20(金) 04:48:03
回線種類 ADSL
回線業者 eaccess
プロバイダ nifty
データサイズ 586.586kB
伝送時間 7.47秒
ホスト1 www2.ocn.ne.jp 598kbps
ホスト2 www2.ocn.ne.jp(2) 628kbps
ホスト3 WebARENA 606kbps
ホスト4 WebARENA(2) 638kbps
ホスト5 WebARENA(3) 606kbps
推定スループット 78.5kB/s
推定スループット 628kbps
コメント eaccessとしては少し遅いですが収容局からの距離が2km以上であれば問題ありません。

うちは電話局から直線で1.7kmくらい（目分量）あります。
回線の長さは2kmを越えているかも知れません。
モデムは800Kbpsを示していますが、データのスループットは
600Kbps程度なのかも。