Micah J Waldstein

The DartCannon Technology Stack

Thu, 09 Aug 2018 00:00:00 +0000

Today we want to pull back the curtain on how we built DartCannon and share our appreciation on all the projects that have helped us get here.

The Core

The foundational piece of DartCannon is our custom-build proprietary Monte Carlo simulation engine, Thompson. Under development in some form for over 8 years, Thompson is what enables us to iterate quickly and provide such high quality simulations at an affordable price point. Over the development of DartCannon every other piece of technology has been swapped out for alternatives and likely will be again, but Thompson has been the constant we’ve built around.

Power Players

With Thompson powering the core of DartCannon, these are the components which drive the main user experience.

Firebase - Our database and authentication, firebase allows us to not worry about servers or infrastructure.
Stripe - For payments and subscriptions, stripe means we can be confident that security is all taken care of.
Vue - There are a lot of javascript frameworks, Vue happens to be the one our team knew and was comfortable using to build DartCannon.
Vuetify - Vuetify is a fantastic material design framework for Vue.

Supporting Roles

While not as central as our Power Players, these pieces all play important parts driving very specific features.

Chartjs - Powers all the pretty confidence intervals
Dagre - Enables process diagrams for projects
exceljs - The underlying tech for our excel import / export.

Extras

In addition to these components, we have a huge pile of additional pieces we depend on for testing, error handling, screen shots, and more. They are too numerous and detailed for this overview, but we owe them a lot.

Thanks

DartCannon would not exist without the rich open source ecosystem and we are deeply indebted to all of the projects mentioned here.

Photo by Chris Yang Unsplash

R Directional 3.3 Package is Out

Wed, 08 Aug 2018 00:00:00 +0000

A few weeks late, but worth calling out that Directional 3.3 is out on CRAN. I had a small contribution which came out of my investigations into spherical densities.

I modified the respective posts to use the native Directional vmf.kerncontour rather than the previously unreleased modification I made to return the data.

Thanks to maintainer Michail Tsagris for accepting the patch and all his help.

DartCannon: Week In Review 7/13/2018

Fri, 13 Jul 2018 00:00:00 +0000

Every week on DartCannon we give a rundown on the week including what we’ve written, are reading, and major imporvements. I won’t cross-post all of them, but will put them up every so often.

Happy Friday! Here’s a rundown of this week in DartCannon

What We Wrote

Accepting an Estimate - DartCannon is about creating simulations of complex business problems, but once the simulation is done the work of getting buy in starts. We shared some pointers of how to approach those conversations and potential pitfalls to look out for.
The Curse of Parallel Tasks - It is so easy for our intuition to lead us astray as problems get complex. Here we show how you can be fooled even in the simple case of tasks with equal estimates performed in parallel.

What We’ve Been Reading

If you only know one thing about Risk Management… (J. Goodpasture, Musings on project management) John is always good at bringing complex ideas back to fundamentals. Evidentially coupling of projects is on everyone’s mind, as we wrote about parallel tasks, John wrote about the importance of schedule slack where it is unavoidable.
Real-world Monte Carlo analysis (Cook, M. S., Paper presented at Project Management Institute Annual Seminars & Symposium, Nashville, TN) It likely comes as no surprise that we’re slightly geeky around here, so no one should be shocked that we read this conference paper from 2001. Great if you’re looking for a more rigorous review of the application of monte-carlo analysis, the simulation method underlying DartCannon.

DartCannon Change Spotlight

We are constantly continuing to improve DartCannon and while the majority of changes are too small to call out, we want to highlight larger improvements.

Excel Import Enhancements

In addition to overall performance improvements to XLSX import and export, we’ve added some smarts to the import process. Now, DartCannon will automatically attempt to identify which sheet contains your items and risks AND try to identify what each column represents.

Excel import/export is a Pro feature, so you need to subscribe to take advantage.

An end-of-week quote:

A goal without a plan is just a wish - Antoine de Saint-Exupéry

Hope everyone has a great weekend!

See something you think we’d like to share? Send an email to weekly@dartcannon.com or connect on twitter, @dartcannon

edgarWebR 1.0

Tue, 03 Jul 2018 00:00:00 +0000

I recently realized that edgarWebR 1.0 was released a while ago without much fanfare. 1.0 is a major milestone for the library, bringing the full set of (initial) planned functionality along with some bonus features.

Headline features:

100% coverage of SEC search tools.
Parsing of submissions into component files and 10-x filings into items and parts.
A dataset of SIC mappings

What’s Next:

Bugfixes - corner cases keep popping up that need fixing
Parsing Improvements - I have some ideas about table handling that will help anyone interested in getting data out of older filings

EDGAR Tools

The EDGAR System provides a number of tools for filing and entity lookup and examination. As of v1.0, edgarWebR supports all public search and browse interfaces.

Search Interfaces

Tool	URL	edgarWebR function(s)
Company	https://www.sec.gov/edgar/searchedgar/companysearch.html	`company_search()`, `company_information()`, `company_details()`, `company_filings()`
Recent Filings	https://www.sec.gov/cgi-bin/browse-edgar?action=getcurrent	`latest_filings()`
Full Text	http://searchwww.sec.gov/EDGARFSClient/jsp/EDGAR_MainAccess.jsp	`full_text()`
Header Search	https://www.sec.gov/cgi-bin/srch-edgar	`header_search()`
Fund Disclosures	https://www.sec.gov/edgar/searchedgar/prospectus.htm	Use `company_search()` and specify the ‘type’ parameter as 485
Fund Voting Records	https://www.sec.gov/edgar/searchedgar/n-px.htm	Use `company_search()` and specify the ‘type’ parameter as ‘N-PX’
Fund Search	https://www.sec.gov/edgar/searchedgar/mutualsearch.html	`fund_search()`, `fund_fast_search()`
Var. Insurance Products	https://www.sec.gov/edgar/searchedgar/vinsurancesearch.html	`variable_insurance_search()`, `variable_insurance_fast_search()`
Confidential treatment orders	https://www.sec.gov/edgar/searchedgar/ctorders.htm	Use `header_search()`, `company_search()`, `latest_filings()`, or `full_text()` and use form types ‘CT ORDER’
Effectiveness notices	https://www.sec.gov/cgi-bin/browse-edgar?action=geteffect	`effectiveness()`
CIK	https://www.sec.gov/edgar/searchedgar/cik.htm	`cik_search()`
Daily Filings	https://www.sec.gov/edgar/searchedgar/currentevents.htm	`current_events()`
Correspondence	https://www.sec.gov/answers/edgarletters.htm	Use `header_search()`, `company_search()`, `latest_filings()`, or `full_text()` and use form types ‘upload’ or ‘corresp’

