Aug 17, 2012

Function Composition กับ Programming


ตอนม.ปลาย คงเคยเห็นฟังก์ชั่นที่เขียนแทนด้วยสัญลักษณ์ g o f กันมาแล้ว ซึ่งมันหมายความง่ายๆ เช่นนี้
(g o f) (x) = g(f(x))
(นิยามเต็มๆ ของมันคือ ถ้า f: X -> Y และ g: Y -> Z แล้ว g o f: X -> Z ---- ที่ต้องนิยามเช่นนี้เพราะเราจะสามารถละการเขียน argument x ติดไปกับนิยามได้)

ในการเขียนโปรแกรม (โดยเฉพาะเชิง functional) เรามักต้องทำงานแบบฟังก์ชันต่อเนื่อง คือ output จาก function หนึ่ง จะถูกนำมาใช้เป็น input ให้ฟังก์ชันถัดไปเป็นลูกโซ่

เขียนอธิบายเป็นภาษาโปรแกรมได้คือ
first_input = x
first_output = f(first_input)
second_input = first_output
second_output = g(second_input)
y = second_output
หรือเพื่อไม่ให้เปลืองตัวแปร ทั้งหมดนี้สามารถย่อได้เหลือ
y = g(f(x))
คำถามคือ ถ้าเราต้องการประกาศแค่ฟังก์ชั่นที่ทำงานต่อกันไปเรื่อยๆ เช่นนี้ โดยที่ไม่ต้องการใส่ input ให้ฟังก์ชั่นโดยทันที เราจะทำอย่างไร?

ทางออกหนึ่งคือใช้ lambda เข้าช่วย
h = lambda x: g(f(x))
แล้วเวลาจะเรียกใช้ฟังก์ชั่นนี้ ก็แค่สั่ง
y = h(x)
ฟังดูง่ายดี แต่นึกดูอีกที ทำไมเราถึงต้องทำอะไรให้มันยุ่งยากด้วยการเอา lambda เข้ามาเกี่ยวด้วย?

ในภาษา imperative คงไม่มีทางเลือกอื่น แต่สำหรับภาษา functional จ๋าอย่าง Haskell เราสามารถเขียนแบบนี้ได้
let h = g . f
จะเห็นว่าง่ายดายเหมือนกับ g o f ตอนแรกเลย เวลาใช้ก็แค่
h x
หรือถ้าจะละการประกาศฟังก์ชั่น h ทิ้งไป เพื่อหาผลลัพท์ทันทีเลย ก็ทำได้โดย
(g . f) x
อ่าห์... นี่มันคณิตศาสตร์ชัดๆ!!

Aug 16, 2012

ความเคยชิน


คิดมานานแล้วว่านิ้วก้อยซ้ายมันใช้งานน้อยมากๆ และปุ่ม CapsLock ก็ไม่โดนใช้เลย น่าจะเอาปุ่มนี้ไว้ใช้เปลี่ยนภาษา

เดิมเคยเปลี่ยนภาษาด้วย ~ (Thai-Windows style) มาก่อน ต่อมาใช้ Linux ที่ต้องใช้ปุ่ม ~ บ่อยๆ เลยเปลี่ยนเป็น Alt+Shift ซึ่งมันจะมีปัญหา lost focus บ้าง คราวนีเปลี่ยนอีกรอบ เลยจับเวลาที่ต้องใช้ปรับตัวซักหน่อย (เช่นเดียวกับที่เคยทำตอนเปลี่ยนจาก Emacs มาเป็น vi [1] [2])

ปรากฏว่าใช้เวลาแค่วันเดียวเท่านั้นเองแฮะ น่าแปลกใจมากๆ

แต่ว่าคนอื่นๆ ก็คงใช้เวลาตรงนี้ไม่เท่ากันสินะ แน่นอนว่าตอนเปลี่ยนแรกๆ ก็ด่าในใจไปเยอะเหมือนกัน ไม่ชินจนอยากเปลี่ยนกลับเป็นแบบเดิม แต่พอถึงขั้นหนึ่งแล้วก็ไหลลื่นเป็นธรรมชาติ

สรุปว่าอย่าไปใจร้อนสินะ เวลาจะเปลี่ยนอะไรซักอย่าง (แต่ก็อย่าเอื่อยเฉื่อย เฉไฉไม่ยอมเปลี่ยนพอ)

Jul 10, 2012

ความประทับใจกับห้องสมุดวิทย์ฯ มช.

