add option to invert data set so you can convert seconds into per seconds..

[jmg]

Summary

Invert data set...

[wblock]

usr.bin/ministat/ministat.1

56

This is a little confusing. Maybe show the fractions?

...inverting a set of time per value measurements into a set of value per time measurements...

[delphij]

usr.bin/ministat/ministat.c

491–495

Since we are going to divide by d later if invert, we should probably do:

if (invert && d == 0.)

err(2, "Invalid data on line %d: 0 is not allowed in inverted mode", line);

[imp]

Invert isn't the right terminology.
You are converting from the time domain to the frequency domain.
This is a fundamental conceptual faux pas.

[jmg]

In D3084#61045, @imp wrote:

Invert isn't the right terminology.
You are converting from the time domain to the frequency domain.
This is a fundamental conceptual faux pas.

Is there a specific terminology issue that you have or what? This patch only changes the values from x to 1/x, and as 1 is a constant, there is no issue with this conversion.

For example, I run a program that hashes 1 GB, and I measure the time it takes to do this operation. I compare it w/ another program that also hashes 1 GB. I now have two sets of data to compare. I can now calculate 1GB/xsec where x is the measured time which gives me the GB/sec that the program ran at. Since both sets have the 1GB constant, I can divide the constant out w/o effecting the results, resulting in 1/x, which is what this patch calculates.

[jmg]

I could also use the term reciprocal, but for me invert makes sense and is more common.

usr.bin/ministat/ministat.1

56

should I be more explicit in what x is? like:

All values are inverted, where x is a value, the value will be 1 / x, when they are added.

[jmg]

Update to add error when d == 0...

[jmg]

errx needed to be used instead of err as errno will not be set in this case.

[imp]

In D3084#61102, @jmg wrote:

In D3084#61045, @imp wrote:

Invert isn't the right terminology.
You are converting from the time domain to the frequency domain.
This is a fundamental conceptual faux pas.

Is there a specific terminology issue that you have or what? This patch only changes the values from x to 1/x, and as 1 is a constant, there is no issue with this conversion.

For example, I run a program that hashes 1 GB, and I measure the time it takes to do this operation. I compare it w/ another program that also hashes 1 GB. I now have two sets of data to compare. I can now calculate 1GB/xsec where x is the measured time which gives me the GB/sec that the program ran at. Since both sets have the 1GB constant, I can divide the constant out w/o effecting the results, resulting in 1/x, which is what this patch calculates.

I understand how you are using it. You are converting the time domain (elapsed time per 1GB run) to a rate (something in the frequency domain how many X per unit time something can do). this is done via an inversion, true (which is how you make that conversion). I do suppose there are other domain shifts that could be accomplished this way....

[wblock]

usr.bin/ministat/ministat.1

56

Well, yes. More specific is usually better. "x becomes 1/x" is more clear.

[jmg]

As "more" correct term was never provided, and phk also didn't like this change, no point in keeping this open.