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.

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

Thursday, May 11, 2017

Visions and Pioneering and Responsibility to Family

I was talking with some members of the Forth community on comp.lang.forth about using floating point numbers in a Forth language, and thinking about how I really don't much care for floating point math in programming languages.

Arbitrary precision is much more what most people want. It's a little slower than floating point, but it has fewer surprises. (There are still some surprises induced by the fact that computers do not easily extend precision, where we on the other hand are quite happy to grab another piece of paper and keep going until our wrists get sore or we fall asleep -- or get bored.)

Fixed precision is much faster and much lighter on computer resources. With 64 bit math on modern computers, we can easily do math to 18 decimal places. That would cover most peoples yearly budgets, easily.

But, for all that fixed precision would cover most daily calculation needs, it requires us to keep track of precision ourselves. That's why arbitrary precision and floating point are useful.

Floating point would be a bit easier if it weren't for all the bit fields that have to be extracted from memory that don't fall on easily addressed boundaries.

Then I had this idea about having the exponent be in one integer and the fractional part be in another. That would give ridiculous range for 16-bit CPUs (like 10 followed by more than 16,000 zeros). The fraction part would give us one part in 65536, or a bit more than four digits on the right of the decimal point, which isn't enough for some things, but is plenty for others.

On 32 bit CPUs, the range would be even more ridiculous, but we would have about nine digits on the right of the decimal. Which is why floating point fields don't fall on even boundaries.

On 64 bit CPUs, the range would be beyond ridiculous. Billions of zeros. But the fractional part would be more than 18 digits, which is pretty decent.

The discussion on comp.lang.forth focused on the problem of knowing just how wide a floating point number on the top of the stack of recently used numbers is. When working on the stack, you need to know the size of the numbers that are on the stack so you can get them off the stack and get around them to other numbers, and so forth.

It occurred to me that a floating point number that could tell the programmer how wide it is would be rather useful.

And this first-blush byte format came to mind, just before I went to bed:

8888 8888
length = 0
(8 bits)
exponent (24 bits)fraction (32 bits)

And, in fact, it kept me up a bit, re-thinking things:

8888 8888
sign
(high bit),
length = 0
(7 bits)
exponent (24 bits) fraction (32 bits)

And then it was

8888 8888
sign
(high bit),
length = 0
(7 bits)
exponent
(8 bits)
fraction
(16 bits)
------
sign
(high bit),
length = 1
(7 bits)
exponent (24 bits) fraction (32 bits)

Where length of 0 would be a special case, with the whole floating point number contained in a single 4 byte (32 bit) unit.

From length 1 on, the length would be the count of 32 bit units containing the fractional part (or mantissa, I have to figure out details later), and the three bytes after the length byte would be the exponent.

Checking the IEEE floating point specs on Wikipedia, none of the most common formats have more than 15 bits of exponent. The standard 32-bit format has only 7 bits of exponent, and the standard 64-bit format has only 11 bits of exponent. So 24 bits of exponent is plenty.

Maybe I can scrape the top two bits of the exponent off for flags of some sort. 22 bits of exponent still gives an exponent range of 10 followed by two million zeros.

Speaking of zeros, being able to specify up to 127 times 32 bits of mantissa means ( 127 × 4 == 508 bytes, or 1016 nibbles) better than 1100 decimal digits worth of accuracy in decimal terms.

That's going to be enough to satisfy most mathematical needs for primary grades through college, except for certain engineering purposes.

Mathematically, it's a loose fit, but, with everything falling on nice byte boundaries, it's going to be a lot less work up front.

A similar approach could be used for decimal or other base digits, which is something to think about later.

It will be a little slow, since it will be implemented in software, but you can extend the numbers, mid calculation, to avoid losing precision.

And, randomly associating, a similar approach could be taken with text strings, if we had a better way of representing numbers in the middle of text (a topic which I really want to rant on sometime).

You can probably get a sense of what this has to do with pioneering (ergo, new or less-explored computer/data techniques), but what does this have to do with visions and responsibility to families?

I really should not be typing this.

I really should be running around like a chicken with its head cut off trying to scrounge up work for when my savings runs out in another month.

I am being irresponsible.

I woke up this morning at three thirty, still thinking about this stuff.

And I was thinking about Nephi, in the Book of Mormon, 1 Nephi 17: 9, asking God where to go to get ore to make tools to build the ship with.

Now we have to understand the story. Nephi had been helping his father get their families moved across the desert towards the sea. He had done his part in making sure that the women and children had enough to eat. They had found a nice place on the sea shore to settle down and maybe be safe from the Babylonians and others whom the prophets had been foretelling would be coming to take Jerusalem down for real this time.

Now, he was getting inspired to take the whole group on a long adventure into the unknown, across the sea to a land he and his father had seen in dreams.

His older brothers were upset, and we can understand why.

I am being inspired to take my family on a long adventure into uncharted territory with my writings and other dreams, visions, fantasies, and delusions such as the above. My family is understandably upset.

(Delusions. Ask pretty much anyone, and they will tell you that someone like me should not working with all the wonderful technology that is out there for the using. We have floating point. We have arbitrary precision math. We have the Unicode character set. We have programming languages and CPUs.

What need have we of more of these?

(Other than that it is a deliberate mess, designed to keep the riff-raff like you and me from using it to make the world a better place.)

Well, Nephi asked God where he should go to get ore for tools.

I have been asking God where I should go to get funding.

There is a bit of difference.

Nephi had done his part in securing food and a place for his family. My family and I are on the brink.

He was looking for ore for tools. I am looking for money for a place, for food, and for tools.

This is scary business.

Visions, pioneering, and responsibility to family.

No comments:

Post a Comment

Courtesy is courteous.