Nya funktioner till NAT Pro

[LillWicke]

Jag hade tanken att bygga scripten bottom-up, alltså få gjort minsta möjliga
deloperationerna först så att jag har "byggklossar" som går att återanvända
när jag bygger på senare med mer sammansatta funktioner.

Smart tänkt shadowtvister, en av tankarna (bland många) med den här tråden och dump-kommandot är ljust att man ska kunna modulbygga sina modeller ungefär som med lego, och kanske också dela med sig av en smart legobit till andra. För att detta ska vara möjligt fullt ut måste scripten kunna hantera dataserier både på ”input” och ”outputsidan” samt internt kunna hantera loopar, mellanlagring av dataserier samt kunna sätta pekare på bestämda poster i dataserien.

Bertils totalmodell kan man ju till viss del säga är modulbyggd men inte riktigt ändå.
En modulmodell kommunicerar fram och tillbaka åt alla håll med alla modulerna samtidigt.
Detta går inte idag, men skulle bli möjligt med dump-kommandot som den här tråden handlar om.

Tanken jag har är att utgå från en lista (listgrupp) som innehåller alla svenska aktier (701 st).
På denna lista vill jag sedan köra masterscriptet som innehåller alla "sub-script".

Masterscriptet ska sedan ge en ny lista som resultat som innehåller alla
aktier där något av de tolv sub-scripten hittat en formation (multipelt OR-villkor).

Om du ska kunna åstadkomma detta på ett bra sätt behöver du absolut ha dump-kommandot.

Nu är det juldags för mig också. God jul på er och tack igen för hjälpen !

/Robban

God jul på dig också Robban

[Henric]

Nu, i och med att vi till NAT-språket har fått en LOOP-funktion så börjar språket bli i stort sett helt komplett (enligt mitt sätt att se det), det saknas egentligen bara en ytterligare NAT-funktion som gör det möjligt att kunna spara ned egna värden i en databas för att sedan kunna hämta dem igen i form av en dataserie.

Om detta vore på plats skulle man utan begränsningar kunna använda språket till att tillverka egna syntetiska instrument, egna påhittade indikatorer egna index eller annat av intresse som man vill skapa dataserier av, och som sedan alla andra script/modeller i sin tur direkt kan ta del av. På så sätt skulle scriptaren inte vara beroende av att Autostock tillverkar den efterfrågade funktionen om ett nytt krav likt AMA skulle dyka upp.

(OBS! jag pratar här inte om "input" utan om "output" och vad som händer i scriptningen innan "output". AMA var ju exempelvis inte möjlig att tillverka i NAT-språket och det finns fler sådana exempel.)

Jag har funderat på hur en sådan funktion skulle vara konstruerad och lägger därför upp ett förslag här. Förutsättningen är att Autostock skapar en ny mindre helt parallell kloning av NAT:s nuvarande databas. Låt oss säga en databas på max 10000 id:n.

De nya funktionerna är tänkta att vara en kombination utav redan existerande funktioner och funktionalitet för att göra kodningen för Autostock lite enklare.
Exempelvis skulle SetIniIf() lika väl kunna lagra direkt till en databas istället för som nu till inifilen.

Som sagt, hela grejen med detta utspel är att få så kompletta grundfunktioner för programmering som möjligt i NAT och att man inte ska behöva gå till Autostock och be om nya fuktioner hela tiden även om det är praktiskt.

Jag tänker jag mig, att om vi får kompletta grundfunktioner så kan hela scriptkollektivet vara med och bidra med utvecklingen av nya NAT-funktioner framöver. När någon scriptat en ny funktion som visar sig användbar kan man dela med sig av denna till andra och i efterhand be Autostock om att inlämma den i utbudet, för det är ju trots allt så att en C-kodad NAT-funktion är mycket snabbare än en scriptad, speciellt om funktionen är avancerad.
Obs när jag menar dela med sig, menar jag här enskilda nya NAT-funktioner, inte kompletta handelsmodeller.

Om de här funktionerna kommer till stånd kan jag visa er på många spännande tillämpningar framöver.

Nåväl, i nästa inlägg kommer mitt förslag, kommentera och debattera gärna, ordet är fritt!!

Jag förstår vad du vill åstadkomma. Gemensamma nyckeln är alltid tid och egentligen är det funktioner för att välja och beräkna från existerande data och möjlighet att även skapa dataset, tex listor(typ SQL). Eftersom att alla beräkningar på något sätt härleds från existerande data skulle det räcka att kunna välja, läsa, beräkna och använda resultaten(typ Queries). Nu kanske det inte går och då måste egna lagringar av informationen göras. Då du skriver att 10000 dataserier ska kunna användas gäller det nog att ha tungan rätt i mun då dessa används. Det kan också lätt hända att script som inte används i dag läser och skriver till en databas.

