Aprendizaje automático en el trading: teoría, práctica, operaciones y más - página 203
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
OK, aceptado.
¿Y por qué dices: "...justo así..."? ¿Desde qué punto de vista es correcto? Vuelve a pincharme en Wolfram, donde el estadístico tío John escribió "0".
Te niegas obstinadamente a aceptar la realidad, escondiéndote detrás del "aceptado, gracias". Incluso te faltó señalar resultados similares en Matlab esta vez.
Así que vas contra el montón de MQL5 + Matlab + Wolfram + explicación, que demuestra la corrección de nuestras conclusiones, y defiendes el huérfano R autónomo con su error.
¿Sus propias ideas como experto en cuanto a por qué en el cero la densidad se define más apropiadamente como 0? ¿Y los ejemplos en los que definir la densidad como 1 o inf se convierte en un problema?
El infinito en el intervalo de integración puede provocar problemas de normalización. ¿Tiene ejemplos de distribuciones en las que la inf en la densidad no da problemas?
He reproducido el caso en el que vuelve el infinito.
La integral de la derecha en el punto cero para una función con los mismos parámetros cuenta como 1:
pgamma(0,0.5,1,log = FALSE,lower.tail = F)
Es decir, no hay problema para definirlo en todo el dominio (no hay problema con la incertidumbre en 0), lo que en la práctica significa que no hay problema. Tal vez usted está hablando de otra cosa, entonces por favor, aclare...
Y matlab u otra cosa, no me importa. Puedo dar ejemplos de los lenguajes de programación más populares donde 0^0 devolverá 1. Y...
Estás incurriendo en una marca religiosa, sin entender la diferencia entre los conceptos de "error" y "conveniencia". Lo que una parte (y muy significativa) de la comunidad matemática acepta como conveniente lo habéis tachado de erróneo. Eso es lo que hemos estado escribiendo todo el tiempo.
Gracias.
Nuestro enfoque: transferir sus desarrollos de R a MQL5 utilizando nuestras bibliotecas estándar.
Genial, sin ironía. Pero no es posible portar todas las funciones R personalizadas y las de nueva aparición que llevan los últimos logros matemáticos y algebraicos en diferentes áreas.
¿Dónde vas a frenar? ¿En qué momento dirías que el porteo está terminado?
He reproducido el caso en el que vuelve el infinito.
La integral de la derecha en el punto cero para una función con los mismos parámetros cuenta como 1:
pgamma(0,0.5,1,log = FALSE,lower.tail = F)
Es decir, no hay problema para definirlo en todo el dominio (no hay problema con la incertidumbre en 0), lo que en la práctica significa que no hay problema. Tal vez usted está hablando de otra cosa, entonces por favor, aclare...
No estoy seguro de que esta integral se cuente con los resultados de dgamma, ya que el infinito ha desaparecido en alguna parte. No podemos depurar este punto ya que todo ocurre dentro de R.
Necesitamos un código (en cualquier lenguaje) para calcular pgamma usando dgamma donde el infinito es devuelto a la traza en el momento en que el problema del infinito desaparece.
No estoy seguro de que esta integral se cuente con los resultados de dgamma, ya que el infinito ha desaparecido en alguna parte. No podemos depurar este punto ya que todo ocurre dentro de R.
Necesitamos un código (en cualquier lenguaje) para calcular pgamma usando dgamma donde el infinito es devuelto a la pista cuando el problema del infinito desaparece.
Sí, no estamos seguros de eso....
Pero, ¿cómo pretenden utilizar dgamma para integrarse en todo el soporte? Para eso está diseñado pgamma...
Te obstinas en no aceptar la realidad, escondiéndote detrás del "aceptado, gracias". Incluso te faltó señalar resultados similares en Matlab esta vez.
Así que vas contra un montón de MQL5 + Matlab + Wolfram + explicación que demuestra que nuestras conclusiones son correctas, y defiendes una R huérfana que se queda sola con su error.
Lamentablemente no, todas las explicaciones de Quantum son "porque así es en Wolfram". La función AS243 mencionada da un error de un decimal, no de 1, y no tiene nada que ver con el error de dgamma().
Explicación de Alexey - el resultado de la función dgamma en x=0 depende del resultado 0^0= ?
R devuelve 1 a esta pregunta. Wolfram no devuelve nada. Esa es la diferencia. Nadie sabe cuál es el camino correcto, es una operación indefinida. Así que es una tontería decir que 0^0 = 0 es la única solución correcta. Pero cuando se calcula en una situación así, el software tiene que devolver algo, así que los creadores de software matemático devuelven algunas constantes a voluntad. Que habrá 0, es una decisión personal de los programadores de wolfram, no la verdad final. Incluso podrían lanzar una moneda para elegir entre 0 y 1, y ahora alguien se refiere a ello.
Llamar a una función con un parámetro no válido y luego comparar los resultados con otros programas, para luego alegar que se han encontrado errores, no es muy académico. Su sexto punto del artículo en su forma actual es marketing, no matemáticas.
Así que pronto llegarás al punto de declarar que R multiplica infinitos incorrectamente, por ejemplo :)
Llamar a una función con un parámetro no válido, y luego comparar los resultados con otros programas, y luego afirmar que se han encontrado errores, de alguna manera no es académico. Su sexto punto del artículo en su forma actual es marketing, no matemáticas.
Lamentablemente no, todas las explicaciones de Quantum son "porque así es en Tungsteno". La función AS243 mencionada da un error en décimas de decimal, no en 1, y no tiene nada que ver con el error en dgamma().
Explicación de Alexey - el resultado de la función dgamma en x=0 depende del resultado 0^0= ?
R devuelve 1 a esta pregunta. Wolfram no devuelve nada. Esa es la diferencia. Nadie sabe cuál es el camino correcto, es una operación indefinida. Así que es una tontería decir que 0^0 = 0 es la única solución correcta. Pero cuando se calcula en una situación así, el software tiene que devolver algo, así que los creadores de software matemático devuelven algunas constantes a voluntad. Que habrá 0, es una decisión personal de los programadores de wolfram, no la verdad final. Incluso podrían lanzar una moneda para elegir entre 0 y 1, y ahora alguien se refiere a ello.
Llamar a una función con un parámetro no válido y luego comparar los resultados con otros programas, para luego alegar que se han encontrado errores, no es muy académico. Su sexto punto del artículo en su forma actual es marketing, no matemáticas.
Así que pronto llegarás al punto de afirmar que R multiplica infinitos incorrectamente, por ejemplo :)
Gracias.
Se me quitan las ganas de hablar con el estimado Renat aquí, porque ya me está marcando también, acusándome de algo que no existe. Hay un diálogo con Quantum, pero se niega obstinadamente a responder a la pregunta de por qué lo que hace es "correcto". Simplemente porque no hay un punto de vista correcto sobre el asunto. Y eso implicaría tener que cambiar la redacción del artículo.
Este no es el tono de una discusión científica. Esto es una denuncia en el foro.
Hemos dicho que la frase de error no es correcta, y resulta que la gente a la que se la han dicho ni siquiera puede entender de qué se trata. Y sugerirles que les tomen la palabra... Gracias, nos abstendremos.
Genial, sin ironía. Pero no es posible transferir todas las funciones R personalizadas y las que vuelven a surgir que llevan los últimos avances matemáticos y algebraicos en diversos campos.
¿Dónde vas a frenar? ¿Dónde dice que se acabó el porteo?
No las necesitamos todas, basta con un conjunto básico de funciones de esteras. Ninguno de nosotros va a perseguir módulos.
La gente escribirá las bibliotecas de destino para MQL5 por sí misma. Hemos creado un ecosistema y hemos conseguido unir a un gran número de comerciantes y desarrolladores. Nosotros también haremos el resto.