thắc mắc [Học tập] Toán Rời Rạc trong cuộc đời lập trình viên

Biết bao nhiêu sinh viên ù ù cạc cạc mất phương hướng vì môn C++ ở trường Đại Học không ?
Ở Havard họ dạy hết 2 môn Computer Science cũng chả thấy đả động gì đến pointer đâu
Ra trường anh đi làm code C++ được bao nhiêu năm mà cứ tỏ ra nguy hiểm thế :ops:
Giờ ở Tây môn Low Level Programming tức dạy về Pointer của C++ họ dạy ở năm gần cuối chứ không phải dạy ngay từ đầu như Việt Nam
Mời anh xem khoá CS50 rất nổi tiếng của Havard xem họ dạy ngôn ngữ gì đầu tiên và con trỏ ở bài thứ mấy.

Nhân tiện, anh nào muốn bắt đầu học lập trình thì nên bắt đầu với CS50 là tốt nhất :rolleyes:
 
Rồi ra đi làm bao nhiêu người ứng dụng vào làm rồi. Coder ở VN toàn code web, mobile ứng dụng thế nào vậy bạn? Viết ra để hù dọa người ta à?



Lý thuyết đồ thị ứng dụng vào xử lý ngôn ngữ, AI, ML thế nào vậy bạn? Nó có ứng dụng đó nhưng ra đời đi làm ko phải ai cũng đụng tới. Biết gì về xử lý ngôn ngữ, AI, ML ko mà chém. :shame:

Hỏi thật thím đi làm bao năm rồi và ứng dụng toán rời rạc đc nhiều thế nào mà nói là cực kỳ quan trọng.
Chắc ứng dụng bằng cách dạy lại cho sing viên đó thím ơi :big_smile::big_smile:

Sent from Jarvis via nextVOZ
 
Học con trỏ luôn đi rồi đá sang golang đợi thời tới thôi :rolleyes:
Còn mê oop quá thì học java ngay từ đầu cho rồi.
 
C ko học contro thì học nó làm gì vậy ? Ai có điều kiện thì tốt nhất hãy học hết. Kiến thức mức căn bản ko hề cao siêu. Tự học trên gg ko thiếu thứ gì. Ko phải bằng cấp nhưng kiến thức thì cần.
Lập trình viên chí ít phải hiểu được cái máy chạy ntn ? Rồi dần dần giải thích được tại sao ko được lạm dụng cái này cái chai. ( Đệ quy ...abcxyz). Cứ bảo công việc ko cần ko học phế vkl. Hãy hiểu đang viết gì ... Và dưới cái đang viết là gì thì tốt hơn.
mãi rồi cũng thấy trên voz có member có suy nghĩ giống mình :-*
 
mãi rồi cũng thấy trên voz có member có suy nghĩ giống mình :-*
Chỉ tiếc giờ anh em thích tàu nhanh. Chẳng cần hiểu lạm dụng ngôn ngữ ....rồi đến fw and fw. Đến mệt ...
Mới hôm trước kèm một nhóc năm 3 CNTT. Thực sự thấy oải , nghe nó kể thầy vô tâm vs nghề vãi ra. Các thầy giờ mải kiếm tiền quên thế hệ trẻ.
 
Chỉ tiếc giờ anh em thích tàu nhanh. Chẳng cần hiểu lạm dụng ngôn ngữ ....rồi đến fw and fw. Đến mệt ...
Mới hôm trước kèm một nhóc năm 3 CNTT. Thực sự thấy oải , nghe nó kể thầy vô tâm vs nghề vãi ra. Các thầy giờ mải kiếm tiền quên thế hệ trẻ.
mình ngày xưa được gặp cô giáo có tâm, nên cứ tập trung học căn bản ( may main của mình là C) nên tiếp xúc vấn đề và ngôn ngữ mới nhanh lắm :D
 
Last edited:
mình ngày xưa được gặp cô giáo có tâm, nên cứ tập trung học căn bản ( mày main của mình là C) nên tiếp xúc vấn đề và ngôn ngữ mới nhanh lắm :D
thí chủ có fb hay kênh nào chém gió như tele ko nhể. A em t a đêm khuya đàm đạo tí về vụ C.
 
