Czy ktoś z naszych Grupowiczów bawił się może rozwiązaniem następującego
zagadnienia:

"Mamy dwa rachunki bankowe, konto bieżące i konto lokacyjne, drugie z nich
oprocentowane (odsetki dopisywane na koniec optymalizowanego okresu). Wpływy
i wypływy z rachunku bieżącego (daty i kwoty) są znane. Opłaty za przelewy w
obie strony (pomiędzy tymi rachunkami) są też znane i pobierane są w chwili
dokonywania przelewu. Należy zoptymalizować ruchy pomiędzy rachunkami w celu
zmaksymalizowania ich łącznego salda końcowego."

przy zastosowaniu programowania liniowego (tzn. nie interesuję się metodami
brute force, tylko chce mieć coś co sobie potem mogę wrzucić do jakiegoś
solvera simplexowego)? Czyli funkcja celu to suma salda na koniec okresu
dwóch rachunków plus odsetek, które się dopiszą.

Rozwiązanie powyższego zagadnienia można dość banalnie uzyskać stosując
różnego rodzaju metody natury "segmentowej" ale czy ktoś może przymierzał
się do zapisania ogólnego zagadnienia programowania liniowego dla takiego
zagadnienia, co nie wydaje się wcale takie trywialne, choć co do zasady
powinno takim być.

W pierwszym czytaniu zignorowałbym wszelkie dodatkowe ograniczenia czasowe,
przelewów można dokonywać w obie strony każdego dnia oraz wpływ w danym dniu
oznacza także możliwość wypływu w tym samym dniu. Bawił się ktoś albo
spotkał z czymś podobnym w jakimś źródle?

do góry

Osobnik posiadający mail b...@a...w.pl napisał(a) w poprzednim odcinku co
następuje:

> Czy ktoś z naszych Grupowiczów bawił się może rozwiązaniem
> następującego zagadnienia:
>
> "Mamy dwa rachunki bankowe, konto bieżące i konto lokacyjne, drugie z
> nich oprocentowane (odsetki dopisywane na koniec optymalizowanego
> okresu). Wpływy i wypływy z rachunku bieżącego (daty i kwoty) są
> znane. Opłaty za przelewy w obie strony (pomiędzy tymi rachunkami) są
> też znane i pobierane są w chwili dokonywania przelewu. Należy
> zoptymalizować ruchy pomiędzy rachunkami w celu zmaksymalizowania ich
> łącznego salda końcowego."
>
> przy zastosowaniu programowania liniowego (tzn. nie interesuję się
> metodami brute force, tylko chce mieć coś co sobie potem mogę wrzucić
> do jakiegoś solvera simplexowego)? Czyli funkcja celu to suma salda na
> koniec okresu dwóch rachunków plus odsetek, które się dopiszą.
>
> Rozwiązanie powyższego zagadnienia można dość banalnie uzyskać
> stosując różnego rodzaju metody natury "segmentowej" ale czy ktoś może
> przymierzał się do zapisania ogólnego zagadnienia programowania
> liniowego dla takiego zagadnienia, co nie wydaje się wcale takie
> trywialne, choć co do zasady powinno takim być.
>
> W pierwszym czytaniu zignorowałbym wszelkie dodatkowe ograniczenia
> czasowe, przelewów można dokonywać w obie strony każdego dnia oraz
> wpływ w danym dniu oznacza także możliwość wypływu w tym samym dniu.
> Bawił się ktoś albo spotkał z czymś podobnym w jakimś źródle?
>
to chyba nie do konca pytanie na grupe bankowa.

--
Pozdrawia... Budzik
b_ud_zi_k_6_1 na poczta kropka onet kropka pl (adres antyspamowy, usuń także "_")
Dyplomata potrafi powiedzieć "idź do diabła" w taki sposób,
że właściwie cieszysz się na tę wyprawę.

do góry

Użytkownik "Budzik" <b...@p...o.n.e.t.pl.nie.spam.oj> napisał w
wiadomości grup dyskusyjnych:1...@b...poznan.pl...

> to chyba nie do konca pytanie na grupe bankowa.

