ລະດູຮ້ອນທີ່ຜ່ານມາຂ້າພະເຈົ້າໄດ້ເຂົ້າຮ່ວມ ລະຫັດລະດູຮ້ອນຂອງ Google - ໂຄງການສໍາລັບນັກຮຽນຈາກ Google. ທຸກໆປີ, ຜູ້ຈັດຕັ້ງໄດ້ເລືອກໂຄງການ Open Source ຫຼາຍ, ລວມທັງຈາກອົງການຈັດຕັ້ງທີ່ມີຊື່ສຽງເຊັ່ນ Boost.org и ມູນນິທິ Linux. Google ເຊີນນັກຮຽນຈາກທົ່ວໂລກໃຫ້ເຮັດວຽກກ່ຽວກັບໂຄງການເຫຼົ່ານີ້. 

ໃນຖານະເປັນຜູ້ເຂົ້າຮ່ວມໃນ Google Summer of Code 2019, ຂ້າພະເຈົ້າໄດ້ເຮັດໂຄງການພາຍໃນຫ້ອງສະຫມຸດ ເງິນເດືອນ ກັບອົງການຈັດຕັ້ງ Haskell.org, ເຊິ່ງກໍາລັງພັດທະນາພາສາ Haskell - ຫນຶ່ງໃນພາສາການຂຽນໂປຼແກຼມທີ່ເປັນປະໂຫຍດທີ່ສຸດ. Alga ແມ່ນຫ້ອງສະຫມຸດທີ່ເປັນຕົວແທນ ພິມປອດໄພ ການເປັນຕົວແທນຂອງກາຟໃນ Haskell. ມັນຖືກນໍາໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນ ຄວາມາຍ — ຫ້ອງສະໝຸດ Github ທີ່ສ້າງຕົ້ນໄມ້ແບບ semantic, ກຣາຟການເອີ້ນ ແລະການເພິ່ງພາອາໄສໂດຍອີງໃສ່ລະຫັດ ແລະສາມາດປຽບທຽບພວກມັນໄດ້. ໂຄງ​ການ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ແມ່ນ​ການ​ເພີ່ມ​ຕົວ​ແທນ​ປະ​ເພດ​ທີ່​ປອດ​ໄພ​ສໍາ​ລັບ​ກາ​ຟ bipartite ແລະ​ວິ​ທີ​ການ​ສໍາ​ລັບ​ການ​ຕົວ​ແທນ​ນັ້ນ​. 

ໃນບົດຂຽນນີ້, ຂ້ອຍຈະເວົ້າກ່ຽວກັບການຈັດຕັ້ງປະຕິບັດ algorithm ຂອງຂ້ອຍໃນການກວດສອບກາຟສໍາລັບການສອງສ່ວນໃນ Haskell. ເຖິງແມ່ນວ່າ algorithm ແມ່ນຫນຶ່ງໃນພື້ນຖານທີ່ສຸດ, ການປະຕິບັດມັນທີ່ສວຍງາມໃນຮູບແບບທີ່ເປັນປະໂຫຍດໄດ້ໃຊ້ເວລາຫຼາຍຄັ້ງແລະຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກຫຼາຍ. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຕົກລົງກ່ຽວກັບການຈັດຕັ້ງປະຕິບັດກັບ monad transformers. 

ກ່ຽວກັບຕົວເຮົາເອງ

ຂ້ອຍຊື່ Vasily Alferov, ຂ້ອຍເປັນນັກສຶກສາປີທີ 4 ທີ່ St. Petersburg HSE. ກ່ອນຫນ້ານີ້ໃນ blog ຂ້າພະເຈົ້າໄດ້ຂຽນ ກ່ຽວກັບໂຄງການຂອງຂ້ອຍກ່ຽວກັບ algorithms parameterized и ກ່ຽວກັບການເດີນທາງໄປ ZuriHac. ດຽວນີ້ຂ້ອຍ ກຳ ລັງຝຶກງານຢູ່ ມະຫາວິທະຍາໄລ Bergen ໃນປະເທດນໍເວ, ບ່ອນທີ່ຂ້ອຍກໍາລັງເຮັດວຽກກ່ຽວກັບວິທີການແກ້ໄຂບັນຫາ ລາຍຊື່ສີ. ຄວາມສົນໃຈຂອງຂ້ອຍປະກອບມີສູດການຄິດໄລ່ຕົວກໍານົດການແລະການຂຽນໂປຼແກຼມທີ່ເປັນປະໂຫຍດ.

