Base 256 character set, and "Base Byte" numbering system.

[MonDie]

To tar:

 

Sorry, but I have to say this again: HEXADECIMAL

 

Those 80 binary ones simply become this in hex: 0xffffffffffffffffffff

 

How easy is that? You're trying to fix something that's not broken.

 

TAR clearly must quick at processing bytes to the point that a yet more succinct notation is merited.

[Thorham]

I understand the system is already set, but Base Byte is a way to show a pair of hex characters in one character, and it shows the binary nature at the same time. It is everything that hex is, plus everything that binary is, and it is base 256, all rolled into one.

 

You'd know the binary equivalent if you know hexadecimal. Anyway, I would do it like this (three rows of octal per character):

 

 

[MonDie]

Too hard to draw quickly.

[Thorham]

Too hard to draw quickly.

 

It's not for writing by hand, but for computer generated text. Usable for printing text to screen or paper, and with a suitable input method you can easily type these characters as well. Hexadecimal is probably best for handwritten text.

Edited June 21, 2015 by Thorham

[tar]

Thorham,

 

The octal didn't fit exactly, because three octal characters show 512 and I was trying to match an 8 bit computer byte. I think I even tried the box idea, and the box yielding 9 squares and me needing only 8 had me using the middle box as a dummy box. Then thinking clockwise around I thought you could use the filled boxes for the binary ones. Then I thought that looked too disjointed, like 8 objects, rather than one character, so I thought of actually using ones (lines) and have them go off, from the middle through the center of the box they represented. Just like your system, only adjusted to be actual binary, and a single base 256 character at the same time. So you wouldn't have to remember the value of a character, you could figure it out, and "see" its value, each position being worth double the position before.

 

You point out nicely that the base byte characters can be thought of as two hex characters, but the octal does not make for a clean, identifiable back and forth translation between base 256 and base 8.

 

When I have seen things written in base 256 they use the decimal numbers 0 through 255 to represent each of the characters, like 255 255 means 255 times 256 plus 255. I was, in my coming up with 256 characters, that had no other meaning, attempting to simplify the situation, and have a number system that could be used on its own, seen as an exact quantity on its own, be exactly compatible with an eight bit computer byte, and would not have to be translated into any other base, in order to be understood for exactly what it was.

 

Regards, TAR

Edited June 21, 2015 by tar

[Thorham]

To TAR:

 

Octal fits a eight bits just fine, you just don't have to use all possible digits for the third number. The system I came up with doesn't actually do this and it simply shows the eight bits in a compact form.

 

Here are some more versions. The digits are clearly whole units, and you can easily make out the individual bits allowing you to see the value. This system seems quite clear to me. Dots are zero, squares are one, and the blank space isn't used. The bits are now in right to left order as well (got this wrong in the first version).

 

 

However, generally speaking, writing a single byte value is best done with an existing writing method, based on what the byte represents. If the byte represents a normal value, then base 10 is fine, because there's often no need to see the connection with the binary representation. If the byte represents a bit mask, then base 2 or base 16 is probably best.

 

Basically, systems such as this become potentially interesting if you want to see large numbers in their binary form, such as 32 or 64 bit bit masks, because that is a rather large number of base 2 digits.

Edited June 22, 2015 by Thorham

[tar]

Thorham,

 

But I would like to stick with one "shape" as having a certain value. As in an L shape, meaning 130 decimal, or a 1 in the 128 spot and a 1 in the 2 spot in binary, or meaning 82 hex ((8 x 16) + ( 1 x 2)=130 decimal)

 

Your octal designation shapes do not jive with this "basebyte" system I am presenting. Perhaps you should suggest a base 512 character system, using the boxes, but it will not be as clean and intuitive as an eight bit binary string wrapped around a half dot being a single continuous character shape usable, as a single character, one of 256 distinct recognizable characters, in a positional, base 256 numbering system.

 

The basebyte characters don't have to be memorized, and can be seen as binary if you need to "figure out" what number is being shown. You don't need to know hex or decimal. All you need to know is that a unit is up and to the right, double that, is to the right, double that is to the SE, double the amount shown by a single arm in any position, can be shown by a single arm in the next clockwise position. And once you fill one character's position, with eight arms, if you need double 10000000 you start another character on the left and write 00000001 00000000.

 

Regards, TAR

Every integer value between 0 and 255 can be equaled by adding up a particular (one and one only) combination of the values 0, 1, 2, 4, 8, 16, 32, 64, and 128. In drawing a basebyte character, your NE arm = 1, your East arm equals 2, your SE arm equals 4, your S arm equals 8, your SW arm equals 16, your West arm equals 32, your NW arm equals 64, and your North arm is 128.

 

If you want to draw the basebyte character equal to 222 decimal, you know you are going to need the 128 arm. You still have to show 94, so you know you are going to need the 64 arm. You still have to show 30, so you will not be needing the 32 arm, as it is too much, but you will need the 16 arm, leaving 14, which can use the 8 arm, leaving 6, which can use the 4 arm and the two arm, and you are done, you do not need the 1 arm.

 

So you need the N arm (128), the NW arm (64), the SW arm (16), the S arm (8), the SE arm (4), and the E arm (2). 128+64+16+8+4+2=222

 

If the basebyte character system is as intuitive and realistic as I think it is. Rotating that whole character, with all its arms, counter clockwise, should give us 111 decimal.

 

Instead of N, NW, SW, S, SE and E we will have,

NW, W, S, SE, E and NE which is 64, 32, 8, 4, 2 and 1. 64+32+8+4+2=111

 

Using the unit position in the next character to the left (worth 256 decimal) you could likewise figure 444 decimal in two basebyte characters, mentally rotating the whole basebyte character, that shows 222 base 10, one position clockwise. 256+128+32+16+8+4=444.

 

Thorham,

 

Can you use your block system as such a simple mental doubling and halfing machine?

 

Regards, TAR

[Thorham]

Your octal designation shapes do not jive with this "basebyte" system I am presenting. Perhaps you should suggest a base 512 character system, using the boxes, but it will not be as clean and intuitive as an eight bit binary string wrapped around a half dot being a single continuous character shape usable, as a single character, one of 256 distinct recognizable characters, in a positional, base 256 numbering system.

 

We're doing exactly the same thing, namely sticking eight bits into a single character position. The systems just look different.

 

Can you use your block system as such a simple mental doubling and halfing machine?

 

Yes, because you're just shifting bits to the left and right.

 

Anyway, if I'm going to write anything, either by hand or with a keyboard, then I'll simply use decimal or hexadecimal, based on what the number represents. It's just the easiest way. Think about it, how would you type these characters? You'd need an IME, and you'd basically end up just typing the number normally. Why not just type them without this IME crud? It's not more convenient for writing, it's a hassle.

[tar]

Thorham,

 

Well you are right of course, you have no need for the system, so you won't use it.

 

I have some developing to do, before its an easy system to use.

 

But the Japanese found ways to type Kanji characters, and there a 4000 commonly used ones.

 

I don't think it will be impossible to dream up a way to type 256.

 

Regards, TAR

[Thorham]

Well you are right of course, you have no need for the system, so you won't use it.

 

That block system could be used for a view mode in a memory/file viewer when you want to view things in binary. For that it's undoubtedly much better than writing everything in base 2 (it's the same, yet uses up much less space).

 

But the Japanese found ways to type Kanji characters, and there a 4000 commonly used ones.

 

I don't think it will be impossible to dream up a way to type 256.

 

They use an IME for that. It basically comes down to spelling words in Hiragana (or Romaji when using Latin only keyboards) which are then converted to Chinese characters. You'd end up using something like it, meaning you'd simply type numbers in decimal or hexadecimal and the software converts it to the base 256 digits. Certainly very doable, and probably not as inconvenient as I thought before.

 

For use on computers I'd go for something that sacrifices ease of writing by hand and is as clear as possible, because you'll need an IME anyway and the computer ends up handling the writing part for you.

Edited June 23, 2015 by Thorham

[Strange]

 

You'd know the binary equivalent if you know hexadecimal. Anyway, I would do it like this (three rows of octal per character):

 

 

 

Reminds me of punched tape... (the good old days)

[tar]

Thorham,

 

I am still in favor of the BaseByte "single" character look, over the box look. Here is why.

 

In Philosophy class, in college, I had a VERY intelligent professor (did integral calculus problems for fun and relaxation) and he told us (I paraphrase) that the human mind could only conceive of a small number of thing at once. To think about a larger number of things, you have to do it over time. Like counting for instance, is an "over time" consideration.

 

With the dots, you have three rows and eight separate items...you can understand the number fine, but you have to do it over time.

With the BaseByte system you can see the character, at once. It has a shape, that you can recognize, as you would an A or a Z or a 9. Made of separate parts, but looked at as "one thing".

 

Many years ago, I developed a "theory of seven" to consider, by myself, in my own muses. Considering what Dr. Zucker (my Philosophy prof) had said, and combining it with my own thoughts and mental experiments ( like noticing when counting a large number of items, like a flock of birds, one tended to "group" the birds into pairs and triplets and fours.) (Then "add up" over time, the groups.) I decided, that one (I) could think of up to 7 things at once, but in thinking of the eighth thing, one (I) considered the whole eight as one thing (not eight individual things.)

 

I made the analogy of a box, with eight corners.

 

We can think of a thing (dot) and then its opposite (a dot on either end of a short line), and then the opposite of that (another two ended line, yielding a panel with four corners) and then the opposite of that (another four cornered panel, yielding an eight cornered box), but that was the limit, of what could be easily pictured at once. The next step would be two boxes, which was both like counting, as in "over time" and a grain size shift, where the eight corners where no longer important, but the whole picture was considered as one box.

 

So I confirmation biasly considered things like the days of the week and the whole notes on a Western musical scale, both having 7 individual components, where the eighth item "completed" the scale or week and started a new round of individual things. I once mentioned this hypothetical human limitation to my harried VP with 13 direct reports, and suggested that he should limit his direct reports to 7, so that he could consider them, all at once. He modified his organization to include this limitation and afterward seemed much happier and in control.

 

So the reason why I think basebyte characters are better than the boxes, are because you can see each character, as one thing. (besides, when I drew out decimal 222 and decimal 111 in the octal box arrangement, the shapes were not the same).

 

Regards, TAR

[John Cuthber]

Just a thought; I usually use base 10 so I only need to memorise the multiplication tables up to 10 by 10. beyond that I use long multiplication or (in reality quite often) a calculator.

There are about 50 products you need to remember todo that, and it took me a year or two to learn them.

If, on the other hand I used base 256 I would need to memorise a set of 32768 products.(as well as needing to remember 255 different names for numbers.) That's roughly a thousand times more numbers to remember so I guess it would take me roughly a thousand times as long to remember my multiplication tables.

 

Maybe I'm just getting old, but you would need to offer a jolly good reason to get me to do that.

 

Is this "new" set of numbers actually going to achieve some purpose?

[tar]

John Cuthber,

 

I am guilty of not figuring out the math.

 

My thought was though, that there would be some interesting maths related to this, as in doubling being just a mechanical rotation one position.

 

The names will not be that hard to memorize, because they are not random arbitrary names, but actually made up syllables close to english and latin counting numbers. And there are only 16 syllables for the high half of the character and 16 for the low half.

 

But I was not at all thinking this would be a replacement number system for our perfectly workable and very well worked out decimal system.

 

I thought it would be excellent for visualizing large numbers. I thought it would be neat for looking at computer bytes, rather than the nonsense symbols you look at that do not tell you the actual number, or value of the byte. This would tell you the actual value of the byte, because it is the actual value of the byte. It is absolutely eight bit binary, wrapped around a center semicircle. The fact that you could use the characters as base 256 characters, is an added bonus.

 

I just got a new laptop yesterday, and I joined the 21st century. Maybe I can now get to work on seeing how I can easily make the characters usable. Make a few Java applets or something, that would integrate into some other character rendering programs...I don't even know what I am talking about...but I was able to write a basic program, that displayed them and printed them out, using 64k of RAM (which included video memory if I recall.) Hopefully I can figure out how to get them to show up on my screen now that I have 8gig of ram to work with.

 