ตอนไปยืมวันแรกๆ ที่เปิดเทอม ก็บอกว่ายังไม่ได้จ่ายตังค์ค่าเทอม ยังยืมไม่ได้ ... เอ่อ พี่ครับ ที่นี่เค้าเปิดเทอมก่อน จ่ายตังค์สัปดาห์ที่สองโว้ย ให้รอสัปดาห์หน้าลูกเดียวเลยหรือไงวะ

สัปดาห์ถัดมา จ่ายตังค์ค่าเทอมเรียบร้อยหนังสือที่จะยืมตั้งแต่คราวแรกแม่งหายอีก ไม่มีระบบจองหนังสือหรือไงวะ

เอ่อ งั้นยืมเล่มอื่นที่แก้ขัดก็ได้ พอหาหนังสือที่ต้องการเจอ แม่งเชี้ย บอกห้องสมุดปิดให้ยืมแล้ว มึงใช้เวลา shutdown เครื่องยืมหนังสือ 15 นาทีหรือไงวะ เวลาเลิกยืมก่อนห้องสมุดปิดถึงกินเวลานานขนาดนั้นเนี่ย

เอาใหม่ อีกวันนึงเอาใบเสร็จค่าเทอมไปยืมจนสำเร็จ ระหว่างนั้นก็ไปออกบัตรนศ.ใหม่ด้วย เพราะใบเก่าหมดอายุ

... ผ่านไปสองอาทิตย์อ่านหนังสือจบ เอาไปคืน เห็นเล่มที่จะยืมตั้งแต่คราวแรกพอดี เลยหยิบไปเคาน์เตอร์ แม่ง บอกบัตรนศ.กูเป็นบัตรใหม่ บัตรมันไม่ link กับบัตรเก่า ยืมไม่ได้ ต้องไป activate บัตรที่สำนักทะเบียนก่อน

ห่าเอ้ย หมดความอดทนแล้วโว้ย

Jul 8, 2012

ข้าวมันไก่?

สั่งหมีขาวน้ำตก... บอกว่าร้าน "ไม่น่า" จะมี เอาเป็นเย็นตาโฟแทนมั้ย (ตรูไม่กินเย็นตาโฟเว้ย เอาแบบธรรมดามาไม่ได้เหรอ -- ว่าแต่ร้านก๋วยเตี๋ยวที่ไหนบ้าง ที่ไม่มีน้ำตกเนี่ย)

เอาใหม่ สั่งข้าวมันไก่ทอด... ได้ข้าวมันไก่ต้ม (ทั้งๆ ที่คราวนี้ร้านมันแขวนไก่ทอดไว้ข้างๆ กันเลย) - -"

ก็พอเข้าใจแล้วหละ ว่าทำไมตัวเองถึงติดคำว่า "อะไรก็ได้" ไปเสียหมด

ไม่ใช่ไม่อยากคิด (โว้ย) แต่พอคิดทีไร แม่ง "ไม่เคย" ได้อย่างคิดเลย

เอ่อ ไม่คิดดีกว่าหวะ

One More Time, One More Chance



วันนี้หยิบเอา 5cm ฉบับการ์ตูนที่เพิ่งออกมาอ่าน พบว่า part 1 เนือยๆ ทำบรรยากาศได้ดีเหมือนกับในหนัง คือก็ไม่น่าเบื่อซะทีเดียว แต่ก็เหมือนว่าตอนนี้ไม่มีจุด peak เอาซะงั้น (มันหลบหายไปพร้อมกับการแสดงออกของตัวเอกนั่นแหละ)

อ่านจบ part 1 จะวางละ ง่วงนอน+ดูจากความหนาแล้ว part 2 ไม่น่าจะเล่าจบได้ในเล่มนี้... แล้วเล่มต่อไปจะออกเมื่อไหร่ก็ไม่รู้ กลัวลงแดงตายซะก่อน...

แต่จนแล้วจนรอด ก็หยิบ part 2 มาอ่านต่อจนได้ ซึ่งต้องยอมรับว่า ประหลาดใจ (แบบไม่ประหลาดใจ) พอสมควร เพราะเนื้อเรื่องเล่าไว้ละเอียดกว่าในหนังมากๆ (ก็ไม่น่าแปลก part 1 ในหนังได้เวลาไปตั้งครึ่งนึงเลย part 2, 3 ก็โดนตัดฉับๆๆ ซะ)

