Off topic: Always define your abbreviations. To find out what CNN stands for here, you either have to read a comment thread on HN, or go to the paper and read the introduction. The linked page doesn't even mention neural networks. And as some other commenter here has mentioned, CNN has other more well known meanings than Convolutional Neural Networks.
It was drilled into us in university (engineering) that you spell out abbreviations and acronyms on first use, no matter how well known you think it is.
Some cases I've seen lately seem to forgo this not out of ignorance but as a form of eletism/knowledge gate keeping.
> Some cases I've seen lately seem to forgo this not out of ignorance but as a form of elitism/knowledge gate keeping.
It's a natural tendency for ingroups. Nearly any video game forum, or anything else that's full of hobbyists will ultimately contain posts that are absolutely full of acronyms. And they're impenetrable. Bear in mind, I'm not defending this behavior, and certainly not disagreeing with you.
I'll defend it. Not the elitism, but using jargon/abbreviations/etc. When you're writing something for a larger audience, you should of course target that audience. But when you're on the "inside" writing for people who already have the background knowledge, it's unnecessary friction to stop and think "what terms would a newbie need defined in this?" It breaks the flow of writing/discourse and is probably mostly not needed, because someone coming in not knowing the terms in play can either go look them up, or just ask in their own post. (Granted, this also depends on that being easy; either a jargon dictionary being available, or the forum members being friendly to newbie questions.) I think it's also understandable to apply a small amount of gatekeeping, insofar as that continual beginner questions in the middle of an advanced discussion are just a distraction. The answer to that should be directing them to a more beginner-friendly subforum, but FWIW I do understand why people sometimes act poorly out of frustration.
Oh no, I understand your point, no misunderstanding here. It's one of the reasons I keep a technical blog, as an engineer, if I learn the hardest thing I've learned this $timeperiod, I want to share it, as clearly and understandably as I can. I fully support and encourage knowledge sharing, and it hurts just that little bit more when I see it being hoarded.
Seriously? You want to be able to join a community you might not be familiar with and understand the lingo/jargon off the bat? Of course people will abbreviate things when the word/phrase is sufficiently long, commonly used, and the abbreviation mutually understood (brb, tldr, OOP, etc.). There is no elitism involved, if you don't understand something either Google it or ask. No reason to act snobbish because people cater the the most common denominator in a community rather than the lowest.
Not exactly, what I'm arguing against is writing something technical, intended to educate non-experts in the field (the experts don't need your report/paper/thing) and then not providing them with the information they need to background research the things you refer to in abbreviations or acronyms.
And I'm not saying this is _my_ solution, this was literally taught to me in engineering first year.
May be this is specific to I.T or Computer Science? Where there are thousands of abbreviations and acronyms which itself is often the name people use. SQL, DRAM, CPU, HTTP, SRAM, FPGA, URL, TCP/IP, UDP, NAT, DHCP, GPL, etc.
I mean if you are discussing technicals of Neural network you expect your audience to at least know CPU, GPU, and FPGA. And if you are discussing software development I hope I dont have to spell out GPL.
So I dont think it is a form of eletism/knowledge gate keeping. In the age of internet you can search those "acronyms" meant without the full name, which isn't something could be easily done 15 to 20 years ago.
In other industry such as Mobile Wireless Networking, those acronyms are often clearly spell out because there are comparatively little of it. FDD, TDD, MIMO, NR or LTE are often spelt out in full when they first use.
> And if you are discussing software development I hope I dont have to spell out GPL.
I'm my university first-year CS class, a third of the students had never heard of GitHub. Now, that's easy to look up, and GPL seems to be a lucky acronym as well, but CNN certainly isn't. Expanding it the first time or adding a footnote costs you nothing, but people not right in your field or still learning tremendously. Someone who got their Master's in CS 10 years ago likely wouldn't have heard of CNNs at all, and neither would most new CS students.
A scientific publication in such a broad field with such a widely-applicable topic and one of the most clashing acronyms right in the title should most certainly at least expand their key terms.
I agree with all of that, however, I still stand by; if you're writing a technical document/paper you should spell out all of them, it's just how I was taught.
It doesn't have to be a hard rule, but major topics of a subject should be spelled out, at least, then you're giving people something to work with in their web search.
The same could be said for my biology education. But it never seems to stop those biologists publishing papers from invocing obscure acroynms and phrases without definition.
Genuinely thought this was some reference to something on the topic of 'fake news' Abbreviations are great if you're using the term multiple time. Not as an intro.
I also thought it was a reference to a manner of distinguishing genuine Cable News Network (CNN) screenshots from doctored ones divulged by “fake news” outlets.
This is a paper that was published in CVPR (Conference on Computer Vision and Pattern Recognition). In that context it is unambiguous that CNN means Convolutional Neural Networks.
Where would you draw the line though? Would you want the same for e.g. HTML? HTTP? HN? YC?
I mean personally I'm all in favor of more usage - or even automatic insertion - of the `<abbr>` tag. Can probably be done with a browser addon as well.
"CNN generated Image" sounds like "Images generated by the Cable News Network, CNN" as if the corporation has some software/policy for editing and prepping images in a way they can be detected. It's not so absurd, photojournalism can be quite specific in rules.
The ability to classify photos by news outlet based on identifying their photojournalism rules through computer algorithms sounds like a remarkably clever idea.
I wonder if part of an issue is the generation gap? For older readers, I imagine that they're much more familiar with CNN referring to the Cable News Network. Whereas for younger readers heavily involved in tech, me included, we aren't as heavily tied to the former abbreviation, so CNN referring to neural networks comes more readily to mind.
> Where would you draw the line though? Would you want the same for e.g. HTML?
The day someone uses “HTML” to mean “hyper-threaded machine learning” or whatever, yes definitely.
CNN was unambiguously used for the TV channel for decades now, of course some people are confused when one uses it to mean something else without warning.
It’s all about audience and confusion. My feel of the HN readership is that it’s a vey broad base of mostly technical backgrounds; international but US heavy. That puts the ones you list as perfectly reasonable, and CNN referring to the neural networks is usually ok.
I this case, however, there’s a conflict with the news network which could also plausibly be the subject of the headline. They have interenational recognizability, and have been using the acronym almost exclusively for years; it is effectively their name.
Someone who scanned the front page and didn’t delve into these comments might infere that the American news network CNN artificially generate images for their news stories. That’s how I picked this up.
Not really, I just thought that CNN (the news network) uses generated images in their articles. The topic about recognizing them, or even generating them, would make sense in CVPR.
If that were their justification, they wouldn't need to define the acronym in the paper. However, in the introduction section of the actual paper they do define CNN. But they use the acronym 9 times before defining it, which is what's kinda weird.
And the website isn't published in the CVPR, it's published on the internet.
I found CNN a bit confusing, even though I did guess it meant Convolutional Neural Net.
Perhaps my pre-caffeine morning brain is overly pedantic but Generative Nets use deconvolutions to generate images from latent codes, so using CNN rather than GAN (Generative Adversarial Network) is a bit confusing in this context.
CNNs are used by VAEs (Variational AutoEncoders, also generative) use convolutions to produce the latent codes and the discriminator (adversarial) part of GAN training uses convolutions.
I think Generative Networks ( or GNNs ;-) ) would perhaps have been clearer.
GANs use transposed convolutions to generate images. I haven’t seen anyone use a true deconvolution operation in deep learning. Not even sure it’s possible to invert the result of a convolutional layer, because it’s lossy.
"Transposed convolution" was called "deconvolution" for a short period of time. The authors apparently weren't aware that "deconvolution" has meant "the inverse problem of recovering a convolved signal" since at least the 70s.
The character limit is 80. Many abbreviations on the front-page are almost certainly caused by the low character limit making it difficult to express concepts that don't have a singular word for them.
I think it depends upon the audience and the work being written. Anything on the level of a news article definitely should spell it out, but a forum post about some game can get away with the common acronyms used by the community. It is part of knowing your audience.
Yes, with an abbreviation like CNN it is remarkably presumptuous to not define it in this article. I followed the headline specifically because it was in the title and I assumed it referred to the news network.
it’s a scientific paper from a computer vision conference, it would be absurd in that context to assume anyone reading it doesn’t know that it stands for convolutional neural network. they didn’t write this with Hacker News in mind.
Also, the convolution part is only a speedup thing. You can do very similar neural network operations without the convolution, except that everything will be much slower and you'd need a lot more memory.
It's not really "only a speedup thing" because the training process is different: as a CNN learns to (say) recognize dog-noses in the top left portion of the image, it's simultaneously learning to recognize dog-noses everywhere else too. A fully-connected MLP with the same layer structure doesn't have that property.
It's true that once you've trained your CNN you could make a non-convolutional NN that computes exactly the same things but less efficiently, but the point of an NN is not just what it can compute -- there are lots of systems that can, given enough parameters, approximate arbitrary functions well -- but how you train it.
Yes that's why I said "very similar". Without a convolution, you will have to replicate a lot of the network structure, and you'd have to train with shifted versions of your data. But fundamentally the convolution only gives an advantage in speed and memory, not in functionality.
Am I the only one who thinks that Apple was turning around independently of Taylor Swift? It seems to me that they had heard the criticism before and then used it as an answer to Swift as a better story.
I don't think Swift is so influential as everybody thinks. Apple turned so fast after her open letter, it makes me think they were already thinking about it. Not that Swifts letter was meaningless, but stuff usually takes a bit longer in the corporate world.
If the company wants to hire you, they will want to negotiate a deal that works for both parties. Crossing out and signing might be a bit harsh, but there should be no problem saying to the employer that you disagree with some sections.
Because IT folks are generally very well-paid to begin with; have strong individualistic tendencies; have a very, very wide range of skills that aren't easily equatable; and frequently job-hop for better offers rather than bedding down. And mostly, it's an industry with a very strong negotiate-your-own-paypacket ethos.
Interesting. I guess it depends on where your job falls within "IT". Then there is that valley skewing of salaries that happens on HN. My first "real" job was with a mega shipping corp supporting software for logistics and the autosorting equipment. I made 40k a year which was a lot of money to me in 2006. I worked 12 hour shifts rotating shifts (3 on 3 off which was nice). No holidays off. I wasn't allowed to leave my desk without a phone. Was once told I was required to answer the phone while on the toilet. Often the 12 hours became more than 20 hours because my manager demanded you own an issue if it came in during your shift. We switched to rotating 8 hour shifts but still ended up working way more than 40 hours per week and not sleeping. I had way more responsibility than I should have had at that pay scale. I also should have been paid hourly. I'm sure there are tons of people in that situation. To your point I decided to leave.
There is a side of the industry that most high paid developers don't see. Maybe they would just chock that up to lack of skills? I make double that now and average over 40 hours still. Plus travel, living out of hotels, and losing money on food while traveling. I still think I'm better off in Ohio at my current rate than in the valley at 50% more.
Overall IT is a good career even though it can be high stress. Most of the time that stress is unnecessary or even manufactured by managers/organizations. I really think the exempt employee is exploited in tech in general. There is no reason a help desk employee should be considered exempt. They should be paid by the hour with overtime. That and non-compete agreements are one reason I would even entertain the idea of a union. When a non-compete basically says you can't work anywhere then something is wrong.
Full disclosure: most of my family are union construction workers so that could sway my opinion. They have better compensation than I do, especially if you break it down by actually hours working. I'm in tech, in the fastest growing group, at one of the largest tech companies in the world.
If I remember correctly, the patient "died" after the game got too much press, and the server crashed. Instead of rerunning the game, they called it a success. Couldn't find it either, but I did not look too long.
For how long will HTTP 1.1/1.0 live alongside HTTP/2? It's all nice if every web page has TLS, but if I can just not upgrade to 2.0, it will not matter at all...
That's not completely accurate about HTTP/1.0. It's true that HTTP/1.1 requires "Host:" (a compliant server MUST reject any request from a 1.1 client that lacks that header). However, HTTP/1.0 clients had been sending "Host:" headers for years before the 1.1 standard came out.
It's still possible to use a 1.0 client today if you don't want to handle other client-side requirements of 1.1 like chunked transfer-encoding. Likewise, embedded devices can speak 1.0 only without any problem.
It's perfectly normal (and allowed) for servers to send back a version string of "HTTP/1.1" even if the client sent the request as "HTTP/1.0". As long as they don't do anything in their response that assumes that the client has 1.1 features, all is fine. This basically just means:
* Don't use chunked encoding in the response. (Technically a 1.0 client could specifically indicate support for that by sending a "TE: chunked" header, but since chunked encoding arrived at the same time as 1.1 I think most servers just assume that HTTP/1.0 clients never support it)
* Don't assume that the client supports keep-alive connections. However, prior to HTTP/1.0 clients often did indicate that they could do keep-alive by sending "Connection: keep-alive". The only real difference in 1.1 is that now the client must support it unless they specifically indicate that they don't by sending "Connection: close". In the absence of a "Connection:" header, a 1.1 client supports keep-alive and a 1.0 does not.
Most well-behaved servers will only send chunked-encoding if the client claimed to be HTTP/1.1. If the client is HTTP/1.0 it will fall back to doing "Connection: close"
The only big thing chunked-encoding gives you is the ability to do a keep-alive connection when the server doesn't know the Content-Length in advance. (Technically it also added "trailers" for sending headers after the reply body, but that's little-used)
> HTTP/1.0 is basically dead and has been for years
There are probably a lot more active HTTP/1.0 clients than you think. Just slap a `Host: foo.com` and `Connection: close` header onto the request and your HTTP/1.0 client can talk to just about any HTTP/1.1 server.
So basically, while HTTP/2.0 could force TLS, the world could still be like it is today, with some pages running web servers with HTTP/1.1 without TLS?