Once a filing is found via any of the above, there are a number of functions to process the result -

filing_documents()
filing_filers()
filing_funds()
filing_information()
filing_details() - returns all 4 of the filing components in a list.

Parsing Tools

While edgarWebR is primarily focused on providing an interface to the online SEC tools, there are a few activities for handling filing documents for which no current tools exist.

parse_submission() - takes a full submission SGML document and parses out component documents. Most of the time, the documents of interest in a particular submission will be online and accessible via filing_documents() - this function is to unpack the raw submission to get all the documents. You may also find it more efficient if you’re regularly downloading all of the files in a given submission.
parse_filing() - Takes a HTML narrative filing and annotates each paragraph with item and part numbers.

Data Sets

There is one dataset provided with edgarWebR, sic_codes, providing a catalog of SIC codes and their hierarchy.

URL Tools

There are also a number of utility functions to help construct useful URL’s once you have a company CIK, submission accession number or specific file.

company_href() for linking to the company page
submission_index_href() and its family of related functions for linking to a specific submission and file.

Installation

edgarWebR is available from CRAN, so can be simply installed via

install.packages("edgarWebR")

To install the development version,

# Install the development version from GitHub:
# install.packages("devtools")
devtools::install_github("mwaldstein/edgarWebR")

Contributing

If you’ve found this package helpful, contributions are always appreciated at the page on github:

Bug Reports
Code improvements
Documentation

I’m also always excited to hear about how the package is being used. If this package has helped you in any way, drop me a note!

Heatmaps of Spherical Densities in R

Fri, 15 Jun 2018 21:13:14 -0500

Last time we made contour maps of densities of points on a globe, now it is time to take another step and make heatmaps. We created all the data we needed when creating the contours, but heatmaps add new challenges of dealing with large amounts of raster and polygon data. Lets get to it.

DISCLAIMER: While I know a thing or two, there’s a reasonable chance I got some things wrong or at very least there are certainly more efficient ways to go about things. Feedback always appreciated!

NOTE: This has been updated to use the native vmf.kerncontour since the release of Directional 3.3 supports returning results

Set-Up

First, we’ll make use of a number of libraries and setup our plotting environment:

library(rgdal)       # For coordinate transforms
library(sp)          # For plotting grid images
library(sf)
library(lwgeom)
library(Directional) # For spherical density functions
library(spData)      # worldmap
library(raster)
library(magick)      # for animating
par(bg = NA)

We’ll also use the same vmf_density_grid function we introduced in the Intro post.

vmf_density_grid <- function(u, ngrid = 100) {
  # Translate to (0,180) and (0,360)
  u[,1] <- u[,1] + 90
  u[,2] <- u[,2] + 180
  res <- vmf.kerncontour(u, thumb = "none", den.ret = T, full = T,
                             ngrid = ngrid)

  # Translate back to (-90, 90) and (-180, 180) and create a grid of
  # coordinates
  ret <- expand.grid(Lat = res$lat - 90, Long = res$long - 180)
  ret$Density <- c(res$den)
  ret
}

Global Earthquakes Again

Global Earthquakes from Northern California Earthquake Data Center is a great dataset we’ll continue to use, so we start with a set of quakes since Jan 1, 1950 of magnitude 5.9 or higher.

For all our heatmaps, we’ll start the same as we did for contours, calculating the density map:

grid.size = 100
earthquakes <- read.csv(file.path("..", "data", "earthquakes.csv"))
earthquake.densities <- vmf_density_grid(earthquakes[,c("Latitude",
                                                        "Longitude")],
                                         ngrid = grid.size)

Once we have the densities, we need to coerce them into a spatial format - in this case we’ll create a SpatialGridDataFrame, matching the grid of densities we calculated with vmf_density_grid.

density_matrix <- matrix(earthquake.densities$Density, nrow = grid.size)
density_matrix <- t(apply(density_matrix, 2, rev))
gridVals <- data.frame(att=as.vector(density_matrix))
gt <- GridTopology(cellcentre.offset = c(-180 + 180 / grid.size,
                                         -90 + 90 / grid.size),
                   cellsize = c( 360 / grid.size, 180 / grid.size),
                   cells.dim = c(grid.size, grid.size))
sGDF <- SpatialGridDataFrame(gt,
                             data = gridVals,
                             proj = "+proj=longlat +datum=WGS84 +no_defs")

plot(sGDF)
plot(gridlines(sGDF), add = TRUE, col = "grey30", alpha = .1)
plot(st_geometry(world), add = TRUE, col = NA, border = "grey")

Great, we have a heatmap! But it is in rectangular coordinates, we want to project it to something nicer, like a Winkel triple. There’s a problem though… We can’t just re-project our SpatialGridDataFrame - it gets interpolated into points, losing our nice pretty smooth heatmap.

There are two real options for us:

Convert to raster data, then project the raster
Convert to raster, convert to polygons, project the polygons

Projecting Raster Data

This is really slow, so we have to turn the resolution way down.

r <- raster(sGDF)
crs1 <- "+proj=wintri"
world.crs1 <- st_transform_proj(world, crs = crs1)

pr1 <- projectExtent(r, crs1)
res(pr1) <- 9e5
pr2 <- projectRaster(r, pr1, method = "bilinear", over = TRUE)
plot(pr2)
plot(st_geometry(world.crs1), add = TRUE, col = NA, border = "grey")

I guess this works, but the low resolution suggests we can do better.

Using Polygons

We’ll use raster data again, but we’ll immediately convert it into a grid of square polygons which we can then project

r2 <- raster(sGDF)
# We'll manually colorize
r2 <- cut(r2,
          pretty(r2[], 50),
          include.lowest = F)
color.vals <- rev(terrain.colors(50))
pol <- rasterToPolygons(r2)
crs1 <- "+proj=wintri"
world.crs1 <- st_transform_proj(world, crs = crs1)
pol.crs1 <- spTransform(pol, crs1)
par(mar = c(0, 0, 0, 0))
plot(pol.crs1, col=color.vals[r2[]], border = NA)
# plot(gridlines(sgdf.crs1), add = TRUE, col = "grey30", alpha = .1)
plot(st_geometry(world.crs1), add = TRUE, col = NA, border = "grey")

Now that looks good!