Lots of layers to learn about these days though...not quite so simple as just accessing the pixels on a black and white screen and turning them on or off.

 

Regards, TAR

[Thorham]

Lots of layers to learn about these days though...not quite so simple as just accessing the pixels on a black and white screen and turning them on or off.

You could try FreeBasic first. Makes accessing the screen extremely easy. It allows you to do things the BASIC way, and it also allows you to do things the C way (proper pointers, etc). Nice and fast little language, especially for quickly trying some things.

[tar]

Thorham,

 

Thanks for the FreeBasic tip.

 

I was looking for such a way access the screen.

 

Regards, TAR

 

 

 

 

John Cuthber,)

 

Last night I was thinking about the "uses" for the number system and thought that since you actually had information about the number in the arms of the character itself, there would be mathematical inquiries you could make, being able to better visualize base 2, along with base 256. Thorham already pointed out, how binary and hex are linked so the relationship between base 2 and base 16 is set when using hex. As one character of hex shows 4 binary places, and one character of octal shows 3 binary places (2 to the 0, 2 to the 1, 2 to the 2), BaseByte shows 8 binary places in one character, and additional 8 places in each character to the left, and the recipricols of those numbers going off to the right. So anything you can do with binary, you can show as basebyte characters.

 

Here is the previously drawn 256 characters with the right triangle centers, with the decimal number added in the upper right of each display box. I circled the prime numbers (between 1 and 255), just to show you, that you could "see" what a character is numerically made of, which might be an example of the "use" of such a character set.

 

 

Also a crude diagram of the theory of 7, opposites, concept of doubling and our "way" of thinking in 3D (up/down, forward/back, left/right) which is analogous to the corners of a box, and then the grain size shift, where we can visualize the same, using a complete box as a unit again.

 

Regards, TAR

Another "use" I thought of, was to put 5 base 256 (BaseByte) characters up in lights in Times Square in NYC, showing the population of the Earth, as it changes. (to complement the U.S. debt number that is already up there in base 10.)

Edited June 24, 2015 by tar

[tar]

humm...just noticed that you cannot show an odd number, with any of the basebyte characters in a position other than the first position. Therefore, every prime number there is, when written in basebyte has to have in its least significant digit, a character that has an arm in the 2 to the 0 spot. In base 10 every prime number must end in 1,3,5,7, or 9. Since every number can be shown in basebyte and every number greater than 255 can be divided by 256 with a remainder between 0 and 255, then every prime number, must end with one of the 128 "odd" characters seen in every other column of the 16x16 chart.

 

It might be interesting to chart the primes between 256 and 511, in the same manner, against this 16x16, least significant digit grid. Then increment the 256 to 1 character, and see where the primes fall, again. There might be a pattern that would emerge.

[tar]

Thread,

 

Here is the second group of 256 numbers with the actual characters omitted but decimal numbers used in their place. The concept of the characters is retained however, and each position in the 16x16 grid has a unique shape and name, as described. The first diagram with the yellow circles around the primes, showed all the characters in the 256 to the 0 position, when the 256 to the 1 character was "nullzer". This 16x16 grid shows decimal 256 through decimal 511, or in BaseByte, when the 256 to the 1 character is "nullone".

 

The reason for this diagram, is to show that there may be some value in working in base256, and its good to have 256 unique and identifiable characters, with names, to use so you don't have to use characters that already have other meanings.

 

 

 

 

Regards, TAR

Edited June 25, 2015 by tar

[EdEarl]

I have yet to come up with a way (simple, systematic and pleasing) to pronounce these symbols. Anybody have a good idea?

I invented some nonsense syllables to see if doing so would stimulate my brain. The brainstorm gave me the aftermath of a tornado:

0 = B = aa
1 = D = ae
2 = F = ai
3 = G = ao
4 = H = ea
5 = J = ee
6 = K = ei
7 = L = eo
8 = M = ia
9 = N = ie
A = P = ii
B = R = io
C = S = oa
D = T = oe
E = V = oi
F = Z = oo

The single character 256 base values can be represented with one phoneme spelled with combinations of three letters. For example, Foo = 256 and Baa = 0.

 

