Skip to content
Narrow screen resolution Wide screen resolution Auto adjust screen size Increase font size Decrease font size Default font size default color grey color
         
 | 
VNOI - Olympic tin học Việt Nam

Điểm tin VOJ

Số thành viên:6040
Số bài tập:1001
Số bài nộp:722923
Bài nộp hôm nay:0

Top 10 thành viên xuất sắc

HạngThành viênĐiểm
1mr_invincible587.9
2white_cobra418.6
3hieult403.4
4phaleq384.0
5vodanh9x368.2
6con_nha_ngheo352.0
7flash_mt350.2
8darksabers349.8
9yenthanh132345.3
10rockman9x_94343.1

Danh tiếng các thành viên

HạngThành viênĐiểm
1mr_invincible+213
2conankudo+149
3khuc_tuan+137
4tuananhnb93+129
5khanhptnk+108
6hphong+103
7flash_mt+99
8paulmcvn+71
9technolt+70
10hoangle+63

Topcoder Vietnam

HạngThành viênĐiểm
Diễn đàn
Forum
Kinh nghiệm thi cử (1 đang xem) ,(1) Khách
Bài viết dưới cùng Gửi trả lời Được ưa thích: 8
CHỦ ĐỀ - Kinh nghiệm thi cử
#5939
minhduc (Admin)
paulmcvn+71
Admin
Bài viết: 1288
graphgraph
Thành viên đang truy cập Click vào đây để xem thông tin về thành viên này
Kinh nghiệm thi cử 12 năm, 4 tháng trước   (+1)
Đây là 1 bài viết cũ của mình về các kinh nghiệm thi cử

Kinh nghiệm thi cử

Làm bài thật nhanh
Suy nghĩ thì phải cẩn thận, nhưng khi đặt tay xuống làm bài thì phải làm bài thật nhanh, không chần chừ do dự. Nên nhớ đây là một yếu tố rất quan trọng, nếu không nhiều khả năng sẽ bị thiếu thời gian! Luyện tập làm bài nhanh mỗi khi có thể để đến khi đi thi sẽ quen.

Đọc kỹ và suy nghĩ tất cả các bài trước khi làm
Nên dành một khoảng thời gian để suy nghĩ tất cả các bài toán, sau đó mới quyết định sẽ làm bài nào trước. Có rất nhiều trường hợp, một bài toán tưởng chừng đơn giản nhưng đến khi làm gần xong mới phát hiện là bài khó. Vì vậy cần tỉnh táo tránh lãng phí thời gian.

Làm bài dễ trước
Hoàn thành bài dễ trước để đảm bảo một số điểm cho mình và tạo cảm giác yên tâm khi làm những bài còn lại.

Kiểm tra mỗi bài sau khi làm xong
Sau khi làm xong mỗi bài, cần phải kiểm tra lại chương trình trước khi chuyển sang bài khác.
Để kiểm tra chương trình, cách tốt nhất là test thật nhiều. Có thêm một test đúng, xác suất đúng đắn của chương trình sẽ tăng lên đáng kể.
Dùng các test kích thước nhỏ, tự sinh ra để kiểm tra tính đúng đắn của thuật toán; các test lớn, nhận giá trị lớn nhất và giá trị ngẫu nhiên để kiểm tra thời gian thực hiện của thuật toán, phát hiện các lỗi như range check, stack overflow, arithmetic overflow.
Có những bài toán mà có thể kiểm tra kết quả một cách đơn giản (ví dụ bài Dò mìn). Khi đó đừng ngại viết chương trình tạo test hoặc chương trình kiểm tra kết quả nếu cần thiết.
Với những bài toán mà có thuật toán đúng đắn rất đơn giản (tuy nhiên thời gian thực hiện lớn hơn), hãy viết một chương trình như vậy dùng để kiểm tra kết quả. Chẳng hạn, bài toán cặp điểm gần nhất: cho N điểm trên mặt phẳng, tìm hai điểm có khoảng cách gần nhất. Dùng chương trình O(N2) để so sánh với chương trình O(NlogN), nếu hai chương trình cho kết quả như nhau ở các bộ test thì xác suất đúng đắn của chương trình O(NlogN) là rất cao. Tương tự, nếu có hai phương pháp khác nhau nhiều để giải bài toán mà cùng cho kết quả như nhau thì xác suất đúng của chương trình là tương đối cao.

