L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 2367

[Aleksey Vyazmikin]

mytarmailS:

Lungo sospiro... dimenticato, stanco)

384 GB DI RAM?

Non ho bisogno di così tanto - ne vale la pena 64.

[mytarmailS]

Aleksey Vyazmikin:

Non ho bisogno di così tanto - costa 64.

Ok, beh, vediamo, sto ancora sistemando il codice da solo, come fare al meglio ciò che può essere ottimizzato, penso, sto provando delle opzioni, non voglio disturbarti per niente anche io, terrò presente koroch...

[mytarmailS]

Aleksey Nikolayev:

Alcune cose che ti piacciono molto dopo sembrano brutte all'inizio - caffè, caviale, wasabi, musica rock, ecc.)

è vero, anch'io non capivo alcune delle strutture di p-ka all'inizio, pensavo fosse una sciocchezza

Ho anche pasticciato con alcune strutture in p-ka all'inizio, pensavo che fosse un'assurdità, per esempio usavo i loop per scrivere tutto e non capivo la famiglia "apply", ma poi ho scoperto che potevo vincere in leggibilità e velocità e potevo scrivere 6 righe di codice e fare una riga di codice

[Vladimir Perervenko]

mytarmailS:

Anche io non capivo alcune strutture in p-ka all'inizio, pensavo fosse una sciocchezza.

Scrivevo tutto in un ciclo e non capivo la famiglia "apply", ma in seguito ho scoperto che potevo ottenere più leggibilità e velocità e potevo scrivere 6 righe di codice e fare una

Non solo applicare. Uso spesso foreach perché può essere parallelizzato senza alterare il codice... A volte l'iteratore è utile, provalo

library(coro)
abc <- generate_abc()
loop(for (x in abc) print(x))

Buona fortuna

[mytarmailS]

Vladimir Perervenko:

Non solo applicare. Io uso più spesso foreach, puoi parallelizzarlo senza rifare il codice... A volte l'iteratore è utile, provalo

Buona fortuna

Grazie!

[mytarmailS]

mytarmailS:

Grazie!

Cos'è generate_abc? Non ho ancora capito perché l'esempio dà un errore

library(coro)
> abc <- generate_abc()
Error in generate_abc() : could not find function "generate_abc"

[Maxim Dmitrievsky]

Tutte queste operazioni sono in python

print([x for x in range(50)])

[Aleksey Nikolayev]

Tutto questo è iniziato in lisp ed è particolarmente sviluppato nella programmazione funzionale, elementi della quale si trovano sia in R che in Python.

[Vladimir Perervenko]

Mi è capitato di leggere un articolo con un'affermazione che mi ha sorpreso:Predittori, risposte e residui: cosa deve essere veramente distribuito normalmente?

Alcune citazioni:

"Molti scienziati sono preoccupati per la normalità o la non normalità delle variabili nell'analisi statistica. Le seguenti e simili opinioni sono spesso espresse, pubblicate o insegnate:

• " Se si vuole fare statistica, allora tutto deve essere distribuito normalmente .
• "Abbiamo normalizzato i nostri dati per adattarli all'ipotesi di normalità .
• " Abbiamo convertito i nostri dati in un log perché avevano una distribuzione molto asimmetrica" .
• "Dopo aver montato il modello, abbiamo testato l'omoscedasticità dei residui .
• " Abbiamo usato un test non parametrico perché i nostri dati non si adattavano all'ipotesi di normalità" .

E così via. So che è più complicato di così, ma sembra ancora che la distribuzione normale sia ciò che la gente vuole vedere ovunque, e che la distribuzione normale delle cose apre la porta a statistiche pulite e convincenti e a risultati forti. Molte persone che conosco controllano regolarmente se i loro dati sono distribuiti normalmente prima dell'analisi, e poi cercano di "normalizzarli", per esempio usando una trasformazione logaritmica, o regolano il metodo statistico di conseguenza in base alla distribuzione di frequenza dei loro dati. Qui esploro questo più da vicino e mostro che ci possono essere meno presupposti sulla normalità di quanto si possa pensare".

Ulteriore giustificazione del pensiero e della conclusione:

" Perché la gente continua a normalizzare i dati?

Un altro problema sconcertante è perché le persone tendono ancora a "normalizzare" le loro variabili (sia i predittori che le risposte) prima di applicare un modello. Perché questa pratica è emersa e si è diffusa, anche se non ci sono presupposti per innescarla? Ho diverse teorie su questo: ignoranza, tendenza a seguire ricettari statistici, propagazione degli errori, ecc. D.
Due spiegazioni sembrano più plausibili: in primo luogo, le persone normalizzano i dati per linearizzare le relazioni. Per esempio, una trasformazione logaritmica del predittore può essere usata per adattare una funzione esponenziale usando il solito meccanismo dei minimi quadrati. Questo può sembrare normale, ma allora perché non specificare la relazione non lineare direttamente nel modello (per esempio usando una funzione di riferimento appropriata)? Inoltre, la pratica della trasformazione logaritmica della risposta può portare a gravi artefatti, ad esempio nel caso di dati di conteggio con zero conteggi (O'Hara & Kotze 2010).
Una seconda ragione plausibile per "normalizzare" la pratica è stata suggerita dalla mia collega Catherine Mertes-Schwartz: questo può essere perché i ricercatori stanno cercando di risolvere un problema e i loro dati sono stati raccolti in modo molto scaltro e irregolare. In altre parole, molto spesso si lavora con dati che hanno un gran numero di osservazioni aggregate in una certa parte del gradiente, mentre l'altra parte del gradiente è relativamente sottorappresentata. Questo porta a distribuzioni distorte. Trasformando tali distribuzioni si ottiene una distribuzione apparentemente regolare delle osservazioni lungo il gradiente e l'eliminazione degli outlier. Questo può essere fatto in buona fede. Tuttavia, anche questo è fondamentalmente sbagliato".

Per me questa affermazione è (scioccante?), non riesco a trovare la parola giusta. Ma lo terrò presente in futuro.

[Vladimir Perervenko]

Maxim Dmitrievsky:

Tutte queste operazioni sono in python.

Non si tratta di stampa, ma di generatori e iteratori.