Zasadniczo masz rację, ale tutaj przewija się mnóstwo sensownych ludzi, a
związek tematyczny występuje, co mnie usprawiedliwia przynajmniej częściowo.
:)

Przecież nie pójdę z tym pytaniem na jakieś fora, gdzie mnie zaraz zapytają
czy to jest praca domowa. Nie jest mi to niezbędne a gdyby nagle się
okazało, że jest to sam też dam sobie radę to "wykminić". Ale nie chce mi
się wyważać otwartych drzwi, o ile są one już otwarte.

do góry

Dnia Sun, 19 Sep 2010 17:02:59 +0200, MarekZ napisał(a):

> Czy ktoś z naszych Grupowiczów bawił się może rozwiązaniem następującego
> zagadnienia:
>
> "Mamy dwa rachunki bankowe, konto bieżące i konto lokacyjne, drugie z
> nich oprocentowane (odsetki dopisywane na koniec optymalizowanego
> okresu). Wpływy i wypływy z rachunku bieżącego (daty i kwoty) są znane.
> Opłaty za przelewy w obie strony (pomiędzy tymi rachunkami) są też znane
> i pobierane są w chwili dokonywania przelewu. Należy zoptymalizować
> ruchy pomiędzy rachunkami w celu zmaksymalizowania ich łącznego salda
> końcowego."
>
> przy zastosowaniu programowania liniowego (tzn. nie interesuję się
> metodami brute force, tylko chce mieć coś co sobie potem mogę wrzucić do
> jakiegoś solvera simplexowego)? Czyli funkcja celu to suma salda na
> koniec okresu dwóch rachunków plus odsetek, które się dopiszą.
>
> Rozwiązanie powyższego zagadnienia można dość banalnie uzyskać stosując
> różnego rodzaju metody natury "segmentowej" ale czy ktoś może
> przymierzał się do zapisania ogólnego zagadnienia programowania
> liniowego dla takiego zagadnienia, co nie wydaje się wcale takie
> trywialne, choć co do zasady powinno takim być.
>
> W pierwszym czytaniu zignorowałbym wszelkie dodatkowe ograniczenia
> czasowe, przelewów można dokonywać w obie strony każdego dnia oraz wpływ
> w danym dniu oznacza także możliwość wypływu w tym samym dniu. Bawił się
> ktoś albo spotkał z czymś podobnym w jakimś źródle?

Ponieważ stawiasz problem bardzo teoretyczno-praktyczny, więc i
odpowiedzi udzielę ci teoretyczno-praktycznej: Tego zagadnienia lepiej
nie traktować jako problem z dziedziny programowania liniowego ze względu
na zaokrąglenia do pełnego grosza.

do góry

Użytkownik "jureq" <j...@X...to.z.adresu.Xop.pl> napisał w wiadomości
grup dyskusyjnych:i76ud5$kn3$...@n...onet.pl...

> Ponieważ stawiasz problem bardzo teoretyczno-praktyczny, więc i
> odpowiedzi udzielę ci teoretyczno-praktycznej: Tego zagadnienia lepiej
> nie traktować jako problem z dziedziny programowania liniowego ze względu
> na zaokrąglenia do pełnego grosza.

Nie widzę tego jako przeszkody. Prowizje, wpływy i wypływy, czyli dane
wejściowe będą w pełnych groszach. Odsetki pojawiają się tylko w funkcji
celu, więc po prostu jeden z parametrów modelu (dobowa stopa procentowa dla
rachunku oprocentowanego) będzie jakimś tam ułamkiem. Zresztą można to
zrobić na siatce, czyli jako programowanie całkowitoliczbowe.

Pytanie jest takie, jakby już się uprzeć na tę metodę (co samo w sobie
raczej udanym pomysłem nie jest) to co by tu najsensowniej przyjąć jako
zmienne decyzyjne, żeby ich się nie zrobiło setki. Bo nie dość że każdego
dnia trzeba decydować czy i w którą stronę wykona się transfer, to jeszcze
trzeba decydować w jakiej wysokości. Co do zasady zagadnienie jest przecież
bardzo proste.

do góry

Dnia Mon, 20 Sep 2010 09:32:41 +0200, MarekZ napisał(a):