Đọc kỹ đề bài
Đọc lại một đề bài nhiều lần, đọc cả trước khi làm, sau khi làm xong, phát hiện xem mình có nhầm lẫn, thiếu sót chi tiết gì không!

Sửa lỗi chương trình
Khi chương trình chạy cho ra kết quả sai, cần sửa lỗi (debug) chương trình. Cần tận dụng hiệu quả các công cụ debug của Free Pascal như watches, break point, sử dụng tốt các phím tắt F4, F7, F8. Thông thường chương trình sẽ bị một vài lỗi nhỏ như viết sai tên biến trong một biểu thức, thiếu một đoạn xử lý,…
Có thể xảy ra trường hợp phát hiện cả thuật toán sai, nhất là đối với những bài có thuật toán đúng đắn thì điều này là hoàn toàn có thể. Khi đó đừng hốt hoảng! Cần bình tĩnh tính toán xem xác suất đúng đắn của chương trình có cao không, có nên làm tiếp bài toán đó hay không? Đừng bao giờ để bị vướng vào một bài toán quá lâu, nếu thấy lo lắng vì đã dành nhiều thời gian cho một bài mà vẫn cho kết quả sai, hãy tạm thời chuyển sang bài khác.
Trong trường hợp cần thay đổi toàn bộ chương trình, nhớ backup chương trình cũ vào một bản khác, phòng khi cần sử dụng lại.

Phong cách viết chương trình
Phong cách viết chương trình là điều rất quan trọng khi đi thi. Với phong cách viết chương trình tốt sẽ có lợi thế hơn. Nhưng điều này lại chỉ có thể có khi luyện tập nhiều. Phong cách viết chương trình tốt không có nghĩa là những cách viết để cho chương trình chạy nhanh, mà là đảm bảo để làm bài nhanh, sửa lỗi nhanh, giảm xác suất sai của chương trình và giảm xác suất nhầm lẫn cho người viết.

Đừng đòi hỏi perfect
Trong trường hợp không thể nghĩ ra thuật toán đúng đắn cho một bài toán (hoặc bản thân bài toán cũng không có thuật toán đúng đắn, điều này rất có thể xảy ra trong kỳ thi quốc gia), cố gắng tìm cách đạt được một số điểm nhất định. Một chương trình đạt 80 hay 90 điểm hầu như không khác gì nhiều so với một chương trình perfect. Đôi khi không đáng để viết thêm một đoạn chương trình rất dài chỉ để đạt thêm 10-20 điểm, nhưng đôi khi chỉ cần thêm một hai dòng cận hay điều kiện thì thậm chí có thể đạt thêm một số điểm rất lớn. Điều quan trọng là cần bình tĩnh để đánh giá những gì nên làm và không nên làm.

Đạt được 50% số điểm
Các bài toán thường đưa ra 50% (hoặc 30-40%) số test có giới hạn nhỏ, có thể dùng những thuật toán đơn giản hoặc duyệt. Tốt nhất nên thêm một điều kiện để kiểm tra nếu dữ liệu thuộc giới hạn này thì dùng chương trình đơn giản hoặc duyệt để chạy.

Sao lưu bài làm
Thỉnh thoảng hãy sao lưu bài làm vào nhiều thư mục, nhiều ổ đĩa khác nhau phòng khi có sự cố kỹ thuật. Hãy tạo 3 thư mục cho 3 bài làm. Lưu các bài sẽ nộp vào một nơi riêng, tránh nộp nhầm bài.

Đánh giá, quyết định thông minh
Có nhiều thứ cần đánh giá: mức độ khó của mỗi bài, xác suất đúng đắn của thuật toán nghĩ ra, thời gian cần thiết để làm một bài, kiểm tra kết quả và tạo test có khó không? Từ đó quyết định làm bài nào trước, có nên tiếp tục cải tiến một bài không, cải tiến như thế nào sẽ hiệu quả hơn, kiểm tra chương trình như thế nào để chắc chắn nhất. Hãy linh hoạt

Khi lập trình
Khi đi thi thường sẽ sử dụng compiler và IDE Free Pascal.

Đặt chỉ dẫn bộ nhớ
Trong trường hợp chương trình lặp vào thủ tục đệ quy nhiều lần, cần tăng kích thước stack bằng cách đặt chỉ dẫn bộ nhớ:
{$M 2000000,0,2000000}

