Toggle navigation OptaPlanner logo
  • Home
  • Download
  • Learn
    • Documentation
    • Videos
    • Slides
    • Training
    • Use cases
    • Compatibility
    • Testimonials and case studies
  • Get help
  • Source
  • Team
  • Services
  • Star
  • @OptaPlanner
  • Fb
Fork me on GitHub
  • Optimize your problems using KIE Execution Server
  • Java Reflection, but much faster

Does A.I. include constraint solvers?

Thu 7 September 2017

Avatar Geoffrey De Smet

Geoffrey De Smet


Twitter LinkedIn GitHub

OptaPlanner lead

The A.I. winter is over. For a few years now, the interest in Artificial Intelligence technologies is growing again. Not just from us, A.I. geeks. Business sees the potential to invest. To acquire new funding, many research projects are rebranding themselves as A.I. technology. Often justified. But not always. Can Constraint Solvers use the A.I. tag too?

A little history: the fifth generation project

For almost two decades, A.I. was a dirty word. To understand why, we need to go back to 1982, when Japan decided to invest massively in the fifth generation computer, an Artificial Intelligence platform which would leapfrog the existing computers of the time and break IBM’s monopoly. In a reaction, other countries funded similar projects. Suddenly research money fell out of the sky. The 80’s summer of A.I.

It failed. Despite decadent funding for almost 10 years, the fifth generation research had little practical use to show for. Some of the research was ahead of its time: lacking big data, smart phones and faster computers, it couldn’t work yet. Other research was completely useless.

In the aftermath of that failure, in the 90’s and early 2000’s, the term A.I. was tainted. A.I. didn’t work. Developers quickly stopped branding their technologies as such. Constraint solvers strengthened their Operations Research affiliation. Search engines acted as if they’re a simple dictionary lookup. Rule engines focused on decision tables. They all avoided mentioning their A.I. affiliation. Except for neural nets.

Neural nets: one tech fits all?

The last few years, neural nets made Artificial Intelligence cool again. A neural net mimics the neurons in our brain (not as much as you’d think). It’s a black box that transforms input data into output data, by pushing it through a number of neural layers of mostly sum and multiply arithmetic. For decades, its accuracy was too low, but that changed dramatically, with the recent rise of big data and the discovery of better backpropagation methods. The latter enables more layers. More layers equals deep learning.

Nowadays, neural nets can recognize faces and voices. And in a hybrid combination with other A.I. technologies (such as minimax), they can even beat the world’s champion of Go. Sounds like magic. But these are all pattern recognition problems. They can’t handle other problems. Neural nets can’t find the fastest route from La Louvre to the Colosseum. They can’t build the ultimate American roadtrip.

The right A.I. for the job

Neural nets aren’t an AGI (artificial general intelligence). Neither are constraint solvers or production rule systems, for that matter. Each one can only solve one subset of A.I. problems. That’s probably a good thing: none can become Skynet and pose a treat to humanity.

So to solve business problems with intelligent software, use the algorithm that fits the use case:

theRightAIForTheJob

This hasn’t stopped academics from trying. There’s plenty of research with neural nets to solve vehicle routing or employee rostering, it’s just consistency inferior to constraint solving algorithms such as Tabu Search and Simulated Annealing. Why settle for a 1% reduction in driving time when you can have 15%?

Visa versa, constraints solvers can’t even solve the infamous image recognition of a hot dog.

Do all algorithms produce intelligence?

Multiplying 1234 by 5678 isn’t easy, yet we don’t consider this artificial intelligence. Similarly, sorting algorithms aren’t A.I either. Why is that?

Maybe it’s because those problems don’t have an error margin. A.I. problems do: Given an image of a husky dog, some people recognize a wolf instead. Given a TSP problem to draw the shortest tour, people submit unique results of varying quality.

Maybe it’s because the calculation and sorting algorithms are understandable. There is no black box. It’s relatively easy to see how the computer transforms the input, instruction by instruction, into the output.

What about constraint solvers?

Historically, constraint solvers (such as OptaPlanner) are definitely part of the field of Operations Research, but that doesn’t exclude them from other fields.

I’d argue that constraints solvers also fall into the field of Artificial Intelligence. Not just because papers and books say so. Mainly because constraint solving use cases are inherently complex problems to master. There’s great variation in solution quality, both by human planners and specialized algorithms alike. Given a sufficiently large dataset, the optimal solution is impossible to find. Furthermore, researchers still discover new algorithms, even though other algorithms are almost 40 years old.

What do you think? Are constraint solvers part of the field of Artificial Intelligence?


Comments Permalink
 tagged as community insight

Comments

Visit our forum to comment
  • Optimize your problems using KIE Execution Server
  • Java Reflection, but much faster
Atom News feed
Don't want to miss a single blog post?
Follow us on
  • T
  • Fb
Blog archive
Latest release
  • 8.1.0.Final released
    Fri 15 January 2021
Upcoming events
  • KIE Live
    Worldwide - Tue 19 January 2021
    • OptaPlanner Shadow Variables for the Vehicle Routing Problem and Task Assignment by Geoffrey De Smet, Karina Varela, Alex Porcelli
  • Javaland
    Worldwide - Tue 16 March 2021
    • AI on Quarkus: I love it when an OptaPlan comes together by Geoffrey De Smet
Add event / Archive
Latest blog posts
  • Solve the facility location problem
    Fri 9 October 2020
     Jiří Locker
  • OptaPlanner Week 2020 recordings
    Mon 7 September 2020
     Geoffrey De Smet
  • Let’s OptaPlan your jBPM tasks (part 1) - Integrating the two worlds
    Fri 3 July 2020
     Walter Medvedeo
  • AI versus Covid-19: How Java helps nurses and doctors in this fight
    Fri 8 May 2020
     Christopher Chianelli
  • Workflow processes with AI scheduling
    Tue 5 May 2020
     Christopher Chianelli
  • Constraint Streams - Modern Java constraints without the Drools Rule Language
    Tue 7 April 2020
     Geoffrey De Smet
  • How to plan (and optimize) a Secret Santa
    Wed 18 December 2019
     Christopher Chianelli
Blog archive
Latest videos
  • YT Shadow variables
    Tue 19 January 2021
     Geoffrey De Smet
  • YT Domain modeling and design patterns
    Tue 17 November 2020
     Geoffrey De Smet
  • YT Quarkus insights: AI constraint solving
    Tue 20 October 2020
     Geoffrey De Smet
  • YT AI in kotlin
    Wed 23 September 2020
     Geoffrey De Smet
  • YT Planning agility: continuous planning, real-time planning and more
    Thu 3 September 2020
     Geoffrey De Smet
  • YT Quarkus and OptaPlanner: create a school timetable application
    Thu 3 September 2020
     Radovan Synek
  • YT Business use cases and the impact of OptaPlanner
    Thu 3 September 2020
     Satish Kale
Video archive

KIE projects

  • Drools rule engine
  • OptaPlanner constraint solver
  • jBPM workflow engine

Community

  • Blog
  • Get Help
  • Team
  • Governance
  • Academic research

Code

  • Build from source
  • Submit a bug
  • License (Apache-2.0)
  • Release notes
  • Upgrade recipes
Sponsored by
Red Hat
More coder content at
Red Hat Developers
© Copyright 2006-2021, Red Hat, Inc. or third-party contributors - Privacy statement - Terms of use - Website info