ກ່ຽວກັບການຈັດຕັ້ງປະຕິບັດ algorithm

ຄໍາອະທິຖານ

ນັກສຶກສາທີ່ເຂົ້າຮ່ວມໂຄງການໄດ້ຮັບການຊຸກຍູ້ຢ່າງແຂງແຮງໃນ blog. ພວກເຂົາໄດ້ໃຫ້ຂ້ອຍມີເວທີສໍາລັບ blog ລະດູຮ້ອນຂອງ Haskell. ບົດຄວາມນີ້ເປັນການແປ ບົດຄວາມ, ຂຽນໂດຍຂ້ອຍຢູ່ທີ່ນັ້ນໃນເດືອນກໍລະກົດໃນພາສາອັງກິດ, ມີຄໍານໍາສັ້ນໆ. 

ດຶງຄໍາຮ້ອງຂໍທີ່ມີລະຫັດໃນຄໍາຖາມສາມາດພົບໄດ້ ທີ່ນີ້.

ເຈົ້າສາມາດອ່ານກ່ຽວກັບຜົນຂອງການເຮັດວຽກຂອງຂ້ອຍ (ເປັນພາສາອັງກິດ) ທີ່ນີ້.

ຕອບນີ້ສົມມຸດວ່າຜູ້ອ່ານມີຄວາມຄຸ້ນເຄີຍກັບແນວຄວາມຄິດພື້ນຖານໃນການຂຽນໂປລແກລມທີ່ມີປະໂຫຍດ, ເຖິງແມ່ນວ່າຂ້ອຍຈະພະຍາຍາມຈື່ຈໍາຄໍາສັບທັງຫມົດທີ່ໃຊ້ໃນເວລາທີ່ເວລາມາ.

ການກວດສອບກາຟສໍາລັບ bipartiteness 

ສູດການຄິດໄລ່ສໍາລັບການກວດສອບກາຟສໍາລັບ bipartiteness ປົກກະຕິແລ້ວແມ່ນໄດ້ຖືກມອບໃຫ້ຢູ່ໃນຫຼັກສູດກ່ຽວກັບສູດການຄິດໄລ່ເປັນຫນຶ່ງໃນສູດການຄິດໄລ່ກາຟທີ່ງ່າຍດາຍທີ່ສຸດ. ຄວາມຄິດຂອງລາວແມ່ນກົງໄປກົງມາ: ທໍາອິດພວກເຮົາວາງແນວຕັ້ງຢູ່ໃນສ່ວນແບ່ງຊ້າຍຫຼືຂວາ, ແລະເມື່ອພົບຂອບທີ່ຂັດແຍ້ງ, ພວກເຮົາຢືນຢັນວ່າເສັ້ນສະແດງບໍ່ແມ່ນສອງສ່ວນ.

ລາຍລະອຽດເພີ່ມເຕີມເລັກນ້ອຍ: ທໍາອິດພວກເຮົາເອົາບາງຈຸດຢູ່ໃນສ່ວນແບ່ງຊ້າຍ. ແນ່ນອນ, ປະເທດເພື່ອນບ້ານທັງຫມົດຂອງ vertex ນີ້ຕ້ອງນອນຢູ່ໃນ lobe ທີ່ຖືກຕ້ອງ. ນອກຈາກນັ້ນ, ປະເທດເພື່ອນບ້ານທັງຫມົດຂອງປະເທດເພື່ອນບ້ານຂອງ vertex ນີ້ຕ້ອງນອນຢູ່ໃນ lobe ຊ້າຍ, ແລະອື່ນໆ. ພວກເຮົາສືບຕໍ່ການມອບໝາຍຮຸ້ນໃຫ້ກັບແນວຕັ້ງຕາບໃດທີ່ຍັງມີຈຸດຕັ້ງຢູ່ໃນອົງປະກອບທີ່ເຊື່ອມຕໍ່ກັນຂອງ vertex ທີ່ພວກເຮົາເລີ່ມຕົ້ນດ້ວຍທີ່ພວກເຮົາບໍ່ໄດ້ມອບໝາຍໃຫ້ເພື່ອນບ້ານ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາເຮັດຊ້ໍາການປະຕິບັດນີ້ສໍາລັບອົງປະກອບທີ່ເຊື່ອມຕໍ່ທັງຫມົດ.

ຖ້າມີຂອບລະຫວ່າງຈຸດທີ່ຕົກຢູ່ໃນການແບ່ງປັນດຽວກັນ, ມັນບໍ່ຍາກທີ່ຈະຊອກຫາວົງຈອນຄີກໃນກາຟ, ເຊິ່ງເປັນທີ່ຮູ້ຈັກກັນຢ່າງກວ້າງຂວາງ (ແລະແນ່ນອນ) ເປັນໄປບໍ່ໄດ້ໃນກາຟ bipartite. ຖ້າບໍ່ດັ່ງນັ້ນ, ພວກເຮົາມີການແບ່ງປັນທີ່ຖືກຕ້ອງ, ຊຶ່ງຫມາຍຄວາມວ່າເສັ້ນສະແດງແມ່ນ bipartite.

ໂດຍປົກກະຕິ, ສູດການຄິດໄລ່ນີ້ຖືກປະຕິບັດໂດຍໃຊ້ ຄວາມກວ້າງຂອງການຄົ້ນຫາຄັ້ງທໍາອິດ ຫຼື ຄວາມ​ເລິກ​ການ​ຄົ້ນ​ຫາ​ຄັ້ງ​ທໍາ​ອິດ​. ໃນພາສາທີ່ຈໍາເປັນ, ການຄົ້ນຫາແບບເລິກຄັ້ງທໍາອິດມັກຈະຖືກນໍາໃຊ້ຍ້ອນວ່າມັນງ່າຍດາຍເລັກນ້ອຍແລະບໍ່ຈໍາເປັນຕ້ອງມີໂຄງສ້າງຂໍ້ມູນເພີ່ມເຕີມ. ຂ້ອຍຍັງໄດ້ເລືອກການຄົ້ນຫາຄວາມເລິກ - ທໍາອິດຍ້ອນວ່າມັນເປັນແບບດັ້ງເດີມຫຼາຍ.

ດັ່ງນັ້ນ, ພວກເຮົາມາຮອດໂຄງການດັ່ງຕໍ່ໄປນີ້. ພວກເຮົາຜ່ານຈຸດຕັ້ງຂອງກາຟໂດຍໃຊ້ການຄົ້ນຫາຄວາມເລິກຄັ້ງທໍາອິດແລະມອບຫມາຍການແບ່ງປັນໃຫ້ພວກເຂົາ, ປ່ຽນຈໍານວນສ່ວນແບ່ງໃນຂະນະທີ່ພວກເຮົາຍ້າຍອອກໄປຕາມແຄມ. ຖ້າພວກເຮົາພະຍາຍາມມອບສ່ວນແບ່ງໃຫ້ກັບຈຸດສູງສຸດທີ່ມີສ່ວນແບ່ງທີ່ຖືກມອບຫມາຍແລ້ວ, ພວກເຮົາສາມາດເວົ້າໄດ້ຢ່າງປອດໄພວ່າກາຟບໍ່ແມ່ນ bipartite. ໃນປັດຈຸບັນຈຸດຕັ້ງທັງຫມົດຖືກມອບຫມາຍສ່ວນແບ່ງແລະພວກເຮົາໄດ້ເບິ່ງຢູ່ແຄມທັງຫມົດ, ພວກເຮົາມີການແບ່ງປັນທີ່ດີ.

ຄວາມບໍລິສຸດຂອງການຄິດໄລ່

