Một ví dụ về một vấn đề kinh doanh không thể tính toán là gì?

Tôi có đồng nghiệp từ chối chấp nhận thực tế rằng máy Turing (và máy Von Neuman bằng cách mở rộng) không thể giải quyết vấn đề tạm dừng của chính họ nêu rõ:

Bạn có thể làm bất cứ điều gì với đủ thời gian và tiền bạc.

Ông cũng không thích các vấn đề lý thuyết cho rằng:

Trong lĩnh vực của chúng tôi, chúng tôi sẽ không bao giờ gặp phải những câu hỏi đó. Chúng tôi là nhà phát triển ứng dụng, không phải nhà khoa học lý thuyết.

Có một ví dụ hay về một vấn đề kinh doanh không thể tính toán mà tôi có thể sử dụng để giúp thuyết phục anh ấy về điều này?

Không phải kỹ thuật là không thể, nhưng ...

Lập kế hoạch tài nguyên , với mục tiêu tìm ra lịch trình lý tưởng tối đa hóa việc sử dụng các khe thời gian. Tôi đã từng tham gia một dự án, trong những ngày đầu tính toán, có yêu cầu này. Tôi đã làm việc với nó một lúc trước khi tôi nhận ra rằng đó là NP-hard.

Các ví dụ khác về các vấn đề không thể về mặt kỹ thuật, nhưng khó về mặt kỹ thuật, có thể tìm thấy ở đây .

Hầu hết các vấn đề tính toán cứng trong điện toán doanh nghiệp không phải là không thể, chỉ là không thực tế. Bạn của bạn nói đúng; bạn có thể giải quyết hầu hết trong số họ nếu bạn ném đủ tiền vào họ. Nhưng tranh luận là đặc biệt; toàn bộ quan điểm của việc điều hành một doanh nghiệp là kiếm tiền chứ không phải mất nó.

Trong thực tiễn hàng ngày, chúng ta nói về Turing hoàn chỉnh một cách mơ hồ, không phải để thể hiện một số nguyên tắc toán học, mà để minh họa (ví dụ) sự không đầy đủ của HTML và CSS như một phương tiện hoàn chỉnh để sản xuất các chương trình hoàn chỉnh tính năng.

Tương tự, Vấn đề dừng là quan trọng đối với các nhà lý thuyết, nhưng nó không liên quan nhiều đến hầu hết các doanh nghiệp.

Những người khác đã bình luận về điều này, nhưng tôi sẽ cố gắng viết ra một câu trả lời đưa ra quan điểm của tôi.

Tôi thích câu trả lời của Robert Harvey, và những bình luận cho câu trả lời của anh ấy, và tôi muốn mở rộng về những điều đó.

Tôi nghĩ rằng bạn phải trình bày những vấn đề không thể giải quyết này (như chấm dứt) theo cách trần tục: ví dụ: một công cụ IDE "kiểm tra xem hàm này có luôn trả về giá trị không".

Khi giảng dạy, ví dụ yêu thích của tôi là tái cấu trúc ( tương đương chức năng, một vấn đề không thể giải quyết khác ). Tôi hỏi:

Làm thế nào để bạn kiểm tra nếu một chức năng / chương trình làm tương tự sau khi tái cấu trúc tốt đẹp của bạn? Chắc chắn, chúng tôi có các bài kiểm tra đơn vị cho điều đó, nhưng chúng không bao gồm tất cả các trường hợp. Và họ thật nhàm chán khi viết ... Nhưng chúng tôi là những lập trình viên! Chúng ta nên viết một chương trình kiểm tra xem hai hàm này có tạo ra kết quả như nhau không! Tại sao bạn không thử viết nó?

hoặc, như một biến thể có thể gần với trường hợp của bạn hơn:

Chúng tôi có mã kế thừa này được viết bằng một phương ngữ COBOL tối nghĩa cổ xưa, mà không có thông số kỹ thuật và / hoặc trình biên dịch tồn tại. Chúng tôi chỉ có chương trình. Toàn bộ hoạt động kinh doanh của chúng tôi dựa vào nó, vì vậy chúng tôi phải chắc chắn 100% mã Java mới thực hiện giống hệt nhau trong mọi tình huống. Ban quản lý muốn một chương trình thực hiện điều đó, kiểm tra tất cả các trường hợp có thể và ước tính nó có thể được thực hiện trong 6 đến 8 tuần. Tại sao bạn không thử viết nó?

