Skip to main content

Blog

Learn About Our Meetup

5000+ Members

MEETUPS

LEARN, CONNECT, SHARE

Join our meetup, learn, connect, share, and get to know your Toronto AI community. 

JOB POSTINGS

INDEED POSTINGS

Browse through the latest deep learning, ai, machine learning postings from Indeed for the GTA.

CONTACT

CONNECT WITH US

Are you looking to sponsor space, be a speaker, or volunteer, feel free to give us a shout.

Author: torontoai

[P] Helping a total newbie learn to run SC-FEGAN

I’m sorry if this is the wrong place to ask but I’ve Googled my issues and I’m at a loss on helpful resources.

I’m not familiar with neural networks but would like to try SC-FEGAN out. I have the files, the model, and Python downloaded and I’m stuck on getting this working:

mv /${HOME}/SC-FEGAN.ckpt.* /${HOME}/ckpt/ python3 demo.py 

Should I be using command prompt or Python to launch the GUI? How do I use the other dependencies listed (tensorflow, numpy, Python3, PyQt5, opencv-python, pyyaml)?

ELI5, any advice would be appreciated, thank you for your time 🙂

submitted by /u/sytrix
[link] [comments]

[N] IBM halting sales of Watson AI tool for drug discovery amid sluggish growth

Citing lackluster financial performance, IBM is halting development and sales of a product that uses its Watson AI software to help pharmaceutical companies discover new drugs, news outlet Stat reported on Thursday, citing a person familiar with the company’s internal decision-making. From the report:

The decision to shut down sales of Watson for Drug Discovery marks the highest-profile retreat in the company’s effort to apply artificial intelligence to various areas of health care. Last year, the company scaled back on the hospital side of its business, and it’s struggled to develop a reliable tool to assist doctors in treating cancer patients.

In a statement, an IBM spokesperson said, “We are focusing our resources within Watson Health to double down on the adjacent field of clinical development where we see an even greater market need for our data and AI capabilities.”

submitted by /u/inarrears
[link] [comments]

How to Train Your Robot: Robot Learning Guru Shares Advice for College Students

Whether you’re a robot or a college student, it helps to start with the fundamentals, says a leading robotics researcher.

While robots can do amazing things, compare even the most advanced robots to a three-year-old and they can come up short.

Pieter Abbeel, a professor at the University of California, Berkeley, and cofounder of Covariant.ai, an AI company, has pioneered the idea that deep learning could be the key to bridging that gap: creating robots that can learn how to move through the world more fluidly and naturally.

Or as Abbeel refers to it, building “brains for robots.”

Teaching robots new skills is similar to taking classes in college, Abbeel explained on the latest episode of the AI Podcast.

While college courses may not immediately qualify a student for a job, the classes are still important in helping students develop fundamental skills they can apply in all kinds of situations.

Abbeel uses the same approach in his robotics research. At last month’s GPU Technology Conference, he showed a robot learning to navigate a new building it’s never been in before. His talk will be available here starting May 1.

The robot was able to do that because it was applying principles it had learned by navigating other buildings. “What were [the robot’s] courses in its college curriculum were the many other buildings that it was also learning to navigate,” he said. “So it learned a generic skill of navigating new buildings.”

Similarly, college students should look for classes that can teach them skills they can apply broadly.

Getting Physical

For younger students interested in getting a head start in AI and deep learning, Abbeel encourages them to look into physics.

“When I think about the foundations, the things you would learn early on, that will help a lot — they’re essentially mathematics and computer science and physics,” said Abbeel.

“And the reason I say ‘physics,’ which might be slightly more unexpected in the lineup, is that physics is all about looking at the world and building abstractions of how the world works,” he said.

Abbeel also recommends getting involved in research.

“It’s a lot about taking initiative, trying things,” Abbeel said. “The research cycle is a lot about just trying things people haven’t tried before and trying them quickly and understanding how to simplify things.”

How to Tune into the AI Podcast

Our AI Podcast is available through iTunes, Castbox, DoggCatcher, Google Play Music, Overcast, PlayerFM, Podbay, PodBean, Pocket Casts, PodCruncher, PodKicker, Stitcher, Soundcloud and TuneIn.

If your favorite isn’t listed here, email us at aipodcast [at] nvidia [dot] com.

The post How to Train Your Robot: Robot Learning Guru Shares Advice for College Students appeared first on The Official NVIDIA Blog.

[R] A Bayesian Perspective on the Deep Image Prior – CVPR 2019