One thing to keep in mind however - because our polygons are rectangular in equal coordinates, they will warp and distort as a projection gets more severe. In our animation, you can see what I mean

Animating

We’re projecting into an orthographic projection to simulate the rotating globe. A few things you’ll see in the code where I jump through hoops:

Cropping the top - If I leave the top polygons in place, they bunch up in an ugly fashion
Making features valid - Both for the world and our heatmap polygons I jump through hoops to make sure only valid polygons get through to the final plot.

r3 <- raster(sGDF)

# Crop down because projecting the poles causes problems
r.crop <- res(r3)
rc <- crop(r3, extent(-180, 180,
                      -90 + r.crop[2], 90 - r.crop[2]))
pol <- rasterToPolygons(rc)
pol.breaks <- pretty(pol$att, 20)
pol.colors <- rev(terrain.colors(length(pol.breaks) - 1))
# Make the lowest color transparent
substr(pol.colors[1], 8, 9) <- "00"

n.frames <- 30
img <- image_graph(400, 400, res = 96)
par(mar = c(0, 0, 0, 0))
grad <- st_graticule(ndiscr = 1e4)
for (i in 1:n.frames) {
  long <- -180 + (i - 1) * 360 / n.frames
  crs.ani <- paste0("+proj=ortho +lat_0=0 +lon_0=", long)
  grad.ani <- st_geometry(st_transform(grad, crs.ani))

  world.ani <- st_transform(st_geometry(world), crs = crs.ani)

  # For some reason this stopped working,
  # Not including results in more countries not rendering properly
  # world.ani <- lwgeom::st_make_valid(world.ani)

  # We don't want the points
  world.ani <- world.ani[st_geometry_type(world.ani) %in% c('POLYGON',
                                                            'MULTIPOLYGON')]

  # There are inevitable some bad polygons out of the transform
  world.ani <- world.ani[st_is_valid(world.ani)]

  pol.ani <- st_transform(as(pol, "sf"), crs.ani)
  pol.ani.geo <- lwgeom::st_make_valid(pol.ani)
  pol.ani.geo <- pol.ani.geo[st_geometry_type(pol.ani.geo) %in% c('POLYGON',
                                                                  'MULTIPOLYGON',
                                                                  'GEOMETRYCOLLECTION'), ]
  pol.ani.geo <- pol.ani.geo[st_is_valid(pol.ani.geo), ]
  pol.ani.geo <- pol.ani.geo[!st_is_empty(pol.ani.geo), ]

  plot(grad.ani, col = "black")
  plot(world.ani, add = TRUE, col = "grey30", border = "grey")
  plot(pol.ani.geo, border = NA, breaks = pol.breaks, pal = pol.colors,
       add = TRUE, main = NA, key.pos = NULL)
}
msg <- dev.off()
image_animate(img, fps = 10)

Looks pretty good, but we do have some interesting world map problems with countries popping out as they reach the edge… Something to investigate another day.

Final Notes

In both these examples we’ve used global data as it shows the problems of using “traditional” density estimators, but the same issue exists at all scales. It is just a question of when a simpler approximation is reasonable.

You can also see a bit of blockiness which we could reduce with an increase in grid size, but that will be very dependent on need.

Next, some real data…

If you want to explore the code yourself, everything is on github here.

Appendix

Spherical Density Function

This calculates a grid of densities which can then be used with geom_contour. The code basically comes directly from Directional’s vmf.kerncontour, only returning a data.frame instead of actually plotting the output.

vmf.kerncontour.new <- function(u, thumb = "none", ret.all = FALSE, full = FALSE,
                            ngrid = 100) {
  ## u contains the data in latitude and longitude
  ## the first column is the latitude and the
  ## second column is the longitude
  ## thumb is either 'none' (default), or 'rot' (Garcia-Portugues, 2013)
  ## ret.all if set to TRUE returns a matrix with latitude, longitude and density
  ## full if set to TRUE calculates densities for the full sphere, otherwise
  ##   using extents of the data
  ## ngrid specifies the number of points taken at each axis
  n <- dim(u)[1]  ## sample size
  x <- euclid(u)

  if (thumb == "none") {
    h <- as.numeric( vmfkde.tune(x, low = 0.1, up = 1)[1] )
  } else if (thumb == "rot") {
    k <- vmf(x)$kappa
    h <- ( (8 * sinh(k)^2) / (k * n * ( (1 + 4 * k^2) * sinh(2 * k) -
    2 * k * cosh(2 * k)) ) ) ^ ( 1/6 )
  }

  if (full) {
    x1 <- seq( 0, 180, length = ngrid )  ## latitude
    x2 <- seq( 0, 360, length = ngrid )  ## longitude
  } else {
    x1 <- seq( min(u[, 1]) - 5, max(u[, 1]) + 5, length = ngrid )  ## latitude
    x2 <- seq( min(u[, 2]) - 5, max(u[, 2]) + 5, length = ngrid )  ## longitude
  }
  cpk <- 1 / (  ( h^2)^0.5 *(2 * pi)^1.5 * besselI(1/h^2, 0.5) )
  mat <- matrix(nrow = ngrid, ncol = ngrid)

  for (i in 1:ngrid) {
    for (j in 1:ngrid) {
      y <- euclid( c(x1[i], x2[j]) )
      a <- as.vector( tcrossprod(x, y / h^2) )
      can <- sum( exp(a + log(cpk)) ) / ngrid
      if (abs(can) < Inf)   mat[i, j] <- can
    }
  }

  if (ret.all) {
    return(list(Lat = x1, Long = x2, h = h, d = mat))
  } else {
    contour(mat$Lat, mat$Long, mat, nlevels = 10, col = 2, xlab = "Latitude",
            ylab = "Longitude")
    points(u[, 1], u[, 2])
  }
}

References

Earthquake data was accessed through the Northern California Earthquake Data Center (NCEDC), doi:10.7932/NCEDC.

Introduction to Spherical Densities in R

Sun, 10 Jun 2018 21:13:14 -0500

It always happens… I get interested in what I think will be a small data project to scratch some itch and end up down a deep rabbit hole. In this case, a passing interest in the geographic distribution of some samples (more on that in a future post) led to a deep dive into spherical distributions and densities.

NOTE: This has been updated to use the native vmf.kerncontour since the release of Directional 3.3 supports returning results

Motivation

While I got interested in figuring out densities for the purpose of figuring out the density of points on a map, there are plenty of other cases where you might be interested in the distribution of points on a sphere. The trouble is that most functions commonly available, e.g. geom_density_2d from ggplot2, only handles regular grid coordinates.

