Dotaz: Algoritmus pro vyhledání nejkratší vzdálenosti

[Deleted [8409]]

Ahoj,

nevím jak efektivně řešit tento problém. Mám pole bodů, a potřeboval bych funkci, která by co nejefektivněji našla nejkratší vzdálenost pro danou pozici. Naprosto triviálně to lze řešit lineárním prohledáváním, ale to je z hlediska výkonu nepoužitelné. Pro lepší porozumění předložím malý prototyp, kterým bych chtěl lépe vysvětlit, o co mi jde:

struct DistancePoint
{
  double x, y;
};

struct DistanceFinder
{
  DistanceFinder();
  ~DistanceFinder();

  bool init(const DistancePoint* p, int count);
  void free();
  double find(double inX, double inY);
  void findSpan(double x, double y, int count, double* results);

  DistancePoint* _data;
  int _count;
};

DistanceFinder::DistanceFinder() :
  _data(NULL)
{
}

DistanceFinder::~DistanceFinder()
{
  free();
}

bool DistanceFinder::init(const DistancePoint* p, int count)
{
  free();
  if (!count) return false;

  _data = (DistancePoint*)malloc(count * sizeof(DistancePoint));
  if (!_data) return false;

  memcpy(_data, p, count * sizeof(DistancePoint));
  return true;
}

void DistanceFinder::free()
{
  if (_data) { ::free(_data); _data = NULL; }
}

double DistanceFinder::find(double x, double y)
{
  double dist = fabs((_data[0].x - x) * (_data[0].y - y));

  for (int i = 1; i < _count; i++)
  {
    double d = fabs((_data[i].x - x) * (_data[i].y - y));
    if (dist > d) dist = d;
  }

  return sqrt(dist);
}

a teď stručně charakteristiku a pár typů k optimalizaci:

• množství bodů se po initializaci nebude měnit, init() tedy má možnost vytvořit a inicializovat další datové struktury potřebné k hledání (binární stromy, atd).
• protože to chci použít v počítačové grafice, jedna z optimalizací může využít fakt, že budu potřebovat hledat vždy pozice, které mají stejnou Y souřanici a na ose X budu přičítat 1.0.

optimalizace tedy může využít potřeby pro tuto funkci:

void DistanceFinder::findSpan(double x, double y, int count, double* results)
{
  for (int i = 0; i < count; i++, x += 1.0) 
    results[i] = find(x, y);
}

Tak co, věděl by někdo, jakým směrem mám jít? Potřeboval bych vědět, jaké nejlepší datové struktury a algoritmy volit pro vytvoření dat, které použiju k efektivnímu vyhledání. Budu používat metodu findSpan(), takže samotná find() není vůbec důležitá.

Chtěl bych to použít na generování podobných obrázků jako tyto.

Odpovědi

[saslik]

Jako trivialni reseni se  mi jevi, ze bych si nad mnozinou bodu vytvoril dva indexy dle souradnic x a y a s jejich pouzitim pak hledal metodou okenka. Napr. nejprve v kruznici o polomeru a, pak a*1,5 apod. Inspiraci pro lepsi reseni mohou byt struktury jako quadtree nebo R-tree.

[stativ]

Já bych z toho vytvořil váhovou matici sousednosti přičemž bych předpokládal, že body tvoří úplný graf (všechny jsou spojeny se všema) a pak zkusil třeba Dijkstru nebo Floyda.

[petr_p]

Matice sousednosti vytvoří kvadratické množství hran. Dijkstra má složitost O(E+V.log(V)), tedy složitost by byla kvadratická. To naivní prohledání je lineární ;)

Navíc Dijkstra je moc obecný. Tady si můžeme dovolit počítat s tím, že vzdálenosti bodů respektují topologii (tedy pokud se pohybujeme v Euklidovském prostoru). Například navržené kvarterní stromy jsou použitelné (používá to třeba Google na svých mapách).

Ono obecně hledání ve vícerozměrných strukturách je ošklivé a moc se toho nedá ulehčit. Většina GISových algoritmů předpokládá nějaké zjednodušení, které umožní preferovat jeden směr (třeba autor říká, že bude hledat jen ve směru osy), na kterém se vybuduje efektivní vyhledávací struktura a vedlejší veličiny se pak už neohrabaným způsobem navěsí na její listy.

[Radek Miček]

Nevím, jestli jsem to dobře pochopil. Máš neprázdnou množinu bodů M a úsečku mezi body [a, y] a [b, y], kde a<b. A pro určité body úsečky [z, y] chceš určit vzdálenost k nejbližšímu bodu z množiny M?

Budu předpokládat (možná špatně), že tě zajímají pouze vybrané hodnoty y např. 0, 1, 2, 3, ... A těch hodnot, které tě zajímají není mnoho. Potom pro každé y, které tě zajímá, můžeš spočítat intervaly na ose x [u1, u2], [u2, u3], [u3, u4],... takové, že pro každý bod [x,y], kde x je z intervalu [u(i), u(i+1)], bude nejbližší bod p(i).

Příklad: Tedy pokud máš množinu M se dvěma body p(1)=[0, 1] a p(2)=[2, 1], a zajímá tě y=0, pak si předem spočítáš intervaly [-nekonečno, 1], [1, nekonečno] a pro každou úsečku mající y=0 víš, že pro každý bod s x <= 1 je nejbližší bod p(1) a pro x >= 1 je nejbliží bod vždy p(2).

Tedy časová složitost je pro celou úsečku O(log n +count). Předzpracování nepočítám.

