Re: [PHP] Seeking overlap algorithm

2007-12-07 Thread Nathan Nobbe
On Dec 6, 2007 9:14 PM, tedd [EMAIL PROTECTED] wrote:

 At 6:07 PM -0500 12/6/07, Nathan Nobbe wrote:
 On Dec 6, 2007 4:59 PM, tedd [EMAIL PROTECTED] wrote:
The problem is, could you guarantee to a preferred service
 provider
that they would receive top-listing 25 percent of the time? Keep in
mind that preferred service providers will overlap. So, the question
is how to accommodate for that overlap?
   
If anyone has an algorithm, I would be interested in hearing it.
 
 i think that should be pretty easy. the algorithm is dependent upon
 2 values.  the number of listings you consider as top-listings for
 each result set and the number of customers that are registered as
 preferred customers.
 
 let me illustrate. imagine you designate only the first entry of the
 resultant listings as a *
 top-listing*. in that case you can support a maximum of 4 preferred
 customers before you
 can no longer guarantee to each of the preferred customers their
 listing will be
 a top-listing 25% of the time.  so, if you want more capacity you
 can increase the number
 of results that are designated as top-listing results.
 
 suppose you increase the number to 2, now you have a capacity of 8
 customers you can guarantee top-listing status 25% of the time.
 
 what you would need to determine is what to do if ever you didnt
 want to increment the number of listings that are designated as
 top-listing customers and you were already at capacity for the
 number of customers the current capacity supports.

 Yes, that was pretty easy, but that was not the answer to the
 question -- my error for not explaining it better.

 Let me rephrase the question by providing an example.

 Let's say we have a customer base that is spread-out at random over a
 geographic area. Each customer has designated a 50 mile radius from
 their location as being within their zone -- the map would look like
 a bomb saturation map, if you know what I mean.

 Now, many of those areas overlap so that if a end-user is within that
 overlap he can see all the service providers that can provide
 service. It's a simple matter to pull those providers out of a
 database depending upon distance and show them to him. After all,
 that's the way it works, isn't it? The end-user is provided all the
 service providers who are within their service range.

 However, if you are also considering that some of these service
 providers should be shown as preferred (i.e., at the top 25 percent
 of the time) then you might find yourself in a position of over
 selling the top position because there may be too many preferred
 service providers in certain areas.

 Now, what I need is a way to analyze the distribution of the current
 service providers to see if a given location is open to being sold as
 a preferred position -- do you see what I mean?

 Another example, let's say we have four preferred service providers
 at the same location. Obviously, we could not sell another
 preferred position within 100 miles.

 Another example, let's say we have four preferred service providers
 100 miles apart, clearly we can sell more preferred positions. But,
 the number of positions available depends upon the distribution of
 the original four. If they were located in a straight line, then we
 could sell two positions between each one. But, if they were
 distributed in a square, we could only sell one. Do you see?

 I know what solution I will be using unless someone comes up with
 something different. I just want to tap this knowledgeable group
 before I spin my wheels trying to solve a problem, that may be
 already solved.