อ่านจบเล่ม (แต่ไม่จบ part) ทนไม่ไหว มาเปิดอ่านภาษาอังกฤษในเน็ตต่อซะ เลยเข้าใจเรื่องราวขึ้นอีกเยอะเลย

และเสียน้ำตาอีกตามเคย TwT

ไปๆ มาๆ รู้ตัวอีกทีก็นั่งดู MV ตัวข้างบนอีกแล้ว...

รถไฟที่วิ่งคั่นกลางระหว่างคนสองคนนั้น ก็ยังคงเป็นฉากที่ทำให้ใจจะขาดเหมือนเช่นทุกที

... แต่จริงๆ แล้วนะ การดับความหวังไปซะเลย ก็ยังดีกว่าปล่อยให้หวังลมแล้งๆ แทบไม่มีทางเป็นจริงสินะ

สุดท้ายก็ได้แต่กลับมาถามตัวเองอีกครั้งว่า ถึงเวลาที่จะก้าวเดินต่อไปหรือยัง?



ปล. อันข้างล่างนี่ สำหรับใครที่อยากให้จบแบบ happy ending นะ :')

Jun 13, 2012

อยากทำ อย่างที่ 5 โปรแกรมแก้ไขเอกสารที่มองภาพรวมเป็นต้นไม้

วันนี้เห็น @awkwin ทวีตเกี่ยวกับความ *** สุดจะบรรยายของ JavaScript เลยได้ฤกษ์ขุดกระทู้ในตำนานมาอ่านอีกรอบ แล้วก็ได้สัมผัสถึงความ !@#$%^&* ของภาษา APL ซึ่งคอมเมนท์ในนั้นบอกไว้ว่า มันคงเป็นภาษาที่เจ๋งและกี๊คมากเลยถ้าอยู่ในหนัง ก็เลยทำให้นึกถึงหนังเรื่อง Stealth ตอนที่ศูนย์คอมเข้าไปดูโค้ดของโปรแกรมเพื่อหาบั๊ก (ส่วนนี้ในหนังกากมาก เพราะแม่งเล่นง่าย เอาโค้ดส่วนที่เป็นบั๊กไปไว้ "ระหว่างบรรทัด" เลย ซึ่งในความเป็นจริงโค้ดมันจะซ้อนอยู่ตรงนั้นได้ยังไงวะ) ถึงตอนนี้ก็ฉุกคิดได้ว่า เอ่อ ไม่เห็นจะเจ๋งตรงไหนเลย ถ้ามันแต่งมาเวอร์ๆ แต่ไม่มีทางเป็นไปได้ในโลกความเป็นจริง ...

... แล้วก็มาคิดได้ว่า อึม หรือโปรแกรมแก้เอกสารในหนังนั้นมันเป็นแบบโคตรล้ำยุคหว่า สามารถแสดงข้อความซ้อนๆ กันแบบ 3 มิติได้ เลยนั่งคิดต่ออีกซักพักนึงแล้วพบว่าโคตรไร้สาระ โค้ดที่เขียนกันอยู่ 2 มิติจะไปแสดงผลแบบ 3 มิติให้งง+เก็บบั๊กยากขึ้นทำไมหละ

ถอยกลับมา 1 ก้าว.. เอ่อ แต่ถ้าได้เขียนโค้ดแบบ 3 มิติจริงๆ คงเจ๋งไม่น้อยเลยนะ ก็เลยลองออกแบบว่า ไอ้การเขียนโค้ด 3 มิติ (ถ้ามันจะมีจริง) มันควรจะเป็นยังไงกันนะ?

คิดไปเรื่อยๆ โดยอิงจากตัวอย่างในปัจจุบัน ก็พบว่ารูปแบบโค้ดโดยทั่วไปจะออกแนวๆ นี้



ซึ่งถ้ามองในมุมของโปรแกรมเมอร์ที่เชี่ยวแล้วคงไม่มีปัญหา (เริ่มอ่านโปรแกรมจาก main ด้านล่างสุด แล้วโดดไปดูคลาส/ฟังก์ชันแค่เวลาที่ต้องการข้อมูลเพิ่มเติม)

แต่สำหรับโปรแกรมเมอร์มือใหม่ (อย่างผม) นี่ทำให้เกิดปัญหาที่เรียกว่า "เริ่มไม่ถูก" ขั้นรุนแรง ตั้งแต่เริ่มไม่ถูกว่าจะดูโค้ดที่ไหนก่อนดี? ทำไมต้องมองโปรแกรมตามแบบที่คอมพิวเตอร์ทำงานโดยการเริ่มจาก import requirement/dependency ต่างๆ ให้ครบก่อนแล้วจึงจะเริ่ม main ได้? ทิศทางการเขียนโปรแกรมควรจะเขียนแบบ top-down หรือ bottom-up กันแน่?

เลยได้ข้อสรุปสำหรับตัวเองว่า มันคงจะเหมาะกว่า ถ้าเริ่มมาก็สามารถเขียน concept ทั้งหมดของ main ได้เลย อยากใช้ฟังก์ชันใหม่ชื่ออะไรก็เขียนๆ ไปก่อน พอวางโครงเสร็จก็ค่อยกลับมาดูว่ามีฟังก์ชันไหนที่ยังไม่ได้เขียนกฎให้มัน ซึ่งพอดับเบิลคลิกที่ชื่อฟังก์ชันนั้นๆ ก็จะเป็นการเปิดป๊อปอัพหน้าต่างใหม่สำหรับเขียนกฎให้มันนั่นเอง (ยืมแนวคิดมาจาก lambda)



โดยรวมแล้วก็คงคล้ายๆ กับ Inspect Element ของเว็บเบราว์เซอร์ คือเริ่มดูจาก root node ไล่ลงไปเรื่อยๆ นั่นเอง เพียงแต่เปลี่ยนการ expand tag ไปเป็นการเปิดหน้าต่างใหม่แทน

รายละเอียดปลีกย่อย (ถ้าจะทำจริงๆ) ก็คงต้อง highlight สีของฟังก์ชันที่ยังไม่ได้เขียนกฎให้เด่นหน่อย ส่วนถ้าฟังก์ชันไหนเขียนไปแล้วแต่ติดแท๊ก FIXME หรือ TODO ไว้ ก็เปลี่ยนไป highlight ด้วยอีกสีหนึ่ง (จะได้รู้ว่ามีข้อผิดพลาดที่ฟังก์ชันนี้ และกลับมาแก้ไขทีหลังได้ง่าย) แล้วก็คงต้องดักพวก recursion ด้วย ส่วนการเขียนเพิ่มฟังก์ชันใหม่ๆ เข้าไป ต้องเอามันไปแทรกไว้ก่อน main เสมอ

คิดออกแค่นี้ ง่วงแล้ว ลองนอนดูก่อนว่าจะหายบ้ามั้ย 555

Jun 2, 2012

Opensource ไม่ใช่ของฟรี, คนทำไม่ได้อิ่มทิพย์

เรื่องหนึ่งที่เข้าใจผิดๆ กันมากเกี่ยวกับวงการไอที คือความคิดที่ว่า opensource คือของฟรี การนำ opensource มาใช้งานมีค่าใช้จ่ายเป็นศูนย์

อันที่จริงก็มีหลายคนเขียนถึงเรื่องนี้ไว้หลายครั้งแล้ว: 0, 1, 2 (ฯลฯ ที่ผมไม่สามารถหาเจอได้แล้ว) ซึ่งตอนนั้นผมเองอ่านบทความเหล่านั้นก็ยังไม่ค่อยเข้าใจเท่าไหร่ จนกระทั่งมาได้ทำงานกับ opensource จริงจัง

โปรเจค opensource อาจกำเนิดขึ้นมาจากงานง่ายๆ ที่ได้รับจากผู้ว่าจ้าง ในตอนแรกผู้ใช้เครื่องมือ opensource ชิ้นนั้นคงมีแค่เพียงทีมผู้สร้างไม่กี่คน แต่เมื่อเครื่องมือ opensource ชิ้นนั้นเริ่มมีประสิทธิภาพมากขึ้น มีคนให้ความสนใจศึกษาใช้งานมัน โปรเจค opensource ชิ้นนั้นก็จะได้รับการปรับปรุงขึ้นเรื่อยๆ จนติดลมบนไป

เช่นกันสำหรับผู้ที่ต้องการเริ่มงานบางอย่างที่ได้รับจากผู้ว่าจ้าง การเริ่มจากศูนย์นั้นยากและเสี่ยงเกินไป การดึงเครื่องมือ opensource มาช่วยงานคือสิ่งที่ควรทำ แน่นอนว่าการใช้งานเครื่องมือเหล่านั้น ย่อมพบเจอปัญหาไม่ต่างจากการเขียนโค้ดเองทั้งหมด การส่ง patch กลับไปยังต้นน้ำจะเป็นการช่วยพัฒนา opensource ให้แข็งแกร่งขึ้น

