The Simpsons ve Fermat Teoremi (Yanlış Mı?)

0
FZ
FZ
11 Haziran 2006 , 1 dakika okuma süresi
cember.net'in bilişim forumunda gördüğüm ve Volkan Özçelik tarafından yazılmış eğlenceli bir mesajı (ufak tefek editöryel müdahale ile) paylaşmadan duramadım: Fermat'nın son teoremine göre a^n + b^n = c^n eşitliği 2den büyük hiçbir tamsayı için doğru değildir. Bu teoremin doğruluğu çok yakın bir geçmişte ispatlandı. Yani yıllarca matematikçilere karın ağrıları çektiren bir teorem bu. Ancak

1782^12 + 1841^12 = 1922^12

ediyor (en azından Homer Simpson öyle düşünüyor!)
İnanmadım ve denedim. Aldım Casio CFX-9850 GB'mi (mühendislerin can dostu bilgisayardan bozma, hesap makinesi demeye bin şahit, grafik çizen, integral çözen, kendine ait programlama dili bile olan aygıtı) ve 1782^12 + 1841^12 yi hesaplayım 12. dereceden kökünü aldım. Ekranda gördüm ki 1922 yazıyor!

Ama nasıl ola ki? En basit mantık bile bunun yanlış olduğunu söyler:

1782^12 + 1841^12 = 1922^12

(çift sayı)^12 + (tek sayı)^12 = (çift sayı)^12

çift sayıların her kuvveti çift, tek sayıların her kuvveti tektir.

çift sayı + tek sayı = çift sayı (lakin bir çift sayı ile bir tek sayı toplanınca her zaman tek sayı elde edilir)

tek sayı = çift sayı

çelişki!

İşin altındaki bit yeniğini öğrenmek için: http://www.sciencenews.org/articles/20060610/bob8.asp

Editörün notu: Görünen o ki Simpsons çizgi film ekibinde sadece "sanatçılar" yok ;-) Dizinin yazarlarından David X. Cohen aynı zamanda bilgisayar bilimleri dalında yüksek lisans derecesine sahip bir "geek".
Matematik
79
Linkedin Facebook Twitter Google plus

Görüşler

Chaosopher
0
Chaosopher

Linkteki yazıya göre Simpsons yazar ekibinde matematik alanında doktora derecesine sahip kişiler de var. Hatta bu yazarlar Kaliforniya Berkeley deki Mathematical Sciences Research Institute'de The Simpsons'daki matematiksel referansların konuşulduğu bir panele katılmışlar.

Yazarlardan Jeff Westbrook panelde sezon sonu finalinde metematiksel açıdan ilginç olan 8191, 8128, 8208 sayılarını kullandıklarını belirtmiş ama bu sayıların neden matematiksel olarak ilginç olduklarını söylememiş. Var mı bir fikri oan?

Klişe olacak ama: Yurdumuz ekranlarındaki zilyon diziden birinin yazar ekibindeki "matematikçilerin" örneğin Feza Gürsey Enstitüsü'nde benzer bir panele katıldığını görmeye ömrümüz acaba yeter mi?

yilmaz
0
yilmaz
dizi yada film senaristlerinin matematiksel geçmişinin olması o kadar önemli mi? Bahsi geçen kimse uç bir örnek.
FZ
0
FZ
O kadar önemli değil. Konu zaten senaristlerin özel hayatı değil. Konu Simpsons ya da belki Fermat... ya da belki teoremler, ispatlar, programlama, bilgisayarlar, CASIO, HP48... Ya da belki senaristlerin özel hayatı. Kendi kendine eğlenen bir grup bilgisayarcı, matematikçi ya da her kimse. Konu belki sadece "geek humour". Ya da "nerd humour". Ya da "humor". Her neyse...
yilmaz
0
yilmaz
tabiki ana konu o. Ama her konuda "Bizde niye boyle şeyler yok." ile başlayan ve memleketim insanlarını kötü gösteren geyikleri hoş bulmuyorum.
Chaosopher
0
Chaosopher
Yorumun zaten klise bir `geyik` oldugu belirtilmisti zaten.
Ayrica neden bizde icerigi zekice olan ve cok genis kaynaklardan beslenen (matematik olmasi sart degil) diziler olmasin bunu istemek memleket insanlarini kotu gostermek midir?
bm
0
bm
8191, 8128, 8208 icin: http://www.mathsci.appstate.edu/~sjg/simpsonsmath/baseball.html
sundance
0
sundance
Simpsons'a da başka türlüsü yakışmazdı :)
nehuse
0
nehuse
Hesap makinesine gerek yok Google halleder. 1782^12 + 1841^12 :)
Ayrıca Çift sayıların her üssü çift olmaz eksik bilgi vermeyelim ..
euler
0
euler
evet, her n eleman Z^+ için gerçeklenir sadece..
syntor
0
syntor
Bunun ispati icin cok yuksek hassasiyetli hesap makinasi lazim, mesela bc. $ a=1782 $ b=12 $ c=1841 $ d=12 $ echo $a^$b+$c^$d | bc 2541210258614589176288669958142428526657 $ e=1922 $ f=12 $ echo $e^$f | bc 2541210259314801410819278649643651567616 gördüğünüz gibi 9. haneden sonra yeterince hassas olmayan makinalar yuvarlama hatasi yapiyor.
281817 181476855250691 6784756 n
0
tongucyumruk
Evet, bu şekilde hesaplanırsa farklı olduğu görülüyor. Fakat eğer yazıda anlatıldığı gibi 12. dereceden kökünü almayı denerseniz sonuç tuhaflaşıyor. BC kullanmayı çok iyi bilmediğim için, işte Common Lisp'in duruma cevabı: 

CL-USER> (+ (expt 1782 12) (expt 1841 12))

2541210258614589176288669958142428526657

CL-USER> (expt 1922 12)

2541210259314801410819278649643651567616

;; Sonuçlar farklı

CL-USER> (expt (+ (expt 1782 12) (expt 1841 12)) (/ 1 12))

;;bu işlemin sonucu 1922 olmamalı

1922.0

CL-USER>
Sanıyorum bu bir hassasiyet hatasından biraz daha farklı.
newman
0
newman
Sadece bir ondalik basamaga yuvarliyorsunuz, o yuzden 1922.0 aliyorsunuz (Kullandiginiz Lisp versiyonunun cikti rutini yuzunden). Ben DrScheme'de denedim, iste sonuc: (expt (+ (expt 1782 12) (expt 1841 12)) (/ 1 12)) Welcome to DrScheme, version 301.14-svn18may2006. Language: Pretty Big (includes MrEd and Advanced Student). 1921.9999999558663
bm
0
bm
(Kullandiginiz Lisp versiyonunun cikti rutini yuzunden)

Yok o hesabi hakikaten oyle yapiyor. Expt'i bir tamsayi ve bir ratio ((/ 1 12)) ile cagiriiyoruz. Rule of Float Substitutability ile single-float oluyor sonuc. Birini double yapinca bu sefer Rule of Float Precision Contagion yuzunden double'a zorluyoruz. Kabaca gordugum bu. (RSNS bu Scheme'de durum icin ne diyor bakmadim). Soyle de oluyor ayni sebepten:

CL-USER> (expt (float (+ (expt 1782 12) (expt 1841 12)) 1.0d0) (/ 1 12)) 1921.9999999558663d0 CL-USER>

Ama bu konuda bana guvenmeyin, 'ben nasil bildim de bunu boyle yaptim'dan geri giderek specten kilif buldum. Simdi niye single-float'a sigmayacak bir bignum verilince hala single donduruyor filan diyecekseniz, comp.lang.lisp sizi bekliyor.

newman
0
newman
Dogru gorunuyor :). Yalniz bunu hazirlarken ne dusunmusler merak ettim: insan bir "at least single float precision" filan der ;). Fazla standard olmak da iyi degil.
bm
0
bm
Bunun komikimsi bir cevabi var, orada 'at least single-float' demiyorlar belki ama single-float ne demektir sorusunun cevabi 'at least'li. Bakarsaniz oraya hakikaten olmasi sart olan tek float tipi single-float zaten, belki ona bagli birseydir. Gerci bunlari tahmine luzum yok, o dokumanin editoru cll'de cene yaristiriyor, sorulabilir.
newman
0
newman
Bu gercekten ilginc:
The precise definition of these categories is implementation-defined.
Neredeyse hersey havada gibi :). single-float deyince ben sanki intel makinalarindaki single floattan bahsediyorlar diye dusundum. Herhalde derleyici yazanlarin da oyle kolayina geliyor :).
bm
0
bm
O spec yazilmaya baslandiginda Intel makinelerinde calisan lispi olan biri oturuyor muydu o komitede emin degilim. IEEE 754 filan diyebilirlerdi belki tabii, ama CLTL1 (ilk Common Lisp diyelim) ciktiginda o bile var miydi bilmiyorum. Herneyse, yeterince onu acik o specin bence -- engel olmuyor.
newman
0
newman
Yok, engel olmuyor. Gerci pek bir standard getirdigi de soylenemez :), ama kati bir standard mi, yoksa onu acik olmak mi? Elbette onu acik olmak daha onemli. Hatta bardaga dolu tarafindan bakinca, eger double-float varsa, default single-float'tan daha iyi olmasini da zorunlu kiliyor. Fakat o eksik "at least" yuzunden, bardaga bos yarisindan bakinca, o daha iyi double-float default olamiyor :). Insanoglunu memnun etmek zor kardes ;)
Bu arada IEEE 754'nin temelinde aslinda intel spec'leri yatiyor bildigim kadariyla: sadece detay bazi iyilestirmeler var belki. Bir zamanlar bir assembly kitabinda gordum sanki oyle birseyler.
bm
0
bm
CL-USER> (expt (+ (expt 1782 12) (expt 1841 12)) (float (/ 1 12) 1.0d0)) 1921.9999999558663d0
FZ
0
FZ
CL-USER> (expt 1782 12)
1025397835622633634807550462948226174976
CL-USER> (expt 1841 12)
1515812422991955541481119495194202351681
CL-USER> (+ (expt 1782 12) (expt 1841 12))
2541210258614589176288669958142428526657
CL-USER> (expt 1922 12)
2541210259314801410819278649643651567616
CL-USER> (eq (+ (expt 1782 12) (expt 1841 12)) (expt 1922 12))
NIL
bm
0
bm
Efendim eq eql = ne ise yarar, hangi durumda ayni ise yarar? Bu gunku odevimiz bu. Su ornek yadimci olur niye sordugumu gostermek bakimindan:
CL-USER> (eq (expt 1782 12) (expt 1782 12)) NIL CL-USER> (= (expt 1782 12) (expt 1782 12)) T CL-USER> (eql (expt 1782 12) (expt 1782 12)) T
FZ
0
FZ
Biraz daha kafa karışıklığı serpiştirelim o halde:

CL-USER> (eq (expt 2 4) (expt 4 2))
T
CL-USER> (eq (expt 1782 12) (expt 1782 12))
NIL
bm
0
bm
Valla calisitiriyorsunuz beni bu gece. Genel kural: 'eq'yu numeriklerle kullanmayin calisabilir de calismayabilir de. Fixnum'lar icin calisiyor cunku fixnum'i 'unboxed' olarak immediate saklayabiliyor makine bu durumda. Calismasi sart degil ama sbcl'in oyle isine geldigi icin calisiyor, dil oyle gerektirdigi icin degil. Buna guvenerek kod yazilmaz, buan el hic hic hic alistirilmaz. kitap der ki:

Objects that appear the same when printed are not necessarily eq to each other. Symbols that print the same usually are eq to each other because of the use of the intern function. However, numbers with the same value need not be eq, and two similar lists are usually not identical.

An implementation is permitted to make "copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are "the same thing'' if that thing is a character or number.

FZ
0
FZ


Pandora's unboxed!

;-)
bm
0
bm
Tamam oldu mu is simdi, onu soyle? Cok zor degil aslinda. O box etme isini katmam luzumsuz olmus. Ama madem kattim, niye calisti diye soyleyeyim 'eq' orada adres kontrol ediyor. Fixnumlar icin adresin bulunacagi yere degerin kendisi sigiyor. Onun icin calisiyor. Bignumlar icin calismaz. Bak mesela:

CL-USER> (eq (1+ most-positive-fixnum) (1+ most-positive-fixnum)) NIL CL-USER> (= (1+ most-positive-fixnum) (1+ most-positive-fixnum)) T CL-USER> (let ((foo (1+ most-positive-fixnum))) (eq foo foo)) T CL-USER> (eq (1- most-positive-fixnum) (1- most-positive-fixnum)) T CL-USER>
Aslinda bunlari bilmek gerekmiyor. Sayi icin eq kullanmayin, = kullanin.
FZ
0
FZ
Niye kök almakla uğraşalım ki, üs almak için makineyi yeterince yorduktan sonra ;-)
enginsavsatli
0
enginsavsatli
(çift sayı)^12 + (tek sayı)^12 = (çift sayı)^12 yaklaşımının tutmadığı yerde başka bir yaklaşım daha


Bütün sayının 12. kuvvetini almak yerine sadece son rakamın kuvvetini alınır maksat eşitliği sağlamadığını bulmak değil mi?


2^12 = 4096 Son rakam >> 6

1^12 = 1    Son rakam >> 1

-----------------------+ 7


7  =  6


Bu yöntem de tutmassa makineleri kasabiliriz
skoylu
0
skoylu
İlla LISP kullanacağız diye böyle kasmak, yok eq adresi mi karşılaştırırdı vs. diye koca soru işaretleri ile uğraşmak? [root@opg1 serdar]# python Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> (1782 **12) + (1841 ** 12) == 1922 ** 12 False >>> Buymuş.. Tek tek sonuçlar lazımsa: >>> (1782 **12) + (1841 ** 12) 2541210258614589176288669958142428526657L >>> 1922 ** 12 2541210259314801410819278649643651567616L >>> 1782 **12 1025397835622633634807550462948226174976L >>> 1841 ** 12 1515812422991955541481119495194202351681L >>> LISPMania vakası yani ... LISP Pek iyidir pek hoştur ama, Python ve C varken pek bir gereksizdir maalesef.. Elbet bir yerde, bir şeyde pek bir güzel iş yapabilir, ama istisna olur bunlar...
skoylu
0
skoylu
İlla LISP kullanacağız diye böyle kasmak, yok eq adresi mi karşılaştırırdı vs. diye koca soru işaretleri ile uğraşmak?
[root@opg1 serdar]# python Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
>>> (1782 **12) + (1841 ** 12) == 1922 ** 12
False
>>>
Buymuş.. Tek tek sonuçlar lazımsa:

>>> (1782 **12) + (1841 ** 12)
2541210258614589176288669958142428526657L
>>> 1922 ** 12
2541210259314801410819278649643651567616L
>>> 1782 **12
1025397835622633634807550462948226174976L
>>> 1841 ** 12
1515812422991955541481119495194202351681L
>>>

LISPMania vakası yani ... LISP Pek iyidir pek hoştur ama, Python ve C varken pek bir gereksizdir maalesef.. Elbet bir yerde, bir şeyde pek bir güzel iş yapabilir, ama istisna olur bunlar...
281817 181476855250691 6784756 n
0
tongucyumruk
Hocam yapmayın, illa Common Lisp kullanacağız diye birşey yok. Sadece matematiksel ifadeler yazarken "infix" sözdizimini rahat kullanamadığım, "arbitary precision" hesaplama yapabilen bir hesap makinasına ihtiyacım olduğu ve o sırada önümde SLIME açık olduğu için Common Lisp ile yazdım.

Aslında incelerseniz eq, eql, equal, equalp ve = ayrımı sizin pek bir seveceğiniz cinsten pointer mantığına benzer özellikler sergiliyor ve benzer "pitfall"lara sahip. Dahası sanıyorum bu ayrım Common Lisp'in "kirli" yüzünü daha bir ortaya çıkarıyor.

Son olarak Python kodunuzla ilgili ufak bir detay var. Eğer hesaplamayı sizin dediğiniz biçimde yaparsak Common Lisp'te bu sayıların eşit olmadığını söylüyor. Ancak işlemi yazıda anlatılan biçmde yapıp önce iki sayıyı toplayıp ardından 12. dereceden köklerini alarak 1922'ye eşit olup olmadıklarına bakarsak bakın neler oluyor: 

>>> ((1782 **12) + (1841 ** 12))**(1/12)

1L

#Hmm, burada bir sorun mu var? Ah evet, Python tamsayı bölemiyordu. Floating point kullanmalı

>>> ((1782 **12) + (1841 ** 12))**(1.0/12)

1921.9999999558663

#Şimdi oldu...

>>>
Evet, gördüğünüz gibi floating point kullanırsak Python bize sonucun 1922 olmadığını güzelce söylüyor. Öte yandan zaten Floating point kullandığımızda zaten sanıyorum her dil bize bu sonucu verecektir.

Aslında Python 2.4 ile Decimal adlı bir veri tipi geldi. Ne yazık ki sistemimde Python 2.3 kurulu olduğundan onu deneme şansım olmadı. Sisteminde Python 2.4olan biri bu işlemi bir de Decimal tipi kullanarak tekrarlayabilirse sevinirim.

Son olarak, aslında burada tartıştığımız şey programlama dillerinden bağımsız bir konu. Sorun Python veya Common Lisp veya C değil. Asıl konu temelden ikilik sistemde matematikle ilgili gibi geliyor bana.
bm
0
bm
Dahası sanıyorum bu ayrım Common Lisp'in "kirli" yüzünü daha bir ortaya çıkarıyor.

Sadece onu degil, nispeten yeni ogrenen insanlarin kodlarini biraz tecrubeli insanlarin gormesinin ne kadar onemli oldugunu da gosteriyor. FZ onu yazmasa idi duzeltilme sansi da olmayacakti.

Ayni sekilde Lisp filan ogrenmeye/ogretmeye calisarak yaptigimiz fuzuli isler hususundaki ikazlari nasil alacaktik burada konusmasak?

Kissadan hisse: bol bol yazin.

Eq/=/eql/equal vs.'deki ana fikir pointer degil aslinda, 'object identity'. Bu derin/sig kopyalama probleminde de karsimiza cikar. KMP'den bir kisa makale aklima geldi bu konuda, belki fuzuli islere devam etmek isteyenlere yarayabilir.

FZ
0
FZ
Şimdi burada bir hususu netleştirmekte fayda var. Common Lisp ile ilgili bazı detaylara girildi lakin kullanılan terminoloji, üzerinde durulan kavramlar tabii ki Lisp'e özgü değil. Daha açık söylemek gerekirse boxing / unboxing, shallow copy / deep copy, vb. kavramlar nesneye yönelimli diller olarak tabir ettiğimiz Java ve C# gibi dillerde de gayet kalın hatlarla karşımıza çıkar. "Eşitlik" bu tür dillerde de dikkat edilmesi gereken bir kavramdır. Nesne yönelimli bir dil olan Common Lisp'ten bahsedilirken bu kavramlardan bahsedilmesi bu yüzden doğal görünüyor. Bugün Java, C#, vb. dilleri çalışan, kullanan, öğrenen biri de bu sözcüklerin ve muhabbetin yabancısı değildir.

Benim verdiğim örnek, tamamen benim üşengeçliğim ve kusurumdur, eq deyip geçmiş gitmişim ilk aklıma gelen (hatalı olarak) o olduğu için. Yoksa doğru dürüst Common Lisp anlatan "tutorial" tarzı kaliteli kaynaklarda (misal Practical Common Lisp) bu eşitlik konusu gayet sade, düzgün ve işe yarar şekilde anlatılır. (Okuduğum halde unutmuş olmam yine tamamen bendeki arızi durumla ilgili :))