Some combinations are politically incorrect, for example Mia Lie = hex 8879 This particular list of hex digit phonemes isn't ideal, but I didn't filter them.

 

Using Tar's system, a person must learn to add, subtract, multiply, and divide in binary to do arithmetic. Math whizzes could learn the 256 times table.

 

I like it but I'm too old to change.

[tar]

Ed Earl,

 

I like the principle, but you only need one syllable per character, using your system. You are pronouncing two base byte characters.

 

Can you give the phonetic alphabet sounds you intend there? I am not sure if you mean diphthongs or like two syllable vowel sounds. May say like the oi in toilet so I can hear it when I see it. Also, I think its a little messy to have B as a number and B as a sound in the same system, and be associated with a different arm pattern in a different position.

 

Regard, TAR

[studiot]

Gosh was it so long ago?

 

Here is some tech data from a textbook in 1983.

 

 

Note that the matrix is two bytes or 16 bits high and 7 bits wide.

 

 

Whtever, the characters you can use are determined by the fine dot matrix of the 'character generator' chip in the electronics.

 

The example shows upper and lower case P

 

I am not up with the latest chips but the principle remains.

 

 

 

 

Edited February 16, 2016 by studiot

[EdEarl]

Ed Earl,

 

I like the principle, but you only need one syllable per character, using your system. You are pronouncing two base byte characters.

 

Can you give the phonetic alphabet sounds you intend there? I am not sure if you mean diphthongs or like two syllable vowel sounds. May say like the oi in toilet so I can hear it when I see it. Also, I think its a little messy to have B as a number and B as a sound in the same system, and be associated with a different arm pattern in a different position.

 

Regard, TAR

I didn't think about what the sounds would be. There weren't sixteen vowels, so used the first four of aeiouwy and selected 16 consonants, discarding Q as problematic, and others more or less by whim, assigned values to each, stirred in some glue, and posted. A design would mean writing all the combinations, selecting vowel sounds, writing and pronouncing all the syllables, and pronounce selected numbers from 0 to FFFF. In retrospect, it probably makes more sense to use aeou than aeio. If you want to use it, please do.

[tar]

Ed Earl,

 

Thank you.

6

I do think I will eventually come upon a pronunciation system somewhat like what you are proposing. But my goal is not to count to FFFF. Just need to count to FF. 16 times 16, or 256, is all we need. The higher numbers can be written by putting one of the 256 base byte characters in each value position. 256 to the 7, 256 to the 6, 256 to the 5, 256 to the 4, 256 to the 3, 256 to the 2, 256 to the 1, and 256 to the 0 power, for instance could be the positions where 8 one syllable words, would be the incredibly huge number, you were pronouncing.

 

I like your consonant for the four left hand arms of a single character, and diphthong for the right hand arms of the single character. Then each base byte character, would be a single syllable, and the pronounciation of the huge number would be like saying 99999999 instead of ninety nine million, nine hundred and ninety nine thousand, nine hundred and ninety nine.

 

Although it might be good to add a device that would suggest what position you where talking about, with each syllable. Like tone or emphasis or softer or harder sounding of the syllables, or something.

 

Regards, TAR

[wtf]

Over 1/4 century ago, I was reading about base 256 and the book stated that if you used all the english letters and numbers, and borrowed characters from other languages you would still not have 256 identifiable characters

That can't actually be right. Unicode currently maps over 109,000 characters. Surely you can see that if you took all the English, Chinese, Japanese, Arabic, Indian, and Russian alphabets together you'd have far more than 256 characters, and I'm leaving out lots of alphabets.

 

Of course that doesn't take away from your invention of a 256 character alphabet. But there are plenty of natural language characters in the world.

 

http://stackoverflow.com/questions/5924105/how-many-characters-can-be-mapped-with-unicode

Edited February 16, 2016 by wtf

[tar]

wtf,

 

I don't remember the words used. Just the drift, that choosing 256 arbitrary characters, would not be the kind of thing people would be likely to remember and use, so nobody is about to come up with such a menagerie of characters. I took it as a challenge, and came up with a sensible system, by wrapping a binary string around a center point, and making one character, out of 8.

 

Regards, TAR