จาก 2 เคสที่ยกมานี้ จะเห็นว่าตัว opensource ไม่ได้จ่ายเงินให้นักพัฒนาเลย แต่เป็นผู้ว่าจ้างนั่นเองที่จ่ายเงินให้นักพัฒนาโดยตรง และโปรเจค opensource ก็โตได้เพราะเงินในส่วนนี้

ใช่ครับ opensource ไม่ใช่ของฟรี และคนทำก็ไม่ได้อิ่มทิพย์!!

May 17, 2012

ข้าวเย็น-แม่หลับรอ-ลูกกลับบ้านดึก

นอนไม่หลับ เลยตกตะกอนเรื่องตอนเย็นๆ จดเก็บไว้หน่อย เผื่อแก่ไปมีลูกเป็นวัยรุ่นจะได้กลับมาอ่านบ้าง...

ช่วงนี้เห็นโฆษณาหลายตัวเล่นประเด็นเกี่ยวกับความสัมพันธ์ในครอบครัว ตัวละครส่วนใหญ่ก็จะเป็นลูกชายกับแม่แค่สองคน (น่าสนใจมากว่าพ่อหายไปไหน ประเด็นลูกชาย-แม่มัน mass ขนาดนี้เลยหรือ?) และหนึ่งในเรื่องที่โฆษณาแทบทุกตัวหยิบมานำเสนอคือ ข้าวเย็น-แม่หลับรอ-ลูกกลับบ้านดึก



ผมก็เคยเจอกับเหตุการณ์นี้ครับ มันไม่สนุกหรอก ที่ต้องเห็นใครบางคนฟุบหลับบนโต๊ะอาหารที่เปิดไฟรอเรา ทั้งที่เค้ามีสิทธิ์เลือกสิ่งที่ดีกว่าอย่างขึ้นไปนอนเปิดแอร์บนเตียงดีๆ

คุณอาจคิดว่านี่เป็นภาพที่แสดงออกถึงความรัก ผมไม่เถียงนะ แต่คำถามคือ มันสมควรแล้วหรือ?

มันจะดีกว่ามั้ย ถ้าแม่จะขึ้นไปนอนหลับพักผ่อนดีๆ จะได้ไม่ต้องมาเจ็บป่วยทีหลังกับโรคข้อและอาการหลับไม่สนิท เก็บอาหารเข้าตู้เย็นซะ มันจะได้ไม่เสียและมดไม่ตอม ปิดไฟไปเหอะ ประหยัดพลังงานในส่วนที่ไม่ได้ใช้

คุณอาจเถียงว่าทำอย่างนี้แล้วลูกจะรู้มั้ยว่ารัก ... มันไม่มีลูกคนไหนหรอกครับ ที่คิดว่าพ่อแม่ไม่รัก ทำอย่างนี้มีแต่จะเพิ่มความอึดอัดให้ลูกซะเปล่าๆ คิดว่าตนเองเป็นภาระให้ครอบครัวต้องลำบากไปซะงั้น

คุณอาจบอกว่าวันๆ ลูกมันเอาแต่ทำงาน ถ้าไม่รออย่างนี้กว่าจะเจอหน้ากันทีก็คงเป็นสัปดาห์ละครั้ง ... ผมไม่อยากเปรียบเทียบกับคนอื่นๆ ที่เค้าต้องไปทำงานต่างจังหวัดแล้วได้เจอกันปีละสอง-สามครั้งหรอกนะ แต่ลองคิดดูดีๆ ครับ เจอกันแค่สัปดาห์ละครั้งแบบมีความสุข หรือเจอกันทุกวันด้วยความรู้สึกหนักอึ้งเช่นนี้

หรือคุณอาจจะบอกว่าตัวเองแก่แล้ว เวลาเหลือน้อย อยากใช้ชีวิตอยู่กับลูกให้มากที่สุด ... รอลูกอย่างนี้ นอกจากจะเสียสุขภาพกายเพราะได้หลับไม่เต็มที่ ไปจนถึงบางทีก็ไม่ยอมกินข้าวจนกว่าลูกจะกลับ ยังเสียสุขภาพจิต มัวแต่ชะเง้อรอด้วยความเครียดว่าลูกจะปลอดภัยมั้ย ผมอยากถามกลับครับว่า ใช้ชีวิตเครียดๆ แถมยังไม่ดูแลตัวเองอย่างนี้ แล้วคุณจะอยู่กับลูกไปได้นานๆ มั้ยครับ