The forms:

Global densities simply fail at the ‘edge’ of coordinates - e.g. near the poles or near +/- 180 degrees longitude.
Projection issues. On small scales and near the equator, it is generally safe to make the simplification that longitude/latitude forms a square grid. As you look to larger scales and close to the poles, that assumption breaks down.

I think it is important to point out that there are many tutorials on plotting event densities on maps (e.g. crime occurrences), but that these are all at the city level, where the problems of using existing methods is a reasonable approximation.

Set-Up

First, we’ll make use of a number of libraries and setup our plotting environment:

library(ggplot2)     # For most of our plotting
library(cowplot)     # grid arrangement of plots
library(Directional) # For spherical density functions
library(maps)        # vector maps of the world
library(hrbrthemes)  # hrbrmstr themes
library(magick)      # For animation
library(mapproj)     # Needed for projection

# And set some theme defaults
theme_set(theme_ipsum())
# Axis settings we'll reuse a lot
no.axis <- theme(axis.ticks.y = element_blank(), axis.text.y = element_blank(),
                 axis.ticks.x = element_blank(), axis.text.x = element_blank(),
                 axis.title.x = element_blank(), axis.title.y = element_blank())

Next, for this example, we’ll be using a random blob placed on a sphere. I’ll use the rvmf function from the Directional package. Directional is a general purpose library using Latitude defined from 0 to 180 degrees and Longitude from 0 to 360 instead of -90 to 90 and -180 to 180 respectively. The random_points function here gives us points in a coordinate system we’re used to.

random_points <- function(n_points, lat, lon, concentration) {
  # Directional defines lat + long as 0-180 and 0-360 respectively so we
  # have to shift back and forth
  mu <- euclid(c(lat + 90, lon + 180))[1,]
  pts <- euclid.inv(rvmf(n_points, mu, concentration))
  pts[,1] <- pts[,1] - 90
  pts[,2] <- pts[,2] - 180
  data.frame(pts)
}

Problem

To visualize the problem, we’ll create 2 sets of points, one centered on the map, the other near the pole and near 180 degrees. We’ll then plot the contours of the densities to show the issue.

offset.pos <- list(Lat = 75, Long = 175)
positions.center <- random_points(1000, 0, 0, 10)
positions.offset <- random_points(1000, offset.pos$Lat, offset.pos$Long, 10)
plot.colors <- hcl(h = c(0:3)*90, c = 50 , l = 70)
g.base <- ggplot(positions.center, aes(x = Long, y = Lat)) +
          scale_y_continuous(breaks = (-2:2) * 30, limits = c(-90, 90)) +
          scale_x_continuous(breaks = (-4:4) * 45, limits = c(-180, 180)) +
          coord_map()

g.broken <- g.base +
     # The centered random points
     geom_density_2d(color = plot.colors[1]) +
     geom_point(size = 0.5, stroke = 0, color = plot.colors[1]) +
     # The offset random points
     geom_density_2d(data = positions.offset, color = plot.colors[2]) +
     geom_point(data = positions.offset, size = 0.5, stroke = 0,
                color = plot.colors[2])

ortho.projections <- plot_grid(
  g.broken + coord_map("ortho", orientation = c(0, 0, 0)) + no.axis,
  g.broken + coord_map("ortho", orientation = c(offset.pos$Lat, offset.pos$Long, 0))
           + no.axis,
  labels = NULL,
  align = 'h')
g.broken
ortho.projections

We can quickly see the problem looking at the blue offset density plot - there are multiple “centers” and the contours don’t connect cleanly.

Spherical Densities

The solution is to use spherical densities an fortunately, the Directional package provides functions for spherical (and in fact, circular and spheres of arbitrary dimensions) distributions using the von Mises-Fisher distribution.

Our basic approach will be the following steps:

Calculate a “grid” of densities manually, covering the entire globe
Use geom_contour to turn those density maps into contour curves
Plot away!

Before we fix the problem using spherical densities, we first need to do some setup. We’ll be using vmf.kerncontour from the Directional library, but in current CRAN version (3.2), that function plots contours itself. We want to get the data to perform the plots ourselves, so we need a version that returns the data. The next version of the package will have that option, but in the meantime we put the code for the revised function in the Appendix as vmf.kerncontour.new.

Similar to what we did for random_points, we also need to perform some translation of vmf.kerncontour’s input and output to out more familiar formats.

vmf_density_grid <- function(u, ngrid = 100) {
  # Translate to (0,180) and (0,360)
  u[,1] <- u[,1] + 90
  u[,2] <- u[,2] + 180
  res <- vmf.kerncontour(u, thumb = "none", den.ret = T, full = T,
                             ngrid = ngrid)

  # Translate back to (-90, 90) and (-180, 180) and create a grid of
  # coordinates
  ret <- expand.grid(Lat = res$lat - 90, Long = res$long - 180)
  ret$Density <- c(res$den)
  ret
}

Now we can go ahead and calculate the densities and plot the contours. We’ll keep the “bad” contours for comparison.

densities.center <- vmf_density_grid(positions.center)
densities.offset <- vmf_density_grid(positions.offset)

g.broken <- g.base +
     geom_density_2d(color = plot.colors[1], alpha = .5) +
     geom_point(size = 0.5, stroke = 0, color = plot.colors[1], alpha = .5) +
     geom_density_2d(data = positions.offset, color = plot.colors[2], alpha = .5) +
     geom_point(data = positions.offset, size = 0.5, stroke = 0, color =
                plot.colors[2], alpha = .5)

g.densities <- g.broken +
  geom_contour(data = densities.center,
               aes(x=Long, y=Lat, z=Density),
               color = plot.colors[3]) +
  geom_contour(data = densities.offset,
               aes(x=Long, y=Lat, z=Density),
               color = plot.colors[4])

ortho.projections <- plot_grid(
  g.densities + coord_map("ortho", orientation = c(0, 0, 0)) + no.axis,
  g.densities + coord_map("ortho",
                          orientation = c(offset.pos$Lat, offset.pos$Long, 0))
              + no.axis,
  labels = NULL,
  align = 'h')
g.densities
ortho.projections

Particularly looking at the orthographic plots, it is easy to see that the spherical density process gives the same rings in both locations, with continuous curves.

Practical Example: Global Earthquakes

Earthquake density is used in one of the few existing attempts to perform density calculations with spherical coordiates on R-Bloggers. The Northern California Earthquake Data Center provides an archive of earthquakes for download, so we start with a set of quakes since Jan 1, 1950 of magnitude 5.9 or higher. Given that data, we then follow the same process as we did with our random data to plot both the 2d density contours and the density contours using spherical functions.

