September 24, 2009

Derleyicinin kararı bazı durumlarda teorik olarak olanaksızdır. Bazı durumlarda ise kodun derleyici tarafından incelenip mutlaka sonlanacağını garantilemek çok zordur.

Bir işlevin her durumda bir değer döndürüp döndürmeyeceğini bilmesi bile çok zor olur. Ondan sonra da "bunu anladım, sonunda return gerekmiyor" veya "bunu anlayamadım, return'de ısrar edeyim" diye ikili davranmasının da istemeyiz.

Ayrıca, ben bir programcı olarak her baktığımda kodu incelememi gerektiren kodlar üzerinde çalışmak istemem. :)

Ayrıca, derleyicinin sonuçta bir kod üretmesi gerekiyor. O sondaki

   if(++i==ilk.length){
       return 0;
   }

denetimi için kod üretecek; şart... O if'in "olmadığında" diye bir dalı var. Mutlaka kod üretmesi gerek. Ne üretsin? return 0? return 1? sabit diski formatlama kodu? (Nasıl olsa gelinmez ya ;) )? Bilemez.

Son olarak, derleyicinin bizim adımıza karar vermesini de istemeyiz. Bu davranışı kodumuzdaki hataları gizleyebilir.

Yine son olarak, :) zaten aslında bilse yine de haklı: ++i'nın ilk.length'e eşit olmadığı durumlar var. Örneğin "a" ile "a"yı karşılaştırdığında if'e gelindiğinde i==ilk.length zaten. Bir arttırınca geçersiz oluyor ve program işlevden return olmadan çıkıyor...

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 24, 2009

svn'e ekleme komutu şöyle herhalde:

'svn commit -m "... buraya mesaj gelecek ..." tr/string.d'

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 25, 2009

Şimdilik 'icmp_tr' için hey bir şey hazır. Unittestleride yazdım. Unittestler:

unittest

{

   assert(icmp_tr("deneme"d.dup,"debeme"d.dup)==15);

   assert(icmp_tr("çalışkan"d.dup,"öğrenci"d.dup)==-15);

   assert(icmp_tr("TürkçeyeUygun"d.dup,"TürkçeyeUygun"d.dup)==0)

   }

Ama şimdi aklıma şunlar takıldı:

  1. Boşluk olursa örneği 'den eme' ile 'deneme' ben boşluğa hangi değeri atayacağım.

  2. '@}[' gibi saçma sapan şeyleri ne yapacağım. Onları da eklemeye gerek yok herhalde.

  3. Türk abc'sinin 29 harfi var ama başka karakter girerlerse ne yapacağım. 'W'... filan.

Sizce bunlar trileri ile alakası var mı ? Bana belki göre boşluğun var. Eğer boşluğa da bir karakter girmek gerekirse ne gireyim ? 0 Uygun mudur?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 25, 2009

Boşluk karakteri, ASCII'de diğer her harften önceki bir değere sahiptir: 32.

Bence daha köklü bir çözüm bulmak gerek. Desteklediğimiz her harfi içeren bir eşleme tablosunu elle teker teker büyütmek zahmetli olacak.

Ayrıca o birim testleri iyice genişletmek gerek ve 15 gibi sabit bir değer yerine, kullanıcılar gibi ==0, <0, ve >0 koşullarına bakmak gerek.

assert(icmp_tr("aa"d.dup,"aaa"d.dup) < 0);
assert(icmp_tr("aaa"d.dup,"aa"d.dup) > 0);
// baştan aynı olup da ortada bir harfi değişik olanlar
// onların değişik uzunlukta olanları
// şapkaları destekliyor muyuz?

Hatta Ã, Ñ, Ė, vs. harfleri de mümkünse Türk benzerlerinin yanında sıralanmış görmek iyi olur; o harflerin z'den sonra gelmeleri bana garip gelir.

Doğrusu ben henüz bu konuya kafamı tam olarak veremedim. Böyle rastgele fikirler atıyorum... :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 26, 2009

Hatta Ã, Ñ, Ė, vs. harfleri de mümkünse Türk benzerlerinin yanında sıralanmış görmek iyi olur; o harflerin z'den sonra gelmeleri bana garip gelir.

Alıntı (canalpay):

>

Fonksiyonu denedim ve olmuş ellerime sağlık. â î bizimle alakası olmadığı halde daha sonra ekleyeceğim. Şimdilik iş planım bu :

  1. icmp'yi son kez dene. Doğru ise svn'ye gönder(unittest olsun yorum olsun ekle) ( bu arada konsolda şimdiye kadar svn ile bir şey göndermedim hatalı olursa alltan alırsınız artık :-) )

  2. cmp'yi yap (ya a=1 A=1 diyeceğim ya da tolower ile hepsini küçültüp deneyeceğim. Sizce hangisi daha iyi ? )//Burada icmp'yi yanlış anlamışım. Düzelttim :-)

  3. â î û ... destekli hale getir.

