Thanks, beat it following your plan. Very cute that at times the game punishes the player for being too productive with tractors.
HN user
adinisom
So far have not made it to phase 3.
Despite improving production (more tools! more assistants!) and bonus tractors (work harder! heroic labor brigade!) it's not enough to make up for phase 2's punishing 1000 tractors in 60 days, or roughly 16 tractors a day. Even if we give ourselves a full 120 days, that's 8 tractors a day and we seemingly cannot accumulate tools and assistants early enough to do that.
Great seeing where Speech with Sam and, more generally, you ended up.
In Stratton Oakmont v. Prodigy, Prodigy ran a message board and would have escaped liability for defamation by a third-party save one problem: they exercised editorial control by moderating content.
Hacker News faces the same risk.
Respectfully I prefer a world where Hacker News exists.
Appreciate you sharing that. Agree with the overall concern with children using tech and I'd start with banning smartphones in school classrooms. Two observations:
Why stop with image boards? After eliminating all photo uploads, awful people still produced and shared illegal content. So then we eliminated unlicensed camera use. 'Course the real problem still happened.
Hacker News is made possible by Section 230... should it not exist?
There's some logic to wanting to assign responsibility for other's actions upon those who enable it. Like you say, to incentivize intermediates to police their users and those they do business with.
But the problem with deputizing intermediates is that it's too effective. It creates incentives to over-police and we have less rights against corporate policing than we do government policing. We would not have the internet we have today without the user generated content and moderation that section 230 enabled.
If you want to pull another cable:
- secure a string to the old cable
- pull the cable out the other end, pulling the string through
- secure the string to the new cable
- pull the string out the other end, pulling the new cable into position
The picture in the article shows what looks like keypoint matching (ie, SIFT, SURF, FAST) between the query picture and the database. This can give an exact location if a picture of the location exists in their database.
They contrasted this with their prior technique which is more of an image classifier that can identify general location from image features. This approach does not require their database to contain a picture of the exact location.
A while back I looked at matching pursuit. At first it seemed very complicated, but after staring at it a bit realized it's simple.
- Start with a list of basis functions and your signal.
- Go through the list and find the basis function that best correlates with the signal. This gives you a basis function and a coefficient.
- Subtract out the basis function (scaled by the coefficient) from your signal, and then repeat with this new residual signal.
The Fourier transform is similar using sine wave basis functions.
The key that makes this work in situations where the Nyquist theorem says we don't have a high enough sampling rate is ensuring our sampling (possibly random) is un-correlated with the basis functions and our basis functions are good approximations for the signal. That lowers the likelihood that our basis functions correlating well with our samples is by chance and raises likelihood it correlates well with the actual signal.
Buildings as walls and using spawn points to jump through terrain are fun mechanics in WC2.
Addressing comments on hearing aid technology:
Often people who lose their hearing want to be able to hear in social situations such as restaurants and family gatherings. In this context, the signal and noise have similar properties and are coming from the same direction. Directionality helps but can only do so much. Noise reduction can make hearing aids more comfortable to wear but don't necessarily improve comprehension in challenging situations. Progress here is fantastic -- at the same time it helps to have realistic expectations.
Putting the mic on the person speaking sidesteps the problem -- it's like the rest of the room isn't there.
Hearing in noise is both what most people want from hearing aids and what they are least equipped to provide.
The traditional solution is an FM system where you give the person speaking a microphone linked to your hearing aids. There are dedicated ones like Phonak Roger. You could probably also use your phone as a microphone if it's bluetooth connected to your headphones or hearing aids.
I read it as:
Dan is a moderator on a forum and his goal is to maintain a level of civil discourse rather than an aggressive style of communication. It's a very specific definition of "violence" for a specific context and perhaps there's room for clearer terminology.
If talking about UI, the flip side is not to harm the user's data. So despite containing errors it needs to representable, even if it can't be passed further along to back-end systems.
For parsing specifically, there's literature on error recovery to try to make progress past the error.
Two that come to mind:
1) Embedded systems typically do not allow data to grow without bound. If they were going to keep debugging data, they'd have to limit it to the last N instances or so. In this case N=0. It seems like the goal here was to send troubleshooting data, not keep it around.
2) Persisting the data may expose the driver to additional risks. Beyond the immediate risks, someone could grab the module from the junkyard and extract the data. I can appreciate devices that take steps to prevent sensitive data from falling into the hand of third parties.
Yes, 100%. State transitions are "goto" by another name. State machines have their place but tend to be write-only (hard to read and modify) so are ideally small and few. Worked at a place that drank Miro Samek's "Practical Statecharts in C/C++" kool-aid... caused lots of problems. So instead I use this pattern everywhere that I can linearize control flow. And if I need a state machine with this pattern I can just use goto.
Agreed re: making the state a static variable inside the function. Great for simple coroutines. I made it a pointer in the example for two reasons:
- Demonstrates access to the state variables with very little visual noise... "s->"
- For sub-coroutines that can be called from multiple places such as "delay" you make the state variable the first argument. The caller's state contains the sub-coroutine's state and the caller passes it to the sub-coroutine. The top level coroutine's state ends up becoming "the stack" allocated at compile-time.
My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine:
typedef struct blinky_state {
size_t pc;
uint64_t timer;
... variables that need to live across YIELDs ...
} blinky_state_t;
blinky_state_t blinky_state;
#define YIELD() s->pc = __LINE__; return; case __LINE__:;
void blinky(void) {
blinky_state_t *s = &blinky_state;
uint64_t now = get_ticks();
switch(s->pc) {
while(true) {
turn_on_LED();
s->timer = now;
while( now - s->timer < 1000 ) { YIELD(); }
turn_off_LED();
s->timer = now;
while( now - s->timer < 1000 ) { YIELD(); }
}
}
}
#undef YIELD
Can, of course, abstract the delay code into it's own coroutine.Your company is probably using hardware containing code I've written like this.
What's especially nice that I miss in other languages with async/await is ability to mix declarative and procedural code. Code you write before the switch(s->pc) statement gets run on every call to the function. Can put code you want to be declarative, like updating "now" in the code above, or if I have streaming code it's a great place to copy data.
Humans are also created/derived from other works, trained, and used as a tool by humans.
It's interesting how polarizing the comparison of human and machine learning can be.
I would assume EasyTier devs use it to connect their devices within China so the great firewall isn't involved. Attempts to cross the firewall with EasyTier are detectable without things like Tor's pluggable censorship evasion transports.
Agreed: caution is advisable.
At the same time shaping perception is key. Authorities may push a narrative that affords them greater control. If that's not the world you want, the first step is not to legitimize it.
The effective number of bits (ENOB) is only ~8.7. Originally designed to have an ENOB of 9+ bits, but silicon bugs lowered it.
There is also some noise from the Pi Pico power supply which could be a good thing if you're willing to average or filter over a large number of samples.
More details here: https://pico-adc.markomo.me/
Done for effect: it felt to the OP as if it was the present so the writing conveys that, while elsewhere making it clear the arrest was not the present.
On Youtube I really like the auto-generated captions and often prefer them to the creator's because:
- Sometimes the creator bases their captions on the script and misses changes in edit
- Sometimes the creator's captions are perfect transcriptions but broken up and timed awkwardly
Auto-generated captions aren't always perfect but unlike human captions provide word-by-word timing.
If bufferbloat is increased latency caused by excessive use of increasingly available RAM, then turbobloat is increased latency caused by excessive use of increasingly available CPU.
Certain vintage hardware had a "turbo" button to unleash the full speed of the newer CPUs. The designers blind to the horrors of induced demand.
They can definitely be distinct languages as is the case with protactile. For the deaf-blind people I've met, ASL is their first language and protactile is more of a second. Maybe it's different in other areas of the world.
What I've noticed is that in deaf-blind contexts plain ASL is terrible for back-channeling information... is the listener paying attention? Agreeing? Disagreeing? Laughing? Protactile communicates these back to the signer using touch, and not touching is considered rude.
The intended solution seems to be a 2% bandwidth limit for announcements and a preference for lower hop-counts to keep your flooding local.
There's a FAQ item on this: https://github.com/markqvist/Reticulum/wiki/Frequently-Asked...
Deaf ASL users have much less need to hear since their language doesn't require it. For that reason I suspect deaf folks generally find hearing less important than blind folks find seeing.
There are blind people like Daniel Kish who use echolocation to replace sight; I get the sense they're more on the difference side of the fence.
Not sure but can mention some challenges:
- The power budget of a traditional HA is ~1mW and operate on ~1V. Existing vendors use custom silicon with sub-threshold designs to hit this. I see this as one of their largest moats. Lipo rechargeable wearables work around this problem.
- Customers for your product want their hearing back, and that's not something HAs realistically provide. So selling them is pretty weird as your customer isn't going to be completely satisfied and newer HAs won't improve much along this dimension. On the other hand you can sell "comfort" via noise reduction, bluetooth streaming, and whatever technology buzzwords you can fit on a brochure.
- But can my fancier DSP algorithms improve speech understanding in noise? Maybe, but you've got a 10ms latency budget in which to do so. Hard to compete with the human brain which can cheat and backdate perceptions into the past.
- FM systems, on the other hand, can dramatically improve speech understanding by eliminating noise and echoes. Right now it's only a fit for situations where you can mic the speaker. Traditional HA companies have a hand in making these.
Mine used to have the problem. Upgrading the firmware and using Ethernet did not fix it.
Observation: disconnecting the printer from the network avoided the un-wake-able "deep sleep" state. Re-connecting the network made it susceptible again. I suspect it's particular network traffic that causes the printer to wedge into a sleep it cannot leave; possibly a Debian box that I've since de-commissioned. The problem no longer occurs despite having the same firmware as before and being connected to the network.
When you're in a better place, maybe have someone else ship them so you don't have to deal with it.