Obchodní algoritmus Solany se snáze chápe, když sledujeme jedno pravidlo od jeho vstupů až po konečný záznam účtu. Široké popisy jako nakupovat podle momenta nebo automatizovat výstupy nechávají příliš mnoho věcí neurčených. Užitečné podrobnosti se týkají toho, která pozorování vstupují do pravidla, kdy se zdrží rozhodnutí, jak je návrh autorizován a jak se výsledná akce posuzuje.
Tento článek rozvíjí jeden záměrně jednoduchý příklad snížení pozice. Nejde o doporučenou strategii ani tvrzení ziskovosti. Jeho účelem je ukázat úplnou specifikaci, kterou si čtenář může ručně vypočítat a porovnat s implementací.
Smyšlené pravidlo, v tomto článku nazvané R1, sleduje stávající tokenovou pozici. Za definovaných podmínek navrhuje prodat pevnou část poté, co prodejní kotace pro konkrétní množství vzroste vůči krátkému dokončenému základnímu období. Návrh stále vyžaduje samostatnou autorizaci účtu a čerstvé podklady pro provedení.
Řešený příklad obchodního algoritmu Solany potřebuje účel
Účelem R1 je vytvořit posouditelný návrh částečného snížení pozice, kterou již postup spravuje. Neobjevuje nové tokeny, nevyvozuje záměr obchodníka ani nevybírá celé portfolio. Tento úzký rozsah udržuje příklad zaměřený na vztah mezi pozorováními a jedním druhem akce.
Algoritmus používá pevný mint tokenu a podporovanou interpretaci trhu. Pozoruje kotace pro prodej přesně 100 tokenů za pojmenované kotovací aktivum. Každé porovnání používá stejný směr a množství. Kotace pro nákup 100 tokenů nebo prodej jiného množství nevstupuje do základního období, jako by byla rovnocenná.
Starší průvodce architekturou obchodního bota Solany odděluje pozorování, strategii, autorizaci a ověření skutečného stavu se sladěním záznamů. R1 tyto hranice dodržuje. Spuštění pravidla je navrženým rozhodnutím, zatímco výsledek účtu vyžaduje podklady z pozdějších fází.
Určete balíček pozorování
Každý balíček pozorování obsahuje identitu mintu, kotovací aktivum, vstupní množství, očekávaný výstup, čas pozorování, rozsah zdroje nebo trasy a stav interpretace. Uvádí také, které náklady jsou již ve výstupu zohledněny. Balíček by měl být uložen dříve, než se stane vstupem pravidla.
Pro R1 je výstupem prodejní kotace pro konkrétní množství, nikoli obecná cena tokenu. To spojuje porovnání těsněji se zamýšleným množstvím snížení, přičemž nejistota provedení přetrvává. Kotace je podkladem o podmínkách v určitém čase, nikoli zárukou pozdějšího výsledku účtu.
Balíček potřebuje jasný čas dostupnosti. Kotace získaná z historie po rozhodovací uzávěrce nemůže vstoupit do přehrání, jako by byla známa dříve. Důkazní stopa jediného algoritmu začíná tím, co systém mohl skutečně prozkoumat v okamžiku běhu pravidla.
Definujte dokončené základní okno
R1 porovnává nejnovější způsobilou kotaci s průměrným výstupem tří předchozích dokončených pozorování vybraných podle pevného rozvrhu. Rozvrh a pravidla čerstvosti jsou součástí verze pravidla. Nevybírají se později tak, aby základní období vyšlo příznivě.
Všechna tři základní pozorování musejí splňovat stejné požadavky na identitu, množství, směr a podporu. Pokud jedno chybí nebo je neplatné, R1 se v tomto příkladu zdrží rozhodnutí. Potichu nezkracuje základní období ani nenahrazuje chybějící hodnotu nejnovější kotací.
Složitější algoritmus by mohl použít jiný výpočet, ale specifikace by potřebovala stejnou jasnost. Smyslem není tvrdit, že tři pozorování tvoří silný prediktivní model. Smyslem je, že malý pevný výpočet usnadňuje prozkoumání vstupní hranice a odhaluje, jak chybějící data mění rozhodnutí.
Stanovte rytmus posuzování pro příklad
Pro tuto řešenou specifikaci si představte posouzení naplánovaná každých pět minut. Posouzení v 10:00 používá jako základ zaznamenané balíčky kotací z 09:45, 09:50 a 09:55 a samostatnou nejnovější kotaci pro současné posouzení. Každý balíček musel při přijetí ve vlastním čase posouzení splňovat minutový limit čerstvosti; nejnovější balíček jej musí stále splňovat při současném rozhodnutí.
Tyto intervaly jsou ilustrativním nastavením, nikoli doporučenými obchodními frekvencemi. Činí příklad reprodukovatelným a brání implementaci vybírat libovolná tři historická pozorování poskytující pohodlný základ. Pokud naplánovaný balíček nebyl dostupný, uplatní se pravidlo R1 pro chybějící vstup, místo aby se bez výslovné změny verze sahalo dále do minulosti.
Vyjádřete spouštěcí podmínku srozumitelně
R1 navrhuje snížení, když je nejnovější způsobilý výstup alespoň o 5 % nad průměrem tří základních výstupů. Práh je zvolen pouze pro ilustraci. Rovnost podle tohoto pravidla vyhovuje a výpočet používá nezaokrouhlené zaznamenané hodnoty před formátováním pro zobrazení.
Podmínka popisuje relativní změnu kotovaného příjmu za stejné množství 100 tokenů. Netvrdí, že lze celou pozici prodat za takto naznačený kurz ani že je další pohyb ceny předvídatelný. To by byly jiné otázky vyžadující jiné podklady.
Průvodce obchodními signály Solany vysvětluje, proč detekce nebo předpověď automaticky nepředstavuje ekonomickou výhodu. Spuštění R1 je pouze definovaným přiřazením události k návrhu. Jeho užitečnost by vyžadovala samostatné hodnocení výsledků, nákladů a alternativního chování, které nahrazuje.
Vypočítejte spuštění ručně
Předpokládejme, že smyšlené základní výstupy činí padesát, padesát dva a padesát jedna kotovacích jednotek. Jejich průměr je padesát jedna. Nejnovější výstup je padesát čtyři. Relativní nárůst je tři děleno padesáti jednou, přibližně 5,88 %, takže číselná spouštěcí podmínka je při 5% prahu R1 splněna.
Výpočet by měl být uložen s identifikátory vstupů. Hodnotitel jej pak může reprodukovat bez současné stránky trhu. Pokud je vstup později opraven, uchovejte původní rozhodnutí a zaznamenejte, jak se opravený výpočet liší, místo tichého přepsání dřívějšího výstupu.
Tento výpočet nedokazuje přínosnost navrženého prodeje. Dokládá pouze, že zaznamenaná pozorování splňují určenou spouštěcí podmínku. Další fáze kontrolují, zda pozice existuje, zda je množství dostupné, zda kotace zůstává aktuální a zda akce odpovídá pravidlům účtu.
Posouzení pravidla obchodního algoritmu Solany zahrnuje způsobilost
R1 pracuje pouze se spravovanou pozicí s alespoň 300 dostupnými tokeny před navrženým snížením o 100 tokenů. Příklad tedy po úspěšném snížení ponechává alespoň 200 tokenů. Toto množstevní pravidlo je ilustrativní a patří do definice strategie, nejde o univerzální doporučení velikosti.
Pravidlo také vyžaduje podporovanou interpretaci tokenu a trhu, úplné základní období, čerstvé nejnovější pozorování a nepřítomnost nevyřešeného záměru snížení rezervujícího stejné držené tokeny. Pokud kterýkoli požadavek není splněn, výstup uvádí důvod zdržení se rozhodnutí, místo aby vracel zavádějící nulové skóre.
Posouzení pravidla obchodního algoritmu Solany by mělo tyto požadavky ověřit před zkoumáním výpočtu prahu. Matematicky správný výsledek 5,88 % nemůže vyvážit nesprávný mint, zastaralé podklady ani nedostupné držené množství. Způsobilost určuje, zda výpočet dává smysl pro zamýšlenou akci.
Udržujte návrh v užším rozsahu než hranici oprávnění
Když se R1 spustí, vytvoří návrh na snížení pozice o 100 tokenů. Návrh obsahuje verzi pravidla, odkazy na podklady, množství, současný kontext kotace a dobu platnosti. Sám transakci nepodepisuje ani neodesílá.
Samostatný autorizační krok kontroluje pravidla účtu a současný stav. Účet může návrh zamítnout, protože jiná akce rezervovala držené tokeny, oprávnění není dostupné nebo navržená trasa leží mimo rozsah. Zamítnutí je platným výsledkem i při splnění pozorovacího pravidla R1.
Průvodce obchodním systémem Solany vysvětluje trvalou odpovědnost za tyto záznamy. Oddělení návrhu a autorizace umožňuje hodnotiteli odlišit zdržení se rozhodnutí strategie od zamítnutí účtem. Tyto výsledky naznačují různá zlepšení a neměly by se slučovat do obecného počtu neprovedených obchodů.
Před pokusem znovu zkontrolujte kotaci
Kotace, která spustila R1, může ztratit platnost dříve, než je akce připravena k odeslání. Postup by měl získat aktuální podklady a uplatnit uvedená pravidla pro podstatné změny. Staré spuštění nedokládá, že původně pozorovaný výstup zůstává dostupný.
Pokud nová kotace již nesplňuje podmínky návrhu, akce může být zamítnuta nebo vrácena k opětovnému hodnocení. Pravidla by měla vysvětlovat, zda původní spouštěcí podmínka musí stále platit, nebo zda pokus řídí samostatně autorizovaná hranice provedení. Příklad tuto volbu neponechává nahodilému rozhodnutí pracovníka.
Spouštěcí kotaci a pozdější kotaci pro provedení uchovávejte odděleně. Jejich rozdíl je užitečným podkladem o zpoždění a proveditelnosti. Nahrazení původní kotace pozdější by ztížilo vysvětlení toho, proč se algoritmus vůbec spustil.
Rezervujte držené tokeny pro autorizované snížení
Předpokládejme, že účet má při autorizaci návrhu na 100 tokenů k dispozici 500 tokenů. Postup rezervuje navržené množství, aby jiné výstupní pravidlo nemohlo nezávisle předpokládat, že všech 500 zůstává dostupných. Pokud se akce dokončí podle záměru, zbývá 400 tokenů před zohledněním nesouvisejících změn účtu.
Rezervace přetrvává po nevyřešenou dobu pokusu podle pravidel ověření skutečného stavu a sladění záznamů. Může být uvolněna, když neodeslaný návrh ztratí platnost nebo když podložené důkazy doloží výsledek umožňující uvolnění. Plánovač by ji neměl uvolnit jen proto, že začíná další interval.
Starší průvodce koordinací výběru zisku a omezení ztráty na Solaně pojednává o soupeřících výstupních podmínkách. R1 je jedním možným zdrojem návrhu snížení. Jeho implementace musí spolupracovat se všemi ostatními zdroji prostřednictvím sdíleného záznamu pozice, místo aby držené tokeny spravovala odděleně.
Zaznamenejte odeslání jako pokus
Komponenta provedení zaznamenává autorizovaný záměr a výsledný transakční pokus. Uchovává identitu a časové údaje potřebné ke sledování výsledku. Úspěšná odpověď na odeslání sama není prodejem ověřeným podle skutečného stavu; dokumentace Solany k sendTransaction toto rozlišení výslovně uvádí. Dokumentace odesílání na Solaně.
Pokud je odpověď nejistá, postup by měl prozkoumat stávající pokus. Neměl by znovu spouštět R1 a vytvářet nový prodejní záměr jen proto, že dřívější požadavek nevrátil pohodlný konečný stav. Původní návrh a jeho rezervované tokeny zůstávají součástí stavu účtu.
Toto oddělení také zlepšuje výzkum. Spuštěný návrh, autorizovaný návrh a dokončené snížení jsou různé počty. Provozní proveditelnost algoritmu lze posoudit pouze tehdy, když záznam uchovává přechody a důvody, proč se některé návrhy nikdy nestanou změnami účtu.
Po výsledku ověřte pozici a slaďte záznamy
Jakmile je výsledek transakce doložen podle zvolených pravidel, porovnejte dopad na účet se záměrem. Zaznamenejte snížené množství, příjem, náklady a zbývající spravované tokeny. Pokud se výsledek liší od očekávání, uchovejte nesrovnalost a vyřešte ji dříve, než závislé akce začnou předpokládat bezproblémový stav.
Pozice by po snížení o 100 tokenů z 500 neměla být označena jako zcela uzavřená. Zůstává otevřená s množstvím ověřeným podle skutečného stavu. Stav dokončeného pokusu a stav uzavřené pozice popisují různé objekty a měly by zůstat odlišné v rozhraní i exportu.
Zbývající pozice také ovlivňuje další hodnocení R1. Pravidlo by mělo používat současné dostupné držené množství včetně ostatních rezervací a vnějších změn. Kopírování původního množství 500 tokenů do každého budoucího návrhu by porušovalo samotnou podmínku způsobilosti, kterou specifikace stanovila.
Definujte, kdy se pravidlo může spustit znovu
Bez pravidel opětovné aktivace by R1 mohlo vydávat další snížení při každém pozorování stejné přetrvávající podmínky. Rozhodněte, zda algoritmus povoluje opakovaná snížení, čeká na ukončení podmínky nebo vyžaduje novou základní epizodu před otevřením dalšího návrhu.
V této ilustrativní specifikaci může mít jedna spouštěcí epizoda pouze jeden otevřený záměr snížení. Po vyřešení záměru R1 vyžaduje čerstvé úplné posouzení, jehož nejnovější výstup není více než 2 % nad jeho způsobilým základem, než může začít další epizoda. Toto obnovení uzavírá starou podmínku; pozdější posouzení musí znovu splnit 5% otevírací práh, aby vytvořilo novou epizodu. Požadavky na držené množství a oprávnění nadále platí nezávisle.
To brání opakovaným pozorováním stát se náhodnými pyramidami výstupních záměrů. Definuje to také jednotku výzkumu: jedna epizoda má otevírací podmínku, výsledek návrhu a uzavření nebo obnovení. Počet oznámení a počet pozorování pak lze oddělit od počtu skutečných rozhodnutí algoritmu.
Otestujte případ neúplného základního období
Odstraňte prostřední základní pozorování a ponechte nejnovější výstup na padesáti čtyřech. Podle R1 je očekávaným výsledkem zdržení se rozhodnutí, protože požadovaný základ ze tří pozorování je neúplný. Systém by neměl zprůměrovat padesát a padesát jedna a tvrdit, že původní pravidlo stále proběhlo.
Záznam by měl pojmenovat chybějící vstup a uchovat nejnovější platné pozorování pro pozdější výzkum. Jakmile chybějící pozorování dorazí, systém může rekonstruovat dřívější výpočet, ale jde o retrospektivní výsledek. Nestává se signálem, který byl živě dostupný v původním čase rozhodnutí.
Tento případ testuje informační hranici spíše než výpočet. Program může správně vypočítat průměr a přitom porušit pravidlo použitím neúplného nebo pozdního souboru dat. Smysluplné ověření kontroluje způsobilost vstupů před kontrolou číselného výstupu.
Otestujte zastaralou kotaci a změněné držené množství
Dále ponechte základní období úplné, ale nastavte nejnovější kotaci jako starší než limit čerstvosti R1. Očekávaným výsledkem je podle fáze zdržení se rozhodnutí nebo vypršení návrhu. Nově vykreslená obrazovka by neměla obnovovat stáří podkladové kotace.
Poté obnovte čerstvou kotaci a současně řízenou vnější změnou snižte dostupné držené množství pod 300. Číselná spouštěcí podmínka může stále platit, ale způsobilost pozice selže. Záznam by měl určit množstevní podmínku, místo aby předstíral, že signál zmizel kvůli změně trhu.
Tyto případy ukazují, proč pozorovací pravidla a stav účtu musejí zůstat propojeny. Stejný tržní balíček může vést k různým povoleným výsledkům při změně drženého množství nebo oprávnění. To není nekonzistence; jde o zamýšlené chování úplného algoritmického postupu s výslovnými předpoklady.
Porovnejte R1 s definovanou alternativou
Pro hodnocení užitečnosti R1 zvolte základní chování za stejných předpokladů účtu, pozorování a nákladů. Alternativou může být naplánované pevné snížení nebo žádné snížení až do pozdějšího předem vyhlášeného posouzení. Volba by měla odpovídat výzkumné otázce a vyhýbat se využití znalosti pozdějších událostí.
Průvodce obchodními algoritmy Solany rozvíjí spravedlivé porovnávání pravidel. R1 by nemělo dostávat příznivější kotace, větší rozpočet ani jiný výstupní horizont než alternativa, pokud tento rozdíl není výslovnou součástí studie.
Porovnání by mělo zahrnovat navržená, ale neprovedená snížení, zbývající držené množství a náklady. Pohled pouze na dokončená snížení může skrýt případy, kdy se pravidlo spustilo, ale akce nebyla proveditelná. Úplná cesta účtu poskytuje více informací než sbírka izolovaných úspěšných příkladů.
Před pozdějším posouzením zmrazte pravidlo
Konečná specifikace R1 zahrnuje jeho soubor aktiv, kotované množství, výběr základního období, práh, způsobilost, dobu platnosti, opětovnou aktivaci, předání k autorizaci a účtování výsledků. Tuto úplnou definici zmrazte před zkoumáním pozdějšího hodnoticího období. Změna jediného skrytého předpokladu může podstatně změnit výsledek.
Starší průvodce výzkumným postupem Solany vysvětluje význam časových uzávěrek a pevných pravidel. Pokud pozdější období odhalí vadu nebo nelákavý výsledek, zdokumentujte revizi jako R2 a určete, které podklady byly použity k jejímu výběru.
Pravidlo upravené po prozkoumání hodnoticího okna by si nemělo ponechat tvrzení, že stejné okno nezávisle ověřilo upravenou verzi. Záznam může být stále cenným vývojovým podkladem. Poctivé verzování uchovává to, co výzkum zjistil, bez vytváření dojmu, že konečné pravidlo bylo vybráno předem.
Rozložte posouzení výsledku na jednotlivé části
Posuďte, zda R1 obdrželo úplné podklady, správně vypočítalo spuštění, vytvořilo zamýšlený návrh, prošlo autorizací, dosáhlo doloženého výsledku pokusu a ověřilo pozici se sladěním záznamů. Selhání v každé fázi znamená něco jiného. Správný vzorec nedokládá správnost celého úplného postupu.
Poté samostatně posuďte ekonomickou otázku: co snížení změnilo oproti definované alternativě po nákladech a při stejné cestě účtu? Odpověď může být příznivá, nepříznivá nebo neprůkazná. Interpretovatelnost algoritmu nezaručuje jeho hodnotu.
Užitečná zpráva tedy může uvádět, že implementace odpovídala specifikaci, zatímco strategie nesplnila výzkumný cíl. Může také určit provozní vadu před jakýmkoli ekonomickým tvrzením. Oddělení těchto závěrů směřuje zlepšení k fázi, na kterou podklady skutečně ukazují.
Uchovejte úplný příklad pro budoucí změny
Uchovejte řešenou posloupnost kotací padesát, padesát dva, padesát jedna a padesát čtyři s očekávaným výpočtem 5,88 % a souvisejícími případy způsobilosti. Přidejte záznamy návrhu, autorizace, pokusu a ověření skutečného stavu se sladěním záznamů z řízeného běhu. Tím vzniká stručný referenční příklad pro pozdější změny implementace.
Referenční příklad by měl zahrnovat výsledky bez akce i úspěšnou cestu. Budoucí verze lze kontrolovat podle zamýšlených rozdílů při zachování hranic, které mají zůstat stabilní. Regresní posouzení je nejužitečnější, když ověřuje smysluplné chování, místo aby pouze zrcadlilo nejnovější implementaci.
Obchodní algoritmus Solany se stává posouditelným, když je celý jeho řetězec výslovný. Jedno jednoduché pravidlo může tuto disciplínu ukázat: pozorované podklady vstupují do pevného výpočtu, způsobilost omezuje jeho použití, oprávnění řídí akci a ověření účtu se sladěním záznamů dokládá následek. Stejná jasnost zůstává cenná, i když je výsledný algoritmus složitější.