Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Son versiyonda onu da kontrol ettim. İhtiyacı olan kullanabilir.
Doğru. Ancak sağlanan algoritmaların boşluk bırakmadığını nereden biliyoruz? Sağlama toplamı bunu kanıtlamaz. Eleman sayısı da. Sonuçta işlev, dizi yeniden boyutlandırılmadan önceki öğeleri sayar.
Sunulan hemen hemen hepsinde, bu, NULL ile bir istek göndererek sorunsuz bir şekilde uygulanır.
Algoritma için başka bir gereksinim daha vardır - gereksiz öğeleri çıkardıktan sonra öğelerin dizi içine doğru yerleştirilmesi. Önce bu kontrol yapılmalıydı. Ardından, bir hız testi.
Neyi döndüren kodda bir açıklama var. Karışık diziler var. Başka bir dizide.
PS Bu arada. Benim fonksiyonumda bazı çekler kaydedilir, ancak kullanılmaz. Ama bunların hepsi ve daha fazlası var.
Katılımcıların profesyonelliğini ve yerlerini sorgulamıyorum. Az önce sağlama toplamı denetimindeki kusura ve ayrıca yeni dizideki öğelerin doğru düzenlenmesinin ek doğrulama ihtiyacına dikkat çektim.
Bütün bunlar doğruysa, sondan bir önceki yeri hak ettim.
Uygulamamda, belirli işlemlerin hızını nadiren düşünürüm. Ben daha çok çözümün kısa ve net olmasıyla ilgileniyorum. Bu giriş benim için bir sürpriz oldu:
if (Arr[q]==val){deleted++; q--;}
yavaşlayabilir.
Ancak, algoritmaları değerlendirmek için bir kriter daha eklersek - Çözümün Kısalığı, o zaman muhtemelen ilk sıradayım.
İki kriteri birleştirirsek - Hız ve özlülük ve algoritmanın ortalama puanını hesaplarsak, o zaman tabloda daha yüksek bir yer alacağım.
Her ne kadar Fedoseev'in versiyonu benimkinden daha özlü olsa da.Ancak, algoritmaları değerlendirmek için bir kriter daha eklersek - Çözümün Kısalığı, o zaman muhtemelen ilk sıradayım.
Ana döngü sürümünüz:
ve bu Fedoseeva:
Her iki seçenek de aynı şeyi yapar. Kim daha özlü?
Ana döngü sürümünüz:
ve bu Fedoseeva:
Her iki seçenek de aynı şeyi yapar. Kim daha özlü?
O. onun yerine sahip
for (;i<sz;i++)
Bu daha kısa.))
O. onun yerine sahip
Bu daha kısa.))
bu sadece derleyici için aynıdır.
Sadece çok fazla gereksiz Peter var, bu yüzden hepsinden daha yavaş çalışıyor (konudaki ilk seçeneği hiç düşünmüyorum)
Fedoseev'in döngünün bir geçişinde bir kontrol, bir atama ve bir artış var (Bir döngü düzenlerken doğrulama ve artırmayı dikkate almıyorum).
İki kontrolünüz, iki değişkenin bir toplamı , üç artış ve bir atamanız var.
Derleyici tarafından optimizasyon için tüm umutlar, aksi takdirde her yinelemede ArraySize yürütülür.
Derleyici tarafından optimizasyon için tüm umutlar, aksi takdirde her yinelemede ArraySize yürütülür.
Evet, derleyici, görünüşe göre, dizi boyutu döngüde değişmezse, bu işlevi bağımsız olarak bir değerle değiştirdiğini ve bu işlevi yalnızca bir kez değerlendirdiğini kontrol eder.
Her neyse, bunu yaparsanız:
işlevin yürütme süresi değişmez.
Bu nedenle, daha fazla kompaktlık için tam olarak Peter'ın yaptığı gibi yazmak mantıklıdır :)
Ama katılıyorum, kişisel olarak da gözlerimi acıtıyor. Fonksiyonun her seferinde çağrılacağını hissetmek.
Ama katılıyorum, kişisel olarak da gözlerimi acıtıyor. Fonksiyonun her seferinde çağrılacağını hissetmek.
imho, derleyiciye bir seçenek vermemek daha iyidir)
Sormama izin ver,
if(sayım>6) { ArrayCopy
altıdan fazla - değer bilimsel dürtme yöntemiyle elde edildi veya hangi gerekçe var?)imho, derleyiciye bir seçenek vermemek daha iyidir)
Sormama izin ver,
if(sayım>6) { ArrayCopy
altıdan fazla - değer bilimsel dürtme yöntemiyle elde edildi veya hangi gerekçe var?)Evet, bu o. Bilimsel dürtme yöntemi. Aslında benim gözlemlerime göre 5'ten 8'e kadar bu sayıyı her seferinde otomatik ayarlayarak bu işlemi otomatikleştirebilirsiniz. Gerçekten de, farklı işlemcilerde ve sistemlerde bu sayı farklı olabilir.
Örneğin CCanvas sınıfındaki tüm ArrayCopy ve ArrayFill'leri bu prensibe göre değiştirirseniz kanvas hızında iyi bir kazanç elde edebilirsiniz.