Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 2367

[Aleksey Vyazmikin]

mytarmailS:

Suspiro longo... esquecido, cansado)

384 GB RAM ??

Não preciso assim tanto - 64 vale a pena.

[mytarmailS]

Aleksey Vyazmikin:

Eu não preciso de tanto - custa 64.

Ok, bem, vejamos, ainda estou a organizar o código sozinho, como melhor fazer o que pode ser optimizado, acho, estou a experimentar opções, não quero incomodar-te por nada também, vou ter em mente o Koroch...

[mytarmailS]

Aleksey Nikolayev:

Algumas coisas que você gosta muito depois parecem desagradáveis no início - café, caviar, wasabi, música rock, etc.)

Isso é verdade, eu também não entendi algumas das estruturas do p-ka no início, achei que era um disparate

Também estava a mexer com algumas estruturas em p-ka no início, pensei que era um disparate, por exemplo usei loops para escrever tudo e não percebi "aplicar" a família, mas acabou por se revelar mais tarde que podia ganhar em legibilidade e velocidade e podia escrever 6 linhas de código e fazer uma linha de código

[Vladimir Perervenko]

mytarmailS:

Também não entendi algumas das estruturas do p-ka no início, achei que era um disparate.

Eu costumava escrever tudo em loop e não entendia a família "aplicar", mas depois consegui ler e acelerar mais, e pude escrever 6 linhas de código e fazer uma

Não só se aplica. Costumo usar a foreach porque pode ser paralela sem alterar o código... Às vezes o iterador é útil, experimente-o.

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

Boa sorte.

[mytarmailS]

Vladimir Perervenko:

Não só se aplica. Eu uso a Foreach mais vezes, você pode fazer o paralelo sem refazer o código... Às vezes o iterador é útil, experimente-o.

Boa sorte.

Obrigado!

[mytarmailS]

mytarmailS:

Obrigado!

O que é o generate_abc ? Ainda não entendo porque o exemplo dá um erro

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

[Maxim Dmitrievsky]

Todas estas operações estão em python.

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

[Aleksey Nikolayev]

Tudo isto começou em lisp e está particularmente desenvolvido na programação funcional, cujos elementos se encontram tanto em R como em Python.

[Vladimir Perervenko]

Por acaso li um artigo com uma declaração que me surpreendeu:Preditores, respostas e resíduos: O que realmente precisa ser distribuído normalmente?

Algumas citações:

"Muitos cientistas estão preocupados com a normalidade ou não normalidade das variáveis na análise estatística. Os pontos de vista seguintes e similares são frequentemente expressos, publicados ou ensinados:

• " Se você quer fazer estatísticas, então tudo tem que ser normalmente distribuído .
• "Normalizámos os nossos dados para se adequarem à suposição de normalidade .
• " Convertemos os nossos dados para um registo, pois tinha uma distribuição altamente enviesada" .
• "Depois de termos instalado o modelo, testamos a homocedasticidade dos resíduos .
• " Utilizámos um teste não paramétrico porque os nossos dados não correspondiam à suposição de normalidade" .

E assim por diante. Sei que é mais complicado do que isso, mas ainda assim parece que a distribuição normal é o que as pessoas querem ver em toda parte, e que a distribuição normal das coisas abre a porta para estatísticas limpas e convincentes e resultados fortes. Muitas pessoas que conheço verificam regularmente se os seus dados são normalmente distribuídos antes da análise, e depois ou tentam "normalizá-los", por exemplo usando uma transformação logarítmica, ou ajustam o método estatístico de acordo com a distribuição de frequência dos seus dados. Aqui eu exploro isso mais de perto e mostro que pode haver menos suposições sobre a normalidade do que se poderia pensar".

Mais uma justificação para o pensamento e a conclusão:

" Porque é que as pessoas ainda normalizam os dados?

Outro problema intrigante é porque as pessoas ainda tendem a "normalizar" suas variáveis (tanto os preditores como as respostas) antes de encaixar um modelo. Por que esta prática surgiu e se tornou prevalecente, mesmo que não haja suposições que a causem? Tenho várias teorias sobre isso: ignorância, tendência a seguir livros de receitas estatísticas, propagação de erros, etc. D.
Duas explicações parecem mais plausíveis: em primeiro lugar, as pessoas normalizam os dados para linearizar as relações. Por exemplo, uma transformação de previsão logarítmica pode ser usada para encaixar uma função exponencial usando o mecanismo habitual dos mínimos quadrados. Isto pode parecer normal, mas então porque não especificar a relação não-linear directamente no modelo (por exemplo, usando uma função de referência apropriada)? Além disso, a prática da transformação da resposta logarítmica pode levar a artefatos sérios, por exemplo, no caso da contagem de dados com contagem zero (O'Hara & Kotze 2010).
Uma segunda razão plausível para "normalizar" a prática foi sugerida pela minha colega Catherine Mertes-Schwartz: isto pode ser porque os investigadores estão a tentar resolver um problema e os seus dados têm sido recolhidos de forma muito manhosa e desigual. Em outras palavras, muitas vezes se trabalha com dados que têm um grande número de observações agregadas em uma determinada parte do gradiente, enquanto a outra parte do gradiente está relativamente sub-representada. Isto leva a distribuições distorcidas. A transformação de tais distribuições leva a uma distribuição aparentemente regular das observações ao longo do gradiente e à eliminação dos outliers. Isto pode, de facto, ser feito de boa fé. No entanto, isto também é fundamentalmente errado".

Para mim esta afirmação é (chocante?) , não consigo encontrar a palavra certa para ela. Mas vou ter isso em mente no futuro.

[Vladimir Perervenko]

Maxim Dmitrievsky:

Todas estas operações são em píton.

Não se trata de impressão, mas sim de geradores e iteradores.