# Size Matters

## Matters of Size

Nowhere does size matter more than in proper selection of data types. Accurate quantization of virtual properties or physical properties depend on decisions made at design time. Loosely typed languages such as php or perl along with strongly typed languages such as Java (not JavaScript) each present unique opportunities to embed nefarious logic errors in mission-critical software, unless matters of size are carefully considered.

## A simple example illustrating why size matters

Consider a simplified version of a discrete wavelet transform function:

## DWT(f(x)) = ΣΨj,k(x)

Assuming a Haar scaling function and also a Haar wavelet, we must consider the upper and lower bounds that will result from the calculation. Data type size becomes crucial. For the purposes of this discussion we will assume f(x) is a simple step function:

## We can see that size matters

From the (admittedly arbitrary) definition of our discrete function, we see that an improper selection of container size for the summation expression could result in disaster.

## Another example of why size does matter

A gross oversimplification of the size issue is without question the seemingly ubiquitous issue of overflow and underflow when dealing with integer types. Consider the following code snipped in C++:

## A simple example of why size matters

```#include <iostream>
#include <limits.h>
void main()
{
int alpha;
long int delta;
delta = INT_MAX;
alpha = ++delta;
}```

This code snipped illustrates an all-too-common problem in software development. The size of the integer data item, alpha, is not sufficient to handle the result of the calculation. The value of delta++ generates a value that exceeds the maximum possible number that can be stored in a signed integer data item. The assignment statement (line 8) evaluates properly, but the result of the assignment is usually unexpected and almost always improper; alpha is truncated. This code is deterministic, but often not properly understood. In other words, it works, but not the way that most programmers think it works. It's not broken, just misunderstood.

Let us examine this code in greater detail. In a typical modern development environment, 4 byte integers are the norm. A signed integer can range from -231 through +((231) - 1). In base 10, these values are -2147483648 through +2147483647 (for better or worse, these base 10 values are not at all intuitive. Digital computers store integers in base 2 format. We humans live in a base 10 world.). A signed long integer can range from -263 to +(263-1)) , or -922337203685477580810 to +922337203685477580710.

In line 7 of our code we store the maximum value of a signed 4 byte integer in a signed long integer. So far, so good. However, in line 8 we foment a logic error. A through understanding of the methodology employed by C++ to evaluate an assignment expression is necessary here. Keep in mind that line 8 contains two operators; the increment operator and the assignment operator. We know from the C++ order of operations rules that the increment is executed first because it is prepended to the delta symbol (commonly referred to as a "pre-increment' operator). After executing the increment operator, the assignment operator is executed. Given that C++ is not exactly a strongly typed operating system, the compiler happily adds an implicit data conversion in order to successfully complete the assignment operation; delta is coerced to a signed int and that result is stored in alpha. For better or worse the result of the coercion is a truncated version of what delta contains.

From this simple illustration we can see that size matters. Had alpha been declared as a long integer (as delta already was) then the result of the code would have been completely different. Allow us to reemphasize the fact that the code as written is not necessarily 'wrong'. It should be considered to be a completely predictable behavior of the C++ compiler. The code can only be considered 'correct' or 'incorrect' when taken in a greater context. We do not claim to provide that context here; should there be sufficient future interest, we will supply additional code and discuss a larger framework in which this matter of size may be quantitatively judged as right or wrong.

## Conclusion

We hear it all the time. It's become a mantra in the computer science field: size matters. We have demonstrated two situations in which this is indeed true.

## More by this Author

greatAmerican 6 years ago

It might matter to some, but when you get to be 79 years old

even little things mean a lot!!

fishtiger58 6 years ago from Momence, Illinois

wow I didn't understand a word your said.Lol I kept waiting for the punch line. Most of the hubs of yours I have read have been funny. Ummmm nice hub???

psychicdog.net 6 years ago

I have struggled with this when assigning size to data types in mysql databases. Basically, I try and keep it down to the bare minimum to reduce space and increase efficiency but alas many a time I have been truncated! Thanks for the info and this is the first time I've heard of the distinction between loosely and strongly typed languages.

The Old Firm 6 years ago from Waikato/Bay Of Plenty, New Zealand

You really can be a nasty sarcastic smartarsed bastard when you set your mind to it can't you?

I may still think base ten, (with leanings to base twelve, twenty, and multiples of four from my childhood imperial schooling), but in reality, aren't we all, like my two finger typing, dependant on base two to exist in this world of computer dependence?

Regards.

nicomp 6 years ago from Ohio, USA Author

@The Old Firm: yes, and yes. :)

drbj 6 years ago from south Florida

nicomp - Are you feeling all right? Are you hearing any strange voices or seeing any peculiar visions?

I must be from the old school. Upon reading the title of this hub, I anticipated an article emphasizing (with the exphasis on size) entirely different subject matter.