Question: I recently started learning AngularJS, and I have the following sample code that does a REST callout from a Visualforce page - the code does a successful callout.
My question: In the 'app.config' where we provide the Authorization header as a string value ('BASIC base64Hash'), base64Hash being the username:password hash, how is this secure? If I open up the page and hit inspect, I can grab the hash and decrypt the base64 to get the username:password.

P.S: Keep in mind that I recently got into AngularJS, and I know that the following procedure for a REST callout from AngularJS may not be the best practice. Which is why the question. :)

```
<apex:page standardStylesheets="false" showHeader="false">
    <html ng-app="hello" lang="en">
        <head>
            <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"> </script>
            <script>
                // define the app
                var demoApp = angular.module('hello', []);
                demoApp.config(['$httpProvider', function($httpProvider) {
                    $httpProvider.defaults.headers.common['Authorization'] = 'BASIC base64Hash';
                }]);
                demoApp.controller('helloController', function($scope, $http){
                    $http({
                        method: "GET",
                        url: "ENDPOINT URL",
                    }).then(function mySuccess(response){
                        $scope.apiResponse = response.data;
                    }, function myError(response){
                        $scope.apiResponse = response.statusText;
                    });
                });
            </script>
        </head>
        <body ng-controller="helloController">
            <div>
              {{apiResponse}}
            </div>
        </body>
    </html>
</apex:page>

```

Answer: 
The data type that gives you fine-grained control over precision is `Decimal`. For example, if you wanted to have 30 decimal places after the divide this:

```
Decimal d = 5;
d = d.divide(3, 30);
System.debug('>>> ' + d);

```

outputs this:

```
>>> 1.666666666666666666666666666667

```

Take a look at the [Decimal documentation](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_decimal.htm) to see the various methods available that allow you to control precision.

Decimal is significantly different from Double or Float: they represent numbers using a fixed number of bits and most CPUs have hardware support for calculations using them. Decimal (BigDecimal in Java) on the other hand is implemented in software and handles an open ended number of digits *exactly*. Unless you are doing massive amounts of calculations the slower performance of Decimal is irrelevant.

If doing calculations involving money, Decimal is a good choice to exactly control rounding and avoid losing precision with large numbers.

On your specific question, when a calculation discards some digits they are not going to re-appear. Financial algorithms often have specific rounding rules defined as part of their specification to address this e.g. [COMPOUND INTEREST](http://sites.csn.edu/istewart/Math120/Consumer/compound_interest.html).
When you store certain types of fractions in a Decimal value, their value is approximated, because they can not be exactly represented in the binary format used by computers. While we humans have no problems with 2 / 3 \* 3 equaling 2, ordinary programming languages can't express all numbers precisely.

Let's take a look at another example. If we take sqrt(4) \* sqrt(4), we get the answer 4. That's because the square root of a number is the number that, when multiplied by itself, yields that number. However, if we now take a look at sqrt(2) \* sqrt(2), we end up with a value like 2.0000000000000004, instead of the logical conclusion of 2. This is because irrational numbers can not be expressed in the binary format native to decimal; we end up with only a close approximation. 

The general rule for performing math in a programming language is to perform division *last* whenever possible, even if it means doing some algebra to figure out how to do so. Whenever you perform division, you must assume that some loss of precision will occur. The more times you divide, the greater loss of precision may occur. Generally, this means you'll need to reset the precision of the end result using Decimal.setScale. Additional precision will be lost.

Finally, note that in Apex Code, writing `(5 / 3) * 3` literally results in the value of 3, not 4.99999999999999999. This is because those values are interpreted as integers, so you get integer division. To yield a result closer to what you observed, you'd need to introduce a decimal for implicit upcasting:

```
System.debug((5 / 3) * 3); // 3
System.debug((5.0 / 3) * 3); // 5.00000000000000000000000000000001

```

This is the exact same behavior as observed in Java.