[volca]

Podle me by mohl pomoci vyvazeny BSP strom. Liche body budou rezat 2d prostor horizontalne, sude vertikalne. Find potom bude traverzovat podle uzlu, vzdy vybere tu polovinu prostoru na ktere sedi hledany bod (a zapamatuje nejkratsi vzdalenost) - body v druhe polovine prostoru jsou urcite dal.

Jde jen o to vyvazit ten BSP strom, aby v kazdem uzlu byla velikost obou vetvi srovnatelna.

[volca]

A sakra, jak ted o tom premyslim tak by to nefungovalo. Ty delici primky musi byt v polovine mezi dvema body, nikoli skrze body samotne...

[AraxoN]

BSP podľa osí ma tiež napadlo ako prvé, ale nerieši to podmienku najmenšej vzdialenosti od hľadaného bodu.

Dotaz ma ale inšpiroval do tej miery, že idem kúpiť pravítko, trojuholník, ceruzky, kružidlo a papiere a večer nad tým budem bádať

[volca]

Hodne stesti :)

Podle me to podle os nepujde, ale pujde to jako kolmice na spojnici dvou bodu v jejim stredu (ekvidistanta tech dvou bodu). Ta primka potom opravdu deli prostor na body blize bodu A a/nebo B. To vyvazovani by slo bud brute-force, tim ze se najde takova dvojice, jejiz delici cara produkuje pomer bodu na obou stranach co nejblizsi jednicce, nebo by mozna sel ten strom i zoptimalizovat po naivnim vybudovani - to vyvazovani bude obecne vetsi problem nez vystaveni toho stromu jako takoveho - coz je celkem jednoducha operace.

Co se tyce toho dotazu, tam je zajimave ze by mozna slo snadno zoptimalizovat prochazeni tim, ze se bude predavat cela mnozina bodu (ve forme usecky). Usecka se potom bude delit ve dvi v kazdem uzlu - vzniknou segmenty se stejnou prislusnosti k nejblizsimu bodu po protlaceni vsech segmentu do listu :)

[AraxoN]

Operácia zistenia toho, na ktorej strane priamky leží bod je (ak si dobre pamätám) triviálna - dosadia sa súradnice bodu do rovnice priamky ax+by+c a ak je výsledok kladný, tak to leží na jednej strane (ľavý podstrom), ak záporný tak na druhej (pravý podstrom) a ak rovný nule, tak bod leží na priamke (to by sa priradilo ku jednému z podstromov). Takže by z hľadiska výpočtovej zložitosti ani veľmi nevadilo, že priestor nebude delený podľa osí X a Y...

[volca]

Tak po dalsim zamysleni musim odvrhnout myslenku ze to jde po segmentech - kazdy bod se musi resit zvlast. Podle os to samozrejme lze taky resit (kd-tree), ten prohledavaci algoritmus zkratka hleda nejkratsi bod do hloubky a neprechazi prez rozdelujici primku co je dal nez aktualni nejlepsi kandidat...

[AraxoN]

Tu nižšie v diskusii je odkaz na wikipediu (Voronoi diagram) a sú k tomu aj algoritmy. Spomína sa tam zložitosť O(n.log(n)), čo mi pripadá o dosť lepšie než to nad čím som uvažoval ja ... ale aspoň som sa trochu precvičil v rysovaní a som zásobený písacími pomôckami na 10 rokov dopredu!

[xnov22]

http://en.wikipedia.org/wiki/Voronoi_diagram

[Ivan]

Hmm nevim jestli je to pro tvoji ulohu optimalni alg. Ale predtav si nasledujici situaci:

1. mame nakonecne veliky ctverec(koren stromu)

2. Vlozime do nej jeden bod -> ctverec se rozdeli na 4 pod-ctverce. Tyto pod-ctvrce jsou synove korene.

3. Mame dalsi bod. Projdeme koren, najdeme spravneho syna, a do nej vlozime dalsi bod a rozdelime ho na 4 syny

Pokud svoje body rozume nahodne zamichas, tak dostanes strom, ktery projdes log. case. Podobny alg. se pouziva pro reprezentaci map, akorat se misto bodu pouzivaji usecky.

Ivan

 

 

[petr_p]

A říká se tomu kvarterní strom.

[tomfi]

A není právě řešení toho problému to co je na tom nejlepší, nejzáživnější? ... samotné naprogramování už je pak nuda.

[Deleted [8409]]

Takže díky všem za reakce. Něco jsem zkoušel, ale zdá se mi, že chci řešit problém jiným způsobem, než by se měl řešit. Chci generovat výplň, která je definovaná jako grafická cesta (v GDI+ je to PathGradientBrush), tak mě napalo vygenerovat body té cesty, pak hledat ten nejbližší a podle toho přiřadit pixelu barvu (podle gradient lut tabulky). Jenže tento způsob je asi overkill a řešit se to dá pomocí trojúhelníků.

Jinak pomocí nejkratší vzdálenosti se mi líbí ty Voronoi diagramy, myslím, že by to krásně sedlo na hledání pole hodnot, ale stejně to budu řešit s největší pravděpodobností pomocí těch trojúhelníků.

Kdyby někdo věděl i jiný způsob, rád se nechám poučit. Kdybych měl upřesnit problém, tak já hledám nejkratší vzdálenost k úsečkám (tedy grafické cestě složené z úseček), ale měl jsem pocit, že jednodušší by bylo převést to na body a jen hledat nejkratší vsdálenosti k nim.