Size göre eksikler nelerdir ?

Alıntı (acehreli):

>

Boşluk karakteri, ASCII'de diğer her harften önceki bir değere sahiptir: 32.

a'nın değeri 1 boşluğun değeri 0 olursa ascii ile aynı mantık oluyor.

Alıntı (acehreli):

>

Bence daha köklü bir çözüm bulmak gerek. Desteklediğimiz her harfi içeren bir eşleme tablosunu elle teker teker büyütmek zahmetli olacak.

İki tane harfi aynı eşe eşleyebilmemiz gerekiyor.

Benim düşüncelerime göre ya şimdiki kullandığım yöntem yada enum işey yarar. Ama enum'u buna nasıl dahil edebiliriz ki ? mesela siz enum ile a ile b'yi ayırt eden bir uygulama yazabilir misiniz ? Ben de onu genişletirim.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 26, 2009

Alıntı (acehreli):

>

assert(icmp_tr("aa"d.dup,"aaa"d.dup) < 0);
assert(icmp_tr("aaa"d.dup,"aa"d.dup) > 0);

Bu olasılıkları unutmuştum. Hatırlattığınız için teşekkürler.
Şu anda bunlarıda destekliyor.

   writeln(icmp_tr("aaaa"d.dup,"aaa"d.dup));
   writeln(icmp_tr("aaaa"d.dup,"aaaaa"d.dup));

   writeln(icmp_tr("deb eme"d.dup,"debeme"d.dup));

Kodlar da bunlar :
http://www.ozgurlukicin.com/yapistir/248/

Şu an başka bir olasılık kaldı mı ?

Şimdilik eksik kalan âîû karakterleri. Onlarıda yaptıktan sonra /{¾[]½$# gibi karakterleri eklemeye gerek var mı ? Belki o karakterlere gelincede phobos kütüphanesinin icmp'sini çağırırız. Ne dersiniz ?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 26, 2009

Alıntı (canalpay):

>

Kodlar da bunlar :
http://www.ozgurlukicin.com/yapistir/248/

Çok güzel... :)

Sanki son üç return birleştirilebilir gibi geldi:

return ilk.length - son.length;

Çağıran -100 ve 100 gibi özel değerler beklemediği için çalışır...

Alıntı:

>

