Có phải là thực hành tốt để thay thế phép chia bằng phép nhân khi có thể?

Bất cứ khi nào tôi cần phân chia, ví dụ, kiểm tra điều kiện, tôi muốn cấu trúc lại biểu thức của phép chia thành phép nhân, ví dụ:

Phiên bản gốc:

if(newValue / oldValue >= SOME_CONSTANT)

Phiên bản mới:

if(newValue >= oldValue * SOME_CONSTANT)

Bởi vì tôi nghĩ rằng nó có thể tránh:

1. Chia cho số không

2. Tràn khi oldValuenhỏ

Có đúng không? Có một vấn đề cho thói quen này?

Hai trường hợp phổ biến để xem xét:

Số nguyên

Rõ ràng nếu bạn đang sử dụng số học số nguyên (cắt ngắn), bạn sẽ nhận được một kết quả khác. Đây là một ví dụ nhỏ trong C #:

public static void TestIntegerArithmetic()
{
    int newValue = 101;
    int oldValue = 10;
    int SOME_CONSTANT = 10;

    if(newValue / oldValue > SOME_CONSTANT)
    {
        Console.WriteLine("First comparison says it's bigger.");
    }
    else
    {
        Console.WriteLine("First comparison says it's not bigger.");
    }

    if(newValue > oldValue * SOME_CONSTANT)
    {
        Console.WriteLine("Second comparison says it's bigger.");
    }
    else
    {
        Console.WriteLine("Second comparison says it's not bigger.");
    }
}

Đầu ra:

First comparison says it's not bigger.
Second comparison says it's bigger.

Số học dấu phẩy động

Ngoài việc phân chia có thể mang lại một kết quả khác khi nó chia cho 0 (nó tạo ra một ngoại lệ, trong khi phép nhân không), nó cũng có thể dẫn đến các lỗi làm tròn hơi khác nhau và kết quả khác nhau. Ví dụ đơn giản trong C #:

public static void TestFloatingPoint()
{
    double newValue = 1;
    double oldValue = 3;
    double SOME_CONSTANT = 0.33333333333333335;

    if(newValue / oldValue >= SOME_CONSTANT)
    {
        Console.WriteLine("First comparison says it's bigger.");
    }
    else
    {
        Console.WriteLine("First comparison says it's not bigger.");
    }

    if(newValue >= oldValue * SOME_CONSTANT)
    {
        Console.WriteLine("Second comparison says it's bigger.");
    }
    else
    {
        Console.WriteLine("Second comparison says it's not bigger.");
    }
}

Đầu ra:

First comparison says it's not bigger.
Second comparison says it's bigger.

Trong trường hợp bạn không tin tôi, đây là một Fiddle mà bạn có thể tự mình thực hiện và xem.

Các ngôn ngữ khác có thể khác nhau; Tuy nhiên, hãy nhớ rằng C #, giống như nhiều ngôn ngữ, triển khai thư viện dấu phẩy động chuẩn (IEEE 754) , do đó bạn sẽ nhận được kết quả tương tự trong các lần chạy chuẩn hóa khác.

Phần kết luận

Nếu bạn đang làm việc trên cánh đồng xanh , có lẽ bạn vẫn ổn.

Nếu bạn đang làm việc với mã kế thừa và ứng dụng là một ứng dụng tài chính hoặc nhạy cảm khác thực hiện số học và được yêu cầu cung cấp kết quả nhất quán, hãy thận trọng khi thay đổi xung quanh các hoạt động. Nếu bạn phải, hãy chắc chắn rằng bạn có các bài kiểm tra đơn vị sẽ phát hiện bất kỳ thay đổi tinh tế nào trong số học.

Nếu bạn chỉ làm những việc như đếm các phần tử trong một mảng hoặc các hàm tính toán chung khác, có lẽ bạn sẽ ổn. Tuy nhiên, tôi không chắc phương thức nhân làm cho mã của bạn rõ ràng hơn.

Nếu bạn đang triển khai thuật toán cho một đặc tả, tôi sẽ không thay đổi gì cả, không chỉ vì vấn đề làm tròn lỗi, mà để các nhà phát triển có thể xem lại mã và ánh xạ từng biểu thức trở lại đặc tả để đảm bảo không có triển khai sai sót.

