public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
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

  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).