นอกจากนี้รู้มั้ยครับ กลับบ้านดึกอย่างนี้ ส่วนใหญ่ก็กินข้าวรอบเย็นกันมาหมดแล้ว (ไม่งั้นจะมีแรงทำงานหรือ?) แต่พอเห็นอาหารที่คุณเตรียมไว้ก็ต้องกินอีก ไม่งั้นเดี๋ยวคุณจะเสียน้ำใจ ... แล้วผลลัพท์ที่ตามมาสู่ลูกๆ ก็คือความอ้วนและกรดไหลย้อนนั่นแหละ

... ใครว่าความรักอันเปี่ยมล้นของพ่อแม่ไม่มีทางไม่ดีครับ? ลองคิดดูใหม่นะ

แล้วก็ลองคิดดูนะครับ ว่าความรู้สึกผิดโดยไม่มีทางออกจะส่งผลเสียขนาดไหน เลือกครอบครัวกลับบ้านเร็วก็ทำให้เสียงาน เลือกงานก็ทำให้คนที่บ้านน้อยใจ

หลังจากเจอเหตุการณ์อย่างนี้หลายๆ ครั้ง (จนบางครั้งผมทั้งโมโหทั้งเสียใจ นั่งลงจ้วงข้าวเย็นที่เย็นชืดและมีมดขึ้นจนหมด) ผมเลยตัดสินใจที่จะไม่กลับบ้าน มันไม่ใช่ทางเลือกที่ผมอยากทำเท่าไหร่หรอก แต่ในเมื่อการพูดคุยอธิบายมันไม่ได้ผลแล้ว ก็ปล่อยให้แม่กระวนกระวายใจเล่นซักวันสองวัน และรับรู้ไว้ว่าแม้จะรอไปอย่างนี้ ผมก็ไม่กลับบ้านให้คุณเห็นหน้าเร็วขึ้นหรอกนะ

ก็เลือกเอาละกันครับ ว่าคุณจะเป็นพ่อแม่แบบไหนให้ลูกจดจำ? จะเป็นพ่อแม่ที่ทำให้ลูกรู้สึกผิดอยู่ตลอดเวลา เพราะว่าปันเวลาไปดูแลท่านได้ไม่ดีพอ หรือจะเป็นพ่อแม่ที่ลูกอาจไม่ได้คิดถึงตลอดเวลา แต่พอพูดถึงทีไรก็อมยิ้มและพูดด้วยความภาคภูมิใจว่า นี่แหละพ่อแม่ของฉัน

Apr 27, 2012

Code Jam 2012 รอบคัดเลือก


สืบเนื่องจาก @Blltz กับ @ngfar มาเที่ยวบ้าน เลยนั่งปั่น Daiblo II กันตั้งแต่ตีสองตีสามจนถึงเจ็ดโมงเช้า กว่าจะเริ่มทำโจทย์ (ซึ่งควรจะเริ่มทำตั้งแต่หกโมงเช้าเลย)

ข้อแรก ง่ายๆ แค่ substitution cipher ธรรมดา ก็โยน input เข้าไป map กันแล้วสร้างเป็น dict ออกมา ทีนี้เวลามันเหลือ เลยเล่นกับ code ซักหน่อย ให้คนตามอ่านปวดหัวเล่น (ของจริงมันอยู่ในบรรทัดเดียว แต่อันนี้แยกบรรทัดให้อ่านง่ายๆ ละนะ) :P
print('\n'.join(
    'Case #{}: {}'.format(
        t+1,
        ''.join(d[c]
            for d in [dict(zip('abcdefghijklmnopqrstuvwxyz ',
                               'yhesocvxduiglbkrztnwjpfmaq '))]
            for c in input()))
    for t in range(int(input()))))
แล้วก็เพิ่งมานึกได้ว่า ไม่ต้องสร้างเป็น dict ก็ได้นี่หว่า...



ข้อถัดมา อันนี้ทดในกระดาษ กระจายรูปแบบออกมาแล้วจะพบว่า ถ้าคะแนน mod 3 แล้วได้ 1 ไม่มีทางที่จะเป็นเซอร์ไพรส์ เลยดูแค่ที่มันไม่ใช่พอ แล้วก็เพิ่มข้อยกเว้นคะแนนแค่ 0 กับ 1 ด้วย
from math import ceil