/{¾[]½$# gibi karakterleri eklemeye gerek var mı ? Belki o karakterlere gelincede phobos kütüphanesinin icmp'sini çağırırız. Ne dersiniz ?

Gelen dizgilerdeki bütün karakterler konusunda tutarlı bir sonuç üretmemiz gerek.

Ama galiba icmp'u da çağıramayız... Karşılaştıracak karakterler c ve ç olduğunda kendimiz yaparız, tamam... Ama ç ve { karakterlerini hiçbir zaman icmp'a gönderemeyiz, çünkü {ç sırasıyla sıralar; oysa { bütün ASCII harflerden sonradır...

Bence bu harflere kod atama işini daha dikkatli yapmalıyız. a-z harfleri ASCII tabloda 97-122 kodlarında duruyorlar. Biz bu 26 kodu genişleterek 29 tane kullanırsak, bu sefer tabloda bizden sonraki kodları itelemiş oluruz.

Şu fikir nasıl: acaba 26 kodun içine 29 harfi sıkıştırabilir miyiz? Tabii ki olanaksız ama belki örneğin c ve ç'yi aynı yere ama ç için özel bir belirteçle yerleştirsek. Şuna benzer bir yapı oluştursak (bir anlamda kesirli sıra numaraları kursak):

'
ASCII İkincil
kod kod Aksanlı Harf

97 0 false a
98 0 false b
99 0 false c
99 1 false ç
99 2 true ć
99 3 true ĉ
.. . .. .
100 0 false d
...
'

Not: ç aksanlı değil, çünkü Türkçe açısından kendisi bir harftir. Ama c'nin diğer aksanlıları bizim için aksanlı kabul edilir... herhalde... :)

Böylece yalnızca bir "ASCII'de olmayanlar" tablosu tutarız ve öncelikle orada olup olmadığına bakarız. Örneğin ç oradaysa, onun da ASCII kodu 99'dur. Mantık şöyle kurulabilir:

Burada iki harfin karşılaştırmasını düşünüyorum, çünkü dizgi karşılaştırması bunu kullanırsa zaten istediğimiz gibi sıralar:

  • birinci'nin ASCII kodu büyükse birinci büyüktür
  • birinci'nin ASCII kodu küçükse ikinci büyüktür
  • ASCII kodları eşitse, ikincil kodlarını karşılaştır
    gibi...

Bir arkadaşım Microsoft'un bu işi çok iyi çözdüğünü ve belgelerinin de iyi olduğunu söyledi. Daha bakmadım... :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 27, 2009

Alıntı (acehreli):

>

Şu fikir nasıl: acaba 26 kodun içine 29 harfi sıkıştırabilir miyiz? Tabii ki olanaksız ama belki örneğin c ve ç'yi aynı yere ama ç için özel bir belirteçle yerleştirsek. Şuna benzer bir yapı oluştursak (bir anlamda kesirli sıra numaraları kursak):

Onun yerine 'double' değerler kullanırız daha iyi bence. Hem if kontrolü gerekmez kod hızlanır. Hemde kod basitleşir.

Bence ayrıca kendimize ascii gibi bir tablo yapsak daha iyi. Daha yavaş çalışır ama karakter eklenmesi olsun karakter çıkartılması olsun daha kolay olur. Hem başka biri başka karakter eklemek isterse onun için de kolaylık olur.(Bizde eklemek isteyebiliriz.)
Bence microsoft'ta bu yöntemi kullanıyordur. Kendine ascii gibi bir karakter tablosu yapmıştır.
Alıntı (acehreli):

>

Sanki son üç return birleştirilebilir gibi geldi:

return ilk.length - son.length;

Çağıran -100 ve 100 gibi özel değerler beklemediği için çalışır...

Tamam dediğiniz gibi yaptım. Hem de if kontrolü olmadığı için çok daha hızlı çalışır. :-) Ama 100 olsun -100 olsun kendisinden kısa olduğunu belirtiyordu. Artık belli olmayacak :-/(Bu arada kod yavaşladı gibi :-D )

Kod çok yavaş çalışıyor. icmp'den 11 kat daha yavaş çalışıyor. Birde bunlara ek karakter eklersek...

Bu arada sizin yanıt vermediğiniz için bilmediğinizi varsayıyorum. Ama yinede başkaları bilebilir diye soruyorum.
**mesela siz enum ile a ile b'yi ayırt eden bir uygulama yazabilir misiniz ? Ben de onu genişletirim. **

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 27, 2009

demek istediğim:

import std.stdio;
void main(){
   writeln(cmp_tr(cmpAbc.a,cmpAbc.ç));
   }
enum cmpAbc {
   a,b,c,ç,d,e,f,g,ğ,ı,i,j,k,l,m,n,o,ö,p,r,s,ş,t,u,ü,v,y,z,
}
int cmp_tr(cmpAbc birinci, cmpAbc ikinci){
   return birinci-ikinci;
   }

Ben bu kodda cmpAbc.a değil 'a' diye çağırmak istiyorum. Ne yapabilirim ?

Alıntı (acehreli):

>

Ama bu tablo yalnızca istisnaları kapsamalı. Yoksa desteklediğimiz her karakteri girmek çok zor olurdu; yüz bin Unicode karakter var...

cmp hangi kodlar için çalışıyor. Sadece ascii kodları yani 255 tanesi için çalışmıyor mu ? Çalışsa bile bence her karakteri eklemeye gerek yok. ™ @€¶€¶™™←¾{[]¾]}½[]½#¾ gibi bir karakter topluluğunu adam varsın a ile û ile â ile ç ile karşılaştırmasın. Biz daha â bile bizi ilgilendirmiyor onu düzeltmeye gerek yok derken gidip [{¾ bu karakterleri düşünmeyelim bence.

Bu arada mesajınızı okurken bir şey dikkatimi çekti hemen size belirtim: Biz matematikte ve veya yada'nın anlamlarını böyle gördük:
've'nin anlamı' : hem sağ taraf hem sol taraf doğru olacak.
'veya'nın anlamı' : sadece sağ taraf doğru olabilir, sadece sol taraf doğru olabilir, hem sağ hem sol doğru olabilir.
'ya da'nın anlamı' : sadece sağ taraf doğru olabilir, sadece sol taraf doğru olabilir, hem sağ hem sol doğru olamaz.

Sadece bir şeyi anlatırken daha kolay anlatalım diye bizde böyle kullanabiliriz. Yoksa kök bakımından Türkçe bir sözcük olmadığı için tdk'daki anlama göre ya da matematikteki anlama göre kullanılıp kullanılmadığı pek umurumda değil. and,or,xor da kullanabiliriz ama ve veya yada'nın anlamlarını böyle bilen sayısı çok.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

September 27, 2009

Alıntı (canalpay):

>

Onun yerine 'double' değerler kullanırız daha iyi bence. Hem if kontrolü gerekmez kod hızlanır. Hemde kod basitleşir.

Bunu ben de düşündüm: ç == 99.5... Ama kesirli sayı işlemlerinin tamsayılardan çok daha yavaş olduklarını bildiğim için, ve buradaki if karşılaştırması da tamsayı karşılaştırması olduğu için, yine de böyle bir yapı daha hızlı olabilir.

Ben çok hızlıca şöyle bir şeyler yazdım:

import std.cstream;
import std.algorithm;
import std.functional;

class SıralamaKodu
{
   int asciiKod_;
   int ikincilKod_;
   bool aksanlı_;    // Henüz kullanılmıyor

   this(int asciiKod, int ikincilKod = 0, bool aksanlı = false)
   {
       asciiKod_ = asciiKod;
       ikincilKod_ = ikincilKod;
       aksanlı_ = aksanlı;
   }

   const int opCmp(in SıralamaKodu diğeri)
   {
       int sıra = asciiKod_ - diğeri.asciiKod_;

       if (!sıra) {  // if (sıra == 0) ile aynı şey
           sıra = ikincilKod_ - diğeri.ikincilKod_;
       }

       return sıra;
   }
   unittest
   {
       auto aSırası = new SıralamaKodu('a');
       auto çSırası = new SıralamaKodu('c', 1);
       auto dSırası = new SıralamaKodu('d');

       auto hSırası = new SıralamaKodu('h');
       auto ıSırası = new SıralamaKodu('i', -1);
       auto iSırası = new SıralamaKodu('i');

       assert((aSırası < aSırası) == false);
       assert((aSırası < çSırası) == true);
       assert((çSırası < aSırası) == false);
       assert((dSırası < çSırası) == false);
       assert((çSırası < dSırası) == true);

       assert((hSırası < hSırası) == false);
       assert((hSırası < ıSırası) == true);
       assert((ıSırası < hSırası) == false);
       assert((iSırası < ıSırası) == false);
       assert((ıSırası < iSırası) == true);
   }
}

static SıralamaKodu[dchar] sıralamaKodları;

static this()
{
   sıralamaKodları['ç'] = new SıralamaKodu('c',  1, false);
   sıralamaKodları['ı'] = new SıralamaKodu('i', -1, false);
}

SıralamaKodu sıralamaKodu(dchar karakter)
{
   SıralamaKodu * gösterge = (karakter in sıralamaKodları);

   SıralamaKodu kod = gösterge ?
                      *gösterge
                      : new SıralamaKodu(karakter, 0, false);

   return kod;
}
unittest
{
   assert(sıralamaKodu('c') < sıralamaKodu('ç'));
   assert(sıralamaKodu('ç') < sıralamaKodu('d'));
   assert(sıralamaKodu('h') < sıralamaKodu('ı'));
   assert(sıralamaKodu('ı') < sıralamaKodu('i'));
}

void main()
{
   // Bu kodun çalışmasını beklerdim; derleyici hatası mı?
//     dchar[] harfler = "açzdiı"d.dup;
//     sort!"sıralamaKodu(a) < sıralamaKodu(b)"(harfler);
//     dout.writefln(harfler);
}

Ama sanırım derleyici ve/veya kütüphane hatalarına takıldım. main içindeki kodun derleneceğini beklerdim. Şu hatayı alıyorum:

/home/acehreli/dmd2.032/linux/bin/../../src/phobos/std/algorithm.d(3688): Error: static assert  "Invalid predicate passed to sort: s\xc4\xb1ralamaKodu(a) < s\xc4\xb1ralamaKodu(b)"

Alıntı:

>

Bence ayrıca kendimize ascii gibi bir tablo yapsak daha iyi.

Ama bu tablo yalnızca istisnaları kapsamalı. Yoksa desteklediğimiz her karakteri girmek çok zor olurdu; yüz bin Unicode karakter var...

Alıntı:

>

mesela siz enum ile a ile b'yi ayırt eden bir uygulama yazabilir misiniz ? Ben de onu genişletirim.

Enum değerler zatan tamsayı gibi değerlere sahiptirler. Soruyu tam anlamıyorum ama şöyle olur:

void foo(BirEnum birinci, BirEnum ikinci)
{
   if (birinci != ikinci) {
       // ...
   }
}

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]