Có phải tất cả các vấn đề lập trình vấn đề thuật toán? [đóng cửa]


13

Tôi thích cách "Giới thiệu về thuật toán" của Cormen et al. truyền đạt kiến ​​thức. Một lý do là mọi thứ liên quan đến các vấn đề lập trình và cuốn sách không được thực hiện bằng bất kỳ ngôn ngữ lập trình cụ thể nào. Độc lập ngôn ngữ này cung cấp tập trung vào các ý tưởng nói chung.

Vì vậy, câu hỏi của tôi là, như nó nói trong tiêu đề. Là mọi vấn đề lập trình có thể giải quyết được bằng cách suy nghĩ theo kiểu thuật toán này. Không có vấn đề ngôn ngữ, lĩnh vực, vv? Nếu có, đưa ra lập luận, khác, đưa ra lập luận!

Tôi chưa bao gồm nhiều chương trình phức tạp với GUI, AI, Đồ họa, v.v ... Nhưng những loại vấn đề này cũng là vấn đề nghĩ ra các thuật toán tốt?


6
Vấn đề phổ biến nhất đối với một lập trình viên, imho, là: "oh, RATNG đó là những gì bạn muốn nói? Bây giờ tôi hiểu. Đó không phải là những gì tôi đã thực hiện, xin lỗi". Đó có phải là một vấn đề lập trình?
keppla

1
Câu hỏi này rất giống nhau.
back2dos

Bạn cần làm một báo cáo với khách hàng, mô tả các yêu cầu của họ và dựa vào đó bạn phải thiết kế, kiểm tra, thực hiện, tái cấu trúc, tối ưu hóa và bảo trì phần mềm. Bạn cần môi trường để kiểm tra, phát triển, triển khai, chạy và đo lường phần mềm. Trong hệ thống này, một thuật toán riêng lẻ chỉ là một chi tiết thực hiện.
inf3rno

@Keppla (cộng với một) ope, đó là một vấn đề yêu cầu, nguyên nhân
cốt lõi

Câu trả lời:


29

Nó phụ thuộc vào cách bạn định nghĩa "Vấn đề lập trình".

Trong các dự án thực tế, câu trả lời chắc chắn là KHÔNG. Hầu hết các vấn đề thậm chí không phải là vấn đề kỹ thuật, mà là vấn đề giao tiếp, yêu cầu không rõ ràng, v.v.

Sau đó, bạn có toàn bộ các đối tượng của các lớp vấn đề yêu cầu bên cạnh không có thuật toán. Ví dụ, GUI thường đơn giản với "chương trình", nhưng vấn đề thực sự liên quan là phải có một thiết kế tốt (từ quan điểm khả dụng, không chỉ là hình thức đồ họa).

Có một số lĩnh vực, trong đó các vấn đề có xu hướng thuật toán hơn nhiều bởi bản chất của lĩnh vực đó mặc dù. Ví dụ, AI là một chủ đề chính, trong đó các thuật toán là cốt lõi. Đồ họa có thể là thuật toán chuyên sâu, nhưng nó phụ thuộc vào chính xác ý nghĩa của "Lập trình đồ họa".

Nói chung, nếu vấn đề bạn đang giải quyết theo chương trình phù hợp với biểu diễn toán học, thì bạn đang bước vào khu vực thuật toán. Tất nhiên, đây chỉ là một chỉ số sơ bộ, vì bạn có thể tạo các mô hình toán học cho hầu hết mọi thứ. Nhưng đối với hầu hết mọi thứ bạn thường không xem xét làm như vậy.

Ví dụ cuối cùng: Nếu vấn đề là tạo GUI cho phép nhập dữ liệu cho các đối tượng kinh doanh, bạn sẽ không nghĩ nhiều về các công thức toán học. Tuy nhiên, nếu vấn đề là tạo ra một GUI thay đổi linh hoạt và định vị lại các yếu tố dựa trên một số giá trị quan trọng, thì nhiều khả năng bạn sẽ kết thúc với một mô hình toán học và triển khai thuật toán.


2
Rõ ràng, nó cũng phụ thuộc vào cách bạn định nghĩa "Thuật toán". Tôi sẽ nói rằng rất ít vấn đề yêu cầu các thuật toán mới, nhưng vì một chương trình máy tính chỉ có hai phần - thuật toán và cấu trúc dữ liệu - tất cả các vấn đề đều yêu cầu một số thuật toán, ngay cả khi các thuật toán đó là tầm thường. Một thuật toán không phải là một mô hình toán học, nó là một chuỗi các hướng dẫn.
philosodad

