electrograv

When a corporate or person's name/trademark is used explicitly and intentionally, freedom of speech does not automatically inherently protect the publication or media. In such a case, damages (if any) are resolved on a case-by-case basis, generally depending on the content and how indistinguishable it is from the real thing (and whether it's potentially damaging).

Saturday Night Live and The Onion are protected because both are widely known and clearly labeled as comedy/satire content. Neither is the case for this video, and as a result it's extremely likely they would fail at defending a lawsuit from the NRA if they did decide to prosecute.

P.S. My post assumed nothing about anyone's political views. The planned parenthood example was meant to provide balance via an analogical example from the other stereotypical political side.

“Paid for in part by the National Rifle Association of America with additional support from Smith & Wesson Holding Corporation." [1]

Conversely, I could imagine a parody video created by extreme conservatives mocking Planned Parenthood by happily and cheerfully promoting "baby murder" and "baby parts harvesting for the good of medical science", and quoting the text "This advertisement sponsored and paid for by Planned Parenthood."

Independent of your political views, claiming false official sponsorship of a parody is wrong. Slanderous impersonation of a person or organization is not inherently protected by freedom of speech.

[1] https://www.youtube.com/watch?v=_8punyPP-bs

> The academics’ latest work hurdles those restrictions allowing the use of sequences that are only weakly random

What does "weakly random" mean, if not a PRNG? Just low pure entropy per bit of sequence data? What's the threshold then between strong random and weak random -- wouldn't it be a continuum of entropy?

Minor nitpick: Also, how can a deterministic PRNG have less entropy (0) than that of its seed?

"Independent and no correlations" sounds like a crippling assumption if you want to use any two deterministic PSRNGs. How can you possibly guarantee they're completely un-correlated and independent without seeding them with collectively more bits of entropy than you can get out of the combined system?

I'm not sure what "independent" is even supposed to mean for a deterministic sequence, which by definition is recursively dependent.

I don't think anyone could ask for a better example of systemic entrenched sexist bias than this quote. "It's okay, don't worry about it; they just don't want to be promoted as much as us men."

This is not that much different from the old "women enjoy being in their husband's kitchen and tending to the house, so it's okay most women are there instead of working independently!" Evidence clearly exists that lot of women used to enjoy being in the kitchen, but that doesn't mean women are less suited to work outside the kitchen -- to make an extreme example.

> This is why we’ve created all these bullshit “arty” corporate jobs in marketing and related fields, why software engineering is discussed in terms of people really making things rather than in terms of sitting at a computer, staring bleary-eyed at your code

What...? I love my job, and it does involve making things while I sit at my desk -- incredibly cool things. Not only that, but my manager is awesome and discourages anything of the "up late bleary-eyed" variety.

