Stock Market Prediction With Natural Language Machine Learning

May 30, 2018 by Lewin Day 38 Comments

Machines – is there anything they can’t learn? 20 years ago, the answer to that question would be very different. However, with modern processing power and deep learning tools, it seems that computers are getting quite nifty in the brainpower department. In that vein, a research group attempted to use machine learning tools to predict stock market performance, based on publicly available earnings documents.

The team used the Azure Machine Learning Workbench to build their model, one of many tools now out in the marketplace for such work. To train their model, earnings releases were combined with stock price data before and after the announcements were made. Natural language processing was used to interpret the earnings releases, with steps taken to purify the input by removing stop words, punctuation, and other ephemera. The model then attempted to find a relationship between the language content of the releases and the following impact on the stock price.

Particularly interesting were the vocabulary issues the team faced throughout the development process. In many industries, there is a significant amount of jargon – that is, vocabulary that is highly specific to the topic in question. The team decided to work around this, by comparing stocks on an industry-by-industry basis. There’s little reason to be looking at phrases like “blood pressure medication” and “kidney stones” when you’re comparing stocks in the defence electronics industry, after all.

With a model built, the team put it to the test. Stocks were sorted into 3 bins — low performing, middle performing, and high performing. Their most successful result was a 62% chance of predicting a low performing stock, well above the threshold for chance. This suggests that there’s plenty of scope for further improvement in this area. As with anything in the stock market space, expect development in this area to continue at a furious pace.

We’ve seen machine learning do great things before, too – even creative tasks, like naming tomatoes.

VCF East 2018: The Mail Order App Store

May 30, 2018 by Tom Nardi 16 Comments

Today we take the concept of a centralized software repository for granted. Whether it’s apt or the App Store, pretty much every device we use today has a way to pull applications in without the user manually having to search for them on the wilds of the Internet. Not only is this more convenient for the end user, but at least in theory, more secure since you won’t be pulling binaries off of some random website.

But centralized software distribution doesn’t just benefit the user, it can help developers as well. As platforms like Steam have shown, once you lower the bar to the point that all you need to get your software on the marketplace is a good idea, smaller developers get a chance to shine. You don’t need to find a publisher or pay out of pocket to have a bunch of discs pressed, just put your game or program out there and see what happens. Markus “Notch” Persson saw his hobby project Minecraft turn into one of the biggest entertainment franchises in decades, but one has to wonder if it would have ever gotten released commercially if he first had to convince a publisher that somebody would want to play a game about digging holes.

In the days before digital distribution was practical, things were even worse. If you wanted to sell your game or program, it needed to be advertised somewhere, needed to be put on physical media, and it needed to get shipped out to the customer. All this took capital that would easily be beyond many independent developers, to say nothing of single individuals.

But at the recent Vintage Computer Festival East, [Allan Bushman] showed off relics from a little known chapter of early home computing: the Atari Program Exchange (APX). In a wholly unique approach to software distribution at the time, individuals were given a platform by which their software would be advertised and sold to owners of 8-bit machines such as the Atari 400/800 and later XL series computers. In the early days, when the line between computer user and computer programmer was especially blurry, the APX let anyone with the skill turn their ideas into profit. Continue reading “VCF East 2018: The Mail Order App Store” →

Using TensorFlow To Recognize Your Own Objects

May 23, 2018 by Steven Dufresne 9 Comments

When the time comes to add an object recognizer to your hack, all you need do is choose from many of the available ones and retrain it for your particular objects of interest. To help with that, [Edje Electronics] has put together a step-by-step guide to using TensorFlow to retrain Google’s Inception object recognizer. He does it for Windows 10 since there’s already plenty of documentation out there for Linux OSes.

You’re not limited to just Inception though. Inception is one of a few which are very accurate but it can take a few seconds to process each image and so is more suited to a fast laptop or desktop machine. MobileNet is an example of one which is less accurate but recognizes faster and so is better for a Raspberry Pi or mobile phone.

You’ll need a few hundred images of your objects. These can either be scraped from an online source like Google’s images or you get take your own photos. If you use the latter approach, make sure to shoot from various angles, rotations, and with different lighting conditions. Fill your background with various other things and even have some things partially obscuring your objects. This may sound like a long, tedious task, but it can be done efficiently. [Edje Electronics] is working on recognizing playing cards so he first sprinkled them around his living room, added some clutter, and walked around, taking pictures using his phone. Once uploaded, some easy-to-use software helped him to label them all in around an hour. Note that he trained on 24 different objects, which are the number of different cards you get in a pinochle deck.