earthquakes <- read.csv(file.path("..", "data", "earthquakes.csv"))
earthquake.densities <- vmf_density_grid(earthquakes[,c("Latitude",
                                                        "Longitude")],
                                         ngrid = 300)

world <- map_data("world")
g.earthquakes <- ggplot() +
  geom_map(data = world, map = world,
           mapping = aes(map_id = region),
           color = "grey90", fill = "grey80") +
  geom_point(data = earthquakes,
             mapping = aes(x = Longitude, y = Latitude),
             color = "red", alpha = .2, size = .5, stroke = 0) +
  geom_density_2d(data = earthquakes,
                  aes(x=Longitude, y=Latitude),
                  color = plot.colors[2], alpha = 1) +
  geom_contour(data = earthquake.densities, aes(x=Long, y=Lat, z=Density),
               color = plot.colors[4]) +
  scale_y_continuous(breaks = (-2:2) * 30, limits = c(-90, 90)) +
  scale_x_continuous(breaks = (-4:4) * 45, limits = c(-180, 180)) +
  coord_map("mercator")

g.earthquakes

n.frames <- 40
img <- image_graph(400, 400, res = 96)
for (i in 1:n.frames) {
  long <- 170 + (i - 1) * 360 / n.frames
  # We Explicitly use the 'plot' command to show the ggplot
  print(g.earthquakes + coord_map("ortho", orientation = c(0, long, 0)) + no.axis)
}
msg <- dev.off()
image_animate(img, fps = 10)

The yellow shows default 2d density, and you can again see the continuity problems. The blue shows the expected Ring of Fire thanks to the spherical density. It isn’t perfect - if we were really interested in the most accurate results, we’d probably want to turn up the grid size to better follow the chains of quakes or tweak the contour breakpoints to see the fine features.

This should be a good first step to looking at densities in geo events.

While this should have given a good introduction to densities on a sphere and the issues with using the default density functions, there is still more we can do. We’ve got a few more posts coming:

Heatmaps - Working with heatmaps means generating raster data and projections with raster data adds more complexity
More Real Examples - I mentioned I had an actual project I was curious about, right?

If you want to explore the code yourself, everything is on github here.

Appendix

Spherical Density Function

vmf.kerncontour.new <- function(u, thumb = "none", ret.all = FALSE, full = FALSE,
                            ngrid = 100) {
  ## u contains the data in latitude and longitude
  ## the first column is the latitude and the
  ## second column is the longitude
  ## thumb is either 'none' (default), or 'rot' (Garcia-Portugues, 2013)
  ## ret.all if set to TRUE returns a matrix with latitude, longitude and density
  ## full if set to TRUE calculates densities for the full sphere, otherwise
  ##   using extents of the data
  ## ngrid specifies the number of points taken at each axis
  n <- dim(u)[1]  ## sample size
  x <- euclid(u)

  if (thumb == "none") {
    h <- as.numeric( vmfkde.tune(x, low = 0.1, up = 1)[1] )
  } else if (thumb == "rot") {
    k <- vmf(x)$kappa
    h <- ( (8 * sinh(k)^2) / (k * n * ( (1 + 4 * k^2) * sinh(2 * k) -
    2 * k * cosh(2 * k)) ) ) ^ ( 1/6 )
  }

  if (full) {
    x1 <- seq( 0, 180, length = ngrid )  ## latitude
    x2 <- seq( 0, 360, length = ngrid )  ## longitude
  } else {
    x1 <- seq( min(u[, 1]) - 5, max(u[, 1]) + 5, length = ngrid )  ## latitude
    x2 <- seq( min(u[, 2]) - 5, max(u[, 2]) + 5, length = ngrid )  ## longitude
  }
  cpk <- 1 / (  ( h^2)^0.5 *(2 * pi)^1.5 * besselI(1/h^2, 0.5) )
  mat <- matrix(nrow = ngrid, ncol = ngrid)

  for (i in 1:ngrid) {
    for (j in 1:ngrid) {
      y <- euclid( c(x1[i], x2[j]) )
      a <- as.vector( tcrossprod(x, y / h^2) )
      can <- sum( exp(a + log(cpk)) ) / ngrid
      if (abs(can) < Inf)   mat[i, j] <- can
    }
  }

  if (ret.all) {
    return(list(Lat = x1, Long = x2, h = h, d = mat))
  } else {
    contour(mat$Lat, mat$Long, mat, nlevels = 10, col = 2, xlab = "Latitude",
            ylab = "Longitude")
    points(u[, 1], u[, 2])
  }
}

References

Earthquake data was accessed through the Northern California Earthquake Data Center (NCEDC), doi:10.7932/NCEDC.

DartCannon: Estimating at the grocery store

Mon, 28 May 2018 01:57:44 +0000

To understand probability in forecasting, we can take a trip to the grocery store.

What We’re Going To Do

Demonstrate Estimation by shopping for produce
Look at reducing uncertainty
Explain reducible vs irreducible uncertainty

The Basic Scenario

Lets say we’re going to shop for ingredients for a fruit salad consisting of 2 apples, 1 banana and some grapes.

Without going any further, you probably can make a reasonable guess about how much things will cost. I’d say we’d spend roughly the following:

Apples: Between $2 and $4, but most likely $2.50
Bananas: $1 – $2, most likely $1.50
Grapes: $2.50 – $4.00, most likely $3.00

Plus, at my store apples are on sale ~20% of the time which could take between .25 an .75 off. We can plug these estimates into DartCannon giving us the following model:

We can plus these numbers into DartCannon to get the following distribution:

One thing DartCannon does for us immediately which might not have been obvious otherwise is while our full range of estimates are between $4.75 and $10, a range of $5.25, the 90% range is only $2.

Reducing uncertainty

For some projects this level of estimation is good enough to make decisions, but perhaps we need more accuracy. For our grocery example, instead of relying on our existing feelings about prices and the historic chance of a sale, we could look up current prices and sales. Also finding average weights of the fruits.

While finding current prices would reduce much of the uncertainty, while fruit (at least where we’re based) is priced by weight, it is sold by unit. Since no piece of fruit is exactly the same weight, if we need 2 apples we can’t say precisely how much that will weigh, so we still have some uncertainty.

Lets say we went through this process

Apples: Between $2.20 and $3, but most likely $2.60
Bananas: $1.25 – $1.50, most likely $1.30
Grapes: $3.50 – $3.60, most likely $3.50

