From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Hans Ronne <hronne@comhem.se>
Cc: xconq7@sources.redhat.com
Subject: Clearing the Air (long)
Date: Fri, 20 Aug 2004 03:29:00 -0000 [thread overview]
Message-ID: <412556EF.80401@phy.cmich.edu> (raw)
In-Reply-To: <l03130306bd4ac13f0bec@[212.181.162.155]>
Debugging email is a tiresome business and I think both of our efforts
could better be spent doing other things. However, I do feel compelled
to reply to this, and attempt to set things to right.
We have worked together on this project for over a year now, and I doubt
it would be good for the project if our collaboration were to end. So,
I'll make another attempt to clarify and rectify.
Hans Ronne wrote:
> by changing the
> subject to fire-at in the middle of our discussion.
I don't know how this could be construed as changing the subject. In
practically every case where I mention 'fire-at', there is a
corresponding mention of 'fire-into' lying near at hand. Comparison and
contrast are legitimate tools to use in a debate.
>But perhaps this was a
> misunderstanding? Let's recapitulate:
Yes, let's:
> 1. You proposed a scheme for how to model hits against stacked unit in
> fire-into (not fire-at).
Correct.
>I am referring to the section of your email 2 days
> ago that started "Let me clarify and expand upon what I think should happen
> wrt 'fire-into'". The scheme you proposed for distributing hits in
> fire-into is based on unit sizes and the total terrain area.
If, by unit sizes, you mean the unit target area coverages, then that is
essentially correct.
> 2. I pointed out a problem with this scheme, namely that it introduces the
> sizes of other units into the hit-chance calculations for a given unit.
I am still quite confused by what this supposed problem is. I asked you
earlier to give me an example of where my probabilities are screwed up,
and you have, thus far, not done so.
But, since we're all about clarification these days, allow me to clarify:
(1) Suppose I have one unit in a cell, and its target coverage area
(subarea size, subregion size, or whatever) against the backdrop of the
cell is 2%, and its hit probability is 50%. The coverage area of the
stack is therefore 2%. This means that there is a 98% chance of missing
the stack. Now suppose that the stack is hit. What does this really
mean? It means that we randomly chose an unit, mutliplied its target
coverage area by its hit probability and determined a hit. In this case,
we only have one unit, and so it is "randomly" chosen, and then its
target coverage area (2%) is multipled by its hit probability (50%),
thus giving it a 1% probability of being randomly hit.
(2) Suppose I have two units in a cell, and each has a target coverage
area against the backdrop of the cell of 2%, and that their hit
probabilities are both 50%. The coverage area of the stack is therefore
4%. This means that there is a 96% chance of missing the stack. Now
randomly choose one of the two units in the stack, apply its target
coverage area multiplied by its hit probability. We get 1% (as in the
previous case of an identical solo unit occupying the cell). Now suppose
we miss the first unit occupying the cell, so we calculate the
probability of hitting the second unit after it is "randomly" chosen.
Guess what? The probability of hitting the second unit is also 1%.
Therefore, it is not dependent on other units in the stack.
Quod erat demonstrandum (QED).
> I suggested that a better way
> to model random hits against a stack of units is to treat them as
> statistically independent objects and roll a dice for each one of them.
You mean you suggested what I suggested?
> I did not at that time discuss how to strike a proper balance between hit
> chances in fire-at (targeted shots) and fire-into (random shots)
That is unfortunate, because your "hit-chance" comment certainly fooled
me into thinking you had made a significant oversight. (Your
"hit-chance" comment is mentioned below.)
> 3. After pondering my comments, you claim that this way of modeling hits in
> fire-into is flawed because the basal hit-chance against a unit would be
> the same as in fire-at (your example with u1 and u2). You make a big deal
> of this,
Well, yeah, it was the fatal flaw in your scheme, as I understood it.
(Again, see the mention of your "hit-chance" comment below.)
>and the inference is that your scheme would not suffer from
> similar problems.
That is correct. It would not suffer from similar problems.
> This argument is incorrect for several reasons. First, I did not state that
> the basal hit-chances in fire-into and fire-at (or against invisible and
> visible units) should always be the same. That's your assumption, not mine.
Actually, to quote you in
http://sources.redhat.com/ml/xconq7/2004/msg00944.html:
"Now, as I see it, all these factors (including the unit's size) are already
weighed into the hit-chance table and its various modifier tables such as
uu_protection etc. I certainly assign a larger hit chance against units
that are big targets when I design a game. So if the hit-chance for
artillery against infantry is 20% it means that an infantry unit which sits
in a standard terrain cell (no terrain modifiers) has a 20% chance of being
hit each time a piece of artillery fires into that cell."
You clearly and unequivocally state that you are considering the
'hit-chance' table (which _is used_ by 'fire-at'), and, yes, we were
most definitely discussing 'fire-into'. The subject had not been changed
and 'fire-into' was very much the topic at hand.
So, my "assumption" is based on something you wrote in the context of
the discussion. Not too shabby of an "assumption", I would say.
> Second, these matters are irrelevant to the discussion we had, which was
> about how to model random hits against a stack of units.
You're saying that your own mention of 'hit-chance' was irrelevant to
the discussion we had?
>Third, as far as I
> understand, your area-subdivision scheme does not address these problems
> either, unless modified by further assumptions not described in your
> original proposal.
The unit area coverage scheme was made out of the necessity to
differentiate between 'fire-at' and 'fire-into' by better modelling
'fire-into', and it appears to do exactly that. Your above claim that it
does not address "these problems" is, quite frankly, bizarre and
contradictory.
> I stand by my criticism of your scheme, but please do not take it
> personally.
I don't take it personally. I do think it shows that you still
misunderstand the unit target area coverage scheme.
What I am taking personally, as you likely would too if the situation
was reversed, is what appears to be the way you have distorted my
arguments. If you didn't understand them, you could have asked for
further clarification instead of making them out to be something they
are not. I even gave you an opportunity recently to demonstrate your
understanding of them by asking you to show their supposed statistical
flaw, but you did not take me up on the offer.
>And I do think we had that in this
> case, right until we got side-tracked into fire-at.
As I mention above, there was no sidetracking or changing of subject. If
anything, it was your mention of 'hit-chance' that sidetracked things.
> We have always been able discuss technical matters on this list without
> getting emotional. Let's keep it that way.
I wish we could. And perhaps calm can return again if you can
convincingly show me that you were not abusing my arguments in the way I
perceived.
>And perhaps move on to a
> different subject.
I would like to, but I am not sure that the 'fire-into' stuff is
completely thought through yet. Although this is not presently as
critical to me as some of the earlier topics in the thread, I am still
concerned about and keen on helping make sure that we do the right/best
thing wrt it. However, if we want to take a breather from the
discussion, I think it would probably be welcome by all those who have
been watching the flames and shards of ice fly.
Eric
next prev parent reply other threads:[~2004-08-20 1:42 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-16 21:53 Major bug and what to do about it (long) Hans Ronne
2004-08-16 22:14 ` Eric McDonald
2004-08-16 22:43 ` Hans Ronne
2004-08-17 0:33 ` Hans Ronne
2004-08-17 1:13 ` Eric McDonald
2004-08-17 1:39 ` Hans Ronne
2004-08-17 2:21 ` Eric McDonald
2004-08-17 4:28 ` Jim Kingdon
2004-08-17 5:17 ` Hans Ronne
2004-08-17 18:00 ` Eric McDonald
2004-08-18 5:26 ` Jim Kingdon
2004-08-18 11:11 ` Hans Ronne
2004-08-17 16:14 ` Eric McDonald
2004-08-17 0:35 ` Eric McDonald
2004-08-17 1:16 ` Hans Ronne
2004-08-17 1:46 ` Eric McDonald
2004-08-17 3:03 ` Hans Ronne
2004-08-17 3:56 ` Eric McDonald
2004-08-17 1:30 ` Eric McDonald
2004-08-17 2:52 ` Hans Ronne
2004-08-17 2:53 ` Eric McDonald
2004-08-17 4:42 ` Jim Kingdon
2004-08-17 16:37 ` Eric McDonald
2004-08-17 4:48 ` Hans Ronne
2004-08-17 16:42 ` Eric McDonald
2004-08-18 10:56 ` Jim Kingdon
2004-08-17 11:06 ` Stan Shebs
2004-08-17 15:29 ` Hans Ronne
2004-08-17 16:01 ` Hans Ronne
2004-08-17 18:57 ` Eric McDonald
2004-08-17 20:38 ` Hans Ronne
2004-08-17 21:55 ` Eric McDonald
2004-08-17 23:42 ` Hans Ronne
2004-08-18 0:49 ` Eric McDonald
2004-08-18 4:59 ` Hans Ronne
2004-08-18 15:28 ` Eric McDonald
2004-08-19 6:37 ` Elijah Meeks
2004-08-19 12:46 ` Hans Ronne
2004-08-19 16:46 ` Eric McDonald
2004-08-19 13:09 ` Hans Ronne
2004-08-19 16:05 ` Eric McDonald
2004-08-19 20:09 ` Hans Ronne
2004-08-19 23:37 ` Eric McDonald
2004-08-20 1:42 ` Hans Ronne
2004-08-20 3:29 ` Eric McDonald [this message]
2004-08-20 15:26 ` Clearing the Air (long) Stan Shebs
2004-08-18 5:30 ` Major bug and what to do about it (long) Jim Kingdon
2004-08-18 12:52 ` Hans Ronne
2004-08-17 18:23 ` Eric McDonald
2004-08-17 18:47 ` Hans Ronne
2004-08-17 18:59 ` Eric McDonald
2004-08-17 19:39 ` Hans Ronne
2004-08-17 21:14 ` Eric McDonald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=412556EF.80401@phy.cmich.edu \
--to=mcdonald@phy.cmich.edu \
--cc=hronne@comhem.se \
--cc=xconq7@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).