Phong cách viết chương trình
Nếu chương trình sử dụng ít biến, có thể đặt tên các biến, mảng ngắn gọn đơn giản để tăng tốc độ làm bài, ví dụ a, b, x, y,… mảng quy động là f. Tuy nhiên nếu chương trình sử dụng nhiều biến, các biến mang ý nghĩa khác nhau thì hãy đặt tên các biến dài và mang ý nghĩa của chúng để tránh nhầm lẫn. Nên nhớ việc nhầm lẫn giữa các biến là vấn đề rất khó chịu. Nên đặt tên các biến bằng tiếng Việt và viết chương trình bằng chữ in thường để tăng tốc độ làm bài.
Giữa các câu lệnh, nên xuống dòng để tận dụng các công cụ debug của Free Pascal như các phím F4, F7, F8.

Sử dụng chuỗi
Nếu cần sử dụng chuỗi có độ dài vượt quá 255 ký tự cần đặt chỉ dẫn {H+} ở đầu chương trình.

Cắt dán
Để sử dụng các phím tắt Ctrl-C,X,V cho cắt dán chữ như Windows, chọn Options – Keyboard & mouse – đánh dấu Microsoft convention.
 
Đã lưu IP Đã lưu IP  
  Đã khóa chức năng gửi bài.
#9072
hmb (Thành viên)
hmb
Biết code binary-indexed tree
Bài viết: 43
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
Nếu cần sử dụng chuỗi có độ dài vượt quá 255 ký tự cần đặt chỉ dẫn {H+} ở đầu chương trình.
Sao không dùng ansistring vậy?Nếu dùng khônng khai báo{H+} có sao không anh?
 
Đã lưu IP Đã lưu IP  
  Đã khóa chức năng gửi bài.
#9075
hphong591992 (Admin)
hphong+103
Admin
Bài viết: 1296
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
À, hình như là đỡ mất công phải khai báo ansistring thôi
 
Đã lưu IP Đã lưu IP  
 
Dont be shy when + 4 me !!
  Đã khóa chức năng gửi bài.
#9080
bnta2 (Thành viên)
naruto238
Ra đề chuyên nghiệp
Bài viết: 196
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
Đọc kĩ đề bài rất chi là quan trọng.
Thêm cái Đừng đòi hỏi perfect nữa.
Kinh nghiệm xương máu của em rồi.
 
Đã lưu IP Đã lưu IP  
  Đã khóa chức năng gửi bài.
#9084
wanderer (Thành viên)
Đã biết code đệ quy
Bài viết: 9
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
Bài viết của Đức đã chỉ ra khá nhiều điều lý thú cho các bạn. Mình chỉ có 1 kinh nghiệm xương máu từng chứng kiến. Nếu các bạn gặp 1 đề bài quen thuộc thì nhớ cẩn thận nhé. Tâm lý gặp bài quen thuộc thì thường khá vui mừng, , bắt tay vào làm ngay, mà nhiều khi quên nghiên cứu thật kỹ đề bài, nên có thể dính bẫy.
Năm đó đội tuyển bọn mình đi thi, có 1 bài thế này. Cho n địa điểm trên 1 con đường quốc lộ, hãy chọn k điểm đặt trạm đổ xăng, sao cho khoảng cách xa nhất để đi đổ xăng từ n điểm trên là min. Trước đó vài ngày, bọn mình cũng gặp 1 bài, kiểu tương tự, chỉ có điều yêu cầu là tổng khoảng cách để đến các điểm đổ xăng là min. 1 bạn thuộc dạng giỏi nhất đội tuyển, vào thi, ung dung cài y hệt bài cũ. Xui xẻo là, đề thi yêu cầu xuất ra các địa điểm chọn làm trạm xăng thôi, và kết quả ví dụ y hệt như bạn mình tính ra.
Chúc các bạn may mắn.
 
Đã lưu IP Đã lưu IP  
  Đã khóa chức năng gửi bài.
#9085
vdmedragon (Thành viên)
vdmedragon+5
Không code nữa rồi
Bài viết: 726
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
Nhớ thiết kế test ví dụ cẩn thận nữa, nhất là mấy bài mà thuật toán dựa vào ví dụ. Đề bài hay đưa test lởm, test đặc biệt và thiết kê thuật toán theo nó hay thiếu trường hợp.