ໃນ Haskell ພວກເຮົາສົມມຸດວ່າການຄິດໄລ່ທັງຫມົດແມ່ນ ສະອາດ. ຢ່າງໃດກໍຕາມ, ຖ້ານີ້ແມ່ນກໍລະນີຢ່າງແທ້ຈິງ, ພວກເຮົາຈະບໍ່ມີທາງທີ່ຈະພິມສິ່ງໃດໃນຫນ້າຈໍ. ທັງໝົດ, ສະອາດ ການ​ຄິດ​ໄລ່​ແມ່ນ lazy ນັ້ນ​ວ່າ​ບໍ່​ມີ​ຫນຶ່ງ​ ສະອາດ ເຫດຜົນໃນການຄິດໄລ່ບາງສິ່ງບາງຢ່າງ. ການຄິດໄລ່ທັງໝົດທີ່ເກີດຂຶ້ນໃນໂຄງການແມ່ນຖືກບັງຄັບໃຫ້ເຂົ້າໃສ່ໃນບາງວິທີ "ບໍ່ສະອາດ" Monad IO.

Monads ແມ່ນວິທີການເປັນຕົວແທນການຄິດໄລ່ກັບ ຜົນກະທົບ ໃນ Haskell. ການອະທິບາຍວ່າພວກເຂົາເຮັດວຽກແນວໃດແມ່ນເກີນຂອບເຂດຂອງໂພສນີ້. ຄໍາອະທິບາຍທີ່ດີແລະຊັດເຈນສາມາດອ່ານເປັນພາສາອັງກິດ ທີ່ນີ້.

ໃນທີ່ນີ້ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະຊີ້ໃຫ້ເຫັນວ່າໃນຂະນະທີ່ບາງ monads, ເຊັ່ນ IO, ໄດ້ຖືກປະຕິບັດໂດຍຜ່ານການ compiler magic, ເກືອບທັງຫມົດອື່ນໆໄດ້ຖືກປະຕິບັດໃນຊອບແວແລະການຄິດໄລ່ທັງຫມົດໃນພວກມັນແມ່ນບໍລິສຸດ.

ມີຫຼາຍຜົນກະທົບແລະແຕ່ລະຄົນມີ monad ຂອງຕົນເອງ. ນີ້ແມ່ນທິດສະດີທີ່ເຂັ້ມແຂງແລະສວຍງາມຫຼາຍ: monads ທັງຫມົດປະຕິບັດການໂຕ້ຕອບດຽວກັນ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບສາມ monads ດັ່ງຕໍ່ໄປນີ້:

• ທັງ e a ແມ່ນການຄິດໄລ່ທີ່ໃຫ້ຄ່າຂອງປະເພດ a ຫຼືຖິ້ມຂໍ້ຍົກເວັ້ນຂອງປະເພດ e. ພຶດຕິກໍາຂອງ monad ນີ້ແມ່ນຄ້າຍຄືກັນກັບການຈັດການຂໍ້ຍົກເວັ້ນໃນພາສາທີ່ຈໍາເປັນ: ຄວາມຜິດພາດສາມາດຖືກຈັບໄດ້ຫຼືສົ່ງຕໍ່. ຄວາມແຕກຕ່າງຕົ້ນຕໍແມ່ນວ່າ monad ໄດ້ຖືກປະຕິບັດຢ່າງສົມບູນໃນຫ້ອງສະຫມຸດມາດຕະຖານໃນ Haskell, ໃນຂະນະທີ່ພາສາ imperative ປົກກະຕິແລ້ວໃຊ້ກົນໄກຂອງລະບົບປະຕິບັດການ.
• ລັດ s a ແມ່ນການຄິດໄລ່ທີ່ສົ່ງຄືນຄ່າຂອງປະເພດ a ແລະມີການເຂົ້າເຖິງສະຖານະຂອງປະເພດ s.
• ບາງທີ ກ. The Maybe monad ສະແດງອອກການຄິດໄລ່ທີ່ສາມາດຂັດຂວາງໄດ້ທຸກເວລາໂດຍການກັບຄືນບໍ່ມີຫຍັງ. ຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາຈະເວົ້າກ່ຽວກັບການປະຕິບັດຂອງຫ້ອງຮຽນ MonadPlus ສໍາລັບປະເພດ Maybe, ເຊິ່ງສະແດງຜົນກົງກັນຂ້າມ: ມັນເປັນການຄິດໄລ່ທີ່ສາມາດຂັດຂວາງໄດ້ທຸກເວລາໂດຍການສົ່ງຄືນຄ່າສະເພາະ.

