Un po' sorpreso :) Ho pensato di condividere e fare una domanda NON retorica. - pagina 21
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
È facile saltare da una dichiarazione fallita all'altra.
Quando avrete un processore con tipi di dati razionali e quando un altro set di comandi SSExxx potrà gestirli più velocemente del doppio, allora potrete portare i numeri razionali nella discussione sulla velocizzazione dei calcoli. Quando pubblicherete delle prove di calcolo della SMA con diversi metodi e mostrerete una vincita sul doppio, allora sarà un discorso di pratica.
Nel frattempo, l'affermazione originale sull'accelerazione dei calcoli matematici reali passando ai numeri interi è fallita.
Tu cosa?! Non ho saltato nulla. Se ne legge solo la metà. Ahimè. Ho detto delle frazioni razionali una ventina di volte. Ma finché non ho fatto notare che si tratta di frazioni, nessuno ha capito. :) Vi dico che è ridicolo. Ahimè. :(
:) Fallito - Stavo parlando di numeri interi e del concetto di PUNTO, e un punto è sempre il denominatore. 13000 punti se un punto equivale a 10000 - allora il valore è = 13000/10000 = 1,3 :)
Cosa stai facendo? Non ho saltato da nessuna parte. Se ne legge solo la metà. Mi dispiace. Ti ho già parlato venti volte delle cisterne razionali. Ma finché non ho fatto notare che si tratta di frazioni, nessuno ha capito. :) Vi dico che è ridicolo. Ahimè. :(
:) Fallito - Stavo parlando di numeri interi e del concetto di PUNTO, e un punto è sempre il denominatore. 13000 punti se un punto equivale a 10000 - allora il valore è = 13000/10000 = 1,3 :)
Tu proponi di elaborare tre lunghezze di 8 byte (parte intera + denominatore + numeratore) invece di un doppio di 8 byte. E se iniziate a tagliare i lunghi in qualcosa di più corto, otterrete un overflow in calcoli abbastanza adeguati.
Anche tre int e quelli sono più di una ripresa.
Tu proponi di elaborare tre lunghezze di 8 byte (parte intera + denominatore + numeratore) invece di un doppio di 8 byte. E se iniziate a tagliare i lunghi a qualcosa di più corto, otterrete un overflow in calcoli abbastanza adeguati.
Avete scelto il modo peggiore per implementarlo. Visto quello che mi hai detto, non ha senso. Chi di noi lo sa meglio?
C'è un numero in chilometri - è int32 E non ha bisogno di altro. Non è necessario sommarlo con un valore in un'altra dimensione. :) Se vuoi più precisione dei chilometri, vai ai nanometri. :) E memorizzarli come un numero intero. :)
TheXpert:
E in secondo luogo, dubito fortemente che l'aritmetica con il doppio sia più lenta che con i numeri razionali.
Wapchet rallenta. Ma ci ha fornito un link sbagliato.
1. L'implementazione in BOOST normalizza i numeri di razione ad ogni operazione con loro. Questo non deve essere fatto su tutti, perché è costoso. Meglio farlo solo quando c'è una reale minaccia di overflow del denominatore.
2. La riduzione a un denominatore comune (più precisamente, il calcolo del più grande divisore comune) non è fatto lì dall'algoritmo più veloce. Di gran lunga il più veloce.
Con la correzione, ha ragione sulla velocità dei numeri razionali.
Li avrei in mql, se le operazioni aritmetiche di ricarica fossero disponibili. Senza di esso la mia sintassi sarebbe molto noiosa (funzionale), quindi dimenticatelo... С++ :-)
--
Ma sarebbe davvero bello se ci fosse un supporto a livello di processore...
Wapchetta più lento. Solo che il link che ha dato era sbagliato.
1. L'implementazione in BOOST normalizza i numeri di razione ad ogni operazione su di essi. Non dovete farlo su tutti, perché è costoso. Meglio farlo solo quando c'è una reale minaccia di overflow del denominatore.
2. La riduzione a un denominatore comune (più precisamente, il calcolo del più grande divisore comune) non è fatto lì dall'algoritmo più veloce. Di gran lunga c'è un più veloce.
Detto questo, ha ragione sulla velocità dei numeri dei rapporti.
Li avrei in mql, se le operazioni aritmetiche di ricarica fossero disponibili. Ma senza di esso otterrei una sintassi molto noiosa (funzionale), quindi lasciate perdere... С++ :-)
--
Ma sarebbe davvero bello se ci fosse un supporto a livello di CPU...
L'aritmetica stessa è più lenta perché dobbiamo ancora gestire la virgola mobile (questo è se confrontiamo l'aritmetica pura del doppio e del lungo), se convertiamo i doppi in aritmetica intera perdiamo. Il solo calcolo NOD ricorrente richiederebbe log(N) operazioni, per non parlare del fatto che ogni operazione di moltiplicazione richiederebbe di controllare l'overflow. Poi altre 4 divisioni (due per NOD e per estrarre la parte intera e il resto frazionario).
Per di più, avreste ancora bisogno di allocare più memoria per immagazzinare tutte queste sciocchezze di quanta ne avreste bisogno per la presa.
Wapchet rallenta. Solo il link che ha citato è stato sfortunato.
Prove? Lei è certamente più autorevole ai miei occhi dello scrittore originale, ma è un'affermazione forte.
Perciò vorrei vedere dei test comparativi.
L'aritmetica stessa è più lenta perché deve ancora gestire la virgola mobile (questo se si confronta l'aritmetica pura doppia e lunga),
1. Se si convertono i doppi in aritmetica intera, si perde.
2. il solo calcolo del NOD ricorrente richiederebbe log(N) operazioni, per non parlare del fatto che
3. Ogni operazione di moltiplicazione richiederà se controllare l'overflow.
4. Poi altre 4 divisioni (due per NOD e per estrarre la parte intera e il resto frazionario).
5. In più, in cima a tutto questo, avrete ancora bisogno di allocare più memoria per immagazzinare tutte queste sciocchezze di quanta ne serva per la ripresa.
1. questa è un'operazione una tantum per ogni ripresa. La perdita è insignificante, poi i guadagni sono solidi. :) Suppongo che il quoziente originale sia logaritmato una volta e convertito in rappresentazione intera.
2. questo è corretto. Anche se è veloce, perché c'è un algoritmo veloce che usa gli spostamenti di bit.
3. non più di controlli di overflow.
4. la parte intera non ha bisogno di essere allocata. la frazione è memorizzata come una coppia di longs e, se possibile, come una coppia di ints.
5. Esattamente la stessa quantità se memorizzata come coppia di longs, e la metà nel caso in cui ci siano abbastanza ints (dipende dai requisiti dell'algoritmo).
Se consideriamo che il principale consumatore di memoria è una citazione, allora con la rappresentazione intera il guadagno di spazio è innegabile.
Mentre il punto principale non è nel risparmio di memoria, ma nell'accelerazione. Questo è molto più importante.
--
Il problema di Academician non è che ha torto. È che sta facendo sembrare gli altri sbagliati.
È questo che irrita i presenti e rifiuta le idee sane... Insieme all'acqua sporca... :(
Pertanto, vorrei vedere dei test comparativi.
Farò un tentativo. Su mql5, se si arriva a questo... :)
Ho solo bisogno di tempo. Dovrei scrivere una biblioteca.
Farò un tentativo. In mql5, se si arriva a questo... :)
Per quale motivo? C++ è accettato.
Il problema dell'accademico non è che ha torto. È che sta facendo sembrare gli altri sbagliati.
Il problema è che pensa di essere più intelligente degli altri e cerca costantemente di prendere in giro gli altri.
E lui sbaglia. In alcuni posti, molto.
Il problema dell'accademico non è che ha torto. È che fa sembrare gli altri sbagliati.
Questo è ciò che irrita i presenti e rifiuta le idee sane... Insieme all'acqua sporca... :(
Non entro nella testa di nessuno. Ma io sono invertito. :) Chi ha chiesto consigli su "devo seguire il tema?". :)
E poi sono io quello che è quello che è... :) Beh, non venire da me.
Qual è la differenza in generale, cosa c'è da discutere? IMHO - tutto rimane allo stesso livello embrionale di prima. Quindi non c'è nessun problema con me - è come se non esistessi. :)