Benim bu dalgınlığım, saçmalamam nesneye yönelik dillerdeki eşitlik, derin / sığ kopyalama, temsil, vs. konularında bir muhabbeti başlatıp ayrıntılara dair bilgi paylaşımına sebep oldu ise de ne güzel derim. Bunda bir kötülük görmüyorum çünkü. Alışmış olup da eq yerine = kullanıp geçip gitseydim o zaman bu tür bir tartışma belki hiç açılmayacaktı. Eee?
FZ
0
FZ
Bu arada boxing / unboxing, shallow vs. deep copy, "object identity, equality" filan derken Java, C# örneklerini verdim, nesne yönelimli olduğu iddia edilen Python'u düzgün bilen biri de benzer şeylerin Python'da nasıl olduğunu söyleyebilir elbette. (Python lafı geçmiş olmakla birlikte pek deneyimim olmadığı için yukarıdaki yorumumda Java ve C#'a göndermede bulundum.)
newman
0
newman
C ile LISP tamamen farkli amaclara sahip iki dil degil mi? Elma ile armut benzetmesi yapilmisti bir sure once baska bir muhabbette, dogru bence. Bu ikisini karsilastirmak dogru degil gibi. Ne dersiniz?
Python'a gelince, Python'un LISP'ten ustun oldugu (objektif anlamda: hadi subjektif olsun, ona da raziyim) nokta(lar) nedir? Yuksek seviyeli diller olmalari bakimindan bu ikisini karsilastirmak mumkun: yani C ile LISP gibi degil. Fakat, neden Python LISP'i "gereksiz" kiliyor?
skoylu
0
skoylu
LISP, gereğinden fazla kriptik bir dil. Pitfall'ları bir hayli mevcut filan ama, asıl sorun gereksiz yere kriptik kodlama yaptırması. Denecektir, şöyle güzel oluyor, böyle açıklayıcı oluyor.. REGEXP ve PERL içinde aynı şeyler söylenir. Mesele, bunların her zaman akılda tutulması gereken bir acayip yol olması, farkedilmese de acayip tuzaklar ortaya koymasıdır. Asıl önemli olan ise, kitle ve uygulama açısından dillerin hedefleridir. LISP veya PYTHON'un hedef kitlesi profesyonel programlama değildir. OS'tan, SpreadSheet'ine komple bir ürün gamı değildir. Daha ziyade, gündelik olaylara yönelik, orta karar program ve kod yazarlara yöneliktir. Denir şimdi kesin, LISP ile işte şuda şöyle yapılır, böyle yapılır... Yapılmaz diyen yok ki.. Kafası esen BASH ile Assembler Derleyicisi bile yazar. İşte bu hedefleri gözetince, Python sadeliği ile öne çıkar. Aradaki fark budur.
newman
0
newman
LISP'in hedef kitlesini sizin yaptiginiz gibi sinirlayamam. Ama onun hedef kitlesi icinde C'nin hedef kitlesi icnde olmayan bir grup var: Akademi. LISP akademide dogmus ve gelismis bir dildir, bunun da avantaj ve dezavantajlarina sahiptir. Yani "profesyonel olmayan" hicbir tarafi yok LISP'in.
C'nin benim bildigim tek hedefi "assembly programmming made easy"! O da bunun tum avantaj ve dezavantajlarina sahip. Akademide kullanilma sansi ise (OS programming haric) hic yok. Bu iyi veya kotu olarak gorulebilir. Ama onemli olan, C ile LISP tamamen ayri kulvarlarda iki dil. Fakat bu iki kulvar "Profesyonel" ve "Amator" degil...
bm
0
bm
Burada Scheme ile Common Lisp arasinda belki bir ayrim yapmak lazim. Common Lisp aslinda duz anlamiyla akademik kaygilar yuzunden degil, DARPA'nin 'devamli oynayip bin tane lisp turetmeye devam ederseniz artik size para mara vermeyecegiz' demesiyle ortaya cikmis bir dil. Bir acidan bakarsaniz belki o da 'akademik' bir kaygi ama ucu pratige dayaniyor.
newman
0
newman
Maalesef, evet :). Ben LISP'in hedef kitlesini sinirlandirmak istemedim: ancak LISP genellikle akademik cevreden insanlarin (tamaminin degil: yanlis anlama olmasin) tercih ettigi bir dil. Nitekim yukselisi de dususu (kadir-kiymet bilmezler icinde :) --zaten hic kullanmayacaklar icinde degil) de AI ile olmadi mi? Bu demek degil ki LISP sadece AI icindir: ama benim gordugum kadariyla, en azindan tarihsel cercevede AI cok onemli olmus. Son donemdeki reenkarnasyon daha farkli belki, ama basarili olup olmayacagini zaman gosterecek onun.
DARPA olayini bilmiyordum, ama simdi ogrenmis oldum. Ise yarayip yaramadigi tartisilir bence :). "Deve nedir?" diye bir saka vardir hani: "Bir komitenin dizayn ettigi at!" diye :). Bunun en guzel ispati da C++'dir derler. Ben emin degilim; bence pekala Common LISP de olabilir ;). Ama LISP ana hatlariyla bir mucevher benim gordugum kadariyla: Common LISP, veya Scheme, veya baska bir varyant...
Evet acikca yazmak gerekirdi: ben LISP deyince Scheme oluyor aklimda daha cok. Ama acikcasi, kriptik olma meselesinde, ben simdiye kadar brainfuck ve perl disinda kriptik bir dil gormedim :).
bm
0
bm
Bunun kisa bir tarihi http://citeseer.ist.psu.edu/steele93evolution.html da olmali. DARPA o zaman ARPA'ydi galiba, oyle ararsaniz bulursunuz (merakliysaniz).
newman
0
newman
Kesinlikle merakliyim :). Tesekkurler, 80 sayfa birinci elden bir kaynak.
bm
0
bm
Onu sevdiyseniz, Gabriel'in su acik kitabina da bakin:

http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf

(Indiana'daki arkadassiniz degil mi? Oyleyse o kitabin bir kisminda hocalarinizin bazilarinin nasil bir yoldan gecerek hocalik isine basladiklarini anlatiyor gibi de dusunebileceginiz oldukca samimi bir okul tecrubesi kismi da var, belki isinize yarar.)

newman
0
newman
Bu tip yazilar her zaman ilginctir. Cook cok tesekkurler :). Gerci benim bilgisayar bolumuyle tek iliskim, Lindley Hall'deki bilgisayar labinda arada bir email kontrol etmekten ibaret (matematik bolumu ile bilgisayar bolumu komsu binalarda burada), ama akademik hayatin bolum-brans duvarlarini asan birlestirici bir yonu var;). Tekrar tesekkurler.
bm
0
bm
Rica ederim. Hosunuza giderse veya isinize yararsa buraya veya bizim lisp listesine bir not yollayabilir misiniz? Boyle bir suru acik dokuman var, hangisini ne durumda tavsiye edecegini bilemiyor insanlar okuyanlardan ses cikmayinca.
newman
0
newman
Tabii ki, memnuniyetle! Firsat bulup fikir beyan edecek kadar okudugumda bir not duser, ne anladim/ne anlamadim yazarim. Saygilar.
bm
0
bm
Ne iyi! Tesekkur ederim. Steele&Gabriel makalesinin hikayesi icin (ve daha uzun versyonu icin) suraya bakabilirsiniz bu arada:

http://www.dreamsongs.com/Essays.html

(sayfanin ortasinda gibi)

newman
0
newman
Suregelen "Lisp ne icindir?" sorusuna veciz bir cevap olmasi acisindan, sizin bu verdiginiz linkten (sayfa 78) bir alinti yapmak istiyorum. Umarim bu, konu hakkinda ciddi olarak sorusu olanlari, "asil bu dilin onemli isimlerinin aklinda ne vardi, neden bu dil bugun aldigi sekli aldi" noktasinda ikna edecektir.
ALINTI If FORTRAN is the language that pushes numbers around, and C is the language that pushes characters and pointers around, then Lisp is the language that pushes programs around. Its data structures are useful for representing and manipulating program text. The macro is the most immediate example of a program written in a metalanguage. Because Lisp is its own metalanguage, the power of the entire programming language can be brought to bear on the task of transforming program text.
Iste bu kadar! Goruyorsunuz, simdiden isime yaradi: ben kendim bunu sanirim bu kadar guzel ve esasli ifade edemezdim, zaten kimseyi ikna edecek otoritem de olmazdi. Buna ragmen halen "learning curve", "gunluk isler", vs. gibi argumanlar one surulmeden once, bunlarin konuyla ilgisi olup olmadigina bakmak gerekmez mi?
Ilgilenenler yukaridaki mesajda gecen dreamsongs sayfasina bir zahmet gidiversinler.
Bence bu alinti Lisp'in ne icin tasarlandigini guzelce ozetliyor. Evet, Lisp baska isler de yapabilir. Ama Lisp'i gercekten takdir edebilmek icin amaclarina iy bakmali. C deyince herkes amacina bakip degerlendiriyor: kimse onu python ile karsilastirip bu ne bicim sintaks demiyor. Ama Lisp olunca sozkonusu olan isler degisiyor ve bu da dogru olmayan bir hedef ve kullanici kitlesi birligi varsayimina dayandiriliyor. Tabii ki argumanlar boyle temelsiz ve ustelik tutarsiz olunca, oradan baska yerlere gidiyor is. Yakinda Turkce grameriyle Ingilizceyi karsilastirmaya, oradan GNU vs. Evil Northwest Empire, linux vs. windows vesaire tartismalarina baslanirsa hic sasirmayacagim :). Ne de olsa 0=>0, TRUE!
Saygilar.
bm
0
bm
Firsat bulup fikir beyan edecek kadar okudugumda bir not duser, ne anladim/ne anlamadim yazarim.

Harika bir not oldu bu. Tekrar tesekkur ederek ilgili linki vereyim.

FZ
0
FZ
Ben de kendi adıma çok teşekkür ederim. Hilbert uzayları ve orada kullanılan notasyona dair örnek de eğlenceli idi ;-)

Yoruma gelen yorumları takip etmek isteyenler için alternatif linkler:

http://thread.gmane.org/gmane.lisp.region.turkey/710/focus=710

http://comments.gmane.org/gmane.lisp.region.turkey/710
FZ
0
FZ
Bu demek degil ki LISP sadece AI icindir: ama benim gordugum kadariyla, en azindan tarihsel cercevede AI cok onemli olmus. Son donemdeki reenkarnasyon daha farkli belki, ama basarili olup olmayacagini zaman gosterecek onun.

