# Windows event log viewer

• @dhromed said:

I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).

No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.

• @morbiuswilters said:

And I never use the numpad, really. I'm only typing short sequences of digits,

Never got that 4+ digit paycheck, did you?

• @morbiuswilters said:

@dhromed said:
I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).

No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.

I mean if you calculate pi to some arbitrary length, and randomly chunk it, then take the first digit of each chunk. The naturalness of pi will probably negate the randomness of the chunk length.

I am probably spouting complete nonsense, negating the randomness of my point.

Edit.

Or rather, chunk it with exponentially increasing chunk length.

Edit II

Eh, still nonsense, probably.

• @dhromed said:

You're randomly generating numbers?

Nope, just counting up sequentially.

I considered adding a "modifier for popularity", i.e. 2 digit numbers are 5 times more popular than 3-digit numbers which are 5 times more popular than 4 digit numbers, etc. But I didn't know what the proportions were in real-world data so I didn't.

So it just counts from zero, and counts the digits in each number.

Source code or something.

• @blakeyrat said:

So it just counts from zero

Try an exponential growth function.

counts the digits in each number.

Wait, your program counts the number's length in digits, or counts the occurrences of each first digit? Because of you just count up, then nothing's going to happen either way.

• @dhromed said:

@morbiuswilters said:

And I never use the numpad, really. I'm only typing short sequences of digits,

Never got that 4+ digit paycheck, did you?

Well, I'm never typing my paycheck into my computer, so my point stands. I did get a 5 digit paycheck once, but it turned out to be a clerical error and I had to give most of it back.

• @dhromed said:

counts the digits in each number.

Wait, your program counts the number's length in digits, or counts the occurrences of each first digit? Because of you just count up, then nothing's going to happen either way.

I linked to the fucking code. Read the fucking code. Don't be helpless.

```Current number: 5301147692
0	4731815921	9.11711477798382%
1	5840874724	11.2540145583851%
2	5840679339	11.253638096684%
3	5741827031	11.0631725643913%
4	5740677031	11.0609567803942%
5	5041817031	9.71441521155079%
6	4740669331	9.13417325119879%
7	4740668931	9.13417248049131%
8	4740668239	9.13417114716738%
9	4740668231	9.13417113175323%
```

• @blakeyrat said:

I linked to the fucking code. Read the fucking code. Don't be helpless.

Oh shit, Blakeyrat open sourced some of his code and now he's become a stereotypical Open Sores developer!!!

• @blakeyrat said:

I linked to the fucking code. Read the fucking code. Don't be helpless.

I just read the fucking code anf it fucking looks like it's fucking doing the right fucking thing but I didn't fucking investigate fucking further, but I do fucking know that you fucking should not just fucking add 1 for every fucking iteration because that's fucking not going to fucking work.

•  @morbiuswilters said:

@blakeyrat said:
I linked to the fucking code. Read the fucking code. Don't be helpless.

Oh shit, Blakeyrat open sourced some of his code and now he's become a stereotypical Open Sores developer!!!

I was planning on responding to comments on my code such as "That code is complete shit." with a mirthful "That's because I made it open source. It was fine when I wrote it!"

• @dhromed said:

I just read the fucking code anf it fucking looks like it's fucking doing the right fucking thing but I didn't fucking investigate fucking further, but I do fucking know that you fucking should not just fucking add 1 for every fucking iteration because that's fucking not going to fucking work.

I don't understand what you're trying to say.

```Current number: 9288350335
0	8320969398	9.06696359873671%
1	9432080174	10.2776880321876%
2	9420430509	10.2649939477078%
3	9332030439	10.1686686064551%
4	9331980064	10.1686137152195%
5	9331970398	10.1686031826402%
6	9331970063	10.1686028176067%
7	9331970063	10.1686028176067%
8	9329670733	10.1660973473406%
9	8609320398	9.38116593449914%
```

• Blakey: I don't get WTF you're doing.
If you're just counting sequentially up to a certain number, you can simply calculate the percentage of that without a computer: How many of the numbers from 0 to 999 start with a 1? Answer is obviously 111. The described distribution comes from the numbers being distributed by a power law, not uniformly.

@dhromed said:

I mean if you calculate pi to some
arbitrary length, and randomly chunk it, then take the first digit of
each chunk. The naturalness of pi will probably negate the randomness of
the chunk length.

I am probably spouting complete nonsense, negating the randomness of my point.

Edit.

Or rather, chunk it with exponentially increasing chunk length.

Edit II

Eh, still nonsense, probably.

Yes, nonsense. Pi is assumed (though not conclusively proven) to be normal, i.e. the digits are distributed uniformly.

• @PJH said:

@erikal said:
Must be, you can't explain it away as a typo. On no keyboard I know of the 8 is next to the 4.
Is this close enough for you?:

IAmActually using this keyboard layout. AMA.

Another peculiarity: the num pad is reordered 123-456-789 instead of 789-456-123 and can type hexadecimal numbers (A to F is shift+1 to 6) as well as parentheses, the letter x (for hex constants) and some more characters (\$,;=:). The European version of the keyboard uses the extra key next to shift as a compose key for intuitive access to foreign characters like é, ë or ß, and even exotic characters like İ, ő and þ. Greek letters are also easy to type.

• @dhromed said:

I was planning on responding to comments on my code such as "That code is complete shit." with a mirthful "That's because I made it open source. It was fine when I wrote it!"

In the code, that is...

• @topspin said:

Yes, nonsense. Pi is assumed (though not conclusively proven) to be normal, i.e. the digits are distributed uniformly.

I see.

• @Anonymouse said:

@error_NoError said:

The Maximum Log Size specified is not valid. It is too large, too small, or not a multiple of 64KB. The Maximum Log Size will be set to the following: 1028KB
So, according to Microsoft Math(tm), 1028 is a multiple of 64?

Not necessarily.  They may have meant something like the following:

The Maximum Log Size specified is not valid. It is too large, too small, or not a multiple of 64KB. If it's set to a value which is not a multiple of 64KB, every time the log fills, a chunk of the log file equal to the Maximum Log Size mod 64KB will be corrupted.  This will continue until the entire log file is corrupted.  After that, every time the log fills, a chunk of that size will be rendered usable again.  Once the whole file is once again uncorrupted, the cycle will repeat.  You have set it to such a value.  ENJOY!

Of course, substituting the real bug description for mine.  I just came up with something entertaining.  I haven't looked at the Windows Event Viewer since discovering that it was a nice concept, but a shame they didn't generate all of the events that one might want, and didn't include key details about some of the events.  That was over a decade ago, so 1. I can't provide further details, 2. They've probably fixed my actual issue from that time, 3. There's probably more issues of the sort I had that they've since coded, some of which have also been fixed.  I am, after all, not a Windows admin.

(Sadly, I've used software which detected configuration errors, complained about them, but accepted them and used the broken values.  My 'favorite' such application also did a configuration check when one opened the configuration dialog, and would abort if the configuration was currently broken.  So if you closed the configuration dialog after applying a broken configuration (such as if you had hit 'Ok', rather than 'Apply'), the only three fixes were manually editing the configuration file (with a hex editor), restoring the configuration file from a backup, and uninstalling and reinstalling the software.  Fortunately, this happened before the application was updated to use the Registry.)

• This thread inspired me to go look up the event viewer. I don't know much about it never having done much admin/IT work but it looks like amdkmdag is one hell of an event spammer. Over 90% of my events are from that one service, all of remarking that I don't have a HDCP display connected because I have the nerve to use a VGA monitor. It is crapping these messages out non-stop. WHO THE HELL LET THIS THROUGH QA

• @nexekho said:

This thread inspired me to go look up the event viewer. I don't know much about it never having done much admin/IT work but it looks like amdkmdag is one hell of an event spammer. Over 90% of my events are from that one service, all of remarking that I don't have a HDCP display connected because I have the nerve to use a VGA monitor. It is crapping these messages out non-stop. WHO THE HELL LET THIS THROUGH QA

Oh, still?  Last I looked at the event viewer, it was crapping out similar messages because I had the nerve to use something or other that wasn't the latest and greatest that the computer supported.  However, a friend of mine assured me, if I had the latest and greatest, it'd be crapping out messages about not having the old crap.

That's the flipside reason why event viewer is suboptimal, but I didn't feel like griping about it.  Logging *something* is better than logging nothing, IMHO.  Until, of course, your disk fills; then you're logging nothing regardless.

Back in the '90s, my unix syslog had this feature, if something logged the same message to it multiple times in a row, it wouldn't log the second instance.  Instead, it would simply count them, and then when someone *finally* logged something different, it would log a line with the timestamp of the last repeated message (more often than not, the current timestamp - but if you made the chatterbox stop, it could potentially be minutes earlier) saying "last line repeated \$count times".  That was over a decade ago.  Why doesn't Microsoft have something like that?

(Note: I understand where the counting concept fails when you have a centralized loghost.  But as long as you're smart enough to compare hostnames, it's much less of a problem than the repeated log lines.  Also, my current unix system does something more sophisticated - but I'd rather not get into that here, because it's a bit complicated.  I'm only mentioning it, because it doesn't have the same multi-host confusion issue.  It skips that by logging the repeated line a second time, right before the count, but there's more to it.)

• @tgape said:

Back in the '90s, my unix syslog had this feature, if something logged the same message to it multiple times in a row, it wouldn't log the second instance.  Instead, it would simply count them, and then when someone finally logged something different, it would log a line with the timestamp of the last repeated message (more often than not, the current timestamp - but if you made the chatterbox stop, it could potentially be minutes earlier) saying "last line repeated \$count times".  That was over a decade ago.  Why doesn't Microsoft have something like that?

The *nix method is to alter verbosity at service or syslog level, so that the file contains just the messages at the required level of detail. Microsoft's method is to log it all[1] then use the filters in the event viewer to alter the level of detail at exposure level, rather than at capture level. AFAIK, there is some quota control and automatic truncating to prevent files growing out of control.

I don't know which is a more effective method - Microsoft's allows you to drill down more deeply if the required level isn't displayed, which requires a change and rehash of syslog under *nix. I've always followed the "capture everything then turn down noise as you go" rule of thumb from the *nix world, and used logwatch to throw anything interestng over email. Both have their pros/cons.

[1] again, I'm not a win sysadmin/dba/etc so I don't know if the level of logging to the event viewer is customisable.

• @morbiuswilters said:

@dhromed said:
I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).

No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.

Actually it applies to all digits of any number that is potentially a "counting sequence", transcendentals are not.

To make is clear... Consider if the numbers are constrain to be between 1 and 199. The first digit will clearly be a 1 more than anything else (actually everything else combined)... But now look if the constraint is between 1 and 219. For numbers where the first digit is two, we have eliminated all used of 2 thru9 in the second digit, therefore increasing the probability of there being a 1 in the second digit across the board..The same logic can be extended for any number of digits.

Now in the general case the (upper) bounds of the number is not known, therefore one calculates the percentages for every possible upper limit and uses the average. Since there are no upper limits where the probability of a higher digit will exceed (it may equal) that of a lower digit, and since there are limits where the probability of a lower digit, in any position, will be higher, the generalization holds.

• @TheCPUWizard said:

@morbiuswilters said:

@dhromed said:
I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).
No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.

