logo

SwiftCalcs BlogNews, New Features and Examples from The SwiftCalcs Team

Unit Pre-Processing and Adaptive Plots

Noticed speed improvements in Swift Calcs plots and solvers recently? It's not your imagination: Quietly slipped in to a weekly production release two weeks ago was an update to our mathematics engine that increases calculation speeds up to 100x, depending on the calculation.

The secret to the bump? Well, its actually two:

Unit pre-processing

Working with units is a huge benefit of performing calculations with Swift Calcs, but the downside is that the inclusion of unit operators adds considerable overhead to each calculation. Units of the same type have to be converted during operations, checks have to be made to ensure unit consistency, and unit simplifications have to be done to remove canceled dimensions.

For most calculations, this added overhead is hardly noticed, but for operations that require continual re-evaluation of a function or expression, such as solvers and plots, this added overhead turns in to a real drag.

In these situations, however, we don't really need to do all the extra unit calculations on each and every iteration. We really need to do it once, up-front, to check for unit collisions or inconsistencies. Once we know the units are valid, we can simplify the expression by converting all units to mksa equivalents and then stripping them out.

In this way, we reduce the unit calculation overhead considerably by removing it from internal iterative routines. When we get our results, we simply re-apply the output unit to the answer. The results of this approach are dramatic...take a look at measured computation times for some functional tests before and after the change:
image For some calculations involving heavily nested functions with lots of unit calculations, this approach increased computation speed nearly 100x! And best of all, it works in the vast majority of situations...but when it doesn't (for example, when non-absolute temperature scales are utilized...ugh offsets!), we can simply revert to the previous method to perform the calculation.

Adaptive Plotting

When it comes to plots, however, we have more to share: Prior to last week's release, Swift Calcs used a plotting algorithm that is best described as brute-force. We would take a plot window, determine the number of pixels along the x-axis, and calculate the corresponding y value for each location. That equals 590 calculations for each function plotted. Consider y=x2 below using our old implementation...the number of sampled points is so large you can't really discern one point from the next:
image

This is overkill. Most functions don't need every pixel to be calculated to produce a visually accurate line. To reduce computational load, our new routine focuses on areas of high-curvature. We use an adaptive sampling routine that starts with a certain number of points (we use 20) roughly evenly spaced throughout the plot domain (not exactly even as we apply a bit of randomness to each point...if we didn't, we could get tripped up by periodic functions that have the exact same frequency as our sample points).

Next, we take a look at each sampled point and its two neighbors. If the angle formed by the three points is between 170 and 190 degrees, we have minimal curvature and no further refinement is needed (Tangent: The angle calculated is the perceived angle when plotted on the screen, as opposed to the true angle between the vectors. So its value depends on both the x-axis and y-axis limits, as well as the plot aspect ratio and use of log-plots). If we're outside these bounds, we calculate another point and at it to our sample, and again run the curvature comparison.

In this way, we continue to refine the plot until all sampled points are within the curvature bounds, or we've reached the resolution of the screen. Take a look at y=x2 plotted using our new method:
image

And here are the two plots from before and after, with the sampling points removed to only show the functional form:

image image

The plots are visually indistinguishable (can you tell which is which?), but the number of calculations (and therefore the time) to produce the one on the left is over 10 times less.

Most functions we tested end up using somewhere between 60 to 120 points, representing speed improvements of 3-10x from our previous brute force method. Combined with the unit pre-processing above, we're seeing speed improvements of between 10-100x...plots now often render in fractions of a second!

And added bonus: Dynamic Range

A nice benefit to the inclusion of the adaptive sampling algorithm is that a dynamic range solver comes along for free.

What is dynamic range? This is the idea that when producing a function plot where the y-axis bounds we're not set to specific values, the plotting engine should return appropriate y-axis bounds that produce a visually useful plot. For most functions, this range is simply the minimum and maximum y-values observed within the plot domain. However for plots with asymptotes that approach infinite values, the asymptote spike leads to an extremely large maximum or minimum value that create a visually useless plot.

Our calculation of the visual angle for the adaptive sampling technique, however, requires us to 'know' the y-axis range to determine the angle. Using this information, we can apply a simple test: Every time we add a new point in the sampling routine, if the new point is outside the currently known y-axis bounds, we consider the point to be 'outside' the preferred range if it would cause the value of:
image to increase by a factor of 8 times or more. Otherwise, we simply increase our known y-axis bounds. This helps us ignore asymptotes when a plot blows up and focus on the portion of the function of interest. Take a look at the plot for y=cos(x)/x from before and after this change:

