|
Post by fcg710647 on Sept 17, 2015 21:11:40 GMT -8
I'll do some encoding myself then. Let's say we have four bytes, what does it look like when encoded in hex and the base 42 strategy?
Bytes: 00010111 11011101 00010111 01100011 -> in decimal, these represent 23 221 23 99 Hexadecimal: 17 DD 17 63 (using the convention, where D is thirteen) Goofy forty-two, which takes two bytes at a time: 3GG 3Jj (that's it ^^)
|
|
|
Post by Buffoonery on Sept 17, 2015 22:29:24 GMT -8
When you increase to a higher base like that, while collecting prime factors, does it open up new problems between numbers? An example of what I'm trying to ask would be easier to explain when we compare base 10 to 12: ___In base 10___: 3: 3,6,9,12,15,18,21,24,27,30 [10 digits-Bad] 4: 4,8,12,16,20 [5 digits-Medium] *5: 5,10 [2 digits-Good] 6: 6,12,18,24,30 [5 digits-Medium] 7: 7,14,21,28,35,42,49,56,63,70 [10 digits-Bad] 8: 8,16,24,32,40 [5 digits-Medium] We have 1 Good digit, 3 Medium digits, and 2 Bad digits.
___In base 12___: 3: 3,6,9,10 [4 digits-Decent] *4: 4,8,10 [3 digits-Good] 5: 5,d,13,18,21,26,2E,34,39,42,47,50 [12 digits-Bad] *6: 6,10 [2 digits-Good] 7: 7,12,19,24,2E,36,41,48,53,5d,65,70 [12 digits-Bad] *8: 8,14,20 [3 digits-Good] 9: 9,16,23,30 [4 digits-Decent] d: d,18,26,34,42,50 [6 digits-Medium] E: E,1A,29,38,47,56,65,74,83,92,d1,E0 [12 digits-Bad] That's 3 Good digits, 3 Decent, and 3 Bad.
___In base 42___: What would be the ratio of Good, medium, to Bad? Since it has so many numbers, it's hard to even get started, or even write the numbers (since we only have 26 letters). One of the things that pops into my head is that if a number is hard to work with, there will be a lot of digits to go through before that number has reached a nice number.
|
|
|
Post by Buffoonery on Sept 17, 2015 22:31:25 GMT -8
Wait, how does 42 take 2 bytes at a time?
|
|
|
Post by Buffoonery on Sept 17, 2015 22:39:58 GMT -8
From what you're describing, 42 would be very useful for large numbers, like 42^3, that's a hefty chunk, I can see that having an extra dimension of another prime factor for this would be pretty useful. But for every day use, I think it would be a bit clunky.
Haha, and now I know why the answer to the universe and everything is "42".
|
|
|
Post by fcg710647 on Sept 17, 2015 23:43:01 GMT -8
These digit ratios depend on what factors the digit has in common with the base. I mentioned in the prime sieving post that base 42 has twelve totatives (digits with no common factors); fortunately, this is fewer than 1/3 of the digits (it's exactly 1/3 of them in dozenal, 4 totatives for it, and base 36 also has twelve totatives, 1/3 of its digits). Any base with 2 and 3 as prime factors has a 1/3 chance of a digit being a totative. This can be derived by multiplying (prime - 1) / prime for each prime factor. This is why binary has one totative (1/2 probability) and octal has four totatives (still a 1/2 chance because it's just a power of two). This is enough proof that going for four primes isn't worth it (base 210) Probability for base 42: 1/2 * 2/3 * 6/7 = 2/7 = 0.285714285.... in decimal Probability for base 30: 1/2 * 2/3 * 4/5 = 4/15 = 0.2666666.... slightly better, base 30 has 8 totatives, base 24 has 8 of them as well, so its probability is still 1/3 Probability for base 210: 1/2 * 2/3 * 4/5 * 6/7 = 8 / 35 = 0.228571428571428... that is a little lower, but not worth being five times as high as 42, and base 210 in total has 48 totatives Ok, then, what digits are more compatible with base 42? We know the bad ones are 5, 11, 13, 17, 19, 23, 25, 29, 31, and 37. Of these, only 25 is composite (5^2). This is clear because those numbers are not multiples of 2, 3, or 7 (the prime factors of 42). They do have the full cycle length of 42. Again, it sounds like a lot, but the odds of running into one of them is still not bad since there are so many digits in total. Good digits: Half of 42 is 21 so it has a period of 2 1/3 and 2/3 are 14 and 28, so they have cycles of three 1/6 and 5/6 must also be good, which are 7 and 35, they have periods of six 1/7, 2/7, 3/7, 4/7, 5/7, and 6/7 have to also be good and have periods of seven. These digits are 6, 12, 18, 24, 30, and 36. Periods longer than these may be considered "moderate"? lolz The remaining fourteenths are moderate (periods of fourteen). These are multiples of three but not of 2 or 7 and are 3, 9, 15, 27, 33, and 39. All the digits I have not mentioned by now must be even, but not multiples of 3 or 7. I feel bad for you, damn elementary school needs to discuss writing every integer as a prime factorization and really emphasize how important it is, those primes tell you everything. It's easy to notice that using a large prime base, such as 29, would make all those digits "bad" because they have no factors in common with 29. What about 42? Does the digit have a 2, 3, or 7 in it? That's how the analysis is done. The digit 4 only has a 2 in common with 42, since 42 is only divisible by 2 once, but 18 and 42 are both divisible by 2 and 3 and so both have 6 in them. The other way to look at it is with all the fractions where the denominator is a factor of 42: 2, 3, 6, 7, 14, or 21 (neglecting 1 and 42 themselves). Multiplying these fractions by 42 gives a digit that can not be "bad" because the fraction isn't irreducible out of 42, a bad one being 11/42 (those damn larger primes). So, why the hell would I want 42 instead of 30? Dividing by twos is easier in 42 due to patterning, 42 has fewer cyclic primes (most notably, an eleventh repeats five digits instead of ten), and I don't like trigesimal's repunits as much. The fifth and eleventh repunits in trigesimal are prime; in other words, (30^5-1) / 29 and (30^11-1) / 29. For the fifth one, this means that the only way to get a recurring period of length five is to divide by the prime number 837931. All sorts of other numbers that could repeat five digits in base thirty end up repeating longer patterns. 30 is also a very inconvenient size for encoding in the way I described. It could be used to handle four bytes in seven digits, but the smallest base that can do that is 24, hahaha and 42 is so nice to be able to take bytes in twos, there is an encoding format called ASCII85, and yes, it uses base 85!?! This scheme fits four bytes into five digits of base 85, because 85^5 is just larger than 256^4. Even more compact, but pretty problematic when the number of bytes isn't divisible by four.
|
|
|
Post by fcg710647 on Sept 18, 2015 9:14:19 GMT -8
1/2 = 0.a 1/4 = 0.ta 1/8 = 0.5ta // A pattern appears, as in octodecimal, unlike in trigesimal, although it stops here for a bit. 1/2^4 = 0.2?ta // Still ends in "ta," digits for ten and twenty-one, and now these digits are all even except the last, divide by two again 1/2^5 = 0.1H5ta // So the ? to H is 26 to 13
What about 3/8? 1/8 + 1/4 = 0.5ta + 0.ta = 0.AFa // If this is translated to decimal, it's (21 + 31 * 42 + 15 * 1764) / 74088, 1764 is 42^2 and 74088 is 42^3, so it is 27783 / 74088, reducing to 3/8. So we can add 1/6, 1/7, 1/8, and 1/9?! 0.7 + 0.6 + 0.5ta + 0.4Z = 0.NZ + 0.5ta = 0.0Z + 0.]ta = 0.]wa // That one looks wacky --> (21 + 38 * 42 + 22 * 1764) / 74088, reduces to 275 / 504, that would have been ugly in least common denominator, lmfao
|
|
|
Post by fcg710647 on Sept 19, 2015 9:26:58 GMT -8
One advantage of big bases is borrowing and carrying less often. Just look at binary, if you have to add 101101011 to 101100111, how many times you carry onesies.
|
|
|
Post by Buffoonery on Oct 2, 2015 3:10:17 GMT -8
Alright, now I really wanna find an easy way to memorize numbers. But, it'd also be nice not to use letters, but if we have to, then maybe they should be a predictable pattern. 1,2,3,4,5,6, a,b,c,d,e,f, g,h,t,u,v,w, x,y,z,Z,X,Y, W,V,U,T,H,G, F,E,D,C,B,A, [,],7,8,9,10
[7 rows of 6 characters]
Grrr, needs a lot of work.
|
|
|
Post by fcg710647 on Oct 2, 2015 11:06:01 GMT -8
How many languages, Chinese, Korean, Japanese... sub versions of these, etc. etc. have thousands of symbols? Rofl I'm okay with 42...
|
|
|
Post by fcg710647 on Oct 10, 2015 11:04:58 GMT -8
Time to arrange 30 objects (2*3*5)? The border becomes a dodecagon.
_____O_O_____ __O_O_O_O_O__ _O_O_O_O_O_O_ __O_O___O_O__ _O_O_O_O_O_O_ __O_O_O_O_O__ _____O_O_____
|
|
|
Post by Buffoonery on Oct 11, 2015 10:25:22 GMT -8
If you want to make it easy to convey information, a pattern would be nice to use. Since this is a base that is still in construction, we have the ability to make it much more legible. Language sadly can't do this, it's been hard wired into billions of citizens (at least for Mandarin), in the same way that base 10 Arabic numerals are hard wired into most of the world.
I know base 60 was used in Babylonian times, but they had order among their numerals, if you knew an adjacent number, you could assume the next or previous.
---
Oooo, interesting, I like that shape. For some reason, it makes me think, which base would be the best for representing a calendar? If you want a clean amount of months, 13 would be a nice number.
Days of the year: 13 * 28 = 364, 1 extra day would be required at the end of the year. Days of the week: 1/7 = .1B--- So, those 2 are handy.
However, base 13 is odd, so that's a no go.
|
|
|
Post by fcg710647 on Oct 11, 2015 15:36:34 GMT -8
13 is also prime, unlike 15, which has 4 factors and is the best odd base unless you like nonary (3^2).
That 365.2422 days in a year figure is still a pain in the butt for any base. Anyway, 364 = 26 * 14 (I'm sure you noticed the 28 was divisible by 14), so base 14 would also reach 364. If you divided a year into 14 months, a "normal" year would have 13 of them with 26 days and 1 month with 27, and a leap year would need 2 months with 27 days and 12 of them with 26.
1/7 = 0.2 exactly in base fourteen lolz How many days in a month would be too few for a reasonable division of that days in a year figure?
|
|