FurioSan

Nie jesteś!

musisz przeczytać cały ciąg.

i to tu jest trick.

dwa przykłady

ciągi

1,2,1

zapis binarny

01,10,01

xory

01xor10 = 11

11xor01 = 10

w innej

10,01,01

10xor01 = 11

11xor01 = 10

teraz dziedzina niech bedzie zbior 3 elementowy

a nasz ciag to

01,10,11,01,11

01xor10 = 11

11xor11 = 00

00xor01 = 01

01xor11 = 10

Ale dlaczego to rozwiazanie jest złe - to czekam na odpowiedz (bo ja juz wiem)

PS

Nic nie zakładaj o przedziale liczbowym.

Jaras nie

>>> def find(l):

... a = None

... for itm in l:

... if a is None:

... a = itm

... else:

... a^=itm

... return a

nie alokujesz na każdy element - masz 'jedna' zmienna tymczasową.

a przejechac po całej tablicy i tak musisz ( raz )

ok, zle przeczytałem. zadziała

No ja tez jeszcze poniżej n/2 +1 przy liniowym czasie nie mam. Przy nie liniowym np nlogn + n to kłopot znika

A co do regexp w bazie danych to różnie z ich wsparciem

Z SQL takim dość nie trywialnym i popularnym jest usuwanie dublikatow z tabel bez pk

Pary zawsze kolo siebie?

Oszukali mnie!

Banda dysydentów!

Przynajmniej piwo dostanę? Nie?

Mamy 2 typy klientów (A i B).

Klient typu A może mieć 'córki' wtedy parent pokazuje na 'matkę'

Do transakcji zawsze dochodzi między A i B ( nie ma możliwości aby w jedną transakcje zaangażowane był A i A lub B i B ) przy czym 'córka' jest również typu A.

CREATE TYPE c_type AS ENUM ('A', 'B');

create table customers

( id serial,

parent int REFERENCE customer (id),

typ c_type,

name text

);

trochę podobną sytuacje mamy z produktami ( zakładamy że ilość produktów jest stała i znama ) czli są produkty główne i pod produkty.

Transakcja może być zawarta zaróno na produkt główny jak i na pod produkt.

CREATE TABLE products

(

id serial,

parent int REFERENCE products(id),

name text

)

wreszcie tabela reprezentująca operacje

create table transactions

( id int,

payer int REFERENCE customer (id),

partner int REFERENCE customer (id),

product int REFERENCE product (id),

secondary_id int,

fee numeric,

CONSTRAINT transactions_pkey PRIMARY KEY (id,payer,product,secondary_id)

);

id to indetyfikator 'transakcji' możemy myśleć że jest identyfikator kontraktu między stronami.

Kontrakt musi obejmować wykonanie jednej lub więcej usług (do ilości produktów) ( produktów ).

Jeden kontrakt zawsze skutkuje conajmniej dwoma wpisami

np kontrakt 1 między A:321 i B:5432 na wykonanie usług 8 i 9 będzie reprezentowany tak:

1;321;5432;8;NULL,1.1

1;5432;321;8;NULL,0.1

1;321;5432;9;NULL,1.43

1;5432;321;9;NULL,32.11

Jak widać z przykłądu powyżej fee za pojedynczą usługę jest różne po każdej ze stron.

Secondary id jest użyty tylko kiedy występuje więcej jak jedna usługa danego typu w obrębie kontraktu.

Ale uwaga jeśli w obrębie jednego kontraktu występują np dwie usługi P3 to ilość transakcji P3 w raporcie o którym mowa w zadaniu to 1.

Przykłąd - Usługa poinformowanie SMS - liczymy za każdego SMS ale traktujemy w raporcie jak 'pakiet'

Teraz wreszcie zadanie.

Trzeba wygenerować raport przychodów i iliści transakcji per Klient A i każdy produkt podstwowy.

Dodatkowo policzyć wpływ wynikający z transakcji od każdego klienta typu A oraz rozbić to na wpływ od owego klienta i 2gich strom wszystkich jego transakcji oraz to samo per każdy produkt i ilość ptrnsakcji takiego prduktu i średnie.

spodziewamy się takiej tabelki na wyjściu

total_fee,total_tr_cnt,total_avg_fee,A_sum_fee,A_avg_fee,B_sum_fee,B_avg_fee,P1_total_fee,P1_A_sum_fee,P1_B_sum_fee,P1_tr_cnt,P1_avg_fee,P1_A_avg_fee,P1_B_avg_fee ...

A1

A2

A3

A4

.

.

.

gdzie kolumny znaczą

total_fee - suma wpływów dla wiersza

total_tr_cnt - ilość transakcji dla wiersza

total_avg_fee - średnia fee dla wiersza

A_sum_fee - suma wpływów od klienata typu A dla wiersza

A_avg_fee - średni fee od klienata typu A dla wiersza

B_sum_fee - suma wpływów od klienata typu B dla wiersza

B_avg_fee - średni fee od klienata typu B dla wiersza

P1_total_fee - suma fee dla produktu P1 dla wiersza

P1_A_sum_fee - suma fee dla produktu P1 od klienta typu A dla wiersza

P1_B_sum_fee - suma fee dla produktu P1 od klienta typu B dla wiersza

P1_tr_cnt - ilość transakcji produktu P1 dla wiersza

P1_avg_fee - średnie fee dla wiersza

P1_A_avg_fee - średnie fee produktu P1 od klienta typu A dla wiersza

P1_B_avg_fee - średnie fee produktu P1 od klienta typu B dla wiersza

Oczywiście każdy produkt musi być zmapowany do Master produktu a każdy klient do master produktu

No i część P powinna być powielona do ilośći master produktów

Zadanie nie jest łatwe ani do zrozumienia ani do wykonania ani do napisania.

Jest to uproszczony sceneriusz czegoś z czym walczyłem ( wygrałem ) niedawno.

Moje rozwiązanie ma jakieś 180 lini ( jest to jedno zapytanie SQL )

ilość wierszy w tabeli transactions to od 1.2 - 2.5 mln

w pliku wyjściowym jest niecałe 900 wierszy i kolumn do AW.

czs wykonania zależy - ale waha się do 90-550 sekund - oparte na PostgreSQL 9.3

( ale mój przypadek jest bardziej złożony )

jake - wejdz na TeamSpeak'a - nie chce mi sie pisać a znam kilka ciekawych zadań

http://www.ikea.com/pl/pl/catalog/products/20103016/

26 zł.

moje pierwsze testy pokazują że jest dokładny a przynajmniej w zakresach użytecznych do piwowarstwa ( około 20-30 stopni reaguje wolno i ciężko stwierdzić dokładność ).

Wydaje mi się, że FurioSan pomieszał 2 pojecia: cukier trzcinowy i cukier brązowy

ja nic nie pomyliłem.

zwróć uwagę że temat i post nr 1 jest edytowany.

Jeśli różnica jest tylko i wyłącznie w kolorze to dlaczego chcesz go barwić?

Poza tym sprytnie zmieniłaś temat wątku - teraz się zgadza - w ten sposób otrzymasz cukier BRĄZOWY a nie trzcinowy.

I teraz nie wjeżdżaj mi na krytykanctwo bo moje bezlitosne obnażenie paranoi skłoniło cię do przeczytania artykułu ( do którego linkujesz ) i poprawieniu dość istotnego błędu logicznego.

Brawo!

TAK, TAK i po stokroć TAK.

głównym składnikiem cukru ( kuchennego ) jest sacharoza nie zależnie od czego pochodzi.

Jeśli uważasz że jedyne czym się różni jest kolor to dodaj plakatówki - będzie taniej.

Przestań też warzyć piwo tylko kupuj z dyskontów - przecież to to samo - woda, trochę c2h5oh i jakieś szczątkowe ( pod względem procentowym ) inne związki.

Jeśli chcesz mieć cukier brązowy to faktycznie - sposób wydaje się być ok, ale jeśli chcesz w ten sposób otrzymać cukier trzcinowy to niestety nie uzyskasz go.

Różnica między cukrem buraczanym a trzcinowym jest ( i nie tylko w kolorze ).

Melasa to:

http://pl.wikipedia.org/wiki/Melasa

"Powstaje jako produkt uboczny podczas produkcji cukru spożywczego. Jest produktem o zawartości około 50% sacharozy, której dalsze odzyskiwanie jest nieopłacalne"

w myśl tej zasady.

Aby 'zrobić' konia siwka potrzeba:

- konia jakiejkolwiek maści ( może być siwek )

- wiadro białej farby

- pędzel

sposób wykonania sobie sami dośpiewajcie.

Reasumując - jeśli zależy ci na kolorze lub 'nabraniu' kogokolwiek to super pomysł!

PS.

Blog do jakiego linkujesz to IMO objaw paranoi zdrowożywieniowej.

Czyli jak dodasz do normalnego białego pieczywa trochę brązowej plakatówki to od razu staje się zdrowym razowym czy pełnoziarnistym ?