hồi mới ra trường đi làm, mình có suy nghĩ kiểu kiến thức ở trường lớp quá "hàn lâm" không có tính thực chiến cao. Mình còn tranh luận với cả anh lead về những câu hỏi anh phỏng vấn, rằng em làm ở cty vài năm rồi, nhưng chưa bao h đụng tới kiến thức mà a phỏng vấn cả. Mà các kiến thức đó google cả đống. Nhớ làm gì.
Hồi đó mình chủ yếu code outsource, học framework, và code mấy cái CRUD quản lý. Trong khi deadline thì liên tọi, và mình cho rằng quan trọng là 1 người làm được những task gì, trong thời gian bao lâu, đó mới là value của người đó trong dự án.
Sau này mình nhảy sang làm công ty khác, và dần dần vài năm trôi qua, mindset mình bắt đầu thay đổi, mình thấy kiến thức ở trường lớp có giá trị. Và khoảng cách về trình độ giữa các dev bắt đầu hình thành. (dù xuất phát điểm đều giống nhau). Lúc rảnh mình bắt đầu đọc lại các kiến thức ngày xưa được dạy, mà hơi lơ là vì hồi đó không hiểu ý nghĩa của chúng. Ví dụ như môn Hệ Phân Tán, nó trình bày các vấn đề của 1 hệ thống, mà giờ hệ thống nào cũng có, cluster, distribution system.
Rồi mình đọc lại về mô hình OSI 7 tầng, để biết nên lựa chọn xử lý ở tầng nào sẽ cho performance cao nhất. Rồi học lại Hệ điều hành,để biết tại sao EBS lại cho performance cao hơn NFS.
Và tất nhiên cả môn Toán Rời Rạc, Và Cấu trúc dữ liệu và giải thuật, cũng phải đọc lại. Khi xử lý với dữ liệu lớn, thì bắt đầu quan tâm tới cấu trúc, và giải thuật nhiều hơn
 
Để tôi kể cho các bạn trường hợp cái app dưới sign tôi đang làm xem nó có cần học thuật toán hay không.

Nói đến cái webapp của tôi, thì nó là một cái công cụ dịch máy tiếng tàu. Nghe dịch máy thì rõ oai, nhưng về bản chất là thay thế 1:1 từ tiếng trung sang tiếng việt, ví dụ 程序员=>lập trình viên hay 码农=>code monkey... cho nên cái quan trọng nhất là dữ liệu từ điển đúng đắn đầy đủ, chứ không là thuật toán thông minh.

ví dụ kết quả cụ thể cho các bạn tham khảo: https://chivi.xyz/~dai-phung-da-canh-nhan/-chuong-162-lau-nam-ban-an-cu-xbiquge-36253791

chuyện nó chẳng có gì, nếu như không nói đến việc dữ liệu từ điển nó nằm tầm 500k tới 1 triệu entries, mỗi entries dài từ 1 tới hơn 10 ký tự, và độ dài của input tiếng chung thường từ một chương 4000 chữ tới cả bộ vài triệu chữ (bộ dài nhất tôi đọc có khoảng 18 triệu chữ)... nếu không dùng algo + data structure, thì đảm bảo kết quả sẽ vô cùng khó đỡ.

khi tôi làm cái chivi này, từng có một bạn liên hệ với tôi qua fb hỏi là mình cũng làm một cái tương tự cũng gần năm năm rồi, nhưng mà ra kết quả rất chậm dù rằng chỉ có 30k entries (bổ xung: riêng hán việt đã khoảng hơn 12k entries rồi, 30k entries hầu như chỉ chứa những từ phổ biến nhất, hoàn toàn không đủ).

hỏi ra mới biết là cách bạn ấy dịch rất trực quan: chạy một vòng lặp cho tất cả cặp từ trung/việt có sẵn trong từ điển, với mỗi cặp thì lại dùng hàm replace thay thế tất cả cụm trung ở trên bằng cụm việt... thực ra thì nếu chỉ có 30k từ, cho input dài 4k chữ thì nó cũng không nhiều, dù là cái server ghẻ lở thì cũng có khả năng ra kết quả sau một vài giây...