for t in range(int(input())):
    gg, surprise, expected, *point = (int(n) for n in input().split())
    point.sort(reverse=True)

    count = 0
    for p in point:
        if ceil(p/3) >= expected:
            count += 1
        elif surprise > 0 and ceil(p/3)+1 >= expected:
            if p%3 == 1 or p in (0, 1):
                continue
            count += 1
            surprise -= 1

    print('Case #{}: {}'.format(t+1, count))
ถ้าดูตาม code แล้ว จะเห็นว่าเริ่มมาสั่ง sort ไว้เลย (จริงๆ ไม่ต้องก็ได้) คือตอนนั้นเตรียม optimize ไว้แล้ว แต่เท่าที่จับเวลาดูไม่น่าเป็นห่วง เลยไม่ optimize ดีกว่า เดี๋ยวเจอ bug ซ่อนเร้น



ข้อสาม สมองเริ่มตายเพราะไม่ได้นอนทั้งคืน + เห็นคำว่า recycle เลยเขียนแบบ recursive (ที่ไม่จำเป็นต้อง recursive) ซะเลย 555+
def recycle(m, r):
    global pair, count
    if r > 0:
        m = m%digit * 10 + int(m/digit)
        if lower <= n < m <= upper and m not in pair.setdefault(n, []):
            pair[n].append(m)
            count += 1
        recycle(m, r-1)

for t in range(int(input())):
    lower, upper = [int(n) for n in input().split()]
    round = len(str(lower)) - 1
    digit = 10 ** round

    pair = {}
    count = 0
    for n in range(lower, upper+1):
        recycle(n, round)

    print('Case #{}: {}'.format(t+1, count))
อันนี้ optimize นิดหน่อย ตอนแรกทำการกลับเลขโดยแปลงเป็น str -> สลับที่ str -> แปลงกลับเป็นตัวเลข ปรากฎว่ากินเวลาไปเกินกว่ารับได้ เลยเปลี่ยนวิธีเขียนเป็น math ถ้า test แค่ส่วนกลับเลขก็เร็วกว่าเป็นสิบเท่าเหมือนกัน แต่ไม่ได้ลอง test ทั้ง script ดูว่าเร็วจนน่าพอใจหรือเปล่า

อนึ่ง พอเอาไปรันใน pypy แล้วไม่มีปัญหาเรื่องความเร็วเลยแฮะ เสียเวลา optimize ทำไมเนี่ย

(ข้อนี้แอบโดน @lewcpe ว่าตรงที่ทำไมใช้ global ไม่ return เอาตามธรรมดาวิสัยฟังก์ชั่นทั่วไปด้วย)


พอทำ 3 ข้อแรกเสร็จก็ออกไปเล่นสงกรานต์ กลับมาตอนดึกๆ นั่งมึนหัวอยู่พักนึงแล้วก็คิดวิธีแก้ปัญหาข้อ 4 ได้ (แบบเดียวกับเฉลยบนเว็บ คือสร้างภาพแบบ reflex แล้วใช้วงกลมร้อมรั้วนับเอา) แต่ตอนนั้นคิดวิธี implement ดีๆ ไม่ออกแล้ว แถมเท่าที่ลองเขียนเล่นๆ ก็คิดว่าน่าจะต้องเจองานหนักกว่า 200 บรรทัดแน่ๆ (เวลาไม่น่าพอ) และยังเลือกไม่ถูกอีกว่าจะเขียนแบบ OOP หรือ functional ดี เลยตัดสินใจนอนดีกว่า

แล้วเจอกันรอบ 1A ครับ ~

Feb 25, 2012

คอนเสิร์ตโนดาเมะ


คราวนี้จัดที่กาดสวนแก้ว ใกล้บ้านขนาดนี้ ยังไงก็ไม่พลาดอยู่แล้ว

Beethoven Symphony No.7
เป็นเพลงแรกที่ถูกนำมาเล่นในคอนครั้งนี้ น่าเสียดายว่าเป็น short version คือ rearrange ให้แต่ละท่อนมีแค่ part ใจความสำคัญแค่ครั้งเดียว ไม่มีการย้อนความซ้ำอีกรอบตามรูปแบบของ symphony โดยทั่วไป และระหว่าง movement ก็เล่น (เกือบจะ) ต่อกันทันทีเลย สงสัยว่าไม่อยากให้ปรบมือคั่นระหว่าง movement? สำหรับตัวเพลงนั้น movement แรกเล่นได้ช้ามาก (น่าจะเป็นไปตามสไตล์ของอาจารย์สมัคร กาใจคำอย่างนั้นเอง?) ทั้งที่น่าจะทำให้กระฉับกระเฉงมากกว่านี้ได้อีกหน่อย พอเข้า movement 2 ก็ขาดซึ่งเสียงแตรมา intro ปลุกใจ ข้ามไปยัง part violin เลย ส่วน movement ที่ 3 และ 4 นั้น ยังขาดความสง่างาม เกรียงไกรอย่างที่มันควรเป็นอยู่ครับ

