378 karma · joined September 27, 2015
A much better way to solve it, which is already being done (to some degree of success) is to calibrate the phrase detection to the owner's unique voice.
Is that really true? Demis stated that the distributed version of AlphaGo beats a single machine version only 75% of the time. That's still stronger than virtually all human players, and probably would still beat Lee Sedol at least once.
I think the point is that if you counted these kinds of incidents in human driver statistics, your miles per accident numbers would come way, way down.
I've had to un-learn my search query habits from the past. I used to attempt to express queries in ways that I thought would help the search engine (limit it to keywords, suppress keywords that are likely to produce false positives, etc.). Now, it seems better to put in sentence fragments, and the old way of a few specific thought out keywords is actually worse at producing the result I want.
The difference is small to the average HN user (most of us are just as capable of expressing queries both ways, and we'll find what we're looking for) but the latter kind of query is far more accessible to the average person.
> [+] Cholesky Decomposition: Trivial to implement
How is it that you can judge Cholesky decomposition to be trivial to implement, while being unfamiliar with QR decomposition?
Cholesky decomposition is not trivial to implement well.
> Your post comes across to me as being rather cynical - but why not be supportive of the good work that's being done?
I had a similar experience to what's happening here myself. I worked on a project that had some very specific requirements for a high performance simulation (described by a differential equation). I worked on a very specialized piece of code for a long time to optimize this differential equation solver, eventually writing a JIT compiler to generate specialized code for each simulation.
I had a D advocate come along and rather vigorously argue that D can solve this problem, without really understanding it, and missing some key requirements.
This sort of comes off the same way, "a numpy replacement". numpy is big and does a lot of stuff. Like Cholesky decomposition, many of these things have trivial implementations, and then they have good implementations. The trivial implementations will take a few hours to write. The good implementations will take a few months, or even longer. Sometimes "not good" means slow, sometimes "not good" means numerical stability issues, etc. If you don't have the right background, these things may not even be obvious.
This is a bit of a pattern with D folks. Several times (this, my previous experience, and others), I've gotten the impression that a D fan comes along, invests a bit of time (a few weeks, months) in a particular domain, and starts making comparisons with other tools that they only scratch the surface of. It can rub people the wrong way.
edit: The symbolic expression reference in this post is another example. Computer algebra is an incredibly difficult thing to implement. I don't know of anything that is harder to implement well than a computer algebra system. Yet, you link a single file under 1000 lines as partially checking the box in your list for symbolic expression manipulation. D might be a highly productive, but it's not that productive.
This seems like the easiest way to tackle this problem (aside from chip cards). I doubt it would take much pressure on these guys to get the market for this to dry up, or at least considerably reduce the profitability. I'd guess the gas station owners have a lot more to lose than the thieves actually stealing gas.
My understanding of this is that malicious code was deliberately added to Juniper's software, not that it exploited some existing code that Juniper thought was safe. This could happen regardless of what kind of encryption is in use in the surrounding code/infrastructure.
If my understanding is correct, why is Dual_EC relevant?
edit: And a follow on question: If this back door only works by assuming Dual EC is backdoored, is that not incontrovertible proof that the NSA is behind the entire thing, which there is at least some doubt that they are? That, or someone else has found the hypothesized private key in Dual EC. Either scenario seems like far more significant news than this story already is.
The problem with both situations (VC/entrepreneurs and employers/employees) is that there's a cost associated with evaluating a candidate.
I don't think anyone doubts that good opportunities (and candidates) exist at all at lower tier schools, but it seems very likely that there are fewer of them.
If your resources are already constrained by something other than the number of opportunities you can afford to fund/hire (e.g. time to evaluate/interview), then it doesn't make sense to expand your search if it means lowering your success rate.
- Special instructions to help with common DSP tasks (e.g. circular buffers, nice fixed point/rounding instructions, etc.).
- Much lower power/better performance per watt.
- Directly connected to audio in/out, to minimize latency.
- Real time OS, or no OS at all.
However, the main takeaway from my comment should probably be that simulating audio circuits by modeling them at such a low level (a circuit) is probably not the right thing to do. There are higher level models of the behavior of these kinds of effects/amps that are easier to implement and faster to evaluate. Lots of CPU cycles are wasted simulating inaudible behavior in the circuit. It's a really fun toy/project, but probably not something you would want to use to design a widely deployed simulation with.
A lot of people have problems with audio IO (the ecosystem of audio devices, drivers, OSes, etc. unfortunately is a minefield) but I haven't heard many complaints about the UI.
A small disclaimer on the following, I only attempted simulation of audio amp/effect pedal circuits, which are generally small. There might be ways to effectively parallelize (much) larger circuits. Another disclaimer, I worked on this 1+ years ago, so some of it is fuzzy.
The basic issue is that circuit simulation is fundamentally a serial operation. The circuit state at time step n is a function of the circuit state at time step n-1.
The relationship between timesteps is basically a non-linear system of equations, where the number of variables is the number of nodes in the circuit. For a typical guitar effect pedal, this might be ~50 variables.
There's basically no opportunity for parallelism here. You can't parallelize across the non-linear systems, because you don't know what to solve at timestep n until you've solved for timestep n-1. Within each step, a 50 variable system of equations is probably too small to parallelize, even on the CPU. Note that the technique used here is generally Newton's method, which also is difficult to parallelize for the same reason.
The bottom line is that as far as I know, circuit simulation (at least for audio) is entirely limited by single thread performance.
As a side note, the fun part of LiveSPICE is that even a 50 variable non-linear system is far too big to solve at real time sample rates (48 kHz, plus oversampling to avoid aliasing artifacts). The trick is to observe that only a fraction of these variables are non-linear, most of them are related to the other variables linearly. LiveSPICE solves for these linear relationships once during initialization of the simulation, and eliminates them prior to solving the non-linear system. This turns a typical ~50 variable system into a ~5 variable non-linear system (plus a 45 linear relationships). This is a massive reduction in computation required (Newton's method involves repeatedly solving a linear system, which is O(n^3) for simple methods).
At the same time, understanding distribution is so much more powerful because it generalizes to many other uses and later concepts.
I think FOIL sticks around primarily because it is what people are taught. Even when people actually do understand distribution, they may not realize that FOIL is just a special case of distributing.