image image

Clearly the new plot is more useful than the old.

Swift Calcs Pro and Business are Here!

We've been at work on Swift Calcs for over a year, and are thrilled to announce that as of today, we're out of Beta. Accompanying this change in version numbers is the introduction of paid plans in Swift Calcs: Swift Calcs Professional and Swift Calcs Business.

Paid Plans?!? I like free!

So do we! But we also like making reliable and compelling products, which takes resources. So we've tried to split the difference: We are maintaining a free version through our Swift Calcs Public plan. This option, restricted to non-commercial uses, includes many of the most popular Swift Calcs features and is designed for academics and hobbyists.

For commercial users and those looking for private documents, team management features, priority support, and more, we have crafted the Professional and Business Plans to suit your needs. We've designed our paid subscription plans to allow us to continue to build and improve Swift Calcs for all our users.

Why Now?

We've been squashing bugs and building features for months, and we're not stopping now. But the platform has reached a level of stability and usability that is increasingly attracting serious users with serious needs. The paid plans allow us to continue building the Swift Calcs platform while delivering world-class customer service.

Get to the details!

Our plans and their features are shown in the table below. As a thank you to all of our Beta users, we are offering everyone the Business Plan for free for the entire month of February. New users who sign up will be given the option of a 10 day trial. When you're ready to buy, click the manage subscription link from accounts pulldown menu at the top right of every Swift Calcs screen, or click here to see your current subscription settings.

Public

Free


Hobbyists and
Non-Commercial Users

Professional

$25
User / mo


Individuals or Small
Teams of 1 to 5

Business

$ 45
User / mo


Business Users or
Teams of Any Size
Swift Calcs Core Features
Human Readable Mathematics
Advanced Math Engine
Full Unit Support in Calculations
Engineering Equation and Function Library
Coming Soon...
Engineering Materials Database
Thermodynamic Properties Database Limited to 2 component mixtures
Create Custom Toolboxes and Functions
Coming Soon...
Collaboration Features
Access Files Anywhere, Anytime
Open-Source Worksheets
Private Worksheets
Collaborators per Worksheet 1 4 Unlimited
Team Sharing Options
Cleaned output when printing With non-commercial notice in header
Plugins and Connections
Autodesk Fusion 360 Limited to 3 Projects
Onshape Limited to 3 Projects
Support
Online Forums and Knowledgebase
Priority Email Support When available 2 tickets per month
Priority Feature Development
Security
Full SSL encryption between you and Swift Calcs
View-Only Sharing Permissions
View-Only and Copy Permissions
Ability to Invalidate and Reset URLs
File Revision History

What's New: January 2017

The dev team has been busy this new year, with a wide ranging update that brings a number of requested features and upgrades to Swift Calcs. It's quite the list, and with these updates we're very close to our official transition out of the beta phase!

Line indentation

To help with the visual separation of worksheets, individual lines or groups of lines can be indented. Indentation does not impact calculation in any way, but provides a visual grouping of lines that can be helpful in worksheet organization. Additionally, when multiple lines are indented together, they whole group can be collapsed or expanded using the icons in the worksheet margins.
indent image

Toggle evaluation on lines

Sometimes, it may be useful to toggle out a line from a calculation. Whether for debugging, testing multiple values for a variable, or archiving some previous work, you can now click the small calculator icon in the left-hand margin of a worksheet to disable evaluation for a single line, or group of lines. Simply click again to re-enable.
disable evaluation

Variable results inside text mode

An oft-requested feature, you can now add variable values directly into text mode. As a worksheet changes and values of variables change, the value referenced in the text box will update as well.
variable in text mode

Variable values in autocomplete

Now, when entering equations, the autocomplete listing will show the variable name as well as its current value (large values, such as large matrices that would overflow the autocomplete menu, are hidden).
autocomplete with variables

Variable references in equations

When you click on a variable in math-mode, or move your cursor onto a variable name, a popup will show the value of the variable and the line on which it was defined. Click the line number to move to the definition. No popup will be shown if the variable is not defined.
variable popup in math mode

Cascade variable renaming

Sometimes, you've made a long calculation only to find that you want to rename a variable, but doing so would require updating many other lines that refer to the variable. No longer: now, Swift Calcs will detect if a variable has been renamed, and ask if you would like to have all references automatically updated as well.
variable renaming

