Çok güzel olmuş...

İlginçtir ilk örneği çözmesi daha kolayken, soldan sağa kuralını geri planda bırakıp sonucu 9 buması gerekirken 7 buluyor. Ancak 2. örnekteki testi başarıyla geçti...:)

	parser.load("1+2*(6/2)");
	parser.load("2/(3/4)*3*2");

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

Alıntı:

Teşekkür ederim :)

Alıntı:

Hata mı var sistemde? sonuç 7 olması gerekmiyor mu?

Zekeriya

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

O iki kod arasında hiçbir fark yok. Eğer birisinde hata alıyorsan çok büyük olasılıkla senin kodunda başka bir yerde bir tanımsız davranış (undefined behavior) var demektir.

Ali

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

Hocam 4 soru sormak istiyorum.

case NUMBER, p.calc: diyor ya bunu sadece 1 yerde 1 kere tanımlama gibi bir şansımız var mı?

calcItS fonksiyonunu calcIt içerisinde tanımlasam performans olarak birşey fark eder mi?

calc struct ı içerisindeki string op u string yerine enum yapsam daha mı performanslı olur?

kodlar arasında gereksiz bir işlem, sistemi yavaşlatabilecek bir kod var mı?

ve aşağıdaki kodu daha öncede dediğim gibi calcı t1 içerisine aldığımda hala hata veriyor.

zz = new calc(operator, t1, calcIt(t2, cOpLevel, null));
t1 = Token(line, p.calc, "", zz);

Zekeriya

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

Alıntı (zekeriyadurmus):

Alıntı (zekeriyadurmus):

Alıntı (zekeriyadurmus):

	struct Token{
		ulong line;
		lx typ;
		string value;
		void* val;
	}

Eğer bu dizgelerin amacı sadece Token'ların kimliğini tanımlamak ise bunun daha basit yollar mevcut. Hazır enum'ları daha yetenekli bir şekilde kullanmayı öğrenmişken bence 1 byte yer kaplayabilecek bir değer daha mantıklı görünüyor. Ancak ben enum'ları hala araştırıyorum ve kendilerine pek güvenmiyorum! Sanki enum'ları alfasayısal karşılıkları bellekte yer kaplamakta. Yani sanıldığı gibi türün sayısal karşlığını yazdığınız yere yerleştirmiyor. Assembly kodlarından bakmak lazım...

Alıntı (zekeriyadurmus):

Ama bu sözüm seni kırmasın çünkü gayet iyi gidiyorsun. Bence optimization olayını biraz daha erteleyebiliriz. Tamam, hız önemli ama daha önemlisi kodun doğru çalışması. Kod doğru çalıştı dediğimiz anda, öncekinin verdiği sonuçları referans alarak kodu öyle bir hale getireceğiz ki inşaallah hızlanacak. Övünmek gibi olmasın; kodları sadeleştirme konusunda yetenekli sayılırım. Belki de daha çok bir şeyleri kısatlmak, basit haliyle yazmak (basit derken hızlandıracak manada!) bana zevk veriyor. Elimde olmadan bir bakmışım her yerden kırpmışım. O yüzden en iyileştirme konsunda çok aceleci davranmayalım. Kod olabildiğince gevşek olabilir. Ama işlevleri daha uzun isimler ile adlandırırsan anlamamız kolay olacak.

Son söylediğine bakacağız, istersen hata vermeyen şekilde kullanmaya devam edelim...

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

Alıntı:

Hocam Token eğer başka bir structı belirtiyorsa mesela (2 + 2) işlemini saklayan bir structı belirtiyorsa val değeri o structın adresi oluyor. Eğer belirtmiyorsa lexer içerisindeki lx enumundaki tipe göre bir değer alıyor örneğin
(NUMBER, 100) Veya (PLUS, +) gibi. Orada onunla ilgili bir karşılaştırma var. Ama orada olmaması gereken şey şu input.value değeri null veya hatalı bir değer oraya başka bir Token değeri geliyor adreslerde karışıklık oluyor sanırım. Yada üzerine başka bir veri yazılıyor. Eğer dışarıda tanımlayıp tanımladığımızı yazarsak böyle bir sorun yok

Alıntı:

> if() {...}
> ```
kümesini birlikte değerlendirmeyi başarabilecek zamanı bulabilirsem, sanırım bazı sadeleştirmeler mümkün görünüyor.
>
Şöyle birşey yapabilir miyiz acaba diye düşündüm. Lexer içindeki lx enumunun bütün değerlerini bir diziye atalım struct karşılıklı bir dizi. Bu struct içerisinde de bazı verileri saklayalım dizideki indekse erişim her seferinde kontrol etmekten daha hızlı olacaktır gibime geliyor. Hem orada o şekilde bir karşılaştırma da yapmış olmayız.

Alıntı:
>
> Bence de öyle yapmalısın çünkü sadece o işlev içinde kullanıldığına ve calcItS() sadeleştireceğimizden, çok yakında harika bir caclt() işlevi çıkması olası görünüyor...
>
İnşAllah :) Bir de bu işleve güzel bir isim vermek gerekiyor :)

Alıntı:
>
> Ama bu sözüm seni kırmasın çünkü gayet iyi gidiyorsun.
>
Neden kırsın :) Doğru söze ne hacet :)

Alıntı:
>
> Bence optimization olayını biraz daha erteleyebiliriz. Tamam, hız önemli ama daha önemlisi kodun doğru çalışması. Kod doğru çalıştı dediğimiz anda, öncekinin verdiği sonuçları referans alarak kodu öyle bir hale getireceğiz ki inşaallah hızlanacak.
>
Yaptığım testlerde bir hata göremedim ben o yüzden optimizasyona geçmek istedim.

Zekeriya

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

Hata görememiş olabilirsin; peki referans alacağımız kaynak Google Arama Motoru mu olacak, yoksa bilgiyi işleme, sunma ve her türlü değerlendirmeyi çok çok iyi yapan Wolfram Alpha'dan mı faydalanacağız. Çünkü ona göre ilk sorunu cevabı 9:
http://www.wolframalpha.com/input/?i=6/2*%281%2B2%29

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

Test ettiğimde çıktılar
6/2*(1+2) => 9
http://www.wolframalpha.com/input/?i=6%2F2*%281%2B2%29

1+2*(6/2) => 7
http://www.wolframalpha.com/input/?i=1%2B2*%286%2F2%29

2/(3/4)32 => 16
http://www.wolframalpha.com/input/?i=2%2F%283%2F4%29*3*2

Hala hatayı göremedim :( Çıktılar doğru değil mi?

Zekeriya

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

Hata bende o zaman...:)

Örnek nasıl olduysa evrimleşmiş ve farklı bir şekile; ilk terim bölme yerine toplama haline dönüşmüş. Ahhh şu Darwin yok mu, oraya da parmak atmış...haha

Bu arada belki ilgini çeker, DMD'nin Parser'ı: https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c

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

:) Peki şimdi kodlar düzgün çalıştığına göre iyileştirme yapabilir miyiz?

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