Proposed Metric Calendar part 2

(continuation of this post: http://www.polarjetstream.com/2017/07/proposed-metric-calandar.html )

Ways to identify the day in Metric:

-Year, doy (day of year)
-Year, month, dom (day of month)
-Year, woy (week of year) (woy 1.0 = doy 10, woy 2.2 = doy 22)

Possible work and off days using a metric week.

Gregorian

71%: 5 work days, 2 off days

Metric

80%: 8 works days then 2 off days OR 4 work days then 1 off day then 4 work days then 1 off day
70%: 7 work days then 3 off days OR 4 work days then 2 off days then 3 work days then 1 off day (not symmetrical)
60%:  6 work days then 4 off days OR 3 work days then 2 off days then 3 work days then 2 off days

I'd prefer 3 ON 2 OFF 3 ON 2 OFF
-5 to 8 contiguous work days seems excessive
-4 contiguous works days seems OK, but the corresponding 1 off day seems insufficient.

One way to look at it is splitting the week into 2 mini weeks
1st half: OFF ON ON ON OFF, 2nd half: OFF ON ON ON OFF

2 other ways (shifted)
1st half: OFF OFF ON ON ON 2nd half: OFF OFF ON ON ON
1st half: ON ON ON OFF OFF 2nd half:  ON ON ON OFF OFF

Holidays

Gregorian Oct 31 (Halloween) occurs mid week of the first week of Metric November. I suppose holidays could continue to be held in terms of Gregorian and translated (via doy) to Metric, instead of converted (last day of Metric Oct is Gregorian Oct 26/27.)

Adoption

Replacing the Gregorian system any time soon doesn't seem likely. However with dynamically generated calendars using computers having multiple calendar system being used in parallel seems reasonable. Year and day of year (doy) remains the same between the 2 systems for easy translations, so year/doy would be a good way to note dates. Both year and doy are based on Earth (spin around it's own axis and rotate around the Sun.)

A better way to display nested code blocks

Admittedly this takes alot of lines (13 lines):

i=0;while(i<x)
{
j=0;while(j<y)
{
k=0;while(k<z)
{
//code here
k+=1;
}
j+=1;
}
i+=1
}

However, it is much easier to read than the 'industry standard' method of putting opening braces at the end of lines (10 lines):

i=0;while(i<x) {
j=0;while(j<y) {
k=0;while(k<z) {
//code here
k+=1;
}
j+=1;
}
i+=1
}

What would be nice is to write it either way you want, but when the cursor isn't nearby, display it like this (7 lines):

i=0;while(i<x)
▛ j=0;while(j<y)
▛ k=0;while(k<z)
▛ //code here
▙ k+=1;
▙ j+=1;
▙ i+=1

Easy to read AND doesn't take alot of lines!

\u259B = ▛
\u2599 = ▙

UPDATE:

Better yet, don't just display it that way when the cursor isn't nearby, but also write it this way.

▛ indicates exactly where the code block begins

 ▙ indicates that the code block ends at the next carriage return encountered

Floating point numbers core concept

The core concept of floating point numbers is that you take a magnitude (base^exponent) and add it to a fractional of the same magnitude to come up with a resulting number. When coming up with the appropriate magnitude, you choose the highest magnitude you can without exceeding the resulting number. Note that adding a magnitude to itself results in the next higher magnitude, so this covers everything between the 2 magnitude levels.

Some example base 10 magnitudes:
10^-3 = 0.001
10^-2 = 0.01
10^-1 = 0.1
10^0 = 1
10^1 = 10
10^2 = 100
10^3 = 1000

Some example numbers within the above magnitudes
1.00: 1 magnitude * 1.00
1.01: 1 magnitude * 1.01
1.02: 1 magnitude * 1.02

10.00: 10 magnitude * 1.000
10.01: 10 magnitude * 1.001
10.02: 10 magnitude * 1.002

Lets say the mantissa (digits right of the radix point) max out at 3 digits. As seen above that would mean the max precision at 10 magnitude would be 0.01.

100.1: 100 magnitude * 1.001

The higher the magnitude the lower the precision. At 100 magnitude max precision is reduced to 0.1. The mantissa essentially evenly divided the range between 2 magnitudes. In this case it divides it into 1000 evenly spaced levels. If limited to 3 mantissa digits, you can not represent the number 100.01. Though that's in terms of 'absolute precision', 'relative precision' is always maintained, relative precision in this case is always 1/1000 of the magnitude.

Changing to binary currency, no nickel and diming

Binary (hence computers) can not exactly reproduce 0.01 (cents) 0.05 (nickels) nor 0.10 (dimes). However binary can exactly represent 0.25 (quarters) and 0.50 (half dollars). The closest float 32 can get to 0.01 is roughly 0.009999999776482582

So maybe future currency can just get rid of pennies,nickels, and dimes, and instead just continue on the 'halfing' series:

0.5000 (half dollar) is half of 1.0 (dollar)
0.2500 (quarter) is half of 0.50 (half dollar)
0.1250 (eighth) is half of 0.25 (quarter)
0.0625 (sixteenth) is half of 0.125 (eighth)

Though writing down 0.0625 frequently can be annoying. It would be much easier to write in hex:

0.8 hex = 0.5000 dec
0.4 hex = 0.2500 dec
0.2 hex = 0.1250 dec
0.1 hex = 0.0625 dec

Though without hex alpha digits present (a-f) you wouldn't know it was hex instead of dec. Preceding with the prefix '0x' sort of defeats the goal of reducing the number of characters to write. Though perhaps hex could be the new format for currency and would be assumed after the $ dollar sign.

Hex fractions, and how to add the 4 types of 'binary coins' to create this value:

0.1 hex (01/16) (one of the 4 binary coins)
0.2 hex (02/16) (one of the 4 binary coins)
0.3 hex (03/16) = 0.1875 dec (0.2 + 0.1)
0.4 hex (04/16) (one of the 4 binary coins)
0.5 hex (05/16) = 0.3125 dec (0.4 + 0.1)
0.6 hex (06/16) = 0.3750 dec (0.4 + 0.2)
0.7 hex (07/16) = 0.4375 dec (0.4 + 0.2 + 0.1)
0.8 hex (08/16) (one of the 4 binary coins)
0.9 hex (09/16) = 0.5625 dec (0.8 + 0.1)
0.A hex (10/16) = 0.625 dec (0.8 + 0.2)
0.B hex (11/16) = 0.6875 dec (0.8 + 0.2 + 0.1)
0.C hex (12/16) = 0.7500 dec (0.8 + 0.4)
0.D hex (13/16) = 0.8125 dec (0.8 + 0.4 + 0.1)
0.E hex (14/16) = 0.8750 dec (0.8 + 0.4 + 0.2)
0.F hex (15/16) = 0.9375 dec (0.8 + 0.4 + 0.2 + 0.1)