{"id":16254,"date":"2020-02-08T17:08:20","date_gmt":"2020-02-08T17:08:20","guid":{"rendered":"https:\/\/www.bartbusschots.ie\/s\/?p=16254"},"modified":"2020-02-13T17:43:32","modified_gmt":"2020-02-13T17:43:32","slug":"pbs-tidbit-1-of-y-display-values-are-not-data","status":"publish","type":"post","link":"https:\/\/www.bartbusschots.ie\/s\/2020\/02\/08\/pbs-tidbit-1-of-y-display-values-are-not-data\/","title":{"rendered":"PBS Tidbit 1 of Y \u00e2\u20ac\u201d Display Values are not Data!"},"content":{"rendered":"

Listener @lbutlr<\/a> pointed out on Twitter<\/a> that the sample solution to the challenge set in PBS 88<\/a> as I originally posted it in PBS 89<\/a> had a bug \u00e2\u20ac\u201d it sometimes got its maths spectacularly wrong!<\/p>\n

\"PBS<\/p>\n

It’s important to note that the bug did not affect all currencies, just some currencies.<\/p>\n

The line of code for doing the currency conversion is supremely simple:<\/p>\n

const convAmount = baseAmount * rate;<\/pre>\n
How on earth can there be a bug that is something so simple that only manifests for some currencies but not for others?<\/p>\n
<\/p>\n
\n
Listen Along: PBS Tidbit 1 of Y \u00e2\u20ac\u201d Display Values are not Data!<\/a><\/p>\n\nhttps:\/\/media.blubrry.com\/nosillacast\/traffic.libsyn.com\/nosillacast\/CCATP_2020_02_08-TB1.mp3.mp3<\/a><\/audio><\/div>\n
Diagnosing the Problem<\/h2>\n
The first thing I noticed was that the bug affected low-value currencies. When each unit of the currency has a low value then the exchange rates will involve small numbers. Maybe the combination of a big base amount and a tiny exchange rate was exceeding the amount of precision a JavaScript number can store?<\/p>\n
Javascript numbers are 64bit numbers (double-precision<\/em> numbers or simply doubles<\/em> in programming jargon), so they can only capture so much detail \u00e2\u20ac\u201d as a science student I ran into the limit of doubles when doing homework assignments, so I knew it was at least conceivable. Looking more closely that didn’t make sense \u00e2\u20ac\u201d the numbers were not big enough, and the rates not small enough for that to be a reasonable explanation.<\/p>\n
I was on the right track though \u00e2\u20ac\u201d it was a precision problem, but not with JavaScript’s number storage, but with my code!<\/p>\n
As explained in the description of the solution in PBS 89<\/a>, I used data attributes to store the rate within the relevant row of the card using HTML data attributes. Without thinking about it the value I stored in the data attribute was the rate as displayed to the user \u00e2\u20ac\u201d rounded to 2 decimal places<\/code>!<\/p>\n
The data attribute is added into the currency’s item within this part of my Mustache template:<\/p>\n
\r\n<li class=\"list-group-item currencyRate\" data-currency=\"{{{code}}}\" data-rate=\"{{{rate}}}\">\r\n<\/pre>\n
And the rate is added into the view with this line:<\/p>\n
\r\ncardView.rates.push({\r\n  code: cc,\r\n  rate: numeral(curData.rates[cc]).format('0,0[.]00'),\r\n  ...CURRENCIES[cc]\r\n});\r\n<\/pre>\n
And there we have it \u00e2\u20ac\u201d the view was originally written purely to present information to the user, and I then re-used that view to inject data into the DOM elements. This is a great illustration of why you want to avoid passing information formatted for consumption by humans into computations!<\/p>\n
Bottom line \u00e2\u20ac\u201d as I suspected, it was indeed a loss of precision,  but one of my own making \u00e2\u20ac\u201d oops!<\/p>\n
There is a silver lining though, I have the power to fix problems I created \u00f0\u0178\u2122\u201a<\/p>\n
Fixing the Bug<\/h2>\n
The solution is fundamentally very simple \u00e2\u20ac\u201d add the true rate into view as well as the formatted rate, then use that true rate to populate the data attribute.<\/p>\n
The first step was to tweak the code that creates the view to add a new key named rawRate<\/code>:<\/p>\n
\r\ncardView.rates.push({\r\n  code: cc,\r\n  rate: numeral(curData.rates[cc]).format('0,0[.]00'),\r\n  rawRate: curData.rates[cc],\r\n  ...CURRENCIES[cc]\r\n});\r\n<\/pre>\n
The template could then be updated to use the raw rate:<\/p>\n
\r\n<li class=\"list-group-item currencyRate\" data-currency=\"{{{code}}}\" data-rate=\"{{{rawRate}}}\">\r\n<\/pre>\n
Much better!<\/p>\n
\n\"PBS<\/p>\n
You’ll find the full code for the challenge solution on GitHub<\/a>.<\/p>\n
Related Content<\/h2>\n