Vấn đề là không viết một chương trình như vậy. Hoặc một xấp xỉ đủ tốt của các yêu cầu. Vấn đề là nhận ra rằng nó KHÔNG thể được thực hiện theo cách trực tiếp, KHÔNG lãng phí vô số chúng ta đang cố gắng tìm ra cách để làm điều đó (chỉ để nhận ra rằng điều đó là không thể), nhưng nhận ra nó. "Ah! Điều này là không thể giải quyết được! Không thể làm điều đó trực tiếp. Tôi cần tìm ra một cách khác, thông minh hơn để làm điều đó, với một xấp xỉ đủ tốt".

Bạn phải tìm ra một cách để trình bày vấn đề theo cách dễ nhận biết và có vẻ đơn giản. Bạn sẽ không tin có bao nhiêu sinh viên CS sẽ cố gắng viết một chương trình như vậy ngay lập tức ... trước khi tham gia một lớp học tính toán :)

Giả sử chúng ta có thể đặt sang một bên các câu hỏi đạo đức sang một bên:

Doanh nghiệp A đã ký hợp đồng với bạn về cách liên lạc giữa các văn phòng vệ tinh A1 và A2 mà không có ai ngoài những người được ủy quyền trong A1 và A2 có thể hiểu được giao tiếp.

Doanh nghiệp B đã ký hợp đồng với bạn để có cách nghe lén thông minh trên tất cả các liên lạc giữa A1 và A2.

Rõ ràng bạn không thể làm cả hai.

Do cách thức hoạt động của toán học (toán học chính xác đã được nghiên cứu liên tục trong 100 năm), một trong những yêu cầu sau đây không thể được thỏa mãn:

(1): Cung cấp một thuật toán mã hóa không thể bị phá vỡ bởi kẻ tấn công với số tiền tùy ý có sẵn.

(2): Cung cấp thuật toán phá mã hóa cho thuật toán mã hóa tùy ý chạy trong thời gian hợp lý.

Gần đây tôi đã tham gia một lớp về Mô hình quy trình kinh doanh và ký hiệu ( BPMN ). Ở đó có thể dễ dàng nhận thấy rằng các quy trình công việc có quá nhiều phân tách, tham gia và các vòng lặp trở nên không thực tế (mặc dù không nhất thiết là không thể , AFAIK) để hiểu và kiểm soát, (khi bạn sử dụng quá nhiều phân tách OR thay vì chia tách XOR).

Đối với ngành công nghiệp phần mềm, tôi nghĩ điều tương tự cũng xảy ra đối với các vấn đề tương tự về "phạm vi bảo hiểm nhiều điều kiện" trong phân tích bảo hiểm mã .

Đối với một doanh nghiệp, cách để đi là thu hẹp không gian vấn đề, và không ném thêm tài nguyên vào vấn đề phức tạp. Trong ví dụ của tôi, thêm các ràng buộc cho quy trình công việc, (hoặc trong phân tích độ bao phủ mã, đơn giản hóa mã), thay vì làm việc chăm chỉ để tìm tất cả, giả sử, N có thể có dấu vết và kết quả trong đó N là một số lượng lớn không thể tưởng tượng được.

Ngoài ra, tôi nghĩ rằng có nhiều vấn đề trong phân tích mạng / đồ thị không thể giải quyết (cố gắng xác định cấu trúc liên kết mạng bằng cách lặp đi lặp lại tất cả các đường dẫn, v.v.).

Ví dụ kinh điển là cố gắng phân tích HTML bằng các biểu thức thông thường . Điều này có thể hoạt động với các bộ HTML giới hạn nhưng một giải pháp chung là không thể, do thực tế là chúng có các ngữ pháp Chomsky khác nhau (vì liên kết làm cho rõ ràng (ish)).

Nói chung, một số người không thích suy nghĩ một cách triết lý (như đồng nghiệp của bạn) và tôi không chắc bạn có thể tranh luận theo cách của bạn ra khỏi một tâm trí. Điểm đầu tiên của anh ấy chắc chắn là sai nhưng lần thứ hai của anh ấy có thể chỉ là một cách để nói rằng tôi không cần phải lo lắng về điều này để mã hóa các biểu mẫu web để nhận hàng. Tôi đã có một số thiện cảm với điều này nhưng đôi khi biết lý thuyết có nghĩa là bạn không cam kết tìm kiếm Chén Thánh trong thời gian làm việc.

Có lẽ câu trả lời là đồng nghiệp của bạn là chính xác. Có lẽ bạn đã hiểu nhầm Turing, hoặc nó áp dụng ở đây như thế nào?

Tất cả các máy đều hữu hạn, do đó không có máy Turing 'thật' và không có chương trình nào sẽ không bao giờ dừng lại. Một chương trình tầm thường thực hiện một vòng lặp vô hạn đơn giản có thể chạy 5 phút hoặc 50 năm nhưng trên một máy hữu hạn, nó sẽ dừng lại. Một vấn đề không dừng không tầm thường như 'tính toán chính xác pi' cũng sẽ dừng lại, bởi vì cuối cùng phép tính sẽ vượt quá khả năng lưu trữ các chữ số tiếp theo.

Kết quả Turing không đảm bảo bất cứ điều gì đặc biệt hữu ích trên các máy hữu hạn, vì vậy nhiệm vụ của bạn cuối cùng không có kết quả. Tốt hơn để tập trung vào bao nhiêu thời gian và bao nhiêu tiền và để lại vô hạn cho các nhà toán học.

Bạn có thể nghĩ rằng một chương trình như { while true: print "running"; print "halted"; }là một ví dụ ngược lại nhưng thực tế không phải vậy. Chương trình này có tác dụng phụ, có thể hoặc không thể khiến nó dừng lại. Bỏ qua các tác dụng phụ, có thể đưa ra một bằng chứng chính thức rằng chương trình này sẽ không dừng lại. Trong câu hỏi này, chúng tôi chỉ quan tâm đến các chương trình trốn tránh bằng chứng chính thức về việc không tạm dừng, trong đó câu hỏi tạm dừng là không thể giải quyết được. Đây không phải là một chương trình như vậy.

Nó có thể giúp phân biệt Turing 'mạnh' với Turing 'yếu'. Máy Turing mạnh thực sự là vô hạn và nếu chúng không dừng lại, sẽ chạy trong thời gian vô hạn. Chúng ta không thể xây dựng chúng.

Máy yếu Turing có giới hạn hữu hạn về thời gian và không gian, và chúng là loại duy nhất chúng ta có thể xây dựng. Chúng tôi quan tâm đến các chương trình không thể được chứng minh là dừng lại trong những giới hạn đó. Turing nói với chúng tôi rằng có những chương trình như vậy nhưng chúng tôi không thể xác định chúng. Nếu các giới hạn đủ thấp, chúng ta có thể xác định chúng bằng cách viết chương trình và chạy nó đến giới hạn của nó.

Bản chất của Turing là không có phím tắt. Cách duy nhất để chắc chắn liệu một vấn đề có khả thi về mặt tính toán hay không là viết chương trình, chạy nó và tìm hiểu. Với đủ thời gian và tiền bạc, bạn có thể viết tất cả các chương trình, chạy chúng mãi mãi và theo thời gian, và tìm ra những chương trình tạo ra kết quả (bộ chia). Những người khác vẫn sẽ chạy. Bạn đồng nghiệp có đủ thời gian và tiền bạc để làm việc đó không?

Nghiêm túc mà nói, tranh chấp là về giới hạn. Turing và NP hoàn thành cho chúng tôi biết rằng các loại vấn đề nhất định không thể được giải quyết bằng máy tính trong bất kỳ ngân sách nhất định hoặc theo bất kỳ lịch trình cụ thể nào, bất kể ngân sách đó lớn hay lịch trình đó có thể hào phóng đến mức nào. Ví dụ về loại vấn đề đó rất nhiều: phá khóa mật mã; tối ưu hóa các tuyến đường để thực hiện giao hàng đến hàng trăm địa chỉ; hộp đóng gói trong xe tải; tìm lỗi trong các chương trình lớn!

Vì vậy, hãy hỏi đồng nghiệp của bạn về ngân sách và lịch trình, và đưa ra một lời hứa rằng bạn có thể tạo ra một vấn đề không thể giải quyết trong ngân sách hoặc lịch trình đó. Lời hứa đó sẽ rất dễ giữ.