vấn đề ở đây là bạn này có dùng một cái khác gọi là "luật nhân", nói nôm na là một kiểu ngữ pháp tiếng trung, ghép lại vài cụm từ được đánh dấu danh động tĩnh các kiểu thành một cụm từ mới với cấu trúc thuần việt hơn... ờ giải thích hơi dài dòng, tóm lại thì các bạn hiểu đơn giản là phép "nhân" này biến 30k entries thành 300k thậm chí nhiều hơn, và kết quả là....

(p/s: ngoài mấy cái webapp thì trước đó có một cái desktop app gọi là QuickTranslator, và tôi cũng được nghe kể những trải nghiệm "rùng rợn" của một số bạn lạm dụng công cụ này, ví dụ 1 triệu entries từ điển x 100+ "luật nhân", nghe nói dịch một chương truyện 5k chữ thôi cũng có thể tính bằng tiếng, ăn hơn chục GB ram)

Tôi nghe loáng thoáng cũng có vài người có giải pháp tốt hơn tí, kiểu như chạy một vòng lặp duyệt cái dữ liệu input, rồi trích ra các substring (độ dài < 10 gì đấy), nếu tìm được cụm từ việt phù hợp thì lưu kết quả vào, rồi nhảy qua độ dài cụm từ trung vừa thấy... về cơ bản thì khá ổn, ngoại trừ hai chuyện là mỗi index của string đầu vào)đều phải trích ra khoảng 10 substring gì đấy rồi tìm nghĩa việt, mà tìm nghĩa việt thì tuy dùng hash_map đúng là O(1) thật, nhưng thực tế cũng không đơn giản như vậy (hashing khá tốn kém). Vấn đề thứ hai là chạy từ trái sang phải như thế không hẳn là cách tốt nhất, vì có từ cần được ưu tiên hơn từ khác; ví dụ thành ngữ thường có 4 ký tự trở lên, hoặc tên người; chỉ dịch từ trái sang phải không ra được kết quả dịch tốt nhất có thể...

Các bạn có giải pháp gì tối ưu hơn có thể vào đây chém gió, cần thiết tôi có thể đưa thêm input (một file dữ liệu từ và một file text vài MB), tôi thấy đây là bài toán khá thú vị mặc dù cấu trúc dữ liệu tối ưu (mà tôi biết) thực ra cũng khá đơn giản :"> Lần cuối cùng tôi test thì thuật toán của tôi với dữ liệu là 200k từ + 10MB text file thì mất tầm 10s để dịch xong toàn bộ (bằng nodejs), kể ra cũng khá ổn, nhưng vẫn hóng xem có bạn nào nghĩ ra giải pháp hay hơn không :">
 
Last edited:
chắc là prefix trie gì à
68747470733a2f2f692e696d6775722e636f6d2f6b493461396c482e6a7067
bèo vậy
68747470733a2f2f692e696d6775722e636f6d2f6b493461396c482e6a7067
 

Mấy môn CS thì môn nào sau này cũng có tính ứng dụng cả :)

tôi thì ko phan đối gì về mấy môn cơ sở này, chỉ có cái ai chưa đi làm hay học làng nhàng, mà thấy mấy ông kia nghe bảo mấy môn cơ sở quan trọng ko apply job ngay bây giờ dc thì cứ nhu bác này apply đi làm rồi sau này ôn lại.

Học ở ĐH chỉ để qua môn, sau này đi làm học lại mới thấy giá trị. IT này nó rộng, ai pro ko nói chứ học trước quên sau nhiều đi làm rồi + áp dụng dc thì mới thấy mấy kiến thức đó giá trị.
 
Last edited:
chắc là prefix trie gì à
68747470733a2f2f692e696d6775722e636f6d2f6b493461396c482e6a7067
bèo vậy
68747470733a2f2f692e696d6775722e636f6d2f6b493461396c482e6a7067


Nghe sơ thì tôi cũng nghĩ là dùng trie, mặc dù vẫn chưa hiểu lắm mấy cái luật nhân ông ấy nói, nhưng tôi đoán là khi hai từ tiếng Trung đứng cạnh nhau sẽ đưa ra 1 nghĩa mới.
Ví dụ từ T1 có nghĩa V1, T2 có nghĩa V2 , nhưng T1 T2 thì ko dịch là V1 V2 mà dịch qua V3 chẳng hạn.
Nếu thế thì dùng trie là hợp lý
 
