I just tested my series files and I noticed that when I re-score the
series the ranking is either calculated points score, or it is ranked
1st to ... BUT the NETT points for that competitor are the same as the
rank instead of the correct calculated points.
I will be uploading a series file to show what I mean.
Colin - I just downloaded the program at the link provided. It
installed as 2.00 Build 01. Did I get the wrong build or is the build
indicator not updated?
If it truly is Build 02, then the issue remains. When there are only
two fleets the error remains. When three fleets, it seems to work OK.
Also, the other issue I had with the point assignments and the
calculation after dropping a race still remains.
Colin - the files I used (and are this past seasons actual files from
our club racing) are located in the Rindirle B - Series Sums in the
files section here.
Bill, ah - yes, sorry - I forgot you had uploaded
them. I see the issue (Total is OK, Nett is not) but have no idea why
it’s happening at present - slightly serious bug though for a scoring
program…!
Just installed 2.0 in a different location to my current build, as I wanted to keep doing the results for the rest of the year in the old build. Opened up one set of results and something rather strange was happening with the vertical scroll bar. If I maximise the app on my monitor (1440 x 900), then the vertical scroll bar disappears, when I have the app not maximised the vertical scroll bar is there, but it's length calculation is wrong, the thumb goes below the bottom of the window, so you can never get to the last competitors. Another file does show the scroll bar maximised but the calculated height is still wrong, and you can never get to the bottom competitors.
Also I tried to delete competitors, but the confirm deletion dialogue seems to have opened off the screen, could not delete competitors until I started the old build did a delete, and the delete confirmation in 2.0 was positioned correctly.
I am also not seeing the history list of recently opened files updating correctly, only the first position seems to update.
Don't know how many of these issues are a result of having two versions installed.
However, the on-going problem - the true calculations of the NETT
points continues. I realize you are working on other issues, but it
would certainly go a long way to re-establishing credibility (for me
and SW) if this could be resolved.
Colin - the correction of placing Nett and Rank numbers in the right
place has been attended to, thank you.
If you look at the Nett numbers, you will note that (or at least I
notice that) the Nett is greater than the Total for some competitors -
which is interesting since the Nett should be the Total points less the
drop race points.
I left notes earlier in the forum with my observations of patterns. In
summary, when points are assigned for a code, the assignment is
inconsistent, and the wrong races are dropped, or they are added rather
than subtracted. The assigned points are sometimes represented as a
negative number.
I dunno where that came from but thats what is does - the EXECUTE
statement just means do line 1 if starters is 1 and line 2 if its 2 etc.
The problem comes at “Starters-Pos” because Pos is “the number of boats
in series + 1” - your codes are set up for high point scoring - so
thaht expression is -ve. I dont really know what to do about it. Do
you know where the formula I use came from…?
Presumably DNF etc should be “points for the positon of the number of
boats that started” (or sim) to make any sense…? Perhaps you can let
me know your preferences for CHIPS and RinderleB and I will do
somehting to warn the user than things may not be set up correctly (I
can depect the points going negative for example) - Sailwave seems to
be saving and loading the codes OK…
Colin - now that I have seen the logic, as well as the formula I took
the time to read up more on this. It seems that for assigned points
situations (esp things like DNC / DNS and DNF) there is a possibility
for a negative calculation. I also noticed that some implementations
seem to assign fixed number of points (really low) instead of the
calculations. Given that Rinderle B (and CHIPS I suspect) were
originally designed as table look-up I suppose it is a potential that
this (negative number) situation can occur.
I can't find any pattern for assigning points for scoring codes.
Is there some way to make sure that the result is always positive?
In my series results that I was using to test (nothing like real data
huh?) it looks like the correct number of points were being assigned,
but sometimes a negative number.
Just to clarify, the Rinderle B figures are derived from a look-up table whereas CHIPS is derived from a formula with no scope for going negative. A few years ago I devised a formula designed to be a reasonable fit to Rinderle B, or at least to behave similarly to it, but because the increments are a bit irregular it was not easy to get a good fit. That was one of the several reasons why I devised the CHIPS formula and, having done so, there was no longer any great merit in persevering to get a better equation for Rinderle B. I beleive at least one club in the US is using my “modified Rinderle B” formula which I recall putting in the Sailwave Files area if it is really needed.
Colin - now that I have seen the logic, as well as the formula I took
the time to read up more on this. It seems that for assigned points
situations (esp things like DNC / DNS and DNF) there is a possibility
for a negative calculation. I also noticed that some implementations
seem to assign fixed number of points (really low) instead of the
calculations. Given that Rinderle B (and CHIPS I suspect) were
originally designed as table look-up I suppose it is a potential that
this (negative number) situation can occur.
I can’t find any pattern for assigning points for scoring codes.
Is there some way to make sure that the result is always positive?
In my series results that I was using to test (nothing like real data
huh?) it looks like the correct number of points were being assigned,
but sometimes a negative number.
I was hoping you’d turn up. CHIPS goes negative is users leave the
codes as they usually are for low point systems - for example DNC based
on the number of competitors in the series. In this situation Pos is
A basic element of CHIPS is that the codes need to be set to the proper default values, the key ones being:
DNC = 0
RTD (including DNF & RAF) = Starters + 1
DSQ (including BFD, DNE, OCS) = 0
If anyone wishes to score DNC to be the same as RTD then that is an allowable option, as you have suggested, although my strong preference is to stick with DNC = 0.
It is essential to change the codes from those used for LPS - not doing so will throw up some negative scores.
Similar principles apply to Rinderle B albeit with slightly different values.
I was hoping you’d turn up. CHIPS goes negative is users leave the codes as they usually are for low point systems - for example DNC based on the number of competitors in the series. In this situation Pos is >> Starters…
I was thinking about just making Pos = Starters+1 in that situation. Cant see what else to do really… I’m surprised people dont use DNC = 0 etc…
Colin
Geoff Burrell wrote:
Just to clarify, the Rinderle B figures are derived from a look-up table whereas CHIPS is derived from a formula with no scope for going negative. A few years ago I devised a formula designed to be a reasonable fit to Rinderle B, or at least to behave similarly to it, but because the increments are a bit irregular it was not easy to get a good fit. That was one of the several reasons why I devised the CHIPS formula and, having done so, there was no longer any great merit in persevering to get a better equation for Rinderle B. I beleive at least one club in the US is using my "modified Rinderle B" formula which I recall putting in the Sailwave Files area if it is really needed.
Colin - now that I have seen the logic, as well as the formula I took
the time to read up more on this. It seems that for assigned points
situations (esp things like DNC / DNS and DNF) there is a possibility
for a negative calculation. I also noticed that some implementations
seem to assign fixed number of points (really low) instead of the
calculations. Given that Rinderle B (and CHIPS I suspect) were
originally designed as table look-up I suppose it is a potential that
this (negative number) situation can occur.
I can't find any pattern for assigning points for scoring codes.
Is there some way to make sure that the result is always positive?
In my series results that I was using to test (nothing like real data
huh?) it looks like the correct number of points were being assigned,
but sometimes a negative number.
Does this help? (or hinder?)
Bill
---
No virus found in this incoming message.
Checked by AVG - [http://www.avg.com](http://www.avg.com)
Version: 8.0.175 / Virus Database: 270.8.2/1738 - Release Date: 21/10/2008 14:10
I’ve decided that p >s in RInderle and p > s+1 in CHIPS are
configuration error conditions and scoring is aborted with a message to
sort out the codes - and some tips on how to do it… Silently
tweaking p is ‘dangerous’ in a way and should be avoided…
PS: What is the location of your latest paper(s) on CHIPS etc - I’d
like to link to them form the hewlp file if that’s OK.
COlin
Sailwave
Geoff Burrell wrote:
···
sailwave@yahoogroups.commailto:sailwave@yahoogroups.comOn Behalf Of Sent:
**To:**sailwave@yahoogroups.com Subject: