← 前のページ | 1 | 5 6 7 8 9 10 11 12 13 14 15 | 28 | 次のページ →

683. こんなのみつけましたはんかつ 2001年3月18日(日) 01:06

まだ作ってる会社があったとは!

http://www.fuki.co.jp/mall/index.html

684. Re: こんなのみつけましたM.Kamada  2001年3月18日(日) 03:15

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

> まだ作ってる会社があったとは!

> http://www.fuki.co.jp/mall/index.html

おー、自転車にエンジン載ってますねぇ。

これで楽をしたいときは、アシスト自転車と違って原付の

免許が必要ですが、自転車よりも速く走ったら危なそうですね。

自転車のタイヤで普通の自転車よりも重いから、自転車並の

速さでも危ないかも知れない。

いわゆる「原付」が「原動機付自転車」の略語であること

を思い出して、ちょっと納得。


677. 私じじいかな?はんかつ 2001年3月13日(火) 20:06

鎌田さんおひさしぶりです はんかつです。

>ZETA3ポータブル自転車パワーアシストシステム

 世界初といいますが、私の子供のころにはガソリンエンジン

を使ったこんなやつが日本を走り回っておりました。

 あのホンダも最初はこれから始めたのです。

678. Re: 私じじいかな?M.Kamada  2001年3月13日(火) 22:01

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

> >ZETA3ポータブル自転車パワーアシストシステム

>  世界初といいますが、私の子供のころにはガソリンエンジン

> を使ったこんなやつが日本を走り回っておりました。

>  あのホンダも最初はこれから始めたのです。

これ↓ですね。

http://www.honda.co.jp/50years-history/001.html

普通の自転車に動力を乗せてしまう発想はオートバイの

原点だったのですね。(普通に納得)

しかし、さすがにこれが普通に道路を走っているところは

見たことがありません。

私が子供の頃は、廃車置場に置かれていたオート三輪を見て

「この変なカタチの乗り物は何だろう?」って思っていました。


676. マウス売りに出しましたLeDA 2001年3月13日(火) 09:26

マウス2台とマウストラックボール1台を、また

HST X68000 Roomさんに売りに出しました。

興味のある方はどうぞ。

新品ではないですが、効かないスイッチは交換済みの

感動・・・もとい、完動品です。

681. Re: マウス売りに出しましたM.Kamada  2001年3月14日(水) 21:19

LeDAさん、こんにちは。

> マウス2台とマウストラックボール1台を、また

> HST X68000 Roomさんに売りに出しました。

マウス・トラックボールというと、「ふたを取って底面の

スイッチを切り替えるとボールが持ち上がってマウスから

トラックボールに早変わりするという、X68000の発売当初に

話題になった斬新な発想のマウスですね。

本体に標準で付属している機種とそうでない機種がありますが、

X68000シリーズならばどの機種でも使えます。

トラックボールに切り替えればボールを指でくりくりできるので、

特にマウスを動かすスペースがない人は重宝すると思います。

トラックボールのときに押しやすいように、上面だけでなく

側面にもボタンが付いています。(機能は上面のボタンと同じ)

682. Re^2: マウス売りに出しましたLeDA 2001年3月15日(木) 09:27

> マウス・トラックボールというと、「ふたを取って底面の

> スイッチを切り替えるとボールが持ち上がってマウスから

> トラックボールに早変わりするという、X68000の発売当初に

> 話題になった斬新な発想のマウスですね。

私はこれを愛用していて、現在手元で実働しているX68030、

CompactXVI2台、XVI、030Compact全てにこれを付けています。

机の上が狭いので普通のマウスではやりづらい、という

事情もあります(^_^;)

手の上で転がすには最適なので、Win用にもあればいいのですが、

全く同じような物はないですね。SHARPの特許なのかな?

ちなみに、今日現在売れてません。

以外と需要がないのかも。

なければないで自分の予備品に回すだけなのですが。


674. 中学生日記みかぜ  2001年3月13日(火) 03:51

電撃G’zを嬉々として読み耽る女子中学生……

そのうち「萌え~」とか言い出すかも。

こうしてマーケットは予想外のターゲットへと広がって行くのですね。

ブロッコリーの店舗数がソフマップを越える日も遠くないかも。

675. Re: 中学生日記M.Kamada  2001年3月13日(火) 05:20

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

> 電撃G’zを嬉々として読み耽る女子中学生……

> そのうち「萌え~」とか言い出すかも。

それはこわいっす。

「まじんがっぱグッズ集めてるの~」くらいならいいけど。

> こうしてマーケットは予想外のターゲットへと広がって行くのですね

> ブロッコリーの店舗数がソフマップを越える日も遠くないかも。

子供の遊びがテレビゲームからカードゲームに移りつつある中で

成長を続けるブロッコリーですが、現在のゲーマーズの店舗の

増え方は「節操なし」の域には達していないと思います。

キャラクターグッズ屋さんとデジタルグッズ屋さん(笑)を

比較するのは難しいですね。


669. C vs ASMLeDA 2001年3月12日(月) 09:39

>C言語を完全に理解したければ、アセンブラを少しはかじっておくべきです。

全く同感です。

ただCで書けるというのと、その特性を知って生かすというのは

違う能力だと思います。特に、OSを記述するときや、

組み込みマイコンで記述するときは重要と思っています。

私は。

能力やサイズでの制限が多いですから。

それを他人に言っても理解されないところがありますが。

Cは、他の言語に比べアセンブルコードが想像できるのが

好きなところでもあります。

その意味ではC++は似て非なる物と感じています。

それが、私がC++を習得できず未だにCだけで

やっている理由でもあります。

だめ?

673. Re: C vs ASMM.Kamada  2001年3月12日(月) 21:33

