まだ作ってる会社があったとは！
http://www.fuki.co.jp/mall/index.html
はんかつさん、こんにちは。
> まだ作ってる会社があったとは！
> http://www.fuki.co.jp/mall/index.html
おー、自転車にエンジン載ってますねぇ。
これで楽をしたいときは、アシスト自転車と違って原付の
免許が必要ですが、自転車よりも速く走ったら危なそうですね。
自転車のタイヤで普通の自転車よりも重いから、自転車並の
速さでも危ないかも知れない。
いわゆる「原付」が「原動機付自転車」の略語であること
を思い出して、ちょっと納得。
鎌田さんおひさしぶりです はんかつです。
>ZETA3 ポータブル自転車パワーアシストシステム
世界初といいますが、私の子供のころにはガソリンエンジン
を使ったこんなやつが日本を走り回っておりました。
あのホンダも最初はこれから始めたのです。
はんかつさん、こんにちは。
> >ZETA3 ポータブル自転車パワーアシストシステム
> 世界初といいますが、私の子供のころにはガソリンエンジン
> を使ったこんなやつが日本を走り回っておりました。
> あのホンダも最初はこれから始めたのです。
これ↓ですね。
http://www.honda.co.jp/50years-history/001.html
普通の自転車に動力を乗せてしまう発想はオートバイの
原点だったのですね。（普通に納得）
しかし、さすがにこれが普通に道路を走っているところは
見たことがありません。
私が子供の頃は、廃車置場に置かれていたオート三輪を見て
「この変なカタチの乗り物は何だろう？」って思っていました。
マウス２台とマウストラックボール１台を、また
HST X68000 Room さんに売りに出しました。
興味のある方はどうぞ。
新品ではないですが、効かないスイッチは交換済みの
感動 ･･･ もとい、完動品です。
LeDA さん、こんにちは。
> マウス２台とマウストラックボール１台を、また
> HST X68000 Room さんに売りに出しました。
マウス・トラックボールというと、「ふたを取って底面の
スイッチを切り替えるとボールが持ち上がってマウスから
トラックボールに早変わりするという、X68000 の発売当初に
話題になった斬新な発想のマウスですね。
本体に標準で付属している機種とそうでない機種がありますが、
X68000 シリーズならばどの機種でも使えます。
トラックボールに切り替えればボールを指でくりくりできるので、
特にマウスを動かすスペースがない人は重宝すると思います。
トラックボールのときに押しやすいように、上面だけでなく
側面にもボタンが付いています。（機能は上面のボタンと同じ）
> マウス・トラックボールというと、「ふたを取って底面の
> スイッチを切り替えるとボールが持ち上がってマウスから
> トラックボールに早変わりするという、X68000 の発売当初に
> 話題になった斬新な発想のマウスですね。
私はこれを愛用していて、現在手元で実働している X68030、
CompactXVI ２台、XVI、030Compact 全てにこれを付けています。
机の上が狭いので普通のマウスではやりづらい、という
事情もあります (^_^;)
手の上で転がすには最適なので、Win 用にもあればいいのですが、
全く同じような物はないですね。SHARP の特許なのかな？
ちなみに、今日現在売れてません。
以外と需要がないのかも。
なければないで自分の予備品に回すだけなのですが。
電撃Ｇ’ｚを嬉々として読み耽る女子中学生……
そのうち「萌え～」とか言い出すかも。
こうしてマーケットは予想外のターゲットへと広がって行くのですね。
ブロッコリーの店舗数がソフマップを越える日も遠くないかも。
みかぜさん、こんにちは。
> 電撃Ｇ’ｚを嬉々として読み耽る女子中学生……
> そのうち「萌え～」とか言い出すかも。
それはこわいっす。
「まじんがっぱグッズ集めてるの～」くらいならいいけど。
> こうしてマーケットは予想外のターゲットへと広がって行くのですね
> ブロッコリーの店舗数がソフマップを越える日も遠くないかも。
子供の遊びがテレビゲームからカードゲームに移りつつある中で
成長を続けるブロッコリーですが、現在のゲーマーズの店舗の
増え方は「節操なし」の域には達していないと思います。
キャラクターグッズ屋さんとデジタルグッズ屋さん（笑）を
比較するのは難しいですね。
＞C 言語を完全に理解したければ、アセンブラを少しはかじっておくべきです。
全く同感です。
ただ C で書けるというのと、その特性を知って生かすというのは
違う能力だと思います。特に、ＯＳを記述するときや、
組み込みマイコンで記述するときは重要と思っています。
私は。
能力やサイズでの制限が多いですから。
それを他人に言っても理解されないところがありますが。
Ｃは、他の言語に比べアセンブルコードが想像できるのが
好きなところでもあります。
その意味ではＣ＋＋は似て非なる物と感じています。
それが、私がＣ＋＋を習得できず未だにＣだけで
やっている理由でもあります。
だめ？
LeDA さん、こんにちは。
>＞C 言語を完全に理解したければ、アセンブラを少しはかじっておくべきです。
>
> 全く同感です。
> ただ C で書けるというのと、その特性を知って生かすというのは
> 違う能力だと思います。特に、ＯＳを記述するときや、
> 組み込みマイコンで記述するときは重要と思っています。
> 私は。
> 能力やサイズでの制限が多いですから。
その通りだと思います。
賛同していただけて嬉しいです。(^^;
> それを他人に言っても理解されないところがありますが。
知らない人に理解してもらうのって大変ですよね。
わざわざサンプルプログラムを作って見せてもわかって
もらえなかったりすると悲しくなります。
> Ｃは、他の言語に比べアセンブルコードが想像できるのが
> 好きなところでもあります。
同感です。
> その意味ではＣ＋＋は似て非なる物と感じています。
> それが、私がＣ＋＋を習得できず未だにＣだけで
> やっている理由でもあります。
> だめ？
わたくし的には、全然おっけーだと思います。
私も C++ を積極的に使いたいとは思いません。
必要があって C++ のソースを読むことがありますが、
「C で書いてくれたほうが読みやすいのに…」と思うことが
多いです。書き方にもよるかも知れませんが。
本質的に、C と C++ の違いは、アセンブラと C の違いよりも
大きいと思います。
C++ はコンピュータの高級言語の 1 つであって、不幸にも
C++ 最初に覚えてしまった人が後から C を完全に理解するのは
大変だろうと思います。
C++ は、用途や開発環境によっては使いやすい高級言語の 1 つ
にすぎず、C に取って代わるべき言語ではないと思います。
こんにちは、ゆうき喬史です。
アセンブラの最適化問題やってみました。
;16 ビット符号付き整数同士の飽和加算を行う MC68000 用のプログラム
move.w (a0)+,d0 ; 被加算数をメモリから取り出す
add.w (a1)+,d0 ; 加算を行う
bvc.s done ; オーバーフローしていなければ終わり
add.w d0,d0 ; 加算結果の符号ビットを押し出す
subx.w d0,d0 ;d0 に (d0-d0)－符号ビットの値をセット
addi.w #$8000,d0 ; 値を調整
done: move.w d0,(a2)+ ; 加算結果をメモリに格納する
何度も計算するときは、d1 に #$8000 をいれましょう。
・・・って、ちゃんと動作するのか不安 (~~;
ゆうき喬史さん、こんにちは。
> アセンブラの最適化問題やってみました。
一番乗りです！
投稿ありがとうございます。
> ;16 ビット符号付き整数同士の飽和加算を行う MC68000 用のプログラム
> move.w (a0)+,d0 ; 被加算数をメモリから取り出す
> add.w (a1)+,d0 ; 加算を行う
> bvc.s done ; オーバーフローしていなければ終わり
> add.w d0,d0 ; 加算結果の符号ビットを押し出す
> subx.w d0,d0 ;d0 に (d0-d0)－符号ビットの値をセット
> addi.w #$8000,d0 ; 値を調整
> done: move.w d0,(a2)+ ; 加算結果をメモリに格納する
おしいっ！
処理内容はあっていますが、もっと短くできます。
> 何度も計算するときは、d1 に #$8000 をいれましょう。
ループも考慮して速度を最適化するときはこれも重要ですね。
あまりオーバーフローしないデータでは効果が薄いですが、
頻繁にオーバーフローするデータならばイミディエイト
データをループの外に押し出すだけで毎回 4 クロックの節約。
鎌田さん、こんにちは。
さらに短くできるという話を見て、私も最適化問題に挑戦してみました。
68000 には久しく触っていなかったので、マニュアル片手に命令を
思い出しながらになりましたが。^^;
;16 ビット符号付き整数同士の飽和加算を行う MC68000 用のプログラム
move.w (a0)+,d0 ; 被加算数をメモリから取り出す
add.w (a1)+,d0 ; 加算を行う
bvc.s done ; オーバーフローしていなければ終わり
ext.l d0 ; 加算結果を符号拡張
swap.w d0 ; これで加算結果の MSB が d0.w 全ビットに展開
roxr.w #1,d0 ; 加算時に変化した X フラグを MSB へ
done: move.w d0,(a2)+ ; 加算結果をメモリに格納する
ext,swap は割とすぐに思いついたのですが、roxr が出てくるまでかなり
苦労してしまいました。加算時に変化した X フラグをここまで持ち越す
のがミソでしょうね。
なかむらさん、こんにちは。
どちらのなかむらさんかなと思ってメアドをチェック…
HAS.X と HIOCS.X の作者のなかむらさんではありませんか！
ごぶさたしてます。HAS060.X の件ではお世話になりました。
> さらに短くできるという話を見て、私も最適化問題に挑戦してみました。
> 68000 には久しく触っていなかったので、マニュアル片手に命令を
> 思い出しながらになりましたが。^^;
なかむらさんに挑戦していただけるとは光栄です。
> ;16 ビット符号付き整数同士の飽和加算を行う MC68000 用のプログラム
> move.w (a0)+,d0 ; 被加算数をメモリから取り出す
> add.w (a1)+,d0 ; 加算を行う
> bvc.s done ; オーバーフローしていなければ終わり
> ext.l d0 ; 加算結果を符号拡張
> swap.w d0 ; これで加算結果の MSB が d0.w 全ビットに展開
> roxr.w #1,d0 ; 加算時に変化した X フラグを MSB へ
> done: move.w d0,(a2)+ ; 加算結果をメモリに格納する
>
> ext,swap は割とすぐに思いついたのですが、roxr が出てくるまでかなり
> 苦労してしまいました。加算時に変化した X フラグをここまで持ち越す
> のがミソでしょうね。
お見事です！
オーバーフローしたときの処理が、最短の 3 ワードになって
いますので、正解です。
サイズの最適化の正解が出たところで、もう１つ。
実は、同じサイズで、もっと速い（クロック数が少ない）
方法が存在します。
サイズだけでなく動作速度も最適化してみてください。
はじめまして . こんにちは .
自分も考えてみました .
> add.w d0,d0 ; 加算結果の符号ビットを押し出す
正＋正か、負＋負でなければオーバーフローしないので、あらためて
Ｘビットを変化させなくても、オーバーフローした側によってＸビット
の中身は決まっています . それを活用します .
;16 ビット符号付き整数同士の飽和加算を行う MC68000 用のプログラム
move.w (a0)+,d0 ; 被加算数をメモリから取り出す
add.w (a1)+,d0 ; 加算を行う
bvc.s done ; オーバーフローしていなければ終わり
subx.w d0,d0 ;d0 に (d0-d0)－符号ビットの値をセット
eori.w #$7fff,d0 ; 値を反転
done: move.w d0,(a2)+ ; 加算結果をメモリに格納する
subx.w d0,d0 をした時点で、
正にオーバーフローしていた →d0.w = 0 ($0000)
負にオーバーフローしていた →d0.w = -1 ($ffff)
となるので、あとはひっくり返して終わり .
一応確認もしたのでこれで合っていると思いますけど ...
鈴木Ｋさん、こんにちは。はじめまして。
> 自分も考えてみました .
ありがとうございます。
> > add.w d0,d0 ; 加算結果の符号ビットを押し出す
> 正＋正か、負＋負でなければオーバーフローしないので、あらためて
> Ｘビットを変化させなくても、オーバーフローした側によってＸビット
> の中身は決まっています . それを活用します .
ご明察です。
X フラグは符号ビットと逆になっています。
> ;16 ビット符号付き整数同士の飽和加算を行う MC68000 用のプログラム
> move.w (a0)+,d0 ; 被加算数をメモリから取り出す
> add.w (a1)+,d0 ; 加算を行う
> bvc.s done ; オーバーフローしていなければ終わり
> subx.w d0,d0 ;d0 に (d0-d0)－符号ビットの値をセット
> eori.w #$7fff,d0 ; 値を反転
> done: move.w d0,(a2)+ ; 加算結果をメモリに格納する
>
> subx.w d0,d0 をした時点で、
> 正にオーバーフローしていた →d0.w = 0 ($0000)
> 負にオーバーフローしていた →d0.w = -1 ($ffff)
> となるので、あとはひっくり返して終わり .
>
> 一応確認もしたのでこれで合っていると思いますけど ...
ハイ！ 正解ですっ！
eori を使うところがミソです。
オーバーフローの処理が 3 ワード、12 クロックですので、
これが最短かつ最速のコードです。
（roxr を利用すると 16 クロックかかってしまいます）
繰り返すときは、$7FFF を d1.w に入れておけば、
オーバーフローの処理が
subx.w d0,d0
eor.w d1,d0
だけで済みます。これだと 2 ワード、8 クロックです。
なかむらです。こんにちは。
う～む、あと一歩でしたか。残念。^^;
しかしこの手の最適化は一種パズル的な面白さがあっていいですね。
仕事で某 RISC CPU をいじってたりしますが、これだとそもそもフラグレジスタが
なかったりして、どうやっても C で普通に書いたのと同じような結果になって
しまいます。いや、RISC って本来そういうものなんですけど。
なかむらさん、こんにちは。
> う～む、あと一歩でしたか。残念。^^;
サイズの最適化という当初の目的は達していましたから OK です。
でも、速度も最適化しないと気が済まないという気持ちは
よくわかります。（笑）
> しかしこの手の最適化は一種パズル的な面白さがあっていいですね。
そうですね。
パズル感覚で楽しめることもアセンブラの魅力の 1 つだと思います。
> 仕事で某 RISC CPU をいじってたりしますが、これだとそもそもフラグレジスタが
> なかったりして、どうやっても C で普通に書いたのと同じような結果になって
> しまいます。いや、RISC って本来そういうものなんですけど。
RISC プロセッサのアーキテクチャは、コンパイラの使用を
前提にして設計されているものが多いですよね。
でも、中には Alpha のバイト操作命令のように「コンパイラ
だけに使わせるのはもったいなさそうなトリッキーな命令」
を持っている RISC プロセッサもありますから、「RISC＝
アセンブラで書く意味がない」とは限らないと思います。
設計した人が意図しなかったと思われる使い方ができる
アーキテクチャは面白いと思います。
こんにちは。
最適化問題の最速・最短の回答って、実は、
自分も最初に思いつきました。
でも、頭の中で、最初の加算の X ビットの値を
検証してるうちになぜか、X ビットの値は不定
という結論に・・・(^^;
考えすぎて、間違った結論出すことってよく
ありますよね？
ゆうき喬史さん、こんにちは。
> 最適化問題の最速・最短の回答って、実は、
> 自分も最初に思いつきました。
>
> でも、頭の中で、最初の加算の X ビットの値を
> 検証してるうちになぜか、X ビットの値は不定
> という結論に・・・(^^;
>
> 考えすぎて、間違った結論出すことってよく
> ありますよね？
そうですね。
こういうときはレジスタやフラグの変化を細かく書き出して
考えるとよいと思います。
私はよくソースの注釈に書き込みます。
そうしておくと後で見直すときにもわかりやすいですし。
「符号付き加算で符号が違うときは絶対にオーバーフローしない」
この性質も覚えておくと何かと考えやすくなると思います。
８ K の OS でネットワーク（TCP/IP) につながるとしたら ､
すごいことだと思うのですが ､ それしか出来ないのでは ?
と言う気もします ｡ だったら、ＯＳと言うよりやはり
ＢＩＯＳと呼ぶのがよいような。
実は私も X68 でも動くμ ITRON を作っていたりしますが、
８Ｋというのはかなり小さいと感じています。
私のＸ６８版はタスク同期、１ビットイベントフラグ、
セマフォ、タスク間メイルを含めて１７Ｋもあります。
まあカーネル以外は全部Ｃで書いてありますし、
機能限定すればサイズ縮小は可能ですが。
（X68 専用ではなく ､MPU680x0 用で ､ 各種 CPU 移植を
最大に考慮しているもの。ライブラリ形式なので
各種プログラムの中に組み込んで一時的なマルチタスクを
行うことも可能。８６版 ､ 三菱７９０２版 ､
Z80 版 ､ 松下 MN101C、日立Ｈ８版があり。もちろん
仕事で作ったので非公開。）
Ｘ６８で１０Ｋを切れると良いんですけど、
私の能力ではできてません。
LeDA さん、こんにちは。
> Ｘ６８で１０Ｋを切れると良いんですけど、
> 私の能力ではできてません。
M68K 用のコードが、8 ビット用のコードよりも大きく
なってしまうのは仕方ないと思います。
X68000 を含む M68K 汎用のライブラリでは、外部参照に
ショートブランチや絶対ショートアドレッシングなどを
使いにくいでしょうし。
動作を速くするのではなくてコードを短くする最適化
というのも結構面白いです。
ROM の容量に限りがあった昔の BIOS やモニタ ROM は
よく詰め込んだものだと思います。
> ROM の容量に限りがあった昔の BIOS やモニタ ROM は
> よく詰め込んだものだと思います。
Z80 の時代には、１６進コードレベルでの最適化
というかトリックを使ってサイズ縮小とかスピードアップを
してましたが（そういえば１６進で Z80 が読めたなぁ）、
さすがに１６ビット以上クラスでは出来ないですね。
あぁ懐かしい時代。
CD = CALL
C9 = RET・・・
LeDA さん、こんにちは。
> Z80 の時代には、１６進コードレベルでの最適化
> というかトリックを使ってサイズ縮小とかスピードアップを
> してましたが（そういえば１６進で Z80 が読めたなぁ）、
やってたやってた。
まともなアセンブラを持っていなかったこともあって、
Z80 のプログラムは頭でアセンブルしていました。
それでマンデルブロ集合とか描いていました。
（昔からそんなことばかりやっていたらしい）
> さすがに１６ビット以上クラスでは出来ないですね。
> あぁ懐かしい時代。
16 ビットでも M68K なら結構無茶なことをやります。
オペコードを演算に使ったり、オペランドにオペコードを
埋め込んでオペランドに飛び込んだり、MC68000 専用なら
命令やオペランドの自己書き換えだってやります。
開発効率や保守性を尊重するのは一般論であって、
それらを犠牲にしてでもコードを縮めたり速くしたり
する必要が生じることはあります。
まあ、私がやるのはほとんど趣味ですけど。
「8KByte の OS を家電全部に入れてしまえ」との事ですが、それって TRON の「どこでもコンピュータ」と同じ方針ですね。
ネットワークに繋がるとの事ですが、TCP/IP が乗ってるんでしょうか。
ちなみに、ITRON には適応化と言う秘技が有って、アプリケーションが使用しないシステムコールを削る事が出来たりします。
そうすると、8 ビット向けの物なら 8K なんか余裕で切る場合も有るでしょう。
それに、今のワンチップは大容量です。1cm 四方のチップに 128Kbyte のメモリー (H8 等) も有るので、大きさはあんまり問題にならなくなってきてます。
あと、組み込み用でシングルタスクだとしたら、ネットワーク・スタックだけだろうから、OS とは言わずライブラリとかモニタとか言う気がするのは私だけでしょうか (笑)
M.Suzuki さん、こんにちは。
>「8KByte の OS を家電全部に入れてしまえ」との事ですが、それって TRON の「どこでもコンピュータ」と同じ方針ですね。
ほんと、同じというか、そっくりですよね。
誰が最初に言い出したのかな。
> ネットワークに繋がるとの事ですが、TCP/IP が乗ってるんでしょうか。
どうなんでしょう。
ネットワークに接続するために必要なプロトコルが別だと
したら、小さいことをアピールする意味が薄れてしまう
ような気がします。
> ちなみに、ITRON には適応化と言う秘技が有って、アプリケーションが使用しないシステムコールを削る事が出来たりします。
> そうすると、8 ビット向けの物なら 8K なんか余裕で切る場合も有るでしょう。
> それに、今のワンチップは大容量です。1cm 四方のチップに 128Kbyte のメモリー (H8 等) も有るので、大きさはあんまり問題にならなくなってきてます。
コストの問題もあると思いますが、最近は大容量のチップも
安くなっていますよね。
> あと、組み込み用でシングルタスクだとしたら、ネットワーク・スタックだけだろうから、OS とは言わずライブラリとかモニタとか言う気がするのは私だけでしょうか (笑)
同感。
会社で使ってた、Ｘ６８用モニターのＣＵ－２１ＣＤ
を２台（黒とグレー）、個人売買の掲示板のある
ＨＳＴ Ｘ６８０００ ＲＯＯＭさんに出しています。
興味のある方はどうぞ。
LeDA さん、こんにちは。
> 会社で使ってた、Ｘ６８用モニターのＣＵ－２１ＣＤ
> を２台（黒とグレー）、個人売買の掲示板のある
> ＨＳＴ Ｘ６８０００ ＲＯＯＭさんに出しています。
>
> 興味のある方はどうぞ。
CU-21CD は 21 インチで 15/24/31kHz が入るモニタですね。
マイコンソフト / 電波新聞社の XRGB-2 の接続は要注意。
HST X68000 Room はこちらです。
http://www.cablenet.ne.jp/~hst/x68k/
> CU-21CD は 21 インチで 15/24/31kHz が入るモニタですね。
> マイコンソフト / 電波新聞社の XRGB-2 の接続は要注意。
そうです。
XRGB-2 使用時は、31KHz モードは使わず 15KHz を使えと
書いてあります。
まあ、Ｘ６８だけで使っている分には問題ないのですが。
LeDA さん、こんにちは。
> > CU-21CD は 21 インチで 15/24/31kHz が入るモニタですね。
> > マイコンソフト / 電波新聞社の XRGB-2 の接続は要注意。
>
> そうです。
> XRGB-2 使用時は、31KHz モードは使わず 15KHz を使えと
> 書いてあります。
実物を見ていないので具体的にどうダメなのかわかりませんが、
↓ここ↓には「接続はお奨めできない」と書いてあります。
http://www.dempa.co.jp/MICOMSOFT/XRGB-2.html
モニターは、黒は早速売れてしまいました。
さすがはインターネットと言うところです。
実は手元に純正マウスもいくつか（なぜか３個くらい）
余っているので、スイッチを取り替えて動くようにして
売りに出そうかな。
←売りに目覚めた！？(^_^;)
LeDA さん、こんにちは。
> モニターは、黒は早速売れてしまいました。
> さすがはインターネットと言うところです。
お、早いですね。
あと 1 台ですね。
> 実は手元に純正マウスもいくつか（なぜか３個くらい）
> 余っているので、スイッチを取り替えて動くようにして
> 売りに出そうかな。
>←売りに目覚めた！？(^_^;)
純正マウスは貴重ですよね。消耗品ですし。
Kamada さん、こんばんわ。
3/3 の問題の答えは「接した所で重なっている」ですか？
途中で切れた２つの三角形は微妙に角度が違います。
正方形を半分にした三角形の比率は 144:377 ですが、
途中から先の部分の比率は 89:233。
比率を合せる為に、それぞれ 89 と 144 を掛けると
12816:33552 と 12816:33553 になって、
先の部分の方がより角度が鋭くなっているのが判ります。
それを 144:377 の枠に収めようとするとうまく収まらず、はみだした部分を重ねるしかないので少し減って見える、と。
式とかよくわからないので
算数レベルの回答になってしまいましたが、
これで合ってますか？
ZooMark さん、こんにちは。
> 3/3 の問題の答えは「接した所で重なっている」ですか？
正解です！
# 管理者注：この答えを投稿していただいた時点では、
# M.Suzuki さんの投稿は公開されていませんでした。
> 途中で切れた２つの三角形は微妙に角度が違います。
> 正方形を半分にした三角形の比率は 144:377 ですが、
「長方形を半分にした…」ですね。
> 途中から先の部分の比率は 89:233。
> 比率を合せる為に、それぞれ 89 と 144 を掛けると
> 12816:33552 と 12816:33553 になって、
> 先の部分の方がより角度が鋭くなっているのが判ります。
12816:33553 と 12816:33552 で、長方形を半分にしたほうが
角度が鋭くなっています。
> それを 144:377 の枠に収めようとするとうまく収まらず、はみだした部分を重ねるしかないので少し減って見える、と。
> 式とかよくわからないので
> 算数レベルの回答になってしまいましたが、
> これで合ってますか？
途中に計算違いがありましたが、解き方と結果は合っています。
算数の問題ですから、算数の回答で OK です。
本当は「正しい図を描けば一発でわかる」と言いたいところ
なのですが、この問題はいじわるなので、トリックを見破る
には、かなり大きな絵を正確に描かなければなりません。
Kamada さん、こんにちわ。
あう。途中の説明が抜けてた為に話がズレてしまってごめんなさい。
> > 途中で切れた２つの三角形は微妙に角度が違います。
> > 正方形を半分にした三角形の比率は 144:377 ですが、
>
>「長方形を半分にした…」ですね。
はい。この「途中で切れた…」の文章の上には「ここでは長方形にだけ注目してみましょう」が入ります。
そして指摘通り、文章中の「正方形」は「長方形」の書き間違いです。
寝ぼけてて四角形の名前を間違えて書いてました。
（小学生でも間違えんて）
ZooMark さん、こんにちは。
> 寝ぼけてて四角形の名前を間違えて書いてました。
>（小学生でも間違えんて）
どんまいですぅ。
最初は「あれ？なんで？」と、思ったものの判りました。
なんか久しぶりに数学をやった気分です。
文章で書くのは難しいですが、4 分割した図形を左上を A、右上を B、左下を C、
残りを D とした場合、組み合わされた A+C の図形が本当に C の相似図形であるか
を証明すれば良い訳です。
式にすると、
89 233
--- = ---
144 377
これを解くと、
(233 * 144) 33552
89 = -----------→89 = -----
377 377
で、結果は
89 = 88.99734748010609901568…
と、言う訳で誤差が出ます。つまり、長方形の方では対角線に沿って台形部分
に僅かにすき間が空いていて、その分が誤差になっている筈です。
こんなもんでどうでしょう？
M.Suzuki さん、こんにちは。
> 最初は「あれ？なんで？」と、思ったものの判りました。
> なんか久しぶりに数学をやった気分です。
楽しんでいただけて嬉しいです。(^^;
> 文章で書くのは難しいですが、4 分割した図形を左上を A、右上を B、左下を C、
> 残りを D とした場合、組み合わされた A+C の図形が本当に C の相似図形であるか
> を証明すれば良い訳です。
：
> 89 = 88.99734748010609901568…
>
> と、言う訳で誤差が出ます。つまり、長方形の方では対角線に沿って台形部分
> に僅かにすき間が空いていて、その分が誤差になっている筈です。
>
> こんなもんでどうでしょう？
ほぼ、正解です！
「台形部分にすき間が空く」というよりも、「長方形の
対角線の部分がぶつかってしまうので、並べ替えても
長方形に入り切らない」または「並べ替えて長方形に
入れると、対角線の部分が重なってしまう」と表現すると
わかりやすいと思います。
長方形の対角線の重なってしまう部分は、長さが 400 以上で
面積が 1 しかない非常に細長い平行四辺形なので、見た目で
ごまかされてしまうというわけです。
鎌田さん、こんにちは。
> その証明方法はコンピュータを使ったエレファントな
> 解決法（「エレガントな解決法」の反対）でした。
昔に書かれたコンピュータの教科書には、
「どんなコンピュータを使ったところでこの問題を証明
することはできないだろう」
などと書いてありました。それがコンピュータを使って
証明されたわけですから、とても衝撃的な解決法だった
のでしょうね。
ところで、ムーアの地図は見たことがありません。
どんな地図なんでしょう？
ではでは。
広井さん、こんにちは。
> 昔に書かれたコンピュータの教科書には、
>
>「どんなコンピュータを使ったところでこの問題を証明
> することはできないだろう」
>
> などと書いてありました。それがコンピュータを使って
> 証明されたわけですから、とても衝撃的な解決法だった
> のでしょうね。
「コンピュータを使って証明する」と言うと、いかにも
有限個のパターンをしらみつぶしに調べるような印象が
あります。しかし、アッペルとハーケンが凄かったのは、
四色問題を十分に少ない有限個のパターンに帰着させる
作業そのものをコンピュータにやらせたことのようです。
コンピュータを単なる計算機としてではなく、証明のための
道具として使ったことが、当時としては衝撃的なことだった
ようです。
> ところで、ムーアの地図は見たことがありません。
> どんな地図なんでしょう？
「ムーアの地図」は 1963 年にウィスコンシン大学のムーア
という人が作った、円筒面上または球面上の地図です。
ムーアの地図は少なくとも 2 種類あって、1 つは 342 ヶ国、
もう 1 つは 846 ヶ国からなるそうです。
それらの地図は 4 色で塗り分けることが非常に難しかった
ために、当時は「四色問題の反例が見つかったらしい」
などとうわさになったそうです。
実際は、四色問題の解決が容易でないことを示すために、
それまでにわかっていた理論だけでは塗り分けられない
地図の例として作られたものだったようです。
参考文献：『四色問題』一松信著、講談社（ブルーバックス）
国立国会図書館（http://webopac2.ndl.go.jp/）の
簡易検索で出てきますが、入手は難しいかも知れません。
鎌田さん、こんにちは。
四色問題の説明はとても勉強になりました。
どうもありがとうございます。
> ムーアの地図は少なくとも 2 種類あって、1 つは 342 ヶ国、
> もう 1 つは 846 ヶ国からなるそうです。
ほえー！、ムーアの地図はとても大きいのね。
四色問題が証明されたとはいえ、ムーアの地図を塗り分ける
プログラムを作るのは、とても難しいのでしょうね。
私のＨＰで示した地図ならば、単純なバックトラックで
簡単に解けちゃいます（笑）。
>『四色問題』一松信著、講談社（ブルーバックス）
ブルーバックスならば、もしかすると図書館にあるかも
しれません。探してみようと思います。
それではまた。
広井さん、こんにちは。
> 四色問題の説明はとても勉強になりました。
> どうもありがとうございます。
どういたしましてです。
私も十分に理解しているわけではないのですが、こういう
「問題文は誰でも理解できるのに解くのが難しい問題」は
好きです。
> ほえー！、ムーアの地図はとても大きいのね。
私もムーアの地図の全体は見たことがありません。
見つけたら是非教えてください。
> 四色問題が証明されたとはいえ、ムーアの地図を塗り分ける
> プログラムを作るのは、とても難しいのでしょうね。
> 私のＨＰで示した地図ならば、単純なバックトラックで
> 簡単に解けちゃいます（笑）。
ん、広井さんの問題はアタマで解けました。
答えは何通りあるかな。
> >『四色問題』一松信著、講談社（ブルーバックス）
> ブルーバックスならば、もしかすると図書館にあるかも
> しれません。探してみようと思います。
そうですね。
絶版なので入手は難しいと思いますが、ブルーバックスが
揃っている図書館に行けばあると思います。
鎌田さん、こんにちは。
日記で四色問題解法プログラムのページを紹介して
いただき、ありがとうございます。
今回の問題は簡単でしたので Perl を使いました。
今度はもっと複雑な地図に挑戦してみようと思います。
もしかすると、地図を作る方が大変かもしれませんね（笑）。
それではまた。
広井さん、こんにちは。
> 日記で四色問題解法プログラムのページを紹介して
> いただき、ありがとうございます。
いえ、こちらこそ、引用していただいて嬉しかったです。
> 今回の問題は簡単でしたので Perl を使いました。
> 今度はもっと複雑な地図に挑戦してみようと思います。
> もしかすると、地図を作る方が大変かもしれませんね（笑）。
迷路などもそうですが、人間がやって面白いと感じられる
問題を自動生成することは、解くことよりも難しいと思います。
放送を S-VHS ビデオ経由で MPG-BOX/P にＳ端子接続し、最大性能を
出して 3.4GB 程度の MPEG1 ファイルに。
これを 1.7GB 程度に分解し、MediaStudio ６で AVI 化、さらに
MediaEncoder ７で MPEG7 化。
352x240 の鮮明度 100%・30fps の 696MB になりましたとさ。
700MB の CD-R に焼いて完成 (^^；
普通の人ならこれを 200％拡大モードで見れば充分なはず。
でも私は DVD 買ってしまうことだろう。
上記の映像だと、例えばエンディングのバックで雷雨に
なっているはずの箇所で雷がノイズ扱いにされて消えて
しまうので (^^；
# さて次の作業はＴ２だ。
VFC-LINK さん、こんにちは。
> 放送を S-VHS ビデオ経由で MPG-BOX/P にＳ端子接続し、最大性能を
> 出して 3.4GB 程度の MPEG1 ファイルに。
> これを 1.7GB 程度に分解し、MediaStudio ６で AVI 化、さらに
> MediaEncoder ７で MPEG7 化。
> 352x240 の鮮明度 100%・30fps の 696MB になりましたとさ。
> 700MB の CD-R に焼いて完成 (^^；
ずいぶん小さくなりましたねー。
ディスク 1 枚に入り切れば扱いやすいですよね。
うちのは 640×240 の MPEG-2 で 2.5GB もありますが、
それでも画質には不満が残ります。
やはり、リアルタイムでは転送速度ぎりぎりでなるべく
圧縮せずに保存しておいて、後から時間をかけて圧縮
したほうが綺麗に小さく圧縮できそうですね。
> 普通の人ならこれを 200％拡大モードで見れば充分なはず。
> でも私は DVD 買ってしまうことだろう。
> 上記の映像だと、例えばエンディングのバックで雷雨に
> なっているはずの箇所で雷がノイズ扱いにされて消えて
> しまうので (^^；
はは。
ラピュタのエンディングは遊び心にあふれていますよね。
クレジットの陰で雷雨になっていたり、土星が異様に
近かったり、大きな流れ星が横切ったり…
UFO がラピュタに降り立つ案は却下になったそうですが。
> やはり、リアルタイムでは転送速度ぎりぎりでなるべく
この１年ちょっとで得た経験から言うと
「いかにキャプチャ時に負担をかけないで行うか」
で画質が大きく変わります。
結果として CPU は 800MHz に、DISK は U160-SCSI ２台に、
メモリは 640MB になりました (^^；
それでもキャプチャ時の画面への出力もオフにし、
音声との合成処理もキャプチャ後に行うように設定
してます。
先月に出た MPEG2 キャプチャ機・USB-MPG2TV も画質は
すさまじいものを出してくれますが、細かな動作設定が
できないのでなんかコマ落ちしている感じになって
しまいますね。
# ２月年末だとすっきりするでしょ (^^；
VFC-LINK さん、こんにちは。
>「いかにキャプチャ時に負担をかけないで行うか」
> で画質が大きく変わります。
> 結果として CPU は 800MHz に、DISK は U160-SCSI ２台に、
> メモリは 640MB になりました (^^；
うーん、キャプチャーマシーンですね。（笑）
リアルタイムで綺麗に圧縮するためには速い CPU が必要、
綺麗に圧縮するとサイズが大きくなるので速い転送速度が必要、
瞬間的な過負荷に耐えるために大量のメモリが必要、
ですね。
> # ２月年末だとすっきりするでしょ (^^；
にゅ。
かまださん、お久しぶりです。
先日のミカヅキ、見逃し・録画り逃してしましました…。
何故かと云うと、２月はじめからドリームキャストの
ＰＳＯにドハマリしてしまい、平日はもちろんの事、
週末金曜日は徹夜でＰＳＯ漬けだからです。
ので、最近ＴＶもロクに見てません。せいぜいＮＨＫ
のプロジェクトＸぐらいしか見てません。
大抵、夜通し遊んで土曜の朝８時９時に寝てますので、
先週の土曜日、起きたら既に１８：００でした（涙）。
しかし、手にはビデオのリモコンを握っていたので、
もしかしたら１３時ごろに起きたのかも知れません…。
もちろん、録画はされてませんでした（笑）。謎です（笑）。
春麗さん、こんにちは。
> 先日のミカヅキ、見逃し・録画り逃してしましました…。
それは残念！
次回の放映まではまだ間があるので、その間に誰かに
ビデオを借りて観ましょう。（私でも OK だにょ)
> 何故かと云うと、２月はじめからドリームキャストの
> ＰＳＯにドハマリしてしまい、平日はもちろんの事、
> 週末金曜日は徹夜でＰＳＯ漬けだからです。
> ので、最近ＴＶもロクに見てません。せいぜいＮＨＫ
> のプロジェクトＸぐらいしか見てません。
う～ん、打ち込めるものがあるのはうらやましいにょ。（笑）
> 大抵、夜通し遊んで土曜の朝８時９時に寝てますので、
> 先週の土曜日、起きたら既に１８：００でした（涙）。
> しかし、手にはビデオのリモコンを握っていたので、
> もしかしたら１３時ごろに起きたのかも知れません…。
>
> もちろん、録画はされてませんでした（笑）。謎です（笑）。
寝ている間に「誰か」にリモコンを握らされていたとか…
こ、こわい…
皆さん初めまして。『ろっぱねっと』準備委員会の永井と申します。
この度自前サーバーが一定以上の稼働率を突破した事で６８ユーザー
間の気軽な情報交換を目的とした『６８ユーザーネットワーク』を
提供開始できればと考えています。
現在はネットワーク会員数が極わずかなので目立ったサービスは提供
しておりませんが、ユーザー数が (int) ６８を突破した時点から色々
始めたく、会員を募集開始しました。
まず始めに御提供できるサービスは、x68k.net ドメインのメールアド
レスです。 指定メールアドレスへ x68k.net メールアドレスより転送
致します。
会員登録、会費は無料です。
x68k.net に関する質問、無料メールアドレスのお申し込み、今後の
x68k.net の展開について御意見のある方は御遠慮なく、
X-PowerStation NetworkSolutions.
X68K.NET そこはかとなくぼちぼち頑張ろう
準備委員会広報担当 永井 nagai@x68k.net
まで御気軽にどうぞ！
日記より、
＞アメリカの文化には日本のようにとりあえず謝る気持ちを伝えるための謝罪の言葉というものが存在しないのでしょうか。
これ、私が思うに「存在しない」のだと思います。
その象徴的単語として「apologize」があります。
これには「謝る」という意味と同時に「言い訳する」と
いう意味もあります。
すなわち、アメリカ人にとっては、いいわけをする＝自己主張する
ことが謝っているという態度だということです。
日本は「まず謝れ」であり、まさに文化の違いなのですが、
個人的には米国流は非常に不快です。
（会社でもよくあります。）
悪い結果がでているなら、まず自分の非を認めてから、
今後の対策を言うべきなのにと思います。
今回の艦長のように、謝罪もせずに自分の無罪を得るために
弁護士を選んだなどと言う行動を聞くと、良心のなさに
怒りを覚えますし、これが一般的なら、
仮に間違って核兵器のボタンも押しても「正当防衛」などと
言い逃れしそうです。まあ、イラクへの攻撃なんぞ
その例だと思いますが。
すべてのアメリカ人が悪い人だとは思いたくないですが。
LeDA さん、こんにちは。
> すなわち、アメリカ人にとっては、いいわけをする＝自己主張する
> ことが謝っているという態度だということです。
日本人は曖昧な言葉を選び、アメリカ人はストレートに言う
という印象があるのですが、どうして自らの非を認める言葉は
ストレートに出てこないのでしょうね。
> 日本は「まず謝れ」であり、まさに文化の違いなのですが、
> 個人的には米国流は非常に不快です。
> 悪い結果がでているなら、まず自分の非を認めてから、
> 今後の対策を言うべきなのにと思います。
まったく同感です。
日米地位協定の問題もありますが、多民族国家のアメリカが
他国の文化をないがしろにするのは理に反していると思います。
結局、自分たちのやり方を押し付けているだけなのですから。
被害者の文化に合わせるくらいの融通もきかないようです。
> 多民族国家のアメリカが
> 他国の文化をないがしろにするのは理に反していると思います。
米国は他国から見れば多民族国家なのですが、
中に入れば「America is No.1」という教育が
徹底されているようなので、米国以外を軽視してしまう
人間が少なからずできてしまうようです。
そして、その No.1 の文化を世界に広めようとするやからも。
（大学生にもなって、ＳＯＮＹが米国の企業だと信じて疑わない
馬鹿も多数いるというのがその証拠か。世界に名だたる
ＳＯＮＹが日本の企業であるわけはない、と言うこと。）
本人は「他国の文化をなえがしろにしている」とは
思っていず、良いものを教えていると思っている
のでしょうが、これが他国にとっては押しつけ以外の
何者でもないと。
別に米国を敵視する気はないですが、時折そのようなやり方が
目に付きすぎることがあって、不快に思えることがあります。
ヨーロッパはそのような米国のやり方に対して、
時としてはっきり「ＮＯ」と言いますが、
日本政府はどうにも米国の言うことに従順すぎてだめだめですね。
（日本は本当に独立国なのか？と思うこともしばしば。）
もっとはっきりものが言える政府がほしいところです。
LeDA さん、こんにちは。
> ヨーロッパはそのような米国のやり方に対して、
> 時としてはっきり「ＮＯ」と言いますが、
> 日本政府はどうにも米国の言うことに従順すぎてだめだめですね。
>（日本は本当に独立国なのか？と思うこともしばしば。）
> もっとはっきりものが言える政府がほしいところです。
「日本はアメリカに守ってもらっている（アメリカは日本を
守ってやっている）」という意識を変えないとダメですよね。
日米地位協定のような不平等な協定もありますし。
今の世にあんな不平等な協定が許されるはずがありません。
石原都知事を首相に推す国民が多いのは、アメリカに対しても
何でもはっきり言ってくれるからだと思います。
石原さん一人でどうにかなるものでもないとは思いますが。
私から言わせればパクリです (爆)
とはいえ、私のマシン３台＋会社マシンに常駐中のは完成度
低すぎですけどもね (^^；
ま、この辺は能力の問題ってことで・・・。
http://homepage1.nifty.com/vfclink/ccc/garbage/dokodoke.htm
VFC-LINK さん、こんにちは。
> http://homepage1.nifty.com/vfclink/ccc/garbage/dokodoke.htm
んー、時計ついてきますねー。
X Window System で昔見た oneko を思い出してしまいました。
マウスポインタに猫がついてくるの。
相互リンクしていただいている「遊楽街」の管理者、小西です。
バナーを作ったので、リンクページで使って下さい。
小西さん、こんにちは。
> 相互リンクしていただいている「遊楽街」の管理者、小西です。
> バナーを作ったので、リンクページで使って下さい。
ご連絡ありがとうございます。
さっそく、リンク集を更新しました。
Kamada 様、お晩です。
「でじこ」って本名じゃ無かったんですか。
ガシャポンのリンクのおかげで判りました。
...... っていう素人？な私も拝見させてもらってます。
gussy さん、こんにちは。
>「でじこ」って本名じゃ無かったんですか。
> ガシャポンのリンクのおかげで判りました。
「でじこ」と「ぷちこ」は通称だにょ。「うさだ」は本名。
> ...... っていう素人？な私も拝見させてもらってます。
ありがとうございます。
（でじこの本名を知ったからには、もう素人じゃないにょ）
私も gussy さんの日記をこっそりチェックしていたりします。
「ハロ」とか、影響を受けています。
これからもよろしくです。
テレビ番組雑誌の TVstati○n には、フジテレビ明日 21 日の
深夜３時 35 分～４時５分の枠に
「鉄甲機ミカヅキＳＰ」ダイジェスト
ってあります。
フジテレビ Web の明日の番組表にはそんなこと一切書いて
いませんが (^^；TVstati○n の公式変更情報ページには
変更の届けは出ていません・・・。
変更の届けといえば、金曜■ードショーで予定されていた
米国ゴジラが延期になったそーで。
時節的に危ういシーンがあるそーで (^^；
TVstati○n 変更情報ページはここ。
VFC-LINK さん、こんにちは。
> テレビ番組雑誌の TVstati○n には、フジテレビ明日 21 日の
> 深夜３時 35 分～４時５分の枠に
>「鉄甲機ミカヅキＳＰ」ダイジェスト
> ってあります。
>
> フジテレビ Web の明日の番組表にはそんなこと一切書いて
> いませんが (^^；TVstati○n の公式変更情報ページには
> 変更の届けは出ていません・・・。
インターネット TV ガイドにも書いてあったのですが、
21 日午前 4 時頃、「現在の番組表」の日付が変わると同時に
消えました。
以前は予定されていたものの、中止になったのでしょう。
残念。