Biraz şaşırdım :) Retorik bir soru DEĞİL paylaşmaya ve sormaya karar verdim. - sayfa 22

 
MetaDriver :

1. Bu, her çekim için tek seferlik bir işlemdir. Kayıp ihmal edilebilir, ardından sağlam kazançlar. :) Orijinal alıntının bir kez logaritmik olduğunu ve tamsayı gösterimine dönüştürüldüğünü varsayıyorum.

2. Bu doğru. Hızlı olmasına rağmen, çünkü bit kaydırma kullanan akıllı bir algoritma var.

3. Uzun taşma kontrollerinden daha fazla değil.

4. Tamsayı kısmını seçmek hiç gerekli değildir. kesir bir çift uzun olarak saklanır. ve mümkünse - bir çift giriş olarak.

5. bir çift uzun olarak saklanırsa tam olarak aynı miktar ve yeterli ints varsa yarısı kadardır (bu, algoritmanın kesinliğine bağlıdır).

Alıntıların belleğin ana tüketicisi olduğunu hesaba katarsak, o zaman bir tamsayı gösterimi ile uzaydaki kazanç yadsınamaz.

Ana özelliğin hafızadan tasarruf etmek değil, hızlandırmak olmasına rağmen. Bu çok daha önemli.

--

Akademisyenle ilgili sorun yanlış olması değil. Bu da diğerlerinin yanlış olduğunu ortaya çıkarır.

Bu, mevcut olanların tahriş olmasına ve sağlıklı fikirlerin reddedilmesine neden olur ... kirli su ile birlikte ... :(

Vladimir hiçbir şeyi karıştırmıyor musun? Tanımladığınız şey, düşük seviyeli aritmetik double ve float, depolama için "Akademisyen" i tanıtmayı öneren aynı aritmetik (tamsayı kısmını vurgulamadan bile) en az iki mantis gerektirir.

Peki tasarruf nerede? Double için 8 bayt ve int için 2*4 bayt.

En iyi durumda, zaten uygulanmış olan sonuca geleceksiniz.

 
Urain :

Vladimir hiçbir şeyi karıştırmıyor musun? Tanımladığınız şey, düşük seviyeli aritmetik double ve float, depolama için "Akademisyen" i tanıtmayı öneren aynı aritmetik (tamsayı kısmını vurgulamadan bile) en az iki mantis gerektirir.

Peki tasarruf nerede? Double için 8 bayt ve int için 2*4 bayt.

En iyi durumda, zaten uygulanmış olan sonuca geleceksiniz.

Bu nedenle, tek boyutlu değerlerin tüm noktalarını (paydaları) tek bir yerde saklayın - bunlar aynıdır. :)

Bir tür alın - bir noktanın onda biri değerinde bir değer ve bu kadar. Ve bu paydayı ayrı olarak saklayın.

 
MetaDriver :

Deneyeceğim. Mql5'te, eğer böyle bir içki gittiyse... :)

Sadece zaman alacak. Bir kütüphane yazmalısın.

Öyle bir şey denedim ki orada tatlı yok, sadece zaman kaybedersiniz.

Double'ı bir ikili sayıya ayırın ve onu iki int olarak hayal edin ve tanımladığınız her şeyin zaten double aritmetikte uygulanmış olduğunu anlayacaksınız.

ZY Yalnızca aritmetik düşük düzeyde uygulanır ve bunu daha yüksek bir düzeyde yaparsınız, bu da hız ve hafıza kaybedersiniz.

 

Benim beş sentim.

Tamsayılar, teklif bilgilerini temsil etmenin daha doğal bir yoludur. Sonuçta, puan sayısı tamsayı olamaz. Bu tür sayıların saklanması daha ekonomiktir, yani disk-bellek düzeyindeki indirme hızı ve bellek-işlemci düzeyindeki indirme hızı daha yüksektir. İşleme algoritmaları, doğru bir şekilde oluşturuldukları takdirde, gerçek sayılara sahip algoritmalardan çok daha hızlıdır ve toplu SSE işlemleri dikkate alındığında genellikle rekabet dışı kalırlar. Ancak, büyük ama tamsayılı bir tane var - onlarla sadece birkaç kişi çalışabilir. Ve tabi ki terminalin asm desteği olması gerekiyor. MQ'nun toplu tüketicisi için bu rakamlar uygun değildir.