i see the problem more clearly now.  unfortunately, i dont know the
solution off the top of my head :(  if i think of something in the near
future ill toss it on the list.

-nathan


RE: [PHP] Seeking overlap algorithm

2007-12-07 Thread Ford, Mike
On 07 December 2007 02:14, tedd wrote:


 Now, what I need is a way to analyze the distribution of the current
 service providers to see if a given location is open to being sold as
 a preferred position -- do you see what I mean?
 
 Another example, let's say we have four preferred service providers
 at the same location. Obviously, we could not sell another
 preferred position within 100 miles.
 
 Another example, let's say we have four preferred service providers
 100 miles apart, clearly we can sell more preferred positions. But,
 the number of positions available depends upon the distribution of
 the original four. If they were located in a straight line, then we
 could sell two positions between each one. But, if they were
 distributed in a square, we could only sell one. Do you see?

A simplistic but effective way would be:

(1) Locate all preferred providers within 50 miles of the potential new one 
(presumably a maximum of four!).

(2) For each of these, find how many suppliers are within their 50-mile 
catchment radius.

If any of the answers at step 2 is four, you lose; if none of them is, you win.

I can't think of any obvious ways to optimize this, but then I never did 
properly get the travelling salesman or 4-colour problem!

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
JG125, The Headingley Library,
James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 812 4730  Fax:  +44 113 812 3211 


To view the terms under which this email is distributed, please go to 
http://disclaimer.leedsmet.ac.uk/email.htm

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Seeking overlap algorithm

2007-12-07 Thread Nathan Nobbe
On Dec 7, 2007 10:12 AM, Ford, Mike [EMAIL PROTECTED] wrote:

 On 07 December 2007 02:14, tedd wrote:


  Now, what I need is a way to analyze the distribution of the current
  service providers to see if a given location is open to being sold as
  a preferred position -- do you see what I mean?
 
  Another example, let's say we have four preferred service providers
  at the same location. Obviously, we could not sell another
  preferred position within 100 miles.
 
  Another example, let's say we have four preferred service providers
  100 miles apart, clearly we can sell more preferred positions. But,
  the number of positions available depends upon the distribution of
  the original four. If they were located in a straight line, then we
  could sell two positions between each one. But, if they were
  distributed in a square, we could only sell one. Do you see?

 A simplistic but effective way would be:

 (1) Locate all preferred providers within 50 miles of the potential new
 one (presumably a maximum of four!).

 (2) For each of these, find how many suppliers are within their 50-mile
 catchment radius.

 If any of the answers at step 2 is four, you lose; if none of them is, you
 win.

 I can't think of any obvious ways to optimize this, but then I never did
 properly get the travelling salesman or 4-colour problem!


im ashamed to admit i blew off a couple of linear algebra classes and a
calc-based stats class in college.  had i paid attention, this might still
be
a trivial problem =/
..., bah!

-nathan


[PHP] Seeking overlap algorithm

2007-12-06 Thread tedd

Hi gang:

This post is related to the zip lat/long request I recently made and 
received such an overwhelming response -- many thanks to all.


In any event, let's say we have a end-user who is looking for 
services within his zip-code AND we have a dB of service providers 
who are willing to render service within a set distance (like 50 
miles) from their location.


Now, it's a simple matter to convert the user's zip code to lat/longs 
and then find out how many service providers there are within their 
area and then show that list to the end-user. That's not the problem.


The problem is, could you guarantee to a preferred service provider 
that they would receive top-listing 25 percent of the time? Keep in 
mind that preferred service providers will overlap. So, the question 
is how to accommodate for that overlap?


If anyone has an algorithm, I would be interested in hearing it.

Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Seeking overlap algorithm

2007-12-06 Thread Nathan Nobbe
On Dec 6, 2007 4:59 PM, tedd [EMAIL PROTECTED] wrote:

 Hi gang:

 This post is related to the zip lat/long request I recently made and
 received such an overwhelming response -- many thanks to all.

 In any event, let's say we have a end-user who is looking for
 services within his zip-code AND we have a dB of service providers
 who are willing to render service within a set distance (like 50
 miles) from their location.

 Now, it's a simple matter to convert the user's zip code to lat/longs
 and then find out how many service providers there are within their
 area and then show that list to the end-user. That's not the problem.

 The problem is, could you guarantee to a preferred service provider
 that they would receive top-listing 25 percent of the time? Keep in
 mind that preferred service providers will overlap. So, the question
 is how to accommodate for that overlap?

 If anyone has an algorithm, I would be interested in hearing it.


i think that should be pretty easy.
the algorithm is dependent upon 2 values.  the number of listings you
consider
as top-listings for each result set and the number of customers that are
registered as preferred customers.
let me illustrate.
imagine you designate only the first entry of the resultant listings as a *
top-listing*.
in that case you can support a maximum of 4 preferred customers before you
can
no longer guarantee to each of the preferred customers their listing will be
a top-listing
25% of the time.  so, if you want more capacity you can increase the number
of
results that are designated as top-listing results.  suppose you increase
the number
to 2, now you have a capacity of 8 customers you can guarantee top-listing
status 25%
of the time.
what you would need to determine is what to do if ever you didnt want to
increment the
number of listings that are designated as top-listing customers and you were
already
at capacity for the number of customers the current capacity supports.
perhaps you
could start charging more at that point.

-nathan


Re: [PHP] Seeking overlap algorithm

2007-12-06 Thread tedd

At 6:07 PM -0500 12/6/07, Nathan Nobbe wrote:

On Dec 6, 2007 4:59 PM, tedd [EMAIL PROTECTED] wrote:
  The problem is, could you guarantee to a preferred service provider
  that they would receive top-listing 25 percent of the time? Keep in
  mind that preferred service providers will overlap. So, the question
  is how to accommodate for that overlap?
 
  If anyone has an algorithm, I would be interested in hearing it.


i think that should be pretty easy. the algorithm is dependent upon 
2 values.  the number of listings you consider as top-listings for 
each result set and the number of customers that are registered as 
preferred customers.


let me illustrate. imagine you designate only the first entry of the 
resultant listings as a *
top-listing*. in that case you can support a maximum of 4 preferred 
customers before you
can no longer guarantee to each of the preferred customers their 
listing will be
a top-listing 25% of the time.  so, if you want more capacity you 
can increase the number

of results that are designated as top-listing results.

suppose you increase the number to 2, now you have a capacity of 8 
customers you can guarantee top-listing status 25% of the time.


what you would need to determine is what to do if ever you didnt 
want to increment the number of listings that are designated as 
top-listing customers and you were already at capacity for the 
number of customers the current capacity supports.


Yes, that was pretty easy, but that was not the answer to the 
question -- my error for not explaining it better.


Let me rephrase the question by providing an example.

Let's say we have a customer base that is spread-out at random over a 
geographic area. Each customer has designated a 50 mile radius from 
their location as being within their zone -- the map would look like 
a bomb saturation map, if you know what I mean.


Now, many of those areas overlap so that if a end-user is within that 
overlap he can see all the service providers that can provide 
service. It's a simple matter to pull those providers out of a 
database depending upon distance and show them to him. After all, 
that's the way it works, isn't it? The end-user is provided all the 
service providers who are within their service range.


However, if you are also considering that some of these service 
providers should be shown as preferred (i.e., at the top 25 percent 
of the time) then you might find yourself in a position of over 
selling the top position because there may be too many preferred 
service providers in certain areas.


Now, what I need is a way to analyze the distribution of the current 
service providers to see if a given location is open to being sold as 
a preferred position -- do you see what I mean?


Another example, let's say we have four preferred service providers 
at the same location. Obviously, we could not sell another 
preferred position within 100 miles.


Another example, let's say we have four preferred service providers 
100 miles apart, clearly we can sell more preferred positions. But, 
the number of positions available depends upon the distribution of 
the original four. If they were located in a straight line, then we 
could sell two positions between each one. But, if they were 
distributed in a square, we could only sell one. Do you see?


I know what solution I will be using unless someone comes up with 
something different. I just want to tap this knowledgeable group 
before I spin my wheels trying to solve a problem, that may be 
already solved.


Thanks, for your time.

Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php