Tôi thích câu hỏi của bạn vì nó có khả năng bao gồm nhiều ý tưởng. Nhìn chung, tôi nghi ngờ câu trả lời là nó phụ thuộc , có thể phụ thuộc vào các loại liên quan và phạm vi giá trị có thể có trong trường hợp cụ thể của bạn.

Bản năng ban đầu của tôi là phản ánh về phong cách , tức là. phiên bản mới của bạn không rõ ràng đối với người đọc mã của bạn. Tôi tưởng tượng rằng tôi sẽ phải suy nghĩ trong một hoặc hai giây (hoặc có thể lâu hơn) để xác định ý định của phiên bản mới của bạn, trong khi phiên bản cũ của bạn ngay lập tức rõ ràng. Khả năng đọc là một thuộc tính quan trọng của mã, do đó, có một chi phí trong phiên bản mới của bạn.

Bạn có quyền rằng phiên bản mới sẽ tránh sự phân chia bằng không. Chắc chắn bạn không cần phải thêm một người bảo vệ (dọc theo dòng if (oldValue != 0)). Nhưng điều này có ý nghĩa? Phiên bản cũ của bạn phản ánh tỷ lệ giữa hai số. Nếu số chia là 0, thì tỷ lệ của bạn không xác định. Điều này có thể có ý nghĩa hơn trong tình huống của bạn, tức là. bạn không nên tạo ra một kết quả trong trường hợp này.

Bảo vệ chống tràn là tranh cãi. Nếu bạn biết rằng newValuenó luôn lớn hơn oldValue, thì có lẽ bạn có thể đưa ra lập luận đó. Tuy nhiên, có thể có trường hợp (oldValue * SOME_CONSTANT)cũng sẽ tràn. Vì vậy, tôi không thấy nhiều lợi ích ở đây.

Có thể có một đối số rằng bạn có hiệu suất tốt hơn vì phép nhân có thể nhanh hơn phép chia (trên một số bộ xử lý). Tuy nhiên, sẽ phải có nhiều tính toán như thế này để đạt được mức tăng đáng kể, tức là. coi chừng tối ưu hóa sớm.

Nhìn chung về tất cả những điều trên, nói chung, tôi không nghĩ rằng sẽ có được nhiều thứ với phiên bản mới của bạn so với phiên bản cũ, đặc biệt là giảm sự rõ ràng. Tuy nhiên, có thể có những trường hợp cụ thể trong đó có một số lợi ích.

Không.

Có lẽ tôi gọi đó là tối ưu hóa sớm , theo nghĩa rộng, bất kể bạn đang tối ưu hóa hiệu suất , vì cụm từ thường nói đến, hoặc bất cứ điều gì khác có thể được tối ưu hóa, chẳng hạn như đếm cạnh , dòng mã hoặc thậm chí rộng hơn, những thứ như "thiết kế."

Việc thực hiện loại tối ưu hóa đó như một quy trình vận hành tiêu chuẩn sẽ đặt rủi ro về ngữ nghĩa của mã của bạn và có khả năng che giấu các cạnh. Các trường hợp cạnh bạn thấy phù hợp để loại bỏ âm thầm có thể cần phải được giải quyết rõ ràng bằng mọi cách . Và, cực kỳ dễ dàng hơn để gỡ lỗi các vấn đề xung quanh các cạnh ồn ào (những vấn đề ném ngoại lệ) so với những vấn đề thất bại trong âm thầm.

Và, trong một số trường hợp, thậm chí còn có lợi khi "tối ưu hóa" vì mục đích dễ đọc, rõ ràng hoặc làm chứng. Trong hầu hết các trường hợp, người dùng của bạn sẽ không nhận thấy rằng bạn đã lưu một vài dòng mã hoặc chu kỳ CPU để tránh xử lý trường hợp cạnh hoặc xử lý ngoại lệ. Mặt khác, mã lúng túng hoặc thất bại sẽ ảnh hưởng đến mọi người - ít nhất là đồng nghiệp của bạn. (Và, do đó, chi phí để xây dựng và bảo trì phần mềm.)

Mặc định cho bất cứ điều gì "tự nhiên" hơn và dễ đọc hơn đối với miền của ứng dụng và vấn đề cụ thể. Giữ cho nó đơn giản, rõ ràng và thành ngữ. Tối ưu hóa là cần thiết cho lợi ích đáng kể hoặc để đạt được ngưỡng khả năng sử dụng hợp pháp.

