Wednesday, October 28, 2015

Finally, you can run Einstein Equations with CalcRx

This post assumes that you have the basic idea of C#, LINQ, and Reactive Extensions; and you have read the previous article in this series. You can suggest edits to this post here.
Click here to find out more about CalcRx.


This is the second and the last post with regards to Einstein Equation Fix. In the last post, we identified a major issue on how LINQ syntax was incorrectly generated by CalcRx and how we fixed that. But there was still one glitch that was causing the Einstein equations to fail. A fix is finally applied and now we can run Lorentz Transformations or similar equations. This post discusses the fix.

The issue

As you might recall from the previous post, we were still not able to run any of Einstein's relativity equations because of the way the bug was still there when functions were involved. To understand the issue better, consider the following expression.
I have left out the 'self' reference or the underscore for the sake of simplicity. The above will generate an Expression like this
__main.Select(a0 => fnsqrt(4)).CombineLatest(__main, (a,b) => 1/a);
Which is basically saying, transform the observable to yield square root of 4, then combine it with target observable again and do the division.
The above example would look pretty if CalcRx generated the following expression
__main.Select(a0 => 1/fnsqrt(4));
The last fix was not taking functions into account. Since in computer programming world square roots are done through functions, most of Einstein's Relativity equations that involve square roots would fail.
For instance, this time dilation equation

The fix

The fix this time was easier, or at least we knew what it was. The fix was same but we just have to apply that to functions.
So now finally you can write Einstein Equations in expressions like so
// Length Contraction
var transformedLength = CalcRx.Evaluate<Measurement, double>("Length/(1 - sqrt(Velocity/299792458)^2)", functions);


No math expression library would do justice if it could not function on any kind of expressions. Specially the Einstein's equations. Good thing the issue is resolved.

Friday, October 2, 2015

Here are a few caveats to using Aria Templates in your web application


This post discusses my experience as a first-timer with Aria Template,  what type of challenges I faced, and the lessons I learned that the reader could benefit from.

You may have already known about the robust and awesome way of having templates using Aria Template. If not, check out this short guide here. It indeed looks fancy, sounds like it can help you a great deal but it comes with some warnings.

MIME Types

Most web servers nowadays don't just serve all types of files when requested through a URL. Only the ones that they are configured to serve. Aria template files are saved with .tpl extension, and it also loads one of its internal file with .cml extension in the bootstrap code so you will have to configure your web server software (IIS, apache, nginx etc) to allow those extensions as text/html.

Template Path confusion

Aria turns what you provide in classpath into a relative path to your .tpl file. In my experience, I had thought the following classpath would represent /home/userarea/Profilesnapshot.tpl

{{Template classpath:'home.userarea.Profilesnapshot' }}

But it was actually looking for the said tpl file in /js/home/userarea/Profilesnapshot.tpl where 'js' is same directory where area templates JS file was included from.

Also, the last part of the classpath (in this case Profilesnapshot) should have the first letter upper case (same goes for the template file name).


Be prepared to spend at least 5 hours scratching your head, and trying to figure out why something is not working. Also, if your team has many red-tapes or is one of the ones that are "too busy to improve", it is not easy to sell Aria to them. Not to mention the grouchy admins who will give you all sorts of trouble when you ask them to add new MIME types to the web server.