mlpack, a C++ machine learning library, includes xeus-cling notebooks directly on their homepage: https://www.mlpack.org/
The xeus-cling work is awesome and has made it possible to do data science prototyping in C++. There are lots of other C++ notebook examples in the examples repository: https://github.com/mlpack/examples/
> I feel there is a bit of undercurrent of Luddite sentiment going around here.
Oh, I'm no Luddite, don't get me wrong---I'm a machine learning researcher. I have no problem with data science. The difference between all of the complex technology you pointed out inside the baby monitor and what we're talking about here is that all of that complex technology is robust and, for the most part, well-designed! The data science work here has tons of issues, and I think the vast majority of reactions are reacting to that: machine learning and data science really can be useful... but not if you apply it really badly. Someone else commented elsewhere in the thread that a simple thresholding algorithm would be just as effective---and not suffer from the myriad potential problems present with blindly applying TensorFlow because it's cool.
> the real downside of this model: it overfits on regular crying
I'm with you there, that's a big downside too, but that's not the "real" downside---there are like seven different downsides present with the data science going on here and it's hard for me to say which is the biggest issue, because they're all issues. Data science is not trivial!
So, don't get me wrong. This is a fun project and a neat little device. I don't mean to take away from it in any way.
However it is really important to consider why baby monitors are so primitive: because the cost of a false negative is huge. I didn't see any mention of this in the author's experiments (only a '>98% accuracy' note). So let's talk about this a little bit: is "accuracy" what we want? Probably not---I don't care if I get accidentally notified, but I care very much if I don't get notified when the baby is crying. So you want to weight your classifier's predictions heavily against false negatives (at the price of false positives). It would be good to make an ROC curve to characterize this behavior. More importantly though, any predictive model assumes a stationary distribution; i.e., training conditions accurately reflect test conditions. But will they in real life? What about when your neighbor's house is under construction? Can interference from chainsaws cause the model to fail to detect the baby crying? What about the dude down the street with his super loud motorcycle? What happens then? I bet the training set doesn't have situations like this.
I really, really don't want to come off like a wet blanket here. But I feel obligated to, because this is a model that directly impacts the welfare of a human, and so we should at least talk about or discuss potential drawbacks. (Again, cool weekend project, just, we need to be clear about the implications of outsourcing the decision of whether the baby is crying to a black-box model where we can't interpret what it's doing.)
Similar experience here in Georgia. It sounds like there is more to do on setup morning here, since we had to show up at 5am (and didn't have things really ready until 6:30 or so). There are so many seals to check and record; lots and lots and lots of paperwork.
In Georgia, the ballots are printed from a terminal that the voter uses and then scanned, leaving both an electronic count and a paper trail (the ballot itself is ejected from the bottom of the scanner into a sealed ballot box).
However, our scanners jammed 40 minutes into the day; after a couple hours, a technician managed to come to our precinct and opened the ballot box and revealed that a lackluster design in the ballot box caused the ballots coming out of the scanner to sometimes curl up and jam. Without any realistic solution, we just had to open the ballot box every time it jammed (supervised every time to ensure no monkey business) and push any stuck ballots out of the way of the scanner so that more could be scanned. Amusingly we had good success regularly giving the machine a good shove to dislodge any stuck ballots.
We also had problems printing receipts---in our case, we only need to print 3 from each scanner, but we ran out of scanner receipt paper. Since another precinct called us during the day looking for extra receipt paper... it wasn't available. But, we dodged a bullet, since there was just enough paper to print 2 of the 3 receipts. (1 gets posted on the door of the polling place; 2 go to the county. We wrote an apology on the receipt and only sent 1 to the county. I verified on the Secretary of State website that the votes tabulated for our precinct matched what our receipts printed. Cool to be able to double-check like that!)
I spent a while thinking about what a pollworker would need to do to illegally cast ballots. It would be a tall order indeed and would require cooperation and secrecy from everyone there, since the only way to cast a ballot is to scan it, and everyone can see the scanners at all times. I can't see it realistically happening in any precinct.
I would agree that the coronavirus could be a factor here. At the same time, I've been noticing issues since probably December or January (before the coronavirus started being a real problem), which makes it seem like maybe there are multiple issues.
Of course, I'm not actually internal to Microsoft or Github, so I have no idea and it's all opaque to me.
Yes, and so this is actually a thing that bugs me, because I use Github every day. Over the past several months, there have been numerous days in which I've had problems (`You can not comment at this time`, 500s, etc.) and no corresponding status report.
It seems like the historical uptime page paints a far rosier picture than I am actually experiencing.
Is it just me, or has Github's quality of service been continually degrading over the past several months? What is going on internally? Is this because of the Microsoft acquisition? Increased usage? An internal transition to Azure?
True, and I think that this makes the statistics somewhat misleading. The Atlanta metro area has a population of roughly 6 million and it's not very centralized.
The xeus-cling work is awesome and has made it possible to do data science prototyping in C++. There are lots of other C++ notebook examples in the examples repository: https://github.com/mlpack/examples/