LeDAさん、こんにちは。

> >C言語を完全に理解したければ、アセンブラを少しはかじっておくべきです。

>

> 全く同感です。

> ただCで書けるというのと、その特性を知って生かすというのは

> 違う能力だと思います。特に、OSを記述するときや、

> 組み込みマイコンで記述するときは重要と思っています。

> 私は。

> 能力やサイズでの制限が多いですから。

その通りだと思います。

賛同していただけて嬉しいです。(^^;

> それを他人に言っても理解されないところがありますが。

知らない人に理解してもらうのって大変ですよね。

わざわざサンプルプログラムを作って見せてもわかって

もらえなかったりすると悲しくなります。

> Cは、他の言語に比べアセンブルコードが想像できるのが

> 好きなところでもあります。

同感です。

> その意味ではC++は似て非なる物と感じています。

> それが、私がC++を習得できず未だにCだけで

> やっている理由でもあります。

> だめ?

わたくし的には、全然おっけーだと思います。

私もC++を積極的に使いたいとは思いません。

必要があってC++のソースを読むことがありますが、

「Cで書いてくれたほうが読みやすいのに…」と思うことが

多いです。書き方にもよるかも知れませんが。

本質的に、CとC++の違いは、アセンブラとCの違いよりも

大きいと思います。

C++はコンピュータの高級言語の1つであって、不幸にも

C++最初に覚えてしまった人が後からCを完全に理解するのは

大変だろうと思います。

C++は、用途や開発環境によっては使いやすい高級言語の1つ

にすぎず、Cに取って代わるべき言語ではないと思います。


664. アセンブラ最適化問題ゆうき喬史 2001年3月11日(日) 01:38

こんにちは、ゆうき喬史です。

アセンブラの最適化問題やってみました。

;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をいれましょう。

・・・って、ちゃんと動作するのか不安(~~;

665. Re: アセンブラ最適化問題M.Kamada  2001年3月11日(日) 02:23

ゆうき喬史さん、こんにちは。

> アセンブラの最適化問題やってみました。

一番乗りです!

投稿ありがとうございます。

> ;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クロックの節約。

666. Re^2: アセンブラ最適化問題なかむら 2001年3月11日(日) 23:01

鎌田さん、こんにちは。

さらに短くできるという話を見て、私も最適化問題に挑戦してみました。

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フラグをここまで持ち越す

のがミソでしょうね。

667. Re^3: アセンブラ最適化問題M.Kamada  2001年3月12日(月) 00:25

なかむらさん、こんにちは。

どちらのなかむらさんかなと思ってメアドをチェック…

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ワードになって

いますので、正解です。

サイズの最適化の正解が出たところで、もう1つ。

実は、同じサイズで、もっと速い(クロック数が少ない)

方法が存在します。

サイズだけでなく動作速度も最適化してみてください。

668. Re: アセンブラ最適化問題鈴木.K 2001年3月12日(月) 09:22

はじめまして. こんにちは.

自分も考えてみました.

> add.w d0,d0 ;加算結果の符号ビットを押し出す

正+正か、負+負でなければオーバーフローしないので、あらためて

Xビットを変化させなくても、オーバーフローした側によって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)

となるので、あとはひっくり返して終わり.

一応確認もしたのでこれで合っていると思いますけど...

670. Re^2: アセンブラ最適化問題M.Kamada  2001年3月12日(月) 15:35

鈴木Kさん、こんにちは。はじめまして。

> 自分も考えてみました.

ありがとうございます。

> > add.w d0,d0 ;加算結果の符号ビットを押し出す

> 正+正か、負+負でなければオーバーフローしないので、あらためて

> Xビットを変化させなくても、オーバーフローした側によってXビット

> の中身は決まっています. それを活用します.

ご明察です。

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クロックです。

671. Re^3: アセンブラ最適化問題なかむら 2001年3月12日(月) 17:05

なかむらです。こんにちは。

う~む、あと一歩でしたか。残念。^^;

しかしこの手の最適化は一種パズル的な面白さがあっていいですね。

仕事で某RISC CPUをいじってたりしますが、これだとそもそもフラグレジスタが

なかったりして、どうやってもCで普通に書いたのと同じような結果になって

しまいます。いや、RISCって本来そういうものなんですけど。

672. Re^4: アセンブラ最適化問題M.Kamada  2001年3月12日(月) 20:38

なかむらさん、こんにちは。

> う~む、あと一歩でしたか。残念。^^;

サイズの最適化という当初の目的は達していましたからOKです。

でも、速度も最適化しないと気が済まないという気持ちは

よくわかります。(笑)

> しかしこの手の最適化は一種パズル的な面白さがあっていいですね。

そうですね。

パズル感覚で楽しめることもアセンブラの魅力の1つだと思います。

> 仕事で某RISC CPUをいじってたりしますが、これだとそもそもフラグレジスタが

> なかったりして、どうやってもCで普通に書いたのと同じような結果になって

> しまいます。いや、RISCって本来そういうものなんですけど。

RISCプロセッサのアーキテクチャは、コンパイラの使用を

前提にして設計されているものが多いですよね。

でも、中にはAlphaのバイト操作命令のように「コンパイラ

だけに使わせるのはもったいなさそうなトリッキーな命令」

を持っているRISCプロセッサもありますから、「RISC=

アセンブラで書く意味がない」とは限らないと思います。

設計した人が意図しなかったと思われる使い方ができる

アーキテクチャは面白いと思います。

679. Re^3: アセンブラ最適化問題ゆうき喬史 2001年3月14日(水) 12:56

こんにちは。

最適化問題の最速・最短の回答って、実は、

自分も最初に思いつきました。

でも、頭の中で、最初の加算のXビットの値を

検証してるうちになぜか、Xビットの値は不定

という結論に・・・(^^;

考えすぎて、間違った結論出すことってよく

ありますよね?

680. Re^4: アセンブラ最適化問題M.Kamada  2001年3月14日(水) 15:35

ゆうき喬史さん、こんにちは。

> 最適化問題の最速・最短の回答って、実は、

> 自分も最初に思いつきました。

>

> でも、頭の中で、最初の加算のXビットの値を

> 検証してるうちになぜか、Xビットの値は不定

> という結論に・・・(^^;

>

> 考えすぎて、間違った結論出すことってよく

> ありますよね?

そうですね。

こういうときはレジスタやフラグの変化を細かく書き出して

考えるとよいと思います。

私はよくソースの注釈に書き込みます。

そうしておくと後で見直すときにもわかりやすいですし。

「符号付き加算で符号が違うときは絶対にオーバーフローしない」

この性質も覚えておくと何かと考えやすくなると思います。


654. 8K-OSLeDA 2001年3月7日(水) 09:39

8KのOSでネットワーク(TCP/IP)につながるとしたら、

すごいことだと思うのですが、それしか出来ないのでは?

と言う気もします。だったら、OSと言うよりやはり

BIOSと呼ぶのがよいような。

実は私もX68でも動くμITRONを作っていたりしますが、

8Kというのはかなり小さいと感じています。

私のX68版はタスク同期、1ビットイベントフラグ、

セマフォ、タスク間メイルを含めて17Kもあります。

まあカーネル以外は全部Cで書いてありますし、

機能限定すればサイズ縮小は可能ですが。

(X68専用ではなく、MPU680x0用で、各種CPU移植を

最大に考慮しているもの。ライブラリ形式なので

各種プログラムの中に組み込んで一時的なマルチタスクを

行うことも可能。86版、三菱7902版、

Z80版、松下MN101C、日立H8版があり。もちろん

仕事で作ったので非公開。)

X68で10Kを切れると良いんですけど、

私の能力ではできてません。

658. Re: 8K-OSM.Kamada  2001年3月8日(木) 20:09

LeDAさん、こんにちは。

> X68で10Kを切れると良いんですけど、

> 私の能力ではできてません。

M68K用のコードが、8ビット用のコードよりも大きく

なってしまうのは仕方ないと思います。

X68000を含むM68K汎用のライブラリでは、外部参照に

ショートブランチや絶対ショートアドレッシングなどを

使いにくいでしょうし。

動作を速くするのではなくてコードを短くする最適化

というのも結構面白いです。

ROMの容量に限りがあった昔のBIOSやモニタROMは

よく詰め込んだものだと思います。

662. Re^2: 8K-OSLeDA 2001年3月9日(金) 09:40

> ROMの容量に限りがあった昔のBIOSやモニタROMは

> よく詰め込んだものだと思います。

Z80の時代には、16進コードレベルでの最適化

というかトリックを使ってサイズ縮小とかスピードアップを

してましたが(そういえば16進でZ80が読めたなぁ)、

さすがに16ビット以上クラスでは出来ないですね。

あぁ懐かしい時代。

CD = CALL

C9 = RET・・・

663. Re^3: 8K-OSM.Kamada  2001年3月9日(金) 20:11

LeDAさん、こんにちは。

> Z80の時代には、16進コードレベルでの最適化

> というかトリックを使ってサイズ縮小とかスピードアップを

> してましたが(そういえば16進でZ80が読めたなぁ)、

やってたやってた。

まともなアセンブラを持っていなかったこともあって、

Z80のプログラムは頭でアセンブルしていました。

それでマンデルブロ集合とか描いていました。

(昔からそんなことばかりやっていたらしい)

> さすがに16ビット以上クラスでは出来ないですね。

> あぁ懐かしい時代。

16ビットでもM68Kなら結構無茶なことをやります。

オペコードを演算に使ったり、オペランドにオペコードを

埋め込んでオペランドに飛び込んだり、MC68000専用なら

命令やオペランドの自己書き換えだってやります。

開発効率や保守性を尊重するのは一般論であって、

それらを犠牲にしてでもコードを縮めたり速くしたり

する必要が生じることはあります。

まあ、私がやるのはほとんど趣味ですけど。


652. 8kbyte OSM.Suzuki 2001年3月7日(水) 01:22

「8KByteのOSを家電全部に入れてしまえ」との事ですが、それってTRONの「どこでもコンピュータ」と同じ方針ですね。

ネットワークに繋がるとの事ですが、TCP/IPが乗ってるんでしょうか。

ちなみに、ITRONには適応化と言う秘技が有って、アプリケーションが使用しないシステムコールを削る事が出来たりします。

そうすると、8ビット向けの物なら8Kなんか余裕で切る場合も有るでしょう。

それに、今のワンチップは大容量です。1cm四方のチップに128Kbyteのメモリー(H8等)も有るので、大きさはあんまり問題にならなくなってきてます。

あと、組み込み用でシングルタスクだとしたら、ネットワーク・スタックだけだろうから、OSとは言わずライブラリとかモニタとか言う気がするのは私だけでしょうか(笑)

657. Re: 8kbyte OSM.Kamada  2001年3月8日(木) 20:08

M.Suzukiさん、こんにちは。

> 「8KByteのOSを家電全部に入れてしまえ」との事ですが、それってTRONの「どこでもコンピュータ」と同じ方針ですね。

ほんと、同じというか、そっくりですよね。

誰が最初に言い出したのかな。

> ネットワークに繋がるとの事ですが、TCP/IPが乗ってるんでしょうか。

どうなんでしょう。

ネットワークに接続するために必要なプロトコルが別だと

したら、小さいことをアピールする意味が薄れてしまう

ような気がします。

> ちなみに、ITRONには適応化と言う秘技が有って、アプリケーションが使用しないシステムコールを削る事が出来たりします。

> そうすると、8ビット向けの物なら8Kなんか余裕で切る場合も有るでしょう。

> それに、今のワンチップは大容量です。1cm四方のチップに128Kbyteのメモリー(H8等)も有るので、大きさはあんまり問題にならなくなってきてます。

コストの問題もあると思いますが、最近は大容量のチップも

安くなっていますよね。

> あと、組み込み用でシングルタスクだとしたら、ネットワーク・スタックだけだろうから、OSとは言わずライブラリとかモニタとか言う気がするのは私だけでしょうか(笑)

同感。


650. CU-21CD売りに出してますLeDA 2001年3月6日(火) 13:28

会社で使ってた、X68用モニターのCU-21CD

を2台(黒とグレー)、個人売買の掲示板のある

HST X68000 ROOMさんに出しています。

興味のある方はどうぞ。

651. Re: CU-21CD売りに出してますM.Kamada  2001年3月6日(火) 22:56

LeDAさん、こんにちは。

> 会社で使ってた、X68用モニターのCU-21CD

> を2台(黒とグレー)、個人売買の掲示板のある

> HST X68000 ROOMさんに出しています。

>

> 興味のある方はどうぞ。

CU-21CDは21インチで15/24/31kHzが入るモニタですね。

マイコンソフト/電波新聞社のXRGB-2の接続は要注意。

HST X68000 Roomはこちらです。

http://www.cablenet.ne.jp/~hst/x68k/

653. Re^2: CU-21CD売りに出してますLeDA 2001年3月7日(水) 09:29

> CU-21CDは21インチで15/24/31kHzが入るモニタですね。

> マイコンソフト/電波新聞社のXRGB-2の接続は要注意。

そうです。

XRGB-2使用時は、31KHzモードは使わず15KHzを使えと

書いてあります。

まあ、X68だけで使っている分には問題ないのですが。

655. Re^3: CU-21CD売りに出してますM.Kamada  2001年3月7日(水) 14:30

LeDAさん、こんにちは。

> > CU-21CDは21インチで15/24/31kHzが入るモニタですね。

> > マイコンソフト/電波新聞社のXRGB-2の接続は要注意。

>

> そうです。

> XRGB-2使用時は、31KHzモードは使わず15KHzを使えと

> 書いてあります。

実物を見ていないので具体的にどうダメなのかわかりませんが、

↓ここ↓には「接続はお奨めできない」と書いてあります。

http://www.dempa.co.jp/MICOMSOFT/XRGB-2.html

656. Re^4: CU-21CD売りに出してますLeDA 2001年3月8日(木) 09:45

モニターは、黒は早速売れてしまいました。

さすがはインターネットと言うところです。

実は手元に純正マウスもいくつか(なぜか3個くらい)

余っているので、スイッチを取り替えて動くようにして

売りに出そうかな。

←売りに目覚めた!?(^_^;)

659. Re^5: CU-21CD売りに出してますM.Kamada  2001年3月8日(木) 20:09

LeDAさん、こんにちは。

> モニターは、黒は早速売れてしまいました。

> さすがはインターネットと言うところです。

お、早いですね。

あと1台ですね。

> 実は手元に純正マウスもいくつか(なぜか3個くらい)

> 余っているので、スイッチを取り替えて動くようにして

> 売りに出そうかな。

> ←売りに目覚めた!?(^_^;)

純正マウスは貴重ですよね。消耗品ですし。


643. 消えた面積ZooMark 2001年3月4日(日) 02:51

Kamadaさん、こんばんわ。

3/3の問題の答えは「接した所で重なっている」ですか?

途中で切れた2つの三角形は微妙に角度が違います。

正方形を半分にした三角形の比率は144:377ですが、

途中から先の部分の比率は89:233。

比率を合せる為に、それぞれ89と144を掛けると

12816:33552と12816:33553になって、

先の部分の方がより角度が鋭くなっているのが判ります。

それを144:377の枠に収めようとするとうまく収まらず、はみだした部分を重ねるしかないので少し減って見える、と。

式とかよくわからないので

算数レベルの回答になってしまいましたが、

これで合ってますか?

647. Re: 消えた面積M.Kamada  2001年3月4日(日) 04:50

ZooMarkさん、こんにちは。

> 3/3の問題の答えは「接した所で重なっている」ですか?

正解です!

# 管理者注:この答えを投稿していただいた時点では、

# M.Suzukiさんの投稿は公開されていませんでした。

> 途中で切れた2つの三角形は微妙に角度が違います。

> 正方形を半分にした三角形の比率は144:377ですが、

「長方形を半分にした…」ですね。

> 途中から先の部分の比率は89:233。

> 比率を合せる為に、それぞれ89と144を掛けると

> 12816:33552と12816:33553になって、

> 先の部分の方がより角度が鋭くなっているのが判ります。

12816:33553と12816:33552で、長方形を半分にしたほうが

角度が鋭くなっています。

> それを144:377の枠に収めようとするとうまく収まらず、はみだした部分を重ねるしかないので少し減って見える、と。

> 式とかよくわからないので

> 算数レベルの回答になってしまいましたが、

> これで合ってますか?

途中に計算違いがありましたが、解き方と結果は合っています。

算数の問題ですから、算数の回答でOKです。

本当は「正しい図を描けば一発でわかる」と言いたいところ

なのですが、この問題はいじわるなので、トリックを見破る

には、かなり大きな絵を正確に描かなければなりません。

648. Re^2: 消えた面積ZooMark 2001年3月4日(日) 11:24

Kamadaさん、こんにちわ。

あう。途中の説明が抜けてた為に話がズレてしまってごめんなさい。

> > 途中で切れた2つの三角形は微妙に角度が違います。

> > 正方形を半分にした三角形の比率は144:377ですが、

>

> 「長方形を半分にした…」ですね。

はい。この「途中で切れた…」の文章の上には「ここでは長方形にだけ注目してみましょう」が入ります。

そして指摘通り、文章中の「正方形」は「長方形」の書き間違いです。

寝ぼけてて四角形の名前を間違えて書いてました。

(小学生でも間違えんて)

649. Re^3: 消えた面積M.Kamada  2001年3月4日(日) 14:50

ZooMarkさん、こんにちは。

> 寝ぼけてて四角形の名前を間違えて書いてました。

> (小学生でも間違えんて)

どんまいですぅ。


642. 算数問題(?)M.Suzuki 2001年3月4日(日) 01:49

最初は「あれ?なんで?」と、思ったものの判りました。

なんか久しぶりに数学をやった気分です。

文章で書くのは難しいですが、4分割した図形を左上をA、右上をB、左下をC、

残りをDとした場合、組み合わされたA+Cの図形が本当にCの相似図形であるか

を証明すれば良い訳です。

式にすると、

89 233

--- = ---

144 377

これを解くと、

(233 * 144) 33552

89 = ----------- → 89 = -----

377 377

で、結果は

89 = 88.99734748010609901568…

と、言う訳で誤差が出ます。つまり、長方形の方では対角線に沿って台形部分

に僅かにすき間が空いていて、その分が誤差になっている筈です。

こんなもんでどうでしょう?

646. Re: 算数問題(?)M.Kamada  2001年3月4日(日) 04:47

M.Suzukiさん、こんにちは。

> 最初は「あれ?なんで?」と、思ったものの判りました。

> なんか久しぶりに数学をやった気分です。

楽しんでいただけて嬉しいです。(^^;

> 文章で書くのは難しいですが、4分割した図形を左上をA、右上をB、左下をC、

> 残りをDとした場合、組み合わされたA+Cの図形が本当にCの相似図形であるか

> を証明すれば良い訳です。

> 89 = 88.99734748010609901568…

>

> と、言う訳で誤差が出ます。つまり、長方形の方では対角線に沿って台形部分

> に僅かにすき間が空いていて、その分が誤差になっている筈です。

>

> こんなもんでどうでしょう?

ほぼ、正解です!

「台形部分にすき間が空く」というよりも、「長方形の

対角線の部分がぶつかってしまうので、並べ替えても

長方形に入り切らない」または「並べ替えて長方形に

入れると、対角線の部分が重なってしまう」と表現すると

わかりやすいと思います。

長方形の対角線の重なってしまう部分は、長さが400以上で

面積が1しかない非常に細長い平行四辺形なので、見た目で

ごまかされてしまうというわけです。


638. 四色問題Hiroi Makoto  2001年3月3日(土) 15:08

鎌田さん、こんにちは。

>その証明方法はコンピュータを使ったエレファントな

>解決法(「エレガントな解決法」の反対)でした。

昔に書かれたコンピュータの教科書には、

「どんなコンピュータを使ったところでこの問題を証明

することはできないだろう」

などと書いてありました。それがコンピュータを使って

証明されたわけですから、とても衝撃的な解決法だった

のでしょうね。

ところで、ムーアの地図は見たことがありません。

どんな地図なんでしょう?

ではでは。

639. Re: 四色問題M.Kamada  2001年3月3日(土) 17:59

広井さん、こんにちは。

> 昔に書かれたコンピュータの教科書には、

>

> 「どんなコンピュータを使ったところでこの問題を証明

> することはできないだろう」

>

> などと書いてありました。それがコンピュータを使って

> 証明されたわけですから、とても衝撃的な解決法だった

> のでしょうね。

「コンピュータを使って証明する」と言うと、いかにも

有限個のパターンをしらみつぶしに調べるような印象が

あります。しかし、アッペルとハーケンが凄かったのは、

四色問題を十分に少ない有限個のパターンに帰着させる

作業そのものをコンピュータにやらせたことのようです。

コンピュータを単なる計算機としてではなく、証明のための

道具として使ったことが、当時としては衝撃的なことだった

ようです。

> ところで、ムーアの地図は見たことがありません。

> どんな地図なんでしょう?

「ムーアの地図」は1963年にウィスコンシン大学のムーア

という人が作った、円筒面上または球面上の地図です。

ムーアの地図は少なくとも2種類あって、1つは342ヶ国、

もう1つは846ヶ国からなるそうです。

それらの地図は4色で塗り分けることが非常に難しかった

ために、当時は「四色問題の反例が見つかったらしい」

などとうわさになったそうです。

実際は、四色問題の解決が容易でないことを示すために、

それまでにわかっていた理論だけでは塗り分けられない

地図の例として作られたものだったようです。

参考文献:『四色問題』一松信著、講談社(ブルーバックス)

国立国会図書館(http://webopac2.ndl.go.jp/)の

簡易検索で出てきますが、入手は難しいかも知れません。

640. Re^2: 四色問題Hiroi Makoto  2001年3月3日(土) 20:39

鎌田さん、こんにちは。

四色問題の説明はとても勉強になりました。

どうもありがとうございます。

> ムーアの地図は少なくとも2種類あって、1つは342ヶ国、

> もう1つは846ヶ国からなるそうです。

ほえー!、ムーアの地図はとても大きいのね。

四色問題が証明されたとはいえ、ムーアの地図を塗り分ける

プログラムを作るのは、とても難しいのでしょうね。

私のHPで示した地図ならば、単純なバックトラックで

簡単に解けちゃいます(笑)。

>『四色問題』一松信著、講談社(ブルーバックス)

ブルーバックスならば、もしかすると図書館にあるかも

しれません。探してみようと思います。

それではまた。

644. Re^3: 四色問題M.Kamada  2001年3月4日(日) 04:46

広井さん、こんにちは。

> 四色問題の説明はとても勉強になりました。

> どうもありがとうございます。

どういたしましてです。

私も十分に理解しているわけではないのですが、こういう

「問題文は誰でも理解できるのに解くのが難しい問題」は

好きです。

> ほえー!、ムーアの地図はとても大きいのね。

私もムーアの地図の全体は見たことがありません。

見つけたら是非教えてください。

> 四色問題が証明されたとはいえ、ムーアの地図を塗り分ける

> プログラムを作るのは、とても難しいのでしょうね。

> 私のHPで示した地図ならば、単純なバックトラックで

> 簡単に解けちゃいます(笑)。

ん、広井さんの問題はアタマで解けました。

答えは何通りあるかな。

> >『四色問題』一松信著、講談社(ブルーバックス)

> ブルーバックスならば、もしかすると図書館にあるかも

> しれません。探してみようと思います。

そうですね。

絶版なので入手は難しいと思いますが、ブルーバックスが

揃っている図書館に行けばあると思います。

660. Re^4: 四色問題Hiroi Makoto  2001年3月8日(木) 23:23

鎌田さん、こんにちは。

日記で四色問題解法プログラムのページを紹介して

いただき、ありがとうございます。

今回の問題は簡単でしたので Perl を使いました。

今度はもっと複雑な地図に挑戦してみようと思います。

もしかすると、地図を作る方が大変かもしれませんね(笑)。

それではまた。

661. Re^5: 四色問題M.Kamada  2001年3月9日(金) 02:03

広井さん、こんにちは。

> 日記で四色問題解法プログラムのページを紹介して

> いただき、ありがとうございます。

いえ、こちらこそ、引用していただいて嬉しかったです。

> 今回の問題は簡単でしたので Perl を使いました。

> 今度はもっと複雑な地図に挑戦してみようと思います。

> もしかすると、地図を作る方が大変かもしれませんね(笑)。

迷路などもそうですが、人間がやって面白いと感じられる

問題を自動生成することは、解くことよりも難しいと思います。


636. ラピュタVFC-LINK 2001年2月28日(水) 01:32

放送をS-VHSビデオ経由でMPG-BOX/PにS端子接続し、最大性能を

出して3.4GB程度のMPEG1ファイルに。

これを1.7GB程度に分解し、MediaStudio6でAVI化、さらに

MediaEncoder7でMPEG7化。

352x240の鮮明度100%・30fpsの696MBになりましたとさ。

700MBのCD-Rに焼いて完成(^^;

普通の人ならこれを200%拡大モードで見れば充分なはず。

でも私はDVD買ってしまうことだろう。

上記の映像だと、例えばエンディングのバックで雷雨に

なっているはずの箇所で雷がノイズ扱いにされて消えて

しまうので(^^;

# さて次の作業はT2だ。

637. Re: ラピュタM.Kamada  2001年2月28日(水) 19:59

VFC-LINKさん、こんにちは。

> 放送をS-VHSビデオ経由でMPG-BOX/PにS端子接続し、最大性能を

> 出して3.4GB程度のMPEG1ファイルに。

> これを1.7GB程度に分解し、MediaStudio6でAVI化、さらに

> MediaEncoder7でMPEG7化。

> 352x240の鮮明度100%・30fpsの696MBになりましたとさ。

> 700MBのCD-Rに焼いて完成(^^;

ずいぶん小さくなりましたねー。

ディスク1枚に入り切れば扱いやすいですよね。

うちのは640×240のMPEG-2で2.5GBもありますが、

それでも画質には不満が残ります。

やはり、リアルタイムでは転送速度ぎりぎりでなるべく

圧縮せずに保存しておいて、後から時間をかけて圧縮

したほうが綺麗に小さく圧縮できそうですね。

> 普通の人ならこれを200%拡大モードで見れば充分なはず。

> でも私はDVD買ってしまうことだろう。

> 上記の映像だと、例えばエンディングのバックで雷雨に

> なっているはずの箇所で雷がノイズ扱いにされて消えて

> しまうので(^^;

はは。

ラピュタのエンディングは遊び心にあふれていますよね。

クレジットの陰で雷雨になっていたり、土星が異様に

近かったり、大きな流れ星が横切ったり…

UFOがラピュタに降り立つ案は却下になったそうですが。

641. Re^2: ラピュタVFC-LINK 2001年3月4日(日) 00:52

> やはり、リアルタイムでは転送速度ぎりぎりでなるべく

この1年ちょっとで得た経験から言うと

「いかにキャプチャ時に負担をかけないで行うか」

で画質が大きく変わります。

結果としてCPUは800MHzに、DISKはU160-SCSI2台に、

メモリは640MBになりました(^^;

それでもキャプチャ時の画面への出力もオフにし、

音声との合成処理もキャプチャ後に行うように設定

してます。

先月に出たMPEG2キャプチャ機・USB-MPG2TVも画質は

すさまじいものを出してくれますが、細かな動作設定が

できないのでなんかコマ落ちしている感じになって

しまいますね。

# 2月年末だとすっきりするでしょ(^^;

645. Re^3: ラピュタM.Kamada  2001年3月4日(日) 04:46

VFC-LINKさん、こんにちは。

> 「いかにキャプチャ時に負担をかけないで行うか」

> で画質が大きく変わります。

> 結果としてCPUは800MHzに、DISKはU160-SCSI2台に、

> メモリは640MBになりました(^^;

うーん、キャプチャーマシーンですね。(笑)

リアルタイムで綺麗に圧縮するためには速いCPUが必要、

綺麗に圧縮するとサイズが大きくなるので速い転送速度が必要、

瞬間的な過負荷に耐えるために大量のメモリが必要、

ですね。

> # 2月年末だとすっきりするでしょ(^^;

にゅ。


633. あぅー、ミカヅキ…春麗 2001年2月27日(火) 13:01

かまださん、お久しぶりです。

先日のミカヅキ、見逃し・録画り逃してしましました…。

何故かと云うと、2月はじめからドリームキャストの

PSOにドハマリしてしまい、平日はもちろんの事、

週末金曜日は徹夜でPSO漬けだからです。

ので、最近TVもロクに見てません。せいぜいNHK

のプロジェクトXぐらいしか見てません。

大抵、夜通し遊んで土曜の朝8時9時に寝てますので、

先週の土曜日、起きたら既に18:00でした(涙)。

しかし、手にはビデオのリモコンを握っていたので、

もしかしたら13時ごろに起きたのかも知れません…。

もちろん、録画はされてませんでした(笑)。謎です(笑)。

635. Re: あぅー、ミカヅキ…M.Kamada  2001年2月27日(火) 23:35

春麗さん、こんにちは。

> 先日のミカヅキ、見逃し・録画り逃してしましました…。

それは残念!

次回の放映まではまだ間があるので、その間に誰かに

ビデオを借りて観ましょう。(私でもOKだにょ)

> 何故かと云うと、2月はじめからドリームキャストの

> PSOにドハマリしてしまい、平日はもちろんの事、

> 週末金曜日は徹夜でPSO漬けだからです。

> ので、最近TVもロクに見てません。せいぜいNHK

> のプロジェクトXぐらいしか見てません。

う~ん、打ち込めるものがあるのはうらやましいにょ。(笑)

> 大抵、夜通し遊んで土曜の朝8時9時に寝てますので、

> 先週の土曜日、起きたら既に18:00でした(涙)。

> しかし、手にはビデオのリモコンを握っていたので、

> もしかしたら13時ごろに起きたのかも知れません…。

>

> もちろん、録画はされてませんでした(笑)。謎です(笑)。

寝ている間に「誰か」にリモコンを握らされていたとか…

こ、こわい…


629. ろっぱねっとラキッ! 2001年2月26日(月) 16:22

皆さん初めまして。『ろっぱねっと』準備委員会の永井と申します。

この度自前サーバーが一定以上の稼働率を突破した事で68ユーザー

間の気軽な情報交換を目的とした『68ユーザーネットワーク』を

提供開始できればと考えています。

現在はネットワーク会員数が極わずかなので目立ったサービスは提供

しておりませんが、ユーザー数が(int)68を突破した時点から色々

始めたく、会員を募集開始しました。

まず始めに御提供できるサービスは、x68k.netドメインのメールアド

レスです。 指定メールアドレスへx68k.netメールアドレスより転送

致します。

会員登録、会費は無料です。

x68k.netに関する質問、無料メールアドレスのお申し込み、今後の

x68k.netの展開について御意見のある方は御遠慮なく、

X-PowerStation NetworkSolutions.

X68K.NETそこはかとなくぼちぼち頑張ろう

準備委員会広報担当 永井 nagai@x68k.net

まで御気軽にどうぞ!


628. アメリカ人の謝罪LeDA 2001年2月26日(月) 10:14

日記より、

>アメリカの文化には日本のようにとりあえず謝る気持ちを伝えるための謝罪の言葉というものが存在しないのでしょうか。

これ、私が思うに「存在しない」のだと思います。

その象徴的単語として「apologize」があります。

これには「謝る」という意味と同時に「言い訳する」と

いう意味もあります。

すなわち、アメリカ人にとっては、いいわけをする=自己主張する

ことが謝っているという態度だということです。

日本は「まず謝れ」であり、まさに文化の違いなのですが、

個人的には米国流は非常に不快です。

(会社でもよくあります。)

悪い結果がでているなら、まず自分の非を認めてから、

今後の対策を言うべきなのにと思います。

今回の艦長のように、謝罪もせずに自分の無罪を得るために

弁護士を選んだなどと言う行動を聞くと、良心のなさに

怒りを覚えますし、これが一般的なら、

仮に間違って核兵器のボタンも押しても「正当防衛」などと

言い逃れしそうです。まあ、イラクへの攻撃なんぞ

その例だと思いますが。

すべてのアメリカ人が悪い人だとは思いたくないですが。

631. Re: アメリカ人の謝罪M.Kamada  2001年2月26日(月) 18:00

LeDAさん、こんにちは。

> すなわち、アメリカ人にとっては、いいわけをする=自己主張する

> ことが謝っているという態度だということです。

日本人は曖昧な言葉を選び、アメリカ人はストレートに言う

という印象があるのですが、どうして自らの非を認める言葉は

ストレートに出てこないのでしょうね。

> 日本は「まず謝れ」であり、まさに文化の違いなのですが、

> 個人的には米国流は非常に不快です。

> 悪い結果がでているなら、まず自分の非を認めてから、

> 今後の対策を言うべきなのにと思います。

まったく同感です。

日米地位協定の問題もありますが、多民族国家のアメリカが

他国の文化をないがしろにするのは理に反していると思います。

結局、自分たちのやり方を押し付けているだけなのですから。

被害者の文化に合わせるくらいの融通もきかないようです。

632. Re^2: アメリカ人の謝罪LeDA 2001年2月27日(火) 10:12

> 多民族国家のアメリカが

> 他国の文化をないがしろにするのは理に反していると思います。

米国は他国から見れば多民族国家なのですが、

中に入れば「America is No.1」という教育が

徹底されているようなので、米国以外を軽視してしまう

人間が少なからずできてしまうようです。

そして、そのNo.1の文化を世界に広めようとするやからも。

(大学生にもなって、SONYが米国の企業だと信じて疑わない

馬鹿も多数いるというのがその証拠か。世界に名だたる

SONYが日本の企業であるわけはない、と言うこと。)

本人は「他国の文化をなえがしろにしている」とは

思っていず、良いものを教えていると思っている

のでしょうが、これが他国にとっては押しつけ以外の

何者でもないと。

別に米国を敵視する気はないですが、時折そのようなやり方が

目に付きすぎることがあって、不快に思えることがあります。

ヨーロッパはそのような米国のやり方に対して、

時としてはっきり「NO」と言いますが、

日本政府はどうにも米国の言うことに従順すぎてだめだめですね。

(日本は本当に独立国なのか?と思うこともしばしば。)

もっとはっきりものが言える政府がほしいところです。

634. Re^3: アメリカ人の謝罪M.Kamada  2001年2月27日(火) 20:35

LeDAさん、こんにちは。

> ヨーロッパはそのような米国のやり方に対して、

> 時としてはっきり「NO」と言いますが、

> 日本政府はどうにも米国の言うことに従順すぎてだめだめですね。

> (日本は本当に独立国なのか?と思うこともしばしば。)

> もっとはっきりものが言える政府がほしいところです。

「日本はアメリカに守ってもらっている(アメリカは日本を

守ってやっている)」という意識を変えないとダメですよね。

日米地位協定のような不平等な協定もありますし。

今の世にあんな不平等な協定が許されるはずがありません。

石原都知事を首相に推す国民が多いのは、アメリカに対しても

何でもはっきり言ってくれるからだと思います。

石原さん一人でどうにかなるものでもないとは思いますが。


627. 逃げる時計VFC-LINK 2001年2月25日(日) 00:24

私から言わせればパクリです(爆)

とはいえ、私のマシン3台+会社マシンに常駐中のは完成度

低すぎですけどもね(^^;

ま、この辺は能力の問題ってことで・・・。

http://homepage1.nifty.com/vfclink/ccc/garbage/dokodoke.htm

630. Re: 逃げる時計M.Kamada  2001年2月26日(月) 17:51

VFC-LINKさん、こんにちは。

> http://homepage1.nifty.com/vfclink/ccc/garbage/dokodoke.htm

んー、時計ついてきますねー。

X Window Systemで昔見たonekoを思い出してしまいました。

マウスポインタに猫がついてくるの。


625. バナー小西  2001年2月22日(木) 22:04

相互リンクしていただいている「遊楽街」の管理者、小西です。

バナーを作ったので、リンクページで使って下さい。

626. Re: バナーM.Kamada  2001年2月22日(木) 22:58

小西さん、こんにちは。

> 相互リンクしていただいている「遊楽街」の管理者、小西です。

> バナーを作ったので、リンクページで使って下さい。

ご連絡ありがとうございます。

さっそく、リンク集を更新しました。


623. 本当に、今更なのですがgussy  2001年2月21日(水) 23:31

Kamada様、お晩です。

「でじこ」って本名じゃ無かったんですか。

ガシャポンのリンクのおかげで判りました。

......っていう素人?な私も拝見させてもらってます。

624. Re: 本当に、今更なのですがM.Kamada  2001年2月22日(木) 00:58

gussyさん、こんにちは。

> 「でじこ」って本名じゃ無かったんですか。

> ガシャポンのリンクのおかげで判りました。

「でじこ」と「ぷちこ」は通称だにょ。「うさだ」は本名。

> ......っていう素人?な私も拝見させてもらってます。

ありがとうございます。

(でじこの本名を知ったからには、もう素人じゃないにょ)

私もgussyさんの日記をこっそりチェックしていたりします。

「ハロ」とか、影響を受けています。

これからもよろしくです。


619. 超怪情報ですが・・・VFC-LINK 2001年2月21日(水) 01:21

テレビ番組雑誌のTVstati○nには、フジテレビ明日21日の

深夜3時35分~4時5分の枠に

「鉄甲機ミカヅキSP」ダイジェスト

ってあります。

フジテレビWebの明日の番組表にはそんなこと一切書いて

いませんが(^^; TVstati○nの公式変更情報ページには

変更の届けは出ていません・・・。

変更の届けといえば、金曜■ードショーで予定されていた

米国ゴジラが延期になったそーで。

時節的に危ういシーンがあるそーで(^^;

TVstati○n変更情報ページはここ。

http://tv.diamond.ne.jp/ch/

622. Re: 超怪情報ですが・・・M.Kamada  2001年2月21日(水) 05:09

VFC-LINKさん、こんにちは。

> テレビ番組雑誌のTVstati○nには、フジテレビ明日21日の

> 深夜3時35分~4時5分の枠に

> 「鉄甲機ミカヅキSP」ダイジェスト

> ってあります。

>

> フジテレビWebの明日の番組表にはそんなこと一切書いて

> いませんが(^^; TVstati○nの公式変更情報ページには

> 変更の届けは出ていません・・・。

インターネットTVガイドにも書いてあったのですが、

21日午前4時頃、「現在の番組表」の日付が変わると同時に

消えました。

以前は予定されていたものの、中止になったのでしょう。

残念。

← 前のページ | 1 | 5 6 7 8 9 10 11 12 13 14 15 | 28 | 次のページ →