Điều đó đúng theo nghĩa chặt chẽ nhất của nó, nhưng tôi, với một người, không chấp nhận i++là thuật toán mới của chúng tôi .. erm .. thuật toán.
Frank

Nhưng nếu chúng ta không biết về sự bổ sung. Sau đó, việc giới thiệu bổ sung sẽ là một sự đổi mới lớn trong các nghiên cứu về thuật toán của chúng tôi! Và cứ như vậy cho đến khi chúng ta gặp phải các thuật toán ngày càng phức tạp hơn.
CMCDragonkai

8

Bạn có ý nghĩa gì bởi vấn đề lập trình?

Theo Wikipedia:

Lập trình máy tính (thường được rút ngắn để lập trình hoặc mã hóa) là quá trình thiết kế, viết, kiểm tra, gỡ lỗi và duy trì mã nguồn của các chương trình máy tính.

điều đó có nghĩa là lập trình nói chung vốn đã lớn hơn so với dịch thuật toán thông qua mã.

Để cho bạn một ví dụ, một vấn đề lập trình tôi có ngay bây giờ là tôi phải xử lý mã nguồn spaghetti kế thừa bằng cách thêm các bài kiểm tra đơn vị, sau đó tái cấu trúc nó . Nó cũng liên quan đến việc thêm ý kiến ​​vào đúng chỗ, bình thường hóa cách viết hoa của tên, v.v. Nó không liên quan gì đến thuật toán.

Theo cùng một cách, nhiều nhiệm vụ của nhà phát triển không liên quan đến thuật toán. Ví dụ: quốc tế hóa. Theo cùng một cách, rất nhiều ứng dụng (ví dụ CRUD) không sử dụng thuật toán quá nhiều trong mã nguồn của chúng (không nói về mã cơ bản của khung).

Bây giờ, nếu bạn cho rằng trong "vấn đề lập trình", "lập trình" là từ đồng nghĩa của việc dịch thuật toán thông qua mã, thì có, về mặt logic, bất kỳ vấn đề nào cũng sẽ là vấn đề thuật toán: A × n = B × nnếu A = B.


Có một sự khác biệt giữa một nhiệm vụ và một vấn đề . Vấn đề của bạn không phải là thêm các bài kiểm tra đơn vị hoặc duy trì mã kế thừa, đó là giải pháp cho vấn đề nằm trong cơ sở mã, chứ không phải chính hành vi chương trình mà mã đại diện cho thuật toán.
zxcdw

Nhiệm vụ của bạn, như được mô tả, không làm thay đổi hành vi của chương trình. Có lẽ đó là công việc chuẩn bị cho một số thay đổi khác, có thể có hoặc không liên quan đến thuật toán. Tôi không nghĩ rằng bất cứ ai ở bất cứ nơi nào được trả tiền chỉ để tái cấu trúc mã làm việc cả ngày.
MarkJ

6

Tôi nghĩ rằng câu trả lời là không . Các thuật toán chỉ là các khối xây dựng trong một bộ kỹ năng lớn hơn nhiều.

Tôi có bằng về CS, chuyên về AI

Vấn đề cơ bản, ít nhất là như tôi đã thấy, là tìm ra những đại diện tốt cho thông tin. Các đại diện này nên cố gắng phù hợp với các cấu trúc tri thức trong đầu mọi người và sẽ tạo điều kiện thuận lợi cho các loại thao tác và thay đổi được thực hiện trên chúng.

Về mặt lập trình hàng ngày, điều này có nghĩa là vấn đề cơ bản là xác định đúng ngôn ngữ cụ thể miền (DSL) cho tình huống hiện tại. Có nhiều cách để tạo DSL. Lập trình thông thường, trong đó các lớp, biến và phương thức được xác định trên thực tế là tạo DSL vì nó cho phép bạn nói những điều (ánh xạ cấu trúc tinh thần của bạn thành mã) mà bạn không thể nói mà không có chúng.

Các thuật toán cũng quan trọng, nhưng chúng chỉ là một phần của câu chuyện.


5

Tôi cho rằng bạn có thể nói rằng tất cả các chương trình máy tính là thuật toán, bởi vì bạn đang quy định một chuỗi các hướng dẫn để đạt được kết quả mong muốn. Tuy nhiên, một số vấn đề khó khăn nhất không phải là giao tiếp chương trình với máy tính, họ đang truyền đạt một chương trình cho con người, những người sẽ thử nghiệm và sửa đổi phần mềm.