We can see that the range is greatly reduced and the central 90% range is now only $0.50.

While not a huge effort for making fruit salad, it may not always be worth it depending on the decisions we need to make and how much improving those estimates cost

Reducible vs. Irreducible Uncertainty

The exact price of the produce is called a reducible source of uncertainty. We were able to eliminate that source of uncertainty by putting in the effort to eliminate it completely.

Not knowing the exact weight of our produce is irreducible as we can’t know what it will be until we actually go to the store to buy them.

In most endeavors there are always a mix of reducible and irreducible sources of uncertainty. For reducible uncertainty, the question is always how much reducing the risk costs or can you live with it for the decisions you need to make.

For irreducible risk, there are similar questions only instead of spending to reduce the uncertainty, the question becomes one of buying insurance or mitigating the risk if it is difficult to live with.

Dartcannon can help guide discussions of risk by exposing the range of risks and helping focus on the most likely range of outcomes rather than the unlikely extremes.

Cross Posted from https://dartcannon.com/blog/2018-estimating-at-the-grocery-store

Getting Started With PDS3

Tue, 22 May 2018 00:00:00 +0000

PDS3 is a data standard used extensively by NASA for archiving data from science missions, maintained by JPL. While being replaced by PDS4, PDS4 covers all currently active missions and those covering the history of US space exploration.

The R pds3 package provides tools for parsing PDS3 data, particularly the ODL label format which describes all the metadata of data collection. Want to plot a heatmap of Mars of all the images taken? This is the package for you!

Getting Started

pds3 is available from CRAN, so can be simply installed via

install.packages("pds3")

To install the development version you can use devtools to install:

# Install the development version from GitHub:
install.packages("devtools") # If you don't already have it
devtools::install_github("mwaldstein/pds3")

Finding Data

If you’re exploring this package, chances are you already have a collection of PDS files, but if you’re interested in exploring NASA data, the place to get started is The Planetary Data System.

Once you find a mission you’re interested in exploring, finding the data explorer is typically straight forward. The metadata this package processes is typically stored in .lbl files. For instance, we’ll look at the labels from the Mars Reconnaissance Orbiter’s HiRise experiment, particularly the data associated with this image.

Reading & Parsing Data

We’ll start by grabbing the label (LBL) file.

href <- 'http://hirise.lpl.arizona.edu/PDS/RDR/ESP/ORB_011700_011799/ESP_011707_1440/ESP_011707_1440_COLOR.LBL'
req <- curl::curl_fetch_memory(href)
dat <- rawToChar(req$content)

Now we have the data, we’ll process it using parse_pds3.