Actually it applies to all digits of any number that is potentially a "counting sequence", transcendentals are not.

To make is clear... Consider if the numbers are constrain to be between 1 and 199. The first digit will clearly be a 1 more than anything else (actually everything else combined)... But now look if the constraint is between 1 and 219. For numbers where the first digit is two, we have eliminated all used of 2 thru9 in the second digit, therefore increasing the probability of there being a 1 in the second digit across the board..The same logic can be extended for any number of digits.

Now in the general case the (upper) bounds of the number is not known, therefore one calculates the percentages for every possible upper limit and uses the average. Since there are no upper limits where the probability of a higher digit will exceed (it may equal) that of a lower digit, and since there are limits where the probability of a lower digit, in any position, will be higher, the generalization holds.

What? No.  It doesn't apply to counting sequences at all.  It applies to natural sequences.

• @Sutherlands said:

What? No.  It doesn't apply to counting sequences at all.  It applies to natural sequences.

You are correct, I was not being mathematically correct. My intent was to indicate that it applied when the set of numbers starts at 1 (or 0), increments by 1, and has a uniform distribution.

An example where it would not apply is speed limits. In the USA these range from 5mph to 75mph and almost invariably are a multiple of 5 (I have seen one legitimate sign in my life that was not). As a result, this set of numbers would have a radically different distribution of digits.

• @TheCPUWizard said:

My intent was to indicate that it applied when the set of numbers starts at 1 (or 0), increments by 1, and has a uniform distribution.

That's still not what it applies to.  The distribution is nothing alike.

• @Sutherlands said:

@TheCPUWizard said:

My intent was to indicate that it applied when the sltiples of et of numbers starts at 1 (or 0), increments by 1, and has a uniform distribution.

That's still not what it applies to.  The distribution is nothing alike.

Of course it is. If you think I am wrong, explain how "1" could possibly be more common in numbers, if all of the numbers in question are:

* Multiples of 5
or
* Non-Prime

The increased probability of "1" (and other low digits relative to higher digits) applies when the distribution is even, but the range of number may be limited such that not all n-digit possible numbers are in the set, but a contigous range is.

• @TheCPUWizard said:

@Sutherlands said:

@TheCPUWizard said:

My intent was to indicate that it applied when the sltiples of et of numbers starts at 1 (or 0), increments by 1, and has a uniform distribution.

That's still not what it applies to.  The distribution is nothing alike.

Of course it is. If you think I am wrong, explain how "1" could possibly be more common in numbers, if all of the numbers in question are:

* Multiples of 5
or
* Non-Prime

The increased probability of "1" (and other low digits relative to higher digits) applies when the distribution is even, but the range of number *may* be limited such that not all n-digit possible numbers are in the set, but a contigous range is.