Để tôi kể cho các bạn trường hợp cái app dưới sign tôi đang làm xem nó có cần học thuật toán hay không.

Nói đến cái webapp của tôi, thì nó là một cái công cụ dịch máy tiếng tàu. Nghe dịch máy thì rõ oai, nhưng về bản chất là thay thế 1:1 từ tiếng trung sang tiếng việt, ví dụ 程序员=>lập trình viên hay 码农=>code monkey... cho nên cái quan trọng nhất là dữ liệu từ điển đúng đắn đầy đủ, chứ không là thuật toán thông minh.

ví dụ kết quả cụ thể cho các bạn tham khảo: https://chivi.xyz/~dai-phung-da-canh-nhan/chuong-162-lau-nam-ban-an-cu-xbiquge-36253791

chuyện nó chẳng có gì, nếu như không nói đến việc dữ liệu từ điển nó nằm tầm 500k tới 1 triệu entries, mỗi entries dài từ 1 tới hơn 10 ký tự, và độ dài của input tiếng chung thường từ một chương 4000 chữ tới cả bộ vài triệu chữ (bộ dài nhất tôi đọc có khoảng 18 triệu chữ)... nếu không dùng algo + data structure, thì đảm bảo kết quả sẽ vô cùng khó đỡ.

khi tôi làm cái chivi này, từng có một bạn liên hệ với tôi qua fb hỏi là mình cũng làm một cái tương tự cũng gần năm năm rồi, nhưng mà ra kết quả rất chậm dù rằng chỉ có 30k entries (bổ sung: riêng hán việt đã khoảng hơn 12k entries rồi, 30k entries hầu như chỉ chứa những từ phổ biến nhất, hoàn toàn không đủ).

hỏi ra mới biết là cách bạn ấy dịch rất trực quan: chạy một vòng lặp cho tất cả cặp từ trung/việt có sẵn trong từ điển, với mỗi cặp thì lại dùng hàm replace thay thế tất cả cụm trung ở trên bằng cụm việt... thực ra thì nếu chỉ có 30k từ, cho input dài 4k chữ thì nó cũng không nhiều, tính theo "step" chắc cũng chỉ khoảng 300k tới 400k, dù là cái server ghẻ lở thì cũng có khả năng ra kết quả sau một vài giây...

vấn đề ở đây là bạn này có dùng một cái khác gọi là "luật nhân", nói nôm na là một kiểu ngữ pháp tiếng trung, ghép lại vài cụm từ được đánh dấu danh động tĩnh các kiểu thành một cụm từ mới với cấu trúc thuần việt hơn... ờ giải thích hơi dài dòng, tóm lại thì các bạn hiểu đơn giản là phép "nhân" này biến 30k entries thành 300k thậm chí nhiều hơn, và kết quả là....

(p/s: ngoài mấy cái webapp thì trước đó có một cái desktop app gọi là QuickTranslator, và tôi cũng được nghe kể những trải nghiệm "rùng rợn" của một số bạn lạm dụng công cụ này, ví dụ 1 triệu entries từ điển x 100+ "luật nhân", nghe nói dịch một chương truyện 5k chữ thôi cũng có thể tính bằng tiếng, ăn hơn chục GB ram)

Tôi nghe loáng thoáng cũng có vài người có giải pháp tốt hơn tí, kiểu như chạy một vòng lặp duyệt cái dữ liệu input, rồi trích ra các substring (độ dài < 10 gì đấy), nếu tìm được cụm từ việt phù hợp thì lưu kết quả vào, rồi nhảy qua độ dài cụm từ trung vừa thấy... về cơ bản thì khá ổn, ngoại trừ hai chuyện là mỗi index của string đầu vào)đều phải trích ra khoảng 10 substring gì đấy rồi tìm nghĩa việt, mà tìm nghĩa việt thì tuy dùng hash_map đúng là O(1) thật, nhưng thực tế cũng không đơn giản như vậy (hashing khá tốn kém). Vấn đề thứ hai là chạy từ trái sang phải như thế không hẳn là cách tốt nhất, vì có từ cần được ưu tiên hơn từ khác; ví dụ thành ngữ thường có 4 ký tự trở lên, hoặc tên người; chỉ dịch từ trái sang phải không ra được kết quả dịch tốt nhất có thể...