Có 1 lần gặp 1 bài mà lời giải test của ví dụ trùng với 1 bài khác đã làm (hai bài phát biểu khác nhau) -> tưởng nó là phát biểu cách khác nhưng cùng 1 bài. Code và sai.

1 bài là : phân tích 1 số thành tổng một số các số để bội số chung nhỏ nhất lớn nhất, một bài là phân số 1 số thành tổng các số để tích của chúng lớn nhất.
 
Đã lưu IP Đã lưu IP  
 
  Đã khóa chức năng gửi bài.
#9087
ConanKudo (Admin)
conankudo+149
Admin
Bài viết: 782
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
Một số kinh nghiệm xương máu của mình qua mấy đợt thi năm ngoái :
1/ Đọc đề thật kỹ, đừng nhìn thấy đề dài mà đọc lướt, hậu quả khôn lường
2/ Thấy bài cài một lúc rắc rối quá thì pass sang bài khác, quay lại bài đó sau
3/ Giám thị có cười đểu thì đừng có tìm cách trả đũa, mất tập trung
và quan trọng nhất:
4/ Không nghe nhạc hoặc hát dưới mọi hình thức trong lúc thi !!
 
Đã lưu IP Đã lưu IP  
 
There are times when you can't save others with just love and kindness.
  Đã khóa chức năng gửi bài.
#9088
hphong591992 (Admin)
hphong+103
Admin
Bài viết: 1296
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
Kinh nghiệm em mới bị chết, đó là tự tin quá hóa hâm
 
Đã lưu IP Đã lưu IP  
 
Dont be shy when + 4 me !!
  Đã khóa chức năng gửi bài.
#9248
iamme (Thành viên)
iamme
Biết code binary-indexed tree
Bài viết: 49
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 12 năm, 1 tháng trước   (+0)
Thần kinh vững vàng trước những cơ sở vật chất kinh dị tại nơi tổ chức ---> đợt thi vừa rồi xui xẻo thế nào trúng ngay cái máy tính với bàn phím là hoán vị của các nút phím -> lúc thi cuống lên gõ nhầm tứ tung; máy tính thì luôn chầu chực khởi động lại với chương trình đóng băng ổ còn đang bật nguyên ( thằng ngồi cạnh mình bị khởi động lại 2 lần may mà nó cũng chưa code dc nhiều )
Cố gắng không cà cuống khi phát hiện ra bài mình sai hoàn toàn sau khi đã hùng hục code mất 1 tiếng cho bài đó
 
Đã lưu IP Đã lưu IP  
 
Tên : Sabaku no Gaara
Địa chỉ : làng Cát
Tuổi : 16
Ước mơ : hokage
  Đã khóa chức năng gửi bài.
#12068
just4one (Thành viên)
just4one+1
Nhắm mắt code không bug
Bài viết: 129
graphgraph
Thành viên gián tuyến Click vào đây để xem thông tin về thành viên này
Trả lời: Kinh nghiệm thi cử 11 năm, 11 tháng trước   (+0)
Công nhận cái "đừng yêu cầu perfect" là kinh nghiệm xương máu Nếu chưa nghĩ ra thuật toán ( hoặc nghĩ ra rồi nhưng ước lượng thời gian code không nằm trong phạm vi cho phép) thì phải chấp nhận cài chương trình "trâu bò", vừa là để ăn 60% điểm, vừa để test cho những version cải tiến của mình.
Nhớ năm ngoái lúc đi thi gặp bài 3, thấy ngay là phải xét 4 góc để gấp, đánh giá độ phức tạp nhỏ đủ ăn 100% tests, thế là cắm đầu vào làm đến lúc hết giờ mới phát hiện ra tính nhầm chỗ này chỗ nọ, trong khi đề bài "60% số tests có K <= 3" (tức hoàn toàn có thể ... sinh mảng hằng để lấy điểm). 60% của 7 = 4.2 điểm <-- Một số điểm đủ làm đc nhiều điều.
 
Đã lưu IP Đã lưu IP  
  Đã khóa chức năng gửi bài.
Bài viết trên cùng Gửi trả lời
Powered by FireBoardBài viết mới nhất từ diễn đàn cho các chương trình nhận tin RSS