You’ll need to install a lot of software and do some configuration, but he walks you through that too. Ideally, you’d use a computer with a GPU but that’s optional, the difference being between three or twenty-four hours of training. Be sure to both watch his video below and follow the steps on his Github page. The Github page is kept most up-to-date but his video does a more thorough job of walking you through using the software, such as how to use the image labeling program.

Why is he training an object recognizer on playing cards? This is just one more step in making a blackjack playing robot. Previously he’d done an impressive job using OpenCV, even though the algorithm handled non-overlapping cards only. Google’s Inception, however, recognizes partially obscured cards. This is a very interesting project, one which we’ll be keeping an eye on. If you have any ideas for him, leave them in the comments below.

Continue reading “Using TensorFlow To Recognize Your Own Objects” →

Machine Learning Crash Course From Google

May 22, 2018 by Al Williams 9 Comments

We’ve been talking a lot about machine learning lately. People are using it for speech generation and recognition, computer vision, and even classifying radio signals. If you’ve yet to climb the learning curve, you might be interested in a new free class from Google using TensorFlow.

Of course, we’ve covered tutorials for TensorFlow before, but this is structured as a 15 hour class with 25 lessons and 40 exercises. Of course, it is also from the horse’s mouth, so to speak. Google says the class will answer questions like:

How does machine learning differ from traditional programming?
What is loss, and how do I measure it?
How does gradient descent work?
How do I determine whether my model is effective?
How do I represent my data so that a program can learn from it?
How do I build a deep neural network?

Continue reading “Machine Learning Crash Course From Google” →

Tiny Sideways Tetris On A Business Card

May 20, 2018 by Donald Papp 15 Comments

Everyone recognizes Tetris, even when it’s tiny Tetris played sideways on a business card. [Michael Teeuw] designed these PCBs and they sport small OLED screens to display contact info. The Tetris game is actually a hidden easter egg; a long press on one of the buttons starts it up.

It turns out that getting a playable Tetris onto the ATtiny85 microcontroller was a challenge. Drawing lines and shapes is easy with resources like TinyOLED or Adafruit’s SSD1306 library, but to draw those realtime graphics onto the 128×32 OLED using that method requires a buffer size that wouldn’t fit the ATtiny85’s available RAM.

To solve this problem, [Michael] avoids the need for a screen buffer by calculating the data to be written to the OLED on the fly. In addition, the fact that the smallest possible element is a 4×4 pixel square reduces the overall memory needed to track the screen contents. As a result, the usual required chunk of memory to use as a screen buffer is avoided. [Michael] also detailed the PCB design and board assembly phases for those of you interested in the process of putting together the cards using a combination of hot air reflow and hand soldering.

PCB business cards showcase all kinds of cleverness. The Magic 8-Ball Business Card is refreshingly concise, and the project that became the Arduboy had milled cutouts to better fit components, keeping everything super slim.

MSDOS Development With GCC

May 14, 2018 by Al Williams 19 Comments

It might seem odd to think about programming in MSDOS in 2018. But if you are vintage computer enthusiast or have to support some old piece of equipment with an MSDOS single board computer, it could be just the thing. The problem is, where do you get a working compiler that doesn’t have to run on the ancient DOS machine? Turns out, gcc can do the trick. [RenéRebe] offers a video demo based on a blog post by [Chris Wellons]. You can see the video, below.

The technique generates COM files, not EXE files, so there are some limitations, such as a 64K file size. The compiler also won’t generate code for any CPU lower than a 80386, so if you have a real 8086, 80186, or 80286 CPU, you are out of luck. The resulting code will run in a real DOS environment on a ‘386 or higher or in a simulator like DOSBox.

You might be thinking why not use the DJGPP port of gcc to DOS. That sounds good, but it actually doesn’t produce true DOS code. It produces code for a DOS extender. In addition, [Chris] had trouble getting it to work with a modern setup.

The only real trick here is using the right combination of gcc flags to create a standalone image with the right codes. A COM file is just a dump of memory, so you don’t need a fancy header or anything. You also, of course, won’t have any library support, so you’ll have to write everything including functions to, say, print on the screen. Of course, you can borrow [Chris’] if you like.

The last pieces of the puzzle include adding a small stub to set up and call main and getting the linker to output a minimal file. Once you have that, you are ready to program like it is 1993. Don’t miss part 2, which covers interrupts.

If you pine away for QuickBasic instead of C, go download this. If you just want to run some old DOS games, that’s as close as your browser.

Continue reading “MSDOS Development With GCC” →

Push It To The Limit: SSD1306 At 150 FPS

May 8, 2018 by Tom Nardi 38 Comments

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Larry Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Larry] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Larry] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.