Các bạn có giải pháp gì tối ưu hơn có thể vào đây chém gió, cần thiết tôi có thể đưa thêm input (một file dữ liệu từ và một file text vài MB), tôi thấy đây là bài toán khá thú vị mặc dù cấu trúc dữ liệu tối ưu (mà tôi biết) thực ra cũng khá đơn giản :"> Lần cuối cùng tôi test thì thuật toán của tôi với dữ liệu là 200k từ + 10MB text file thì mất tầm 10s để dịch xong toàn bộ (bằng nodejs), kể ra cũng khá ổn, nhưng vẫn hóng xem có bạn nào nghĩ ra giải pháp hay hơn không :">

Khi bài toán quá nhiều exception thì thay vì phát triển 1 thuật toán phức tạp thì cách dùng dữ liệu để trị là hợp lý đấy.

Một hướng đi mà bây giờ người ta hay làm là dùng Deep Learning để dịch. Nói nôm na là cũng dùng dữ liệu để map từ input -> ouput nhưng thay vì map 1:1 kiểu dictionary thì cái input này nó qua neuron network để ra đc ouput. Cái lợi thế là xử lý đc nhiều case phức tạp với lại nó tự học được nếu cho phép người dùng correct lại những chổ nó dịch sai giống như thằng Google Translate vậy.
 
Last edited:
chắc là prefix trie gì à
68747470733a2f2f692e696d6775722e636f6d2f6b493461396c482e6a7067
bèo vậy
68747470733a2f2f692e696d6775722e636f6d2f6b493461396c482e6a7067
bèo vậy thôi nhưng cậu sẽ thấy bất ngờ là trước đó hầu như không có ai dùng =) tôi cũng hỏi vài người khác cũng không thấy ai làm thế. Nghe bảo nguyên nhân là do muốn ưu tiên cụm từ dài, hoặc ưu tiên tên riêng trước, thì sắp xếp từ điển từ dài tới ngắn, tên riêng trước từ chung rồi chạy replace một loạt nó khả thi hơn =)

cho nên tôi ngoài dùng trie còn phải kết hợp với quy hoạch động nữa (tính giá trị của cụm từ bằng độ dài của nó x bonus của từ điển chứa cụm từ đó). Trie thì có thể nhiều người biết, nhưng quy hoạch động thì tôi đảm bảo là hiếm người dùng nó nhuần nhuyễn, thậm chí nhiều khi còn không nghĩ đến việc áp dụng nó vào thực tế luôn :v cho nên mới thấy là ở trường cần học tử tế thì mới ứng dụng vào lúc làm thật được.

btw, còn cái luật nhân, thì các bạn hiểu đại khái là có một danh sách các "rule", mỗi rule trông dạng này 在{0}之前=tại trước {0}, sau đó lúc đọc từ điển thì áp tất cả những từ đã biết với đống luật nhân này, aka rule có 100 cái thì x100 entries =) lại thêm các bạn thêm từ vô tội vạ dữ liệu nguồn có tới gần triệu entries, cho nên kết quả rất là phê :LOL:
 
hỏi ra mới biết là cách bạn ấy dịch rất trực quan: chạy một vòng lặp cho tất cả cặp từ trung/việt có sẵn trong từ điển, với mỗi cặp thì lại dùng hàm replace thay thế tất cả cụm trung ở trên bằng cụm việt... thực ra thì nếu chỉ có 30k từ, cho input dài 4k chữ thì nó cũng không nhiều, tính theo "step" chắc cũng chỉ khoảng 300k tới 400k, dù là cái server ghẻ lở thì cũng có khả năng ra kết quả sau một vài giây...

Chỗ này không hiểu lắm, dùng hàm replace là theo đúng nghĩa đen luôn à? 30k từ là 30k lần replace, mỗi lần replace là phải tìm kiếm chuỗi rồi allocate với copy mem. Phải cỡ 30k * 4k = 120M thao tác là ít.
 
Back
Top