logo

Swift Calcs BlogNews, notes, and ruminations from the Swift Calcs team

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.

New intelligent computations are now live

Over the last few months, Swift Calcs has been testing a new Computation Tree to help speed calculations in Swift Calcs. We are happy to announce that this new intelligent computation scheme is now live, and we expect our users to see an increase in computation speeds for complex worksheets.

Out with the old

Prior to today, Swift Calcs used a blind computation scheme, similar to python or other scripting languages, to perform calculations. In this method, whenever any item in a worksheet was changed, that line and all following lines were automatically recalculated.

This behavior made a simple assumption: If an item changes, any later item in the worksheet might be impacted, so they should all be recalculated.

Although effective, this calculation scheme is quite inefficient. Many later items may not be impacted by a change, and recalculating them is unnecessary, wasting system resources and time. In the worst cases, long worksheets with hundreds of lines would be completely recalculated when a simple definition, with no impact on the remaining worksheet, was changed at the top of the page.

In with the new

The Computation Tree is our answer. Now, Swift Calcs intelligently links lines in your worksheet based on the independent and dependent variables in each line. When something in a worksheet is changed, Swift Calcs will now only recalculate later lines that depend on the item that was originally changed. When these dependent lines are updated, any lines that are dependent on these lines are then updated as well, and so on, until all dependencies on the original edit are resolved, and the worksheet is fully updated.

It's a bit more work on our end to build the tree on the fly, and we have worked hard testing this feature to ensure the accuracy of our tree building algorithms. That work has paid off: on complex worksheets, this new calculation scheme results in computation improvements of over 10x, as lines un-impacted by a change are passed over instead of needlessly recalculated.

Live now on Swift Calcs

The Computation Tree is now live and running. Since Swift Calcs is cloud-based, you already have it and its already working. Enjoy more efficient calculations with Swift Calcs!