Matrix Games Forums

ORIGINAL: treespider

ORIGINAL: herwin


Please go back to the opening message of this thread. I don't see anything about the developers team.

Long ago, Joe Wilkerson and I did research on IJA Airborne and Armor units
This research seems to have eluded the AE data set

Same as the tanks, Joe and I collected papers and books, and did OB research
which seems to have not survived into AE - where people are being creative
or making assumptions.

I did slightly participate in the discussion when the pre release map showed removal of trails at PM. I have several times reviewed the matter - including this week - and cannot reconcile the removal with how the historical campaign was done - or the options players ought to face.

And for the record, no one put in more man years of work on the economic model than I did. I am not doing entirely new research - just looking it up again. Because it is done.

What is the inference from these recent statements by L. Sid?

That Sid was working with Joe several years ago. That's consistent with what I know about them. That he has done a lot of work on economic modelling of the Pacific War. That's also consistent with what I know about Sid. Remember, there was a lot of work done before the AE team was assembled, and a lot of people who did that work were not on the AE team.

Harry, I think it is pretty clear that the overall impression being given is that he has/had the inside track and special knowledge, and even the posts above are certainly a reproach of the AE Team for not accepting his work and conclusions (although I'm not sure how or in what form he provided it). I urge you to look at more than just this one thread.

ORIGINAL: treespider

ORIGINAL: herwin


Please go back to the opening message of this thread. I don't see anything about the developers team.

Long ago, Joe Wilkerson and I did research on IJA Airborne and Armor units
This research seems to have eluded the AE data set

Same as the tanks, Joe and I collected papers and books, and did OB research
which seems to have not survived into AE - where people are being creative
or making assumptions.

I did slightly participate in the discussion when the pre release map showed removal of trails at PM. I have several times reviewed the matter - including this week - and cannot reconcile the removal with how the historical campaign was done - or the options players ought to face.

And for the record, no one put in more man years of work on the economic model than I did. I am not doing entirely new research - just looking it up again. Because it is done.

What is the inference from these recent statements by L. Sid?

He's inferring that he was on the team, and lying his ass off as usual.

ORIGINAL: witpqs

Harry, I think it is pretty clear that the overall impression being given is that he has/had the inside track and special knowledge, and even the posts above are certainly a reproach of the AE Team for not accepting his work and conclusions (although I'm not sure how or in what form he provided it). I urge you to look at more than just this one thread.

He provided NO work/ideas/knowledge/conclusions whatsoever for AE. None. Zip. Zero. Nada. Zilch.

ORIGINAL: Terminus

ORIGINAL: witpqs

Harry, I think it is pretty clear that the overall impression being given is that he has/had the inside track and special knowledge, and even the posts above are certainly a reproach of the AE Team for not accepting his work and conclusions (although I'm not sure how or in what form he provided it). I urge you to look at more than just this one thread.

He provided NO work/ideas/knowledge/conclusions whatsoever for AE. None. Zip. Zero. Nada. Zilch.

Apparantly it's Sid's "beat" that goes on and on and on. [8|]

ORIGINAL: Terminus

Easy, Mac... "JWE" is just reacting to "el cid again" and his looooooong history of disingenuousness on the forum.

I'm aware of that, but this is not the first time I have seen JWE acting in such a way towards another poster here. Also, threatening to drop El Cid's service record on Matrix reeks of playground bully tatics to me.

Not to mention a clear violation of forum rules. It gets tiresome seeing "oldboys" getting away with stuff that "noobs" have been warned or banhammered for.

Whats good for the goose is good for the gander and all that...

ORIGINAL: Andy Mac

I agree with Andrew and Don on this one

+3

EDIT: This is a message to herwin

Please go back to the opening message of this thread. I don't see anything about the developers team.

No need. See next quote from him (Thread "Sloops" Post #7, 25 May 2011).

In AE different designations have different code effects.

He does try to mislead newbies (and those unsuspecting) by pretending to have code knowledge (which he can't have).
You may prefer to ignore that. I don't.
But I think we should put it rest. Doesn't make sense really.

ORIGINAL: witpqs

Harry, I think it is pretty clear that the overall impression being given is that he has/had the inside track and special knowledge, and even the posts above are certainly a reproach of the AE Team for not accepting his work and conclusions (although I'm not sure how or in what form he provided it). I urge you to look at more than just this one thread.

Why does that lead to ad hominem attacks? What the AE team did was extremely impressive and can stand on its own objective merits.

ORIGINAL: Rainer

EDIT: This is a message to herwin

Please go back to the opening message of this thread. I don't see anything about the developers team.

No need. See next quote from him (Thread "Sloops" Post #7, 25 May 2011).

In AE different designations have different code effects.

He does try to mislead newbies (and those unsuspecting) by pretending to have code knowledge (which he can't have).
You may prefer to ignore that. I don't.
But I think we should put it rest. Doesn't make sense really.

Just curious--you know the difference between white-box and black-box testing? You can make valid claims about what the code is doing based on black-box testing. See such papers as this and this. I suspect what Sid means is that he has inferred that the code does certain things based on its behaviour. That's a valid claim and requires no explicit code knowledge.

ORIGINAL: herwin

ORIGINAL: witpqs

Harry, I think it is pretty clear that the overall impression being given is that he has/had the inside track and special knowledge, and even the posts above are certainly a reproach of the AE Team for not accepting his work and conclusions (although I'm not sure how or in what form he provided it). I urge you to look at more than just this one thread.

Why does that lead to ad hominem attacks?

I didn't say it should. I did say misinformation should be challenged.

ORIGINAL: witpqs

ORIGINAL: herwin

ORIGINAL: witpqs

Harry, I think it is pretty clear that the overall impression being given is that he has/had the inside track and special knowledge, and even the posts above are certainly a reproach of the AE Team for not accepting his work and conclusions (although I'm not sure how or in what form he provided it). I urge you to look at more than just this one thread.

Why does that lead to ad hominem attacks?

I didn't say it should. I did say misinformation should be challenged.

There are acceptable and unacceptable ways to challenge misinformation. ad hominem argument is usually unacceptable.

Time to end this thread, me thinks.

deleted

One last comment before this goes to bed.

I asked Sid and confirmed that he meant he has inferred that the code does certain things based on its behaviour. That's a valid claim--particularly from a tester--and requires no explicit code knowledge. I study the neural production of behaviour, and drawing inferences about the neural code is exactly what I do. Usually, I don't have access to *that* source code.

Bye,

You keep missing the point, It's all in how one presents themselves. One can clearly state that one thinks, based on testing, or whatever that code seems to do this or that. Sid doesn't just imply code knowledge based on 'testing', he words his posts to make it appear that the code DOES do this or that and WILL do this or that and then justifies it with inferences and false claims that it's due to insider knowledge via access to the code itself or having the ear of someone like JoeWilkerson. There is nothing legitimate about making false claims and inferences to try to strengthen one's standing and opinion. It's deceptive and misleading. It is not scientific in any way shape or form. You should know that based on your own signature. Sid can dance around that fact all he wants while you quibble over what he really means vs. what he writes, but that essential truth remains.

But like Don said.....it's time for this thread to end. Sid will continue to do what he's always done. The important point is that unwary posters know the score now.

Nik

I am a trained deception specialist as well as something of a wordsmith, particularly in English.
And the Forum is not a place for formal writing - it is a place for off the cuff comments made without review -
as informal as writing gets. Deceptive communication does not stand the test of time ( usually ) - it is a
poor strategy and I NEVER use it - outside an arrest situation ( on military police duty ) or combat of some
sort. Your assertion is based on an assumption, and it is an incorrect assumption. You might be well
advised to make less negative assumptions.

As a technical guy, if I know something, I take responsibility for saying it, directly, in the simple assertion
sense. And as a tester, I have a good handle on figuring out how something works. I also do have the
ability to ask if I want to bother someone with access to code. [Someone it is said, as incorrectly as that
I am deceptive, I do not know.] At one point, after years of working on a specific part of code, he felt I
had as good a grasp of how it worked as he did. It is common for code NOT to work as intended. A tester
tells you how it ACTUALLY works, whatever the coders may think about how it is supposed to work. This
because the tests (usually) reveal what output range is possible for given inputs, other things being held
constant.

I happen to really be respectful - in general - and of you in particular. I think you are reading what is
written with too negative a set of assumptions. I am not here to argue - only to illuminate and inform -
and to be corrected or illuminated if someone can do that? I will not be drawn into hostile name calling,
and I do not assume - even when you are wrong ( as you are when you assume I was ever deceptive )
that you are my enemy. This is supposed to be an open forum - yet more than half a dozen people have
written me saying they feel it is closed - that it is too much of a hassle to dare to try to say anything other
than "everything is perfect already." I don't believe in perfection, or in one size fits all - or in looking for
trouble when no one is trying to dish it out. If I say it - possibly imperfectly as this is not a paper
submitted for publication - it is to the best of my ability true. Even in the face of the enemy, I use truth
as the SOP, the only way to have a shot at slipping in a deception that will work even for a moment.

ORIGINAL: el cid again

Nik

I am a trained deception specialist as well as something of a wordsmith, particularly in English.
And the Forum is not a place for formal writing - it is a place for off the cuff comments made without review -
as informal as writing gets. Deceptive communication does not stand the test of time ( usually ) - it is a
poor strategy and I NEVER use it - outside an arrest situation ( on military police duty ) or combat of some
sort. Your assertion is based on an assumption, and it is an incorrect assumption. You might be well
advised to make less negative assumptions.

As a technical guy, if I know something, I take responsibility for saying it, directly, in the simple assertion
sense. And as a tester, I have a good handle on figuring out how something works. I also do have the
ability to ask if I want to bother someone with access to code. [Someone it is said, as incorrectly as that
I am deceptive, I do not know.] At one point, after years of working on a specific part of code, he felt I
had as good a grasp of how it worked as he did. It is common for code NOT to work as intended. A tester
tells you how it ACTUALLY works, whatever the coders may think about how it is supposed to work. This
because the tests (usually) reveal what output range is possible for given inputs, other things being held
constant.

Sid, I don't think it helps your credibility to pontificate your purported expertise in the atmosphere of this forum. At this point it would be very helpful for you to site specific verifiable sources of the training and background expertise to be able to muster a base of respect that you have apparently lost.

I don't say this to further pile on with the others. I read and appreciate all information from everybody, and when I find exception, after verification, I follow my own course in my Mod.

I asked Sid and confirmed that he meant he has inferred that the code does certain things based on its behaviour. That's a valid claim--particularly from a tester--and requires no explicit code knowledge.

There is an essential caveat to that, and to black-box testing in general. The completeness/validity of the assumptions you draw depends very heavily on whether you know all of the possible inputs and outputs to the piece of code in question. If you know all of the inputs then you can make definitive assertions about the behaviour, if you don't know all of the inputs, then there may be fundamental sensitivity to conditions you aren't testing. If you don't know all the outputs, there may be side effects you are completely unaware of that invalidate what you assume is identical behaviour across several different sets of inputs and the resultant outputs.

(Simple example for the non-coders, imagine testing the behaviour of a piece of code by varying A and B, the two inputs you know about, but what if there is a third input, C, and the code says that if C is false, reverse the result..., your assumptions based on the behaviour observed with A and B is then only true in some cases).

I don't know anything about the internal coding of AE, but what I've read in various places hints that the code is very likely riddled with conditional rules based on scores of different inputs, and not knowing what those inputs are and which are significant in which piece of code means we draw assumptions from black-box testing at very considerable peril of those assumptions being incomplete if not outright wrong. I would be very loathe to say 'X is true' about the code without one of the development team having confirmed it first.

ORIGINAL: dwg

I asked Sid and confirmed that he meant he has inferred that the code does certain things based on its behaviour. That's a valid claim--particularly from a tester--and requires no explicit code knowledge.

There is an essential caveat to that, and to black-box testing in general. The completeness/validity of the assumptions you draw depends very heavily on whether you know all of the possible inputs and outputs to the piece of code in question. If you know all of the inputs then you can make definitive assertions about the behaviour, if you don't know all of the inputs, then there may be fundamental sensitivity to conditions you aren't testing. If you don't know all the outputs, there may be side effects you are completely unaware of that invalidate what you assume is identical behaviour across several different sets of inputs and the resultant outputs.

(Simple example for the non-coders, imagine testing the behaviour of a piece of code by varying A and B, the two inputs you know about, but what if there is a third input, C, and the code says that if C is false, reverse the result..., your assumptions based on the behaviour observed with A and B is then only true in some cases).

I don't know anything about the internal coding of AE, but what I've read in various places hints that the code is very likely riddled with conditional rules based on scores of different inputs, and not knowing what those inputs are and which are significant in which piece of code means we draw assumptions from black-box testing at very considerable peril of those assumptions being incomplete if not outright wrong. I would be very loathe to say 'X is true' about the code without one of the development team having confirmed it first.

I'm in agreement. After a while, particularly if you've run sensitivity tests like el_cid has, you will have a reliable black box model of what the system does. JFD once described it as the COW effect--a lot of the details come out in the wash--even up in the end--if you have a valid model. If you've been overrun by the detail, you get another effect--see Military Modelling for Decision Making, 3rd edition, Wayne P. Hughes, Jr., ed., 1997. Starting on page 50, he writes "On Model Stricture, or Stifling Thought", where he criticises the way complicated opaque models inhibit imagination and creativity. "Too much detail for the sake of realism is confusing and self-defeating." He then gives examples of systems that had to be abandoned because they "contain coding mysteries that produce counterintuitive, unexplained results."