^{Cũng lưu ý: Trình biên dịch thường tối ưu hóa phân chia cho bạn bằng mọi cách - khi nào an toàn để làm như vậy.}

Sử dụng cái nào ít lỗi hơn và có ý nghĩa logic hơn.

Thông thường , chia cho một biến là một ý tưởng tồi, vì thông thường, số chia có thể bằng không.
Chia theo hằng số thường chỉ phụ thuộc vào ý nghĩa logic là gì.

Dưới đây là một số ví dụ để cho thấy nó phụ thuộc vào tình huống:

Phân chia tốt:

if ((ptr2 - ptr1) >= n / 3)  // good: check if length of subarray is at least n/3
    ...

Nhân xấu:

if ((ptr2 - ptr1) * 3 >= n)  // bad: confusing!! what is the intention of this code?
    ...

Nhân giống tốt:

if (j - i >= 2 * min_length)  // good: obviously checking for a minimum length
    ...

Phân chia xấu:

if ((j - i) / 2 >= min_length)  // bad: confusing!! what is the intention of this code?
    ...

Nhân giống tốt:

if (new_length >= old_length * 1.5)  // good: is the new size at least 50% bigger?
    ...

Phân chia xấu:

if (new_length / old_length >= 2)  // bad: BUGGY!! will fail if old_length = 0!
    ...

Làm bất cứ điều gì bất cứ khi nào có thể, rất hiếm khi là một ý tưởng tốt.

Ưu tiên số một của bạn phải là sự chính xác, tiếp theo là khả năng đọc và bảo trì. Thay thế một cách mù quáng sự phân chia bằng phép nhân bất cứ khi nào có thể thường sẽ thất bại trong bộ phận chính xác, đôi khi chỉ trong trường hợp hiếm và do đó khó tìm thấy trường hợp.

Làm những gì chính xác và dễ đọc nhất. Nếu bạn có bằng chứng chắc chắn rằng viết mã theo cách dễ đọc nhất gây ra vấn đề về hiệu năng, thì bạn có thể xem xét thay đổi nó. Chăm sóc, toán học và đánh giá mã là bạn bè của bạn.

Về khả năng đọc của mã, tôi nghĩ rằng phép nhân thực sự dễ đọc hơn trong một số trường hợp. Ví dụ: nếu có thứ gì đó mà bạn phải kiểm tra xem newValueđã tăng 5 phần trăm trở lên ở trên chưa oldValue, thì đó 1.05 * oldValuelà ngưỡng để kiểm tra newValuevà đó là điều tự nhiên khi viết

    if (newValue >= 1.05 * oldValue)

Nhưng hãy cẩn thận với các số âm khi bạn cấu trúc lại mọi thứ theo cách này (hoặc thay thế phép chia bằng phép nhân hoặc thay thế phép nhân bằng phép chia). Hai điều kiện bạn xem là tương đương nếu oldValueđược đảm bảo không âm tính; nhưng giả sử newValuethực sự là -13,5 và oldValuelà -10,1. Sau đó

newValue/oldValue >= 1.05

đánh giá là đúng , nhưng

newValue >= 1.05 * oldValue

đánh giá thành sai .

Lưu ý Phân chia giấy nổi tiếng theo Số nguyên bất biến bằng cách nhân .

Trình biên dịch thực sự đang thực hiện phép nhân, nếu số nguyên là bất biến! Không phải là một bộ phận. Điều này xảy ra ngay cả đối với sức mạnh không có 2 giá trị. Sức mạnh của 2 bộ phận sử dụng dịch chuyển bit rõ ràng và do đó thậm chí còn nhanh hơn.

Tuy nhiên, đối với các số nguyên không bất biến, bạn có trách nhiệm tối ưu hóa mã. Hãy chắc chắn trước khi tối ưu hóa rằng bạn thực sự tối ưu hóa một nút cổ chai chính hãng và sự đúng đắn đó không bị hy sinh. Cẩn thận với tràn số nguyên.

Tôi quan tâm đến tối ưu hóa vi mô, vì vậy tôi có thể sẽ xem xét các khả năng tối ưu hóa.

Cũng nghĩ về kiến ​​trúc mã của bạn chạy trên. Đặc biệt ARM có sự phân chia cực kỳ chậm; bạn cần gọi một hàm để chia, không có lệnh chia trong ARM.