Doğru, son yıllardaki etkinliklere, kitaplara ya da büyük CL şirketlerinin protföylerine, başarı öykülerine baktığımızda özel olarak yapay zekâya yönelik bir şey görmüyoruz:

Franz Inc. Customer Applications

International Lisp Conference 2005

European Common Lisp Meeting 2005

European Common Lisp Meeting 2006

3rd European Lisp Workshop - 2006

International Lisp Conference 2007

Practical Common Lisp

Successful Lisp

Yukarıdaki etkinliklere, projelere, kitaplara bakan kişiler ortada pek bir yapay zekâ görmeyecekler. Sadece akıllı insanların karmaşık problemlere kısa sürede getirdikleri akıllıca çözümleri görecekler. Bu arada "lambda" lafına bazıları fazla takılıyor, neden bu bilmiyorum mesela yukarıda bahsi geçen ve kamuya açık Practical Common Lisp kitabında Peter Seibel lambda'dan sadece önsözde ve ilk bölümde bahsediyor hatırladığım kadarı ile ;-)
FZ
0
FZ
Korkup kaçmayanlar da var demek ki yukarıdaki listeye bakınca ;-)
skoylu
0
skoylu
FZ, mesele şu. Etrafımda C ile koca koca kodalr yazan elemanlar var. LISP koduna bakınca, "Amaney.." derlerken, Python koduna bakınca, aynı tepkiyi vermiyorlar. İşte mesele bu. Nedendir bilsem, izah ederim ama. inan bilmiyorum. Bana sorarsanız, C derim, çay içmeye giderim, tartışmam bile ötesini aslen..
FZ
0
FZ
Üslup bu olunca (etrafımdaki adamlardan yola çıkarak genelleme yapmak...) ben de çay içmeye giderim orta şekerli. Gitmeden önce de bir C programcısının yorum satırlarını paylaşmak isterim ;-):

/* I can't stand it anymore! Please can't we just write the whole Unix system in lisp or something? */
newman
0
newman
Yaa, nedense bu kolaydi, zordu tartismasi oldukca ragbet gordu: "lambda" lafini gorunce insanlarin kilcik cikarmasina da sasirmamak lazim :). Ama insanlar degisik onceliklere sahip: bu tip terimleri acik etmesi, siradisi gorunmesi, dogup gelistigi ortam, zeka piriltilari ile dolu tanitici kitaplara konu olmasi vs. bir dili bana cekici yapan unsurlar. Kolaylik/zorluk meselesini insan ilk programlama dilini ogrendigi zaman artik geride birakmalidir. Benim icin bu Pascaldi. Ne yani, simdi dillerin ne kadar erdemli olduguna Pascala ne kadar yakin olduguna bakarak mi karar verecegim simdi? Ortaya atilan argumanlar da tamamen subjektif, kendi icinde celiskili; sanki bir dakika once soylenenin bir sonra soylenenle hicbir baglantisi yok.
Neyse, nereden geldim buraya?!: Lambda dedin de oradan :) Sadece SICP'nin kapagindaki lambda bile Lisp'in hedefinin gunluk isleri halletmekle sinirli oldugu savini oldurmeye yeter. Sussman'in videolarina soyle bakan bir arkadas, o adamin oyle gunluk islerin adami olmadigini gorur!
Ben disaridan bakan biri olarak, assembly duzeyinde kod yazabilmek vs. bana ilginc gelmiyor. Ilginc olan ve bana gore programlamanin esasi, fikirleri oradan evrilebilecekleri bir formda organize ve sistematize edebilmek. Iste bu Lisp'in cekici yonu: bunu C, python, vs. nin yapmadigi sekilde vurguladigi (benim anladigim kadariyla) dil oldugu icin Lisp.
Lambda dedin de oradan cikti bunlar :)
rickdangerous
0
rickdangerous
Python kolay olduğu ve yeni başlayanlara uygun bir dil olduğu o kadar çok tekrarlanıyo ki insanlar bunu sorgulanamaz bir gerçek gibi kabulleniyorlar. İşin aslı python belki doksanlı yıllarda özellikle de Perl gibi bir dille kıyasla kolaydı. Anak geçen yıllar içerisinde büyüdü ve karmaşıklaştı. Bugün Python'a kolay bir dil diyen ya dili bilmiyordur ya da bilinçli dezenformasyon çabası içindedir. Bunun böyle olduğunu düşünüyorum çünkü tam üç defa python öğrenmeye çalıştım ve tam anlamayadığım noktaların çokluğu nedeniyle bundan vazgeçtim. Hepsini açıklamam olanaksız ama bazı sebepleri sıralamaya çalışayım:

1- Standart kütüphanesine bakalım. Bazı modüllerde açıkça kullanılmaması gerektiği içsel kullanım için olduğu veya eskidği falan yazılı. Sadelikten uzak belki, 3-4 tane dbm türevi için modül var. İçinde aradaığınızı bulmanız için tecrübeli olmanız gerekiyor.
2- Tip karmaşası. Tuple tipi nedir? Biri bunu yeni açıklayan birine açıklasın. Sakın sadece okunabilir dizidir falan demeyin Tuple'ın ne CS terminolojisinde anlamı ne de GvR'nin dile koyma sebebi budur. İşin aslı Tuple tipinin ne amaçla konduğunu gerçekten bilen Python programcısın fazla olduğunu sanmıyorum.
3- Lisp kötülenirken gözden kaçırılan ortaklıklar. Örneğin değişken değerlerinin somut nesnelere referans olması. Bu yüzden assignmentlarda bir veri yapısı kopyalanmak yerine başka bir referansı alnıyor. Bu karmaşık veri yapılarında hatta basit liste işlemlerinde yeni başlayanlara pek çok sürpriz yaratır.
4-Dile özgü geçmişten gelen gariplikler. Örneğin python FAQ'da geçer bir değişkene verdiğiniz default değer her seferinde başta yaratılmak yerine ortak olarak kullanılıyormuş (ya da böyle bir şey). Açıklamasını anlamak bile vakit alıcı ve bunu bilmiyorsanız çok da kolay can yakacak bir şey.
5- Python'un kendine özgülüğü. Python hangi dile benzer? Örneğin Ruby'nin kullanımı Smalltalk'a benziyor ama Perl programcısı da yabancılık çekmeyecektir. Hatta aynı Java diyen insanlar bile gördüm. Sonuçta bunlar öznel yargılar fakat başka dillere aşinalık derecesi Python için bayağı düşük.
6- Gereksiz kullanım zorlukları. Konulması zorunlu self parametresi ve self'in her member erişimde kullanım zorunluluğu. Kolay bir dil için ilginç bir dizayn seçimi.
7- Fonksiyonel programlamayı destekler gibi yapması fakat önünde zorluklar çıkarması. Bir kere map, lambda gibi şeyleri ya doğru düzgün destekleyin ya da tamamen dilden çıkarın ikisinin ortasında durmak yeni başlayanların sadece kafasını karıştırır.
8- Profesyonel yazılımcıların kendileri için gerçekleştirdiği dillerin kolay kullanımlı olmasının imkansızlığı. Bu dilleri geliştiren insanlar belirli birikimleri olan belirli teknikleri bilen eğitimli insanlar. Bu insanlardan yeni başlayanlara dost bir ortam beklemek Python gibi her yeni sürümde özellik eklenen bir dil için saflık olur.

Sonuç olarak evet Python Perl'e ve C'ye göre kolaydır. Ancak bu Python'un kolay olduğu anlamına gelmiyor. Yeterince özelliğe sahip ve geçmişi her dilin karanlık köşeleri ve geçmişten gelen sıkıntıları olur; Python da artık geniş özellikli ve eski bir dil ve bunlar aslında iyi nitelikler (kısacası artık doksanlardaki basit ve sade dil değil). Bana hangi dillerin kolay olduğunu sorarsanız cevabım hala BASIC, Pascal ve (continuation gibi kavramları dışarda bırakmak şartıyla) Scheme olur.
innaw
0
innaw
> İşin aslı python belki doksanlı yıllarda özellikle de Perl gibi bir
> dille kıyasla kolaydı. Anak geçen yıllar içerisinde büyüdü ve
> karmaşıklaştı.

Sizce hangi yeni özellikleri Python'u "büyütmüş" ve "karmaşıklaştırmıştır"? Yanlış anlamayın, yalnızca öğrenmek için soruyorum. Teşekkürler.
rickdangerous
0
rickdangerous
Burda anlatmaya çalıştığım şey "Python öğrenmesi ve kullanması kolay bir dildir" etiketinin geçmişten kalma günümüzde eski geçerliğlini yitirmiş bir etiket olması. Python'a çok zor veya aşırı karmaşık demiyorum ancak iddia edildiği gibi çok kolay ve yeni başlayanlar için, ilköğretim seviyesi için vb. ideal bir dil olduğuna katılmadığını söylüyorum. Python doksanlarda nasıldı diye merak ediyorsanız webde yeterince bilgi bulabilirsiniz sanıyorum.
skoylu
0
skoylu
İlköğretim öğrencisine S-Expressionlar öğretmek çok daha kolaydır değil mi?

Hiç bir programlama dili kolay değildir. Veya hepsi de çok kolaydır. Çünkü aslolan programlama dili değil, programlama pratiğidir. Bir idlin kolay/zor olduğu, kullanan adama bağlıdır. Eğer bir sayının CPU'nun hnagi registerinde nasıl saklandığı, nasıl toplandığı vs. ile ilgilenmek istemiyorsanız, bunları filan sizin için yapan bir dil ararsınız. İşte o noktada, Python biraz daha yalındır. Aynı şey kod içinde geçerlidir.

