Julia – Dynamic Programming Language for Technical Computing


The Julia language provides a fresh new approach to numerical computing, where there is no longer a compromise between performance and productivity. A high-level language that makes writing natural mathematical code easy, with runtime speeds approaching raw C, Julia has been used to model economic systems at the Federal Reserve, drive autonomous cars at University of California Berkeley, optimize the power grid, calculate solvency requirements for large insurance firms, model the US mortgage markets and map all the stars in the sky.

It would be no surprise then that Julia is a natural fit in many areas of machine learning. ML, and in particular deep learning, drives some of the most demanding numerical computing applications in use today. And the powers of Julia make it a perfect language to implement these algorithms.

TensorFlow – An Open-Source Software Library for Machine Intelligence

TensorFlow was originally developed by researchers and engineers working on the Google Brain team within Google’s Machine Intelligence research organization for the purposes of conducting machine learning and deep neural networks research. The system is general enough to be applicable in a wide variety of other domains, as well.



Performance Decrease When Using Interfaces in .NET

From github on the performance difference of using interfaces vs concrete classes.


Because virtual calls are used when using interfaces, making it so the JIT doesn’t inline them, indexer access time is greatly increased. I was curious just how big the performance decrease was, so I put together a little demo program to try and benchmark this, and the results were worse than I expected:

Times are in milliseconds

18       Array
218      Array as IList
26       List
223      List as IList
19       ArrayWrapper
188      ArrayWrapper as IList

Using an IList resulted in about an order of magnitude longer execution time than not using an IList. I wondered if some of this was due to the extra stuff the CLR does when accessing an Array or List as an IList, so I made a simple wrapper class around an array. This resulted in some improvement, but not much.


…abstractions often have costs. This is part of what makes design hard, because you have to make tradeoffs. We have problems with people going ‘overboard’ both ways. We often have people designing things without any concern for perf, often with really bad consequences. More rarely, we have people who try to optimize ‘everything’ and end up making hard-to-maintain code.

What we really want is to take advantage of a 90%-10% dynamic that typically happens with software. It is typically the case that WELL UNDER 10% of your code in is on high volume (HOT) code paths. Moreover, it is NOT THAT hard to anticipate this. In this code, there is a good chance you need to NOT be as abstract (e.g. using Arrays instead of IList), and think carefully about the APIs (make them chunky, so that they are not called often to do little work). The other 90% of your code you can skew toward all the good software abstractions etc that make the code understandable, reusable and maintainable.

Additional reading on improving performance: https://blogs.msdn.microsoft.com/vancem/2016/05/13/encore-presentation-measure-early-and-often-for-performance/


HTML5 is largely mature enough to start using now with ASP.NET websites.

To start with, get the Web Standards update for Visual Studio 2010 SP1: http://visualstudiogallery.msdn.microsoft.com/a15c3ce9-f58f-42b7-8668-53f6cdc2cd83

The following are a list of things that I do to be compatible with HTML5.

Use the html5 doctype at the top of every page:

<!DOCTYPE html>

Set the lang in the html tag:

<html lang="en">

Declare the character incoding in a meta tag in the head:

<meta charset="utf-8" />

Don’t declare the type or language in script tags:

<script src="/Lib/JavaScript/jquery-1.6.2.min.js"></script>

Don’t declare the type in css links:

<link rel="stylesheet" href="/Lib/Styles/colorbox.css" />

Include this so old versions of IE behave:

<!--[if lt IE 9]>
        <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>

Use <header>, <nav>, <section>, <article> and <footer> tags for the page structure

Get more info at http://diveintohtml5.org/semantics.html

Camera Hack – About page

About pages are mandatory in Windows Phone apps. You may occasionally come across apps that don’t have them because Microsoft was rather loose with the rules when they were first getting the marketplace approval processes worked out. An application must include the application name, version information, and technical support contact information that are easily discoverable. (I think they could have just supplied that info in the marketplace and made it discoverable via long tap on the app icon, but I’m not in charge.) So now, what was once a complete, simple, one page app of single purpose, gets all muddied up with some kind of navigation and another page and extra things you weren’t planning on adding to your app when you started.

And you figure if you’ve got to add a whole other page anyway, it might as well be pretty, and link to the full version (but only if you’re using the trial) and link to the app’s rating page and show a change log and jeez, this is sounding like an entire other app and a lot more testing to do. At this point, rather than reinventing the wheel, we do as all good developers do, and try to find some code. Preferably open source, free to use in commercial software code. And Windows Phone has a wonderful library for just such an occasion. Known as Your Last About Dialog, it’s hosted on Codeplex if you want to check out the source. But the recommended way of getting it into your project is using NuGet.

NuGet side note: If you use Visual Studio and third party libraries, and you don’t know what NuGet is, go make yourself familiar right now. Once it’s installed, you can right-click on your project in Visual Studio and click “Manage NuGet Packages…” and just add all sorts of stuff your project. It will add all the files you need to your project, make any configuration changes you need, and bam! you’re good to go. And if you start using a package and decide it’s just not working out, go back into the package manager and just uninstall. It will clean out all the settings, all the files, put everything back to how it started (except any code you may have written against it, you’ll still have to fix that yourself.)

Once installed via NuGet, you only need to write one line of code…. if you don’t count the actual button or menu item XAML and the code for the actual event. But still, it’s hardly anything.

So, I used an Application Bar Menu Item so my about page link would be out of the way in the hidden part of the AppBar.

	<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">
			<shell:ApplicationBarMenuItem Text="About" Click="AboutMenuItem_Click"/>

And then in the code-behind I have my click event.

private void AboutMenuItem_Click(object sender, EventArgs e)
	NavigationService.Navigate(new Uri("/YourLastAboutDialog;component/AboutPage.xaml", UriKind.Relative));

Everything else is configured and managed by an XML file that magically appeared at \Content\About\Data.xml when the YLAD package was installed. And while I’m sure there is all sorts of extra neat functionality available in the XML file, all I did was enter my name and put my support email information into it. It handled figuring out if the user has the trial version and linking to the marketplace. It handled linking to the review page for users to review the app. It’s easy, it’s quick, it doesn’t require much extra testing. It would probably add less size to my final application file to code it myself, since there are some extra things that it can handle that I probably don’t need, but overall it added less than 60k to my file size, so I believe the ease of use and time savings outweigh that issue.