Ngoài ra, trên các kiến ​​trúc 32 bit, phân chia 64 bit không được tối ưu hóa, như tôi đã tìm ra .

Chọn điểm 2 của bạn, nó thực sự sẽ ngăn chặn tràn cho rất nhỏ oldValue. Tuy nhiên, nếu SOME_CONSTANTcũng rất nhỏ thì phương thức thay thế của bạn sẽ kết thúc bằng dòng chảy, trong đó giá trị không thể được biểu diễn chính xác.

Và ngược lại, điều gì xảy ra nếu oldValuerất lớn? Bạn có những vấn đề tương tự, chỉ là cách ngược lại.

Nếu bạn muốn tránh (hoặc giảm thiểu) nguy cơ tràn / tràn, cách tốt nhất là kiểm tra xem newValuemức độ gần nhất với oldValuehoặc tới SOME_CONSTANT. Sau đó, bạn có thể chọn thao tác chia thích hợp

    if(newValue / oldValue >= SOME_CONSTANT)

hoặc là

    if(newValue / SOME_CONSTANT >= oldValue)

và kết quả sẽ chính xác nhất.

Đối với chia cho 0, theo kinh nghiệm của tôi, điều này gần như không bao giờ thích hợp để được "giải" trong toán học. Nếu bạn có một số chia cho các kiểm tra liên tục của mình, thì gần như chắc chắn bạn có một tình huống đòi hỏi một số phân tích và mọi tính toán dựa trên dữ liệu này là vô nghĩa. Một kiểm tra phân chia rõ ràng gần như luôn luôn là động thái thích hợp. (Lưu ý rằng tôi nói "gần như" ở đây, vì tôi không cho là không thể sai được. Tôi chỉ lưu ý rằng tôi không nhớ đã thấy một lý do chính đáng cho việc này trong 20 năm viết phần mềm nhúng và tiếp tục .)

Tuy nhiên, nếu bạn có nguy cơ thực sự tràn / tràn trong ứng dụng thì đây có lẽ không phải là giải pháp phù hợp. Nhiều khả năng, bạn thường nên kiểm tra tính ổn định số của thuật toán của mình hoặc có thể chỉ cần chuyển sang biểu diễn có độ chính xác cao hơn.

Và nếu bạn không có nguy cơ tràn / tràn đã được chứng minh, thì bạn không lo lắng gì cả. Điều đó có nghĩa là bạn thực sự cần phải chứng minh rằng bạn cần nó, với những con số, trong các bình luận bên cạnh mã giải thích cho người bảo trì tại sao lại cần thiết. Là một kỹ sư chính đang xem xét mã của người khác, nếu tôi gặp phải ai đó nỗ lực thêm về việc này, cá nhân tôi sẽ không chấp nhận bất cứ điều gì ít hơn. Điều này trái ngược với tối ưu hóa sớm, nhưng nhìn chung nó sẽ có cùng nguyên nhân gốc rễ - nỗi ám ảnh với chi tiết không có sự khác biệt về chức năng.

Đóng gói số học có điều kiện trong các phương pháp và tính chất có ý nghĩa. Việc đặt tên tốt không chỉ cho bạn biết "A / B" nghĩa là gì , việc kiểm tra tham số & xử lý lỗi cũng có thể ẩn gọn trong đó.

Điều quan trọng, vì các phương thức này được cấu thành thành logic phức tạp hơn, độ phức tạp bên ngoài vẫn rất dễ quản lý.

Tôi muốn nói thay thế nhân có vẻ là một giải pháp hợp lý bởi vì vấn đề không rõ ràng.

Tôi nghĩ rằng không thể thay thế phép nhân bằng các phép chia vì ALU (Đơn vị logic số học) của CPU thực thi các thuật toán, mặc dù chúng được triển khai trong phần cứng. Các kỹ thuật tinh vi hơn có sẵn trong các bộ xử lý mới hơn. Nói chung, các bộ xử lý cố gắng song song hóa các hoạt động của cặp bit để giảm thiểu các chu kỳ xung nhịp cần thiết. Các thuật toán nhân có thể được song song khá hiệu quả (mặc dù cần nhiều bóng bán dẫn hơn). Các thuật toán phân chia không thể được song song hóa một cách hiệu quả. Các thuật toán phân chia hiệu quả nhất là khá phức tạp. Nói chung, chúng đòi hỏi nhiều chu kỳ xung nhịp hơn trên mỗi bit.