learn2read?  First off, I'm not arguing what you're trying to pin me on.  Second, {10, 15, 20} (just for a quick disproof, although this really doesn't have to do with anything).

Have you looked at the distribution curve for Benford's law?  It's 30%, 18%, 13%, 10%, 8%... etc for the respective numbers.  Find me one counting sequence that follows that distribution.  Benford's law is for natural sequences, and is best expressed over multiple orders of magnitude.  Things like... finding possible fraud on income statements.  It has much more to do with exponential sequences such as growth due to interest than any incremental distribution.

• @Sutherlands said:

learn2read? First off, I'm not arguing what you're trying to pin me on. Second, {10, 15, 20} (just for a quick disproof, although this really doesn't have to do with anything).

Have you looked at the distribution curve for Benford's law? It's 30%, 18%, 13%, 10%, 8%... etc for the respective numbers. Find me one counting sequence that follows that distribution. Benford's law is for natural sequences, and is best expressed over multiple orders of magnitude. Things like... finding possible fraud on income statements. It has much more to do with exponential sequences such as growth due to interest than any incremental distribution.

I am not trying to pin anything on you, and I have already admitted the use of the mathematical term "counting sequence" was incorrect on my part. MY point was that one must be careful what it is applied to (for example, with the number set I provided, you get a distribution of

<colgroup><col style="width: 48pt;" span="10" width="64">

 50.00%14.29%14.49%14.49%14.49%50.00%14.49%14.49%0.00%0.00%

• @TheCPUWizard said:

In the USA these range from 5mph to 75mph...

Texas has a few roads with 80mph speed limits. And they have the statutory ability to set 85mph limits, the highway department just has yet to do so.

• @TheCPUWizard said:

(for example, with the number set I provided, you get a distribution of

 50.00%14.29%14.49%14.49%14.49%50.00%14.49%14.49%0.00%0.00%

I'm confused... you're saying this DOES follow Benford's law, which has a distribution of 30%, 18%, 13%, 10%, 8%...?

• @Sutherlands said:

@TheCPUWizard said:

(for example, with the number set I provided, you get a distribution of

 50.00%14.29%14.49%14.49%14.49%50.00%14.49%14.49%0.00%0.00%

I'm confused... you're saying this DOES follow Benford's law, which has a distribution of 30%, 18%, 13%, 10%, 8%...?

I am saying that they do NOT follow Benford's law (because it is an attempt to inappropriately apply the law to this set of numbers). 50% of all numbers in this set wil contain a "0". 50% will contain a "5". 14.49% will contain (each) a "1,2,3,4,5,6,7" and none (Mo<font face="Calibri">rbius's Texas comment being ignored) will contain an "8" or "9".</font>

Therefore if one analyzed the data, found that it did not follow the distribution of Benford's law, and therefore treated it as "fraudulent data" they would be totally off-base.

• @morbiuswilters said:

Texas has a few roads with 80mph speed limits. And they have the statutory ability to set 85mph limits, the highway department just has yet to do so.

I think they just got rid of the night time speed limits too.

• @TheCPUWizard said:

I am not trying to pin anything on you, and I have already admitted the use of the mathematical term "counting sequence" was incorrect on my part. MY point was that one must be careful what it is applied to (for example, with the number set I provided, you get a distribution of

 50.00%14.29%14.49%14.49%14.49%50.00%14.49%14.49%0.00%0.00%

That's not even the correct distribution (assuming you are applying Benford's law to your speed limit example). You've shown the probability that a number contains a certain digit anywhere in the number, while Benford's law is (primarily) concerned with the leading digit.

• @barrabus said:

@TheCPUWizard said:

I am not trying to pin anything on you, and I have already admitted the use of the mathematical term "counting sequence" was incorrect on my part. MY point was that one must be careful what it is applied to (for example, with the number set I provided, you get a distribution of

 50.00%14.29%14.49%14.49%14.49%50.00%14.49%14.49%0.00%0.00%

That's not even the correct distribution (assuming you are applying Benford's law to your speed limit example). You've shown the probability that a number contains a certain digit anywheret  in the number, while Benford's law is (primarily) concerned with the leading digit.

What was previously discussed, was that Benford's law applies to all digits, but in the general case to a diminishing degree as one gets further away from the leading digit. What I have been illustrating is that application of this law may not be appropriate if there are constraints (known or unknown) on the underlying data. In this particular case, the fact that all numbers are multiples of 5, and that there is an upper bound, skews the probabilities for all digit positions, and even elimates any differentation for the first digit provided it is between 1 and 7 (8 and 9 will never occur)

The application of any statistical (using the term loosely) analysis in a manner that does not take into account the undrlying data, is probably (grin) the single largest abuse, and responsible for much of the "numerical garbage" that floats around society.

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.