XÁC ĐỊNH BÀI TOÁN
Input → Process → Output
(Dữ liệu vào → Xử lý → Kết quả ra)
Việc xác lập bài toán tức là phải xác lập xem ta phải xử lý yếu tố gì, với giả thiết nào đã cho và giải thuật cần phải đạt những nhu yếu gì. Khác với bài toán thuần túy toán học chỉ cần xác lập rõ giả thiết và Kết luận chứ không cần xác lập nhu yếu về giải thuật, nhiều lúc những bài toán tin học ứng dụng trong thực tiễn chỉ cần tìm giải thuật tốt tới cả nào đó, thậm chí còn là tồi ở mức gật đầu được. Bởi giải thuật tốt nhất yên cầu quá nhiều thời hạn và ngân sách .
Ví dụ:
Khi setup các hàm số phức tạp trên máy tính. Nếu tính bằng cách khai triển chuỗi vô hạn thì độ đúng mực cao hơn nhưng thời hạn chậm hơn hàng tỉ lần so với giải pháp xê dịch. Trên trong thực tiễn việc giám sát luôn luôn được cho phép gật đầu một sai số nào đó nên các hàm số trong máy tính đều được tính bằng chiêu thức giao động của giải tích sốXác định đúng nhu yếu bài toán là rất quan trọng bởi nó tác động ảnh hưởng tới phương pháp xử lý và chất lượng của giải thuật. Một bài toán trong thực tiễn thường cho bởi những thông tin khá mơ hồ và hình thức, ta phải phát biểu lại một cách đúng chuẩn và ngặt nghèo để hiểu đúng bài toán .
Ví dụ:
- Bài toán: Một dự án có n người tham gia thảo luận, họ muốn chia thành các nhóm và mỗi nhóm thảo luận riêng về một phần của dự án. Nhóm có bao nhiêu người thì được trình lên bấy nhiêu ý kiến. Nếu lấy ở mỗi nhóm một ý kiến đem ghép lại thì được một bộ ý kiến triển khai dự án. Hãy tìm cách chia để số bộ ý kiến cuối cùng thu được là lớn nhất.
- Phát biểu lại: Cho một số nguyên dương n, tìm các phân tích n thành tổng các số nguyên dương sao cho tích của các số đó là lớn nhất.
Trên thực tiễn, ta nên xét một vài trường hợp đơn cử để trải qua đó hiểu được bài toán rõ hơn và thấy được các thao tác cần phải triển khai. Đối với những bài toán đơn thuần, đôi lúc chỉ cần qua ví dụ là ta đã hoàn toàn có thể đưa về một bài toán quen thuộc để giải .
TÌM CẤU TRÚC DỮ LIỆU BIỂU DIỄN BÀI TOÁN
Khi giải một bài toán, ta cần phải định nghĩa tập hợp tài liệu để màn biểu diễn thực trạng đơn cử. Việc lựa chọn này tùy thuộc vào yếu tố cần xử lý và những thao tác sẽ triển khai trên tài liệu vào. Có những thuật toán chỉ thích ứng với một cách tổ chức triển khai tài liệu nhất định, so với những cách tổ chức triển khai tài liệu khác thì sẽ kém hiệu suất cao hoặc không hề triển khai được. Chính vì thế nên bước kiến thiết xây dựng cấu trúc tài liệu không hề tách rời bước tìm kiếm thuật toán xử lý yếu tố .
Các tiêu chuẩn khi lựa chọn cấu trúc dữ liệu:
– Cấu trúc tài liệu trước hết phải trình diễn được vừa đủ các thông tin nhập và xuất của bài toán Cấu trúc tài liệu phải tương thích với các thao tác của thuật toán mà ta lựa chọn để xử lý bài toán .- Cấu trúc tài liệu phải setup được trên máy tính với ngôn từ lập trình đang sử dụng .
– Đối với một số bài toán, trước khi tổ chức dữ liệu ta phải viết một đoạn chương trình nhỏ để khảo sát xem dữ liệu cần lưu trữ lớn tới mức độ nào.
TÌM THUẬT TOÁN
Thuật toán là một mạng lưới hệ thống ngặt nghèo và rõ ràng các quy tắc nhằm mục đích xác lập một dãy thao tác trên cấu trúc tài liệu sao cho : Với một bộ tài liệu vào, sau một số ít hữu hạn bước thực thi các thao tác đã chỉ ra, ta đạt được tiềm năng đã định .
Các đặc trưng của thuật toán:
Tính đơn định
Ở mỗi bước của thuật toán, các thao tác phải rất là rõ ràng, không gây nên sự nhập nhằng, lộn xộn, tùy tiện, đa nghĩa. Thực hiện đúng các bước của thuật toán thì với một tài liệu vào, chỉ cho duy nhất một tác dụng ra .
Tính dừng
Thuật toán không được rơi vào quy trình vô hạn, phải dừng lại và cho hiệu quả sau một số ít hữu hạn bước .
Tính đúng
Sau khi thực thi tổng thể các bước của thuật toán theo đúng quy trình đã định, ta phải được tác dụng mong ước với mọi bộ tài liệu nguồn vào. Kết quả đó được kiểm chứng bằng nhu yếu bài toán .
Tính phổ dụng
Thuật toán phải dễ sửa đổi để thích ứng được với bất kể bài toán nào trong một lớp các bài toán và hoàn toàn có thể thao tác trên các tài liệu khác nhau .
Tính khả thi
- Kích thước phải đủ nhỏ: Ví dụ: Một thuật toán sẽ có tính hiệu quả bằng 0 nếu lượng bộ nhớ mà nó yêu cầu vượt quá khả năng lưu trữ của hệ thống máy tính.
- Thuật toán phải được máy tính thực hiện trong thời gian cho phép, điều này khác với lời giải toán (Chỉ cần chứng minh là kết thúc sau hữu hạn bước). Ví dụ như xếp thời khoá biểu cho một học kỳ thì không thể cho máy tính chạy tới học kỳ sau mới ra được.
- Phải dễ hiểu và dễ cài đặt.
Ví dụ:
Input : 2 số nguyên tự nhiên a và b không đồng thời bằng 0 .Output : Ước số chung lớn nhất của a và b .
Thuật toán sẽ tiến hành được mô tả như sau: (Thuật toán Euclide)
Bước 1 ( Input ) : Nhập a và b : Số tự nhiên
Bước 2 : Nếu b ¹ 0 thì chuyển sang bước 3, nếu không thì bỏ lỡ bước 3, đi làm bước 4Bước 3 : Đặt r : = a mod b ; Đặt a : = b ; Đặt b : = r ; Quay trở lại bước 2 .Bước 4 ( Output ) : Kết luận ước số chung lớn nhất phải tìm là giá trị của a. Kết thúc thuật toán .Lưu đồ thuật giải ( Flowchart )Khi miêu tả thuật toán bằng ngôn từ tự nhiên, ta không cần phải quá cụ thể các bước và tiến trình triển khai mà chỉ cần diễn đạt một cách hình thức đủ để chuyển thành ngôn từ lập trình. Viết sơ đồ các thuật toán đệ quy là một ví dụ .Đối với những thuật toán phức tạp và nặng về thống kê giám sát, các bước và các công thức nên miêu tả một cách tường minh và chú thích rõ ràng để khi lập trình ta hoàn toàn có thể nhanh gọn tra cứu .Đối với những thuật toán tầm cỡ thì phải thuộc. Khi giải một bài toán lớn trong một thời hạn số lượng giới hạn, ta chỉ phải phong cách thiết kế tổng thể và toàn diện còn những chỗ đã thuộc thì cứ việc lắp ráp vào. Tính đúng đắn của những mô-đun đã thuộc ta không cần phải chăm sóc nữa mà tập trung chuyên sâu xử lý các phần khác .
Xem thêm: Hướng dẫn cách giải Rubik 4×4 cơ bản
LẬP TRÌNH
Sau khi đã có thuật toán, ta phải thực thi lập trình bộc lộ thuật toán đó. Muốn lập trình đạt hiệu suất cao cao, cần phải có kỹ thuật lập trình tốt. Kỹ thuật lập trình tốt biểu lộ ở kiến thức và kỹ năng viết chương trình, năng lực tháo gỡ và thao tác nhanh. Lập trình tốt không phải chỉ cần nắm vững ngôn từ lập trình là đủ, phải biết cách viết chương trình uyển chuyển, khôn khéo và tăng trưởng từ từ để chuyển các ý tưởng sáng tạo ra thành chương trình hoàn hảo. Kinh nghiệm cho thấy một thuật toán hay nhưng do thiết lập vụng về nên khi chạy lại cho hiệu quả sai hoặc vận tốc chậm .Thông thường, ta không nên cụ thể hóa ngay hàng loạt chương trình mà nên thực thi theo giải pháp tinh chế từng bước ( Stepwise refinement ) :Ban đầu, chương trình được bộc lộ bằng ngôn từ tự nhiên, biểu lộ thuật toán với các bước toàn diện và tổng thể, mỗi bước nêu lên một việc làm phải triển khai .Một việc làm đơn thuần hoặc là một đoạn chương trình đã được học thuộc thì ta thực thi viết mã lệnh ngay bằng ngôn từ lập trình .Một việc làm phức tạp thì ta lại chia ra thành những việc làm nhỏ hơn để lại liên tục với những việc làm nhỏ hơn đó .Trong quy trình tinh chế từng bước, ta phải đưa ra những màn biểu diễn tài liệu. Như vậy cùng với sự tinh chế các việc làm, tài liệu cũng được tinh chế dần, có cấu trúc hơn, biểu lộ rõ hơn mối liên hệ giữa các tài liệu .Phương pháp tinh chế từng bước là một biểu lộ của tư duy xử lý yếu tố từ trên xuống, giúp cho người lập trình có được một khuynh hướng bộc lộ trong phong thái viết chương trình. Tránh việc mò mẫm, xóa đi viết lại nhiều lần, biến chương trình thành tờ giấy nháp .
KIỂM THỬ
Chạy thử và tìm lỗi
Chương trình là do con người viết ra, mà đã là con người thì ai cũng hoàn toàn có thể nhầm lẫn. Một chương trình viết xong chưa chắc đã chạy được ngay trên máy tính để cho ra hiệu quả mong ước. Kỹ năng tìm lỗi, sửa lỗi, kiểm soát và điều chỉnh lại chương trình cũng là một kỹ năng và kiến thức quan trọng của người lập trình. Kỹ năng này chỉ có được bằng kinh nghiệm tay nghề tìm và thay thế sửa chữa lỗi của chính mình .
Có ba loại lỗi:
– Lỗi cú pháp: Lỗi này hay gặp nhất nhưng lại dễ sửa nhất, chỉ cần nắm vững ngôn ngữ lập trình là đủ. Một người được coi là không biết lập trình nếu không biết sửa lỗi cú pháp.
– Lỗi cài đặt: Việc cài đặt thể hiện không đúng thuật toán đã định, đối với lỗi này thì phải xem lại tổng thể chương trình, kết hợp với các chức năng gỡ rối để sửa lại cho đúng.
– Lỗi thuật toán: Lỗi này ít gặp nhất nhưng nguy hiểm nhất, nếu nhẹ thì phải điều chỉnh lại thuật toán, nếu nặng thì có khi phải loại bỏ hoàn toàn thuật toán sai và làm lại từ đầu.
Xây dựng các bộ test
Có nhiều chương trình rất khó kiểm tra tính đúng đắn. Nhất là khi ta không biết hiệu quả đúng là thế nào ?. Vì vậy nếu như chương trình vẫn chạy ra hiệu quả ( không biết đúng sai thế nào ) thì việc tìm lỗi rất khó khăn vất vả. Khi đó ta nên làm các bộ test để thử chương trình của mình .Các bộ test nên đặt trong các file văn bản, bởi việc tạo một file văn bản rất nhanh và mỗi lần chạy thử chỉ cần thay tên file tài liệu vào là xong, không cần gõ lại bộ test từ bàn phím. Kinh nghiệm làm các bộ test là :Bắt đầu với một bộ test nhỏ, đơn thuần, làm bằng tay cũng có được đáp số để so sánh với hiệu quả chương trình chạy ra .Tiếp theo vẫn là các bộ test nhỏ, nhưng chứa các giá trị đặc biệt quan trọng hoặc tầm thường. Kinh nghiệm cho thấy đây là những test dễ sai nhất .Các bộ test phải phong phú, tránh sự lặp đi lặp lại các bộ test tương tự như .Có một vài test lớn chỉ để kiểm tra tính chịu đựng của chương trình mà thôi. Kết quả có đúng hay không thì trong đa phần trường hợp, ta không hề kiểm chứng được với test này .Lưu ý rằng chương trình chạy qua được hết các test không có nghĩa là chương trình đó đã đúng. Bởi hoàn toàn có thể ta chưa thiết kế xây dựng được bộ test làm cho chương trình chạy sai. Vì vậy nếu hoàn toàn có thể, ta nên tìm cách chứng tỏ tính đúng đắn của thuật toán và chương trình, điều này thường rất khó .
TỐI ƯU CHƯƠNG TRÌNH
Một chương trình đã chạy đúng không có nghĩa là việc lập trình đã xong, ta phải sửa đổi lại một vài chi tiết để chương trình có thể chạy nhanh hơn, hiệu quả hơn. Thông thường, trước khi kiểm thử thì ta nên đặt mục tiêu viết chương trình sao cho đơn giản, miễn sao chạy ra kết quả đúng là được, sau đó khi tối ưu chương trình, ta xem lại những chỗ nào viết chưa tốt thì tối ưu lại mã lệnh để chương trình ngắn hơn, chạy nhanh hơn. Không nên viết tới đâu tối ưu mã đến đó, bởi chương trình có mã lệnh tối ưu thường phức tạp và khó kiểm soát.
Việc tối ưu chương trình nên dựa trên các tiêu chuẩn sau :
Tính tin cậy
Chương trình phải chạy đúng như dự tính, miêu tả đúng một giải thuật đúng. Thông thường khi viết chương trình, ta luôn có thói quen kiểm tra tính đúng đắn của các bước mỗi khi hoàn toàn có thể .
Tính uyển chuyển
Chương trình phải dễ sửa đổi. Bởi ít có chương trình nào viết ra đã hoàn hảo nhất ngay được mà vẫn cần phải sửa đổi lại. Chương trình viết dễ sửa đổi sẽ làm giảm bớt công sức của con người của lập trình viên khi tăng trưởng chương trình .
Tính trong sáng
Chương trình viết ra phải dễ đọc dễ hiểu, để sau một thời hạn dài, khi đọc lại còn hiểu mình làm cái gì ?. Để nếu có điều kiện kèm theo thì còn hoàn toàn có thể sửa sai ( nếu phát hiện lỗi mới ), nâng cấp cải tiến hay đổi khác để được chương trình xử lý bài toán khác. Tính trong sáng của chương trình nhờ vào rất nhiều vào công cụ lập trình và phong thái lập trình .
Tính hữu hiệu
Chương trình phải chạy nhanh và ít tốn bộ nhớ, tức là tiết kiệm được cả về không gian và thời gian. Để có một chương trình hữu hiệu, cần phải có giải thuật tốt và những tiểu xảo khi lập trình. Tuy nhiên, việc áp dụng quá nhiều tiểu xảo có thể khiến chương trình trở nên rối rắm, khó hiểu khi sửa đổi. Tiêu chuẩn hữu hiệu nên dừng lại ở mức chấp nhận được, không quan trọng bằng ba tiêu chuẩn trên. Bởi phần cứng phát triển rất nhanh, yêu cầu hữu hiệu không cần phải đặt ra quá nặng.
Từ những nghiên cứu và phân tích ở trên, tất cả chúng ta nhận thấy rằng việc làm ra một chương trình yên cầu rất nhiều quy trình và tiêu tốn khá nhiều sức lực lao động. Chỉ một quy trình không hài hòa và hợp lý sẽ làm tăng ngân sách viết chương trình. Nghĩ ra cách xử lý yếu tố đã khó, biến ý tưởng sáng tạo đó thành hiện thực cũng không dễ chút nào .
Những cấu trúc dữ liệu và giải thuật đề cập tới trong chuyên đề này là những kiến thức rất phổ thông, một người học lập trình không sớm thì muộn cũng phải biết tới. Chỉ hy vọng rằng khi học xong chuyên đề này, qua những cấu trúc dữ liệu và giải thuật hết sức mẫu mực, chúng ta rút ra được bài học kinh nghiệm: Đừng bao giờ viết chương trình khi mà chưa suy xét kỹ về giải thuật và những dữ liệu cần thao tác, bởi như vậy ta dễ mắc phải hai sai lầm trầm trọng: hoặc là sai về giải thuật, hoặc là giải thuật không thể triển khai nổi trên một cấu trúc dữ liệu không phù hợp. Chỉ cần mắc một trong hai lỗi đó thôi thì nguy cơ sụp đổ toàn bộ chương trình là hoàn toàn có thể, càng cố chữa càng bị rối, khả năng hầu như chắc chắn là phải làm lại từ đầu (tất nhiên, cẩn thận đến đâu thì cũng có xác suất rủi ro nhất định, ta hiểu được mức độ tai hại của hai lỗi này để hạn chế nó càng nhiều càng tốt).Nguồn : Giáo trình Giải thuật và Lập trình – Lê Minh Hoàng – Đại học sư phạm TP.HN
Source: https://vietsofa.vn
Category : Góc học tập
+ There are no comments
Add yours