Proyecto EA

[baltic46]

Y cual es el enlace a la web?
Saludos

[Wikmar]

Esperamos el enlace y saber una serie de cosas, como si se puede ver el código fuente de la macro y de todo lo que se pretende ejecutar en nuestras máquinas.

En unos días pondremos resultados auditados del EA e iremos siguiendo la evolución en directo y ver su evolución conforme se alimenta de nuevas Lecciones.

Si por "auditados" queréis decir "garantizados de autenticidad", es un tema ampliamente debatido en el foro en diversos hilos.

Os ruego leáis por lo menos un par de cosas, y si no se superan los criterios, prescindáis de ese o esos términos o conceptos.

viewtopic.php?f=14&t=17403&p=197823#p197823
(criterios 2º y 3º)

viewtopic.php?f=6&t=17533#p196872

Muchas gracias y mis mejores deseos para el proyecto.

[SpeakerTrading]

Hola HugoMZ

Desconozco la elección de Excel como lenguaje de programación pero para un proyecto así pienso que es de las peores elecciones que se pueden hacer.

Un proyecto con esos requisitos de computación tendría que realizarse en lenguajes de más bajo nivel, como C/C++. La mejora de rendimiento es de varios factores seguro. Si estáis usando Excel, casi pongo la mano en el fuego que la programación no se hace con varios hilos ¿me equivoco? Si es así, en equipos con 4 y 8 núcleos (lo normal hoy en día) podríais multiplicar por 4 u 8 la velocidad de procesamiento. Si con C++ mejoras en un factor de 2 o 3, hablamos de una mejora global entre 8 y 24 veces más rápido.

Es para pensárselo. Si podéis, haced algunas pruebas. No todo tiene que estar en C pero si lo que se refiera a cálculos que hagan uso intensivo de CPU. Los reportes, interfaz de usuario... da igual con que lenguaje se hagan. Os ahorrareis mucho trabajo y tiempo.

Un saludo

[X-Trader]

Parece ser que es spam porque lo ha puesto por varios foros, en unas horas lo borraré (salvo que alguien quiera que
lo deje ).

Saludos,
X-Trader

[agmageton]

Bueno a mi me interesa lo que dice el gran Speaker, sobre Excel, yo tengo las cosas en Excel y mutando a sistemas expertos, y Excel si trabaja con los 8 nucleos y si es de 64bits hasta con 8gb de memoria, yo este ejemplo lo tengo con 32 bits que va como máximo a 4 gb de memoria, el problema es del Excel que hace culo de botella y no trabaja con el máximo de la computadora, aunque sea la mas rápida del mundo....en cambio con programación supongo que no habrá culo de botella.

[X-Trader]

OK, entonces lo dejo que puede abrir un debate interesante sobre lenguajes de programación y el uso de Excel en el trading

Saludos,
X-Trader

PD: Vi tu respuesta en el otro hilo y ya conocía esos indicadores de volatilidad que manejas pero... no es posible predecir a priori el cambio, solo cuando ya estás en harina lo detectas . A ver, que nadie tiene un modelo para predecir la volatilidad, si así fuera alguien sería muy rico .

[agmageton]

Alberto se trata de gestionar lo más rápido posible un cambio, claro que no vas a anticiparte, nadie tiene la bola de cristal, pero de darte cuenta en 1 mes a 1 semana cambia mucho...incluso hay elementos que hacen que puedas adelantarte, pero estos tienen un nivel de confianza no muy superior al 50%.

[agmageton]

El problema de esto que digo, es que los sistemas de volatilidad normales que hay por el mercado, que te dicen cuando hay volatilidad o cuando la volatilidad va en aumento son lentos, en el 2008 cuando se activa la alarma de cualquier oscilador de volatilidad ya te has comido una bajada del 15% sin pestañear, y es debido a la velocidad que tuvo en relación a la lentitud de estos indicadores, además el año 2008 tiene miga, porque tras una sacudida del 20% luego baja la volatilidad de 0,15% a 0,05% para que luego vuelva a bajar a una velocidad bestial y situarse en un 0,32% (tendríamos que irnos al año 1929 en el dow o recientemente al año 1997-1998 o al año 2000 1º trimestre para ver esas velocidades...). y eso en tiempo record los osciladores que son lentos cuando detectan esto ya te has comido la bajada...por eso en el 2008 petaron tantos sistemas hedges fund, fondos y mesas de institucionales...

[SpeakerTrading]

Hola agmageton

Mi respuesta ha sigo algo generalista pues lo normal es que quien usa Excel como plataforma de desarrollo tenga escasos conocimientos de programación. Con Excel se pueden hacer muchas cosas pero si buscas rendimiento sobre otras opciones (digamos interoperabilidad, tiempo de desarrollo, mantenimiento...) Excel no es el candidato a elegir.

Busca "Programación con la API de C en Excel" en Google (el enlace tiene paréntesis y el foro no lo coge bien) y el enlace de la página de Microsoft muestra distintas formas de programar con Excel.

Las funciones importantes (SUM...) están programadas en C porque hacerlas en VBA haría que muchas de las hojas actuales fuesen lentísimas, el rendimiento de Excel se degradaría en exceso. Programar con la API de C para Excel es un pequeño infierno pero supongo que hecha una, hechas todas.

Un proyecto cuyo núcleo es computar, computar y computar no tiene sentido desarrollarlo con lenguajes de alto nivel y menos con un lenguaje interpretado embebido en otra aplicación, como es el caso del VBA de Excel. Se pierde mucho rendimiento y eso al final es tiempo.

Yo he hecho sistemas y los he probado en backtesting con históricos grandes. Lo he hecho en C# (algo más lento que C++ pero más rápido el desarrollo y el mantenimiento) y si lo pongo sobre los 4 procesadores del equipo lo exprime a tope, no puedo hacer nada. Abrir un explorador de archivos tarda un buen rato porque la CPU está al 100%.

Bien hecho, desde mi punto de vista, seria así:
- Las partes críticas, la computación intensiva, desarrolladas al más bajo nivel. C/C++ seria lo ideal. Si esto supone mucho costo de desarrollo, C#, Java o similar.
- Estas partes programadas de forma que puedan usar desde 1 a todos los procesadores del equipo.
- Si se dispone de varios equipos, programación distribuida.
- La interfaz, en lenguajes de alto nivel. Ya sea una aplicación de .NET, Java o generar los resultados creando un archivo Excel automáticamente.

A mi personalmente me gusta mucho ver los resultados en Excel y lo que hago es preparar una plantilla Excel con los cálculos, colores y gráficos que me interesan. Mi aplicación genera un txt con los resultados de los cálculos y esos resultados se importan en Excel para estudiar los datos obtenidos.

[agmageton]

Seguro que llevas toda la razón, pero el problema es no tener conocimientos grandes de programación, y yo que el año pasado me puse una ingeniera informatica a mi lado para programarlos c# al final fue un fracaso, me di cuenta a los 6 meses que esto no avanzaba quizás elegi mal a la informática pero teníamos muchos problemas, por lo que he decido empezar a aprender el lenguaje easy lenguag e para la plataforma multichart y poco a poco irlo migrando todo.

saludos.

[SpeakerTrading]

Bueno, este tipo de programación es exigente en lo que a conocimientos se refiere a lo que tienes que sumarle que tú trabajas con conceptos que no conoce la gente de a pie y mucha, mucha matemática. Lo normal es que saliese mal. Lo raro seria encontrarla a la primera.

Suerte con el Easy Lenguage!

[oni]

.

[Optiondreamer]

Parece ser que es spam porque lo ha puesto por varios foros, en unas horas lo borraré (salvo que alguien quiera que
lo deje ).

Saludos,
X-Trader

A mi me lo parecía, no es normal hacer un proyecto así con Excel... cuando para hacer lo mismo de forma mucho más potente tienes python, que viene más que preparado para hacer todo tipo de cálculos, y en cuanto a potencia de procesamiento, hay tests por ahí que incluso superan a c/c++...
Os pongo un ejemplo de un referente conocido por estos lares...

http://arxiv.org/abs/1408.1159

Código: Seleccionar todo

#!/usr/bin/env python
# Profit-taking and stop-loss simulations
# On 20131003 by MLdP <[email protected]> 
import numpy as np
from random import gauss
from itertools import product
#----------------------------------------------------------------------------------------
def main():
    rPT=rSLm=np.linspace(0,10,21)
    count=0
    for prod_ in product([10,5,0,-5,-10],[5,10,25,50,100]):
        count+=1
        coeffs={'forecast':prod_[0],'hl':prod_[1],'sigma':1}
        output=batch(coeffs,nIter=1e5,maxHP=100,rPT=rPT,rSLm=rSLm)
    return output
#----------------------------------------------------------------------------------------
def batch(coeffs,nIter=1e5,maxHP=100,rPT=np.linspace(0,10,21), \
    rSLm=np.linspace(0,10,21),seed=0):
    phi,output1=2**(-1./coeffs['hl']),[]
    for comb_ in product(rPT,rSLm):
        output2=[]
        for iter_ in range(int(nIter)):
            p,hp,count=seed,0,0
            while True:
                p=(1-phi)*coeffs['forecast']+phi*p+coeffs['sigma']*gauss(0,1)
                cP=p-seed;hp+=1
                if cP>comb_[0] or cP<-comb_[1] or hp>maxHP:
                    output2.append(cP)
                    break
        mean,std=np.mean(output2),np.std(output2)
        print comb_[0],comb_[1],mean,std,mean/std
        output1.append((comb_[0],comb_[1],mean,std,mean/std))
    return output1

S2

[SpeakerTrading]

Hola Optiondreamer

Phyton es imposible que sea más rápido que C/C++. Es un lenguaje de alto nivel y, además, interpretado, como Java o C#.

http://www.google.com/search?hl=en&q=ph ... ce&spell=1

Eso si, tiene las ventajas propias de un lenguaje de alto nivel: desarrollo más rápido, mantenimiento menos costoso, etc.

Por eso es tan importante seleccionar el lenguaje en función de lo que vas a desarrollar. Hay partes críticas de los sistemas operativos que están codificadas en ensamblador, también muchos drivers usan ensamblador en sus desarrollos. Al final, si quieres rendimiento tienes que ir a lenguajes de bajo nivel aunque vaya en detrimento del coste y tiempo del desarrollo.

[agmageton]

Una curiosidad, los sistemas en HFT alta frecuencia en que lenguaje están hechos, alguien lo sabe?

vale ya me contesto, Alberto puso un articulo sobre esto...

https://www.x-trader.net/articulos/soft ... a-hft.html