ການ​ປະ​ຕິ​ບັດ​ຂອງ algorithm​

ພວກເຮົາມີຂໍ້ມູນສອງປະເພດຄື Graph a ແລະ Bigraph a b, ອັນທຳອິດສະແດງເຖິງກຣາຟທີ່ມີແນວຕັ້ງຕິດສະຫຼາກດ້ວຍຄ່າຂອງປະເພດ a, ແລະອັນທີສອງສະແດງເຖິງກຣາຟ bipartite ທີ່ມີຈຸດຕັ້ງດ້ານຊ້າຍຕິດສະຫຼາກດ້ວຍຄ່າຂອງປະເພດ a ແລະຂວາ. -side vertices ຕິດ​ສະ​ຫຼາກ​ທີ່​ມີ​ຄຸນ​ຄ່າ​ຂອງ​ປະ​ເພດ b​.

ເຫຼົ່ານີ້ບໍ່ແມ່ນປະເພດຈາກຫ້ອງສະຫມຸດ Alga. Alga ບໍ່ມີການເປັນຕົວແທນຂອງກາຟ bipartite ທີ່ບໍ່ມີທິດທາງ. ຂ້າພະເຈົ້າໄດ້ເຮັດປະເພດນີ້ເພື່ອຄວາມຊັດເຈນ.

ພວກເຮົາຍັງຕ້ອງການຫນ້າທີ່ຜູ້ຊ່ວຍທີ່ມີລາຍເຊັນຕໍ່ໄປນີ້:

-- Список соседей данной вершины.
neighbours :: Ord a => a -> Graph a -> [a]

-- Построить двудольный граф по графу и функции, для каждой вершины
-- выдающей её долю и пометку в новой доле, игнорируя конфликтные рёбра.
toBipartiteWith :: (Ord a, Ord b, Ord c) => (a -> Either b c)
                                         -> Graph a
                                         -> Bigraph b c

-- Список вершин в графе
vertexList :: Ord a => Graph a -> [a]
Сигнатура функции, которую мы будем писать, выглядит так:

type OddCycle a = [a]
detectParts :: Ord a => Graph a -> Either (OddCycle a) (Bigraph a a)

ມັນເປັນເລື່ອງງ່າຍທີ່ຈະເຫັນວ່າຖ້າໃນລະຫວ່າງການຄົ້ນຫາຄວາມເລິກຄັ້ງທໍາອິດພວກເຮົາພົບເຫັນຂອບເຂດທີ່ຂັດແຍ້ງກັນ, ວົງຈອນຄີກຢູ່ເທິງສຸດຂອງ stack recursion. ດັ່ງນັ້ນ, ເພື່ອຟື້ນຟູມັນ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຕັດທຸກສິ່ງທຸກຢ່າງອອກຈາກ stack recursion ເຖິງການປະກົດຕົວຄັ້ງທໍາອິດຂອງ vertex ສຸດທ້າຍ.

ພວກເຮົາປະຕິບັດການຄົ້ນຫາຄວາມເລິກຄັ້ງທໍາອິດໂດຍການຮັກສາ array ສະມາຄົມຂອງຕົວເລກການແບ່ງປັນສໍາລັບແຕ່ລະຈຸດ. stack recursion ຈະຖືກຮັກສາໄວ້ໂດຍອັດຕະໂນມັດໂດຍຜ່ານການປະຕິບັດຂອງ Functor class ຂອງ monad ທີ່ພວກເຮົາໄດ້ເລືອກ: ພວກເຮົາຈະຕ້ອງການພຽງແຕ່ເອົາຈຸດຕັ້ງທັງຫມົດຈາກເສັ້ນທາງເຂົ້າໄປໃນຜົນໄດ້ຮັບທີ່ສົ່ງຄືນຈາກຫນ້າທີ່ recursive.