Mesele şudur. LISP (Scheme vs.) gibi dillerde öğrenme eğrisi önce diktir, sonra giderek yatay olur, öyle devam eder. Pythonda, eğri en başta daha az diktir. Daha ötede diklik önce azalır, sonra yokuştan, inişe geçer, sonra tekrar düzelir, tekrar yokuş olur, dalgalana dalgalana gider. C için bu eğri başlangıçta 90 derecedir, bir süre sonra hızla yataylaşır ve yatay olur. Ardından ortadan kaybolur, artık öğrenecek bir şey kalmamıştır, elbette nefesiniz yetip te, o yere ulaşabilmişseniz.. İşte LISP'in dezavantajı bu noktadadır. İşin başındaki adam için daha zordur mesele. Ama belki, uzun soluklu bir yolculuk düşünülüyorsa, LISP daha avantajlı da olabilir, bu biraz öğrenmek isteyene vs. kalmış..
rickdangerous
0
rickdangerous
Lisp Python kıyaslaması yapmıyorum. Öğrenme eğrisi gibi kavramlarla tartışma yapmaya da niyetim yok. Sadece kolay dil deyince BASIC, Pascal ve (ileri özelliklerini daha sonraya saklamak şartıyla) Scheme anladığımı yok illa Python kategorisinde bir şey seçmem gerekiyorsa da farklı dillere aşinalığı arttırma özelliğiyle, zarif dizaynıyla ve kendi fikrime göre zihinde modellenmesin bu yüzden de öğrenilmesinin ve kullanılmasının kolay olduğunu düşündüğüm Ruby'yi anlarım. Python'un kolay olmadığını, yeni çıkacak Python sürümünde gelecek özellikleri anlamak için ileri CS konularını içeren sitelere bakmak durumunda olmanın neresinin kolaylıkla bağdaştığını anlamadığımı da eklemek isterim.
rickdangerous
0
rickdangerous
Yanlış anlaşılmaması için özellikle vurgulamak isterim, ilköğretim öğrencisi için ne Ruby uygundur ne de Python, sanıyorum Scheme'de bayağı sulandırmadan o seviyedeki öğrencilerin öğretimi için kullanmak zordur. Ancak öğretim gibi derin bir konuda fikir öne sürmek yerine sadece, Ruby'yi veya Scheme'i bu seviyede _önermediğimi_ vurgulamak isterim.
rickdangerous
0
rickdangerous
Bu arada, Python kolay değil Scheme kolay deyince ister istemez bir Lisp Python kıyaslaması oluyor haklısınız :) Aslında kolay diller listeme Scheme'in girmesinin sebebi Scheme'in minimalistliği, zarifliği; pratik kullanım için tasarlanmamış ancak sonuç olarak zarifliğiyle pratik kullanıma da uygun bir dil ortaya çıkmış. Dili kuralları nispeten az ve öz, kolay öğrenilmesinin sebebi bu. Kolay öğrenilmesinden de öte az miktarda olan bu kurallar bazı konulara uyanmanıza yardımcı oluyor. Ancak işte Scheme belirli bir uç noktayı temsil ediyor yoksa zaten Python veya Ruby zaten Lisp ailesinden dillere pek çok benzerlikler taşıyorlar. Kolaylık konusunda ise Scheme'e ayrı bir yer vermek lazım kanımca...
skoylu
0
skoylu
Aslında bu cevap bir hayli offtopic olacak ama..

1. Standart kütüphanesinde obsolete olmuş veya birden fazla instance'a sahip kütüphaneler var. Doğru. Peki hangileri? Sizi mesela smtplib yerine rfc822 library kullanma konusunda mı zorluyor? Bu kütüphanler gerçekten şu mu olsa, bu mu olsa dedirten türden mi? Evet, 3-5 tane DB kütüphanesi var. Ama özel gerekleriniz yoksa, herhangi birini alır, open/var['key'] = value şeklinde kullanırsınız. Obsolote olanları kullanmak sakıncalı mı? Hayır, ama yenileri daha iyi yazılmış, neden bu dezavantaj olsun ki? Bazı modüller içsel kullanım içinse, kullanmazsınız olur biter.
2. Tuple tipi nedir? Pythonda bir değişken bir değer değil, bir değerler dizisine referans tutarlar. İşte bu bir tuple'dir. a = 1 dediğiniz zaman, a değişkeni, (1) tuplesine bir referanstır. List ve sekanslar ise özel nesnelerdir. Peki, kabul, karışık bir iş diyelim. Siz Tuple kullanmaya zorlayan bir şey var mı? Ben genelde kullanmam, hiç bir zamanda aman aman bir ihtiyaç görmedim kullanmak için..
3-4. Python dilinin mevcut halinin asıl özelliği bu zaten. Python için tüm değerler bir nesne ve değişkenler bu nesnelere bir referans. Bu python ile uğraşan için bilinmesi, öğrenilmesi gereken, çok iyi tarif edilmiş bir durum. Elbette benzer sorunlar LISP'te, C'de vs. de var. Oysa Python'da değişken kavramı izah edilirken bu net bir şekilde ortaya konur. Bu da dilin açık bir avantajıdır. Bir şeyler referans iken, başak bir şeyler değer olmaz. Her şey her zaman referanstır. Bu da olası çelişkileri önler..
5. Python'un herhangi bir dile benzemesi gerekiyor mu? Eğer bir dil üzerind eyetkinseniz, neden Python vs. aramaya gidiyorsunuz? Eğer bilinen bir dile benzerlik bir kıstas olsaydı, C# veya Java ahanda en iyi dil denmesi gereken şeyler olurdu. Ama öyle diyemiyoruz..
6. Self parametresi, bulunduğunuz nesneyi nesne içersinden sürebilmek için kullanılır. Fakat bunun nesi kötüdür anlamış değilim. Bir yanlış şu. Nesneye yönelim, Nesneler ve/veya C++/Java/SmallTalk vs. nesneleri birbirine karıştırılıyor. C++ nesnesi, bir takım kendi özelliklerine, tanımlarına sahiptir. Python nesnesi de öyle. Java nesnesi de öyle. Bunların birbirinden farklı bir set ile tanımlanması nasıl bir dezavantaj olabilir ki? Haa, derseniz ki, ben Java bilirim, oradaki Class'ın karşılığını Python'da isterim.. Yok böyle bir şey. Java nesnesi ile C++ veya X dilinin nesnesi hemen hemen denk işler yapabilir, ama implemantasyonun aynı olması gerekmez. Bu şekilde bakınca, self'in mecbur olmaması bir sorun olarak algılanabilir daha hatta, diğer diller için..
7. map, lambda gibi şeyleri kullanmak veya kullanmamak size kalmış.

Gördüğüm kadarıyla, bir bahane bulayımi amanda Python şöyledir diyeyim kaygısıyla yazılmış bir post olmuş maalesef. Mesela, python'un en büyük zaafiyeti, değişkenlerin global scope'tan erişilebilir olmasıdır. Bu çok baş ağrıtabilir, çok canlar yakabilir. Ama mesela bu mevzudan bahsedilmiyor.

Genelde yapılan, diğer dillerdeki bazı alışkanlıkların Python'da bekleniyor olması. Bu yanlış olur. Bende çıkıp neden pointer yok, neden struct kullanamıyorum (native yoldan) vs. diyebilirim. Ama bu haksızlık olur.

Burada mesele edilen konu, sadelik, yalınlık filan feşmekan değildir. Mesele, hesap makinesi pozisyonundan öteye geçip, algoritma kurmaya başlayacağınız noktada önünüze çıkacak olan meselelerdir. Bu noktada Python gerçekten kolayca baş edilebilecek bir dildir.

Bu tür, yanlış eleştirileri her dil için yapabilirsiniz. Çünkü yaptığınız şey, o dili diğerlerinden ayıran sistematiği eleştirmek. Bu lsitedeki parametrelerin hiç biri, yeni başlayan bir programcı için ayak bağı olacak, zorluk çıkaracak vs. bir şey değil. Ancak, bir vakit BASIC ile uğraşmış birisine bu liste anlamlı gelir. Ama yeni başlayan gittiği her dilde bu yapıları dile özgü haliyle öğrenecektir zaten eli mahkum.

rickdangerous
0
rickdangerous
* 1. Standart kütüphanesinde obsolete olmuş veya birden fazla instance'a sahip....

Yeni başlayanların işini zorlaştıran şeyler bunlar aradığı şeyin nerde olduğunu bilmeyen biri bütün bu kirlilikle mücadele etmek zorunda.

* 2. Tuple tipi nedir? Pythonda bir değişken bir değer değil, bir değerler dizisine....

Tuple'ın dilde bulunmasının nedenin bu olduğunu sanmıyorum. Sanırım sizde Tuple neden var sorusunun yanıtını tam bilmiyorsunuz çünkü açık bir yanıt vermemişsiniz. İşin daha acı yanı Tuple ne için kullanılır anlamıyorsanız kullanmayın demek. Bu şu anlama geliyor Python'u tamamen anlayamazsınız ama bir şekilde Python kullanıyorsanız (zorundaysanız veya öyle istiyorsanız) Python'la iş görebilirsiniz. Kullandığı dili bilmeyen programcılar neslinin oluşmasına neden olmaz umarım bu yaklaşım.

* 3-4. Python dilinin mevcut halinin asıl özelliği bu zaten...

Herneyse 3 ile 4'ü birleştirmişsiniz ama bunların birbirleri ile ilişkisi fazla değil. Daha doğrusu değişkenlerin referans tutması default argüman değerinin bir kez evaluate edilmesini gerektiren bir şey değil kesinlikle. Örneğin Ruby'de böyle değil. Direk Python tutorial'a baktım çok sık kullanılabilecek bir kod örneği vermiş, işte bir diziye bir değer ekle (ya da başka bir işlem önemli değil) dizi parametresi verilmediyse boş dizi kullan. Sonra uyarılar vermiş workaround falan vardı FAQ kısmında eskiden şimdi bakmadım. Sonuçta tamamen dilin o konuda anlamsız dizaynı, eğer ben state saklamak istesem bunu neden default argüman'da yapayım? Nesye uzatmayım dili öğrenirken, kullanırken başına iş açacak potansiyel mayındır bu tip gariplikler.

* 5. Python'un herhangi bir dile benzemesi gerekiyor mu?...