library(pds3)
res <- pds3_read(dat)
str(res$odl)
#> List of 26
#>  $ PDS_VERSION_ID               : chr "PDS3"
#>  $ NOT_APPLICABLE_CONSTANT      : int -9998
#>  $ DATA_SET_ID                  : chr "MRO-M-HIRISE-3-RDR-V1.1"
#>  $ DATA_SET_NAME                : chr "MRO MARS HIGH RESOLUTION IMAGING SCIENCE\r\n                            EXPERIMENT RDR V1.1"
#>  $ PRODUCER_INSTITUTION_NAME    : chr "UNIVERSITY OF ARIZONA"
#>  $ PRODUCER_ID                  : chr "UA"
#>  $ PRODUCER_FULL_NAME           : chr "ALFRED MCEWEN"
#>  $ OBSERVATION_ID               : chr "ESP_011707_1440"
#>  $ PRODUCT_ID                   : chr "ESP_011707_1440_COLOR"
#>  $ PRODUCT_VERSION_ID           : chr "2.0"
#>  $ INSTRUMENT_HOST_NAME         : chr "MARS RECONNAISSANCE ORBITER"
#>  $ INSTRUMENT_HOST_ID           : chr "MRO"
#>  $ INSTRUMENT_NAME              : chr "HIGH RESOLUTION IMAGING SCIENCE EXPERIMENT"
#>  $ INSTRUMENT_ID                : chr "HIRISE"
#>  $ TARGET_NAME                  : chr "MARS"
#>  $ MISSION_PHASE_NAME           : chr "EXTENDED SCIENCE PHASE"
#>  $ ORBIT_NUMBER                 : int 11707
#>  $ SOURCE_PRODUCT_ID            : chr [1:12] "ESP_011707_1440_BG12_0" "ESP_011707_1440_BG12_1" "ESP_011707_1440_RED4_0" "ESP_011707_1440_RED4_1" ...
#>  $ RATIONALE_DESC               : chr "Channels on crater rim"
#>  $ SOFTWARE_NAME                : chr "PDS_to_JP2 v3.15.5 (1.49 2008/07/12 04:09:51)"
#>  $ IMAGE_MAP_PROJECTION         :List of 24
#>   ..$ ^DATA_SET_MAP_PROJECTION    :List of 2
#>   .. ..$ value : chr "DSMAP.CAT"
#>   .. ..$ offset: num -1
#>   ..$ MAP_PROJECTION_TYPE         : chr "EQUIRECTANGULAR"
#>   ..$ PROJECTION_LATITUDE_TYPE    : chr "PLANETOCENTRIC"
#>   ..$ A_AXIS_RADIUS               :List of 2
#>   .. ..$ value: num 3390
#>   .. ..$ unit : chr "KM"
#>   ..$ B_AXIS_RADIUS               :List of 2
#>   .. ..$ value: num 3390
#>   .. ..$ unit : chr "KM"
#>   ..$ C_AXIS_RADIUS               :List of 2
#>   .. ..$ value: num 3390
#>   .. ..$ unit : chr "KM"
#>   ..$ COORDINATE_SYSTEM_NAME      : chr "PLANETOCENTRIC"
#>   ..$ POSITIVE_LONGITUDE_DIRECTION: chr "EAST"
#>   ..$ KEYWORD_LATITUDE_TYPE       : chr "PLANETOCENTRIC"
#>   ..$ CENTER_LATITUDE             :List of 2
#>   .. ..$ value: num -35
#>   .. ..$ unit : chr "DEG"
#>   ..$ CENTER_LONGITUDE            :List of 2
#>   .. ..$ value: num 180
#>   .. ..$ unit : chr "DEG"
#>   ..$ LINE_FIRST_PIXEL            : int 1
#>   ..$ LINE_LAST_PIXEL             : int 55636
#>   ..$ SAMPLE_FIRST_PIXEL          : int 1
#>   ..$ SAMPLE_LAST_PIXEL           : int 10633
#>   ..$ MAP_PROJECTION_ROTATION     :List of 2
#>   .. ..$ value: num 0
#>   .. ..$ unit : chr "DEG"
#>   ..$ MAP_RESOLUTION              :List of 2
#>   .. ..$ value: num 236637
#>   .. ..$ unit : chr "PIX/DEG"
#>   ..$ MAP_SCALE                   :List of 2
#>   .. ..$ value: num 0.25
#>   .. ..$ unit : chr "METERS/PIXEL"
#>   ..$ MAXIMUM_LATITUDE            :List of 2
#>   .. ..$ value: num -35.4
#>   .. ..$ unit : chr "DEG"
#>   ..$ MINIMUM_LATITUDE            :List of 2
#>   .. ..$ value: num -35.6
#>   .. ..$ unit : chr "DEG"
#>   ..$ LINE_PROJECTION_OFFSET      :List of 2
#>   .. ..$ value: num -8377212
#>   .. ..$ unit : chr "PIXEL"
#>   ..$ SAMPLE_PROJECTION_OFFSET    :List of 2
#>   .. ..$ value: num 7151126
#>   .. ..$ unit : chr "PIXEL"
#>   ..$ EASTERNMOST_LONGITUDE       :List of 2
#>   .. ..$ value: num 143
#>   .. ..$ unit : chr "DEG"
#>   ..$ WESTERNMOST_LONGITUDE       :List of 2
#>   .. ..$ value: num 143
#>   .. ..$ unit : chr "DEG"
#>  $ TIME_PARAMETERS              :List of 6
#>   ..$ MRO:OBSERVATION_START_TIME  : POSIXlt[1:1], format: "2009-01-24 17:07:14"
#>   ..$ START_TIME                  : POSIXlt[1:1], format: "2009-01-24 17:07:14"
#>   ..$ SPACECRAFT_CLOCK_START_COUNT: chr "917284056:11103"
#>   ..$ STOP_TIME                   : POSIXlt[1:1], format: "2009-01-24 17:07:19"
#>   ..$ SPACECRAFT_CLOCK_STOP_COUNT : chr "917284060:44707"
#>   ..$ PRODUCT_CREATION_TIME       : POSIXlt[1:1], format: "2009-09-12 04:31:46"
#>  $ INSTRUMENT_SETTING_PARAMETERS:List of 4
#>   ..$ MRO:CCD_FLAG               : chr [1:14] "ON" "ON" "ON" "ON" ...
#>   ..$ MRO:BINNING                : int [1:14] -9998 -9998 -9998 -9998 1 1 -9998 -9998 -9998 -9998 ...
#>   ..$ MRO:TDI                    : int [1:14] -9998 -9998 -9998 -9998 128 128 -9998 -9998 -9998 -9998 ...
#>   ..$ MRO:SPECIAL_PROCESSING_FLAG: chr [1:14] "NULL" "NULL" "NULL" "NULL" ...
#>  $ VIEWING_PARAMETERS           :List of 7
#>   ..$ INCIDENCE_ANGLE  :List of 2
#>   .. ..$ value: num 60.9
#>   .. ..$ unit : chr "DEG"
#>   ..$ EMISSION_ANGLE   :List of 2
#>   .. ..$ value: num 0.27
#>   .. ..$ unit : chr "DEG"
#>   ..$ PHASE_ANGLE      :List of 2
#>   .. ..$ value: num 61
#>   .. ..$ unit : chr "DEG"
#>   ..$ LOCAL_TIME       :List of 2
#>   .. ..$ value: num 16
#>   .. ..$ unit : chr "LOCALDAY/24"
#>   ..$ SOLAR_LONGITUDE  :List of 2
#>   .. ..$ value: num 197
#>   .. ..$ unit : chr "DEG"
#>   ..$ SUB_SOLAR_AZIMUTH:List of 2
#>   .. ..$ value: num 193
#>   .. ..$ unit : chr "DEG"
#>   ..$ NORTH_AZIMUTH    :List of 2
#>   .. ..$ value: num 270
#>   .. ..$ unit : chr "DEG"
#>  $ COMPRESSED_FILE              :List of 8
#>   ..$ FILE_NAME                 : chr "ESP_011707_1440_COLOR.JP2"
#>   ..$ RECORD_TYPE               : chr "UNDEFINED"
#>   ..$ ENCODING_TYPE             : chr "JP2"
#>   ..$ ENCODING_TYPE_VERSION_NAME: chr "ISO/IEC15444-1:2004"
#>   ..$ INTERCHANGE_FORMAT        : chr "BINARY"
#>   ..$ UNCOMPRESSED_FILE_NAME    : chr "ESP_011707_1440_COLOR.IMG"
#>   ..$ REQUIRED_STORAGE_BYTES    :List of 2
#>   .. ..$ value: int NA
#>   .. ..$ unit : chr "BYTES"
#>   ..$ ^DESCRIPTION              :List of 2
#>   .. ..$ value : chr "JP2INFO.TXT"
#>   .. ..$ offset: num -1
#>  $ UNCOMPRESSED_FILE            :List of 6
#>   ..$ FILE_NAME   : chr "ESP_011707_1440_COLOR.IMG"
#>   ..$ RECORD_TYPE : chr "FIXED_LENGTH"
#>   ..$ RECORD_BYTES:List of 2
#>   .. ..$ value: int 21266
#>   .. ..$ unit : chr "BYTES"
#>   ..$ FILE_RECORDS: int 166908
#>   ..$ ^IMAGE      :List of 2
#>   .. ..$ value : chr "ESP_011707_1440_COLOR.IMG"
#>   .. ..$ offset: num -1
#>   ..$ IMAGE       :List of 19
#>   .. ..$ DESCRIPTION               : chr "HiRISE projected and mosaicked product"
#>   .. ..$ LINES                     : int 55636
#>   .. ..$ LINE_SAMPLES              : int 10633
#>   .. ..$ BANDS                     : int 3
#>   .. ..$ SAMPLE_TYPE               : chr "MSB_UNSIGNED_INTEGER"
#>   .. ..$ SAMPLE_BITS               : int 16
#>   .. ..$ SAMPLE_BIT_MASK           : int 1023
#>   .. ..$ SCALING_FACTOR            : num 0.000136
#>   .. ..$ OFFSET                    : num 0.0332
#>   .. ..$ BAND_STORAGE_TYPE         : chr "BAND_SEQUENTIAL"
#>   .. ..$ CORE_NULL                 : int 0
#>   .. ..$ CORE_LOW_REPR_SATURATION  : int 1
#>   .. ..$ CORE_LOW_INSTR_SATURATION : int 2
#>   .. ..$ CORE_HIGH_REPR_SATURATION : int 1023
#>   .. ..$ CORE_HIGH_INSTR_SATURATION: int 1022
#>   .. ..$ CENTER_FILTER_WAVELENGTH  :List of 3
#>   .. .. ..$ :List of 2
#>   .. .. .. ..$ value: int 900
#>   .. .. .. ..$ unit : chr "NM"
#>   .. .. ..$ :List of 2
#>   .. .. .. ..$ value: int 700
#>   .. .. .. ..$ unit : chr "NM"
#>   .. .. ..$ :List of 2
#>   .. .. .. ..$ value: int 500
#>   .. .. .. ..$ unit : chr "NM"
#>   .. ..$ MRO:MINIMUM_STRETCH       : int [1:3] 3 3 3
#>   .. ..$ MRO:MAXIMUM_STRETCH       : int [1:3] 1021 1021 1021
#>   .. ..$ FILTER_NAME               : chr [1:3] "NEAR-INFRARED" "RED" "BLUE-GREEN"