Abstract:

The deep image prior was recently introduced as a prior for natural images. It represents images as the output of a convolutional network with random inputs. For “inference”, gradient descent is performed to adjust network parameters to make the output match observations. This approach yields good performance on a range of image reconstruction tasks. We show that the deep image prior is asymptotically equivalent to a stationary Gaussian process prior in the limit as the number of channels in each layer of the network goes to infinity, and derive the corresponding kernel. This informs a Bayesian approach to inference. We show that by conducting posterior inference using stochastic gradient Langevin we avoid the need for early stopping, which is a drawback of the current approach, and improve results for denoising and impainting tasks. We illustrate these intuitions on a number of 1D and 2D signal reconstruction tasks.

Authors: Zezhou Cheng, Matheus Gadelha, Subhransu Maji, Daniel Sheldon

Project page: https://people.cs.umass.edu/~zezhoucheng/gp-dip/

submitted by /u/AruniRC
[link] [comments]

[R] Objects as Points

[R] Objects as Points

https://i.redd.it/kc4e1b3ly2t21.png

Abstract:

Detection identifies objects as axis-aligned boxes in an image. Most successful object detectors enumerate a nearly exhaustive list of potential object locations and classify each. This is wasteful, inefficient, and requires additional post-processing. In this paper, we take a different approach. We model an object as a single point — the center point of its bounding box. Our detector uses keypoint estimation to find center points and regresses to all other object properties, such as size, 3D location, orientation, and even pose. Our center point based approach, CenterNet, is end-to-end differentiable, simpler, faster, and more accurate than corresponding bounding box based detectors. CenterNet achieves the best speed-accuracy trade-off on the MS COCO dataset, with 28.1% AP at 142 FPS, 37.4% AP at 52 FPS, and 45.1% AP with multi-scale testing at 1.4 FPS. We use the same approach to estimate 3D bounding box in the KITTI benchmark and human pose on the COCO keypoint dataset. Our method performs competitively with sophisticated multi-stage methods and runs in real-time.

Github: https://github.com/xingyizhou/CenterNet

submitted by /u/AruniRC
[link] [comments]

[Discussion] When ML and Data Science are the death of a good company: A cautionary tale.

(This is a true story, happening to the company I currently work for. Names, domains, algorithms, and roles have been shuffled around to protect my anonymity)

Company A has been around for several decades. It is not the biggest name in its domain, but it is a well respected one. Risk analysis and portfolio optimization have been a core of Company A’s business since the 90s. They have a large team of 30 or so analysts who perform those tasks on a daily basis. These analysts use ERP solutions implemented for them by one the big ERP companies (SAP, Teradata, JD Edwards,…) or one of the Big 4 (Deloitte, Accenture, PWC, Capgemini) in collaboration with their own in house engineering team. The tools used are embarrassingly old school: Classic RDBMS running on on-prem servers or maybe even on mainframes, code written in COBOL, Fortran, weird proprietary stuff like ABAP or SPSS…..you get the picture. But the models and analytic functions were pretty sophisticated, and surprisingly cutting edge compared to the published academic literature. Most of all, they fit well with the company’s enterprise ecosystem, and were honed based on years of deep domain knowledge.

They have a tech team of several engineers (poached from the aforementioned software and consulting companies) and product managers (who came from the experienced pools of analysts and managers who use the software, or poached from business rivals) maintaining and running this software. Their technology might be old school, but collectively, they know the domain and the company’s overall architecture very, very well. They’ve guided the company through several large scale upgrades and migrations and they have a track record of delivering on time, without too much overhead. The few times they’ve stumbled, they knew how to pick themselves up very quickly. In fact within their industry niche, they have a reputation for their expertise, and have very good relations with the various vendors they’ve had to deal with. They were the launching pad of several successful ERP consulting careers.

Interestingly, despite dealing on a daily basis with statistical modeling and optimization algorithms, none of the analysts, engineers, or product managers involved describe themselves as data scientists or machine learning experts. It is mostly a cultural thing: Their expertise predates the Data Science/ML hype that started circa 2010, and they got most of their chops using proprietary enterprise tools instead of the open source tools popular nowadays. A few of them have formal statistical training, but most of them came from engineering or domain backgrounds and learned stats on the fly while doing their job. Call this team “Team X”.