ຄວາມຄິດທໍາອິດຂອງຂ້ອຍແມ່ນໃຊ້ Either monad, ເຊິ່ງເບິ່ງຄືວ່າຈະປະຕິບັດຜົນກະທົບທີ່ພວກເຮົາຕ້ອງການ. ການປະຕິບັດຄັ້ງທໍາອິດທີ່ຂ້ອຍຂຽນແມ່ນໃກ້ຊິດກັບທາງເລືອກນີ້. ໃນຄວາມເປັນຈິງ, ຂ້າພະເຈົ້າມີຫ້າການປະຕິບັດທີ່ແຕກຕ່າງກັນຢູ່ໃນຈຸດຫນຶ່ງແລະໃນທີ່ສຸດກໍ່ໄດ້ຕົກລົງກັບອີກອັນຫນຶ່ງ.

ຫນ້າທໍາອິດ, ພວກເຮົາຈໍາເປັນຕ້ອງຮັກສາ array ສະມາຄົມຂອງຕົວລະບຸການແບ່ງປັນ - ນີ້ແມ່ນບາງສິ່ງບາງຢ່າງກ່ຽວກັບລັດ. ອັນທີສອງ, ພວກເຮົາຈໍາເປັນຕ້ອງສາມາດຢຸດເຊົາໃນເວລາທີ່ການຂັດແຍ້ງໄດ້ຖືກກວດພົບ. ນີ້ສາມາດເປັນ Monad ສໍາລັບທັງສອງ, ຫຼື MonadPlus ສໍາລັບບາງທີ. ຄວາມແຕກຕ່າງທີ່ ສຳ ຄັນແມ່ນວ່າທັງສອງສາມາດສົ່ງຄືນຄ່າໄດ້ຖ້າການຄິດໄລ່ບໍ່ໄດ້ຖືກຢຸດ, ແລະບາງທີອາດຈະສົ່ງຄືນພຽງແຕ່ຂໍ້ມູນກ່ຽວກັບເລື່ອງນີ້ໃນກໍລະນີນີ້. ເນື່ອງຈາກພວກເຮົາບໍ່ຕ້ອງການຄ່າແຍກຕ່າງຫາກສໍາລັບຄວາມສໍາເລັດ (ມັນຖືກເກັບໄວ້ໃນລັດ), ພວກເຮົາເລືອກບາງທີ. ແລະໃນປັດຈຸບັນໃນເວລາທີ່ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ສົມທົບຜົນກະທົບຂອງສອງ monads, ພວກເຂົາເຈົ້າອອກມາ monad transformers, ທີ່ຊັດເຈນສົມທົບຜົນກະທົບເຫຼົ່ານີ້.

ເປັນຫຍັງຂ້ອຍຈຶ່ງເລືອກປະເພດສະລັບສັບຊ້ອນດັ່ງກ່າວ? ສອງເຫດຜົນ. ປະການທໍາອິດ, ການປະຕິບັດໄດ້ກາຍເປັນຄ້າຍຄືກັນກັບຄວາມຈໍາເປັນ. ອັນທີສອງ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຫມູນໃຊ້ຄ່າກັບຄືນໃນກໍລະນີຂອງຄວາມຂັດແຍ້ງໃນເວລາທີ່ກັບຄືນມາຈາກການ recursion ເພື່ອຟື້ນຟູ loop odd, ເຊິ່ງງ່າຍກວ່າທີ່ຈະເຮັດໃນ Maybe monad.

ດັ່ງນັ້ນພວກເຮົາໄດ້ຮັບການປະຕິບັດນີ້.

