# Fog vs. Cloud Computing: Should I Stay or Should I Go? +
## 4 Analyzing Test Cases
### Choosing an Approach to Estimate \(f\)  
When following the steps presented in Section 3.2 to estimate the probability that a value passes the filter (\(f\)), we come across the question of whether it would be more profitable to make a decision at the beginning of the stream and then process the values accordingly or to make several decisions along the stream with the intent of accounting for possible changes in data patterns. In order to evaluate the possibility of making several decisions along the stream, we implemented two different estimation procedures, which we call Local and Cumulative. In both approaches, we first divide our stream into a certain number of blocks (\(b\)). As the number of values we are allowed to test (\(v\)) is still the same, we can now check \(\lfloor v/b\rfloor\) values in the first \(b-1\) blocks and \(v-(b-1)\times\lfloor v/b\rfloor\) values in the last block. The total number of elements in each block depends on the stream size (\(z\)) and can be calculated as \(\lfloor z/b\rfloor\) for the first \(b-1\) blocks and \(z-(b-1)\times\lfloor z/b\rfloor\) for the last one. In the Local approach, we leverage the information obtained by testing local values in order to try to better estimate \(f\) for each block. To that end, we test the values at the beginning of each block and count how many of them passed the filter, then divide this number by the number of tested values. Continuing the example from Section 3.2, for \(b=4\), we would be able to check \(\lfloor 5/4\rfloor=1\) data point in each of the first three blocks and \(5-3\times\lfloor 5/4\rfloor=2\) data points in the last one. If the number of values that passed the filter (\(n\)) was one in each of the first and second blocks, none passed the filter in the third, and one passed it in the fourth, we would have \(f=1/1=1\), \(f=1/1=1\), \(f=0/1=0\), and \(f=1/2=0.5\) for each block, respectively. In the Cumulative approach, we attempt to use the results from all previously-tested blocks in order to make a more informed estimate using a larger number of data points. In this case, we also test the values at the beginning of each block and count how many passed the filter, but we then accumulate the number of both tested and passed values with the count from previous blocks. In our example, that would lead to \(f=1/1=1\) for the first block, \(f=(1+1)/(1+1)=1\) for the second block, \(f=(1+1+0)/(1+1+1)=0.67\) for the third, and \(f=(1+1+0+1)/(1+1+1+2)=0.6\) for last block. Using these two approaches to estimate \(f\), we calculated the costs in terms of execution time for all benchmarks and datasets using the simplified versions of Equations (1) and (2) obtained in Section 3.2 (i.e., \(C_{f}=t+s\cdot f\) and \(C_{c}=s\)). The figures in this subsection present a summary of these results. For the sake of simplicity, we did not include all possible combinations between datasets and applications, as some of the graphs are very similar to the ones shown. All figures employ the same values for stream size (\(z=65\),\(536\)) and custom execution code cost (\(t\), shown in Tables 1 and 2 in Appendix B), but Figures 2-5 use the measured time of \(7.3\,\mathrm{ms}\)[24] as the cost of sending data to the cloud (\(s\)), while Figures 6-9 show what the costs would be like if \(s\) was ten times smaller (\(0.73\,\mathrm{ms}\)). In the first case, the results are fog-prone, that is, the fog is more likely to be profitable, as \(s\) is about one order of magnitude larger than \(t\). On the other hand, the results in the second case are cloud-prone, as the cloud is more likely to be profitable when we have close values for \(s\) and \(t\).