Kinh nghiệm viết Paper

Chia sẻ: Basso Basso | Ngày: | Loại File: DOC | Số trang:4

Thêm vào BST

Báo xấu

198
lượt xem 27
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Organizational element: tổ chức bài viết cho tốt. Thông thường, một bài báo nên có cấu trúc như sau

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Kinh nghiệm viết Paper

Kinh nghiệm viết Paper Chất lượng technical papers có thể chia thành 3 phần chính: 1. Stylistic element: cấu trúc câu, chấm phẩy thế nào, tổ chức một paragraph ra sao? Xin đọc quyển sách kinh điển Elements of styles. Đây là quyển sách phải-đọc cho tất cả các thể loại viết lách tiếng Anh. (Phải đọc cho cả người bản xứ!) 2. Organizational element: tổ chức bài viết cho tốt. Thông thường, một bài báo nên có cấu trúc như sau (không nhất thiết phải theo thứ tự này) 1. Phần giới thiệu: đặt kết quả của mình vào ngữ cảnh lớn hơn, giải thích tại sao vấn đề là quan trọng, tại sao nó khó khăn, tại sao các kết quả hiện nay chưa thỏa đáng, đóng góp kỹ thuật của bài báo là gì, và đóng góp này “khớp” ra sao vào bức tranh lớn của (phân) ngành. 2. Phần literature review: mô tả chi tiết hơn các nghiên cứu đã có, phân tích sơ bộ tại sao chúng chưa thỏa đáng cho vấn đề mình muốn giải quyết. 3. Phần formulation: định nghĩa vấn đề một cách chặt chẽ hơn, nêu rõ các giả thiết (assumptions) mà mình dùng và giải thích tại sao mình lại có thể dùng các giả thiết này. Phần giải thích giả thiết có thể phải bao gồm cả simulations và experiments. 4. Phần lời giải: trình bày các định lý, thuật toán, mô hình, v.v. những thứ cấu thành lời giải. Cái nào dài dòng rắm rối về
mặt chi tiết mà không tải nhiều ý thì bỏ ra appendix cũng được. 5. Phần validation của lời giải: nếu bạn có một thuật toán, một mô hình mới thì phải validate nó analytically và/hoặc experimentally. Analytical validation bao gồm phân tích độ phức tạp không/thời gian của thuật toán, chứng minh soundness, completeness, hay rate of convergence của một thuật toán tối ưu, v.v. Experimental validation bao gồm chạy thử và so sánh chất lượng giải pháp của mình với những giải pháp tốt nhất đã có, cẩn thận control các tham số khi so sánh, giải thích các drawbacks nếu có của giải pháp là ở đâu, có đáng “hy sinh” các drawbacks này không, v.v. 6. Phần kết luận và phân tích hướng nghiên cứu tương lai: chẳng có giải pháp nào là hoàn hảo trong một bài báo, ta phải kết luận và phân tích xem tương lai cần làm gì tiếp, giải pháp của ta đã mở ra hướng nghiên cứu mới nào, v.v. 3. Novelty: giá trị của đóng góp của ta dĩ nhiên không chỉ nằm ở cái cấu trúc của bài báo hay ở việc viết tiếng Anh xuôi chèo mát mái. Có nhiều bài báo có tất cả các thành tố vừa nêu (bao gồm giải pháp và validation) nhưng vẫn không được nhận đăng ở các hội nghị và tạp chí danh tiếng. Tại sao? Tại vì technical novelty không đủ mạnh! Mặc dù “technical novelty” là một khái niệm chủ quan, nếu bạn là người ở lâu trong ngành thì sự đánh giá này sẽ ngày càng trở nên khách quan. Tôi không có một định nghĩa chặt chẽ cho khái niệm này, nên sẽ nêu vài ví dụ. Ví dụ 1: bạn có một implementation tốt của thuật toán quicksort, trong đó có nhiều mẹo dùng pointers, memory allocation, v.v. làm cho implementation của bạn tốt hơn tất
cả các implementation hiện có khoảng 20 phần trăm về mặt thời gian chạy. Đây rõ ràng là một đóng góp không tồi cho KHMT. Trên thực tế công trình này làm tăng tốc các cơ sở dữ liệu trên toàn thế giới 20 phần trăm. Bạn viết một bài báo mô tả chi tiết implementation của mình theo đúng sườn bài ở trên, và … không hội nghị lớn nào nhận đăng.Ví dụ 2: bạn có một thuật toán sorting mới hoàn toàn, tư tưởng khác hẳn với các thuật toán sorting thông thường như quicksort, merge-sort, insertion-sort, v.v. Phân tích cho thấy nó chạy trong thời gian O(n log log n), và experiments cho thấy nó chạy nhanh hơn tất cả các implementation của các thuật toán hiện có khoảng 10 phần trăm (nghĩa là tệ hơn Ví dụ 1). Bài báo này của bạn sẽ được đăng ở hội nghị tốt nhất về thuật toán. Hai ví dụ trên tôi bịa ra trong vài phút suy nghĩ, nên không hoàn hảo lắm. (Ví dụ như cái running time O(n log log n).) Tôi hy vọng là chúng đủ để minh họa cho điều tôi muốn nói. Trên thực tế các bài báo trải một spectrum rất rộng giữa ví dụ 1 và 2 và tràn cả xuống dưới ví vụ 1. Nhiều bài báo đọc thấy nực cười, bảo phê bình không biết bắt đầu từ đâu. Nhiều bài báo có giải pháp thuần túy là một biến thể nào đó của các ý tưởng sẵn có. Nếu biến thể này “tầm thường” thì novelty kém, nếu biến thể này “thú vị” thì novelty cao. Tóm lại, muốn viết bài báo tốt thì phải thực hành nhiều và tự học từ các sai lầm đã có của mình. Đừng nản khi paper của mình bị từ chối mà phải xem referees nói gì và rút ra bài học. Dĩ nhiên là có đôi khi referees rất tệ, nói bậy nói bạ; nhưng tình trạng này sẽ ít xảy ra hơn khi bạn nộp bài vào một hội nghị hay tạp chí danh tiếng hơn. Chúc bạn may mắn!

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn