bash script memory size in gb

[rene]

How would you go up again, without using 1024 / 1024 / 1024?

Not sure I understand what you mean; n / a / b / c is simply n / (a * b * c); in this special case, n / 1024^3.

[Termy]

...

Yep, you answered the question exactly. Thanks! I don't fully understand it, because I suck at maths, but I have a basic understanding of it.

Thanks to your reply, I now understand that I can do this:

Code: Select all

free -b | awk '$1 == "Mem:" {printf("%.2f GiB\n", $3 / (1024 ^ 3))}'

Instead of this:

Code: Select all

free -b | awk '$1 == "Mem:" {printf("%.2f GiB\n", $3 / 1024 / 1024 / 1024)}'

To get the GiB from bytes.

[rene]

Yes. And just to reinforce my earlier reply then: note how e.g. 1024^3 has a precise (integer) representation also in the computer; when you divide by it you still introduce a potential round-off error inherent to floating point math --- but only once. If you do N / 1024 / 1024 / 1024 you have three such errors: "error upon error" which may in a manner similar to "interest upon interest" blow up significantly in the end if you're not quite careful.

As said, it felt a bit pedantic to point out, but when you do these things routinely that kind of thing jumps out at you. It's not a major problem in this specific instance but generally one should always strive to keep lossy operations such as divide to a minimum.

[Termy]

...

I had absolutely no idea that was a thing. I've never had any errors — that is — I've never had an incorrect number when dividing, as far as I know, but I only tend to use N.NNN at most, so I'm guessing this is only really a problem with numbers like N.NNNNNN, where such specificity is needed; is that right? What confuses me, now, is that you're still dividing by the (N ^ N) value, so don't you still wind up with the chance for an error?

[rene]

A very big thing even; it's the subject of numerical analysis. Yes, not only do you "wind up with the chance for an error", given necessarily finite-length computer representation of numbers said error potential is inherent to computer math: 1/3 or Pi, say, is never going to be exactly representable numerically in a computer.

As also said above though the thing is to as far as possible not amplify errors by chaining potential error producing operations one after the other. I.e., if you divide once by in this case 1024 * 1024 * 1024 you have only the one potential round-off/truncation whereas if you divide three times by 1024 you have that same issue three times.

In this case we were talking about awk and it in fact internally uses nice, large precision arithmetic so it's certainly here quite theoretical; given however that you replied to an already solved thread, i.e., in a general or tutorial-y sense, I still felt it wanted to be remarked upon.

[Termy]

...

If you have a YouTube channel talking about all this stuff, I'd happily watch it! Thanks for the information.

[rene]

If you have a YouTube channel talking about all this stuff, I'd happily watch it!

I feel it safe to say that there's few things which I have more not.

[FreedomTruth]

Is there a way to do script which shows (free -g + 1)?

Yes.

Code: Select all

echo 4

Haha That looks similar to some "random number generator" code I once saw.

[Termy]

Haha That looks similar to some "random number generator" code I once saw.

I'm guessing it was something along these lines:

Code: Select all

printf '%04d\n' $((RANDOM % 9999))

Which generates a random zero-padded number between 0 and 9999.