Planets moving in the sky

Earth's spin obviously causes planets to rise in the east and set in the west, just like all other astronomical bodies. However, when tracking their positions month after month at the same time of night, the reason for their movement is not so obvious.

If going by sidereal time (star time) the planets (excluding Mercury/Venus) actually move west to east because that's the direction of orbit (CCW when viewed from overhead.) Sidereal time is the actual time of Earth's spin. The difference between sidereal and 'regular' time is accounted for by the fact that the Sun and Earth move relative to each other (Earth's orbit) so the Earth has to make a full spin and then some to put the Sun back to the same point in the sky, because the Sun moved a bit, so it takes longer.

Going by 'regular' time (Sun time) straight up at midnight at a specific Earth longitude points to a different direction depending when in the year it is (30deg/month), unlike sidereal time. This very fact makes it confusing about how things move relative to each other, which is why astronomers use sidereal time rather than 'regular' time. Going by regular time gives the appearance that planets orbit CW rather than CCW (Mars and beyond don't orbit as fast as 30deg/month.)

Secure election system

This system can be used to counter-act potential corruption with the voting system.

-Every voter gets a 'carbon copy' of their votes.

-Every ballot is given an ID, and is identifiable on the state database by that ID.

-To ensure uniqueness of each database entry, each voter creates an auxiliary ID when voting. When looking at the state database their votes and chosen auxiliary ID shall match their carbon copy. This prevents a corrupt database system from giving many people the same ID but only counting one of them.

-State database file shall be accessible to all. A checksum can be used to ensure that everyone is looking at a legitimate copy.

-No personal identifiable information shall be on the State database. To further ensure integrity vote count by district shall be checked to reduce the potential of fake voting entries being added.

Traveling in blowing tunnels instead of vacuum tunnels

Not sure if this idea originated with the Boring Company or not
https://www.youtube.com/watch?v=iRi0bL484J0&t=10m40s

Blowers make alot of sense. Instead of vacuum tubes (where people can't breath in) push cars through with wind. No air friction because you're moving with the wind, not against. Not as noisy and one can ride with the top down in a convertible. Air doesn't become stale either with a constant renewal of oxygen rich air. If fact cars could put up a sail in the back for the air to push on. Not a sail made of fabric, more like one made of sheet metal. 

Generic loops for all scenarios

'for loops', 'while loops', and 'do while loops' are all specific cases of generic loops. Why not just have a generic loop structure that can be customized? while(true) loops can be used as generic loops.

-The crux of all loops is an implicit 'continue' statement at the end, and a way to escape.
-At any time you can branch to the top using 'continue'
-At any time you can branch out of the loop using 'break'

For readability:
-comment at the top of the loop what is going on with the loop, which should be done anyways.
-highlight branches so they stand out with a label left justified, like this (it would be nice if IDEs did something like this automatically)

while(true)
{
               stuff;
/*con*/   stuff; if(stuff){continue;}
               stuff;
/*brk*/   stuff; if(stuff){break;}
               stuff;
}

I find generic loops to be more readable than for-loops as you see exactly where an increment occurs and exactly where break check or a continue check occur.

Breaking out of outer loops

There should also be a way to continue and break in reference to an outer loop from within an inner loop, avoiding having to use a variable flag to pass this info between the 2 loops, or having to use a 'goto' statement which many want to avoid the like the plague. For example:

while(true)
{
       /*continue 2 goes here*/
       stuff;
       while(true)
       {
               stuff;
/*con2*/ if(stuff){continue 2;}
               stuff;
/*brk2*/  if(stuff){break 2;}
               stuff;
       }
       stuff;
}
/*break 2 goes here*/

Easy to replace For and Do While loops

//for loop equivalency
i=0;while(1)
{
        if (i>10) {break;}
        //do stuff
        i+=1;
}

//do while equivalency
while(1)
{
       //do stuff
       if (something is true) {break;}
}

//while equivalency (simply moves the check to the first line)
while(1)
{
       if(something is true){break;}
       //do stuff
}

//if equivalency
while(whatever)
{
    stuff;
    break;
}

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.