Multiple linear regression

A new tool in the toolbox in the data section, the multiple linear regression tool allows you to find the best fit function for multiple independent variables.
multi regression

More unit support!

We've increased support for units. Now, rotational units in units of angle/time (rad/s, deg/h, etc) can be converted to or from frequency units (Hz, rpm, etc), added together, or used interchangeably. We've also added prefix support for the mole unit, so now kmol, cmol, etc are available for use. Finally, as previously announced, Fahrenheit and Celsius units are now available in Swift Calcs!

Function helper

One area of confusion we often see in user studies is the difference between a variable and a function in Swift Calcs. Swift Calcs will now work to help automatically convert variable definitions to function definitions where appropriate (not your intent? Simply press undo or Ctrl-Z to undo the change):
var to function helper

Comma delimiter

In your user settings, you can now select whether to show comma delimiters with numbers to help visual separate orders of 1000:
comma in number

More help docs

We've finished out video tutorial library, available form the top-right of any Swift Calcs window or from the help menu. Find topics ranging from introductory lessons to help with calculations to videos on sharing worksheets.

We're not done!

More is on the way, so stay tuned as we continue to make Swift Calcs better, and as always, don't hesitate to send along your ideas, questions, or comments.

Introducing Celsius and Fahrenheit Units

We routinely hear from our users: Swift Calcs supports such a wide range of units and functions...why not temperature? Temperature units are different, and including them in our calculation engine required a wholesale rewrite of many unit handling functions and solvers.

We are happy to announce that this work is now complete, and starting today, Celsius and Fahrenheit units are available for use in Swift Calcs.

What took so long?

Celsius and Fahrenheit are unlike any other unit in Swift Calcs because they have non-zero offsets. Converting any other unit is simply a matter of multiplying by the correct conversion constant:

4 in → 4 ⋅ (0.0254) → 0.1016 m

Not so with Celsius and Fahrenheit. These units do not share a zero, and therefore require both a multiplication AND an offset:

23 °F → (23 - 32) ⋅ (5/9) → -5 °C

The implications of this one little offset are enormous. What if instead of starting with 23 °F, we started with a difference?

(33 °F - 10 °F) → 23 °F → 23 ⋅ (5/9) → 12.78 °C

What happened to the offset? It cancelled out: since the offset is present in the conversion of 33 °F to °C and 10 °F to °C, the difference of these two values cancels the offset. The result is that in the first example, 23°F→-5°C, but in the second example 23°F→12.78°C. With temperature units, there is ambiguity when performing calculations.

Working through the Ambiguity

Dealing with this ambiguity in calculations, solvers, plots, and other functions is a challenge, and Swift Calcs has solved this problem through the use of intelligent assumptions when ambiguities arise that attempt to infer user intent, and through the availability of separate units for absolute and relative temperatures to allow the user to directly signal their intent.

Absolute temperature units are temperatures that include the offset in conversions, representing a true temperature on a thermometer. In the first example above, we would use the absolute temperature unit °F (entered as degF in Swift Calcs using the keyboard) and the conversion would therefore use the offset:

23 °F → -5 °C

Relative temperature units are differences between absolute temperatures, and represent a change in temperature. In the second example above, we would use the relative temperature units Δ°F (entered as deltaF in Swift Calcs using the keyboard) and the conversion would therefore ignore the offset:

23 Δ°F → 12.78 Δ°C

Learn More

We've produced a detailed write-up in our help area that dives in to using Celsius and Fahrenheit units in Swift Calcs, including the assumptions made by the calculation engine and how to override default behaviors. Find the article in our Help Center to learn more!

A faster and more reliable backend

Last night, the Swift Calcs team completed the transition of the entire Swift Calcs platform from Heroku to Amazon Web Services (AWS).

Why the change?

