• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Comp group % max & validation question

  • Thread starter Thread starter woodywalton at hotmail.co
  • Start date Start date
W

woodywalton at hotmail.co

Guest
All,


In general, if a comp group is set to a max of x% is the validation
supposed to trigger when that maximum % is reached, exceeded, or
both? I have many percentage based maximums defined for comp groups
in my datafiles and some are triggered when they reach the exact %
and have not gone over. The default text for the validation message
states "Composition group 'name' does not satisfy requirements
(<=x%)" The issue is that the comp group is actually in agreement
with the expression 'less than or equal to x percent' because it is
equal to x percent.

Thanks,

Woody


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
I'll bet you $5 that AB is working correctly. :-)

The reason is that this WAS a problem when V2.0 was first released, and it
was a subtle one. My guess is that you're falling prey to the inverse
situation of how I messed up within V2.0. :-)

Consider the following. You are creating a 2000 point roster. Composition
group X is limited to a maximum of 50% of the total points in the roster.
The rule is given as "<=50%", which is interpreted to mean that the roster
is valid when you have exactly 50% or less. Now let's say you currently
have 1001 points of X in your roster, which translates to 50% after
reasonable rounding is performed. So the percentage will display as 50%
within AB. However, the REAL percentage is 50.05%, which is MORE than 50%.
Therefore, AB will report this as a validation error, even though the
rounded percentage displayed by AB will appear to be valid.

Please double-check this subtle distinction within your rosters. I've got
$5 riding on AB doing this correctly, so don't make we wait too long for
verification. :-) Besides, V2.2b just went final and is ready to be
released, and I *REALLY* don't want to run into a new bug like this. So
I'll hold off releasing it for 24 hours so you can verify that AB is
working correctly and let me know. :-)

Thanks, Rob


At 12:48 AM 9/19/2001 +0000, you wrote:
>All,
>
>
>In general, if a comp group is set to a max of x% is the validation
>supposed to trigger when that maximum % is reached, exceeded, or
>both? I have many percentage based maximums defined for comp groups
>in my datafiles and some are triggered when they reach the exact %
>and have not gone over. The default text for the validation message
>states "Composition group 'name' does not satisfy requirements
>(<=x%)" The issue is that the comp group is actually in agreement
>with the expression 'less than or equal to x percent' because it is
>equal to x percent.
>
>Thanks,
>
>Woody


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
 
Rob,

All the numbers I work with for costs have no decimal places. I
have tried it with multiple lists from all five races. It throws
the validation message when the number is right on the max.(500pts
of 1000 at 50%). I have changed the roster sizes and it does not
seem to be tied to a specific size or range (100 to 5000 points in
50 point increments). I sent you the datafiles earlier last weekend
so you can verify the behavior yourself if you would like. The
demonworld.ab file is up on ab-fiels as well.

Woody


--- In armybuilder@y..., Rob Bowes <rob@w...> wrote:
> I'll bet you $5 that AB is working correctly. :-)
>
> The reason is that this WAS a problem when V2.0 was first
released, and it
> was a subtle one. My guess is that you're falling prey to the
inverse
> situation of how I messed up within V2.0. :-)
>
> Consider the following. You are creating a 2000 point roster.
Composition
> group X is limited to a maximum of 50% of the total points in the
roster.
> The rule is given as "<=50%", which is interpreted to mean that
the roster
> is valid when you have exactly 50% or less. Now let's say you
currently
> have 1001 points of X in your roster, which translates to 50%
after
> reasonable rounding is performed. So the percentage will display
as 50%
> within AB. However, the REAL percentage is 50.05%, which is MORE
than 50%.
> Therefore, AB will report this as a validation error, even though
the
> rounded percentage displayed by AB will appear to be valid.
>
> Please double-check this subtle distinction within your rosters.
I've got
> $5 riding on AB doing this correctly, so don't make we wait too
long for
> verification. :-) Besides, V2.2b just went final and is ready to
be
> released, and I *REALLY* don't want to run into a new bug like
this. So
> I'll hold off releasing it for 24 hours so you can verify that AB
is
> working correctly and let me know. :-)
>
> Thanks, Rob
>
>
> At 12:48 AM 9/19/2001 +0000, you wrote:
> >All,
> >
> >
> >In general, if a comp group is set to a max of x% is the
validation
> >supposed to trigger when that maximum % is reached, exceeded, or
> >both? I have many percentage based maximums defined for comp
groups
> >in my datafiles and some are triggered when they reach the exact %
> >and have not gone over. The default text for the validation
message
> >states "Composition group 'name' does not satisfy requirements
> >(<=x%)" The issue is that the comp group is actually in agreement
> >with the expression 'less than or equal to x percent' because it
is
> >equal to x percent.
> >
> >Thanks,
> >
> >Woody
>
>
> -------------------------------------------------------------------
--------
> Rob Bowes (rob@w...) (650) 726-9689
> Lone Wolf Development
www.wolflair.com



