Due to the impacts of the coronavirus outbreak, we are experiencing longer than normal lead times on certain products. We encourage back-ordering out-of-stock items to receive them as soon as possible.
Member Since: July 11, 2014
Country: United States
I had never heard of Zeller's Congruence. I guess as a Aerospace Engineer I was taught to use the Julian date as it is also used as a convenient time base for time-of-flight calculations. Interestingly though, when I did a google search for Zeller's Congruence the calculation is very similar to that for calculating the Julian Day Number (JDN in the link I provided). So it looks like Zeller's Congruence is embedded in the conversion from Gregorian to Julian dates. Looks like I learned something new today.
For the Daylight Savings Time calculation, you can readily determine day of week by first converting the (Gregorian) date to Julian Date (https://en.wikipedia.org/wiki/Julian_day). If I were going to write the program, I'd precompute a lookup table which provides the starting and ending day of year as well as Julian date of January 1st for each year. Then each day, convert the date to Julian, calculate day of year using the January 1st reference, and if the day of year falls between the start and end days, apply the DST offset.
My advice (for what it's worth) is to always remember that while communication is good, reliable communication is better. To avoid embarrassment, I won't admit how many times I've had a component behave unexpectedly only to find out it was processing data that wasn't received correctly. So as I've gotten older and (arguably) wiser, I have forced myself into the habit of always sending data in packets - even if only sending a few bytes of data. The packet usually consists of a header to identify the data, a length field to indicate how much data is being sent, and a CRC or just a simple checksum so the receiving node can make sure everything came across uncorrupted. It may seem like overkill at the start of a project, but I've found that if you lay the foundation early for reliable communication, adding data later almost becomes trivial.
I agree completely and that is the point I was attempting to make (perhaps not as clearly as possible). Shawn stated that XOR isn't fundamental because it can be written in terms of AND, OR, and NOT thereby implying that those operators are in a sense fundamental. My post was trying to show that those operators can also be written in terms of other logic operators, thereby highlighting the fallacy in trying to label certain operators as fundamental. I think your use of the term basis is much more accurate.
Nice write up, but I want to pick on one thing. You said exclusive OR is not considered a fundamental logic operator because it can be written in terms of AND, OR, and NOT. If we follow that logic (see what I did there!), however, then AND and OR cannot both be fundamental logic operators because De Morgan's laws provide a relationship between AND, OR, and NOT:
NOT A AND B equals NOT A OR NOT B
NOT A OR B equals NOT A AND NOT B
So AND can be written in terms of OR and NOT, or OR could be written in terms of AND and NOT. We can also go one step further. If you write the truth table for a NAND gate, you'll see that it contains the logic for NOT if the inputs are connected together. So it's possible to construct AND, OR, and NOT from just NAND gates (you can do the same with NOR), meaning NAND is really the only fundamental logic operator.
Speaking of toilets with unicorn qualities, this commercial came on the other day, and... well, just watch - https://www.youtube.com/watch?v=YbYWhdLO43Q
If one were follow the fritzing diagram exactly, the red LED would not light up. The jumper connecting the resistor to ground is in the wrong place.
Unfortunately it took tragedy before SparkFun HR took those "working us to death" complaints seriously.
Actually, you don't need calculus to derive the equations for capacitors. The trick is to use electric charge, not current, and the definition of capacitance, C = Q/V. When the capacitors are connected in parallel, the charge supplied by the source is distributed between the two capacitors, thus Qs = Q1+Q2. When in series, the source pushes a charge into C1 which pushes the same charge into C2 which finally pushes the same charge back to the source, thus Qs = Q1 = Q2. With just a little algebra, the equations are yours.
Note: The calculus buffs would remind us that charge is just the integral of current, so I guess the calculus is there, just hidden!
I am very glad that I wasn't the only one to see that!
No public wish lists :(