nestes
If I knew for certain (big if) that a business would never have a liquidity event and I couldn't transfer my ownership then it's dead capital for all intents and purposes and you could consider its value essentially $0, right?
Since you have an EE background, I would recommend a few strategies (in any order, except 0 should be first if you have major deficiencies):
0) Brush up on some of your math if you need to. Linear algebra (just up to Eigenvector/Eigenvalue), vector calculus, differential equations. Mostly just understanding the concepts is OK, because the major derivations for RF engineering are relatively simple problems. That said, RF engineering is just one big love letter to linear algebra.
1) Read Pozar, as another commenter have suggested, but you don't need to cover-to-cover it. You absolutely must know some network theory, the basics of transmission lines (characteristic impedance, propagation, loaded driving point impedance), and simple matching techniques (basic RF design is about 75% just making sure power goes where you want it to). Beyond that you can pick and choose depending precisely on what you're doing.
2) Read older papers (1940s-1980s depending on topic) on whatever you're interested in. They're going to assume relatively little starting information. The only caveats are that notation has changed and that a lot of the design techniques, while still valid, were more useful when simulators weren't readily available (i.e. they assume a really strong mathematical background).
3) Stay low frequency as much as possible early on. <6 GHz for sure, ideally lower. This makes things a lot cheaper (metrology, components) and makes mechanical tolerances less critical. Stuff just gets less "fiddly". There's of course a tradeoff where things start to get pretty big at low (10-100's MHz) frequencies.
4) Tear apart anything you can get your hands on -- broken metrology equipment for one. Try and figure out why people are doing what they're doing. Just because a system's cheap doesn't mean they aren't using some cool tricks.
If you're not a Zotero user, I can't recommend it enough.
Which to your point: You're absolutely correct that you can use a bunch of different sets of functions for your decomposition. Linear algebra just says that you might as well use the most convenient one!
It took me some time, but now it's a lot better -- like a little game I somewhat know the rules of. I now accept that mathematicians are often worrying about maximal abstraction or addressing odd pathological corner cases. This allows me to wade through the complexity without getting overwhelmed like I used to.
I do broadly agree with your position that some people are going to excel where others fail. We know there trivially exist people with significant disabilities that will never excel in certain activities. What the variance is on "other people" (a crude distinction) I hesitate to say. And whatever the solution is, if there is even a solution, I'd at least like for the null hypothesis to be "this is possible, we just may need to change our approach or put more time in".
On a slightly more philosophical note, I firmly believe that it is important to believe some things that are not necessarily true -- let's call this "feel-good thinking". If someone is truly putting significant dedicated effort in and not getting results, that is a tragedy. I would, however, greatly prefer that scenario to the one in which people are regularly told, "well, you could just be stupid." That is a self-fulfilling prophecy.
Now if we find (or author) a recipe that we really like, we send it, with any additional annotations, to my parents so that they can include it in the next print edition. It's a relatively time-intensive and expensive process, but from this point forward we should be able to maintain our family's recipes in a physical, living document form.
Maybe we don't get the yellowed pages and flour from grandma's hands on the cover, but I think it's a good system.
More critically: you want to be very very careful about trying to extrapolate this filter down to lower frequencies. We're dealing with "weird physics" here. I am not an expert on spin-wave devices by any means, but a guy in my lab during grad school was working with them, so I do know that the resonant frequencies of the spin-waves are a function of the magnetic bias and the material. The researchers here are tuning the filter by tuning the magnetic bias. Someone more knowledgeable can correct me, but I believe YIG would have trouble propagating spin-waves down at 600 MHz, and so this kind of filter would not be practical.
From an circuit analysis standpoint (your problem may be different), but exponentials that decay over time ("a" is negative) corresponds to loss in a circuit, whereas exponentials that grow over time ("a" positive) correspond to something blowing up (this is really a nonphysical result but generally means a circuit is going to oscillate on its own, without a source driving that response). I mostly do electromagnetics/passive RF types of problems, in which you generally want everything to be low-loss. In that case Fourier is perfect, especially since I typically care most about steady-state behavior.
Convolution turns into multiplication, differentiation wrt time of the complex exponential turns into multiplication by j*omega. I don't know about you, but I'd rather do multiplication than convolution and time derivatives.
As a corollary, once you accept "we use the Fourier representation because it's convenient for a specific set of common scenarios", the use of any other mathematical transform shouldn't be too surprising (for other problems).
We don't typically have log files for hardware, but I'm always surprised when otherwise extremely intelligent people first try to debug by applying "fixes" that shouldn't have any causal effect on any weird observations we've gotten. I have no problem with people coming up with theories because each modification takes time, but each theory should ideally explain the data...
Now here's the catch: If the receive area were not changing as a function of frequency when the receive antenna gain is kept constant (it does), this would break physics (it doesn't). However, the effective area of an antenna with fixed gain varies as 1/lambda^2. In effect the geometric interpretation is still correct, but the variation of antenna area with gain resolves the seeming paradox and saves physics.
Where the "bogus" gain really shines, though: I can take my original receive antenna, operate it as a transmitter (so gain is now relevant), receive with my original transmit antenna (where I now care about area) and get the exact same result in terms of loss!
That said, a receive antenna does absolutely have "gain", which is evident by the antenna receiving a stronger or weaker signal depending on its orientation with respect to the transmit antenna. The key is this: for an arbitrary antenna, the (transmit, if you like) gain has a one-to-one relationship to the "effective receive area" at a given frequency, so talking about area and gain are equivalent, if not intuitive. We usually assume for point-to-point links that the antennas are oriented at each other, and in such cases (for good aperture antennas), you are absolutely right that the physical area and effective area are approximately equal. For ideal wire antennas, however, the physical area of the antenna is 0, but the effective area is nonzero (because of magic).
Now, I disagree that the path loss equation violates conservation of energy. The link to the effective area and gain depends on the wavelength. When I increase the frequency of operation but I keep the gain of the antennas constant, the areas decrease, so my receive antenna is physically smaller and the power goes down. Not breaking physics. A lot of people will say "path loss gets worse as you go up in frequency", and this is extremely misleading if not "scientifically illiterate" as you pointed out. Sure, there are molecular absorption bands from oxygen/water that literally dissipate power in the atmosphere, but generally speaking, the path loss didn't get worse, your receive antenna just got smaller.
Now wait a minute, what if I just made my receive antenna larger? Well, you can do that! The problem is that because gain and area are linked, efficiently receiving power in a given LARGE area (with respect to the wavelength) implies high gain. High gain implies a very narrow beam (more like a laser pointer than a normal dipole spilling energy everywhere). So it becomes really important that I "point" my receive antenna perfectly at the transmitter. Satellite dishes are really big, and they absolutely have to be pointed accurately at the satellite.
1) I buy physical textbooks and absolutely destroy them with notes in the margins, highlighting, etc. It helps me to interact with the material instead of letting it wash over me, which means I'm both thinking about it more in-depth and as side effect I'm less bored. Otherwise I'll fall asleep and won't learn anything. 2) I accept that I'm not going to remember the entire book. A lot of books are most useful as references anyway. But if you ever find yourself going, "Oh that's really handy to know," then you can make a special note of it or even put it into flashcards. I've been using Anki. The trick is to recognize what is actually worth doing this for. 3) If something is especially worth knowing, (see point 2), see if you can either do problems from the book or try out the concept in some way if there are no problems available.
If you're reading something just because you feel like you should, you won't get anything out of it (or a least I don't).
I didn't have any other objections to the printer, for what it's worth.
a) I had full control of the back-end, so my solution was ultimately fully custom -- I don't have any APIs to point to, sorry.
b) Look at the iCalendar specification if you haven't already if for no other reason than to see what kinds of crazy corner cases they were expecting to support.
c) Generally speaking, making recurring series of events ('recurrence sets' or 'rsets') is "easy", but altering rsets will make you want to kick a small animal. I'm just going to throw out a couple of examples to indicate how annoying this can be.
Assuming each event is in a rset. 1) I move an event on a week calendar from Tuesday to Thursday. Is there an event in the rset in the preceding week that should now be visible on my calendar? 2) I move an event in a series recurring on T/R from T->R. Is the set now R/Sa or is it still T/Th? 3) Do I permit changes to a single event while still allowing it to be a member of its recurrence set (iCalendar allows this!)? More to the point, do subsequent changes of that rset affect the event that you've now changed? 4) I move event from a T/R rset to a Friday. Does it even exist anymore? It's not on a Thursday or Tuesday after all (not joking!). And there are so many "gotchas" of this variety.
Granted, a lot of this complexity will be the job of the backend, for which you may or may not be responsible. But you still need to affirmatively decide if you're going to ask the user if they want to make a ("this"/"this and following"/"all") type of edit on certain actions and what an action maps to in terms of the API you're using. And if you ever want to implement your own backend, you're locked into that decision and you might hate yourself later.
As for my personal solution (again, I was writing the backend): Most calendar implementations of recurring events (if the iCalendar specification is followed) comprise a "base" event and a recurrence rule from which the other events may be calculated. I personally settled on a much more rudimentary solution where each event was initially calculated via a recurrence rule but was stored a first-class entity in my database. I also prohibited changing the recurrence rule of for a set of events that was already created. This made it so that the recurrence rule actually had no semantic meaning besides at creation. The individual events were linked in a "group" and things like drag and drop operations were done just by computing the time delta and shifting each individual event by that amount. I NEVER regretted making my calendar "dumber" and almost always regretted making it more clever.
A last word of warning -- if you do not know precisely the "specification" you want to achieve in terms of what actions are permitted on rsets, you are 100% going to rewrite it multiple times (ask me how I know :p).
Have you decided how (or if) you're going to handle recurring events? Because that has huge implications for how otherwise "simple" changes to events behave, both from whatever backend you use as well as the UI.
This may be a bit tangential, but something like 1/8th of surviving classical Greek literature (1000 years!) is attributed in part to Galen. While he was quite prolific, the point is that the entire corpus is extremely small.
We didn't even have the capability to record audio and video until the early 1900s, and certainly not in a mass, centralized, easily-distributable sense until the internet. Having a million monkeys write Shakespeare is pure happenstance, but having a million Shakespeares is inevitable. I abstractly worry that even besides the junk, there will actually be so much PHENOMENALLY GOOD stuff that would-be creators and artisans will be discouraged instead of inspired.
Let's hope that you're right about the real carvings. That at least is not so scalable.