View Full Version: Binary Representation In Dozenals

Dozensonline > New Systems of Measure > Binary Representation In Dozenals


Title: Binary Representation In Dozenals
Description: discuss the best way to do this


sunny - September 6, 2017 12:31 PM (GMT)
I have asked something like this before but i got no responses.

As I don't recall the topic was/being discussed elsewhere in this forum, I thought i might like to start one. I am surprised that bases other than dozenal gets more attention than actually improving things in a dozenal society, since it's dozensonline forum.

As the computers only understand the base-2 system, that it can apply in it's core level. The length of these base-2 numbers grows rapidly than any other bases and we already have a term for a single binary digit, the bit (a natural unit) which can fill up any of the two states, 0 or 1 and that it stores the information with it likewise. Now that we have a unit, which seems as simple that it usually deserves. But instead, computers stores bits in packets but usually transfer data in single bits, for example 1 packet of 8 bit each is being required to make information of one character. But some encoding requires upto 32 bits made up of 4 packets. Now that the so called 'packet' is another unit here, which is byte. But the byte hasn't been necessarily of 8 bits since history, but now is the defacto standard, we have an unnecessary unit existing besides simple bit as the unit, the byte (where byte is now 8 bits). Now that by convention, byte is used while storing data and bit is used while transferring data, usually. Now in the decimal world, there are the existing usual prefixes which might mean something else in binary prefixes, where 1000 = 1024. Adding to the already confusion that usually is that 'b' was defined bit and 'B' was defined byte, Ki was defined 1024 and K was defined 1000, for kibi and kilo, 1024^2 for mebi(Mi) and 1000^2(M) for mega resp, etc before switching from 'K' as binary kilo and 'k' as decimal kilo which i don't know it was being followed. Adding this confusion at the time of confusion that kbps is not a transfer of 1 KB every second, ie kb = 1000 bits where KB = 1024x8 bits, adding 'i' in front of K,M,G,T,.. etc isn't anywhere to be seen usually now, as far as i know. Hard disk manufacturers still falsely advertise space in order to gain benefits, some people still don't know that usually a transfer speed of 1mbps doesn't mean 1MB each second, and if they do, they have to make awkward calculations back and forth. Adding to this, there are many additional problems that i can share (where i've heard the cases like merging binary and decimal prefixes like 1000x1024 for mega, etc) but i wanted to keep this as an informative lecturing short and more of a new reformation.

In the dozenal world, the problem (where prefix can mean other type of prefix and unit can mean other type of unit, was once done mostly for marketing gimmick by storage manufacturers to make profit and has been followed ever since as their informal std) can be solved after strictly dropping unnecessary prefixes and unnecessary units, which is the 'binary prefixes' and groups of bits as 'bytes' here. For unit, we should only deal with 'bits' to make this simpler, the computer architecture (ironically bits, not bytes) knows what group of packets that it is compatible to work, store and send data. Humans don't have to adjust with them, computers have to adjust for humans because they don't do math like 5+4, they convert that into binary and add, convert again to decimal to show the result as 9. Also, we could drop 'binary' prefixes and keep dozenal prefixes. For example, the approachment shouldn't be something like this: 2^12 = kilo, 2^(12x2) = mega, 2^(12x3) = giga,.. etc because the dozenal radix point shifting no longer works. Instead a simple (Kode's prefixes) like unqua, biqua, etc where these pure powers of dozen applied to the true binary unit, 'bit' would work.

So, a usual speed of *10 pb/t is 8.6 mb/s, where p=*10^5, b=bit, m=mega(dec) and is not Mega(binary) and t=pentciaday.

Also, a usual file size of *2 nb is 1.2 GB, where n=*10^9, G=giga(binary) or Gibi, b=bit and B=byte.

As simple as that.

