Errori, bug, domande - pagina 2637
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
forse rispetto alla programmazione funzionale?
Controlla la wikipedia:
E scopriamo che non è la stessa cosa.
Quindi è tutto procedurale...
Forse vi sorprenderà, ma i giovani programmatori di oggi considerano l'OOP una programmazione più facile della programmazione procedurale.
State pensando in termini di 25 anni fa. I giovani d'oggi assorbono l'OOP con il latte della madre. Imparate l'OOP se volete essere alla moda, altrimenti non farete altro che brontolare.
Ma è davvero così. Lasciate che i vecchi programmatori provino a risolvere i compiti delle Olimpiadi per gli scolari.
Quello che hanno studiato prima nelle università, materie come programmazione dinamica, teoria dei grafi, OOP, classi ecc. Gli attuali scolari di 9-10 classi (non tutti ovviamente) risolvono tali problemi in pochi minuti.
Ed è naturale. Legge di natura :)
Sì, capisco l'OOP, non nella misura in cui mi piacerebbe, naturalmente.
Questo non è un brontolio ma un suggerimento costruttivo.
Affinché lo sviluppatore non debba scrivere una funzione per allocare due malloc, costringono gli utenti a imparare l'OOP.
Naturalmente, è che il progresso e la divulgazione della lingua. Bene, qui potete vedere quanto amano e capiscono l'OOP.
Vedi, Nikolay, tutto nel wrapper è codice inutile da eseguire, non credo ci sia bisogno di spiegarlo.
Non ho bisogno di parlarvi dei moderni compilatori di ottimizzazione - non sappiamo quali istruzioni applicheranno.
Forse vi sorprenderà anche il fatto che anche i programmatori americani preferiscono scrivere in stile procedurale non perché l'OOP è male, ma perché il codice è più semplice e veloce.
E se non ci sono problemi di oggetti nel progetto, perché usare i wrapper, che devono essere in qualche modo compresi, per i giovani))
Per questo non sono d'accordo con te che i giovani assorbono avidamente l'OOP.
Sto pensando in C, che è dove è costruita la logica del linguaggio mql.
C è nato nel 1972, quindi ha 48 anni ))
Ma comunque, C è uno dei linguaggi più veloci. Sapete perché? Perché non ha wrapper di classe.
Beh, questo non è affatto vero. È solo che ci sono ancora molti linguaggi in uso senza OOP. C, per esempio. In Canada, per esempio, la maggior parte delle istituzioni governative sono sedute su Kobol e non possono liberarsene.
https://www.tiobe.com/tiobe-index/
Roman, onestamente non capisco perché stai facendo storie per cambiare le dimensioni della matrice - quali difficoltà ci possono essere con questo.
Non hai bisogno di puntatori o di OOP per questo.
Comunque, per un computer, un array di qualsiasi dimensione è un array unidimensionale.
Quindi, lavorate con un array dinamico unidimensionale. E formare matrici virtualmente e ridimensionarle a piacere con l'aiuto di funzioni.
Per esempio qualcosa come:
In pratica io stesso uso solo array monodimensionali nel codice, anche se mi occupo di array multidimensionali sulla base di questi monodimensionali.
Ecco perché vorrei chiedervi di fare funzioni come ArrayResize solo per matrici ArrayResizeMx(A, n, m)
tutto fatto, non voglio soluzioni pronte all'uso usando OOP (non è richiesto che tu conosca OOP, usa le soluzioni pronte all'uso!)
usate ALGLIB, c'è un metodo per ridimensionare la matrice Resize().... ma ancora tutto è fatto da OOP ))))
SZS: cerca nel forum, ci sono state molte volte su questo argomento, c'erano esempi, puoi avvolgere una struttura con un campo array in un array di queste strutture - sarà senza OOP, ma a me sembra tutto macchinoso
Sto pensando in C, che è la base della logica mql.
Il linguaggio C è nato nel 1972, quindi risulta che ha 48 anni ))
Ma comunque, C è uno dei linguaggi più veloci. Sapete perché? Perché non ha wrapper di classe.
Non ricordo il C puro, l'ho studiato all'università molto tempo fa, ma se non mi sbaglio, il C non aveva gli array dinamici come tali, ma si poteva lavorare con i puntatori alla memoria, e il lavoro sull'allocazione della memoria e il controllo dell'accesso alla memoria era completamente sul programmatore, che è essenzialmente lo stesso involucro
Ok, questa potrebbe essere una grande discussione, non ha senso continuare.
Roman, onestamente non capisco perché hai fatto storie per cambiare le dimensioni della matrice - quali difficoltà ci possono essere con questo.
Non hai bisogno di puntatori o di OOP per questo.
Comunque, per un computer, un array di qualsiasi dimensione è un array unidimensionale.
Quindi, lavorate con un array dinamico unidimensionale. Nel frattempo, formate virtualmente le matrici e ridimensionatele come volete usando le funzioni.
È chiaro che qualsiasi dimensione è un array unidimensionale per il computer.
Se vediamo la dimensione [][] nel codice, possiamo capire visivamente che si tratta di una matrice, non di un array unidimensionale.
La leggibilità del codice è molto più alta che indovinare cosa contiene [][].
Non avrei mai pensato che avrei incontrato una tale mancanza di comprensione quando mi è stato chiesto di aggiungere una funzione sull'allocazione della memoria per le matrici.
Tutti voi state usando ArrayResize, è comodo e non vi preoccupate. Qual è il problema per uno sviluppatore di scrivere una funzione di allocazione della memoria perun array multidimensionale?
Esatto, non ci sono problemi e ostacoli, e per gli utenti è comodo organizzare il loro codice. Così ho deciso di portare una grande e buona libreria C di metodi numerici a mql,
ma non ho strumenti mql normali per questo. Ancora una volta ci sono stampelle, il che toglie ogni desiderio di costruire codice inefficiente.
Capisco l'OOP, non quanto vorrei, ovviamente.
Questo non è un brontolio ma un suggerimento costruttivo.
Affinché lo sviluppatore non debba scrivere una funzione per allocare due malloc, costringono gli utenti a imparare l'OOP.
Naturalmente, è che il progresso e la divulgazione della lingua. Bene, qui potete vedere quanto amano e capiscono l'OOP.
Vedi, Nikolay, tutto nel wrapper è codice inutile da eseguire, non credo ci sia bisogno di spiegarlo.
Non ho bisogno di parlarvi dei moderni compilatori di ottimizzazione - non sappiamo quali istruzioni applicheranno.
Forse vi sorprenderà anche il fatto che anche i programmatori americani preferiscono scrivere in stile procedurale non perché l'OOP è male, ma perché il codice è più semplice e veloce.
E se non ci sono problemi di oggetti nel progetto, perché usare i wrapper, che devono essere in qualche modo compresi, per i giovani))
Per questo non sono d'accordo con te che i giovani assorbono avidamente l'OOP.
Sto pensando in C, che è dove è costruita la logica del linguaggio mql.
C è nato nel 1972, quindi ha 48 anni ))
Ma comunque, C è uno dei linguaggi più veloci. Sapete perché? Perché non ha wrapper di classe.
MQL è costruito in C++.
Roman, per introdurre queste caratteristiche che menzioni, MQL dovrà introdurre molte cose aggiuntive in termini di lavoro con la memoria. E questa è una complicazione per i principianti.
Lei stesso ha detto che deve essere più facile per i non professionisti.
È una situazione del tipo "Sono bravo a imparare a pedalare in bicicletta, è così semplice e comprensibile". Mettiamo i pedali nella BMW, sarà più facile". :)
Cioè sono generalmente dell'opinione che sia lo stile procedurale che quello OOP siano sfigati e poco pratici))
tutto fatto, non voglio soluzioni pronte all'uso usando OOP (non è richiesto che tu conosca OOP, usa le soluzioni pronte all'uso!)
usate ALGLIB, c'è un metodo per ridimensionare la matrice Resize().... ma comunque è tutto fatto con OOP ))))
SZS: cerca nel forum, ci sono state molte volte su questo argomento, c'erano esempi, puoi avvolgere una struttura con un campo array in un array di queste strutture - sarà senza OOP, ma a me sembra tutto macchinoso
Il problema è che in C non ti ricordi il C puro, l'hai studiato all'università, ma se non mi sbaglio, non c'erano array dinamici, ma si poteva lavorare con puntatori alla memoria, e il lavoro di allocare la memoria e controllare l'accesso alla memoria era lasciato interamente al programmatore, sarebbe lo stesso wrapper
OK, questo potrebbe diventare un grande argomento e non ha senso continuare
Provato ALGLIB, c'è un problema con la stampa da oggetto, la funzione ArrayPrint non stampa gli oggetti.
Ma da [][] stampa una bella matrice, anche con intestazioni, di nuovo, è facile da vedere quando hai bisogno di tracciare visivamente il risultato del calcolo.
Sì, ho guardato alcuni argomenti sul forum, ma non sono impressionato. Ecco perché tutto sembra macchinoso e inefficiente. C è un linguaggio molto elegante e mql tende a corromperlo.
Sì, C può allocare la memoria per le matrici dinamiche attraverso i puntatori, ma in mql non ci sono puntatori alle variabili, quindi di nuovo dobbiamo passare agli oggetti.
Quando gli utenti hanno bisogno di una sola funzione ArrayResizeMx(A, n, m, k) e sarà nell'implementazione nativa, si capisce la differenza.
Beh, non ha senso continuare, se ne hanno sentito parlare e lo faranno, grazie mille. Ma la funzione è davvero utile e necessaria.
Speculazione ad alta voce, ma è più un appello allo sviluppatore.
Per questo Zloy, non prenderla sul personale.
Quindi, le matrici dinamiche possono essere gestite solo attraverso oggetti o strutture. Un'altra stampella è creata in generale.
Non ci sono puntatori alle variabili in mql, quindi dobbiamo usare l'approccio a oggetti dove i puntatori sono disponibili.
Quindi, per utilizzare le matrici dinamiche, un utente deve conoscere OOP e lavorare con i puntatori, e inoltre, nell'esecuzione MQL.
Quanti di loro hanno questa conoscenza? Tu stesso conosci la risposta. Non ho difficoltà a capire l'approccio a oggetti, ma per coloro che non conoscono OOP
Creano una soglia artificiale per l'uso del linguaggio, in particolare quando si tratta di matrici dinamiche.
Per come la vedo io, uno sviluppatore, al contrario, dovrebbe essere interessato a rendere il linguaggio più facile da usare, piuttosto che complicarlo.
In altre parole, dovrebbero sviluppare quelle funzioni che sono necessarie all'utente per lavorare comodamente con il linguaggio.
E tanto più con le matrici, che sono quasi la base dei metodi numerici.
Per questo motivo, vorrei chiedervi di creare funzioni simili ad ArrayResize solo per le matrici ArrayResizeMx(A, n, m),
e forse anche per quelli multidimensionali. In altre parole, dare la possibilità di lavorare con le matrici non come con gli oggetti, ma come con i normali array nello stile C.
Specialmente per la rappresentazione visiva delle matrici, la funzione ArrayPrint(A, 0) stampa le matrici dagli array, non dagli oggetti.
Gli sviluppatori sono stati abbastanza specifici su questo. Qui
Gli sviluppatori sono stati abbastanza specifici su questo. Qui
Non c'è bisogno di andare lontano, il prossimo post, con domande specifiche da Prival,
Lo conosco da molto tempo, più o meno dallo stesso periodo, uno sviluppatore militare competente, e cosa, perché ha lasciato qui, la risposta è ovvia.
Sono passati dieci anni, è cambiato qualcosa?
Essendo pieno di semplici algoritmi, è rimasto a quel livello. Dove sono le soluzioni professionali?
Ma stiamo scrivendo più in python che per dare strumenti per scrivere queste soluzioni professionali e per sviluppare il nostro kodobase.
È qui che si trova l'errore, non ci sono strumenti, non c'è un livello adeguato di programmatori.
Ok, ora vado a dormire, non ho ancora dormito. Buona fortuna a tutti.
Quindi è tutto procedurale...
Procedurale è B, è tutto elementare lì, solo più opportunità di darsi la zappa sui piedi.
Credo che tu abbia sbagliato e che intendessi funzionale. Non ha importanza, però.