My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Monday, May 22, 2017

journal 20170522

So I think I'll start posting parts of my work journal.
作業日記の一部を公開しようと思うようになりました。

I'm still spinning my wheels.
まだ無駄作業ばかりです。

My last contract ended in March.
最後の契約が3月に終わったのです。

In complete rejection of logic and reason, I have not been burning myself out to find a new job.
完全に理と役から離れて、就職活動に無駄な力を尽くしていません。

I have a series of novels I want to write.
書いて公開したい連続小説があります。

Nobody but my oldest sister is reading them.
一番上の姉以外はだれも読んでくれていません。

After the contract ended, I've been stuck on a little side-tour.
契約が終わってから、寄り道に詰まっています。

I needed to calculate the calendar of the world where the first several stories take place.
小説の最初の話の舞台となる惑星の暦を計算しないと進めないものがあります。

Then I got really interested in the puzzle of adding double integer divide to the base wordset of the programming language Forth.
プログラミング言語フォース(「先へ」)の基本単語集に、倍範囲幅変数型の割り算計算機能を付け加えることの謎謎に夢中になってしまいました。

Last week, I pretty much proved to myself that there are no easy, fast, deterministic methods for division, the way there are with multiplication.
掛け算にあるような、簡単で早い決定経路型手順は割り算に無いことに、だいたい納得できるまであちこちを探って、自分なりに証明しました。

Not a mathematical proof, just finding a difficult problem that no one else seems to have solved.
正確に証明したのではありません。ただ、南海の問題にぶつかって、その問題を解決した人の情報がどうしても出てこないのです。

We humans intuitively use estimates when we divide large numbers.
我々人間は、大きい数字の割り算に手を付けると、無意識に推測して、概算の手順を使います。

We have the multiplication tables memorized, and we use those tables in division.
既に暗記済みの掛け算表を参考に、割り算を行います。

When doing this in computers, those tables can become larger than the entire memory of the old 8-bit processors.
コンピュータに割り算を実装すると、その掛け算表が一昔の8ビット中央計算装置の全記憶装置量を超えるほどの量になることがあります。

The Forth that needs the double length divide is an 8-bit CPU implementation.
この倍範囲幅割り算を必要としているフォース言語は8ビットCPUに実装したものです。

Fortunately, the size of the table depends on the numeric base you operate in.
幸いに、その概算表の量は数値表現の進法に決まっているものです。

The table for one digit of decimal math is not really big, only 100 elements:
十進法の一桁の場合は表が大きくありません。百個の要素だけです。つまり、


×0123456789
00000000000
10123456789
2024681012141618
30369121518212427
404812162024283236
5051015202530354045
6061218243036424854
7071421283542495663
8081624324048566472
9091827364554637281

But we are not talking about one digit of decimal math.
ただ、十進法の一桁の話ではないのです。

The smallest table we can do without using bit shifts is a table for one column of base 256 math.

ビットシフト演算なしで一番小さい表はなんと 256 進法の一桁の表です。

That means a table 256 wide and 256 deep. That's 65,536 16-bit integers.
つまり、 256 桁の 256 行の表です。 65,536個の 16 ビットの整数です。

I'm not going to reproduce that here, because I'm pretty sure it would give your browser fits, not to mention what it might do to blogspot's template engine.

ここで再現しようとありがたく思われないので、止めておきます。閲覧者のウェブプラウザには全く優しくないどころか、ブログスポットのテンプレートエンジンの結構ひどい扱いにもなります。

(Blogspot might accuse me of trying to DOS them, and you might accuse my of DOSsing you.)
(あなたにも、ブログスポットにも、攻撃と思われるかも知れません。)

Now the problem is the shifts. Left shifts are just doubling, so they are pretty cheap. It's just an addition.
ビットシフト演算が問題です。左シフトは倍の計算ですので、特に問題になりません。足し算だけです。

Unless you have actual bit shifts, shifting to the right is expensive, requiring a division.
ビットシフト演算がなければ、右にシフトするのは割り算の重たい計算がかかります。

It's a relatively cheap single-wide division, so it's not a chicken-and-egg problem, but even single-wide divisions take a long time on old microprocessors.
単幅の比較的に重たくない割り算ですので、鶏と卵のような問題ではありません。と言っても、古いマイクロプロセッサーには結構の暇が掛かります。

Addition on old microprocessors takes maybe ten microseconds. Division takes easily 200 times that.
古いマイクロプロセッサでは、足し算は凡そ十ナノ秒(一秒の十万分の一)しか掛かりません。割り算は辛うじてその200倍がかかります。

It's possible to use scaling to reduce the amount of math required without the tables, but scaling requires shifting as well.
表無しでよろうと思えば、スケーリングという尺度合わせのような手もあります。但し、これにもビット演算が必要です。

Binary division is different. This is all there is to the table:
二進法の割り算は違います。これだけの表です。

×01
000
101

And binary division is just shifting, subtracting, and counting.
そして、二進法の割り算はただシフト演算と引き算と回数の一をとることで済ませる。

It's slow, but it's straightforward.
ゆっくりと出来上がりますが単純な決定経路型手順です。

So, if I have to use shifts anyway, I may as well go down to the machine level and implement the division in assembler anyway.
なるほど、シフトをもって実装するしかないなら、もう、低レベルアセンブリ言語で割り算そのものを実装するほうが懸命ではありませんか?

[JMR201706171513:

I have the program running, and it produces monthly calendars for the planet that I think are accurate. The source can be found, complete with the code for dividing double integers, in my Xhilr Calendar workspace at OSDN Japan.
暦作成のプログラムは稼働できます。その惑星の正確性在るとボクが思っている月毎のカレンダーが作成できます。倍幅割り算を含めたソースコードをボクの OSDN Japan 上の Xhilr Calendar 作業部屋に置いています。

]

This is not the way a sane person spends his time when he needs to be finding a new job, you know.
新しい仕事を探しているはずの正気の人がやるようの人生の過ごし方ではありません。ね。

Last Sunday, I went to the special stake conference in Kõbe and listened to Elder Oaks and other Church leaders.
先の日曜日は、特別ステーク大会のために神戸に行って、オークス長老と他の教会指導者の話を聞きました。

I'm feeling much less down.
ちょっと立ち直りました。

No comments:

Post a Comment

Courtesy is courteous.