Wednesday, 26 June 2019
Facebook's cryptocurrency faces pre-G20 examination
Apple acquires self-driving startup Drive.ai
Google accused of working to prevent Trump return in 2020
Tatas may soon join queue for drone clearance from DGCA
How To Use Big Data to Improve Your Customer Service
Recent research has revealed that 90 percent of buyers are willing to pay a premium for better customer experience. The key is understanding what an improved experience actually means for a customer, however.
The rise of analytics has positioned companies to achieve closer customer analysis—on a far greater scale than feedback surveys or social media comments. With access to a mix of complex data sets from an array of sources, companies now have better insight into customer behavior, leading to higher sales numbers and better customer service.
With that in mind, here are five ways you can use this new emphasis on data to deliver better customer care.
1. Know Your Target Audience Much Better
In the past, data collected on customer interactions were primarily drawn from observation and direct engagement. These sources provided some level of insight but were difficult to aggregate—making it a challenge to get a comprehensive view. Today, companies are able to examine thousands of data points on each customer to better understand and segment their best customers.
For example, companies have used big data to figure out how millennial buying habits differ from previous generations. In terms of a singular product, companies now understand why the product ...
Read More on Datafloq
How to Leverage the Internet of Things for Railroads
It’s a word that you hear getting thrown around a lot. As more and more industries experience widespread digitalization, and we rely on mobile devices to conduct even the simplest of daily activities, it becomes clear that there are many opportunities to leverage connectivity to work more efficiently and make smarter decisions.
This is where the Internet of Things (IoT) enters the picture.
The Internet of Things for railroads
The Internet of Things (IoT) refers to objects that have unique identifiers and possess the ability to transfer data over a network in near real-time.
Once this data is transmitted, railroads can then leverage data analytics to extract insights from the data to optimize performance and efficiency. What railroads are realizing is that they can make predictions about the future through historical and current data, convey this information in real time, and act on it.
Everyday objects can send and receive real-time data to each other, enabled with computing devices that are embedded in these devices.
The benefit of IoT for railroads
According to Cisco, an estimated $30 billion is going to be spent on the Internet of Things in railways in the next 15 years. Back in 2016, Progressive Railroading wrote that the IoT “represents ...
Read More on Datafloq
Tuesday, 25 June 2019
Mass Transit Future and AI Autonomous Cars
By Lance Eliot, the AI Trends Insider
Hop on, hop off, hop on, hop off, and repeat until you reach your destination.
Here in Southern California, a key local transit entity is called MTA (Metropolitan Transit Authority) and provides mass transit options for commuters from throughout Los Angeles county. You’ve got light rail, heavy rail, buses, and the like.
Of the nearly one hundred MTA stations used by commuters to get access into the transit system, it turns out that only a few of those stations directly intersect with a second line. This means that you need to hop onto one train, hop off at another station, wait for the next right train, hop on, and maybe then arrive at the final station you were intending to reach. It seems likely you’ll need to make at least two or three such stops and switches, in reality, due to the lack of stations being interconnected with multiple lines.
You might say that it’s no big deal and shrug it off as just part of the mass transit system structure.
Unfortunately, it is a big deal in that it tends to turn-off riders or potential riders from using the mass transit system. Many people perceive that it is too confusing to have to make so many switches. They perceive that it uses up too much time, having to make the switches and sit around for the needed waiting times for the next right train. All in all, the inconvenience posits them over into avoiding using the mass transit option for travel.
The less riders on the mass transit system, the less valuable it is having the mass transit system.
It also means that the lack of ridership implies there’s less people taken out of the conventional car traffic pool.
And, thus, the mass transit doesn’t achieve some key stated goals of reducing conventional car traffic, which tends to also reduce pollution, and the mass transit is supposed to produce a lower cost alternative per mile per person traveled.
Looking At The Year 2047 For A Solution
One topic being discussed and debated here in Southern California is the proposed development of a new north-south spine that would run throughout central L.A. and create more intersecting points with the existing stations. According to Metro, the new line would potentially serve 90,000 trips a day and become the busiest light-rail line in the United States.
If all goes well in terms of proceeding to build the new line, it would open in the year 2047.
That’s right, the official ribbon cutting for the first ridership would be about 30 years from now.
Yikes!
For most of us, it’s hard to imagine waiting thirty years for something. If you have small children, they’ll be middle aged by the time the new line is running. If you are middle aged now, you’ll likely be nearing retirement. If you are already retired now, I can only hope you’ll be around to come and see the grand unveiling of the new line.
In terms of construction cost, it’s estimated that it could be around $150 million per mile (totaling a cost of about $3 billion), if built at street level.
Some say that it should not be at street level, and instead be placed either above ground via an aerial line, or maybe place it all underground. These proposed options are more expensive, including for example that the underground approach would likely be around $700 million per mile (total project cost of $4.7 billion). These are projected costs, of which there are some critics that say it’s way under-estimated and the true price tag will be much larger.
There is a group pushing to get the project done sooner and wants to have the new line underway by the time the 2028 Summer Olympics come to Los Angeles.
Hey, mark that year on your calendar to come visit L.A. in the year 2028. Be here, or be square.
Anyway, aiming to shave about 20 years off the 2047 forecasted date would certainly be a nice wish to have occur. But, whether you can accelerate a project of this magnitude, given all of the regulatory hurdles, the political aspects, and the rest, along with what it might due to pushing up the cost, well, let’s just say it’s still a dream for the moment.
Focus on the year 2047.
Think seriously about it.
Place your mind into the future.
The Future Should Include AI Autonomous Cars
What does this have to do with AI self-driving driverless autonomous cars?
Depending upon whom you believe, we’re presumably going to have quite a number of AI self-driving cars on our roadways by the time that the year 2047 rolls around. One notable prediction mentioned in a Fortune magazine article has predicted that by the year 2040 that about 95% of new cars sold in the United States will be AI self-driving cars (see: http://fortune.com/2017/09/13/gm-cruise-self-driving-driverless-autonomous-cars/).
If that’s the case, it would tend to suggest that by the year 2047 there will be a plentiful number of AI autonomous cars cruising around our highways and byways.
Some clarifications are needed.
Right now, there are an estimated 200+ million conventional cars in the United States.
Whenever AI self-driving cars start to become readily available, it will take a while to turn over the stock of conventional cars to become AI self-driving cars. I’ve mentioned many times that I’m doubtful there will be much in the way of kits to retrofit conventional cars, and that instead you’ll need to buy a new car that’s equipped as an AI self-driving car. And, since most people cannot just outright ditch their existing car and buy a new one, the odds are that it will take many years for AI self-driving cars to become widely populated on our roads.
See my article about kits for AI self-driving cars: https://aitrends.com/selfdrivingcars/kits-and-ai-self-driving-cars/
See my article about induced demand due to AI self-driving cars: https://aitrends.com/selfdrivingcars/induced-demand-driven-by-ai-self-driving-cars/
If we go along with the notion that it won’t be until about 2040 that the predominant new car purchase will consist of AI self-driving cars, it suggests that during the 2020’s and the 2030’s we’ll have a mix of conventional cars and AI self-driving cars, but that conventional cars will still be the dominant mode of car traffic on our roads.
I’ve emphasized this aspect many times too because there are some AI self-driving car pundits that keep bringing up a nirvana world of all and exclusively AI self-driving cars on our streets, but this just isn’t going to happen for a very long time.
It’s important to realize that there are various levels of AI self-driving cars. The topmost level is Level 5, which is the point at which an AI self-driving car can drive the car without any human intervention needed. Indeed, there is usually no provision in the car for any human driving, such as there is the elimination of the pedals and the steering wheel. Whatever a human could do in terms of driving the car, it is expected that the AI will do instead for a Level 5 AI self-driving car.
During the 2020’s and the 2030’s, we’ll definitely see a lot of cars that are at the levels 2 and 3, and perhaps some at the level 4, but presumably very few at the true Level 5. There will be some intense and acrimonious debate about whether a self-driving car has actually achieved a Level 5, and which is a facet not so easily determined.
See my article about levels of AI self-driving cars: https://aitrends.com/selfdrivingcars/richter-scale-levels-self-driving-cars/
See my article about a Turing test for AI self-driving cars: https://aitrends.com/selfdrivingcars/turing-test-ai-self-driving-cars/
See my framework about AI self-driving cars: https://aitrends.com/selfdrivingcars/framework-ai-self-driving-driverless-cars-big-picture/
Returning to the matter at-hand, I began by mentioning that the Los Angeles mass transit system is proposing to add a new line at a cost of perhaps $3 billion to $5 billion dollars, and that it won’t be ready until 2047 (unless there’s a miracle and Santa Claus deliver it earlier, such as by the year 2028).
Hard-To-Digest Questions About Future Mass Transit
Here’s the million dollar (or billion dollar) question: Do we need more mass transit by the time we reach the mid-2040’s and beyond?
If we’re going to have widespread AI self-driving cars by that same time frame, perhaps we’re pouring money into adding mass transit that will ultimately have been for not.
In other words, yes let’s keep the existing mass transit system going, since we presumably need it during the next 30 years or so for purposes of shoring up the lack of widespread AI self-driving cars, but maybe we should be doing a “gut check” as to starting to build something that won’t come available until a future in which it maybe won’t be needed.
It’s perhaps a bridge to nowhere, as they say.
By the way, as an interesting aside, we already have a bridge to nowhere here in California, based in our San Gabriel mountains.
Back in 1936, there was an effort to build an arch bridge that was going to connect with a road that would lead to San Gabriel Valley. The bridge got built. The road got washed out in 1938. The decision was made that it was no longer worth the cost to proceed. The bridge now just sits there. From time to time, people come to look at it and some try to parachute off it. It’s officially known as the “Bridge to Nowhere.”
In any case, any mass transit project that is going to get started now or in the near future, and for which it might take 30 years or more to get built, we probably should look in the mirror and say do we like what we see?
Does it make sense to pump money into such projects?
Though I’ve brought up the question in the context of the Los Angeles mass transit, it seems prudent to ask the same question about any mass transit proposed anywhere in the United States.
Look around in your geographical area and ask yourself whether adding mass transit is worthwhile if indeed there will be prevalent autonomous cars.
One argument in favor of proceeding on the mass transit project would be that we don’t really know when the advent will be of AI self-driving cars in terms of a timeline, and thus it’s a reasonable hedge bet to assume that mass transit will still be needed by 2047. It’s conceivable that we won’t have many AI self-driving cars by then, and instead maybe it will be another twenty or thirty years later, such as perhaps 2060 or 2070. In that case, full-steam ahead with more mass transit until we reach those later dates.
Consider The Trade-offs Involved
Another argument in favor of proceeding with massive multi-decades long mass transit projects would be that even if AI self-driving cars are popular by 2047, maybe we will still need mass transit.
Let’s consider that aspect, analyzing the positions both in-favor and opposing to it.
Some believe that with the prevalence of AI self-driving cars, we are going to have a ridesharing-as-an-economy way of living.
This means that ridesharing will be the dominant mode of travel and that we’ll be using AI self-driving cars to do so.
Those that buy AI self-driving cars will realize that they don’t need to use it 24×7, even though it can be used 24×7 generally because it has an electronic chauffeur always at the ready. So, people will turn their AI self-driving car into a ridesharing service. Some will purchase an AI self-driving car purposely to be a ridesharing service and use it almost entirely and only for making money as a ridesharing mechanism.
Some assert that autonomous cars will be mainly fleet owned, such as by a large automaker, or a large tech firm, or a large ridesharing firm, or really any sizable firm that thinks they can make money by using self-driving driverless cars for ridesharing purposes. Though I am emphasizing large sized companies doing this, it could very well be that lots of mini-fleets sprout too, by medium sized firms and smaller firms.
Individuals might also buy several driverless cars and create their own micro-sized fleet, creating a kind of cottage industry.
For my article about non-stop AI self-driving cars: https://aitrends.com/selfdrivingcars/non-stop-ai-self-driving-cars-truths-and-consequences/
For my article about the affordability of autonomous cars, see: https://www.aitrends.com/selfdrivingcars/affordability-of-ai-self-driving-cars/
On the topic of Gen-Z and the emergence of driverless cars, see my article: https://www.aitrends.com/selfdrivingcars/gen-z-and-the-fate-of-ai-self-driving-cars/
If that happens, would anyone want to use mass transit?
Commuters can use the convenience of an autonomous car that provides their own private bubble, as it were, and will take them directly to where they want to go, they don’t need to wait to use it, and presumably the cost will be relatively low since there will such an abundant supply of these AI self-driving cars roaming and roving around.
Furthermore, the AI self-driving car can cover the last mile for them.
The vaunted and prized “last mile” is a reference to the problem that most mass transit options can’t get you to your actual desired destination.
You might desire to get from a train station to that grocery store or your home, and so the mass transit isn’t complete. Meanwhile, the AI self-driving car could take you on the short hauls and even the longer hauls, in theory.
You might argue that all those AI self-driving cars will be polluting and gas guzzlers, which is the reason why mass transit is better, ecologically. But, the odds are that most if not all AI self-driving cars are going to be electrical vehicles. Therefore, no gas guzzling, and little or no pollutants. The mass transit ecological argument is valid today because we have so many conventional cars and they are pretty much gas fueled. It seems unlikely that’s the way that AI self-driving cars will be.
Plus, some believe that there will be potentially a Personal Rapid Transit (PRT) system consisting of a means to have an autonomous car ride on a sled or similar conveyance platform, whisking the driverless in a train-like system to a destination point, and then the autonomous car will disembark and drive the rest of the way to the desired destination.
For my article about Personal Rapid Transit and driverless cars, see: https://www.aitrends.com/selfdrivingcars/personal-rapid-transit-prt-and-ai-self-driving-cars/
For my article about autonomous cars being EV’s, see: https://www.aitrends.com/selfdrivingcars/power-consumption-vital-for-ai-self-driving-cars/
The aforementioned aspects seem to suggest that we won’t need mass transit. That might seem harsh.
Suppose instead we say that we’ll need less mass transit, but not eliminate it entirely. There will still be circumstances perhaps of not wanting to use an AI self-driving car and instead ride on a train or a bus.
We also need to consider that presumably if the AI is good enough to drive a car, it would seem to be good enough to likely drive a bus, and drive a train. In that case, we’ve taken the labor costs out of the bus driving and the train driving.
This perhaps makes mass transit even more affordable, at least on an ongoing basis (it still wouldn’t seem to dampen the initial construction cost).
How Big Is Big
In the United States, there is about $65 billion spent annually toward the ongoing upkeep of our countries mass transit systems.
The average trip length is around 5.5 miles.
There are an estimated 433,000 people employed by mass transit in America, of which 97% of them are in the operational aspects of mass transit.
These are numbers provided by the American Public Transportation Association (APTA).
If AI self-driving cars were to emerge and if it meant that mass transit would gradually disappear or dramatically scale-down, presumably this would mean that the $65 billion annually being spent today would possibly go to other uses.
What would happen to the nearly half a million people employed by mass transit? Seemingly, hopefully, the ramp down of mass transit would occur over a lengthy enough period that those people would be able to shift to some other area of the economy.
According to the mass transit industry, for each $1 billion added investment in mass transit, those invested dollars supports the creation of potentially 50,000 jobs. If we once again assume the scenario of not making those mass transit investments, at least for investments involving mass transit that won’t come on-line until 2047 or thereabouts, it suggests that those added jobs can’t be counted on to materialize.
Consider another idea. Might the advent of AI self-driving cars generate the same kind of jobs expansion, in lieu of the mass transit?
Maybe.
With all of those AI self-driving cars, and going around the clock, there’s going to be a lot of need for maintenance and upkeep of those cars. A car is still a car. It will break down.
Probably even more so than now, since the self-driving cars might be run all the time. Presumably, lots of human specialists for doing maintenance and repairs will be needed, at least until it can be automated via robotics or similar technology.
For my article about the repairs aspects of autonomous cars, see: https://www.aitrends.com/selfdrivingcars/auto-recalls/
For driverless cars and the question of being an economic commodity, see my article: https://www.aitrends.com/selfdrivingcars/economic-commodity-debate-the-case-of-ai-self-driving-cars/
For my article about the changing landscape of jobs due to the advent of driverless cars, see: https://www.aitrends.com/selfdrivingcars/future-jobs-and-ai-self-driving-cars/
Conclusion
Today, there are an estimated 5% of cars in the United States that are being used for ridesharing.
By the year 2040, some predictions are that 68% of cars will be used for ridesharing.
This opens up a tremendous capacity for doing ridesharing. It seems like this shift would have to take away ridership from someplace else, and thus mass transit could be one place that gets reduced in terms of ridership as commuters shift over to using AI self-driving cars.
As a side note, some believe that mobility today is suppressed and not fully exercised due to the arduous and costly aspects of transportation, therefore, the advent of more readily available and affordable mobility might uncork the bottle, namely unleashing the suppressed need, a phenomena often referred to as induced demand.
For my article about induced demand and autonomous cars, see: https://www.aitrends.com/selfdrivingcars/induced-demand-driven-by-ai-self-driving-cars/
People today that don’t travel, or only travel to some degree N, they will all now opt to travel and do so for some heightened amount Z. If you believe in that notion, it could be that with such a massive scaling up of demand for travel, the mass transit still remains in place.
We might need both the advent of AI self-driving cars and the ongoing capability of mass transit to handle all of that gargantuan demand.
Over the last 20 years or so, the growth of mass transit passenger miles has eclipsed the number of car miles traveled (per the APTA stats). Mass transit though still only is used by a relatively small percentage of the traveling public. With the emergence and ultimately prevalence of AI self-driving cars, it might seem reasonable to anticipate that the number of car miles traveled will not only eclipse the mass transit passenger miles, but do so by perhaps a dramatic amount.
We also need to consider the opportunity costs associated with spending on future mass transit expansions.
If the Los Angeles line expansion gets the needed $3 to $5 billion dollars in spending, of which some will come from local sources and some from federal (maybe half from federal), could that money have been put to some other use instead? If it’s a bridge to nowhere, maybe there’s other projects that would be a wiser investment. On the other hand, since the billions will be spent over the next thirty years, you could at least say that it has had a benefit of hiring the people that did the construction during that period of time (and other side economic benefits).
These speculations involve all sorts of economic guesses and also technological guesses.
When will AI self-driving cars become prevalent?
Will they be as safe as mass transit?
Will they be as reliable?
Will they be more or less costly than mass transit?
I’m sure you’ve heard the phrase “voodoo economics” having been used, often in a condescending way, when referring to speculative economic theories that are being espoused.
For AI self-driving cars, perhaps we’ve got a bit of “voodoo predictions” about when AI self-driving cars will truly be viable and become a mainstay in society.
Whether or not we should bet on the future of mass transit based on the voodoo predictions is a tough call. Some say play it safe and build a potential bridge to nowhere, in case it turns out to be a bridge to somewhere, while others decry this kind of logic and say don’t put good money after bad.
Guess we need time to let this play out, and maybe a transportation “witch doctor” to sort this out.
Copyright 2019 Dr. Lance Eliot
This content is originally posted on AI Trends.
Why India should not outlaw cryptocurrencies
Debit cards show up more at retail stores, less at ATMs
Unicorn Freshworks starts investing in AI and chatbots
VR Websites: A Reality?
Difference Between Virtual and Augmented Reality
The concepts of virtual reality (VR) and augmented reality (AR) differ on the following three major factors-
Differentiating Factor
Virtual Reality
Augmented Reality
Immersion
In the case of virtual reality, it generates a completely computer-generated world, i.e. everything seen by the user is due to artificial recreation, and the user begins to lose contact with the real environment
Augmented reality enhances the reality by addition of digital information to it, and the user is still in contact with the real environment during the augmented reality experience.
It allows the users to interact with “augmented” set of objects while being in contact with the real world
Devices
Virtual reality uses headsets that immerse into the user’s vision and hearing into the virtual world
Augmented reality can be provided by some devices which include the AR headsets, laptops, ...
Read More on Datafloq
How Manufacturing Can Embrace IoT
The Rise of the Smart Factory
Two decades ago, robotic automation was considered the wave of the future. Digital tools are becoming commonplace in the industry, from warehouse management software to robotic assemblers, but these advancements, for the most part, stood alone. The smart factory uses IoT to bring everything together, creating a massive network of devices that can talk to one another, collecting information and sending it back to the hub, removing the need for manual data collection.
Sensors can monitor equipment through every step of the production process and can analyze the health of each piece of machinery to prevent costly downtime caused by equipment failure. Smart factories have five primary features — a connected network, an optimized factory floor, broad supply chain transparency, a proactive attitude, and the agility to change as problems arise.
The IoT manufacturing ...
Read More on Datafloq
Monday, 24 June 2019
Can Facebook’s Libra get past the hurdles Bitcoin faced?
Friday, 21 June 2019
An Analysis of Facebook's Cryptocurrency Libra and What it Means for Our World
It was to be expected that when the social media giant, who has seen numerous scandals in 2018, would launch a cryptocurrency, there would be opposition. Many people, organisations and governments no longer trust Facebook with the social media data, let alone with their financial data. The main concerns from regulators and lawmakers around the world are that Facebook is already too massive and careless with users' privacy to launch an initiative like Libra.
However, before we judge too quickly, let's first dive into the Libra blockchain and the Libra coin to understand it ...
Read More on Datafloq
Connecting MongoDB to Ruby with Self-Signed Certificates for SSL
ScaleGrid currently uses self-signed certificates for SSL when creating nodes for a new cluster. Additionally, we also provide you with the option of purchasing your own SSL certificates and configuring them on the MongoDB server, and you can email support@scalegrid.io to learn more about this offer.
Connecting to a Replica Set Using Ruby MongoDB Driver
We will use the latest stable Ruby MongoDB driver version 2.8 for this example. The 2.5.x versions of the driver have a known bug that inhibit them from working with ScaleGrid deployments. The Ruby version used in both the examples below is 2.6.3.
The connection options available for the driver are documented here, and the options we will need are:
:ssl
:ssl_verify
:ssl_ca_cert.
First, find and copy your MongoDB connection string from the cluster details page on the ScaleGrid console:
The CA certificate file is also available for download from the cluster details page. Download and store the cert file at a location that is available to the application:
Here’s a ...
Read More on Datafloq
Micro-benchmarking Framework for Jenkins Plugins
I have been working on improving the performance of the Role Strategy Plugin as a part of my Google Summer of Code project. Since there was no existing way to measure performance and do benchmarks on Jenkins Plugins, my work for the first phase of the project was to create a framework for running benchmarks in Jenkins plugins with a Jenkins instance available. To make our job a bit easier, we chose Java Microbenchmark Harness for running these benchmarks. This allows us to reliably measure performance of our time-critical functions and will help make Jenkins perform faster for everyone.
The micro-benchmarking framework was recently released in the Jenkins Unit Test Harness 2.50. The blog post below shows how to run benchmarks in your plugins.
Introduction
The framework runs works by starting a temporary Jenkins instance for each fork of the JMH benchmark, just like JenkinsRule from Jenkins Test Harness. Benchmarks are run directly from your JUnit Tests which allows you to fail builds on the fly and easily run benchmarks from your IDE, just like unit tests. You can easily configure your benchmarks by either using your Java methods, or by using Jenkins Configuration-as-Code plugin and passing the path to your YAML file.
To run benchmarks from your plugins, you need to do the following:
-
bump up the minimum required Jenkins version to 2.60.3 or above
-
bump Plugin-POM to a version ≥ 3.46 or manually upgrade to Jenkins Test Harness ≥ 2.51.
Now, to run the benchmarks, you need to have a benchmark runner that contains a @Test so it can run like a JUnit test. From inside a test method, you can use the OptionsBuilder provided by JMH to configure your benchmarks. For example:
public class BenchmarkRunner {
@Test
public void runJmhBenchmarks() throws Exception {
ChainedOptionsBuilder options = new OptionsBuilder()
.mode(Mode.AverageTime)
.forks(2)
.result("jmh-report.json");
// Automatically detect benchmark classes annotated with @JmhBenchmark
new BenchmarkFinder(getClass()).findBenchmarks(options);
new Runner(options.build()).run();
}
}
Sample benchmarks
Now, you can write your first benchmark:
Without any special setup
@JmhBenchmark
public class JmhStateBenchmark {
public static class MyState extends JmhBenchmarkState {
}
@Benchmark
public void benchmark(MyState state) {
// benchmark code goes here
state.getJenkins().setSystemMessage("Hello world");
}
}
Using Configuration as Code
To use configuration as code, apart from the dependencies above you also need to add the following to your pom.xml:
<dependency>
<groupId>io.jenkins</groupId>
<artifactId>configuration-as-code</artifactId>
<version>1.21</version>
<optional>true</optional>
</dependency>
<dependency>
<groupId>io.jenkins</groupId>
<artifactId>configuration-as-code</artifactId>
<version>1.21</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
Now configuring a benchmark is as simple as providing path to your YAML file and specifying the class containing the benchmark state.
@JmhBenchmark
public class SampleBenchmark {
public static class MyState extends CascJmhBenchmarkState {
@Nonnull
@Override
protected String getResourcePath() {
return "config.yml";
}
@Nonnull
@Override
protected Class<?> getEnclosingClass() {
return SampleBenchmark.class;
}
}
@Benchmark
public void benchmark(MyState state) {
Jenkins jenkins = state.getJenkins(); // jenkins is configured and ready to be benchmarked.
// your benchmark code goes here...
}
}
More Samples
As a part of this project, a few benchmarks have been created in the Role Strategy Plugin which show configuring the instances for various situations. You can find them here.
Running Benchmarks
Running benchmarks from Maven
To easily run benchmarks from Maven, a Maven profile to run the benchmarks has been created and is available starting Plugin-POM version 3.45. You can then run your benchmarks from the command line using mvn test -Dbenchmark.
Running benchmarks on ci.jenkins.io
If you have your plugins hosted on ci.jenkins.io, you can easily run benchmarks directly from your Jenkinsfile by using the runBenchmarks() method after the buildPlugin() step in your which is now available in Jenkins Pipeline library. This function also accepts the path to your generated JMH benchmark reports as an optional parameter and archives the benchmark results. Running benchmarks in pull request builds allows you to constantly monitor the performance implications of a given change. For example, the Jenkinsfile from Role Strategy Plugin:
buildPlugin()
runBenchmarks('jmh-report.json')
Visualizing benchmark results
Benchmark reports generated (in JSON) can be visualized using the either the JMH Report Plugin or by passing the benchmark reports to the JMH visualizer web service. As an example, here is a visualized report of some benchmarks from the Role Strategy Plugin:
These improvements seen above were obtained through a small pull request to the plugin and shows how even seemingly small changes can bring major performance improvements. Microbenchmarks help to find these hot-spots and estimate the impact of changes.
Some tips and tricks
-
Since
BenchmarkRunnerclass name in the example above does not qualify as a test according to Maven surefire plugin’s naming conventions, the benchmarks will not interfere with your JUnit tests. -
Benchmark methods need to be annotated by
@Benchmarkfor JMH to detect them. -
Classes containing benchmarks are found automatically by the
BenchmarkFinderwhen annotated with@JmhBenchmark. -
A reference to the Jenkins instance is available through either
JmhBenchmarkState#getJenkins()or throughJenkins.getInstance()like you would otherwise do. -
JmhBenchmarkStateprovidessetup()andtearDown()methods which can be overridden to configure the Jenkins instance according to your benchmark’s requirements. -
The benchmark builds on ci.jenkins.io are currently throttled because of the limited availability of
highmemnodes. -
The benchmark framework was made available in Jenkins Test Harness 2.50, it is recommended to use version 2.51 as it includes some bug fixes.
Links and Feedback
If you have any feedback, comments or questions, please feel free to reach out to me through either the Role Strategy Plugin Gitter chat or through the Jenkins Developer Mailing list.
How to Increase Diversity in the Tech Workplace
While the benefits of a diverse workplace can help any company thrive, figuring out how exactly to increase diversity in tech workplaces can be a challenge. However, employing a diverse team is not impossible, and the rewards make diversification efforts well worth it.
Diversity Is Less Common Than You Might Think
Though the tech industry is far more diverse today than it has been in the past, diversity still remains an issue across the sector. Even if those heading tech companies don’t engage in outright racism by fostering a hostile work environment towards people of color or discouraging the hiring of diverse groups, many tech companies still find themselves with teams that look and think alike. Homogeny creates complacency, insulates a workforce from outside perspectives, and ultimately prevents real innovation and creativity from taking place.
Tech companies can be complicit in racism through hiring practices, segregation of existing ...
Read More on Datafloq
Amazon may bring surveillance services with delivery drones
Announcing Databricks Runtime 5.4
Databricks is pleased to announce the release of Databricks Runtime 5.4. This release includes Apache Spark 2.4.3 along with several important improvements and bug fixes . We recommend all users upgrade to take advantage of this new runtime release. This blog post gives a brief overview of some of the new high value features that simplify manageability and improve usability in Databricks.
Simplified Manageability
We continue to make advances in Databricks that simplify data and resource management.
Delta Lake Auto Optimize – public preview
Delta Lake is the best place to store and manage data in an open format. We’ve included a feature in public preview called Auto Optimize that removes administrative overhead by determining optimum file sizes and performing necessary compaction at write time. It’s configured as an individual table property and can be added to existing tables. Optimized tables allow you to query those tables efficiently for analytics.
To try out Auto Optimize, consult the Databricks documentation(Azure | AWS).
AWS Glue as the Metastore for Databricks – public preview
We’ve partnered with the Data Services team at Amazon to bring the Glue Catalog to Databricks. Databricks Runtime can now use Glue as a drop-in replacement for the Hive metastore. This provides several immediate benefits:
- Simplifies manageability by using the same glue catalog across multiple Databricks workspaces.
- Simplifies integrated security by using IAM Role Passthrough for metadata in Glue.
- Provides easier access to metadata across the Amazon stack and access to data catalogued in Glue.
Glue as the metastore is currently in public preview, and to start using this feature please consult the Databricks Documentation for configuration instructions.
Improved Usability
Databricks Runtime 5.4 includes several new features that improve usability.
Databricks Connect – general availability
A popular feature that has enjoyed wide adoption during public preview, Databricks Connect is a framework that makes it possible to develop applications on the Databricks Runtime from anywhere. This enables two primary use cases:
- Connect to Databricks and work interactively through your preferred IDE
- Build applications that connect to Databricks through an SDK
Databricks Connect allows you to:
- Plug into your existing workflows for software development life cycle.
- Check out, and develop locally in your preferred IDE, or notebook environment.
- Run your code on Databricks clusters.
For an in depth description, refer to the Databricks Connect blog post, which goes into further detail. To try out Databricks Connect, refer to the getting started documentation(Azure | AWS).
Databricks Runtime with Conda – beta
Take advantage of the power of Conda for managing Python dependencies inside Databricks. Conda has become the package and environment management tool of choice in the data science community and we’re excited to bring this capability to Databricks. Conda is especially well suited for ML Workloads, and Databricks Runtime with Conda lets you create and manage Python environments from within the scope of a user session. We provide two simplified Databricks Runtime pathways to get started:
- databricks-standard environment includes updated versions of many popular Python packages. This environment is intended as a drop-in replacement for existing notebooks that run on Databricks Runtime. This is the default Databricks Conda-based runtime environment.
- databricks-minimal environment contains a minimum number of packages that are required for PySpark and Databricks Python notebook functionality. This environment is ideal if you want to customize the runtime with various Python packages.
For more in depth information, visit the blog post introducing Databricks Runtime with Conda. To get started, refer to the Databricks Runtime with Conda documentation(Azure | AWS).
Library Utilities – general availability
Databricks Library Utilities enable you to manage Python dependencies within the scope of a single user session. You can add, remove, and update libraries and switch Python environments (if using our new Databricks Runtime with Conda) all from within the scope of a session. When you disconnect, the session is not persisted and is garbage collected and resources are freed up for future user sessions. This has several important benefits:
- Install libraries when and where they’re needed, from within a notebook. This eliminates the need to globally install libraries on a cluster before you can attach a notebook that requires those libraries.
- Notebooks are completely portable between clusters.
- Library environments are scoped to individual sessions. Multiple notebooks using different versions of a particular library can be attached to a cluster without interference.
- Different users on the same cluster can add and remove dependencies without affecting other users. You don’t need to restart your cluster to reinstall libraries.
For an in depth example visit the blog post Introducing Library Utilities. For further information, refer to Library Utilities in the Databricks documentation(Azure | AWS).
--
Try Databricks for free. Get started today.
The post Announcing Databricks Runtime 5.4 appeared first on Databricks.
AI courses a bigger draw for experienced techies
Bengaluru's drone companies get first DGCA certification
Government: An Integral Partner for Exploring AI
By Chuck Brooks, Global Thought Leader in Cybersecurity and Emerging Tech
On June 24, an upcoming conference will explore the implications of artificial intelligence (AI) in the public sectors. AI World Government will gather leaders across government, industry and academia to discuss the challenges and potential solutions of AI in automating our expanding digital world. The event is described as “a comprehensive three-day forum to educate and inform public sector agencies on the strategic and tactical benefits of deploying AI and cognitive technologies.”
The topic of AI is garnering attention in government and industry. Research and consulting firm Gartner describes AI as a “technology that appears to emulate human performance typically by learning, coming to its own conclusions, appearing to understand complex content, engaging in natural dialogs with people, enhancing human cognitive performance or replacing people on execution of non-routine tasks.”
AI can be a game-changer for accelerating cognitive capabilities and economic benefits. McKinsey & Company predicts a $5 to $7 trillion potential economic impact by 2025 from automation of knowledge work by intelligent software systems that can perform knowledge work tasks from unstructured commands, according to an account in Forbes.
Government research in the areas of AI and its potential applications is not new, but the evolution of computing technologies has accelerated the reality of its development and implementation.
In government, the Defense Advanced Research Projects Agency (DARPA), Intelligence Advanced Research Projects Activity (IARPA) and many of the National Labs are involved in researching AI uses for national security, law enforcement, healthcare, transportation and commerce. In fact, the Pentagon played an instrumental role in the creation of one of the best known examples of AI, the self-driving car. As far back as 2004, DARPA hosted a series of autonomous vehicle “Grand Challenges.” The challenges spurred a wave of commercial R&D efforts.
More recently, DARPA announced a multi-year investment of more than $2 billion in new and existing programs in artificial intelligence called the “AI Next campaign.” DARPA director, Dr. Steven Walker, explained the implications of the initiative: “we want to explore how machines can acquire human-like communication and reasoning capabilities, with the ability to recognize new situations and environments and adapt to them.”
The Department of Defense (DoD) in cooperation with DARPA created The Joint Artificial Intelligence Center (JAIC). The mission of the JAIC is to “transform the DoD by accelerating the delivery and adoption of AI to achieve mission impact at scale. The goal is to use AI to solve large and complex problem sets that span multiple services; then, ensure the Services and Components have real-time access to ever-improving libraries of data sets and tools. “
At the Department of Homeland Security (DHS), a Community of Interest by The Science & Technology Directorate to foster collaboration on AI and Machine Intelligence. Similarly, the National Science Foundation and other government agencies are exploring AI and how it can enhance potential public sector missions.
The National Science and Technology Council (NSTC) Subcommittee on Machine Learning and AI was established to monitor state-of-the-art advances and technology milestones in AI and machine learning within the federal government.
In May of 2018, the White House Office of Science and Technology Policy (OSTP) formed a Select Committee on AI, comprised of senior research and development officials from across the government. Michael Kratsios, Deputy CTO at the White House OSTP, announced the creation of the committee noting, “as AI transforms everything from agriculture to manufacturing to transportation, the potential for AI remains breathtaking.”
The key aspect of all these initiatives is that the approaches to develop the tools and applications of AI involve the collective effort of government, industry and academia. Industry in cooperation with both government and academic research is working on “neuromorphic” technology that can incorporate nano-chips into wearables modeled on the human brain.
Eventually these nano-chips may be implanted into our brains artificially, augmenting human thought and reasoning capabilities. Such human/computer interface will extend our human brain capacities, memories and capabilities.
At the crux of the development and application of AI is a true public/private partnership engine supported by investment, ingenuity and real-world implementation. Of course, with disruptive technologies comes accountability (security and trust) for the many administrative, IP, and the regulatory ethical challenges that are arising.
AI World Government is a grand event that will bring together “800 leaders in government, technology, business, science and civil society to explore AI and intelligent automation technology and best practices, consider social and political issues, identify deployment and research priorities, and recommend solutions for policy.” It will also serve as is an important forum to elaborate on trends and distill the implications of AI so we head forward with public/private cooperative strategies in our rapidly changing digital ecosystem.
Chuck Brooks is the Principal Market Growth Strategist for General Dynamics Mission Systems for Cybersecurity and Emerging Technologies. He is also Adjunct Faculty at Georgetown University’s Applied Intelligence Program and graduate Cybersecurity Programs where he teaches courses on risk management, homeland security, and cybersecurity. Learn more at Chuck Brooks.
Read the source post in Forbes.
Brute Force Algorithms and AI: Use Case of Autonomous Cars
By Lance Eliot, the AI Trends Insider
When my children were young, they used to enjoy playing hide-and-seek with each other. One of them would hide somewhere either in the house or in our yard and be allowed a few minutes to find a good hiding spot. Once the other one had finished waiting the prescribed time period, the search would begin. At times, the search was quite hilarious to watch, particularly when they were quite young, since the places looked into were not at all feasible for any of them to hide in. I recall at one point that the teapot was examined and, on another occasion, that a potted plant in the house was dug into as though perhaps the hider might have become a gopher and dug into the dirt.
The search also at first covered every square inch of the house and the yard. They each would usually start indoors and go from room to room, looking throughout the bedroom of the other, then the bathroom, then their own bedroom, then the living room, then the kitchen, etc. If the hider wasn’t found in the house, the search would continue outdoors. This outdoor search usually began in the backyard, then went to the side yard, and eventually to the front yard.
There were some rules about the game that made things “fairer” in that the hider could not change their hiding spot during the game, and nor could they hide in a location that was considered out-of-bounds (for example, we banned them from climbing on the roof, that kind of thing). The person searching had to dutifully conduct the search. I mention this aspect because one tactic they discovered was the searcher could just sit and watch TV and figured that the hider would get tired of waiting to be found and voluntarily give themselves up. That wasn’t the spirit of the game.
All in all, they typically would conduct a rather exhaustive search.
It used up a chunk of their play time and perhaps honed their cognitive ability to undertake a reasoned approach to solving a problem. I enjoyed seeing that they were able to during a search proceed without backtracking and usually avoided revisiting the same location twice. If they felt that they had done an exhaustive search in a particular location, let’s say in the kitchen, they reasoned that there was no need to come back to the kitchen to do so again (recall that the hider could not be sneaky and move from location to location, which of course if so would then potentially necessitate revisiting prior search locations).
They also discovered that if they were sloppy about doing the search, they might end-up having apparently looked everywhere and yet still not found the hider. This was met with great chagrin as it implied that the searcher had somehow overlooked the hiding spot of the hider. At times, if one of them had looked inside and outside and could not find the hider, they would make an accusation that the hider had violated the rules and gone out-of-bounds. An out-of-bounds player was automatically considered the “loser” of the game and forfeited the game to the searcher. As parents, we also added additional penalties to going out-of-bounds since we didn’t want the children to unknowingly in their innocent desperation hide in a spot that would be dangerous for them (e.g., hiding in the fireplace was not allowed, likewise no hiding behind the furnace).
As they grew a bit older, and after having played the game many times, they improved upon their search techniques. One of the overarching aspects of the search involved whether to begin by searching inside the house versus outside of the house. They had each fallen into a pattern of always starting inside the house. This used up a lot of time as they went from room to room. The hider often realized that they could last longer in terms of hiding by finding a spot outside, and it was considered better to be hidden longer rather than getting caught right away. Also, living in Southern California, the outside weather was usually nice and sunny, so hiding outdoors was generally more enjoyable anyway.
As a result of these aspects, the searcher would often decide to forego starting the search indoors and instead begin it outdoors. This seemed like a prudent improvement to the search effort. Why not start the search where you believe the chances of finding the hider are heightened?
This handy rule-of-thumb had its uses and yet was not considered an iron clad approach. If the weather was somewhat foul, the odds were that the hider would opt to hide inside. In that case, rather than shifting to search outdoors first, it made more sense to instead search indoors first.
Likewise, they began to realize that the places of hiding had to be large enough to accommodate the hider. Sure, the hider could scrunch themselves up if needed, or maybe even try to stretch themselves out, but in any case, it was realized that they could not somehow fit into a teapot. There were plentiful areas both indoors and outdoors that could accommodate a hider, and meanwhile there were many more areas that obviously could not accommodate a hider.
Another rule of the game was that the hider could not disturb anything in order to hide. For example, you could not pull things out of a closet to make space for you to hide in closet. If the closet had space within which you could fit, it was permissible to hide in there, but you could not be moving things around to create a space where none already existed per se.
Eventually, the game lost its attraction. There were only so many places to hide and it became apparent as to where those spots were. The job of the searcher became focused solely on going to those spots. There was no need to run all around the house and no need to run all around the yard. Just quickly go to each of the known hiding spots, and you could rather expeditiously find the hider. Furthermore, you could usually guess which of those spots the hider might actually use, since there were some spots more accommodating and desirable than others (hiding behind the stinky cat litter box was not on the top of the list of places to hide!).
As an AI developer, I was fascinated in the evolution of their playing this hide-and-seek game. When they were young and first discovering how to play the game, they pretty much did an exhaustive kind of search. Look everywhere. Leave no stone unturned. Just start looking and keep looking until you find the hider. It involved a lot of exciting and playful running around the house and the yard.
Brute force.
Brute Force Algorithms Have Their Pro And Con
Brute force is a phrase that would aptly describe their initial approach to playing the hide-and-seek game.
The notion of brute force is that you undertake an exhaustive effort towards trying to do something, doing so without particularly having any added insight or ways to cut corners, instead you just go at it until you (hopefully) succeed in your quest. In the case of the kids, they would begin looking and just keep looking until they found the hider. All rooms were included, and all of the outdoor yard area was included.
As mentioned, at first, they had no particular strategy to how they were doing the search. It was almost a mindless kind of approach. Explore all possibilities was the mantra. When you find the hider, you are done.
The nice thing about a brute force method or algorithm is that it is usually pretty easy to implement and describe. I’m going to start looking for the hider and continue doing so until they are found and will look high and low to find them. This search process of looking high and low included areas that would not even accommodate the hider.
One of the disadvantages of a brute force approach is that it can be inefficient. The children would run throughout all rooms of the house and yet there were some rooms that had no available hiding spots. They at first always looked inside the house, even though the odds were that the hider was likely hiding outside. They looked in spots that would not even accommodate the hider. All of this was a quite inefficient search process (but, they had a lot of fun!).
Imagine if you had a computer that was undertaking some kind of search among a lot of data. You could use a brute force method to do so. Similar to the children and their hide-and-seek game, the computer could just start looking and continue doing so until it finds whatever is being searched for. No effort might be undertaken to help the computer identify where to first start looking and nor whether it can skip some of the data that might be readily inapplicable to the matter. Instead, the brute force might look at each data element, one by one, one after another, doing so exhaustively.
From a programming perspective, the odds are that the programmer that opts to use a brute force approach doesn’t have to do much work in terms of preparing the code for the effort. It tends to be easy to write such code. When I say easy, I mean that in comparison to having come up with a more elaborated method takes more effort to do. If you want to have a computer routine that will be savvy in doing a search, it takes some thinking about what the method should be. You need to design it and then code it. You need to test it to figure out whether it works or not. And so on.
One potential issue with brute force is that it can be difficult to know whether the brutish method will be able to find the desired solution in a “reasonable” amount of time.
Suppose the kids had a timeclock that kept track of their hide-and-seek game. If they had agreed to limit the search time to say five minutes, and if the approach of going throughout the entire house was taking say six minutes, it would imply that they would have only had time to do the indoors search and not the outdoors search. Furthermore, the six minutes to do the indoors search would have to end at the five minute deadline, meaning that even the indoor search would not necessarily complete.
For a computer system, using a brute force algorithm, it might take minutes, hours, days, weeks, months, or might not ever end (assuming you could let it keep running), while trying to find the solution being sought. This could chew-up a lot of processing cycles too. You could potentially devote a computer entirely to this search task and it might consume all available computing cycles in doing so.
Use Of Computing Resources Is A Trade-Off Too
Often times, when considering computer systems, you need to look at both the processing cycles consumed and the amount of computer memory consumed too. A brute force method can make use of computer processing cycles during its efforts. This might also require the use of computer memory while doing so.
Memory can be consumed at a tremendous rate during a brute force method. One danger then of a brute force approach is that it can consume so much memory that it might use up all available memory for the computer system being used. This could cause the brute force method to falter, and in some cases come to a halt prematurely.
Oddly enough, a brute force method can actually be a low memory consumer. In other words, rather than using up a lot of memory, the brute force algorithm might use hardly any memory at all. The simplistic nature of the algorithm might be that it uses a minimal amount of memory to undertake its steps. In contrast, sometimes a savvy algorithm might use up a lot of memory, doing so as a means of reducing the time required to find a solution.
If the time performance of a brute force computer algorithm is maybe taking too long, there are ways to potentially speed up the brute force effort without having to change the algorithm itself. For example, you might be able to use a faster computer processor. You might be able to add more computer memory. You might see if you can parallelize it, doing so by perhaps deploying the algorithm onto multiple processors.
The parallelization is not so easy a means to speed-up things. The nature of the brute force algorithm might not lend itself to working in parallel. As such, you cannot blindly just toss more processors at the situation and hope that it will help. The added processors might not speed up things and might actually be unused since there’s no clear-cut way to parallelize without changing the algorithm.
There’s a fine line between pure brute force and trying to make the brute force a bit savvier. Remember when the children realized that they might be better off to start their search outside, since they knew that it was an often-used hiding spot. Maybe we can improve a pure brute force method by refining it.
Some refer to this as employing brute reason.
Brute Reasoning At The Edge Of Brute Force
It can be hard to say where the dividing line is between a pure brute force versus adding brute reasoning, and also then extending beyond brute reasoning to say that we are using a non-brute force method entirely.
With the kids, they might have been using “brute reasoning” when they opted to search outdoors at first rather than indoors and they no longer looked in spots that could not accommodate a hider. You might say they progressed beyond brute reasoning and into a non-brute force method when they began to use their awareness of where the hider was more likely to hide, and not look in every room and reduce the overall search space size accordingly.
Indeed, we tend to think of brute force as a means to search a search space. If the search space is very large, the brute force method, though perhaps easy to implement, might then be quite lengthy in trying to find the desired solution. The kids added various rules-of-thumb, which we might call heuristics, and for which it then “reduced” the amount of search space that had to be examined (no longer looking at all rooms and all possible hiding spots).
I’ve often noticed that at times software developers are pushed to get on with their coding and not given time to figure out whether the system they are crafting will run well or not. In that sense, sometimes an organization is inadvertently shooting its own foot by not encouraging the software developers to take a moment to consider what kind of algorithms there might be for the problem they are trying to solve. It could be that after some exploration, there might be algorithms that go beyond brute force and use brute reasoning that could be employed. Furthermore, there might be elegant and complex algorithms that go even further and far eclipse any kind of brutish method.
Some developers though at times eschew algorithms that they aren’t familiar with, and as a result resort to using ones that they are comfortable with, in spite of the aspect that the algorithms might be brutish and not up to the task at hand in terms of needing to meet time and space constraints. There is a trade-off of trying to get such developers to consider other algorithms, along with their hesitancy to do so, along with the added time required to have them learn about and be able to use the algorithm, etc.
Typically, developers that specialize in AI systems are familiar with a wide range of non-brute force approaches, considered a core foundation for what AI techniques and methods utilize.
That being said, sometimes AI developers are perhaps over-eager to leverage very tricky algorithms that are intended to immensely improve over brute force, but perhaps the trickiness trips them up. They might not fully ensure that the non-brute force algorithm fully applies to the matter, or they put it into place but other developers are clueless about how it works, making for difficulties if they are supposed to maintain or enhance it over time.
I recall too when managing AI developers that one of member of my team came to see me and explained that he knew of only three ways to tackle a problem we were aiming to deal with. I explained to him that when his own base of knowledge about finding faster or more effective methods is exhausted that he should consult with his fellow AI developers to see what they might advise, along with doing some background research to see what else might exist. He was focused solely on his own base of experience, and had not tried to see what others might have to say about the approaches possible.
This brings up a classic line about the idea that if you only have a hammer then everything around you looks like a nail. Essentially, if you only know some brute force methods, you are likely to use them even though they might not be the appropriate choice in the circumstance. I’d say the other side of the coin works in this case too. If you know only elegant and complex algorithms, you might tend to use those when a brute force method might actually be the more fitting choice.
Brute Force As Deployed In AI Autonomous Cars
What does this have to do with AI self-driving driverless autonomous cars?
At the Cybernetic AI Self-Driving Cars Institute, we are developing AI software for self-driving cars. One crucial aspect of the AI involves its ability to perform various searches.
You might be thinking of searches when driving a car such as trying to figure out how to get to where you are going. Maybe there are ten different ways that you can drive to work. Which of the ten paths would be the best? You might use a computer algorithm to consider each of the ten paths. Some might of the paths might be shorter than others, but those shorter paths might involve lots of intersections with traffic signals, all of which might increase the driving time even if the distance is not as far.
There are other various kinds of searches that take place.
Allow me to elaborate.
I’d like to first clarify and introduce the notion that there are varying levels of AI self-driving cars. The topmost level is considered Level 5. A Level 5 self-driving car is one that is being driven by the AI and there is no human driver involved. For the design of Level 5 self-driving cars, the auto makers are even removing the gas pedal, brake pedal, and steering wheel, since those are contraptions used by human drivers. The Level 5 self-driving car is not being driven by a human and nor is there an expectation that a human driver will be present in the self-driving car. It’s all on the shoulders of the AI to drive the car.
For self-driving cars less than a Level 5, there must be a human driver present in the car. The human driver is currently considered the responsible party for the acts of the car. The AI and the human driver are co-sharing the driving task. In spite of this co-sharing, the human is supposed to remain fully immersed into the driving task and be ready at all times to perform the driving task. I’ve repeatedly warned about the dangers of this co-sharing arrangement and predicted it will produce many untoward results.
For the levels of self-driving cars, see my article: https://aitrends.com/selfdrivingcars/richter-scale-levels-self-driving-cars/
For my overall framework about AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/framework-ai-self-driving-driverless-cars-big-picture/
For why AI Level 5 self-driving cars are like a moonshot, see my article: https://aitrends.com/selfdrivingcars/self-driving-car-mother-ai-projects-moonshot/
For the dangers of co-sharing the driving task, see my article: https://aitrends.com/selfdrivingcars/human-back-up-drivers-for-ai-self-driving-cars/
Let’s focus herein on the true Level 5 self-driving car. Much of the comments apply to the less than Level 5 self-driving cars too, but the fully autonomous AI self-driving car will receive the most attention in this discussion.
Here’s the usual steps involved in the AI driving task:
- Sensor data collection and interpretation
- Sensor fusion
- Virtual world model updating
- AI action planning
- Car controls command issuance
During the driving task, the AI system is collecting data from the myriad of sensors, including radar, sonic, cameras, LIDAR, and others. The data needs to be explored to try and identify what the data indicates.
For example, suppose that the camera has captured a picture of the scene in front of the self-driving car. The AI needs to examine the picture and try to see if there are other cars up ahead. Are there pedestrians nearby the self-driving car? Are there bicyclists nearby the self-driving car? All of these have to be found in the picture. Likewise, for the radar, sonic results, LIDAR data, a search needs to be made to figure out what objects exist in that data.
Brute force.
Brute force would be one way to conduct the search of the sensory collected data. The computer on-board the self-driving car could exhaustively examine the data. This might seem like a sensible approach. Just have the system look at everything and anything.
But, suppose the amount of time it takes to do this brute force examination of the sensory data took three seconds to undertake. Suppose the self-driving car was moving along at 55 miles per hour, which is about 80 feet per second. In the three seconds that the brute force algorithm was looking at the data, the self-driving car has moved 240 feet. In that distance, it could be that the self-driving car rams into another car ahead, doing so because the AI was not yet aware that a car was directly ahead and that the AI ought to hit the brakes on the self-driving car.
As such, using a simplistic brute force algorithm might be “easy” to implement, but it could also have life-or-death consequences. Driving a car is a real-time task that requires being extremely mindful of the clock.
For the cognition timing aspects of the driving task, see my article: https://aitrends.com/selfdrivingcars/cognitive-timing-for-ai-self-driving-cars/
For rear-end collisions and AI self-driving cars, see my analysis: https://aitrends.com/ai-insider/rear-end-collisions-and-ai-self-driving-cars-plus-apple-lexus-incident/
For defensive driving tactics and AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/art-defensive-driving-key-self-driving-car-success/
For how AI developers are designing the AI, see my article: https://aitrends.com/selfdrivingcars/egocentric-design-and-ai-self-driving-cars/
Throwing Hardware At Brute Force Won’t Necessarily Solve Things
You might be tempted to suggest that perhaps we can speed-up the data exploration by adding more processors to the on-board computer systems. It might help, it might not. As mentioned before, parallelization is not an automatic due to just adding more processors. Plus, you need to consider the added cost to the self-driving car, which would be boosted by adding more processors, or faster processors, or adding more memory.
Not only would adding more hardware increase the costs associated with the self-driving car, it would add weight and take up more space in the self-driving car. By adding weight to a self-driving car, you are potentially impacting its overall size and maneuverability. The use of space in the self-driving car would likely reduce available space for other purposes, such as space for the human occupants that would likely be wanting to ride in the self-driving car.
There are other important and time critical aspects of the driving task for the AI.
The AI system is keeping track of a virtual world model. This is a kind of 3D virtual representation of the surroundings of the self-driving car. The AI needs to use this virtual model to try and anticipate what it should do next, and what else might occur next in the surrounding environment. Is that car to your right going to try and get ahead of the self-driving car and barge into the lane of the self-driving car? Is that bicyclist that’s riding in the bike lane going to potentially swerve out of the bike lane and into the path of the self-driving car?
You might think of the analysis of the virtual world model as a game of chess. In chess, you need to consider what your next move consists of. Furthermore, you need to consider what counter-moves might take place after your next move. You can do this for a series of levels of thinking ahead, called ply. How many ply ahead should you look when playing chess? Usually, the more ply, the better your current move will be chosen.
While the AI is driving the self-driving car, it needs to carefully explore the virtual world model. The AI might tentatively decide that a right turn would be prudent at the next corner. But, suppose further examination of the virtual world model reveals that the right corner is blocked with red cones and there is construction work taking place there. This might preclude taking a right turn at the corner. The AI would then need to reassess and figure out what might be the next best move, perhaps waiting to make a right turn later on or perhaps making a series of left turns to get to where it needs to go.
Brute force.
Would it make sense to explore the virtual model on a pure brute force approach? The issue is similar to the points made earlier, namely whether a brute force algorithm could work quickly enough and thoroughly enough to get the job done in time. Likely not.
As a result, it is crucial that these kinds of AI systems be using at least brute reasoning, and more so that they would be using very savvy heuristics. A wide variety of AI techniques are utilized, such as using machine learning, support vector machines, etc.
For more about support vector machines, see my article: https://aitrends.com/selfdrivingcars/support-vector-machines-svm-ai-self-driving-cars/
For aspects of ensemble machine learning, see my article: https://aitrends.com/selfdrivingcars/ensemble-machine-learning-for-ai-self-driving-cars/
For my article about machine learning and AI self-driving cars, see: https://aitrends.com/ai-insider/machine-learning-benchmarks-and-ai-self-driving-cars/
For the freezing robot problems, see my article: https://aitrends.com/selfdrivingcars/freezing-robot-problem-and-ai-self-driving-cars/
Conclusion
At some of my presentations about AI autonomous cars I at times have programmers that seem to wonder why the AI software for a self-driving driverless car is so complex.
For some of these programmers, they think that the programming should be straightforward. I point out that if we could just use simplistic brute force methods, it would reduce the complexity of the software and make getting the software established much easier and faster.
Unfortunately, due to the nature of the driving task, a brute force approach is unlikely to be sufficient. It would tend to not work adequately under the severe time constraints involved in driving a car. For the programmer’s toolkit, having brute force algorithms at the ready is handy, but they should only be used when appropriate. The AI systems for self-driving cars require much more than brute force.
Copyright 2019 Dr. Lance Eliot
This content is originally posted on AI Trends.
[Ed. Note: See Lance Eliot’s piece published on June 18: Cognitive Mental Disorders and AI Ramifications: The Case of AI Autonomous Cars.]