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: Re: Major bug and what to do about it (long)
Date: Thu, 19 Aug 2004 16:05:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0408191135050.9219-100000@leon.phy.cmich.edu> (raw)
In-Reply-To: <l03130302bd4a4916c778@[212.181.162.155]>

On Thu, 19 Aug 2004, Hans Ronne wrote:

> The problem of visible and invisible units currently having the same
> hit-chance, which you used as an example, is indeed important, as is the
> question of whether targeted attacks should have an inherently higher
> hit-chance. See my reply to Elijah for some comments. I fail to see how
> your area-subdivision scheme would address this, however. Presumably
> visible and invisible units would still have the same size in the terrain?

Right. And they should. Just because an unit is not seen does not 
mean that it should somehow have a smaller footprint than one that 
is seen in the case of random fire entering a cell, which is what 
I thought we were discussing wrt 'fire-into' (not its current 
implementation, but what it should be).

> My basic objection to this scheme is that it introduces other units in the
> cell (and their sizes) into the hit-chance calculation for a given unit. 

As more units are added to the stack then the chance that the 
stack is hit should increase. However, the chance that any one 
unit within a stack is hit should not change with stack size.

If you see an error with the way the probabilities play out in my 
scheme, could you please point out exactly what that error is?

> did my best to explain what the problem is, as I see it, and have little to
> add to that. 

C'mon, Hans. I explained the problem and you proposed something 
that turned out to be an absurdity once I compared it side by side 
with 'fire-at'. Please stop trying to twist things around.

>The key point is that targets of a random process (fire into a
> cell) should be treated as statistically independent objects. 

Right. I don't think we disagree on that point.

Eric

  reply	other threads:[~2004-08-19 15:46 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-16 21:53 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 [this message]
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                               ` Clearing the Air (long) Eric McDonald
2004-08-20 15:26                                 ` 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=Pine.LNX.4.44.0408191135050.9219-100000@leon.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).