E, çok iyi olur. Çoğu insan birden fazla dil öğrenmek durumunda kalıyor. Benzerlikler öğrenme sürecini oldukça kolaylaştıracaktır.

* 6. Self parametresi, bulunduğunuz nesneyi...

Asıl eleştirim metodlarda ilk parametre olarak self (tabii kafa karıştırmak isterseniz kendim falan da yazabilirsiniz) kullanılmak _zorunda_ olması. Ayrıca yine member erişimlerinde yine aynı sıkıcı kelimeyi kullanmanız lazım hep. Tekrar kötüdür, sıkıcıdır. Hadi görmezden gelelim bunu ne de olsa mükemmel dil yoktur diyoruz.

7. map, lambda gibi şeyleri kullanmak veya kullanmamak size kalmış...

Yine aynı noktaya geldik: anlamıyorsan anlama, dili iyi bilmek zorunda değilsin noktası. Ya yeni başlayan arkadaşın önüne map ve lambda kullanan kod gelirse? Ya da madem python kolaylıklar dili neden lambda'da bu gereksiz sınırlamalar var?

* Gördüğüm kadarıyla, bir bahane bulayımi amanda Python şöyledir diyeyim kaygısıyla yazılmış bir post olmuş maalesef.... mesela bu mevzudan bahsedilmiyor.

Hayır böyle bir derdim yok. Sadece uzun bir listeden o anda aklıma gelenleri yazdım. Uzun zamandır Python'la uğraşma ihtiyacı hissetmiyorum zaten, belki ihtiyacım olsa rehine pisikolojisi içerisinde sevmeye bile başlardım Python'u :) Ancak benden bu kadar siz listeyi daha da uzatabilirsiniz eminim.

* Burada mesele edilen konu, sadelik, yalınlık filan feşmekan değildir. Mesele, hesap makinesi pozisyonundan öteye geçip, algoritma kurmaya başlayacağınız noktada önünüze çıkacak olan meselelerdir. Bu noktada Python gerçekten kolayca baş edilebilecek bir dildir.

Tabii bilmediğiniz şeyleri atlayarak, sevmediğiniz şeyleri görmezden gelerek iş görebilirim diyorsanız buyrun kullanın zaten hiç bir zaman Python çok zor bir dildir demedim ki. Ama çok zor olmaması kolay olduğu anlamına gelmiyor.

* Bu tür, yanlış eleştirileri her dil için yapabilirsiniz. Çünkü yaptığınız şey, o dili diğerlerinden ayıran sistematiği eleştirmek. Bu lsitedeki parametrelerin hiç biri, yeni başlayan bir programcı için ayak bağı olacak, zorluk çıkaracak vs. bir şey değil. Ancak, bir vakit BASIC ile uğraşmış birisine bu liste anlamlı gelir. Ama yeni başlayan gittiği her dilde bu yapıları dile özgü haliyle öğrenecektir zaten eli mahkum.

Eleştirilerim eksik olabilir ama yanlış olduklarını sanmıyorum. Ama son cümleniz gereçekten hoş olmuş. Eli mahkum bir şeyleri öğrenmek zorunda kalmak Python için de geçerli madem biz boşuna tartışmayalım o halde.
rickdangerous
0
rickdangerous
http://blog.philkern.de/archives/177-First-SoC-status-report-Reportbug-Gnome2-GUI.html
Debian hata raporlama aracını yazan arkadaş Python ve Ruby karşılaştırması yapmış. Sadece blog girdisine değil alttaki yorumuna da bakın lütfen.
Not: Ruby'nin yeni sürümü native thread desteğine sahip olacak.
yilmaz
0
yilmaz
Bir programlama dili mevcut bir probleme getirdiği yaklaşım sebebiyle vardır. X dili ile yapılan bir işi Y dili de aynı şekilde yapıyor ise Y dili bir işe yaramaz. O yuzden python java c++ vs.. var. O yuzden dilleri birbirleriyle karşılaştırmak çok saçma.
Bir dil oluşturulurken "aman millet kolay öğrensin" gibi birşeyin düşünüldüğünü sanmıyorum.
rickdangerous
0
rickdangerous
> O yuzden dilleri birbirleriyle karşılaştırmak çok saçma.

Kesinlikle aynı fikirdeyim. Karşılaştırma pek anlamlı değil ama belirli bir dil üzerinde konuşmak mümkün tabii.

> Bir dil oluşturulurken "aman millet kolay öğrensin" gibi birşeyin düşünüldüğünü sanmıyorum.

Hayır bunların düşünüldüğü diller var ve olmalıdır. Programlama eylemi farklı kesimler tarafından gerçekleştirilebilen bir şey olmalıdır. Ayrıca kimin için kolay? Programlama bilen biri için mi kolay, yeni başlayan biri için mi kolay? Bunların ayrımı yapılmadan yukardaki gibi bir ifade kullanmak pek manalı değil. Bu yorumlarda genellikle programlama bilmeyen veya yeni başlamış biri açısından bakıldı hep. Bu insanlar için Python kolay dendi ben de hayır Python kendi halinde, benzerlerine kıyasla ortalama bir dil, kolaylık açısından büyük artılar taşımıyor düşüncemi ifade ettim. Derdim herhangi bir dili küçümsemek değil sadece yanlış önyargılar oluşmasını önlemek. Keşke söylendiği gibi hem kolay hem yetenekli olsaydı sonuçta özgür yazılımın başarısı hepimize fayda sağlar.
skoylu
0
skoylu
Mesele sizin eleştirileriniz doğrudur, değildir ile sınırlı değil. Bir programlama dili öğrenecek, kullanacaksınız bir şeyler önünüze çıkacak. bu kaçınılmaz. Ama sizin eleştiri koyduğunuz hususlar, keyfe keder vermekten öte olmayan, dile ve öğrenim sürecine doğrudan yönelik olmayan hususlar. Öğrenim süreci, statik bir süreç değildir. Veritabanı kullanmayı öğrenmekle, toplama yaptırmayı öğrenmek aynı süreç değildir. Benzer şekilde, siz bu süreçte minör öneme sahip hususları öne çıkarmaya çalışıyorsunuz. Örneğin, ilk maddeniz. Diyorsunuz ki, obsolote olmuş modüller var. vs. vs.

İşte standart modül listesi:

http://docs.python.org/modindex.html

Bir söyleseniz, hangileri obsolete/deprecated olmuş modüller? Veya hangiileri birden fazla iş yapan modül? Mesela ben birini söyleyeyim: rfc822. Bu deprecated, yerine email kullanın denir.

Şimdi bakalım, bu modül ne iş yapar?

e-mail mesajlarını parse etmek için kullanılır. Peki, sizce böyle bir işe kullanıcı ne zaman kalkışır? Böyle bir işe kalkışınca, python kullanmaya karar veririse bu modülü kullanması ne zorluk çıkarır. Ya görecektir, "ls -al /usr/lib/python" yapıp, basacaktır import diyerek, yada bu adresi bulup kullanacaktır. Ve bu modülle ilgili dökümantasoynda, ilk karşınıza çıkan şudur:

http://docs.python.org/lib/module-rfc822.html

Deprecated since release 2.3. The email package should be used in preference to the rfc822 module. This module is present only to maintain backward compatibility.

Eee, o halde, kafa karıştıracak bir şey var mı? Her halükarda bu modülü kullansanız ne sorununuz olur? Diyelim adamımız RTFM denmesi icap eden biri. ls ile buldu modülü, import dedi açtı. Kullandı.. Ne olur, işini yapamaz mı olur?

Benzer sorunlar bırakın dilleri ve kütüphaneleri işletim sistemlerinde vs. heryerde mevcuttur. Bu pythona veya BASIC'e özgü bir şey değildir. Ve işin asıl tarafı, tüm dillerde karşınızda olan sorunları listeliyorsunuz. Olayın özüne bakarsanız, bu saydıklarınız python'un sorunu değil sadece. Bu yüzden hatalısınız. Söyledikleriniz, farklı cümlelerle farklı diller içinde söylenebilir ve genel sonuç aynı çıkar.

LISP için, özelleştirelim Scheme için, benim ortaya koyduğum dezavantaj kriptik olma halidir. En basit yönden "#t", "#f".. Yahu, bunu apaçık "True/False" yapsanız ne olurdu ki? Ha bunun şifresini çözdünüz mü, ötesinde her şey güllük gülistanlıktır, ama önce önünüze çözülmesi gereken bir şifre çıkar işte.

Bunun dışında LISP/Python vs. tartışması etmek abes olur. Bugün ciddi bir uygulamayı, diyelim LISP ile 150.000 satır ve 16 ayda yazdınız. İnanın aynı şekilde, Python ile de 150.000 satır ve 16 ay, ve belki hayda diyeceksiniz ama, C ile de 16 ay ve 150.000 satır ile yaparsınız. Uygulamaların çapı, gerekleri arttıkça, diller arasındaki avantajlar giderek azalmaya başlar. Ve profesyonel bir programcı dediğim insanların karşısına böyle kodlar bolca çıkar.
newman
0
newman
LISP için, özelleştirelim Scheme için, benim ortaya koyduğum dezavantaj kriptik olma halidir. En basit yönden "#t", "#f".. Yahu, bunu apaçık "True/False" yapsanız ne olurdu ki? Ha bunun şifresini çözdünüz mü, ötesinde her şey güllük gülistanlıktır, ama önce önünüze çözülmesi gereken bir şifre çıkar işte.
Bu argumana katilan olur mu bilmiyorum. Ama sizin bu yazdiklariniz uzerine, en azindan DrScheme ve MIT Scheme'de bir bakayim dedim: Ikisi de true/false (maalesef True/False degil :) degerlerini bir tanimlama yapmaniza gerek kalmadan taniyorlar. yani endise edilecek birsey yok, dili ogrenmeden kullanmaya kalksaniz bile takilacak baska bir nokta bulmak gerekiyor ;).
bm
0
bm
R5RS scheme ise tanimamasi lazim herhalde. Denedim de:
Language: Textual (MzScheme, includes R5RS). > false . reference to undefined identifier: false > #f #f > true . reference to undefined identifier: true > #t #t >
Ben Scheme'e ellemeyeli cok oldu, birseyi mi yanlis yapiyorum?
newman
0
newman
Yok, yok. Ama Scheme tamamlanmis bir seruven degil ;). Benim icin de Scheme gibi minimal bir dilin standardi (bu arada, R5RS Common Lisp gibi enternasyonel gecerliligi olan bir standard da degil) 1) Acikca yasakladigi konularin dilde yer almamasi 2) Acikca gerekli kildigi ozellilerin de dilde olmasi acilarindan onem tasiyor. Scheme'in daha alacagi yol var: Common Lisp, C, C++ tipi standardlastirmak bu tip bir dil icin uygun degil bence.
Sadece yapilan elestiriye gore cevap :). Yoksa tanimamasi normal. #f veya #t neymis diye bakmaya tenezzul etmeyen zaten R5RS'e hic bakmaz :).
rickdangerous
0
rickdangerous
Bu modül konusuna takılmayalım. O liste kabaca hazırlanmış bir listeydi herhangi bir dili hedef almak gibi bir niyetim olmadığı için ayrıntılı bir liste de hazırlamadım. Ama hala standart kütüphanenin güya kolay bir dil için fazla "kirli" olduğunu düşünüyorum. Daha önce de belirttiğim gibi önemli olan özgür yazılım olması. Python ile bir derdim yok sadece yanlış önyargılar oluşmasına neden olacak "propaganda"ya karşı mücadele ediyorum. Ne yazık ki bazı diller bir "dünya hakimiyeti" peşinde koşuyorlar. Python camiasını izlemeye çalışıyorum. Örneğin Rails'e karşı propaganda yapmak gibi çabaları enteresan olduğu kadar yanlış buluyorum. Çünkü Rails "iyi" olduğu için isim yaptı; PR ile değil. Bırakın özgür yazılım başarı için uğraş versin neden yapay ayrımlar yaratmaya çalışıyorsunuz? İşin aslı Rails'in başarısından sonra Python'un bu standart dil olmayacağı iyice belli oldu çünkü pogramlama dünyası web programlama ekseninde dönüyor (açmam gerekirse, zincirleme bir reaksiyondan, kritik kitleden falan bahsediyorum. Elbette herkes web programlama yapmıyor).

Scheme'in #t #f meselesine gelince bu bazı Python fanatiklerinin başka dillere nasıl da kolayca kulp taktıklarına güzel bir örnek olmuş. Python kendi doğrusundan başka doğru tanımıyan ve sonuç olarak rekabet gücü düşmüş bir özgür yazılım programlama ortamı yaratma tehlikesini beraberinde taşıyan bir çeşit uzak durulması gereken tehlike olarak kendini gösteriyor (abartıyorum tabii, fanatizm fanatizmdir, nesneyle doğrudan bir ilgisi yoktur elbette).
newman
0
newman
Abartmayalim derim ;). Bu biraz atese korukle gitmek gibi olmus.
skoylu
0
skoylu
Valla, bu listede yazanlara bakınca, en çok LISP kullanmış, halada bil fiil kullananda benimdir sanıyorum. Ama propagandist yaklaşımlarınızla beni bile LISP'ten soğutacaksınız. Doğrusu, #t'dir veya True'dur diyen var mı? True ve False, sezgisel olarak daha kolay erişilebilir. Ama #t için, bilmek ve akılda tutmak gerekir. Sorun hangisinin doğru olduğu değildir. Sorun böyle yapmanın daha kriptik bir syntax ve ürkülen bir hal ortaya çıkardığıdır.

Kimsenin burada doğrusu şudur budur dediğini hatırlamıyorum. Ama siz, güya bizleri doğrularımızı dikte etmekle itham ediyorsunuz. Bir "doğru" şudur ifadesi kullanmadığım halde, böyle bir ithamda bulunuyor olmanız düşündürücü..

Kaç sınıfa, elinize tebeşir alıp LISP öğretmeye çalıştınız? Ve Pyhton, BASIC, COBOL vs? Ben defaten çalıştım. En son 2003'te bir grup MYO Bil.Prg. öğrencisine PHP/Python gösterdim. Ama niyetim LISP öğreteyimde adam gibi bir iş olsundu. Fakat olmadı. İşte bu ve benzeri kriptik yaklaşımların insanları dilden ittiğini bizzat gördüm, yaşadım. İşte o tecrübelerden yola çıkarak bunu söylüyoruz, siz ise, alakasız bir şekilde ithamlarda bulunuyorsunuz..
rickdangerous
0
rickdangerous
Fanatik sözcüğünü itham etmek maksadıyla kullanmadım. Kullanmamın sebebi Python'a benzer örneğin Ruby veya biraz daha kısıtlı bir kullanım alanına sahip da olsa Lua gibi diller mevcutken neden sadece Python'dan bahsediyorsunuz? Bu tek tarafalı bakışı eleştirmek için kullandım fanatik kelimesini. Deseniz ki örneğin Lisp zor ama Python/Ruby/Lua kolay, itirazım farklı şekilde olurdu.

İtiraz ettiğiğm ikinci nokta dilin sentaksının aşırı derece ön plana çıkarırılıyor oluşu. Bu yaklaşımı sadece sizde değil dediğim gibi başka Python programcılarında da gördüm. Sentaks ne öğrenmeyi ne kullanmayı bu kadar fazla etkiler. Okunabilirliği asıl etkileyen dilin soyutlama mekanizmalarıdır. Öğrenilebilirliği asıl etkileyen dilin zihinde modellenme kolaylığıdır. Bu iki alanda da Python'un burda adı geçen dillerin çoğundan daha iyi olduğunu düşünmüyorum.

Lisp kullandığınızı fakat öğretemediğinizi ifade ettiniz. Ama hangi Lisp'den bahsetttiğinizi bile yazmamışsınız. Lisp bir dil ailesinin adıdır. Scheme, Common Lisp, Emacs Lisp ve diğerleri gibi bu aileye mensup az ya da çok birbirinden farklı diller var. Ayrıca kötü örnek örnek kabul edilmez; belki sizin öğretme metodunuz yanlıştı? Bazı üniversitelerde programlamaya giriş dersinde Scheme kullanılılıyor; bunun bir anlamı yok mu?
FZ
0
FZ
Lisp dil ailesinin meşhur ve en yaygın kullanılan üyelerinden Scheme ile programlama öğreten üniversiteler, kolejler ve liseler: http://www.schemers.com/schools.html.

Türkiye'den aklıma gelen örneklerden biri, Bilgi Üniversitesi'nin Bilgisayar Bilimleri müfredatında programlamaya giriş dersleri olan Comp 111 ve Comp 112 (2 yıldır Scheme ile veriliyor dersler ve programlama ile daha önce uğraşmamış pek çok genç alıyor bunları, kullanılan kaynak kitap: How to Design Programs).

Örnekler çoğaltılabilir. Burada Sümer tabletlerinden, Mısır hiyerogliflerinden ya da Mars'tan gelen bir uygarlığın gizemli yazıtlarından filan bahsetmiyoruz görüldüğü gibi. Sözkonusu sözdizimler de insan beynini zorlamak için özel olarak geliştirilmiş şeyler filan değil.

Profesyonel programcıların Lisp dil ailesinden Common Lisp kullanarak yaptıkları şeylere dair daha önce linkler ve örnekler verilmişti zaten.