Heroku is a fantastic service (this blog you're reading? Yup, on Heroku). It allows the near immediate creation of sophisticated web environments with little to no effort. When we started Swift Calcs, we wanted to get our prototypes online, not worry about server configurations or database provisioning. Heroku does all this work for you seamlessly, allowing you to focus on what you care about.

Unfortunately, this comes with some costs. First, COST! Heroku runs on AWS, so they are basically upcharging you for the services you are getting from Amazon. For a small/starter site, this is a non-issue...but as servers get larger and more complex, that extra overhead adds up. Plus, Swift Calcs is a member of the AWS Activate program, which provides us some free AWS services as a young company, credits that we can't use with Heroku.

The second cost, and arguably the reason we made the switch, is customization. Heroku is very good at getting you up and running fast, but that means its offerings are pre-packaged and standardized. Tweaking servers, adding services, customizing the database, and more becomes increasingly difficult as you scale. AWS, on the other hand, is more burdensome to setup, but once it's going, it's incredibly flexible. Customizing the server configurations, database, and workers allows for a better solution for Swift Calcs.

What it means for you

As a user, this change should be completely transparent (apart from the 20 minutes of maintenance/downtime yesterday during the switchover). The point is that you don't notice it. Swift Calcs should be reliable and fast regardless of the time of day or load on our servers, and with this change to AWS, we will be more able to ensure our continued reliability and success. We will also be rolling out new features soon that became available (or more straightforward to implement) thanks to the AWS move, including the ability to reply to support tickets emails directly (currently you have to visit our website to reply), the ability to create new tickets by emailing [email protected], bounce notifications for invitations, and more.

How we did it

For the tech stars out there, our transition process wasn't as worrisome as we feared. Feel free to reach out to us for advice, but we followed a few steps to move (Our Application is primarily Rails based, and was running on a Heroku rails setup):

  1. We create an Elastic Beanstalk (EB) application based on the same Ruby version in use in our Heroku app. Key notes: There are various articles online describing the need for an .ebextensions folder to tell the EC2 instance to use yum to install some dependent libraries (git, etc). We didn't need to do this, as none of our gems are loaded through git, so we skipped this step and had no issues with the default set of installed libraries in the linux AMI we used.
  2. We did NOT create a database with the elastic beanstalk environment (why? Even Amazon tells you not to do this...if you do, the RDS instance is associated with the EB environment, so if you terminate or change the EB environment, the RDS instance can be recreated and all your data can be booted...). Instead, we went to RDS and provisioned a database directly.
  3. Using a database dump from Heroku, we used pg_restore to load our data in to our new RDS instance
  4. In our Elastic Beanstalk environment, we updated the configuration to add our environment variables (including the database host/user/pass, various third party API keys, etc) that are used by the app.
  5. We loaded our SSL certificate into the load balancer associated with the EB environment.
  6. We repointed our DNS settings to amazon. We use Cloudflare to manage our DNS (among other things...) and updating the CNAME records was easy. You may want to visit a few days beforehand and update your expiration time to 2 minutes or so in order to ensure a quick changeover. You can then re-up them to 24+ hours later.
  7. Done! Our app was up and running on AWS.

Final notes: Heroku has a very nice service called 'scheduler' that makes it incredibly easy to define cron jobs to run periodic tasks. Its more difficult to do this on AWS, because EC2 instances can be starting and stopping all the time, and if you set cron on all instances, your jobs will run on each instance, when you only want them to run once. There are many gymnastics around this (check if the instance is the leader, etc) but we went with creating a second EB environment, but in a worker tier.

A worker tier EB environment can be set to run periodic jobs by listing them in a file called cron.yaml in the root of your app. Essentially, it will post to a desired endpoint in your worker tier web-app at specified intervals (See here). We simply use our exact same Rails app as on our web server in the worker tier, but specify different routes to a special controller that contains all the logic for our periodic tasks. Then when they are called, the 'cron' controller in our app handles the request and performs the periodic task, similar to how we used rake tasks for the same purpose in Heroku with scheduler.

A side benefit of doing this is that you can use the worker tier for a variety of other tasks, such as sending emails, handling inbound email, and more, and it integrates with Amazon's SQS service to allow queing jobs quick and easy. We are already finding a number of new interactions for our app using SQS with SNS and SES (AWS loves their 3 letter acronyms) and this flexibility is opening new doors for our dev team.

We also had to update our build scripts for elastic beanstalk, but this was fairly easy as well. Basically, instead of a git push heroku we now use an eb deploy statement in our deploy scripts. Our only complaint? Heroku is git based, so deploys are fast as it only needs to sync changes. EB, on the otherhand, uploads a full zip archive for each deploy, which is slower, and when things go wrong you have to dig in to the logs, as EB doesn't push the same amount of info to the console. This makes deployments to our staging server a bit more time consuming, but these are small gripes, especially because logs aren't too hard to pull with eb logs, and our entire app when zipped is only a couple MB, so the full upload each time isn't too much of a delay.