|
Always using the latest high-tech gadget is one way to boost your image at work, new research suggests.
Indeed, business professionals who want to be perceived as leaders should be investing in the latest technology breakthroughs, according to a study published recently in The Journal of Product Innovation Management. "No. I'm not playing games... I'm advancing my career."
|
|
|
|
|
This article highlights how a discovered quirk is just a few steps away from becoming a feature. "It's a feature." Here we go again.
|
|
|
|
|
Chaochao Lu and Xiaoou Tang at the Chinese University of Hong Kong say they’ve developed a face recognition algorithm called GaussianFace that outperforms humans for the first time. Yea, but can it write a symphony?
|
|
|
|
|
I can write symphony, but still I don't like to do so. Am I artificial intelligence or not?
|
|
|
|
|
The article contained: But when the algorithm is faced with images that are entirely different from the training set, it often fails. “When the [image] distribution changes, these methods may suffer a large performance drop,” say Chaochao and Xiaoou.
The problem where the computer defeats humans is a narrowly-defined situation where the system is trained with a specific set of faces.
Typically humans can recognize thousands of faces in various contexts much of the time.
It is still an impressive accomplishment though.
|
|
|
|
|
Finding look a likes might be much easier now
|
|
|
|
|
Quote: But when the algorithm is faced with images that are entirely different from the training set, it often fails. [] say Chaochao and Xiaoou.
So it's all about speed of processing! Get a extremely powerful computer and run all the known face-recognition algorithms on the pictures - you probably got a 100% success in less time a human need to look at the picture...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
When Scott Erven was given free rein to roam through all of the medical equipment used at a large chain of Midwest health care facilities, he knew he would find security problems–but he wasn’t prepared for just how bad it would be. Please don't tell my big brother about this. He thinks he's hilarious.
|
|
|
|
|
That is f^cking ridiculous.... Death by Bluetoof? That would suck!
"... having only that moment finished a vigorous game of Wiff-Waff and eaten a tartiflet." - Henry Minute
"...who gives a tinker's cuss?" - Dalek Dave
"Let's face it, after Monday and Tuesday, even the calendar says WTF!" - gavindon
It's plain that they do not yet know what true fear really is. - JSOP 2011
|
|
|
|
|
Back in 2013 The Register reported that Google sets its bets on SQL again. On the first sight this might look like a surprising move because it was of all things Google’s publications about MapReduce and BigTable that gave the NoSQL movement a big boost in the first place. On a second sight it turns out that there is a trend to use SQL or similar languages to access data from NoSQL systems—and that’s not even a new trend. However, it raises a question: What remains of NoSQL if we add SQL again? Big things have small beginnings.
|
|
|
|
|
The sooner NoSQL dies, the better, IMO. The idea of storing data in a non-relational manner is a step back to the stone ages. The relationships are information, and removing them and creating willy-nilly JSON-formatted hashes results in a significant loss of useful information. Which is ironic, because this stuff is supposed to help with information management! OK, there might be some narrow application for this stuff, but when I hear some newbie (or seasoned!) developer say "ooh, let's use a NoSQL database like Mongo for this application", I cringe (which is probably better than doing what I really want to do, which is hit them over the head with a 2x4.)
Marc
|
|
|
|
|
Not all data is relational. SQL isn't always the best choice for hierarchical data or graphs.
It's interesting, though, when I read the NoSQL advocates using the argument that the only reason we have normalised tables was that it was necessary in order to conserve disk space.
They are tools. They each solve problems. Please just use the right tool.
cheers
Chris Maunder
|
|
|
|
|
Exactly - but a blended tool (if available) would be able to solve this for all of us. i.e SQL + extensibility of NoSQL + file system.
This can, in fact, be created in SQL Server - you use an XML column (or NTEXT full of JSON) for the variable component of your entities, standard columns for what you need to be pure relational and files for the totally unstructured stuff.
|
|
|
|
|
Absolutely true. But SQL can act like a dumb storage (XML, JSON) as well. While NoSQL have big troubles doing anything else than operator[].
|
|
|
|
|
Chris Maunder wrote: It's interesting, though, when I read the NoSQL advocates using the argument that the only reason we have normalised tables was that it was necessary in
order to conserve disk space. Wrong argument. The arguments are "consistency" and "correctness" (of the data). We've had non-relational data for ages; a game-map will probably not be encoded as a RDB, nor does one need a RDB for a logger.
Chris Maunder wrote: They are tools. They each solve problems. Please just use the right tool. That's the point; what 'problem' does NoSQL solve?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
NoSQL is "not only SQL" (not, "no SQL").
It solves the problem of performance and it solves the problem of accessing data in a non relational manner (eg hierarchical, graph) to name two incredibly important points.
I think in relational databases but we utilise MongoDB (document based), Redis (key/value) and Lucene (document index). They were each chosen specifically because they allow us to solve specific issues that SQL Server / MariaDB can't solve elegantly.
They are all just tools. They need to be understood, not worshiped.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Not all data is relational. SQL isn't always the best choice for hierarchical data or graphs.
Actually, hierarchical and graphs are a subset of "relational". Ironically, while SQL represents those relationships very well, it's extracting the information while preserving the hierarchical or "graph"-ical "semanticism" (geez, I'm inventing words here) that SQL is very poor at.
Chris Maunder wrote: when I read the NoSQL advocates using the argument that the only reason we have normalised tables was that it was necessary in order to conserve disk space.
- that's because they don't need to store all those foreign keys!
Reading this article[^] on MongoDB and tree structures reminds me quite a bit of kinds of queries one can do with XML. The interesting thing about these kinds of queries is that they implicitly understand concepts like "ancestors" and provide "path" queries, again something that SQL really doesn't do.
So yes, as you say, the right tool.
Marc
|
|
|
|
|
Marc Clifton wrote: Actually, hierarchical and graphs are a subset of "relational". Ironically, while SQL represents those relationships very well, it's extracting the information while preserving the hierarchical or "graph"-ical "semanticism" (geez, I'm inventing words here) that SQL is very poor at.
Yes. Well put.
cheers
Chris Maunder
|
|
|
|
|
I don't know anything about NoSQL but, as in all these debates, surely it's a matter of using the right (or appropriate) tool for the right job rather than touting one technology as the solution to all problems?
Kevin
|
|
|
|
|
It cannot be argued that the SQL language was a big success (this is separate from the relational model), and that NoSQL is not really about the SQL language but not obsessing about storage costs and relational thinking, so adding a generally accepted language front end to the backend engine is a good idea and makes transitioning to and working with the new engines easier.
In any case I would much rather have a toolbox of multiple technologies to depend on than having only a hammer... unless I have a sonic screwdriver...
|
|
|
|
|
This article describes 10 of the most common programming mistakes made, or pitfalls to be avoided, by C# programmers. *points at list* Look at what you did. Bad, bad programmer!
|
|
|
|
|
Number "1" mistake that authors make when writing a technical article:
1. Make an assertion without backing it up with data, or at the very least, anecdotal evidence.
I have no data to back that up though.
|
|
|
|
|
The internet is buzzing right now with the latest, greatest (and potentially fake) Worst Thing Ever. Meet Code Babes, the stripping amalgam of everything that's wrong with tech culture today.
Code Babe's premise, purportedly, is to make learning to code fun by giving you an extra special sexytime motivation. Every time you pass a quiz, your lady instructor will remove one piece of clothing—going as far is it takes "to motivate you.
So this is what it's come to...
|
|
|
|
|
And yet people wonder why there are not more women in tech jobs
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
How to ask a question
|
|
|
|
|
Apple sold more iPads in 2013 than it sold Macs in the previous two decades -- combined. It's sold 210 million iPads since the tablet debuted in 2010 -- proving it's no fad. But iPad sales have flattened compared to the previous quarter, and analysts are asking whether we're approaching "peak iPad" -- when the market has saturated itself such that anyone who wants or needs an iPad now has one, and future sales will come from people replacing iPads they already own.
iFlattened Sales, you say?
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
How to ask a question
|
|
|
|