Bu arada, taşma kontrolü sorunu donanım kesintileri düzeyinde uygulanıyor, bunda yanlış bir şey yok, aksine insanlar işlemcileri yaratırken uzun zamandır bunu düşünüyorlardı. Prensipte, tamsayılı algoritmaları programlamak için çok sayıda yol ve teknik vardır, ancak bu, tekrar ediyorum, kitlesel kullanıcılar için değildir.


Tartışmanın ne hakkında olduğunu anlamıyorum. Test cihazında olduğundan daha hızlı bir test/optimizasyon algoritması oluşturmak mümkün mü? Mümkün, ancak yazarın huzurunda sera koşullarında yaşayan evrensel bir algoritma olmayacak - çok az insanın böyle bir şeye ihtiyacı var, bu toplu bir ürün değil. Bu nedenle, "ve ben daha hızlıyım" ruhundaki konuşmalar, ancak dar görüşlülüğün ve emsalsizin karşılaştırılamayacağının yanlış anlaşılmasının kanıtı olarak kabul edilebilir.

 
Urain :

Öyle bir şey denedim ki orada tatlı yok, sadece zaman kaybedersiniz.

Double'ı bir ikili sayıya ayırın ve onu iki int olarak hayal edin ve tanımladığınız her şeyin zaten double aritmetikte uygulanmış olduğunu anlayacaksınız.

ZY Yalnızca aritmetik düşük düzeyde uygulanır ve bunu daha yüksek bir düzeyde yaparsınız, bu da hız ve hafıza kaybedersiniz.

Horozun dediği gibi tavuğun peşinden koşarak “Yetişmem, sıcacık tutarım”... :)

Aslında bu konuyu uzun zamandır düşünüyorum, görünüşe göre denemenin zamanı geldi.

 
MetaDriver :

Horozun dediği gibi tavuğun peşinden koşarak “Yetişmem, sıcacık tutarım”... :)

Aslında bu konuyu uzun zamandır düşünüyorum, görünüşe göre denemenin zamanı geldi.

Tekrarlayan bir GCD algoritması mı veriyorsunuz?
 
TheXpert :

Ne için? C++ kabul edilir.

Bir bakacağım. Önce hissetmelisin. Ben kendim ilgileniyorum.
 
Urain :
Tekrarlayan bir GCD algoritması mı veriyorsunuz?
Bit kaymaları varsa - hadi. Modulo bölümü varsa, gerekli değildir.
 
MetaDriver :
Bit kaymaları varsa - hadi. Modulo bölümü varsa, gerekli değildir.

Bir (zorunlu olarak 2'nin katı değil) bir sayıyı bir bit kaydırma yoluyla başka bir sayıya (mutlaka 2'nin katı değil) bölecek misiniz?

Tamam, elimdekileri atacağım ve sonra ihtiyacın olup olmadığını kendin düşüneceğim.

 //+------------------------------------------------------------------+
long GreatestCommonDivisor( long v0, long v1)
  {
   return (GCD( fmax ( fabs (v0), fabs (v1)), fmin ( fabs (v0), fabs (v1))));
  }
//+------------------------------------------------------------------+
long GCD( long max, long min)
  {
   if (min> 0 ) return (GCD(min,max%min));
   else return (max);
  }
//+------------------------------------------------------------------+
 
DDFedor :
Sonraki gönderilerinizdeki ifadeler kesilecektir. Bunu düşün.

ATP en azından kabul edildi - ifadeleri kestiniz, ancak tüm gönderileri kim siler?

konuya göre, Akademik , sözde bir "sayacınız" olması harika, açıklığa kavuşturmak isterim, ancak ticaret sırasında otomatik optimizasyon olasılığınız var mı?