Forex Walk Forward Testing

Walk Forward Analyzer er nå ledig Gå til nedlastningssiden for å få din gratis kopi Hvordan vet du om din ekspertrådgiver er virkelig lønnsom MetaTraders Strategy Tester gir deg ikke hele bildet Er du trading basert på altfor optimistiske backtests, og skuffet over å finne at din ekspertrådgiver mister penger i live trading Vil du vite om din ekspertrådgiver er lønnsomt, raskt og enkelt, uten å miste penger. The Walk Forward Analyzer for MetaTrader. The Walk Forward Analyzer bruker MetaTraders egen strategi tester for å utføre en gjennomgangsanalyse . bruker innstillingene og testparametrene som er oppgitt av brukeren. Programvaren er enkel å bruke, og kan gi deg en komplett gjennomgangsanalyse i en brøkdel av tiden det ville ta for deg å gjøre det manuelt. En gjennomgangsanalyse avgjør om en ekspertrådgiver er lønnsom når han handler med optimaliserte parametre på data utenfor data. Enhver ekspertrådgiver kan produsere et imponerende optimaliseringsresultat, men den sanne testen er om resultatene vil holde seg når de testes over fremtidige data. Walk Forward Analyzer utfører denne prosessen mange ganger i løpet av måneder og år med historiske data, noe som gir deg et nøyaktig bilde av den sanne ytelsen til din ekspertrådgiver. Når du er ferdig med en gjennomgangsanalyse, vil du bli presentert med en detaljert gjennomgangsrapport, som viser resultatene av test - og optimaliseringsløpene, den totale testresultatet, og effektiviteten for å gå videre. som er et mål på hvor robust ditt handelssystem er. Se Walk Forward Analyzer i bruk Hvis du ikke er kjent med prosessen med å gå videre, kan du lese Hva er Walk Forward Analysis for å finne ut hvorfor det er den beste metoden for å bestemme robustheten og potensiell lønnsomhet i handelssystemet ditt. Videoen nedenfor gir en komplett gjennomgang og veiledning av Walk Forward Analyzer for MetaTrader: Hva er Walk Forward Analysis Gå videre anaylsis er prosessen med å optimalisere et handelssystem ved å bruke et begrenset sett med parametere, og deretter teste det beste optimaliserte parametersettet ut - av-prøve data. Dette ligner på hvordan du vil bruke din ekspertrådgiver i live trading. Prinsippene for gå fremoveranalyse ble først beskrevet i boken Evaluering og optimalisering av handelsstrategier av Robert Pardo. For å utføre en gjennomgangsanalyse i MetaTrader, optimalisere først ekspertrådgiveren i Strategy Tester. Deretter velger du det mest lønnsomme resultatet i fanen Optimaliseringsresultater, og utfører en backtest over en tidsperiode umiddelbart etter optimaliseringsperioden. Slutdatoen for optimaliseringsperioden er den samme som startdatoen for testperioden. Denne prosessen gjentas igjen og igjen til en tilfredsstillende prøvestørrelse oppnås. Hvis ekspertrådgiveren klarer seg godt i testing, i forhold til optimaliseringsresultatene, kan man konkludere med at ekspertrådgiveren sannsynligvis vil være lønnsom i live trading. Hvis den ekspertrådgiver derimot utfører dårlig testing, må optimeringsparametrene eller lengden av test - og optimaliseringsperioder justeres. Hvis, etter mange forsøk, ikke ekspertrådgiveren fortsatt har det bra i testingen, kan det konkluderes med at handelssystemet er urentabelt. Animasjonen til høyre illustrerer prosedyren for å gå videre. En optimalisering utføres over en lengre periode (in-sample data), og deretter testes det optimerte parametersettet i løpet av en etterfølgende kortere periode (dataene utenfor prøven). Optimaliserings - og testperioder forflyttes fremover, og prosessen gjentas til en passende prøvestørrelse oppnås. Kilde Et eksempel på en Walk Forward-analyse Lar oss gi et eksempel på virkelige liv: Skal utføre en gjennomgangsanalyse på en ekspertrådgiver ved å bruke EURUSD M30. Vel optimaliser denne ekspertrådgiveren over en periode på 120 dager. Weve valgte de 3 eller 4 viktigste parameterne for å optimalisere, for ikke å overoptimere eller kurve passer resultatene. Færre parametere betyr også en raskere test. Vel velg det mest lønnsomme resultatet, og kontroller disse parametrene over en 30-dagers periode umiddelbart etter optimaliseringsperioden. Det anbefales å bruke en testperiode på ca. 25 av lengden på optimaliseringsperioden. Når vi har registrert resultatene våre, flytter du neste optimalisering og testperiode fremover med 30 dager. Etter 12 påfølgende runder med optimalisering og testing, har vel et år verdt å gå fremoveranalysedata. Vi sammenligner gjennomsnittlig daglig fortjeneste for optimaliseringsperioder til gjennomsnittlig daglig fortjeneste for testperioder. Dette vil gi oss en beregning som kalles forover-effektivitetsforholdet. En effektivitetsgrad på mer enn 0,5 blir vurdert som et meget godt resultat. Dette kalles et robust handelssystem. Imidlertid er en ekspertrådgiver handelbar så lenge det er konsekvent lønnsomt over flere testperioder. Hvis det går negativt for fortjenestevirkningsforholdet, betyr det at ekspertrådgiveren ikke har det bra i forhold til optimaliseringsresultatene. Selvfølgelig kan du gjøre en gjennomgangsanalyse manuelt i MetaTraders Strategy Tester. Men prosessen er kjedelig, tidkrevende og utsatt for feil. Dette er hvor Walk Forward Analyzer-programvaren kommer inn. Programmet vil automatisk utføre en gjennomgangs-analysering ved hjelp av MetaTraders Strategy Tester over lengre tid, med bare noen få innstillinger som tilbys av brukeren. Testtesting og fremovertesting: Betydningen av korrelasjonshandlere som er ivrige etter å prøve en handelsidee i et levende marked, gjør ofte feilen ved å stole helt på backtesting resultater for å avgjøre om systemet vil være lønnsomt. Mens backtesting kan gi handelsmenn verdifull informasjon, er det ofte misvisende, og det er bare en del av evalueringsprosessen. Utprøvingstesting og fremoverprestasjonstest gir ytterligere bekreftelse om system effektivitet, og kan vise et system ekte farger, før ekte penger er på linjen. God korrelasjon mellom backtesting, out-of-sample og forward performance testresultater er viktig for å bestemme levedyktigheten til et handelssystem. (Vi tilbyr noen tips om denne prosessen som kan bidra til å forfine din nåværende handelsstrategi. For å lære mer, les Backtesting: Tolkning av fortiden.) Grunnleggende om sikkerhetskopiering Backtesting refererer til å bruke et handelssystem til historiske data for å verifisere hvordan et system ville ha utført i løpet av den angitte tidsperioden. Mange av dagens handelsplatforme støtter backtesting. Traders kan teste ideer med noen få tastetrykk og få innsikt i effektiviteten av en ide uten å risikere penger på en handelskonto. Backtesting kan evaluere enkle ideer, for eksempel hvordan et flytende gjennomsnittsovergang ville utføre på historiske data, eller mer komplekse systemer med en rekke innganger og utløsere. Så lenge en ide kan kvantifiseres, kan den bli testet. Noen handelsmenn og investorer kan søke kompetanse fra en kvalifisert programmør for å utvikle ideen til en testbar form. Vanligvis innebærer dette en programmerer som koder ideen inn i proprietært språk som er vert for handelsplattformen. Programmereren kan inkludere brukerdefinerte inputvariabler som tillater handelsmannen å justere systemet. Et eksempel på dette ville være i det enkle glidende gjennomsnittsovergangssystemet som er nevnt ovenfor: Traderen vil kunne legge inn (eller endre) lengdene til de to bevegelige gjennomsnittene som brukes i systemet. Traderen kunne backtest for å bestemme hvilke lengder av bevegelige gjennomsnitt som ville ha utført det beste på de historiske dataene. (Få mer innsikt i Electronic Trading Tutorial.) Optimaliseringsstudier Mange handelsplattformer tillater også optimaliseringsstudier. Dette innebærer å legge inn et område for den angitte inngangen og la datamaskinen gjøre matematikken for å finne ut hvilken innspilling som ville ha gjort det beste. En multi-variabel optimalisering kan gjøre matematikken for to eller flere variabler kombinert for å bestemme hvilke nivåer sammen ville ha oppnådd det beste resultatet. For eksempel kan handelsmenn fortelle programmet hvilke innspill de vil legge til i deres strategi, disse vil da bli optimalisert til deres ideelle vekter gitt de testede historiske dataene. Backtesting kan være spennende ved at et ulønnsomt system ofte kan bli forvandlet til en pengemaskin med noen få optimaliseringer. Dessverre fører tweaking av et system for å oppnå det høyeste nivået av fortjeneste, ofte til et system som vil utføre dårlig i reell handel. Denne overoptimaliseringen skaper systemer som ser bra ut på papir. Kurvmontering er bruk av optimaliseringsanalyse for å skape det høyeste antallet vinnende handler med størst profitt på de historiske dataene som ble brukt i testperioden. Selv om det ser imponerende ut i backtesting-resultatene, fører kurvepassing til upålitelige systemer, siden resultatene er i hovedsak tilpasset for den aktuelle datoen og tidsperioden. Backtesting og optimalisering gir mange fordeler til en næringsdrivende, men dette er bare en del av prosessen når man vurderer et potensielt handelssystem. Et handlende neste trinn er å bruke systemet til historiske data som ikke har blitt brukt i den første backtesting-fasen. (Det bevegelige gjennomsnittet er enkelt å beregne, og når det er tegnet på et diagram, er det et kraftig visuelt trendspottingsverktøy. For mer informasjon, les Simple Moving Averages. Gjør trendene stående.) Eksempel vs. Uttrykksdata Når du tester en ide om historiske data, er det fordelaktig å reservere en tidsperiode med historiske data for testformål. De første historiske dataene som ideen er testet og optimalisert, refereres til som in-sample data. Datasettet som er reservert, kalles ikke-eksempeldata. Dette oppsettet er en viktig del av evalueringsprosessen fordi den gir en måte å teste ideen på data som ikke har vært en komponent i optimaliseringsmodellen. Som et resultat vil ideen ikke bli påvirket på noen måte av dataene utenfor prøven, og forhandlere vil kunne bestemme hvor godt systemet kan utføre på nye data, dvs. i real-life trading. Før du starter opp en eventuell backtesting eller optimalisering, kan handelsfolk legge til side en prosentandel av de historiske dataene som skal reserveres for prøveutprøving. En metode er å dele de historiske dataene i tredjedeler og å skille seg ut en tredjedel for bruk i prøveutprøvingen. Bare in-sample dataene skal brukes til opprinnelig testing og optimalisering. Figur 1 viser en tidslinje der en tredjedel av de historiske dataene er reservert for prøveutprøving, og to tredjedeler brukes til prøveutprøvingen. Selv om Figur 1 viser dataene utenfor prøven i begynnelsen av testen, ville typiske prosedyrer ha utelukkende del umiddelbart før den fremadrettede ytelsen. Figur 1: En tidslinje som representerer den relative lengden av in-sample og out-of-sample data som brukes i backtesting prosessen. Når et handelssystem har blitt utviklet ved hjelp av in-sample data, er den klar til å bli brukt på dataene utenfor prøven. Traders kan evaluere og sammenligne resultatresultatene mellom dataene i prøven og utdataene. Korrelasjon refererer til likheter mellom forestillingene og de generelle trendene i de to datasettene. Korrelasjonsmålinger kan brukes til å evaluere strategiske resultatrapporter opprettet i testperioden (en funksjon som de fleste handelsplatformene gir). Jo sterkere korrelasjonen mellom de to, desto bedre er sannsynligheten for at et system vil fungere godt i fremoverprestasjonstesting og live trading. Figur 2 illustrerer to forskjellige systemer som ble testet og optimalisert på in-sample data, deretter anvendt på data utenfor data. Diagrammet til venstre viser et system som var tydelig kurvepasset for å fungere godt på dataene i prøven og helt mislyktes på dataene utenfor prøven. Diagrammet til høyre viser et system som fungerte bra på både in - og ut-av-prøve data. Figur 2: To egenkapitalkurver. Handelsdataene før hver gult pil representerer prøveutprøvning. Handlingene som genereres mellom de gule og røde pilene indikerer ikke-prøvetesting. Handlingene etter de røde pilene kommer fra de fremadrettede testfaser. Hvis det er lite sammenheng mellom prøven og prøven utenfor prøven, som venstre diagram i figur 2, er det sannsynlig at systemet har blitt overoptimert og ikke vil fungere godt i live trading. Hvis det er sterk korrelasjon i ytelsen, sett i det høyre diagrammet i figur 2, innebærer neste evalueringsfase en ekstra type prøveutprøving, kjent som fremoverprøving. (For mer lesing om prognoser, se Finansiell prognose: Den bayesiske metoden.) Grunnleggende forsendelsesprestasjonstester Videresend ytelsestest, også kjent som papirhandel. gir forhandlere et annet sett med data utenom prøven som skal evaluere et system. Forward performance testing er en simulering av faktisk handel og innebærer å følge systemlogikken i et levende marked. Det kalles også papirhandel siden alle handler utføres kun på papir, det vil si, handelsoppføringer og utganger dokumenteres sammen med eventuelle gevinst eller tap for systemet, men ingen egentlige handler utføres. Et viktig aspekt ved fremoverprestasjonstesting er å følge systemlogikken nøyaktig ellers blir det vanskelig, om ikke umulig å nøye vurdere dette trinnet i prosessen. Handlere bør være ærlige om handelsoppføringer og utganger og unngå atferd som kirsebærplukking, eller ikke med en handel på papir som rasjonaliserer at jeg aldri ville ha tatt den handel. Hvis handelen skulle ha skjedd etter systemlogikken, bør den dokumenteres og evalueres. Mange meglere tilbyr en simulert handelskonto hvor handler kan plasseres og tilsvarende resultat og tap beregnes. Ved å bruke en simulert handelskonto kan du opprette en semi-realistisk atmosfære som du kan øve på handel og videre vurdere systemet. Figur 2 viser også resultatene for fremoverprestasjonstesting på to systemer. Igjen, det system som er representert i det venstre diagrammet, klarer ikke å gjøre det bra utover den opprinnelige testingen på in-sample data. Systemet som vises i riktig diagram, fortsetter imidlertid å fungere bra gjennom alle faser, inkludert fremoverprestasjonstesting. Et system som viser positive resultater med god korrelasjon mellom in-sample, out-of-sample og forward performance testing, er klar til å bli implementert i et levende marked. Bottom Line Backtesting er et verdifullt verktøy som er tilgjengelig i de fleste handelsplatformene. Å dele historiske data i flere sett for å sørge for prøveutprøving og prøveutprøving kan gi forhandlere et praktisk og effektivt middel for å vurdere en handelsidee og et system. Siden de fleste handelsfolk bruker optimaliseringsteknikker i backtesting, er det viktig å deretter vurdere systemet på rene data for å bestemme dens levedyktighet. Fortsett testing utenfor prøven med fremoverprestasjonstest gir et annet sikkerhetslag før du setter et system i markedet som risikerer ekte penger. Positive resultater og god korrelasjon mellom in-sample og out-of-sample backtesting og forward performance testing øker sannsynligheten for at et system vil fungere godt i faktisk handel. (For en omfattende oversikt over teknisk analyse, se Teknisk analyse: Innledning.) Artikkel 50 er en forhandlings - og oppgjørsklausul i EU-traktaten som skisserer trinnene som skal tas for ethvert land som. Et første bud på et konkursfirma039s eiendeler fra en interessert kjøper valgt av konkursselskapet. Fra et basseng av tilbudsgivere. Beta er et mål for volatiliteten, eller systematisk risiko, av en sikkerhet eller en portefølje i forhold til markedet som helhet. En type skatt belastet kapitalgevinster pådratt av enkeltpersoner og selskaper. Kapitalgevinst er fortjenesten som en investor. En ordre om å kjøpe en sikkerhet til eller under en spesifisert pris. En kjøpsgrenseordre tillater handelsmenn og investorer å spesifisere. En IRS-regelen (Internal Revenue Service) som tillater straffefri uttak fra en IRA-konto. Regelen krever at. Walk-forward testing AmiBroker 5.10 inneholder den automatiske Walk-Forward testmodusen. Den automatiske Walk forward-testen er en systemdesign og valideringsteknikk der du optimaliserer parameterverdiene på et tidligere segment av markedsdata (8221in-sample8221), og deretter verifiserer ytelsen til systemet ved å teste det fremover i tide på data som følger optimaliseringen segment (8221out-of-sample8221). Du evaluerer systemet basert på hvor godt det utfører på testdataene (8221out-of-sample8221), ikke dataene den ble optimalisert på. Prosessen kan gjentas i etterfølgende tidssegmenter. Følgende illustrasjon viser hvordan prosessen fungerer. Formålet med fremdriftsprøven er å bestemme når ytelsen til optimalisert handelssystem er det realistiske eller resultatet av kurvepassing. Systemets ytelse kan betraktes som realistisk dersom den har forutsigbar verdi og fungerer bra på usynlige (ikke-utvalgte) markedsdata. Når systemet er riktig utformet, bør real-time trading ytelse være i forhold til det avdekket under optimalisering. Hvis systemet skal fungere i ekte handel, må den først passere en gjennomgangstest. Med andre ord, vi bryr oss egentlig ikke om in-sample resultater som de er (eller burde være) alltid gode. Det som betyr noe, er ikke-systematisk ytelse. Det er det realistiske estimatet av hvordan systemet vil fungere i ekte handel, og vil raskt avsløre eventuelle kurvepassende problemer. Hvis ytelsen er dårlig, bør du ikke handle slikt system. Forutsetningen for å utføre flere optimaliseringstester trinn over tid er at den siste tiden er et bedre grunnlag for å velge systemparameterverdier enn den fjerne fortiden. Vi håper at parameterverdiene som er valgt på optimaliseringssegmentet, vil være godt egnet til markedsforholdene som umiddelbart følger. Dette kan eller ikke være tilfellet da markeder går gjennom bearbull syklus, så det bør tas hensyn når du velger lengden på prøveperioden. For mer informasjon om systemdesign og verifisering ved hjelp av fremdriftsprosedyre og alle involverte problemer, kan vi anbefale Howard Bandys bok: quotQuantitative Trading Systemsquot (se linker på AmiBroker-siden). Hvis du vil bruke Walk-Forward-optimalisering, kan du følge disse trinnene: Gå til Verktøy-gtAutomatisk analyse Klikk på Innstillinger-knappen, og bytt deretter til Walk-Forward-fanen Her kan du se Gå fremoverinnstillinger for In-sample-optimalisering, start-og sluttdato Marker startperiode Begynn slutt Denne perioden vil bli flyttet fremover for trinn til slutten når siste dato. Startdatoen kan også bevege seg for trinn, eller kan forankres (konstant) hvis forankret kontroll er på. Hvis du markerer Bruk i dag, blir Last innlagt dato ignorert, og i dag (nåværende dato) vil bli brukt i stedet. Som standard velges en 8220EASY MODE8221 som forenkler prosessen med å sette opp WF-parametere. Det forutsetter at: a) Utenom prøvesegmentet følger umiddelbart prøvesegmentet b) lengden på eksempelsegmentet tilsvarer trinnet for fremoverføring Basert på disse to antagelsene, tar 8220EASY8221-modusen inn i prøven END-dato og setter ut START-dato for utgang til neste dag. Deretter legges til i prøve-STEP, og dette blir slutten på slutten av prøven. In-sample og Out-of-sample trinnverdier er satt til de samme verdiene. 8220EASY8221-modusen garanterer at WF-prosedyreinnstillingene er riktige. Du bør bruke Easy Mode (EOD) når du tester på slutten av dagen eller Easy-modus (Intradag) når du tester på intradagdata. Forskjellen er at i EOD-modus er sluttdatoen for forrige periode og START-datoen for neste periode den samme, og dermed unngås gapet mellom perioder. Intradag-modus angi START-dato for neste periode som NESTE DAG etter END av forrige periode. Det garanterer at grenseverdien ikke teller to ganger ved testing på intradagdata. I avansert modus. brukeren har full kontroll over alle verdier, i den grad de ikke utgjør gyldig WF-prosedyre. Grensesnittet gjør det mulig å deaktivere in-sample og out-of-sample faser ved å bruke avmerkingsboksene øverst (for spesielle ting som å kjøre sekventielle backtests uten optimalisering). Alle innstillinger gjenspeiles umiddelbart i PREVIEW-listen som viser alle genererte ISOOS-segmenter og deres datoer. 8220 optimaliseringsmål 8221-feltet definerer optimaliseringsrapporten KOLOMNAMN som skal brukes til å sortere resultater og finne den beste. Enhver innebygd kolonne kan brukes (som vist i optimaliseringsutgangen), eller du kan bruke en tilpasset beregning som du definerer i tilpasset backtester. Standard er CARMDD, men du kan imidlertid velge hvilken som helst annen innebygd metrisk fra kombinasjonsboksen. Du kan også TYPE-IN noen tilpasset beregning som du har lagt til via egendefinert backtester-grensesnitt. Når du har definert Walk-Forward-innstillinger, går du til Automatisk analyse og trykker på rullegardinpilen på optimaliser knappen og velger 8220Walk Forward Optimization8221Dette vil kjøre sekvensen av optimizaitons og backtest, og resultatene vises i 8220Walk Forward8221-dokumentet som er åpent i hovedapplikasjonsramme. Når optimalisering kjører, kan du klikke på 8220MINIMIZE8221-knappen på fremdriftsdialogboksen for å minimere den - dette gjør det mulig å se fremdriftsfremgangen under optimaliseringstrinnene. IN-SAMPLE OG UTSATT SAMMENSETNING AV KAPITALKAPITAL Kombinert in-sample og out-sample aksjer er tilgjengelige av OSEQUITY kompositt tickers (sammenhengende perioder med IS og OOS er sammenkoblet og skalert for å opprettholde kontinuitet i egenkapitallinjen - denne tilnærmingen antar at du generelt å snakke er sammensatt fortjeneste). For å vise IS og OOS egenkapital kan du for eksempel bruke dette: ISEQUITY. In-sample Equity. colorRed. styleLine) PlotForeign (utgave av sammendragsrapporten (ny i 5.60) Versjon 5.60 gir en ny sammenføyningsrapport som går utover alle trinnene. Det er synlig i Report Explorer som sist og har quotPSquot-type . Det var betydelige endringer for å gå fremoverprøving laget for å tillate sammendrag utenom prøverapporten. Den viktigste forandringen er at hver påfølgende prøveutprøve bruker opprinnelig egenkapital som tilsvarer tidligere trinnvis egenkapital. (Tidligere brukte den konstant første egenkapital). Denne endringen kreves for riktig beregning av alle statistikkmetriene i alle seksjoner av prøveutvalget. Sammendragsrapport viser notatet at innebygde beregninger representerer alle utgangsstrøkene riktig, men sammendrag tilpassede beregninger er sammensatt ved hjelp av brukerdefinerbar metode: 1 første trinns verdi, 2 siste trinns verdi, 3 sum, 4 gjennomsnitt, 5 minimum, 6 maks. Som standard oppsummeringsrapport viser siste trinns verdi av egendefinerte beregninger UANSETT brukeren spesifiserer forskjellig kombinasjonsmetode i bo. AddCustom Metrics () call. bo. AddCustomMetrics har nå ny valgfri parameter - CombineMethod bool AddCustomMetric (streng Tittel, variant Verdi, valgfri variant LongOnlyValue, valgfri variant ShortOnlyValue. valgfri variant DecPlaces 2, valgfri variant CombineMethod 2) Denne metoden legger til tilpasset beregning i backtestrapporten, backtest quotsummaryquot og optimaliseringsresultatliste. Tittel er et navn på metriske som skal vises i rapporten, Verdi er verdien av metriske, valgfrie argumenter LongOnlyValue, ShortOnlyValue tillater å gi verdier for ytterligere longshort-only kolonner i backtestrapporten. Siste argument DecPlaces kontrollerer hvor mange desimaler som skal brukes til å vise verdien. KombinertMetod-verdier som støttes, er: 1 første trinns verdi, - Sammendragsrapport vil vise verdien av tilpasset beregning fra aller første ut-av-prøve trinn 2 siste trinns verdi (standard), - Sammendragsrapport vil vise verdien av tilpasset beregning fra den siste summen av verdiene for tilpasset metrisk fra alle ut av prøve trinn 4 gjennomsnitt, - Sammendragsrapport vil vise gjennomsnittet av verdiene til tilpasset beregning fra alle ut av prøve trinnene 5 minimum, - Sammendragsrapport vil vise den minste verdien av tilpasset metrisk fra alle ut av prøve trinn 6 maksimal. Sammendragsrapport vil vise den største verdien av tilpasset beregning fra alle ut av prøveinntak Merk at visse beregningsmetoder for beregning er komplekse og for Eksempelvis gjennomsnittlig dem ville ikke føre til matematisk korrekt representasjon av alt ut av prøveprøven. Sammendrag av alle innebygde beregninger er matematisk korrekt utenom boksen (dvs. de er ikke gjennomsnitt, men riktig beregnet beregning ved hjelp av metode som passer for gitt verdi). Dette er i motsetning til tilpassede beregninger, fordi de er brukerdefinerbare, og det er opp til brukeren å velge kombinasjonsmetode, og det kan likevel skje at ingen av de tilgjengelige metodene er hensiktsmessige. Av den grunn inkluderer rapporten notatet som forklarer hvilken brukerdefinerbar metode som ble brukt til å kombinere tilpassede beregninger.