Intressant om detta är möjligt och vilken overhead det skulle skapa. En annan tanke är att syntetiska instrument kan skapas i nuvarande databas med eller utan att behöva skriva från vanliga script.

[LillWicke]

Henric, äntligen ytterligare ett inlägg som behandlar själva trådämnet.

Vad jag pratar om är script som tar in och gör beräkningar på existerande data.
Resultatet av dessa beräkningar ska sedan kunna lagras i dataserier.
Det kan också inträffa att scriptet självt inte kan slutföra sina beräkningar utan att först behöva mellanlagra delresultatsberäkningar som direkt går att adressera ett antal poster bakåt vid loopningar osv. Detta kan inte lösas med SQL-frågor.

Ett annat script skall sedan kunna ta del av de beräknade dataserierna på samma sätt som om de vore vilken aktiekurs som helst, utan att själv behöva göra om samma procedur som beräkningsscriptet.

Det blir alltså möjligt att i NAT skriva egna anropningsbara funktioner/procedurer utan att behöva krångla till det alltför mycket.

Att databasen skulle bestå av 10.000 id:n var bara ett förslag det kanske räcker med 2.000 vad vet jag. De globala har ju idag 900 och man behöver inte ha tungan mer rätt i munnen för att behandla de nya id-nummren än man behöver ha för att behandla de globala. Det finns ju dessutom ett clear-komando.

Om man vill göra det hela bombsäkert kan man utöka id:t i databasen på så sätt att några id:n är allmänna (200 för plats 200) och några är låsta till endast ett visst script-id.

Dump-funktionerna som jag föreslagit är ju relativt lätta för Autostock att skapa, all kod för dessa ligger ju redan skapad i det befintliga NAT-programmet.

Overheaden skulle vara:
a) dels att det blir möjligt att scripta nya anropningsbara funktioner.

b) dels att Autostock initialt slipper att befatta sig med nya NAT-funktionskrav.

c) dels att det blir möjligt att relativt enkelt scripta ren fundamental (optisk) teknisk analys, vilken är mer träffsäker än den sedvanliga laggande indikatorbaserade.

d) dels att det blir enklare att scripta icke-linjära modeller, vilka inte är beroende av nackdelar som curvefitting.

e) dels att det blir överflödigt att utveckla nuvarande cmpref-funktioner till att gälla för mer än tre. (vilket idag är lite knepigt att åstadkomma)

Osv. osv.

[Henric]

Jag håller med i stort. Tänkte mer på overhead då det kan bli fler parallella processer och läsning mellan flera databaser. Den vanliga databasen har ju uppsatta regler för instrument, osv. Jag tror programmet idag lägger upp nedladdningar i minnet och dumpar i intervaller. Detta måste styras för att allt ska fungera och dataintegriteten ska behållas i kombination med alla andra processer. Vad gäller SQL tänkte jag mer på det som i Visual Basic är dataset/recordset, vilket blir en dataserie där varje värde går att nå. Då behövs ingen skrivning, utan bara läsning och massage av existerande data. Tex en scriptfunktion som definierar och hämtar en lista där ett visst villkor är uppfyllt. Finns crcid i listen blir värdet sant. Lycka till som general för denna möjlighet.

[LillWicke]

Har nu uppdaterat inlägg #3 med ett antal exempel så att Bertil förhoppningsvis kan bli nöjd.

[jimmy]

Hej,

Finns det någon återkoppling från Autostock om denna funktionalitet är under utvärdering för kommande version?

Röstar

[johansson]

nExt2

Något nytt om när nExt2 ska komma?
jag läste vid årsskiftet att detta skulle testas skarpt i januari...

[Rikard Nilsson]

Vi väntar fortfarande på klartecken, allt har dragit ut på tiden i och med integrationen med Shareville hos Nordnet. Testerna är gjorda och det som återstår är klartecken att börja gå live med kunder.

[johansson]

Hej, något nytt om nExt2?

[Rikard Nilsson]

Ja nu börjar det hända saker äntligen, vi testkör skarpt med nExt2 nu och jobbar med alla konfig-ändringar. Alla instrument har fått nya identifiers och marknader heter annat nu osv. Men det fungerar fint så här långt, vi hoppas kunna börja släppa på ett mindre antal kunder inom ett par veckor. Det återstår lite jobb med nyhetsfeeden.