L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 203
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
OK, accettato.
E perché dice: "...proprio così..."? Da quali considerazioni è corretto? Punzecchiatemi ancora su Wolfram, dove lo zio John , statistico, ha scritto "0".
Vi rifiutate ostinatamente di accettare la realtà, nascondendovi dietro "accettato, grazie". Questa volta non hai nemmeno indicato risultati simili in Matlab.
Quindi, si va contro il gruppo di MQL5 + Matlab + Wolfram + spiegazione, che dimostra la correttezza delle nostre conclusioni, e si difende l'orfano stand-alone R con il suo errore.
I tuoi pensieri di esperto sul perché nello zero la densità è più appropriatamente definita come 0? Ed esempi quando definire la densità come 1 o inf diventa un problema?
L'infinito nell'intervallo di integrazione può portare a problemi di normalizzazione. Avete esempi di distribuzioni in cui l'inf nella densità non porta a problemi?
Ho riprodotto il caso in cui l'infinito ritorna.
L'integrale a destra al punto zero per una funzione con gli stessi parametri vale 1:
pgamma(0,0.5,1,log = FALSE,lower.tail = F)
Cioè, non c'è nessun problema a definirlo su tutto il dominio (nessun problema di incertezza a 0), che in pratica significa nessun problema. Forse stai parlando di qualcos'altro, allora per favore chiarisci...
E matlab o qualcos'altro, non ha importanza per me. Posso dare esempi dai linguaggi di programmazione più popolari dove 0^0 restituisce 1. E...
Stai facendo un branding religioso, non capendo la differenza tra i concetti di "errore" e "convenienza". Ciò che una parte (e molto significativa) della comunità matematica accetta come conveniente, voi lo avete bollato come errato. Questo è quello che abbiamo scritto per tutto il tempo.
Grazie.
Il nostro approccio - trasferite i vostri sviluppi da R a MQL5 usando le nostre librerie standard.
Figo, nessuna ironia. Ma non è possibile portare tutte le funzioni R personalizzate e quelle che appaiono di recente che portano le ultime conquiste matematiche e algebriche in diverse aree.
Dove andrai a rallentare? A che punto diresti che il porting è finito?
Ho riprodotto il caso in cui l'infinito ritorna.
L'integrale a destra al punto zero per una funzione con gli stessi parametri vale 1:
pgamma(0,0.5,1,log = FALSE,lower.tail = F)
Cioè, non c'è nessun problema a definirlo su tutto il dominio (nessun problema di incertezza a 0), che in pratica significa nessun problema. Forse stai parlando di qualcos'altro, allora per favore chiarisci...
Non sono sicuro che questo integrale sia contato usando i risultati di dgamma, poiché l'infinito è scomparso da qualche parte. Non possiamo fare il debug di questo punto perché tutto avviene all'interno di R.
Abbiamo bisogno di codice (in qualsiasi linguaggio) per calcolare pgamma usando dgamma dove l'infinito viene restituito per tracciare il momento in cui il problema dell'infinito scompare.
Non sono sicuro che questo integrale sia contato usando i risultati di dgamma, poiché l'infinito è scomparso da qualche parte. Non possiamo fare il debug di questo punto perché tutto avviene all'interno di R.
Abbiamo bisogno di codice (in qualsiasi linguaggio) per calcolare pgamma usando dgamma dove l'infinito viene restituito al binario quando il problema dell'infinito scompare.
Sì, non ne siamo sicuri....
Ma come intendete usare dgamma per integrare su tutto il supporto? Questo è ciò che pgamma è progettato per fare...
Lei si ostina a non voler accettare la realtà, nascondendosi dietro "accettato, grazie". Questa volta non hai nemmeno indicato risultati simili in Matlab.
Quindi stai andando contro un mucchio di MQL5 + Matlab + Wolfram + spiegazione che dimostra che le nostre conclusioni sono corrette, e difendendo un R orfano che sta in piedi da solo con il suo errore.
Purtroppo no, tutte le spiegazioni di Quantum sono "perché è così in Wolfram". La funzione Mentioned AS243 dà un errore di un posto decimale, non 1, e non ha niente a che fare con l'errore dgamma().
Spiegazione di Alexey - il risultato della funzione dgamma a x=0 dipende dal risultato 0^0= ?
R restituisce 1 a questa domanda, Wolfram non restituisce nulla. Questa è la differenza. Nessuno conosce il modo giusto, è un'operazione indefinita. Quindi è stupido dire che 0^0 = 0 è l'unica soluzione corretta. Ma quando si calcola in una tale situazione, il software deve restituire qualcosa, quindi i creatori di software matematici restituiscono alcune costanti a volontà. Che ci sarà 0, è una decisione personale dei programmatori di wolfram, non la verità finale. Potrebbero anche lanciare una moneta per scegliere tra 0 e 1, e ora qualcuno vi fa riferimento.
Chiamare una funzione con un parametro non valido e poi confrontare i risultati con altri programmi, e poi affermare di aver trovato degli errori, non è molto accademico. Il tuo sesto punto dell'articolo nella sua forma attuale è marketing, non matematica.
Così presto si arriverà al punto in cui si dichiara che R moltiplica gli infiniti in modo errato, per esempio :)
Chiamare una funzione con un parametro non valido, e poi confrontare i risultati con altri programmi, e poi sostenere di aver trovato degli errori, non è in qualche modo accademico. Il tuo sesto punto dell'articolo nella sua forma attuale è marketing, non matematica.
Purtroppo no, tutte le spiegazioni di Quantum sono "perché è così in Tungsten". La funzione AS243 menzionata dà un errore da qualche parte in decimi di decimale, non di 1, e non ha niente a che fare con l'errore in dgamma().
Spiegazione di Alexey - il risultato della funzione dgamma a x=0 dipende dal risultato 0^0= ?
R restituisce 1 a questa domanda, Wolfram non restituisce nulla. Questa è la differenza. Nessuno conosce il modo giusto, è un'operazione indefinita. Quindi è stupido dire che 0^0 = 0 è l'unica soluzione corretta. Ma quando si calcola in una tale situazione, il software deve restituire qualcosa, quindi i creatori di software matematici restituiscono alcune costanti a volontà. Che ci sarà 0, è una decisione personale dei programmatori di wolfram, non la verità finale. Potrebbero anche lanciare una moneta per scegliere tra 0 e 1, e ora qualcuno vi fa riferimento.
Chiamare una funzione con un parametro non valido e poi confrontare i risultati con altri programmi, e poi affermare di aver trovato degli errori, non è molto accademico. Il tuo sesto punto dell'articolo nella sua forma attuale è marketing, non matematica.
Così presto si arriverà al punto in cui si sosterrà che R moltiplica gli infiniti in modo errato, per esempio :)
Grazie.
Sto perdendo la voglia di parlare con lo stimato Renat qui, perché anche lui mi sta già bollando, accusandomi di qualcosa che non esiste. C'è un dialogo con Quantum, ma lui si rifiuta ostinatamente di rispondere alla domanda sul perché quello che sta facendo è "Giusto". Semplicemente perché non c'è un solo punto di vista giusto sulla questione. E questo comporterebbe la necessità di cambiare la formulazione dell'articolo.
Questo non è il tono di una discussione scientifica. Questa è la denuncia del forum.
Abbiamo detto che la frase di errore non è corretta, e si scopre che le persone a cui è stata detta non riescono nemmeno a capire di cosa si tratta. E suggerire loro di prendere per buona la loro parola... Grazie, ci asterremo.
Figo, nessuna ironia. Ma trasferire tutte le funzioni R personalizzate e quelle riemergenti che portano gli ultimi progressi matematici e algebrici in vari campi non è possibile.
Dove andrai a rallentare? Dove dite che il porting è finito?
Non abbiamo bisogno di tutti loro, un set di base di funzionalità mat è sufficiente. Nessuno di noi inseguirà i moduli.
Le persone scriveranno da sole le librerie di destinazione per MQL5. Abbiamo creato un ecosistema e siamo riusciti a unire un gran numero di commercianti e sviluppatori. Faremo anche il resto.