Archive for the 'e-commerce' Category

Wyszukiwanie wektorowe [cz. 1]

Pod mądrą nazwą wyszukiwania wektorowego kryje się odpowiedź na proste pytanie:

Jak najlepiej dopasować wyniki wyszukania do zapytania,
w sytuacji gdy nie mamy elementów pasujących idealnie?

W życiu pytanie to pojawia się na wszelkich stronach z wyszukiwarką produktów, czy to mieszkań, czy aut, czy komputerów. Gdy produkty te są opisane wyłącznie za pomocą liczb, sprawa jest prosta. Np.: auto o przebiegu 200 000 km, rok produkcji – 2006, średnie spalanie 8 l/100 km. Wiadomo, że auta o mniejszym przebiegu są lepsze, niż te spalające więcej, że im dawniej wyprodukowano auto, tym gorzej, że lepiej żeby paliło mniej niż więcej. Czy dzięki temu wiemy, jakie auta będą na pewno lepsze, a jakie gorsze od tego z przykładu? Prawie tak. Prawie, ponieważ nie wiemy, jak przeliczyć jeden rok wieku auta na kilometry przebiegu i litry paliwa.

Zacznijmy więc od sprawy najprostszej, czyli od bazy aut o tylko jednej cesze, czyli opisane rokiem produkcji. Powiedzmy, że w bazie znajdą się dwa auta:

  1. A, rok prod. 2001
  2. B, rok prod 2009

Gdy dla szukającego auta do zaakceptowania jest pojazd maksymalnie z 2004 roku, sprawa jest jasna nawet intuicyjnie: wybieramy to z 2009, czyli B.

Zbiór aut pasujących do pytania o niestarsze niż z 2004 roku

Zbiór aut pasujących do pytania o niestarsze niż z 2004 roku

Jednak jeśli szukający postawi sprawę nieco inaczej, czyli zamiast «chcę auto maksymalnie z 2004 roku» powie: «chcę auto wyprodukowane mniej-więcej w 2004 roku», to najbliżej jego ideału jest samochód A, z 2001.

Auto najlepiej pasujące do pytania o "z mniej więcej 2004 roku"

Można mieć wątpliwości, czy wyszukiwarka powinna pokazać auto bliższe zadanym kryteriom, czy też o korzystniejszych parametrach. Rok produkcji to cecha, której wartość wprost przekłada się na jakość auta, zmieńmy ją na taką, która jest neutralna, np. długość pojazdu. Nasza baza zmienia się na taką:

  1. A, długość 390 cm
  2. B, długość 450 cm

Jeśli teraz poszukiwane auto ma mieć 400 cm długości, bardzo blisko tej wartości znajdzie się długość pojazdu A. Gdyby ułożyć samochody z bazy wg dopasowania do zadanych parametrów, A byłoby przed B. To właśnie najprostszy przykład wektorowego opisu wyniku wyszukiwania. Wektor dopasowania to odległość między punktem zadanym przez zapytanie (Z:400 cm) a punktami opisującymi rekordy bazy (A:390 cm i B:450 cm). Wektory dopasowania dla obu aut mają odpowiednio:

  1. Z – A: abs(390 – 400) = 10 cm
  2. Z – B: abs(450 – 400) = 50 cm

funkcja abs(x), czyli wartość bezwzględna ;-)

Dopasowanie aut o długości około 400 cm

Dopasowanie aut o długości około 400 cm

Dla A długość wektora dopasowania jest 5-krotnie mniejsza niż dla B, więc A jest dużo lepiej dopasowany do zadanych parametrów od B. Kiedy do długości dodamy szerokość, sprawa skomplikuje się o drugi wymiar. Wektor dopasowania będziemy wtedy obliczać jako złożenie składowych, 1-wymiarowych wektorów długości i szerokości. To znana zależność, kojarzona z Pitagorasem. ;) Długość wektora dopasowania to pierwiastek kwadratowy z sumy kwadratów obu wektorów składowych.

Przekład na SQL

Przekładając problem na SQL, zaczynamy od takiego pytania:

SELECT * FROM samochody
WHERE dlugosc = 400;

W naszej bazie nie daje ono oczywiście żadnych elementów, czyli zwraca zbiór pusty. Dla naszego poszukiwacza aut to dość frustrująca odpowiedź.
Możemy to nieco poprawić, dodając tolerancję:

SELECT * FROM samochody
WHERE dlugosc > 400 - tolerancja AND
dlugosc < 400 + tolerancja;

To zwiększa szanse na dobry wynik, ale tylko czasem. Tolerancja może być za mała albo za duża, a zawsze jest kolejnym utrudnieniem dla użytkownika.
Moim zdaniem lepiej będzie tak:

SELECT * FROM samochody
ORDER BY abs(400 - dlugosc) ASC;

Wydajnościowo to nienajlepsze rozwiązanie, ale pokazuję tu tylko zasadę. Nienajlepsze, bo spowoduje posortowanie całej bazy aut, w dodatku wg obliczanego, a nie przechowywanego, parametru. W realnych zastosowaniach można uniknąć sortowania wprowdzając nieco więcej logiki przed wykonaniem zapytania.

w roli pojazdu A udział wziął Citroen 1968 Dyane Luxe, w roli pojazdu B - Honda CR-V

kurs EUR w PayPal

Wypłaciłem dziś niewielką kwotę z PayPal. Ponieważ system pracuje w euro, a moje konto niekoniecznie, nastąpiło przeliczenie po kursie. No i tu niespodzianka:
Kurs wymiany: 1 Euro = 3,86084 Złote polskie
Podczas gdy waluty.onet.pl mówią:
USD/PLN Kurs bieżący kupna bid (PLN): 3,9620 Kurs bieżący sprzedaży ask (PLN): 3,9680
Podobną sytuację, tylko w przeciwną stronę opisują na forum money.pl

hm.

Market Data Perspective

Here is the first post in English, as its target is perhaps a bit wider than for my usual gibberish.

The nine month now work for Symagon GmBH (subsidiary of Nagler & Company) has its fruit. Or even a few. The first and what took the most effort is a Flex GUI for investment strategy backtesting and market data review. This was done with Rafał Sytek from Symagon. Backend is kdb+, a vector-oriented, fast database which I know little about ;) and a little Java/Blaze DS middleware. The second is a 3D visualisation tool for order book series. The 3D tool is only a little ‘Flexish’. The main 3D component is a pure Actionscript thing, with layers, 3D-2D and back transformations, etc. And here is what I find cool enough to show off.

This type of visualisation is simpler and closer to the common chart.

This type of visualisation is simpler and closer to the common chart.

The plane beneath the chosen order book helps you compare bid and ask sides.

The plane beneath the chosen order book helps you compare bid and ask sides.

Clicking on a order book strip gets you to the details of single orders.

Clicking on a order book strip gets you to the details of single orders.

Almost a hundred of order books visualised as 3d slope

Almost a hundred of order books in a row

An order book is a snapshot of a market, with (almost) all buy and sell offers for a single financial instrument. I pictured a series of order books as a sloped river bank, with the transaction at water’s level. The ground above is a cumulated size of ask orders beginning from the transaction. The green part is going deeper as the bid orders cumulate. Time axis is horizontal, and Y-axis shows price levels. I believe this visualisation gives a lot more information in a simple manner. Now looking forward to the expert opinion… see what is coming.

Backtesting GUI

This was a good lesson. Series renderers, chart extensions, live scrolling, zooming, syncing between the charts show the real flex guts. Sometimes I felt like writing it from the scratch myself… It was not anything about Flex itself, rather my understanding the complexity of its components. As it turned out, it was usually better to study a bit more the originals rather than implementing one’s own solutions. Some of the comps developed at the beginning look completely naive and weird now. The motto of future Flex chart works is:

ChartElement class is essential to almost all you.

And the big application for testing investment strategies looks like this:

Adobe AIR/Flex frontend of an application for testing investment strategies

Adobe AIR/Flex frontend of an application for testing investment strategies

Next Page »