| 掲示板の過去ログ（本文 2001/03/06-） | 2007-07-18(Wed) 21:18 |
|---|
会社で使ってた、Ｘ６８用モニターのＣＵ−２１ＣＤ
を２台（黒とグレー）、個人売買の掲示板のある
ＨＳＴ Ｘ６８０００ ＲＯＯＭさんに出しています。
興味のある方はどうぞ。
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台ですね。
> 実は手元に純正マウスもいくつか（なぜか３個くらい）
> 余っているので、スイッチを取り替えて動くようにして
> 売りに出そうかな。
> ←売りに目覚めた！？(^_^;)
純正マウスは貴重ですよね。消耗品ですし。
「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とは言わずライブラリとかモニタとか言う気がするのは私だけでしょうか(笑)
同感。
670. ８K−OS LeDA 2001/03/07 (水) 09:39
└674. Re: ８K−OS M.Kamada 2001/03/08 (木) 20:09
670. ８K−OS LeDA 2001/03/07 (水) 09:39 ８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専用なら
命令やオペランドの自己書き換えだってやります。
開発効率や保守性を尊重するのは一般論であって、
それらを犠牲にしてでもコードを縮めたり速くしたり
する必要が生じることはあります。
まあ、私がやるのはほとんど趣味ですけど。
こんにちは、ゆうき喬史です。
アセンブラの最適化問題やってみました。
;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ビットの値は不定
> という結論に・・・(^^;
>
> 考えすぎて、間違った結論出すことってよく
> ありますよね？
そうですね。
こういうときはレジスタやフラグの変化を細かく書き出して
考えるとよいと思います。
私はよくソースの注釈に書き込みます。
そうしておくと後で見直すときにもわかりやすいですし。
「符号付き加算で符号が違うときは絶対にオーバーフローしない」
この性質も覚えておくと何かと考えやすくなると思います。
＞C言語を完全に理解したければ、アセンブラを少しはかじっておくべきです。
全く同感です。
ただCで書けるというのと、その特性を知って生かすというのは
違う能力だと思います。特に、ＯＳを記述するときや、
組み込みマイコンで記述するときは重要と思っています。
私は。
能力やサイズでの制限が多いですから。
それを他人に言っても理解されないところがありますが。
Ｃは、他の言語に比べアセンブルコードが想像できるのが
好きなところでもあります。
その意味ではＣ＋＋は似て非なる物と感じています。
それが、私がＣ＋＋を習得できず未だにＣだけで
やっている理由でもあります。
だめ？
LeDAさん、こんにちは。
> ＞C言語を完全に理解したければ、アセンブラを少しはかじっておくべきです。
>
> 全く同感です。
> ただCで書けるというのと、その特性を知って生かすというのは
> 違う能力だと思います。特に、ＯＳを記述するときや、
> 組み込みマイコンで記述するときは重要と思っています。
> 私は。
> 能力やサイズでの制限が多いですから。
その通りだと思います。
賛同していただけて嬉しいです。(^^;
> それを他人に言っても理解されないところがありますが。
知らない人に理解してもらうのって大変ですよね。
わざわざサンプルプログラムを作って見せてもわかって
もらえなかったりすると悲しくなります。
> Ｃは、他の言語に比べアセンブルコードが想像できるのが
> 好きなところでもあります。
同感です。
> その意味ではＣ＋＋は似て非なる物と感じています。
> それが、私がＣ＋＋を習得できず未だにＣだけで
> やっている理由でもあります。
> だめ？
わたくし的には、全然おっけーだと思います。
私もC++を積極的に使いたいとは思いません。
必要があってC++のソースを読むことがありますが、
「Cで書いてくれたほうが読みやすいのに…」と思うことが
多いです。書き方にもよるかも知れませんが。
本質的に、CとC++の違いは、アセンブラとCの違いよりも
大きいと思います。
C++はコンピュータの高級言語の1つであって、不幸にも
C++最初に覚えてしまった人が後からCを完全に理解するのは
大変だろうと思います。
C++は、用途や開発環境によっては使いやすい高級言語の1つ
にすぎず、Cに取って代わるべき言語ではないと思います。
692. 中学生日記 みかぜ 2001/03/13 (火) 03:51
└693. Re: 中学生日記 M.Kamada 2001/03/13 (火) 05:20
692. 中学生日記 みかぜ ⌂ 2001/03/13 (火) 03:51
電撃Ｇ’ｚを嬉々として読み耽る女子中学生……
そのうち「萌え〜」とか言い出すかも。
こうしてマーケットは予想外のターゲットへと広がって行くのですね。
ブロッコリーの店舗数がソフマップを越える日も遠くないかも。
みかぜさん、こんにちは。
> 電撃Ｇ’ｚを嬉々として読み耽る女子中学生……
> そのうち「萌え〜」とか言い出すかも。
それはこわいっす。
「まじんがっぱグッズ集めてるの〜」くらいならいいけど。
> こうしてマーケットは予想外のターゲットへと広がって行くのですね
> ブロッコリーの店舗数がソフマップを越える日も遠くないかも。
子供の遊びがテレビゲームからカードゲームに移りつつある中で
成長を続けるブロッコリーですが、現在のゲーマーズの店舗の
増え方は「節操なし」の域には達していないと思います。
キャラクターグッズ屋さんとデジタルグッズ屋さん（笑）を
比較するのは難しいですね。
マウス２台とマウストラックボール１台を、また
HST X68000 Roomさんに売りに出しました。
興味のある方はどうぞ。
新品ではないですが、効かないスイッチは交換済みの
感動･･･もとい、完動品です。
LeDAさん、こんにちは。
> マウス２台とマウストラックボール１台を、また
> HST X68000 Roomさんに売りに出しました。
マウス・トラックボールというと、「ふたを取って底面の
スイッチを切り替えるとボールが持ち上がってマウスから
トラックボールに早変わりするという、X68000の発売当初に
話題になった斬新な発想のマウスですね。
本体に標準で付属している機種とそうでない機種がありますが、
X68000シリーズならばどの機種でも使えます。
トラックボールに切り替えればボールを指でくりくりできるので、
特にマウスを動かすスペースがない人は重宝すると思います。
トラックボールのときに押しやすいように、上面だけでなく
側面にもボタンが付いています。（機能は上面のボタンと同じ）
> マウス・トラックボールというと、「ふたを取って底面の
> スイッチを切り替えるとボールが持ち上がってマウスから
> トラックボールに早変わりするという、X68000の発売当初に
> 話題になった斬新な発想のマウスですね。
私はこれを愛用していて、現在手元で実働しているX68030、
CompactXVI２台、XVI、030Compact全てにこれを付けています。
机の上が狭いので普通のマウスではやりづらい、という
事情もあります(^_^;)
手の上で転がすには最適なので、Win用にもあればいいのですが、
全く同じような物はないですね。SHARPの特許なのかな？
ちなみに、今日現在売れてません。
以外と需要がないのかも。
なければないで自分の予備品に回すだけなのですが。
695. 私じじいかな？ はんかつ 2001/03/13 (火) 20:06
695. 私じじいかな？ はんかつ 2001/03/13 (火) 20:06 鎌田さんおひさしぶりです はんかつです。
>ZETA3ポータブル自転車パワーアシストシステム
世界初といいますが、私の子供のころにはガソリンエンジン
を使ったこんなやつが日本を走り回っておりました。
あのホンダも最初はこれから始めたのです。
はんかつさん、こんにちは。
> >ZETA3ポータブル自転車パワーアシストシステム
> 世界初といいますが、私の子供のころにはガソリンエンジン
> を使ったこんなやつが日本を走り回っておりました。
> あのホンダも最初はこれから始めたのです。
これ↓ですね。
http://www.honda.co.jp/50years-history/001.html
普通の自転車に動力を乗せてしまう発想はオートバイの
原点だったのですね。（普通に納得）
しかし、さすがにこれが普通に道路を走っているところは
見たことがありません。
私が子供の頃は、廃車置場に置かれていたオート三輪を見て
「この変なカタチの乗り物は何だろう？」って思っていました。
まだ作ってる会社があったとは！
http://www.fuki.co.jp/mall/index.html
はんかつさん、こんにちは。
> まだ作ってる会社があったとは！
> http://www.fuki.co.jp/mall/index.html
おー、自転車にエンジン載ってますねぇ。
これで楽をしたいときは、アシスト自転車と違って原付の
免許が必要ですが、自転車よりも速く走ったら危なそうですね。
自転車のタイヤで普通の自転車よりも重いから、自転車並の
速さでも危ないかも知れない。
いわゆる「原付」が「原動機付自転車」の略語であること
を思い出して、ちょっと納得。
こんばんは、はじめまして。
日記の「グラハム数」ですが、何か数字に意味はあるのでしょうか？
「スキュース数」というのがありまして、これは「過大評価素数予想」に
出てくる数ですが、
10^10^10,000,000,000,000,000,000,000,000,000,000,000
だそうです（ご存知かな？）。「何らかの意味を持つ数学史上最大の数｣。
武田さん、こんにちは。
> 日記の「グラハム数」ですが、何か数字に意味はあるのでしょうか？
グラハム数はラムゼー理論の組み合わせの問題に出てきます。
「どのような2人の人の関係も必ず顔見知りまたは初対面の
どちらかに分類できると仮定したとき、集団をどのように
集めても互いに顔見知りの3人または互いに初対面の3人が
集団の中に必ず含まれてしまうような最小の人数を求めよ。」
この問題の答えの人数の上限がグラハム数になるそうです。
グラハム数はあくまでも上限であって、実際の最小の人数は
たったの6人だったりします。
この問題は、条件の人数を増やすと急激に難しくなります。
4人が顔見知りまたは4人が初対面の場合は18人、4人が顔見知り
または5人が初対面の場合は25人であることが証明されている
そうです。
なお、グラハム数は、1980年のギネスブックに「数学的証明に
使われた世界最大の数」として掲載されました。
> 「スキュース数」というのがありまして、これは「過大評価素数予想」に
> 出てくる数ですが、
>
> 10^10^10,000,000,000,000,000,000,000,000,000,000,000
>
> だそうです（ご存知かな？）。「何らかの意味を持つ数学史上最大の数｣。
私はスキューズ数と覚えていました。
ある数nよりも小さい素数の個数はint(dx/log(x),0,n)で
近似することができます（素数定理）。
nが小さいうちはこの近似は過大評価になりますが、nが大きく
なると過大評価と過小評価を無限に行き来するそうです。
この近似が最初に過小評価になるnの上限として、1933年に
スキューズが10^(10^(10^34))という値を示しました。
この値をスキューズ数（Skewes' number）と呼びます。
スキューズの証明はリーマン仮説を仮定していたそうなので、
厳密には証明されていないことになると思います。
705. カウンタ Hiroi Makoto 2001/03/20 (火) 18:07
└706. Re: カウンタ M.Kamada 2001/03/20 (火) 23:19
705. カウンタ Hiroi Makoto ⌂ 2001/03/20 (火) 18:07 鎌田さん、こんにちは。
50,000 ビジット突破、おめでとうございます！
これからも STUDIO KAMADA を楽しみにしていますので、
がんばってください。応援しているにょ（笑）。
ではでは。
706. Re: カウンタ M.Kamada ⌂ 2001/03/20 (火) 23:19 広井さん、こんにちは。
> 50,000 ビジット突破、おめでとうございます！
ありがとうございますぅ。
みなさんのおかげです。
> これからも STUDIO KAMADA を楽しみにしていますので、
> がんばってください。応援しているにょ（笑）。
がんばるにょ。
トップのページの文字、パレットイルミネーション（でいいのかな）
してるんですね。
いやぁ きれいだなぁ
のぐさん、こんにちは。
> 50,000 ビジット突破、おめでとうございます
ありがとうございます。
たくさんのアクセスに応えられるように、
もっと内容を充実させたいと思います。
> トップのページの文字、パレットイルミネーション（でいいのかな）
> してるんですね。
> いやぁ きれいだなぁ
ありがとうございます。
IEオンリーのシンプルなダイナミックHTMLです。
ちゃんと書けばもっとソースを短くできるのですが、
冗長な書き方のまま使い回してしまっています。
ダイナミックHTMLを使ってもっと変なこともできます。
でも、うっとおしくならないように効果的に使うのは
難しいですね。
A * BCDE = AB * CDE 問題の応えです。
同じ数字を入れても良いとの事なので、一番簡単な答えは、「A=B=C=D=E=0」ですね(笑)
そのバリエーションとして、
「A=B=0,C=D=E=0〜9のどれか」、
「A=C=D=E=0,B=0〜9のどれか」、
「C=1,B=D=E=0,A=1〜9のどれか」、
ってのがあります。
あとは、上記の組合せ以外での探索を行うプログラムを作れば良さそうですが…そこまでやってません(笑)
少なくとも、
奇数×奇数＝奇数
偶数×偶数＝偶数
奇数×偶数＝偶数
なので、かなり枝刈りできそうです。
M.Suzukiさん、こんにちは。
> A * BCDE = AB * CDE 問題の応えです。
どうもですぅ。
> 同じ数字を入れても良いとの事なので、一番簡単な答えは、「A=B=C=D=E=0」ですね(笑)
あぅ。
「文字A,B,C,D,Eをそれぞれ1〜9のいずれかの数字とします」
です。0は使っちゃダメ。
> 少なくとも、
> 奇数×奇数＝奇数
> 偶数×偶数＝偶数
> 奇数×偶数＝偶数
> なので、かなり枝刈りできそうです。
そうそう、そんな感じ。
どこまで枝刈りできるかな？
711. びっくり ZooMark 2001/03/24 (土) 17:10
└712. Re: びっくり M.Kamada 2001/03/24 (土) 18:04
711. びっくり ZooMark 2001/03/24 (土) 17:10 Kamadaさん、こんにちわ。
日記にも速報がありましたが、
ついさっき広島は震度６の地震に見舞われました。
幸い、実家の食堂にも家にも被害はなく、
私の部屋の本棚が倒れたぐらいです。
散乱した本とゲームソフトを前に途方に暮れてます。
今から片付けに入ります。（トホホ…）
712. Re: びっくり M.Kamada ⌂ 2001/03/24 (土) 18:04 ZooMarkさん、こんにちは。
> 日記にも速報がありましたが、
> ついさっき広島は震度６の地震に見舞われました。
ZooMarkさんが広島だと記憶していたので
気になっていました。
> 幸い、実家の食堂にも家にも被害はなく、
> 私の部屋の本棚が倒れたぐらいです。
本棚が倒れたりするのはかなり大きいと思います。
ご無事でなによりです。
> 散乱した本とゲームソフトを前に途方に暮れてます。
> 今から片付けに入ります。（トホホ…）
大変だと思いますが、がんばってください。
Kamadaさん、こんばんわ。
> 本棚が倒れたりするのはかなり大きいと思います。
> ご無事でなによりです。
>
> > 散乱した本とゲームソフトを前に途方に暮れてます。
> > 今から片付けに入ります。（トホホ…）
>
> 大変だと思いますが、がんばってください。
ご心配お掛けしました。
今は余震もおさまり、事態は収束に向かってるようで安堵しています。
それから、現在の日記は数日で内容が切り替わるので、「3月日記」の3/24分にアンカーを入れました。
Kamadaさんの日記から私の日記への「球場前を〜」のリンク部分を
http://ww3.enjoy.ne.jp/~zoomark/qs/dia.html#BTM
↓
http://ww3.enjoy.ne.jp/~zoomark/qs/dia0103.html#010324
で、修正をお願いします。
713. 算数パズル 武田 2001/03/24 (土) 20:26
└714. Re: 算数パズル M.Kamada 2001/03/24 (土) 21:35
713. 算数パズル 武田 2001/03/24 (土) 20:26 投稿がないようなので、無い頭を絞って考えてみました。
その結果「答え：回答なし」になりました。
A=1 B=9 C=5 D=0 E=0 を導き出したんですけど、
0は当てはめちゃ駄目だから。うふーん。
グラハム数は鎌田さんの説明を読んでもりかいできませんでした。
「フェルマーの最終定理」は読まれました？
僕はこの本でスキュース数のことも知りました。
武田さん、こんにちは。
> 投稿がないようなので、無い頭を絞って考えてみました。
> その結果「答え：回答なし」になりました。
うぐぅ。答えはちゃんとありますよぅ。
> グラハム数は鎌田さんの説明を読んでもりかいできませんでした。
累乗を再帰的に使っているだけといえばそれまでなのですが、
実際に計算してみることができず、私も完璧に理解している
とは言えないので、うまく説明できなくてごめんなさいです。
> A=1 B=9 C=5 D=0 E=0 を導き出したんですけど、
> 0は当てはめちゃ駄目だから。うふーん。
0を許すとa*bc=ab*cなどに帰着させて冗長な答えが
たくさんできてしまうのです。
> 「フェルマーの最終定理」は読まれました？
> 僕はこの本でスキュース数のことも知りました。
ナナメに読んだかも。
15パズルの話なども出てきませんでしたか？
別の本だったかな。
タイトルに「フェルマーの最終定理」が入っている本は
たくさんありますよね。
A=7, B=9, C=8, D=7, E=5.
すみません、Cでコンピュータに解かせました。
中学生並に
A*(1000B+100C+10D+E)=(10A+B)(100C+10D+E)
として式をいじくったのですが、いかんともしがたかったです。
解くための考え方ってどうなんでしょう？
「フェルマーの最終定理」は新潮社から出ているのです。
そう、15パズルが入っているのです。この本は数学の内容が容易に
書いてあって、かなり面白くてお勧めの本です。
p.s.
今日、ガメラに壊された京都駅を見てきました。
壊し甲斐がある建物でした。
武田さん、こんにちは。
> A=7, B=9, C=8, D=7, E=5.
正解です。
> すみません、Cでコンピュータに解かせました。
> 中学生並に
> A*(1000B+100C+10D+E)=(10A+B)(100C+10D+E)
> として式をいじくったのですが、いかんともしがたかったです。
> 解くための考え方ってどうなんでしょう？
日記にざっと書いてみましたので、参考にしてみてください。
> 「フェルマーの最終定理」は新潮社から出ているのです。
> そう、15パズルが入っているのです。この本は数学の内容が容易に
> 書いてあって、かなり面白くてお勧めの本です。
数学をわかりやすく書いてある本って面白いですよね。
> p.s.
> 今日、ガメラに壊された京都駅を見てきました。
> 壊し甲斐がある建物でした。
ガメラ３は良かったっす。
＞本日のNHK BS2。09:36-11:08劇場版カードキャプターさくら「封印されたカード」（中略）21:00-24:00衛星映画劇場「サウンド・オブ・ミュージック」、などなど。
しまった！！！
会社に来てからこのホームページを見るから、
知った時にはもう録画の用意ができん！！
まぁ、カードキャプターはDVDもってるからいいけど、
サウンド・・・は、何とか間に合うように帰らねば。
それだけ。
LeDAさん、こんにちは。
> ＞本日のNHK BS2。09:36-11:08劇場版カードキャプターさくら「封印されたカード」（中略）21:00-24:00衛星映画劇場「サウンド・オブ・ミュージック」、などなど。
>
> しまった！！！
> 会社に来てからこのホームページを見るから、
> 知った時にはもう録画の用意ができん！！
>
> まぁ、カードキャプターはDVDもってるからいいけど、
> サウンド・・・は、何とか間に合うように帰らねば。
CCさくらについては昨日書くの忘れましたです。
サウンド…は私も今朝気付きました。
間に合うことをお祈りします。
180分あるから1枚のCD-Rに入れるのはきついカナ？
> > サウンド・・・は、何とか間に合うように帰らねば。
> サウンド…は私も今朝気付きました。
結局、間に合いませんでした。
残念。
今は番組改編時期で、いいものが出てくるので要注意ですね。
LeDAさん、こんにちは。
> > > サウンド・・・は、何とか間に合うように帰らねば。
>
> 結局、間に合いませんでした。
> 残念。
んー、それは残念でした。
> 今は番組改編時期で、いいものが出てくるので要注意ですね。
そうですね。
大きすぎてふだんやらないようなものが出てきたり、
春休みなので日中にいいものをやったりするかも。
週間番組表などで要チェックです。
私は http://www.tvguide.or.jp/ を利用しています。