{-# LANGUAGE ExplicitForAll #-}
{-# LANGUAGE ScopedTypeVariables #-}

data Part = LeftPart | RightPart

otherPart :: Part -> Part
otherPart LeftPart  = RightPart
otherPart RightPart = LeftPart

type PartMap a = Map.Map a Part
type OddCycle a = [a]

toEither :: Ord a => PartMap a -> a -> Either a a
toEither m v = case fromJust (v `Map.lookup` m) of
                    LeftPart  -> Left  v
                    RightPart -> Right v

type PartMonad a = MaybeT (State (PartMap a)) [a]

detectParts :: forall a. Ord a => Graph a -> Either (OddCycle a) (Bigraph a a)
detectParts g = case runState (runMaybeT dfs) Map.empty of
                     (Just c, _)  -> Left  $ oddCycle c
                     (Nothing, m) -> Right $ toBipartiteWith (toEither m) g
    where
        inVertex :: Part -> a -> PartMonad a
        inVertex p v = ((:) v) <$> do modify $ Map.insert v p
                                      let q = otherPart p
                                      msum [ onEdge q u | u <- neigbours v g ]

        {-# INLINE onEdge #-}
        onEdge :: Part -> a -> PartMonad a
        onEdge p v = do m <- get
                        case v `Map.lookup` m of
                             Nothing -> inVertex p v
                             Just q  -> do guard (q /= p)
                                           return [v]

        processVertex :: a -> PartMonad a
        processVertex v = do m <- get
                             guard (v `Map.notMember` m)
                             inVertex LeftPart v

        dfs :: PartMonad a
        dfs = msum [ processVertex v | v <- vertexList g ]

        oddCycle :: [a] -> [a]
        oddCycle c = tail (dropWhile ((/=) last c) c)

ບ່ອນທີ່ຕັນແມ່ນຫຼັກຂອງ algorithm. ຂ້າພະເຈົ້າຈະພະຍາຍາມອະທິບາຍສິ່ງທີ່ເກີດຂຶ້ນພາຍໃນມັນ.

• inVertex ແມ່ນສ່ວນຫນຶ່ງຂອງການຄົ້ນຫາຄວາມເລິກຄັ້ງທໍາອິດທີ່ພວກເຮົາໄປຢ້ຽມຢາມ vertex ເປັນຄັ້ງທໍາອິດ. ໃນທີ່ນີ້ພວກເຮົາມອບຫມາຍເລກສ່ວນແບ່ງໃຫ້ກັບຈຸດສູງສຸດແລະດໍາເນີນການ onEdge ໃນເພື່ອນບ້ານທັງຫມົດ. ນີ້ແມ່ນບ່ອນທີ່ພວກເຮົາຟື້ນຟູການເອີ້ນ stack: ຖ້າ msum ສົ່ງຄືນຄ່າ, ພວກເຮົາຍູ້ vertex v ຢູ່ທີ່ນັ້ນ.
• onEdge ແມ່ນພາກສ່ວນທີ່ພວກເຮົາໄປຢ້ຽມຢາມຂອບ. ມັນຖືກເອີ້ນວ່າສອງຄັ້ງສໍາລັບແຕ່ລະຂອບ. ໃນທີ່ນີ້ພວກເຮົາກວດເບິ່ງວ່າ vertex ໃນອີກດ້ານຫນຶ່ງໄດ້ຖືກໄປຢ້ຽມຢາມ, ແລະໄປຢ້ຽມຢາມມັນຖ້າບໍ່ແມ່ນ. ຖ້າໄດ້ໄປຢ້ຽມຢາມ, ພວກເຮົາກວດເບິ່ງວ່າຂອບແມ່ນຂັດກັນບໍ. ຖ້າມັນເປັນ, ພວກເຮົາສົ່ງຄືນຄ່າ - ເທິງສຸດຂອງ stack recursion, ບ່ອນທີ່ຍອດອື່ນໆທັງຫມົດຈະຖືກວາງໄວ້ເມື່ອກັບຄືນ.
• processVertex ກວດເບິ່ງແຕ່ລະ vertex ວ່າມັນໄດ້ຖືກໄປຢ້ຽມຢາມແລະດໍາເນີນການ inVertex ໃສ່ມັນຫຼືບໍ່.
• dfs ແລ່ນ processVertex ໃນຈຸດຕັ້ງທັງຫມົດ.

ຫມົດ​ເທົ່າ​ນີ້.

ປະຫວັດຂອງຄໍາສັບ INLINE

ຄໍາວ່າ INLINE ບໍ່ໄດ້ຢູ່ໃນການປະຕິບັດຄັ້ງທໍາອິດຂອງ algorithm; ມັນປາກົດຕໍ່ມາ. ເມື່ອຂ້ອຍພະຍາຍາມຊອກຫາການປະຕິບັດທີ່ດີກວ່າ, ຂ້ອຍພົບວ່າສະບັບທີ່ບໍ່ແມ່ນ INLINE ແມ່ນຊ້າລົງຢ່າງເຫັນໄດ້ຊັດໃນບາງກາຟ. ພິຈາລະນາວ່າຫນ້າ semantic ຄວນເຮັດວຽກຄືກັນ, ນີ້ເຮັດໃຫ້ຂ້ອຍປະຫລາດໃຈຫລາຍ. ເຖິງແມ່ນວ່າຄົນແປກຫນ້າ, ໃນເຄື່ອງອື່ນທີ່ມີ GHC ຮຸ່ນທີ່ແຕກຕ່າງກັນບໍ່ມີຄວາມແຕກຕ່າງທີ່ສັງເກດເຫັນ.

ຫຼັງຈາກໃຊ້ເວລາຫນຶ່ງອາທິດໃນການອ່ານຜົນຜະລິດ GHC Core, ຂ້ອຍສາມາດແກ້ໄຂບັນຫາທີ່ມີເສັ້ນຫນຶ່ງຂອງ INLINE ຢ່າງຊັດເຈນ. ໃນບາງຈຸດລະຫວ່າງ GHC 8.4.4 ແລະ GHC 8.6.5, optimizer ຢຸດເຮັດສິ່ງນີ້ດ້ວຍຕົວມັນເອງ.

ຂ້າພະເຈົ້າບໍ່ໄດ້ຄາດຫວັງວ່າຈະພົບກັບຝຸ່ນດັ່ງກ່າວໃນການຂຽນໂປລແກລມ Haskell. ຢ່າງໃດກໍຕາມ, ເຖິງແມ່ນວ່າໃນມື້ນີ້, ບາງຄັ້ງຜູ້ເພີ່ມປະສິດທິພາບເຮັດຜິດພາດ, ແລະມັນເປັນວຽກຂອງພວກເຮົາທີ່ຈະໃຫ້ຄໍາແນະນໍາໃຫ້ເຂົາເຈົ້າ. ຕົວຢ່າງ, ໃນທີ່ນີ້ພວກເຮົາຮູ້ວ່າຫນ້າທີ່ຄວນຈະຢູ່ໃນເສັ້ນເນື່ອງຈາກວ່າມັນຖືກ inlined ໃນສະບັບ imperative, ແລະນີ້ແມ່ນເຫດຜົນທີ່ຈະໃຫ້ compiler ຄໍາແນະນໍາ.

ເກີດຫຍັງຂຶ້ນຕໍ່ໄປ?

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ປະຕິບັດວິທີການ Hopcroft-Karp ກັບ monads ອື່ນໆ, ແລະນັ້ນແມ່ນຈຸດສິ້ນສຸດຂອງໂຄງການ.

ຂໍຂອບໃຈກັບ Google Summer of Code, ຂ້ອຍໄດ້ຮັບປະສົບການປະຕິບັດໃນການຂຽນໂປຼແກຼມທີ່ເປັນປະໂຫຍດ, ເຊິ່ງບໍ່ພຽງແຕ່ຊ່ວຍໃຫ້ຂ້ອຍໄດ້ຝຶກງານຢູ່ Jane Street ໃນຊ່ວງລຶະເບິ່ງຮ້ອນຕໍ່ໄປ (ຂ້ອຍບໍ່ແນ່ໃຈວ່າສະຖານທີ່ນີ້ເປັນທີ່ຮູ້ຈັກດີປານໃດເຖິງແມ່ນວ່າໃນກຸ່ມຜູ້ຊົມທີ່ມີຄວາມຮູ້ຂອງ Habr, ແຕ່ວ່າມັນແມ່ນບ່ອນດຽວ. ສອງສາມບ່ອນທີ່ເຈົ້າສາມາດດໍາເນີນໂຄງການທີ່ມີປະສິດຕິພາບໃນລະດູຮ້ອນ), ແຕ່ຍັງໄດ້ແນະນໍາຂ້ອຍໄປສູ່ໂລກທີ່ຍອດຢ້ຽມຂອງການນໍາໃຊ້ຄໍາຂວັນນີ້ໃນການປະຕິບັດ, ເຊິ່ງແຕກຕ່າງຈາກປະສົບການຂອງຂ້ອຍໃນພາສາພື້ນເມືອງ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com