Lập trình tìm ký hiệu Landau (ký hiệu Big O hoặc Theta) của một thuật toán?

Tôi đã từng tìm kiếm ký hiệu Landau (Big O, Theta ...) bằng tay để đảm bảo chúng được tối ưu hóa nhất có thể, nhưng khi các chức năng đang trở nên rất lớn và phức tạp, nó sẽ diễn ra quá nhiều thời gian để làm điều đó bằng tay. nó cũng dễ bị lỗi của con người.

Tôi đã dành một chút thời gian cho Codility (bài tập mã hóa / thuật toán) và nhận thấy họ sẽ cung cấp cho bạn ký hiệu Landau cho giải pháp đã gửi của bạn (cả về cách sử dụng Thời gian và Bộ nhớ).

Tôi đã tự hỏi làm thế nào họ làm điều đó ... Làm thế nào bạn sẽ làm điều đó?

Có cách nào khác ngoài Phân tích từ điển hoặc phân tích mã không?

Câu hỏi này liên quan chủ yếu đến PHP và hoặc JavaScript, nhưng tôi đã mở cho bất kỳ ngôn ngữ và lý thuyết nào.

Tôi đã tự hỏi làm thế nào họ làm điều đó ... Làm thế nào bạn sẽ làm điều đó?

Tôi tưởng tượng rằng họ thực sự đang ước tính các biện pháp Big O ... bằng cách chạy chương trình cho các kích cỡ vấn đề khác nhau, đo thời gian và không gian sử dụng và điều chỉnh đường cong phù hợp với kết quả.

Vấn đề với cách tiếp cận này là nó có thể hiểu sai nếu các hàm chi phí thay đổi hình dạng khi N trở nên lớn; ví dụ 1000 N + N^1.5.

Có cách nào khác ngoài Phân tích từ điển hoặc phân tích mã không?

Phân tích từ vựng và phân tích cú pháp là không đủ. Bạn cũng cần phải làm một số lý do về hành vi của thuật toán. Và làm điều đó tự động cho một thuật toán chưa biết trước đây là khó.

Họ không thể phân tích mã.

Dưới đây là các ví dụ với "lạm phát / giảm phát" nhân tạo về độ phức tạp chứng tỏ rằng chỉ cần đo thời gian chạy chương trình là không đủ để ước tính đáng tin cậy Big-O

void lets_trick_runtime(int n) {
   if (n == 10 || n == 25 || n == 118) {
      // unfair speed-up
      do_precalculated_solution_in_constant_time(n);
      return;
   }
   if (n == 11 || n == 26 || n == 119) {
      // unfair slow-down
      do_some_fake_processing_in_n_cube_time(n);
      return;
   }
   // fair solution
   do_general_solution_in_quadratic_time(n);
}

Ước tính thời gian chạy ở trên sẽ có thể đưa ra ước tính giả - thời gian không đổi cho các giá trị nnơi có giải pháp được tính toán trước và thời gian khối cho các giá trị unfair slow-downbắt đầu - thay vì thời gian bậc hai "công bằng".

Tôi nghĩ rằng điều này là không thể.

Nếu bạn chạy một số thử nghiệm với một số lượng cố định các kích cỡ đầu vào khác nhau, bạn có thể dễ dàng tính toán một đa thức, điều đó sẽ gần đúng với thời gian chạy mà bạn đã đo rất tốt. Vì vậy, bạn kết thúc với một đa thức cho mọi chương trình có thể, có nghĩa là P = NP(yeah !;)).

Nếu bạn cố gắng làm điều đó với thao tác tượng trưng, ​​bạn sẽ kết thúc tại halting problem. Vì bạn không thể quyết định thời tiết chương trình của bạn sẽ dừng lại, bạn không thể quyết định mức độ phức tạp của thời gian chạy.

Tuy nhiên, có thể có những trường hợp rất đặc biệt, trong đó phương pháp sau là có thể. Nhưng những trường hợp này có thể nhỏ đến mức không thể tin được nếu nỗ lực được trả tiền.

Làm thế nào tôi sẽ làm điều đó? Cách tôi giải quyết hầu hết mọi vấn đề tôi không muốn ngồi xuống và giải quyết . Tôi mô phỏng.

Đối với nhiều vấn đề, có thể đủ để chạy thuật toán của bạn nhiều lần bằng nhiều kích cỡ khác nhau và sau đó khớp đường cong hồi quy với các kết quả đó. Điều đó sẽ nhanh chóng xác định một số chi phí trên không "cố định" cụ thể của thuật toán của bạn (phần chặn của đường cong) và cách nó thay đổi khi kích thước vấn đề của bạn tăng lên.

Sẽ cần một số sửa đổi để nắm bắt các giải pháp đặc biệt phức tạp, nhưng đặc biệt nếu bạn chỉ tìm kiếm một ước tính công viên bóng, bạn sẽ có thể có được nó theo cách đó và xem ước tính của bạn khác với kết quả thực tế của bạn như thế nào và quyết định xem nó có khác không một xấp xỉ chấp nhận được.

Điểm yếu lớn nhất trong suy nghĩ của tôi với phương pháp này là nếu thuật toán của bạn có quy mô thực sự kém, thì bước "chạy nó cả đống lần" ban đầu sẽ trở nên tồi tệ. Nhưng thành thật mà nói, đó là trường hợp, đó là một chỉ số mà bạn có thể muốn lùi lại và xem xét lại mọi thứ.

Trực giác của tôi là một giải pháp chung cho vấn đề này là không thể; khẳng định, như nó, một sự thật tiên nghiệm về thời gian chạy của các thuật toán mà không chạy chúng (bạn ám chỉ phân tích từ vựng). Điều đó nói rằng, có thể đối với một số thuật toán heuristic cho một loại thuật toán (có thể là lớn) (vì chúng ta làm điều đó mọi lúc), nhưng một thuật toán chung để làm điều này sẽ tương đương với việc giải bài toán Entscheidungs nổi tiếng không phải là có thể (xem Church, Turing, et al.). Tôi chắc chắn ~ 99,9% về điều này bây giờ khi tôi nghĩ về nó