Sure, there's a lot of crap jobs out there, but also a lot of amazing jobs where we do make incredible things that change the world. That's the "capitalist american dream" this article loves to call totalitarian propaganda (read the article if you don't believe he said something so absurd).

I have suddenly lost a great deal of respect and confidence for LLVM/Clang after reading this bug thread; I value software reliability above all else, and being able to write reliable software without the compiler negating that effort. It seems I can no longer be assured this is even a priority of my compiler any more, with Clang. All the more reason to switch to Rust I suppose.

That the Clang people are trying to deflect this bug as "fine, no fix necessary" is kind of disgusting software engineering behavior. Compilers spontaneously introducing undefined behavior in another layer (to the point of causing codegen warnings from perfectly correct C code, is as clearly cut a BUG as any, independent of current API implementations outside of the ISO spec.

If you want to make undefined API calls the norm, then make a new API where the behavior you want is defined. Invoking undefined behavior of a decoupled library that users can swap out is flat out indefensible.

That they are reluctant to fix this makes me shy away from ever using Clang/LLVM, which is sad because before I had always held them with very high respect.

I also doubt that it will have no manual control mode, so it shouldn't an issue regardless. Tesla is clearly going the route of being a strict super-set of the capabilities of other cars, until the market decides what features are obsolete many years down the road (e.g. steering wheels).

Both are clearly the future. So what's wrong with doing both?

You say "pivot" as though these are incompatible goals, when in fact they're perfectly complementary paths to a future ideal of ground transportation.

To me, your point is like asking "Is Google a search company, or an advertising company?" They're both, in a fully symbiotic sense. You cannot describe it as one of these accurately, without the other.

Even if this is why, there is never a valid excuse for blindly truncating 64-bit pointer to 32-bits. It's just like saying "I'm gonna just go ahead and truncate all bank account balances to 16-bit integers to save memory in my data structures." It may be the reason, but that reason is still incredibly stupid.

We can simulate the universe with astounding accuracy on many levels (though not all) with computers. Furthermore, when studying the universe deeply we see astoundingly computer-like traits[1]. But to express this by saying the universe is a computer is very misleading.

Similarly, artificial neural networks simulated by computers achieve huge strides in AI, accomplishing things many said would always be impossible (e.g. art[2]). Also, we see many computer-like traits in the brain. But to express this by saying the brain is a computer is very misleading.

[1] http://lmgtfy.com/?q=the+universe+is+a+computer+simulation

[2] http://googleresearch.blogspot.ca/2015/06/inceptionism-going...

You act as though the only datatype usable by computers is bool. That's ridiculous. Yes, computers are binary, but they can compute analog things just fine via floating or fixed point arithmetic to arbitrarily high precision, among many other things. To claim that the brain has a fundamental advantage over a Turing machine is to claim that there's some magical quantum (or otherwise) advantage in the brain's physical system that is un-simulate-able by a Turing machine.

You can't even argue that analog provides superior precision to digital representation of continuous values, because the analog part of the brain is represented with discrete units (accumulation of neurotransmitter molecules in various parts of the neuron)! In other words, our brain actually uses fixed point math (granted, incredibly complicated fixed point math :))

I'm confused... is the counter-argument AGAINST the brain being BEYOND a Turing machine (if I am to interpret your sentence literally)?

Or by this double negative do you actually mean the counter argument is AGAINST the brain being ONLY a Turing machine? (Because that's what the rest of your post sounds like.)

> and the output partly loops back to the input.

So? Turing machines have no issues with feedback loops; what would lead you to think they do?

This made me imagine some poor, bright but new-hire Google PR employee realizing this popular (and quite correct) view of Google ("CANCEL ALL THE THINGS" [1][2]) frantically trying to figure out how to actually communicate to upper management (without getting fired) the blunt truth:

This ongoing strategy of announcing projects and promptly canceling them after a few years is incredibly damaging to the company. Google's "ADHD-like low attention span" to projects is anything but confidence-inspiring. :(

1. http://memegenerator.net/X-All-The-Things

2. HN likes numbered references and I do too

I completely agree with the arguments showing how harmful OOP abuse is (especially branching inheritance trees!), just like abusing pointers, or structs, or error codes, or abusing <insert_language_feature_here> is harmful. But what does that have to do with OOP inherently?

Let's look at historical crashes, glitches, and hopelessly messy code and try to count their actual source. I bet you'll find sloppy programmers as the #1 root cause (maybe null-able pointers and/or weak typing as #2). OOP isn't bad because it's OOP, it's bad because hordes of bad programmers use it at big companies who don't care about code quality.

Beautiful functional code is beautiful.

Beautiful procedural code is beautiful.

Beautiful object oriented code is beautiful.

...

Spend more time writing beautiful code that draws its elegance from the rich set of paradigms and tools we have; spend less time participating in fad paradigm-ocide movements :)

> Open source drivers: poor performance, very stable, likely to not crash.

Actually, in my experience the open-source drivers for all my NVIDIA GPUs has been abysmally unstable. I couldn't even boot or install Ubuntu with the graphical interface, because nouveau kept freezing.

You could blame my uncommon but perfectly valid SLI GTX 580 setup for confusing the open source drivers, but the end result remains: the open-source drivers are inferior in every way except perhaps for the "open source" part (which is kind of meaningless if they don't work).

1. Build an array of a few (let's say 8 or so) cameras pointing outward from the center.

2. Use a stereo matching algorithm to extract a depth map from the perspective of each camera. Keeping track of the position and orientation of each camera in 3D space, these depths become a point cloud associated with each camera.

3. Determine the 3D location and orientation of each "eye" you want to render, then render all point clouds in 3D space to reconstruct a "reprojected" version of the scene from any desired viewpoint. Of course, the farther the eyes deviate from actual camera locations the more stretched/warped the image will appear, but that won't matter much as long as you keep the eye coordinates within the physical space occupied by the camera.

Honestly I'd be kind of disappointed if CMU doesn't actually try this. It's disappointing to think that perhaps all this buzz about "hackathons" (as the article mentions) is encouraging -- even at major research universities -- quickly slapping together components to make something kind of work, as opposed to fundamental algorithm development and proper engineering solutions.

How do we know these genes have an additive effect on IQ?

The causal relationship asserted by this quote is very strange. They claim: Because these effects are additive, IQ is normal distributed. What...? IQ is a test. It's normal distributed, like most tests are.

They're referring to the central limit theorem here, I assume[1], which not a bad insight. However it should be obvious that this normal distribution phenomenon arises out of such tests being scored additively from a number of relatively independent questions (whose answers can be thought of as independent random variables of unknown distribution).

In any case, I don't see how they can justify a causal link (in either direction) between some alleged additive effect of genes and the IQ test itself.

Personally, I'm mostly interested in this claim on additive intelligence genes, since I'm not an expert on this. It would be fascinating and exciting if there were additive "intelligence genes". However, as someone working on artificial neural network research as a hobby, I'm highly skeptical of this. It seems much more likely that human intelligence is a delicate balance of many interacting factors relating to the architecture and "algorithms" of the brain.

[1] http://en.wikipedia.org/wiki/Central_limit_theorem

If you've not used modern Direct3D, it's hard to concisely explain how much better it solves this problem than OpenGL. It's just a cleaner, more elegant, faster API (of course, I know this wasn't always the case, but we're talking about now).

Many of the "non-game" problems you mention really have nothing to do with the API and should be solved by third party libraries or the OS. Text rendering is not a GPU feature so don't expect a graphics API to treat it as such. The problems game developers find in a 3D API affect everyone, because at its core the 3D API is just our way of talking to the GPU.

The main complaints from "non-game" applications like this are either common to everyone (texture, render target limits), or application specific things that have absolutely nothing to do with the GPU (like text rendering) and have no place in a low level GPU API.

I know it would make your life easier if the API was more like a library with exactly your use cases already implemented, but that's simply not the role of a hardware API.

P.S. You probably shouldn't be using polygons for font rendering. Nobody does it this way in practice (except rare cases perhaps). But this is another discussion; feel free to message me privately and I'd be glad to provide more info on best practices.

Honestly, recently moving to Seattle has been refreshing to me in this regard. I find Seattle tech industry pay no less than SF, plus no state income tax, and for the same rent as SF you can practically live like a king/queen here.

I wonder how long the housing situation in SV can keep up until everything collapses under its own weight?

I don't mean to bash Parallax but to make a point that making an N-core processor is itself not impressive. Making an N-core architecture that performs like this is.

As an outsider (non-web software developer), I have to say debates like these hint strongly (IMO) of a cargo cult technology culture surrounding web development. Of course I get that we have to work with existing infrastructure; however I must admit it's surprising so many people seem blind to the idea that maybe the issue shouldn't exist in the first place.

I don't care how many abstraction layers, VMs, and scripting languages you do or don't use. I care that my UI doesn't lag or have choppy scroll animations, and that the battery doesn't drain 2x faster than expected.

Yeah, eventually these problems will likely disappear with more powerful hardware. But we're not the yet, and a good engineer realizes hardware limitations and designs software appropriately to achieve a great user experience.

"HTML5" has rightfully exploded in popularity. In fact, these days it's hard to justify NOT building your front on this stack. But much like any explosion of a popular technology, the developer community will tend to push the limits of what it can reasonably do. This exploration is a good thing, but it can be frustrating until people settle into best practices of what applications do and do not suit a given tech stack.