Maybe calculus does strange things to the brain.

Well, I suppose part of it is context. And the units -- you're allocating memory in increments of 4 what?

The way I parse your question, it sounds to me like you're saying that, from the operating system, you can manually allocate memory for a particular application. If so, wow, I would not have expected that to even be an option on a modern consumer OS (I say that without any offense intended toward MacOS -- it's just that memory management can be handled much better by the OS than by humans, and I'm sure MacOS will do it on its own, and that the feature of being able to override memory management would be something I'd only expect to see on a research OS). But, if you can do this, then I'd suggest allocating memory in multiples of the page size -- modern OSes organize memory in "pages".

If you're talking about allocating memory while programming, then it's a different story. First, why do we use hexadecimal? Because it's a conventient way to short-hand binary. Each hexadigit represents four bits in less written (or verbal) space. Even more convenient, two hexadigits exactly represent the value of one byte, which is handy when we're examining the contents of a memory location. But we use hexadecimal for other uses too, such as addressing, where it's just easier to poke address 0x0A439F30 than to write out (or worse, verbalize) the 32 bits corresponding to that hexadecimal notation.

So, as a programmer, should you allocate memory in units of 4? (Again, 4 what?) I suppose since you're focused on hexadecimal notation, you might be talknig about allocating memory in units of 4 bits. That's just a little too fine-grained. All primitive datatypes on modern computers are multiples of bytes. Yes, you could be working with a bitfield, but as a self-declared newbie, I find that unlikely, and even if you were working with a bitfield, the compiler will allocate memory rounded up at least to byte multiples (if not word multiples).

But let's assume you're not talking about allocating memory at the bit granularity. That is, you're doing something like
int *I = malloc( numelements * sizeof[int] );
Then my suggestion is in two parts. If you really think you're more clever than the compiler, allocate memory at least in multiples of words or better yet, in multiples of cache line sizes.

But let's assume you don't think you're more clever than the compiler (because, trust me, you aren't, and most likely, neither is anyone else on this board -- I can count on one hand the number of people I've met whom I believe could do a better job than the compiler; two hands for the number of people who can do clever things by taking advantage of the compiler's cleverness). Then allocate exactly how much memory you need for that data structure. No more, no less. Why? First, it'll be more maintainable. Second, the compiler will either allocate memory at the appropriate granularity for good performance for that data structure or will take advantage of the memory allocation requests for multple data structures to get a good all-around efficiency. Third (and this is the clincher), if you were to request a certain amount of memory, say 32 bytes, the compiler is actually going to block off more than what you're requesting (perhaps 34 bytes -- there are too many factors involved for me to make a good guess) since it needs a certain amount of overhead for runtime memory management. If you're allocating staticly-sized arrays (e.g., int J[8]; ), then the third factor can be ignored, but the second factor becomes even more prominent.

So my advice: when programming, allocate exactly what you need (unless you know you're Very Clever and you need to be Very Clever and are willing to provide good documentation for future maintainers). At the OS level, let the OS' memory manager do its job and don't try to outsmart it.

To answer donnab's question, yes I expect that memory is allocated in multiples of a certain size, which is likely to be a power of 2, but I've never worried much about what it is - if it was large enough to be an issue I expect I'd have heard about it somewhere by now.

In the case of programming, most allocators actually consume more storage than you ask for (for recordkeeping), so rounding up can be detrimental.