Re: Some data on where HP users are



Post: #2

> Yes, I also found 5743, and the number of CD's dave > Ordered seemed more realistic. But I was astonnished too > of the
> coincidence of same 7 shipments...


It seems I'm missing something.
I tried to compute that number
with the following assumption:

let Ni=X*Pi,
where X = unknown total CDs number,
Pi=(percentual of CDs sent to the country i)/100,
Ni=number of CDs sent to the country i,
then X should satisfy the condition

abs(round(Ni) - Ni) <= epsilon

for every i, because every calculated Ni should be close to
an integer value.

That way, with epsilon=1e-3 I get:
X = 851, already found by other posters, and
X = 1,702.
No other results have been found allowing the algorithm to run
up to 40,000+.
The result 5,743 has not been found by the algorithm.

With an higher value for epsilon, 1e-2, I get:

X = 851
X = 1,702
X = 2,553
X = 3,404
X = 4,255
X = 5,106
X = 5,957
X = 6,808
etc.

but the 5,743 value is still not found.

It's also possible to impose a tolerance on the sum
of the abs(round(Ni) - Ni) terms so that X should satisfy the
following condition:

sigma(abs(round(Ni) - Ni)) <= epsilon, where Ni=X*Pi as above.

That way with epsilon=.01 I get only X = 851.
With epsilon=.1 the results are again
X = 851
X = 1,702
X = 2,553
X = 3,404
etc.

but the 5,743 value is still not found.
Infact sigma(5,743) > 11, so that seems not to be
a valid solution at all.

Well, I gave it a try because this problem seems to be a bit tricky, or maybe I'm just out of exercise...

--


Post: #3

> X should satisfy the condition

>

> abs(round(Ni) - Ni) <= epsilon

No, no, that condition doesn't need to be satisfied at all. Dave calculated his percentages to two decimal digits, regardless of whether your condition is satisfied or not.

What is satistied is the following. Let:

Ki=round(X*Pi)

Pi'=round(10000*Ki/X)

then Pi' should equal 10000*Pi exactly.

This works for 851 and its integer multiples; the first non-trivial solution that I found is 5743. After that, solutions become more frequent; in fact, according to my calculations that last integer that is not a solution is 9939. Starting with 9940, all integers appear to be solutions. All the while, your epsilon can be a very large number, since abs(round(Ni)-Ni) can be anything up to 0.5.


Viktor


Post: #4

> No, no, that condition doesn't need to be satisfied at > all. Dave calculated his percentages to
> two decimal digits, regardless of whether your condition > is satisfied or not.


Thank you for your explanation, but I was not able
to make it work.
Anyway I don't understand why a valid solution for X
shouldn't verify the condition

abs(round(Ni) - Ni) <= epsilon
for any i (where Ni=Pi*X).

Even if my previous results were incorrect
because of an improper copy&paste so that some
percentuals were missing in my data file,
851 and 1,702 are confirmed: with the correct
set of data, imposing an epsilon=0.1
my algorithm gives

X = 851 (already found by other posters)
X = 1,702 (already found by my algorithm)
X = 8,298
X = 9,149

X = 10,000
X = 10,851
X = 11,702
X = 18,298
X = 19,149

X = 20,000
X = 20,851
X = 21,702
X = 28,298
X = 29,149

X = 30,000
X = 30,851
X = 31,702
X = 38,298
X = 39,149

X = 40,000
and so forth.

But the value 5,743 is still missing. :)

--


Post: #5

Rupert,

Your condition doesn't need to be satisfied because that's not how Dave calculated his percentages. Dave didn't say, "I'll calculate the percentages to as many decimal digits as needed, so that abs(round(Ni) - Ni) <= epsilon"); he simply calculated his percentages to two decimals, regardless of the consequences on precision.

This is best demonstrated through an example. Let's say there were 5743 sales, 230 of which went to Lower Tasmania. The percentage, then, would be 230/5743=4.0049%. But Dave only used two decimal digits, so he calculated 4%. 5743*0.04=229.72, so the difference, epsilon, in this case is 0.28. But Dave didn't care; he didn't add more digits to his percentage figure just to reduce the difference to something nicer, say 0.01. (In this case, he'd have had to use 3 decimal digits in his percentage figure, or 4.005%, to reduce epsilon below 0.28.)

To see this, you can create a spreadsheet with the following:

Let A1=5743 (or whatever other number it is that you're testing).

Let A2..A17 be the various percentages: 0.5546, 0.1022... 0.0012.

Let Bn=ROUND($A$1*An,0)

Let Cn=ROUND(Bn/$A$1,4)

For any number A1 for which An==Cn for all values of n, A1 is a solution. You can also compute $A$1*An-Bn (this is your epsilon) and see that it can become very high for many valid solutions.

Because of this, your algorithm misses many solutions. All integer multiples of 851 are solutions; so not only 1702 but 2553, 3404, etc. The first non-trivial solution is 5743, but after that, solutions become more frequent; in fact, ALL numbers above 9940 are solutions.

You might consider redefining epsilon as (round(Ni)-Ni)/Ni, but that's too lax a condition, producing many false results. Quite simply, you need to restate the problem; since Dave didn't compute to a specific PRECISION, he only selected an arbitrary number of digits (not even a specific number of significant digits; 0.12% has only two significant digits, whereas 55.46% has four) so any method that tries to deduce the correct number based on an assumption of the result's precision will by necessity produce misleading results.


Viktor


Post: #6

> Because of this, your algorithm misses many solutions. > All integer multiples of 851 are solutions; so not only
> 1702 but 2553, 3404, etc.

In fact it is clearly displayed in the sigma(delta(i)) function graphics (they are all points of local minimum).
I should have had a look at the graphics before trying to find numerical solutions.

> since Dave didn't compute to a specific PRECISION,
> he only selected an arbitrary number of digits (not even a specific number of significant digits; 0.12% has only
> two significant digits, whereas 55.46% has four) so any

Thank you again for the explanation. Now I have understood the point.

--


Forum Jump: