HN user

jmts

542 karma
Posts8
Comments168
View on HN

AM reception is essentially the direct conversion of the strength (amplitude) of a given radio frequency into an audio signal. Any other noise present at the same frequency is added to the signal (superposition/interference) and therefore impacts the strength of that frequency at the receiver. Therefore it is impossible for the receiver to know whether the amplitude it received is just signal or is signal plus noise.

The claim 'the effect of random noise is to amplitude modulate' is probably not 100% correct, because to my understanding it's not actually performing modulation (the modulation happens at the transmitter but the noise happens between the transmitter and receiver), but it is impacting the amplitude at a given frequency and to a receiver this is impossible to know whether said change in amplitude happened before modulation (signal) or after modulation (noise).

FM works better because it is easier to detect the change in frequency independently of any change in the amplitude.

I'm unsure of what the correct terminology would be, but (for my linear algebra brain) you could say something like, for FM the noise dimension is orthogonal to the signal dimension, while for AM the noise and signal dimensions are the same. Therefore for FM any change in amplitude in the noise dimension should be mostly isolated from the signal dimension, while it is essentially impossible to tell what is noise and what is signal for AM - you could probably do some radio equivalent of a differential pair in order to detect noise and remove it, but then why would you bother when FM has improved noise rejection anyway.

My understanding of PC game development at the time was that most games would re-implement their own drivers for system hardware, hence why you would often need to select what kind of graphics card, sound card, and their settings during the setup. As such, a game running from a boot disk is closer to just skipping DOS and having no OS rather than implementing a custom OS, although from another perspective you might just say that the game is the OS.

Psytrance Guide 3 years ago

Ramtha's School of Enlightenment used to come to a university I used to work at between sessions while the students were away. They would have a section of paddock fenced off and would wander around it blindfolded making "PSSHHTT" noises to stop running into each other (I assume). They definitely seemed like a peculiar bunch.

It's hard to tell what's actually happening in that clip. To me it looks like the chain is actually fully off the rear sprocket just before the rear locks up (it appears to have come off around 1:12). At that point in time the rear wheel should just be free spinning. It also appears to be free spinning during the highside, which is strange because I would expect the most likely non-rider-error issue in this case to be the chain binding between the rear sprocket and the swing arm.

I'm almost inclined to call that one rider error. Their general body language and control of the bike don't suggest to me that they're an experienced rider, and it almost looks like they've just panic-braked and locked up the rear, except it's an odd speed and place to have done that too.

ValueObject (2016) 4 years ago

Programming is all about abstractions and the ways they interact. Specifically this article talks about what it means for two instances of an object to be "equal", which depends very much on what kind of equal you care about.

Consider the possibility that you order two laptops from your favourite computer store. When you order them, you customise one, then in the shopping cart you hit "+1" to order two of them, so for the purposes of this example they are functionally equivalent. When they arrive though, they have different serial numbers ABC, and XYZ. So then we start asking the question, are they equal?

One way of asking this question is "Do these two things perform the same function?" to which we can answer yes, ABC and XYZ perform the same function - this line of questioning treats the laptops as ValueObjects as described in the article - laptop ABC and laptop XYZ can be swapped for each other without concern about whether they will behave differently.

Another way of asking this question is what amounts to something closer to "Is this thing the one that I care about?". This line of questioning treats the laptops as ReferenceObjects. You've just received both laptops, taken them both out of the box, they're functionally identical except that you've decided that you want to use ABC for work stuff, and XYZ for personal stuff, and now you have some work stuff to do. You pick up one laptop and ask "Is this laptop ABC?" - not because the function of the laptops matter at this point, but now because of what they represent.

Both have their pros and cons (as described, ValueObjects are better when they are immutable, ReferenceObjects might tend to be more complex), and different languages make different choices about whether certain language primitives and standard objects/classes are implemented as ValueObjects or ReferenceObjects, but understanding them both conceptually allows you to write code that forces one kind of behaviour because that's what matters most for your chosen solution, independently of what the language you are writing it in has as its standard behaviour.

Slightly off topic, but I've followed this a little deeper and am wondering if anyone has any recommended Taoist reading? It appears this translation of Tao Te Ching is available in book form. Could anyone suggest a translation of Zhuangzi worth looking into?

Is bauxite really new cargo? Or do they mean ship-operators need to be careful when switching to bauxite cargo?

My read on it was that bauxite was new as a solid bulk cargo, not that bauxite itself was a new cargo in general. I know nothing of the industry however, so I'm not sure whether this is a legitimate interpretation or not.

Sure, there are absolutely varying degrees of screw up. You can make the same argument for anything. But for any position there is usually a general rule, and any number of exceptions.

The point here is that the general rule for human error should tend toward compassion, because the vast majority of mistakes people make are not that serious. In my world at least it seems that we prefer to tend toward punishment instead.

Admitting I'm wrong or that I screwed up ... You would not believe how much smoother everything at work is when you learn to recognize early the signs that you're holding on to a bad opinion, or that you're headed towards a fuckup, and just saying it out loud.

Avoiding judgement of those that have screwed up or have done something wrong, and simply working with them to correct it goes hand-in-hand with this. By the time someone admits they did something wrong, they already know what they did - by dwelling on that you're just wasting time and energy.

I wonder occasionally how many problems there are in the world that have become much bigger than they needed to be simply because the person who messed up knows the news won't be received well, so they keep their screw up hidden. Similarly, I wonder how effectively we teach children this kind of dishonesty by teaching them that honesty results in punishment.

While I generally agree with your sentiments here, and this is a somewhat pedantic response, with regard to the following:

The goal of code, however, is simply to communicate a process to a computer. Or rather, when that process is subject to change over time, to communicate a process to a computer, simply.

I would tend to disagree. Code is not about communicating with a computer. It is about communicating with humans. The computer does not care how the code is written - it is the humans that have difficulty with it. In a way, programming is the translation of a language that the computer understands into a form that humans can comprehend. Not so much the other way around. In this regard, clever is fine for a computer, but it is not always understandable to a human.

My understanding of 'set -e' is to ensure that errors are handled appropriately, not to brute force around them. If an error occurs that is not handled, this is treated as a problem and the script exits to ensure that one failure doesn't cause additional unforeseen problems as a result of the script running to completion.

Somewhat surprised not to see ClickSpring [1] on your list. Though maybe not so much home-improvement (I'd argue Welding Tips and Tricks isn't so much either), Chris' series on making a skeleton clock shows some top notch craftsmanship, and the production values are amazing.

At the other end of the spectrum (low-tech but maybe considered home-improvement) would be Primitive Technology [2] - an Aussie that builds all manner of things from clay, sticks, vines, and fire.

[1] https://www.youtube.com/clickspring

[2] https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA

I think culturally (western, not explicitly American, unsure about elsewhere) there is a bias toward people being incapable of change, that their actions in the past define who they are, and this probably results in people just continuing to do more of the same if they are unable to escape it.

Consider when children make a mistake or do something silly - often they are chastised or punished rather than educated and forgiven. Because of this we learn to lie about, hide, or pretend to misremember mistakes in a bid to mitigate the punishment we know we're about to receive. Later in life we're remembered by the things we've done in the past, and if you've done something bad enough (or even just silly or ignorant) it'll hang over you like a shadow for the rest of your life. Even if you personally feel like you've grown and moved on, there is always the risk that someone will dig up your past and throw it at you. In the end we live in fear of our past and feel controlled by it and that makes it harder to look into the future to become the person we might like to be. Those with sufficiently unfortunate pasts are increasingly rejected by society so they have no alternative but to continue adding to their unfortunate past because the communities that contributed to their past are the only ones that accept them.

Personally accepting that the mistakes you make don't define you as a person can go a long way to freeing yourself from some of the burden, but culturally it still lingers. Ultimately though there is a huge difference between shoplifting when you were a dumb kid, and becoming a serial killer. The threshold for redemption clearly varies with the severity of the crime, however it seems to me that in many cases we simply reject any chance of redemption outright and this probably hurts us more in the long run than it needs to.

The difficulty people have with treating the source of a feeling is probably because a lot of the time it's difficult to identify the source. I think many people often go with what their body tells them about what might resolve a symptom that they're feeling in the short term (get drunk and party), but in the long run the root cause may be something entirely different (develop relationships that are more intellectually stimulating).

In addition to positives acting in a way that can prolong a mental illness, often they can also deepen it as well. Generally you're aware of what you could be, or should be, or want to be, but can't be and don't understand why. This in itself can trigger negative thoughts and reinforce the cycle.