Cautionary Notes

All of the data you can access from NASA missions is public, but be aware that if you are going to download a large amount, there are almost always better ways than web scraping - be it either a catalog-only download or via FTP, investigate and be sure to be considerate.

Also of note that the data is public and free to use, it is the product of a lot of hard work and it is appropriate to cite the data source and the principle investigators of the instrument whose data you are using. NASA provides a guide to Citing PDS3 Data

One cool thing is that many PDS catalogs include citation information in a PDS3 formatted file we can use this package to extract!

cit_href <- "https://hirise.lpl.arizona.edu/PDS/CATALOG/RDR_DS.CAT"
cit_req <- curl::curl_fetch_memory(cit_href)
cit_dat <- rawToChar(cit_req$content)
cit_res <- pds3_read(cit_dat)

cit_res$odl$DATA_SET$DATA_SET_INFORMATION$CITATION_DESC
#> [1] "McEwen, A., Mars Reconnaissance \r\n      Orbiter High Resolution Imaging Science Experiment, Reduced \r\n      Data Record, MRO-M-HIRISE-3-RDR-V1.0, NASA Planetary Data\r\n      System, 2007."

References

The MRO-M-HIRISE-3-RDR-V1.0 data set was obtained from the Planetary Data System (PDS).
McEwen, A., Mars Reconnaissance Orbiter High Resolution Imaging Science Experiment, Reduced Data Record, MRO-M-HIRISE-3-RDR-V1.0, NASA Planetary Data System, 2007.

DartCannon: Where We’re Going

Mon, 21 May 2018 01:54:38 +0000

We’re so exited to see the response to our launch, we wanted to let you know what you can expect from us in the coming months. To fulfill out mission of bringing advanced tools to leaders at all levels, we launched with just the basics in place and have so much more planned.

While we can’t commit to a specific date, here is some of what we’re working on:

Shared Simulations

To keep things simple, we currently do now allow sharing simulations. Our first major feature is to allow sharing simulations for collaboration and in a read-only mode. This will also allow you to share simulations publicly so anyone with the link can view it.

Scrum Simulations

We know that not everyone runs their projects in the same way and while we’ve always planned on supporting agile methodologies, finding the right general approach has delayed our first implementation. In the coming months we’ll be releasing a third simulation type to support people using scrum/agile methods for projects.

PowerPoint Export

While we don’t expect anyone to immediately turn around and project our presentations, we do want to provide slides people can use to share plans and progress in easily editable formats.

Correlated Items

A major assumption of our overall approach is that individual tasks or line items are independent of one another. In practice however, actual outcomes tend to all run low or high. This feature will be as easy to use as the rest of DartCannon and will truly provide insights unavailable from other easily accessible tools.

Combined Schedule / Budget

While many projects have the benefit of only needing to worry about budget or schedule independently, if you don’t have that luxury you’ll need to see how they both come together.

When You can expect them

We’re still working on prioritizing all these features and would love to hear from you in what would be most beneficial to your work. We’ll always continue with new tutorials and guides to getting the most out of DartCannon along with bug fixes and minor quality of life improvements.

Cross-posted from https://dartcannon.com/blog/2018-where-we’re-going

DartCannon

Thu, 17 May 2018 00:00:00 -0400

DartCannon was founded on the idea that advanced tools should be available to all managers in an easy to use form. After gestating for 10 years, the time and technology is finally at a point where tools which previously cost $1,000’s per seat can be accessible by everyone.

edgarWebR

Thu, 17 May 2018 00:00:00 -0400

edgarWebR is a R library which provides an interface to access the SEC’s EDGAR system for company financial filings.

edgarWebR does not provide any functionality to extract financial data or other information from filings, only the metadata and company information.

pds3

Thu, 17 May 2018 00:00:00 -0400

pds3 reads PDS3 files, a standard published by JPL and used throughout NASA space missions. While PDS3 is being supplanted by PDS4, a XML based standard, PDS3 is still being used and is needed for accessing historic data.

References

Introducing DartCannon

Tue, 15 May 2018 01:51:59 +0000

Most estimation is taking a single shot in the dark. DartCannon exists to let you take thousands of shots on the goal – firing as many darts at the dart board as needed to get an understanding of where they’ll fall. Previously this capability was limited to planning departments with deep pockets, willing to shell out for esoteric, complicated pieces of software. DartCannon changes the game, bringing those advanced tools to a price point and simplicity where anyone can use them.

And you can start for free. We’re committed to improving estimation we’re letting everyone use the basics of out tool for no out of pocket expense and no credit card required.

Of course we hope you stick around and subscribe to access out premium features –

Unlimited Simulations
Unlimited Complexity to Simulations
High-Resolution Simulations
Excel™ Import and Export

We plan to continue to push the envelope of what you can do with DartCannon and help ensure that leaders at all levels have access to the most advanced tools to move the art of management forward. We’re not done either – in the coming weeks we’ll be sharing our roadmap and how we hope to continue to improve and provide more features, both for free and premium users.

Cross-Posted from the new startup I’ve been working on, DartCannon

MPOD #5 – George (1/n)

Fri, 19 Jan 2018 20:00:39 +0000

MPOD #4 – Hadrian’s Wall

Thu, 18 Jan 2018 17:00:01 +0000