L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 1196
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Bellissimo!
Domanda da specialista di Python, datemi qualcosa in Python da sperimentare, ho quasi preso la mano con Sharpe, si collega con MT5 senza alcun problema, C# e Python dovrebbero supportarlo, allora posso passare a Python ;)
Python non ha nulla a che fare con il nostro problema. Python è un ammasso di tutto e di più che ci può essere utile, una sottospecie di bifolco con versioni oscure che non sono compatibili da cima a fondo. Il supporto di Python è puramente rustico, sugli appassionati. Le rubriche di pacchetti accettabili in Python non esistono come tali. Qualsiasi cosa da trovare in Python è una ricerca sul forum, da parte degli appassionati.
Questo è particolarmente chiaro quando si confronta Python con R. R è il nostro, il sistema del commerciante, con un eccellente apparato di riferimento e il nostro rubricatore. Non ci sono affatto problemi nel trovare gli strumenti di cui avete bisogno. Ogni pacchetto è ben documentato: descrizioni di chiamate di funzioni, link ad algoritmi che implementano queste funzioni, esempi, link ad articoli relativi al pacchetto. R può essere usato come un libro di testo su qualsiasi problema. E tutto il materiale è assolutamente concreto, supportato dal codice corrispondente.
Python non ha e non può avere un vantaggio su R perché tutto ciò che è interessante per noi è scritto in Cp, mentre Python o R sono le shell per questi pacchetti. A volte Python è più avanti del nuovo pacchetto, a causa della completa mancanza di requisiti di progettazione per i pacchetti e il conseguente supporto. Tutto ciò che appare sugli specchi R viene moderato e la spazzatura viene filtrata.
Il rovescio della medaglia di R è Srr, R stesso è scritto in Srr, ha un'interfaccia perfettamente documentata tra R e Srr. Quindi è sempre possibile abbandonare la shell R e usare direttamente lo strumento stesso, scritto in Srr, da programmi su MCL.
Un'ultima cosa. Per quanto ho capito non c'è ancora un ponte tra Python e MCL. Ma tale ponte tra R ed entrambi gli MCL esiste da molti anni, è liberamente disponibile in kodobase, e non ci sono lamentele - tutto funziona stabilmente, il tester funziona e non ho ancora visto lamentele sulla velocità: i dati sono inviati in memoria.
Il pitone non ha assolutamente nulla a che fare con i nostri problemi. Python è un ammasso di tutto e di tutto ciò che ci è utile, una sottospecie di bifolco con versioni incomprensibili che non sono compatibili da cima a fondo. Il supporto di Python è puramente rustico, sugli appassionati. Le rubriche di pacchetti accettabili in Python non esistono come tali. Qualsiasi cosa da trovare in Python è una ricerca sul forum, da parte degli appassionati.
Questo è particolarmente chiaro quando si confronta Python con R. R è il nostro, il sistema del commerciante, con un eccellente apparato di riferimento e il nostro rubricatore. Non ci sono affatto problemi nel trovare gli strumenti di cui avete bisogno. Ogni pacchetto è ben documentato: descrizioni di chiamate di funzioni, link ad algoritmi che implementano queste funzioni, esempi, link ad articoli relativi al pacchetto. R può essere usato come un libro di testo su qualsiasi problema. E tutto il materiale è assolutamente concreto, supportato dal codice corrispondente.
Python non ha e non può avere un vantaggio su R perché tutto ciò che è interessante per noi è scritto in Cp, mentre Python o R sono le shell per questi pacchetti. A volte Python batte la comparsa di un nuovo pacchetto a causa della completa mancanza di requisiti di progettazione sui pacchetti e il conseguente supporto. Tutto ciò che appare sugli specchi R viene moderato e la spazzatura viene filtrata.
Il rovescio della medaglia di R è Srr, R stesso è scritto in Srr, ha un'interfaccia perfettamente documentata tra R e Srr. Quindi è sempre possibile abbandonare la shell R e usare direttamente lo strumento stesso, scritto in Srr, da programmi su MCL.
Un'ultima cosa. Per quanto ho capito non c'è ancora un ponte tra Python e MCL. Ma un tale ponte tra R ed entrambi gli MCL esiste da molti anni, è liberamente disponibile in kodobase e non ci sono lamentele - tutto funziona in modo stabile, il tester funziona e non ho ancora visto lamentele sulla velocità: i dati vengono inviati in memoria.
Preferisco anche R, ma credo che il futuro nel nostro campo sia in python. Puoi costruirci sopra un sistema completo a ciclo chiuso, dall'analisi al trading. Un esempio è quantopian. Questo non funzionerà per R.
Anche io preferisco R, ma credo che il futuro nel nostro campo sia in python. Può essere usato per creare un sistema completamente a circuito chiuso, dall'analisi al trading. Un esempio è quantopian. Questo non funzionerà in R.
Perché non funziona? Mi sembra che sia già così da molti anni. C'è un proprio terminale IBrokers che ha un'API per lo stesso broker di quantopian.
Ancora una volta, Python è la stessa shell di R. Solo R è uno sviluppo serio, mentre Python è uno strumento pratico, un sacco di utenti che non sono fondamentali per noi e creano rumore.
Il rovescio della medaglia di R è Srr, R stesso è scritto in Srr, ha un'interfaccia perfettamente documentata tra R e Srr. Perciò è sempre possibile abbandonare la shell in R e usare direttamente lo strumento stesso, scritto in Srr, da programmi in MKL.
Questo è probabilmente il motivo per cui il ponte per R è scritto in Pascal.
Saresti un buon venditore, complimenti
Saresti un buon venditore, complimenti.
Nominate almeno un pacchetto di apprendimento automatico in R ampiamente conosciuto e popolare (non per voi, ma per la comunità mondiale).
Ce ne sono altri? Non in R? Ce ne sono quasi 200 solo in caret shell e non tutti, come keras stesso. Vuoi che raccolga statistiche sul loro uso nella comunità globale?
Sono tutte chiacchiere inutili come qualsiasi conversazione sulla scelta del linguaggio di programmazione. Non sono un fan dei podlouches. E per me questo è il criterio decisivo. A ciascuno il suo.
Ce ne sono altri? Non su R? Ce ne sono quasi 200 solo nella shell caret e non tutti, come keras stesso. Vuoi che raccolga statistiche sul loro uso nella comunità globale?
Sono tutte chiacchiere inutili come qualsiasi conversazione sulla scelta del linguaggio di programmazione. Non sono un fan dei podlouches. E per me questo è il criterio decisivo. E lì a ciascuno il suo.
Bene, vedo che stanno iniziando ad aggiungere R, come TFlow e MXnet, prima era solo python.
Questo è probabilmente il motivo per cui il ponte per R è scritto in Pascal.
Che differenza fa in cosa è scritto?
Il ponte è stato scritto 10 anni fa, all'epoca veniva usato per insegnare la programmazione agli studenti. Poi Pascal morì improvvisamente.
Ma il vantaggio principale del ponte - la primitività, non richiede tempo per padroneggiare.
Ho anche aperto una filiale qui, agitato per scrivere qualcosa di più decente, anche formulato il ToR, ma nessuno lo vuole, quindi quello che abbiamo, abbiamo. Python non ha nemmeno questo.
OK, vedo che hanno iniziato ad aggiungere R, come TFlow e MXnet, prima era solo python
Ho scritto sul forum: non vedo alcun vantaggio nel sostituire un pacchetto con un altro. L'intero problema sono i predittori e la loro capacità predittiva per un particolare insegnante. Se questo problema viene risolto, allora al costo del pacchetto ci si può sbarazzare di qualche percentuale di errore, ma non vale la pena.