------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
Looks like I owe you $5 and Microsoft needs to receive more hate mail from
me. :-(

It turns out the problem is due to the behavior of the Microsoft C++
compiler and how it performs floating point calculations. According to VC,
the calculation "(50 * 1000) / 100" results in 499.999989 (for a 50% limit
on a 1000 point roster). So, when you compare a limit of 499.999989 to an
actual size of 500, the actual size is larger than the limit and a
validation error is triggered. :-(

The important thing to note on this is that it ONLY occurs in a RELEASE
build. In a debug build, the behavior is correct, because the calculations
are correct. Therefore, I never encountered this anomaly during all of my
testing. Joy. :-(

I just love Microsoft's consistency (i.e. their utter lack of it in their
products IS their consistency). I'm well into double digits on the number
of bugs and/or inconsistencies within the VC compiler that I've stumbled
over with AB - not to mention the bugs and inconsistencies I've encountered
in numerous other Microsoft tools along the way. It's quite depressing.

In any case, I will figure out a way to accommodate this problem and get a
fix for it into the imminent release of AB. Hit me up for the $5 at the
next Con. :-)

Thanks, Rob


At 12:28 PM 9/19/2001 +0000, you wrote:
>Rob,
>
>All the numbers I work with for costs have no decimal places. I
>have tried it with multiple lists from all five races. It throws
>the validation message when the number is right on the max.(500pts
>of 1000 at 50%). I have changed the roster sizes and it does not
>seem to be tied to a specific size or range (100 to 5000 points in
>50 point increments). I sent you the datafiles earlier last weekend
>so you can verify the behavior yourself if you would like. The
>demonworld.ab file is up on ab-fiels as well.
>
>Woody


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
Rob,

All I can say is that you know who I work for and you were more than
diplomatic in your response/comentary regarding the powers that be! ;-
)

-Woody




--- In armybuilder@y..., Rob Bowes <rob@w...> wrote:
> Looks like I owe you $5 and Microsoft needs to receive more hate
mail from
> me. :-(
>
> It turns out the problem is due to the behavior of the Microsoft
C++
> compiler and how it performs floating point calculations. According
to VC,
> the calculation "(50 * 1000) / 100" results in 499.999989 (for a
50% limit
> on a 1000 point roster). So, when you compare a limit of 499.999989
to an
> actual size of 500, the actual size is larger than the limit and a
> validation error is triggered. :-(
>
> The important thing to note on this is that it ONLY occurs in a
RELEASE
> build. In a debug build, the behavior is correct, because the
calculations
> are correct. Therefore, I never encountered this anomaly during all
of my
> testing. Joy. :-(
>
> I just love Microsoft's consistency (i.e. their utter lack of it in
their
> products IS their consistency). I'm well into double digits on the
number
> of bugs and/or inconsistencies within the VC compiler that I've
stumbled
> over with AB - not to mention the bugs and inconsistencies I've
encountered
> in numerous other Microsoft tools along the way. It's quite
depressing.
>
> In any case, I will figure out a way to accommodate this problem
and get a
> fix for it into the imminent release of AB. Hit me up for the $5 at
the
> next Con. :-)
>
> Thanks, Rob
>
>
> At 12:28 PM 9/19/2001 +0000, you wrote:
> >Rob,
> >
> >All the numbers I work with for costs have no decimal places. I
> >have tried it with multiple lists from all five races. It throws
> >the validation message when the number is right on the max.(500pts
> >of 1000 at 50%). I have changed the roster sizes and it does not
> >seem to be tied to a specific size or range (100 to 5000 points in
> >50 point increments). I sent you the datafiles earlier last weekend
> >so you can verify the behavior yourself if you would like. The
> >demonworld.ab file is up on ab-fiels as well.
> >
> >Woody
>
>
> --------------------------------------------------------------------
-------
> Rob Bowes (rob@w...) (650) 726-9689
> Lone Wolf Development
www.wolflair.com
 
It's a public forum, so I have to mind my manners. :-)

My wife is ex-Microsoft, so you can rest assured that she has heard an
earful (or 10) when I've run into the really nasty bugs (i.e. the ones that
have cost me many days to isolate and verify). This one took only about 1
hour to chase down, so it wasn't all that bad. Just a major nuisance, most
especially with the timing.

Besides, it cost me $5!!! The indignity!!! :->

Thanks, Rob


At 04:48 AM 9/20/2001 +0000, you wrote:
>Rob,
>
>All I can say is that you know who I work for and you were more than
>diplomatic in your response/comentary regarding the powers that be! ;-
>)
>
>-Woody


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
You must log in or register to reply here.
Back
Top