Sometime around the mid 2010s, Company A started having some serious anxiety issues: Although still doing very well for a company its size, overall economic and demographic trends were shrinking its customer base, and couple of so called disruptors came up with a new app and business model that started seriously eating into their revenue. A suitable reaction to appease shareholders and Wall Street was necessary. The company already had a decent website and pretty snazzy app, what more could be done? Leadership decided that it was high time that AI and ML become a core part of the company’s business. An ambitious Manager, with no science or engineering background, but who had very briefly toyed with a recommender system a couple of years back, was chosen to build a data science team, call it team “Y” (he had a bachelor’s in history from the local state college and worked for several years in the company’s marketing org). Team “Y” consists mostly of internal hires who decided they wanted to be data scientists and completed a Coursera certification or a Galvanize boot camp, before being brought on to the team, along with a few of fresh Ph.D or M.Sc holders who didn’t like academia and wanted to try their hand at an industry role. All of them were very bright people, they could write great Medium blog posts and give inspiring TED talks, but collectively they had very little real world industry experience.

As is the fashion nowadays, this group was made part of a data science org that reported directly to the CEO and Board, bypassing the CIO and any tech or business VPs, since Company A wanted to claim the monikers “data driven” and “AI powered” in their upcoming shareholder meetings. In 3 or 4 years of existence, team Y produced a few Python and R scripts. Their architectural experience consisted almost entirely in connecting Flask to S3 buckets or Redshift tables, with a couple of the more resourceful ones learning how to plug their models into Tableau or how to spin up a Kuberneties pod. But they needn’t worry: The aforementioned manager, who was now a director (and was also doing an online Masters to make up for his qualifications gap and bolster his chances of becoming VP soon – at least he now understands what L1 regularization is), was a master at playing corporate politics and self-promotion. No matter how few actionable insights team Y produced or how little code they deployed to production, he always had their back and made sure they had ample funding. In fact he now had grandiose plans for setting up an all-purpose machine learning platform that can be used to solve all of the company’s data problems.

A couple of sharp minded members of team Y, upon googling their industry name along with the word “data science”, realized that risk analysis was a prime candidate for being solved with Bayesian models, and there was already a nifty R package for doing just that, whose tutorial they went through on R-Bloggers.com. One of them had even submitted a Bayesian classifier Kernel for a competition on Kaggle (he was 203rd on the leaderboard), and was eager to put his new-found expertise to use on a real world problem. They pitched the idea to their director, who saw a perfect use case for his upcoming ML platform. They started work on it immediately, without bothering to check whether anybody at Company A was already doing risk analysis. Since their org was independent, they didn’t really need to check with anybody else before they got funding for their initiative. Although it was basically a Naive Bayes classifier, the term ML was added to the project tile, to impress the board.

As they progressed with their work however, tensions started to build. They had asked the data warehousing and CA analytics teams to build pipelines for them, and word eventually got out to team X about their project. Team X was initially thrilled: They offered to collaborate whole heartedly, and would have loved to add an ML based feather to their already impressive cap. The product owners and analysts were totally onboard as well: They saw a chance to get in on the whole Data Science hype that they kept hearing about. But through some weird mix of arrogance and insecurity, team Y refused to collaborate with them or share any of their long term goals with them, even as they went to other parts of the company giving brown bag presentations and tutorials on the new model they created.

Team X got resentful: from what they saw of team Y’s model, their approach was hopelessly naive and had little chances of scaling or being sustainable in production, and they knew exactly how to help with that. Deploying the model to production would have taken them a few days, given how comfortable they were with DevOps and continuous delivery (team Y had taken several months to figure out how to deploy a simple R script to production). And despite how old school their own tech was, team X were crafty enough to be able to plug it in to their existing architecture. Moreover, the output of the model was such that it didn’t take into account how the business will consume it or how it was going to be fed to downstream systems, and the product owners could have gone a long way in making the model more amenable to adoption by the business stakeholders. But team Y wouldn’t listen, and their leads brushed off any attempts at communication, let alone collaboration. The vibe that team Y was giving off was “We are the cutting edge ML team, you guys are the legacy server grunts. We don’t need your opinion.”, and they seemed to have a complete disregard for domain knowledge, or worse, they thought that all that domain knowledge consisted of was being able to grasp the definitions of a few business metrics.

Team X got frustrated and tried to express their concerns to leadership. But despite owning a vital link in Company A’s business process, they were only ~50 people in a large 1000 strong technology and operations org, and they were several layers removed from the C-suite, so it was impossible for them to get their voices heard.

Meanwhile, the unstoppable director was doing what he did best: Playing corporate politics. Despite how little his team had actually delivered, he had convinced the board that all analysis and optimization tasks should now be migrated to his yet to be delivered ML platform. Since most leaders now knew that there was overlap between team Y and team X’s objectives, his pitch was no longer that team Y was going to create a new insight, but that they were going to replace (or modernize) the legacy statistics based on-prem tools with more accurate cloud based ML tools. Never mind that there was no support in the academic literature for the idea that Naive Bayes works better than the Econometric approaches used by team X, let alone the additional wacky idea that Bayesian Optimization would definitely outperform the QP solvers that were running in production.

Unbeknownst to team X, the original Bayesian risk analysis project has now grown into a multimillion dollar major overhaul initiative, which included the eventual replacement of all of the tools and functions supported by team X along with the necessary migration to the cloud. The CIO and a couple of business VPs are on now board, and tech leadership is treating it as a done deal.

An outside vendor, a startup who nobody had heard of, was contracted to help build the platform, since team Y has no engineering skills. The choice was deliberate, as calling on any of the established consulting or software companies would have eventually led leadership to the conclusion that team X was better suited for a transformation on this scale than team Y.

Team Y has no experience with any major ERP deployments, and no domain knowledge, yet they are being tasked with fundamentally changing the business process that is at the core of Company A’s business. Their models actually perform worse than those deployed by team X, and their architecture is hopelessly simplistic, compared to what is necessary for running such a solution in production.

Ironically, using Bayesian thinking and based on all the evidence, the likelihood that team Y succeeds is close to 0%. At best, the project is going to end up being a write off of 50 million dollars or more. Once the !@#$!@# hits the fan, a couple of executive heads are going to role, and dozens of people will get laid off.

At worst, given how vital risk analysis and portfolio optimization is to Company A’s revenue stream, the failure will eventually sink the whole company. It probably won’t go bankrupt, but it will lose a significant portion of its business and work force. Failed ERP implementation can and do sink, see what happened to National Grid US, SuperValu or Target Canada.

One might argue that this is more about corporate disfunction and bad leadership than about data science and AI.

But I disagree. I think the core driver of this debacle is indeed the blind faith in Data Scientists, ML models and the promise of AI, and the overall culture of hype and self promotion that is very common among the ML crowd.

We haven’t seen the end of this story: I sincerely hope that this ends well for the sake of my colleagues and all involved. Company A is a good company, and both its customers and its employees deserver better. But the chances of that happening are negligible given all the information available, and this failure will hit my company hard.

submitted by /u/AlexSnakeKing
[link] [comments]

[D] how do you pick the right batch size for deep learning?

I’ve been trying to figure out the right way to pick the batch size for deep learning problems. not sure if there are generic guidelines for that or if it’s pretty much experimental? any thoughts?

I also came across this paper, and made this video to summarize it for a challenge; any feedback would be appreciated: https://youtu.be/crag6bMM-0k

submitted by /u/tdls_to
[link] [comments]

[D] Ian Goodfellow | MIT Artificial Intelligence Podcast

[D] Ian Goodfellow | MIT Artificial Intelligence Podcast

Ian Goodfellow is the author of the popular textbook on deep learning (simply titled “Deep Learning”). He coined the term Generative Adversarial Networks (GANs) and with his 2014 paper is responsible for launching the incredible growth of research on GANs. He got his BS and MS at Stanford, his PhD at University of Montreal with Yoshua Bengio and Aaron Courville. He held several research positions including at OpenAI, Google Brain, and now at Apple as director of machine learning. This recording happened while Ian was still at Google Brain.

https://www.youtube.com/watch?v=Z6rxFNMGdn0

https://i.redd.it/e9854r8dy1t21.png

submitted by /u/UltraMarathonMan
[link] [comments]

[D] Training on realizations, testing on posteriors?

I have a supervised, discriminative problem. The model is a feedforward NN. I’m trying to learn to predict p(Y = y|Z) where Z ~ P(Z | X). At training time I have get a sample Z ~ p(Z | X) but at test time I have the full posterior p(Z | X). Concretely, Z is represented by a 100 dimensional latent vector; at training I only have a 1-hot encoding but at test time I have a distribution. I could, of course, just take the argmax at test time but that throws away the full posterior. Or perhaps I should inject noise at train-time to the one-hot encoding. Is there any literature on this problem?

submitted by /u/the_roboticist
[link] [comments]