'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;
}
Saturday, October 19, 2019
Saturday, August 31, 2019
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.)
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.)
Friday, August 30, 2019
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 = ▙
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
Thursday, August 22, 2019
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.
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.
Tuesday, August 20, 2019
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)
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)
Wednesday, July 17, 2019
2D Mouse tech specs analysis
Some typical gaming mouse spec values I see in 2019
(mps = meters per second, mpsps = mps per second)
CPI: 16000 (counts per inch) = 16000 counts per 0.0254 meters
IPS: 400 (inches per second) = 400 / 39.37 = 10 mps velocity
Accel: 50 g = 50 x 9.98 mpsps = 500 mpsps acceleration
0 to max speed in what time?
500 mpsps achieves 10 mps in 20 milli-seconds.
CPI at max speed must be lower than advertised?
Here's what got me wondering, can 16000 CPI be achieved at 10 mps?
There are almost 400 inches in 10 meters (393.7 to be more precise)
So 400 * 16000 = 6.4 million counts per 10 meters!
That would also be 6.4 million counts per second (hz.)
However, mouse polling rate (USB reports) maxes around 1000 hz.
What's the hz of the internal sensor? Manufacturers don't seem to list this, so who knows.
However, I assume the mouse doesn't lose track of it's relative motion/position at 50g while at 10mps
(it would be interesting to have a robot arm test this assertion, something tells me that when these 2 are maxed at the same time the mouse loses track)
What's the max speed one can do while maintaining 16000 CPI?
Not sure about internal polling, but with 1000hz USB polling, it seems that it would take 16 seconds!
OK then, so apparently it doesn't actually count each 'dot' per poll.
OK, so dots can be skipped between polls, CPI is just precision
So the question is how far can a mouse move between polls before it loses track of where it is relative to where it was on the previous poll? The field of view of the optical camera could be a big factor here. Ignoring internal polling (which is unlisted) at 1000hz USB polling, 10 meters / 1000 = 10 milli-meters which sounds reasonable. If internal polling is greater than 1000hz then this distance is less.
Values gleaned from
https://www.tomshardware.com/reviews/best-gaming-mice,6177.html
(mps = meters per second, mpsps = mps per second)
CPI: 16000 (counts per inch) = 16000 counts per 0.0254 meters
IPS: 400 (inches per second) = 400 / 39.37 = 10 mps velocity
Accel: 50 g = 50 x 9.98 mpsps = 500 mpsps acceleration
0 to max speed in what time?
500 mpsps achieves 10 mps in 20 milli-seconds.
CPI at max speed must be lower than advertised?
Here's what got me wondering, can 16000 CPI be achieved at 10 mps?
There are almost 400 inches in 10 meters (393.7 to be more precise)
So 400 * 16000 = 6.4 million counts per 10 meters!
That would also be 6.4 million counts per second (hz.)
However, mouse polling rate (USB reports) maxes around 1000 hz.
What's the hz of the internal sensor? Manufacturers don't seem to list this, so who knows.
However, I assume the mouse doesn't lose track of it's relative motion/position at 50g while at 10mps
(it would be interesting to have a robot arm test this assertion, something tells me that when these 2 are maxed at the same time the mouse loses track)
What's the max speed one can do while maintaining 16000 CPI?
Not sure about internal polling, but with 1000hz USB polling, it seems that it would take 16 seconds!
OK then, so apparently it doesn't actually count each 'dot' per poll.
OK, so dots can be skipped between polls, CPI is just precision
So the question is how far can a mouse move between polls before it loses track of where it is relative to where it was on the previous poll? The field of view of the optical camera could be a big factor here. Ignoring internal polling (which is unlisted) at 1000hz USB polling, 10 meters / 1000 = 10 milli-meters which sounds reasonable. If internal polling is greater than 1000hz then this distance is less.
Values gleaned from
https://www.tomshardware.com/reviews/best-gaming-mice,6177.html
Subscribe to:
Posts (Atom)