Velocità barre a volume (timer)
Forums › ProRealTime forum Italiano › Supporto ProBuilder › Velocità barre a volume (timer)
- This topic has 11 replies, 3 voices, and was last updated 4 years ago by
nazzareno.
-
-
12/12/2020 at 1:11 PM #15349512/12/2020 at 6:46 PM #153517
Non sono sicuro che sia quello che desideri, ma se vuoi semplicemente la durata in secondi dell’ultima barra a volume costante potresti fare così:
- Imposti come tipologia di grafico delle barre a volume costante
- Crei e applichi un indicatore fatto così:
duration in secs12secs = openhour*3600 + 60*openminute + opentime mod 60return secs - secs[1] as "duration"
Se vuoi il valore aggiornato via via (quindi non solo quello a barra chiusa) potresti essere interessato a sostituire openhour/openminute/opentime con hour/minute/time.
12/12/2020 at 9:51 PM #153528Ti ringrazio Daniele.
La durata in secondi è quello che vorrei ottenere mediante indicatore e rappresentazione ad istogramma.
Applicando la tua formula i valori risultano sbagliati ed anche negativi… oltretutto impossibile..
Per cortesia prova a verificarlo.
Grazie,
Nazzareno
12/12/2020 at 10:33 PM #153530Prova questo (io non l’ho provato):
123456secs = openhour*3600 + 60*openminute + CurrentSecondx = secs - secs[1]If x < 0 thenx = x + (24 * 3600)EndifReturn x as "duration"12/12/2020 at 10:59 PM #153532secs between bars with julian date123456789101112131415// computed julian datey=openyearm=openmonthd=opendayy=y+8000if(m<3) theny=y-1m=m+12endifjuliandate = (y*365) +(y/4) -(y/100) +(y/400) -1200820 +(m*153+3)/5-92 +d-1secs = juliandate*86400 + openhour*3600 + 60*openminute + opentime mod 60return secs - secs[1] as "duration in secs"Con questa dovrebbe essere quasi sempre corretta. Ovviamente tra due giorni vedrai un picco, e nei finesettimana un picco ancor più grande.
12/13/2020 at 10:45 AM #153548Buongiorno, andando a rileggermi i post passati ho trovato la risposta.
Ecco la formula corretta:
123456789101112131415161718192021222324252627282930313233343536Ora1 = OpenTime //ORA attualex = round((Ora1 / 100) - 0.5) * 100 //trovi l'ora ed i minuti, senza secondiss1 = Ora1 - x //trovi i secondiy = round((x / 10000) - 0.5) * 10000 //trovi l'ora senza secondi e senza minutimm1 = (x - y) / 100 //trovi i minutihh1 = round((Ora1 / 10000) - 0.5)//////////////////////////////////////////////////////////////////////Ora2 = OpenTime[1] //ORA della candela precedentex = round((Ora2 / 100) - 0.5) * 100 //trovi l'ora ed i minuti, senza secondiss2 = Ora2 - x //trovi i secondiy = round((x / 10000) - 0.5) * 10000 //trovi l'ora senza secondi e senza minutimm2 = (x - y) / 100 //trovi i minutihh2 = round((Ora2 / 10000) - 0.5)//////////////////////////////////////////////////////////////////////// Calcolo delle differenzeDiffH = hh1 - hh2 //Differenza tra le oreIF DiffH < 0 THENDiffH = DiffH + 23ELSIF DiffH=1 THENDiffH=0m1=m1+60ENDIFDiffM = mm1 - mm2 //Differenza tra i minutiIF DiffM < 0 THENDiffM = DiffM + 59ELSIF ss1 < ss2 THENDiffM = DiffM - 1ENDIFDiffS = ss1 - ss2 //Differenza tra i secondiIF DiffS < 0 THENDiffS = DiffS + 59ENDIF////////////////////////////////////////////////////////////////////////Riportare tutto in SECONDIDiff = Diffs + (DiffM * 60) + (DiffH * 3600)RETURN Diff AS "Secondi"Creato questo indicatore, vorrei calcolare la differenza tra esso e la sua media mobile esponenziale a 3 periodi.
Non riesco a capire come si fa a richiamare un indicatore personalizzato e mettere il mettere il relativo parametro in una media.
12/13/2020 at 10:54 AM #153549Allora, nel codice che ti ho dato c’era un errore (il mod 60 non dava sempre valori corretti).
Usa questa soluzione, dovrebbe essere corretta, inoltre dovresti teoricamente avere i valori corretti anche a cavallo tra due barre appartenenti a settimane/mesi/anni diversi.secs between bars with julian days1234567891011121314151617181920212223242526//computed julian datey=openyearm=openmonthd=opendayy=y+8000if(m<3) theny=y-1m=m+12endiffrac = opentime/100rounded = round(frac)// computing floorBase and ceilBase (functions are not available in v10.3)if rounded > frac thenfloorBase = (rounded-1) * 100elsefloorBase = rounded * 100endifopenseconds = opentime - floorBasejuliandate = (y*365) +(y/4) -(y/100) +(y/400) -1200820 +(m*153+3)/5-92 +d-1secs = juliandate*86400 + openhour*3600 + 60*openminute + opensecondsreturn secs - secs[1] as "duration in secs"Tuttavia se ti è sufficiente che il valore sia corretto semplicemente a cavallo tra le giornate infrasettimanali puoi usare la soluzione di roberto, che sicuramente è più efficiente della mia, però la usi con le costanti “open” ti suggerisco di rimpiazzare “currentsecond” con “openseconds” (come li ho calcolati nel mio codice), perché se una barra dura più minuti “currentsecond” ti sballa il conteggio.
Quindi per capirsi, se non ti interessa avere i valori corretti solo tra giornate adiacenti (quindi infrasettimanale) puoi usare questa:duration infrasettimanale1234567891011121314151617frac = opentime/100rounded = round(frac)// computing floorBase and ceilBase (functions are not available in v10.3)if rounded > frac thenfloorBase = (rounded-1) * 100elsefloorBase = rounded * 100endifopenseconds = opentime - floorBasesecs = openhour*3600 + 60*openminute + opensecondsx = secs - secs[1]If x < 0 thenx = x + (24 * 3600)EndifReturn x as "duration"(ho calcolato il floor in modo che funzioni anche nella PRTv10… nella v11 hai una funzione diretta per farlo…)
12/13/2020 at 11:04 AM #153550differenza tra valore x e media exp a tre periodi di x123x = // il tuo valore (nel tuo caso il valore che trovavi nel return delle funzioni prima)ema = ExponentialAverage[3](x)return x - ema12/13/2020 at 12:18 PM #15355912/13/2020 at 1:57 PM #153576Hai scritto “x = mySecondi = …”, probabilmente basta rimuovere “mySecondi =” (e quindi scrivere solo “x = CALL …”) e dovrebbe andare.
Tuttavia se puoi eviterei di usare la CALL.
Quindi io, se usassi il codice che ti ho passato farei così:duration with ema diff1234567891011121314151617181920212223242526272829//computed julian datey=openyearm=openmonthd=opendayy=y+8000if(m<3) theny=y-1m=m+12endiffrac = opentime/100rounded = round(frac)// computing floorBase and ceilBase (functions are not available in v10.3)if rounded > frac thenfloorBase = (rounded-1) * 100elsefloorBase = rounded * 100endifopenseconds = opentime - floorBasejuliandate = (y*365) +(y/4) -(y/100) +(y/400) -1200820 +(m*153+3)/5-92 +d-1secs = juliandate*86400 + openhour*3600 + 60*openminute + opensecondsdur = secs - secs[1]ema = ExponentialAverage[3](dur)return dur - ema as "duration - ema[3](dur)"Però forse stiamo andando un po’ fuori dal topic iniziale…
12/13/2020 at 3:52 PM #153584Scusami Nazzareno se ti ho fatto un po’ impazzire, spero comunque che adesso hai chiaro come fare ciò che desideravi.
Comunque per chiudere posto la mia versione finale corretta (almeno spero eheheh) per fare ciò che richiedevi nel titolo iniziale del topic.
Tieni presente che questo codice per funzionare correttamente richiede che il timezone sia impostato su UTC+00:00.seconds between bars with julian day1234567891011121314151617181920212223242526272829303132333435363738394041// Compute julian date (must be used with UTC+00:00 Time Zone)y=openyearm=openmonthd=openday// The most negative year in the current Julian period is -4713 Gregorian (4714 BC), so we want to add something to y so we can simplify reasoning about our calculations by considering only positive year values. Any value divisible by 4000 could be chosen, since the pattern of leap years in the reformed Gregorian calendar repeats every 4000 years.y=y+8000// Since leap days are added at the end of February, it makes sense to consider January and February as the last two months (numbered 13 and 14) of the previous year. That way, leap days are always added at the end of the notional year.if(m<3) theny=y-1m=m+12endif// The Julian calendar has normal years of 365 days, plus extra leap days every fourth year.jd1 = (y*365) + (y - (y mod 4)) /4// The Gregorian calendar adds the correction that a century year is not a leap year, unless it is also divisible by 400.jd2 = -(y - (y mod 100)) /100 + (y - (y mod 400)) /400// This correction allows for the 3287-year difference between the arbitrary positive year offset we added earlier and the real Julian Day epoch of 1st. January, 4713 BC, Julian calendar (24th. November, 4714 BC, Gregorian calendar).jd3 = -1200820// With the months starting with March=3 and ending with February=14, there is a simple pattern of month lengths: 31, 30, 31, 30, 31, 31, 30, 31, 30, 31, 31 That is, there are always 30=150/5 days in each month with an additional day every 3/5 month. Since we started with March=3, the first value given would be (3*153+3)/5 = 92, but we want to start from zero so we make a correction.jd4 = ((m*153+3) - ((m*153+3) mod 5)) /5 - 92// The Julian Day number goes up once a day. Days of the month are conventionally numbered from 1, so we subtract 1.jd5 = +d-1// julian dayjd = jd1 + jd2 + jd3 + jd4 + jd5frac = opentime/100rounded = round(frac)if rounded > frac thenfloorBase = (rounded-1) * 100elsefloorBase = rounded * 100endifopenseconds = opentime - floorBasesecs = jd*86400 + openhour*3600 + 60*openminute + opensecondsreturn secs - secs[1] as "duration in seconds"Credits to jd-code per la conversione da data del calendario gregoriano a julian day.
Un saluto, e buona domenica!12/13/2020 at 6:20 PM #153595 -
AuthorPosts
Find exclusive trading pro-tools on