Nói cách khác, máy tính không quan tâm nếu mã của bạn hoàn toàn không thể hiểu được với con người. Họ sẽ chạy nó tốt cả hai cách. Thách thức là làm cho mã đủ rõ ràng để bất kỳ lỗi nào sẽ nổi bật như ngón tay cái đau.

Thật thú vị, những điều kỹ thuật tôi học được ở trường đại học về thuật toán từ lâu đã bị lu mờ bởi những gì tôi đã tự học từ đó. Tại thời điểm này nếu tôi muốn lấy bằng đại học thứ 3 để giúp tôi trong công việc, nó sẽ là thành phần tiếng Anh.


2

Hầu hết các vấn đề lập trình thực sự là vấn đề quản trị hệ thống.

Đó là một câu trả lời ngắn gọn, nhưng tôi thấy điều này đúng thường xuyên hơn mọi người có thể mong đợi. Tôi không biết mình đã gặp phải lỗi bao nhiêu lần vì DNS bị định cấu hình sai trên máy kiểm tra, một quy trình cũ vẫn đang chạy mà đang ăn cắp CPU / bộ nhớ / cổng, chương trình đang chạy sai ID người dùng và do đó đã sai quyền, đĩa được phân vùng không chính xác và do đó hết dung lượng, phiên bản sai của tệp cấu hình đã được cài đặt, v.v.

Làm cho các thuật toán đúng thường chỉ là một phần nhỏ của vấn đề. Phần còn lại của vấn đề là đưa chương trình vào giải quyết các vấn đề thực trong thế giới thực.


"Làm cho các thuật toán đúng thường chỉ là một phần nhỏ của vấn đề" Các vấn đề tại kaggle.com KHÔNG [TM] phù hợp với mô tả đó.
Gandalf

Tôi đồng ý, tôi chỉ cần đặt chúng trong danh mục "hệ thống ống nước". Làm việc với các dịch vụ, API và đôi khi của các lập trình viên khác chỉ là kết nối mọi thứ như người khác nghĩ họ nên làm việc.
JeffO

2

Tôi nghĩ rằng có, tất cả các vấn đề lập trình đều có thể giải quyết được bằng cách suy nghĩ theo kiểu thuật toán. Sau tất cả, một thuật toán chỉ là một bộ hướng dẫn cho máy tính biết phải làm gì.

Lấy một số ví dụ từ trên

Ví dụ, GUI thường đơn giản với "chương trình", nhưng vấn đề thực sự liên quan là phải có một thiết kế tốt (từ quan điểm khả dụng, không chỉ là hình thức đồ họa).

Về mặt lập trình và thậm chí thiết kế sẽ biết các mẫu / quy tắc dẫn đến các thiết kế GUI hiệu quả, thân thiện và hiệu quả với người dùng. Các quy tắc này được giảm xuống thành một thuật toán mà nếu tuân theo sẽ giúp tạo ra GUI thân thiện với người dùng. Trên thực tế, các bước thực tế của việc đặt các điều khiển trên GUI cũng có thể được giảm xuống thành một thuật toán

Để cho bạn một ví dụ, một vấn đề lập trình tôi có ngay bây giờ là tôi phải xử lý mã nguồn spaghetti kế thừa bằng cách thêm các bài kiểm tra đơn vị, sau đó tái cấu trúc nó. Nó cũng liên quan đến việc thêm ý kiến ​​vào đúng chỗ, bình thường hóa cách viết hoa của tên, v.v. Nó không liên quan gì đến thuật toán.

Nhưng cách mà bạn tiếp cận thêm các bài kiểm tra đơn vị có thể được mô tả bằng một thuật toán như

  1. Xác định bài kiểm tra đơn vị mới
  2. Viết bài kiểm tra đơn vị
  3. Áp dụng thuật toán chuẩn hóa viết hoa
  4. Áp dụng thuật toán Nhận xét

Ví dụ: quốc tế hóa Đây là một ví dụ hoàn hảo về giải pháp thuật toán. Vì đơn giản nhất, bạn đang tìm kiếm một từ đã biết trong từ điển và thay thế bằng các hình thức ngôn ngữ khác nhau. (Tất nhiên cuộc sống thực liên quan đến câu và ngữ cảnh và thuật toán có thể bao gồm các bước để xác minh với người bản ngữ nhưng những điều cơ bản là đúng)

Vấn đề với hầu hết các câu trả lời Có là mọi người đang nghĩ về các thuật toán theo QuickSort, Bubble sort thay vì một bộ hướng dẫn làm giảm mô tả mơ hồ của một vấn đề thành một tập hợp các quy tắc logic / quy tắc rõ ràng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.