Sanki bir sorun varmış da çözmeye çalışıyormuşuz gibi garip bir hava oluştu. Ben bir sorun göremiyorum, doğru dürüst anlatan anlatıyor, çalışıp uğraşan da öğreniyor ve iş güç yapıyor. Hayat sürüp gidiyor.
skoylu
0
skoylu
CLOS üzerinden anlatmıştık. Hiç öğretemedik desem yalan olur. Ama, karşımızdakilerin (class-of 'hede)
(class-of "foo")
(class-of 1234)
(class-of '(a b))
(class-of '#(a b c))
gibi mevzularda kafalarının karıştığını görüyordum. Pedagog değilim, ama bunları izah etmek değil sorun, bunların neden böyle yazıldığı ile başlıyor, benim kanımca. Ama bazıları, LISP türevleri iyidir, Python iyidir gibi bir mecraya çekmeye çalışıyor konuyu ki, bende bundan rahatsızım. Ruby daha mı iyidir gibi bir noktada var elbette. Burada kimin iyi, kimin kötü olduğunu değil, bu kriptik anlatımın getirebilidği pitfall ve öğrenme sorunlarını tartışmak asıl mesele. Ha, belki bu sorunu aşabilecek bir fikir veren olur. Ama olmuyor, hemen "Yok LISP şöyledir de siz bilmiyorsunuz" gibi bir tavır takınılıyor.

Şu iyidir, böyledir, şöyledir filan değil mesele. Basitçe, CLI ile GUI farkı bir durum mesele. GUI sezgisel olarak anlamayı kolaylaştırır ama esnekliği sıfıra indirir. CLI ise tam tersine. İşte bu da öyle bir şey. Ama nedense mevzu kayıp gidiyor, Pytho vs. LISP kavgasına..

PHP'nin $ ve @ işaretleri de aynı kafa karışıklığına daha azda olsa sebep oluyor.

Eğer konuya bu açıdan bakılabilse, bu problemi bir gözlem sonucu olarak anlatırken ben, "Benim dlimi daha iyidir, sizinkini döver" babında değilde, bu tespitin teorik altyapısı çıkarılabilse, sorunun kökenine inilebilse, çöüzm de bulunabilir. Böylece belki bir dil filan yazmak isteyene de yol göstermiş oluruz. Ama yok böyle bir yaklaşım. Ya "Ya sev, ya terket" yada "Sen yanılıyorsun, öyle değil, aslında o dediğin daha kötü" gibi bir yaklaşım görüyoruz nedense..
FZ
0
FZ
Önce el insaf diyerek söze başlamak istiyorum, burada insanlar birtakım kod örnekleri verirken ve sonra kendi aralarında bazı şeyleri netleştirmeye çalışırken teknik olarak "Python var Python, iyidir günlük işler için, Python gibi kolay, günlük işlere uygun bir dil dururken kim ne yapsın Lisp'i?" diyen kimdi allah aşkına? Bu teknik bir tartışma mıdır, bu ufuk açacak, vizyon genişletecek bir yaklaşım mıdır? Tartışma tam da bu yüzden uzamadı mı? Şimdi diyorsunuz ki bu iyi bir üslup değil. %100 katılıyorum, bence de iyi bir üslup değil.

Dil tasarlayan insanlara gelince, zaten böyle iddialı işe girişen aklı başında biri herhalde farklı paradigmaları temsil eden dillerin içindeki güçlü fikirlere ve uygulamalara bakacaktır. Çok basit bir örnek: Don Box'ın burada bazı blog girdilerine de yer vermiştik, C# 2.0 ve bir süre sonra çıkacak olan C# 3.0'daki bazı özellikleri anlatıyordu ve bunun için "bakın Scheme dilindeki filanca yapıya benziyor, ne güzel değil mi" gibi bir üslup kullanıyordu. Keza yine başka araştırmacıların Common Lisp, Smalltalk, Haskell, OCaml, Prolog gibi dillerdeki özelliklere bakarak, onlardan feyz alarak bir şeyler geliştirmeye çalıştıklarını görüyoruz, misal "pattern matching" ve benzeri güçlü kavramları Common Lisp tarzı bir ortamda gündeme getiren Qi programlama dili gibi (konu ile ilgili güzel bir blog: Programming Kung Fu Qi).

Zihin, kavramak, vb. şeylere dönelim: Demişsiniz ki etrafımdaki bir grup insana anlatmaya çalıştım, kafaları karıştı. Keşke karışmasaydı. Buna ne denebilir ki, keşke dünyada savaşlar da olmasa idi. Bu bir kriter değil çünkü bir başka "etraftaki" insanlara bakıyoruz bu "kafa karıştırıcı, kriptik" dili benimsediklerini ve binlerce satır kod yazdıklarını görüyoruz. Bahsettiğimiz dilin 50 yıllık tarihi var nerede ise. Demek ki üçü beşi geçen, farklı ülkelerde yaşayan programcıların bir kısmını çekmiş, onlar tarafından birtakım karmaşık bilgi işlem problemlerini çözmek için kullanılmış. O insanlar bunu tercih etmişler. Yani ben hala bir sorun göremiyorum. Söz konusu insanlar sizce mazohist filan mı? Akıl sağlıklarını mı yitirmişler? Egzantrik olmak için, sırf yapmış olmak için yapmışlar bazı şeyleri? Devasa, irrasyonel, dünyadışı bir komplo ile mi karşı karşıyayız? Bir grup insana da karışık gelebilir. Yani buradan yola çıkarak herhangi bir şey demek pek anlamlı değil. Ama diyecekseniz ki dilde şöyle bir tutarsızlık var, %60 durumda şu tür bir sözdizimi ve semantik varken %40 durumda onun tam tersi, uyumsuz birtakım vakalar var, bu yüzden insanları gereksiz yere vakit kaybına uğratıp duruyor, o zaman bu değerli bir eleştiri olur. Böyle bir şey demediğiniz takdirde ben de "yahu programlamanın kendisi zaten doğal bir insan eylemi değil, oturup epey çalışmak gerekiyor" der geçerim. Bir yere varmaz.
bm
0
bm
CLOS üzerinden anlatmıştık. Hiç öğretemedik desem yalan olur.

Ne kadar ogretebildiniz? Hangi materyalle? (acik mi notlariniz?) MOP'a sira gelmis miydi? Bu tecrube bizim guruptaki heveslilere faydali olur, biraz detay verseniz?

bm
0
bm
Bu arada meraklilari icin soyleyeyim:
(class-of "foo") (class-of 1234) (class-of '(a b)) (class-of '#(a b c))
Ifadelerinin hazir anlatildigi yer var. Belge surada. Bu fena bir belge degil aslinda ama iyi kotu Common Lisp bilenler icin oldugunu unutmamak lazim.
Zebani
0
Zebani
Mathematica For Students 5.2

0) N[(1782^12 + 1841^12)^(1/12), 1]
1) N[(1782^12 + 1841^12)^(1/12), 2]
2) N[(1782^12 + 1841^12)^(1/12), 3]
3) N[(1782^12 + 1841^12)^(1/12), 4]
4) N[(1782^12 + 1841^12)^(1/12), 5]
5) N[(1782^12 + 1841^12)^(1/12), 10]
6) N[(1782^12 + 1841^12)^(1/12), 11]
7) N[(1782^12 + 1841^12)^(1/12), 12]
8) N[(1782^12 + 1841^12)^(1/12), 100]
9) N[(1782^12 + 1841^12)^(1/12), 1000]
------------------------------------------
------------------------------------------
0) 2.x10^3
1) 1.9x10^3
2) 1.92x10^3
3) 1922.
4) 1922.0
5) 1922.000000
6) 1922.0000000
7) 1921.99999996

8) 1921.9999999558672254029113283702950729344117065737086823078338186737756066489
81023159083938878859956

9) 1921.9999999558672254029113283702950729344117065737086823078338186737756066489
810231590839388788599557158412290321166181634847221713985295461432710323539109
424026700211102875265694054527019746035449998864214631210243194945745228968967
547336732874274120387767777808331899674510037655656918804438152615337813338726
909358784634712655810351399576502363625482768783606467434898397007779862355114
060247182019025502878755725255286430168464912995223711945924219581558081938418
649569995488584583060352239459554229277476916124024974632956160475556594445877
160831612979668347165936432999618087728063627402725637386822100920392320816616
914533772849359070992804639725021663378573441284678708968940502111639120869234
104915852092086241227778616463313736134552073962062507198730553756715658432855
913808172698106721771964435702289729412432248846049428848941280474952655762481
457802926878431734249298488117075555585504106451341779480579043692331558776913
53849459944692136790518164113452442629304133056610696694048814013
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Matematik Dünyası - Yeni Sayı Çıktı - 2005/I
FZ
1 Ağustos 2005, 1 dakika okuma süresi

14. yılının 1. sayısı ile tekrar okurları ile buluşan Matematik Dünyası dergisi yine dolu dolu.

Bu sayının kapak konuları: Kaos, Kadın Matematikçiler ve Sayma

Detaylı içerik ise buradan öğrenilebilir.

Wolfram'ın 2, 3 Turing Makinasının Evrensel Olduğu İspatlandı
FZ
25 Ekim 2007, 1 dakika okuma süresi

Dün yani 24 Ekim 2007 Çarşamba günü Stephen Wolfram'ın A New Kind of Science kitabında kurallarını verdiği ve evrenselliğinin ispatlanması karşılığında 25.000$ ödül koyduğu sistemin evrenselliğinin ispatlandığı duyuruldu. Birmingham, İngiltere'de bilgisayar bilimleri okuyan 20 yaşındaki Alex Smith'in 40 sayfalık ispatı ile ödülü kazanmayı hak etti.

Ian Stewart ile Mayın Tarlası Üstüne*
FZ
4 Aralık 2008, 14 dakika okuma süresi

Bir bilgisayar oyununu analiz ederek 1 milyon dolar kazanmak pek sık rastlayabileceğiniz bir durum değildir ama kaderin garip bir cilvesi olarak artık böyle bir şansınız var. Fakat bu ödüle erişmeniz için konuyla ilgili tüm uzmanların yanılıyor olması ve çok zor olduğunu düşündükleri bir problemin aslında çok kolay çıkması gerekiyor. Bu yüzden yeni bir Corvette araba siparişi için acele etmeyin.

Söz konusu ödül şu anda Cambridge MA'da, iş adamı Landon T. Clay tarafından matematiksel bilginin geliştirilmesi ve yayılması için kurulan Clay Matematik Enstitüsü tarafından verilen milyon dolarlık yedi ödülden biri. Ödüle konu olan oyun, Microsoft Windows işletim sistemi ile gelen Mayın Tarlası oyunu. Bu oyundaki amacınız bir ızgara üzerinde gizlenmiş mayınları bilgisayarın size verdiği ipuçlarından faydalanarak bulmak. Oyunun ilişkili olduğu problem ise matematikte cevaplanmamış en önemli problemlerden biri olan 'P=NP?' sorusu.

Mayın Tarlası oyunu ile para ödüllü matematik problemi arasındaki bağlantı Birmingham Üniversitesi'nden Richard Kaye tarafından gösterildi ('Minesweeper is NP-complete', Mathematical Intelligencer cilt 22, sayı 4, 2000, sayfa 9-15). Heyecanlanmanıza gerek yok, oyunu kazanarak ödülü kazanamıyorsunuz. Milyon dolarlık ödülü hak etmeniz için Mayın Tarlasını devasa büyüklükte ızgaralar üzerinde oynarken başarılı olmanızı sağlayacak yöntemi bulmanız gerekiyor. Aslında böyle bir yöntemin olmadığını ispatlarsanız o zaman da size aynı ödülü veriyorlar.

Nasıl kesmeli?
tongucyumruk
3 Aralık 2016, 2 dakika okuma süresi

Geçtiğimiz hafta Festival of the Spoken Nerd ekibi tarafından düzenlenen An Evening of Unnecessary Detail başlıklı etkinliğe katıldım. Etkinlik boyunca dokuz farklı gösteri sergilendi fakat bunlardan bir tanesi özellikle diğerlerinden farklı olarak kendini gösteriyordu. Burada onunla ilgili birşeyler paylaşmak istedim.

Elinizde bir A4 kağıt olduğunu düşünün, ve bu kağıttan bir kare kesmeniz...

Euler Projesi: Bilgisayarları Hazırlayın Matematik Sınavı Var
FZ
8 Ağustos 2006, 1 dakika okuma süresi

Euler Projesi bir grup meydan okuyucu problemi çözmek ve bu çözümlerinin puanlandırılması ile ilgili. Problemlerin ortak özelliği ise matematik ile programlamayı birleştirmeleri. Yani tek başına ya matematik ya da tek başına programlama bilmeniz pek yeterli değil. Başka bir deyişle programlama bilgisinin çözümlerde çok kolaylık sağladığı türden problemler.