I know that some storage architecture are usually in sizes of order that can be exactly represented only by round binary prefixes, this can also be represented with rounding out the fractional parts in decimal or dozenal. For example: the display resolution of HD image of 16:9 aspect ratio is typically 1366x768 which isn't exactly 1 megapixel as advertised but 1049088 pixels, but it is rounded off to 1 mega in decimals, that can also happen with non-round numbers in dozenals even though they might be purely round in binary prefix representations. Moreover, the bits are stored in groups of bytes and is usually accessed that way but we don't need to forget that the actual base unit is bit here that is the actual smallest possible information, and where grouping of them into 1 byte to represent 1 whole character is somewhat arbitrary and can be changed adapting with improving technology or as the number of characters is increased in futuristic society to accommodate byte ranges.

If I got everything right above. Tell me why this won't work? If yes, what could be improved?

wendy.krieger - September 9, 2017 09:43 AM (GMT)
The problem with dozenal here, is that none of the powers of 12 are close enough to be taken as powers of 2.

In decimal, we have 1024, which is passable as 1000. In twelfty, 128 is close enough to pretend it's 120. So something like 36-bits, is 30+6 = 64 Gigs, while in twelfty, it is 35+1, gives 2 hundred millions.

CODE
[d:\]rxc 2**36
291,4825 V616:0000   for 200,0000,0000
68,719 476 736.0 0   for 64,000 000 000.  


Of course, if you pretend that 128 = 144, you will get around the problem that computer numbers make for the lower number, and computers use the larger, since both the binary and lower number would be the same.

2**36 = 1.1 3 9,10 0 1,11 8 5,4 for 2. 0 0 0, 0 0 0, 0 0 0, 0 2D10.

Although not as close as the twelfty, it is still reasonably acceptable. It would amount to using the digit-pairing or foursome, rather than the three-digit grouping.

But neither twelfty nor dozenal have the feature of decimal, where the equality is the 10th power, ie you can take something like '48', and write 8+40, ie 2^8 * K^4 = 256T. In the other bases, you need to divide by seven, ie 48 = 6+42 = 2^6 * H^6 = 64 ŮM,

In terms of paper tape, a foot of tape, with holes at 1/10 inch, makes 120, and it's not all that inconcievable you could have something like a 128 bytes make a foot.

I use this scale to translate decimal data sizes into twelfty, and i should imagine the same would go for dozenal, if somewhat smaller.

sunny - September 11, 2017 09:58 AM (GMT)
Thank you for your comments Wendy, but my problem is still with the issue "finding powers of the base that would be close to the binary powers", calling those closest numbers (if any) would confuse the issue to 'which prefix should be used for which purpose'. My proposal was to simply eradicate the 'binary powers' and have powers which would be pure powers of the base where radix shifting works. Also I proposed in favour of eradicating bytes (in measuring band width and representing storage space etc) and to use only the basic unit, the bit. So, as given by my example is that the band width of 1 hexquabit per pentciaday is equivalent to around 8.6 megabit per second or a storage space of 2 ennquabit is 1.2 Gibibytes. So, we could achieve no more fiddling with the numbers that are close enough to give them a same name and no more using multiple units (bits-bytes) that have the same initial alphabet which sound similar but are of different magnitudes where one is represented with lowercase and the other with uppercase. Not that using these differently to different suited applications always cause confusion but because they are unnecessary troublesome to quickly make calculations. For example, if 1GB of file is transferred at the speed of 10mb/s which won't take 100 seconds because 'G' here is not 10^9 but 1024^3 and 'm' is not 1024^2 but 10^6, adding to that 1B is actually 8b. But in my suggested way as example, if *10 ennquabit size of a file is being transfered at the average rate of *10 hexquabit per pentciaday, the file will get downloaded in *(10/10)(ennqua/hexqua)= *1000 pentciadays.

wendy.krieger - September 11, 2017 01:45 PM (GMT)
The closest is 2**18 107854 = 12**5, or 1/4 meg. The square of this is 64 Gig. This is a semitone equation of 216=217, about 10 times better than the next pair.

Outside of this, I would fall either on 128 = 144 or 2048 = 1728. In semitone terms, they correspond to 84=86 or 132=129. That is, an error of a log-difference of 1/21.

A ten-byte address is not really used except for the close connection to 1000. You use things like 8 or 9 or whatever.

The difference here is that kibi is far enough from kilo to make the thing worth wile having different, but close, prefixes.




Hosted for free by zIFBoards