Phương pháp Gradient BFGS so với Conjugate

Tôi nên cân nhắc điều gì khi lựa chọn giữa BFGS và gradient liên hợp để tối ưu hóa? Hàm tôi đang cố gắng khớp với các biến này là các hàm số mũ; tuy nhiên, chức năng mục tiêu thực tế liên quan đến tích hợp, trong số những thứ khác, và rất tốn kém nếu điều đó giúp ích gì cả.

JM nói đúng về lưu trữ. BFGS yêu cầu một Hessian gần đúng, nhưng bạn có thể khởi tạo nó bằng ma trận danh tính và sau đó chỉ cần tính toán các cập nhật cấp hai cho Hessian gần đúng khi bạn đi, miễn là bạn có thông tin về độ dốc, tốt nhất là phân tích thay vì thông qua các khác biệt hữu hạn. BFGS là một phương pháp gần như Newton, và sẽ hội tụ ít bước hơn so với CG, và có một chút ít xu hướng bị "mắc kẹt" và yêu cầu các điều chỉnh thuật toán nhẹ để đạt được mức giảm đáng kể cho mỗi lần lặp.

Ngược lại, CG yêu cầu các sản phẩm vector ma trận, có thể hữu ích cho bạn nếu bạn có thể tính toán các đạo hàm định hướng (một lần nữa, phân tích hoặc sử dụng các khác biệt hữu hạn). Một phép tính sai phân hữu hạn của đạo hàm định hướng sẽ rẻ hơn nhiều so với phép tính sai phân hữu hạn của Hessian, vì vậy nếu bạn chọn xây dựng thuật toán của mình bằng cách sử dụng các đạo hàm hữu hạn, chỉ cần tính trực tiếp đạo hàm. Tuy nhiên, quan sát này không thực sự áp dụng cho BFGS, sẽ tính toán người Hessian gần đúng bằng cách sử dụng các sản phẩm bên trong của thông tin độ dốc.

$n$$n$

Tôi sẽ so sánh hai thuật toán về một vấn đề thử nghiệm nhỏ cho ứng dụng của bạn nếu bạn biết rằng việc lưu trữ sẽ không phải là vấn đề. Không biết cụ thể cụ thể về vấn đề của bạn, tôi đoán là BFGS sẽ nhanh hơn, nhưng bạn thực sự nên thử nghiệm hai thuật toán để có ý tưởng tốt hơn về việc nó sẽ hoạt động tốt hơn.

Cuối cùng, một từ về sự khác biệt tự động: có một số kinh nghiệm với một cơ sở phân biệt tự động (AD) trong nhà cho Fortran ( DAEPACK ), tôi có thể nói với bạn rằng các công cụ AD thường rất khó. Họ có thể không nhất thiết có thể phân biệt mã mà họ tự tạo. Có hai loại công cụ AD:

• công cụ AD nguồn-to-source
• toán tử quá tải công cụ AD

Các công cụ nguồn-nguồn là về cơ bản các trình biên dịch được sửa đổi lấy mã nguồn bạn đã viết, phân tích cú pháp và tự động tạo mã nguồn mới để tính toán độ dốc của các hàm trong mã nguồn của bạn. Các công cụ AD quá tải toán tử yêu cầu bạn sử dụng các toán tử AD quá tải trong mã nguồn của bạn để các đạo hàm có thể được tính toán, điều này đòi hỏi nỗ lực bổ sung từ phía bạn để tính toán các dẫn xuất phân tích với AD.

$m$$m$

Theo kinh nghiệm của tôi, BFGS với rất nhiều cập nhật lưu trữ thông tin quá xa so với giải pháp hiện tại thực sự hữu ích trong việc xấp xỉ Jacobian không bị trễ và bạn thực sự có thể mất khả năng hội tụ nếu bạn lưu trữ quá nhiều. Có các biến thể BFGS "không bộ nhớ" trông rất giống các gradient liên hợp phi tuyến (xem bản cập nhật cuối cùng được mô tả cho một trong số này) chỉ vì những lý do này. Do đó, nếu bạn sẵn sàng thực hiện L-BFGS thay vì BFGS, các vấn đề về bộ nhớ sẽ biến mất và các phương thức có liên quan . Bằng chứng giai thoại chỉ ra rằng khởi động lại là một vấn đề khó khăn, vì đôi khi nó không cần thiết và đôi khi rất cần thiết.

Sự lựa chọn của bạn giữa hai người cũng phụ thuộc rất nhiều vào các vấn đề bạn quan tâm. Nếu bạn có tài nguyên, bạn có thể thử cả hai cho các vấn đề của mình và quyết định xem vấn đề nào hoạt động tốt hơn. Ví dụ, cá nhân tôi không thực hiện tối ưu hóa với các thuật toán này, mà thay vào đó quan tâm đến giải pháp của các hệ phương trình phi tuyến. Đối với những điều này tôi đã thấy rằng NCG hoạt động tốt hơn và dễ dàng thực hiện điều kiện tiên quyết phi tuyến hơn. BFGS mạnh mẽ hơn.

$m$

Trong các kích thước thấp, một phương pháp BFGS được triển khai tốt thường nhanh hơn và mạnh hơn CG, đặc biệt là nếu chức năng không quá xa so với phương trình bậc hai.

Cả BFGS và CG đều không cần bất kỳ giả định nào về độ lồi; chỉ có xấp xỉ Hessian ban đầu (đối với BFGS). điều kiện tiên quyết (đối với CG) phải xác định dương. Nhưng chúng luôn có thể được chọn là ma trận danh tính, ở kích thước thấp mà không gây hại nhiều. Xem thêm /scicomp//a/3213/1117

Trong trường hợp không có độ dốc được lập trình, sẽ rất lãng phí nỗ lực sử dụng độ dốc số, đặc biệt khi giá trị hàm đắt. Thay vào đó, người ta nên sử dụng một thuật toán không có đạo hàm. Xem http://archimedes.cheme.cmu.edu/?q=dfocomp cho một cuộc khảo sát gần đây.