> Nie widzę tego jako przeszkody. Prowizje, wpływy i wypływy, czyli dane
> wejściowe będą w pełnych groszach. Odsetki pojawiają się tylko w funkcji
> celu, więc po prostu jeden z parametrów modelu (dobowa stopa procentowa
> dla rachunku oprocentowanego) będzie jakimś tam ułamkiem. Zresztą można
> to zrobić na siatce, czyli jako programowanie całkowitoliczbowe.

Chcesz znaleźć jak masz dzielić między konta/przelewać między nimi. Czyli
kwoty przepływów między tymi kontami będą wynikami a nie danymi
wejściowymi. I ponieważ masz ogranicznie na wynik do pełnych groszy,
dlatego programowanie liniowe nie jest tu najlepszym sposobem.

do góry

MarekZ <b...@a...w.pl> napisał(a):

> Czy ktoś z naszych Grupowiczów bawił się może rozwiązaniem następującego
> zagadnienia:
>
> "Mamy dwa rachunki bankowe, konto bieżące i konto lokacyjne, drugie z nich
> oprocentowane (odsetki dopisywane na koniec optymalizowanego okresu). Wpływy
> i wypływy z rachunku bieżącego (daty i kwoty) są znane. Opłaty za przelewy w
> obie strony (pomiędzy tymi rachunkami) są też znane i pobierane są w chwili
> dokonywania przelewu. Należy zoptymalizować ruchy pomiędzy rachunkami w celu
> zmaksymalizowania ich łącznego salda końcowego."
Tak od strony bankowej i z ciekawości - to możesz podać przykład kiedy coś
takiego może być potrzebne?

Pozdrawiam
Michał M

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Użytkownik "MrMrooz " <m...@g...pl> napisał w wiadomości grup
dyskusyjnych:i77av0$3e1$...@i...gazeta.pl...

> Tak od strony bankowej i z ciekawości - to możesz podać przykład kiedy coś
> takiego może być potrzebne?

Żeby ocenić efektywność zarządzania kapitałem dla danych przeszłych.

Masz konkretne dane dotyczące wpływów oraz wypływów z rachunku bieżącego
oraz przepływy między bieżącym a oszczędnościowym. Chcesz wiedzieć jaki
najlepszy wynik mogłeś osiągnąć i jak daleko od tego optimum było w
rzeczywistości.

W dalszej perspektywie takie narzędzie może być przydatne do wykonywania
analizy scenariuszy przyszłych.

do góry

MarekZ <b...@a...w.pl> napisał(a):

> Żeby ocenić efektywność zarządzania kapitałem dla danych przeszłych.
>
> Masz konkretne dane dotyczące wpływów oraz wypływów z rachunku bieżącego
> oraz przepływy między bieżącym a oszczędnościowym. Chcesz wiedzieć jaki
> najlepszy wynik mogłeś osiągnąć i jak daleko od tego optimum było w
> rzeczywistości.
Pamiętaj, że historyczne dane nie gwarantują osiągnięcia zysków w przyszłości
:-)
A nie lepiej pominąć koszty przelewów? Wtedy przy zerowym/znikomym
oprocentowaniu konta bieżącego optymalizacja jest bardzo prosta:
jak najszybciej po wpływie przelać na lokacyjne
jak najpóźniej przed wypływem przelać z lokacyjnego

Pozdrawiam
Michał M

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Użytkownik "MrMrooz " <m...@g...pl> napisał w wiadomości grup
dyskusyjnych:i77noa$jpj$...@i...gazeta.pl...

> A nie lepiej pominąć koszty przelewów? Wtedy przy zerowym/znikomym
> oprocentowaniu konta bieżącego optymalizacja jest bardzo prosta:
> jak najszybciej po wpływie przelać na lokacyjne
> jak najpóźniej przed wypływem przelać z lokacyjnego

Wtedy narzędzie będzie wybitnie nieuniwersalne, no i zagadnienie się
kompletnie trywializuje. Koszt przelewu spokojnie może być parametrem.
Chciałbym uwzględnić też sytuację darmowego pierwszego przelewu a płatnych
następnych.

do góry