Beethoven Spring Sonata - Allegro
แต่เพลงที่สองนี้ผมเทใจให้หมดเลยนะ piano ของคุณเรมีย์ นามเทพกับ violin ของอาจารย์อภิรัตน์ ประพันธ์วงศ์เล่นประสานกันได้ลงตัวมาก เสียอย่างนึงคือนักดนตรีไม่ได้ซ้อมถึงขั้นที่ไม่ต้องดู score แล้วจังหวะที่พลิกกระดาษเปิดหน้าถัดไปนั้นเสียงดังมาก คนฮือฮากันใหญ่ (ทำไมก็ไม่รู้)

Beethoven Pathetique Sonata - Andante Cantabile
เพลงนี้ก็เอาใจไปให้หมดเลยเหมือนกันครับ ชอบๆๆ (อ๋อ ผู้เล่นคือคุณเรมีย์คนเดิมครับ) แต่เสียดายว่าตอนใกล้ๆ จบเพลง มีเด็กอายุไม่น่าเกิน 5 ขวบเสียงดังขึ้นมา (ทำไมฟระ คนกำลังอิน) แย่ๆๆ

Gershwin Rhapsody in Blue
แล้วก็กลับมาที่เพลงแบบวงใหญ่อีกครั้ง ก่อนเริ่มเพลงแน่นอนว่าต้องเทียบเสียง เด็กคนนั้นนั่นแหละก็เทียบเสียงไปกับเค้าด้วย (เอ่อ จะว่าไปมันก็ตลกนะ... แต่ตอนนั้นขำไม่ออกกับมารยาทของผู้ปกครองแฮะ) แล้วเด็กคนนั้นก็ส่งเสียงเจี๊ยวจ๊าวตลอดเพลงซะอีก (ทำไมไม่พาลูกกลับบ้านไปเลย?) ส่วนเนื้อหาเพลงนั้นก็ปรกติทั่วไปดีครับ ได้คุณ Soo Hwan Cha มาเล่น piano คู่กับการคอนดักต์ของอาจารย์ชัยพฤกษ์ เมฆรา แต่โดยส่วนตัวแล้ว เพลงนี้ผมหลับแฮะ.. (เฉยๆ กับเพลงกึง Jazz กึ่ง Classic เป็นทุนเดิมอยู่แล้ว)

Rachmaninoff Piano Concerto No.2
นับได้ว่าเป็นไฮไลท์ของงานเลยทีเดียวกับเพลงนี้ แต่ผมว่าฝีมือ piano ของคุณ Atsuko Seta ยังไม่แกร่งกล้าพอที่จะฝ่าฟันทะเล orchestra ไปได้แฮะ หลายๆ ครั้งที่เสียง piano ของเธอนั้นโดนกลืนหายไปในพายุอันหนักหน่วง หนำซ้ำ แม้ว่าพายุร้ายจะได้สงบลง เธอกลับไม่สามารถฉายสายรุ้งสวยงามทั้งสองวงได้ ที่สำคัญ เธอจำโน้ตผิดไป 1 ห้อง (อีกแล้ว) ครับ ทางฝั่ง orchestra ก็เลวร้ายไม่แพ้กัน มีท่อนนึงที่เครื่องเป่าเกือบจะทำเพลงล่มเพราะหายไป 2 ห้อง และเฟรนช์ฮอร์นเล่นเสียงดังเกินไปด้วย -___-"

แต่โดยรวมก็ถือว่า คุ้มกับบัตรราคานักศึกษาครับ ยิ่งถ้ารู้ว่าวง orchestra เป็นวงเยาว์ชนที่อาศัยแค่ซ้อมช่วงเย็นด้วยแล้ว น่าจับตามองจริงๆ ว่าถ้าเราตั้งวง orchestra เป็นเรื่องเป็นราว น่าจะไปได้ไกลกว่านี้มากเลยนะ