363 karma · joined June 22, 2011
I'll need to update this article. The only annoying part will be scribbling over the hexdump output again.
If you're asking why AMD doesn't make a compiler for CUDA source code that targets their own GPUs--that's basically what ROCm currently does. They're pushing their CUDA alternative, called "HIP", which is essentially just CUDA code with a find-and-replace of "cuda" with "hip". (And other similarly minor changes.) They have an open source "hipify" program that does this automatically (https://github.com/ROCm-Developer-Tools/HIP/tree/master/hipi...).
So, basically, AMD GPUs are already sort of CUDA compatible: just run your CUDA code through hipify, then compile it using the HIP compiler, and run it on a ROCm-supported system (which, for now is the most spotty of all of these steps IMO).
Java does have similar things, but, as far as I know, they're limited to the UI libraries and far more complicated (e.g. https://docs.oracle.com/javase/7/docs/api/java/awt/Image.htm...). Imagine if everyone who read or wrote image files in Java were guaranteed to conform to a dirt-simple "Image" interface with only three methods--with optimizations available but strictly optional.
For someone who's just tinkering or just wants to dump some cool bitmaps, the ability to write an "At(...)" function in Go and be looking at a PNG within a few seconds is just great fun to have in the standard library.
And,on top of all that, once you've written code satisfying the image interface, the standard library even includes functions for saving your image as one of several possible image formats. And, due to the fact that the interface itself is specified by the standard library, virtually all third-party image encoding or decoding libraries for Go use it, too. So, every image reader or writer I've seen for Go, even third-party ones, can be drop-in replacements for one another.
Anyway, it's not Go's standard use case, but as someone who loves fractals and fiddles with images all the time it's one of my favorite parts of the language.
The reason being that the accepted definition of time complexity in formal literature is standardized not based on the number of "things" in the input (numbers in a list, nodes in a graph, etc.), but on the length of the input string. This is a common pitfall when people reason about time complexity. Here's why this applies to abacus sort:
1. Abacus sort contains integers in its input string--and based on the conventions of formal time complexity, these can not be encoded in unary (if unary encodings were allowed, then several famous NP-Complete algorithms, e.g. bin packing, would have polynomial time solutions based on the length of their input)
2. The value of an integer is exponentially related to its length. For example, making a binary integer only one bit longer can double its value, making it two bits longer will quadruple its value, etc.
3. The input to a sorting algorithm like abacus sort is a list of numbers. Even if there are n numbers, the number of "beads" you need to simulate is exponentially proportional to the length of the longest single number.
4. Even if you think that the number of beads can be simulated with an infinite number of threads, or something, you'd still need to decode the (at least) binary input to a unary number of beads, which will take an exponentially-related amount of memory.
Of course, all this is not to say the algorithm isn't cool in practice, for numbers in ranges that reasonable people care about. It's similar to a weakly-NP-complete problem (https://en.wikipedia.org/wiki/Weak_NP-completeness) like integer bin packing, where the time complexity is dependent on the longest number and therefore technically exponential, but in practice solved for any reasonable ranges of values in polynomial time.
Edit: By the way, this is why the naive prime-number-checking algorithm (check divisibility of a value v by all values up to sqrt(v) is not an efficient algorithm even though many people incorrectly think it's O(sqrt(n))!
It technically takes exponential time relative to the length of bits in the number, so it's basically useless for guaranteeing primality of something like a 4096-bit number.
Say, for instance, that you're asked by a supervisor to collaborate with a Muslim living in a middle eastern country on writing a piece of software. For the sake of argument, say that this particular person believed that the laws recently enacted in Brunei were in line with the commands of Islam, and therefore just. (For the sake of argument only--obviously not everybody in those categories is like this at all--but clearly at least some must be or we wouldn't have situations like this recent one.) Would it be right to refuse to work with this person on writing say, some python code, when the topic of "sharia law" is never going to be a factor? Furthermore, by your argument, would you be willing to trust this person's judgement on software architecture when they have exhibited a, in your view, extreme lack of good judgement in another field?
Second, you can even take this argument to a higher level. You admit that the opposing party has a reason to believe what they believe, and I'd imagine that you'd even grant that they probably believe that their reasons for their particular position are good reasons. Leaving aside whether the positions themselves are good or not, how do you evaluate whether someone's reasons for holding a particular position are good? After all, a religious person may believe that one day an omniscient being will call them to answer for why they failed to keep holy commands in their life. To the holder of such a view, that's a pretty good reason to do some twisted stuff. If anything, (if their religion is right) such a reason for them holding their particular position (fear of eternal condemnation) may even be better to them than your reasons for your position are to you!
The fact that they don't agree with the others on LGBT rights should only be an issue if they insist on trying to espouse their unrelated viewpoints using the panel, in which case by all means kick them off.
(Obviously the people who complained about a prominent right-wing figure would just argue something hypocritical like "only the right kind of diversity of opinion", but that's beside the point; the panel was a dumb idea to begin with, coming from a group with so much of a stake in trying to advance AI for the sake of advertising)
However, I think this change was mostly just an optimization for common cases with few arguments or no closures (e.g. "defer f.Close()").
You can ignore error codes in go by assigning them to the special variable "_", but, outside of very short toy examples, it is a huge warning sign for terrible code. It's certainly not common to ignore errors in Go.
The other case where this is useful is if you're wanting to write userspace assembly without calling a C library. This may be especially useful when you're writing a compiler, or if you're trying to write small shellcodes for some reason.
Whether it's exaggerated "by the right-wing press" or not (I find it concerning despite being left-leaning and not the press), I don't like the notion of any politically-aligned parties having an outsized role in deciding what's "appropriate".
Like you, I also find the Alex Jones and his ilk to be disturbing and harmful, and consider it a bad sign that people like you and me need to qualify any statement against censorship by explicitly saying we aren't part of the American far right.
For example, here are two images I created using my old tool to convert an image to the C64 color palette. Unlike the website, my tool isn't currently capable of doing the double-wide horizontal pixels, but it still illustrates the effect I think:
Without dithering: http://imgur.com/nQL0y6i With dithering: http://imgur.com/jfwUgnC
If you're interested, Wikipedia has a great example (with code) of the Floyd-Steinberg dithering algorithm, for example: https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dither..., which I imagine wouldn't be too hard to integrate into your site.
This isn't a particularly important question; I'm just a grad student in real-time research so I like learning about what gets used in practice. Thanks!
According to the comments on the bug report, this behavior is inspired by C++'s <atomic> library, which guarantees cross-thread visibility.
However, this is not the case for atomic operations (which are generally specifically intended for communication via shared variables). This optimization of removing the writing thread entirely isn't allowed if atomic operations are used, because those actually do come with a guarantee that other threads will get to see the update in finite time.
Go was incorrectly "optimizing" the atomic operations out entirely. It's a fairly subtle bug, actually, but still likely a big deal for the few programs communicating via shared variables.
While pol may be the most active board on 4chan for the time being, it hasn't always been and may not always continue to be (sadly, painting the entire site as a club for nihilistic Trump supporters makes it less likely to attract different users). Much of the rest of the website offers a great discussion format for focused topics, and I wish I could admit to enjoying the other sections of 4chan without needing to qualify my statements by explaining that the entire site isn't dedicated to racism and porn.