Bí ẩn hàm DATEDIF đã có lời giải!

[PhanTuHuong]

Cái này giống như tính tuổi vậy! "ĐỦ" thì mới tính. Trường hợp trên phải ráng ngủ cho qua 12 giờ đêm thì nó mới tính 1 tháng
Tôi thấy rất hợp lý chứ không thể gọi là không chính xác được
Còn chuyện ta áp dụng trong những trường hợp cụ thể thì tự ta phải suy luận, biến đổi sao cho phù hợp thì thôi

Chúng ta tạm bỏ qua tham số "md" vì ít dùng. Bản thân thằng Microsoft khuyến cáo Important: We don't recommend using the "MD" argument, as there are known limitations with it. See the known issues section below.

Đúng là thằng Datadif nó có nguyên tắc làm việc riêng như bác ndu nói, nó yêu cầu phải "đủ" thì mới tính. Nếu chưa đạt thì sẽ bị làm tròn xuống không thương tiếc dù đã đạt 30/31 ngày
Ví dụ so sánh:
- Ngày bắt đầu 1/5/2017, ngày kết thúc 31/5/2017 thì trả về 0 tháng.
- Ngày bắt đầu 30/4/2017, ngày kết thúc 29/5/2017 cũng trả về 0 tháng. Nhưng ngày kết thúc 30/5/2017 (chỉ tăng lên đúng 1 ngày so với 29/5) thì trả về 1.

Như vậy các bạn làm việc với hàm này cũng cần chú ý! Microsoft đã từng tranh luận về hàm này. Việc ẩn tên hàm có lẽ liên quan đến bản quyền (nhưng vẫn hỗ trợ âm thầm ).

 

[quocgiacan]

Cái này giống như tính tuổi vậy! "ĐỦ" thì mới tính. Trường hợp trên phải ráng ngủ cho qua 12 giờ đêm thì nó mới tính 1 tháng
Tôi thấy rất hợp lý chứ không thể gọi là không chính xác được
Còn chuyện ta áp dụng trong những trường hợp cụ thể thì tự ta phải suy luận, biến đổi sao cho phù hợp thì thôi

Hoàn toàn đồng ý với thầy chỗ: "ĐỦ" thì mới tính.

Chính cái chỗ "ĐỦ" này khiến cho lúc tính phép năm cứ nghĩ: hễ từ cuối tháng này đến cuối tháng sau là đủ 1 tháng, nên khi áp đối số 'm' vào thì đinh ninh ra đúng nhưng hóa ra không như ý vì các tháng 31 ngày nó báo 1 tháng (đúng), nhưng các tháng <31 nó báo 0 tháng (làm sai bài toán - file kèm)

Nên việc nhận diện "ĐỦ" khi dùng đối số 'm' và 'md' khi tìm tháng giữa hai thời điểm bất kỳ phải cẩn thận kiểm tra lại, nếu không sẽ ảnh hưởng đến kết quả mình mong muốn.

Chúc thầy ngày vui.

 

[ndu96081631]

Hoàn toàn đồng ý với thấy chỗ: "ĐỦ" thì mới tính.

Chính cái chỗ "ĐỦ" này khiến cho lúc tính phép năm cứ nghĩ: hễ từ cuối tháng này đến cuối tháng sau là đủ 1 tháng, nên khi áp đối số 'm' vào thì đinh ninh ra đúng nhưng hóa ra không như ý vì các tháng 31 ngày nó báo 1 tháng (đúng), nhưng các tháng <31 nó báo 0 tháng (làm sai bài toán - file kèm)

Nên việc nhận diện "ĐỦ" khi dùng đối số 'm' và 'md' khi tìm tháng giữa hai thời điểm bất kỳ phải cẩn thận kiểm tra lại, nếu không sẽ ảnh hưởng đến kết quả mình mong muốn.

Chúc thầy ngày vui.

Bởi vậy mình đã nói trước rằng:

Còn chuyện ta áp dụng trong những trường hợp cụ thể thì tự ta phải suy luận, biến đổi sao cho phù hợp thì thôi

Chứ hàm người ta đã viết vậy rồi, mình chỉ có 2 quyết định: Hoặc là xài, hoặc là không thôi chứ phân tích nó chính xác hay không chính xác cũng không giải quyết được vấn đề gì
Nói về vụ KHÔNG CHÍNH XÁC thì cũng có đầy hàm "dính" chứ không riêng gì DATEDIF đâu (COUNTIF chẳng hạn)

 

[PhanTuHuong]

Bởi vậy mình đã nói trước rằng:

Chứ hàm người ta đã viết vậy rồi, mình chỉ có 2 quyết định: Hoặc là xài, hoặc là không thôi chứ phân tích nó chính xác hay không chính xác cũng không giải quyết được vấn đề gì
Nói về vụ KHÔNG CHÍNH XÁC thì cũng có đầy hàm "dính" chứ không riêng gì DATEDIF đâu (COUNTIF chẳng hạn)

Em phản đối bác vấn đề này. Vì khi khai thác hàm chúng ta phải tìm hiểu kỹ 1 chút. Từ trước em (chắc nhiều người cũng vậy) tin tưởng hàm tính này. Tuy nhiên nó gặp rắc rối ở một số tình huống mà ta không lường tới. Điều đó dẫn đến lỗi mà ta không bao giờ biết được. Vô tình google hàm này thấy Microsoft nói mới để ý chứ mấy khi dùng
Ví dụ cả hàm Vlookup, sơ ý bỏ qua tham số tìm chính xác (1) thì cho ngay kết quả tương đối (mặc định mới đau). Chuối 1 cái là ban đầu thì ok, nhưng làm nhiều lần mới dính. Tham chiếu sai thì hỏng ngay.
Còn hàm Match cũng vậy, ít người chú ý về sắp xếp theo giá trị tăng hay giảm dần ở 1 số tình huống nhất định...

 

[ndu96081631]

Em phản đối bác vấn đề này. Vì khi khai thác hàm chúng ta phải tìm hiểu kỹ 1 chút. Từ trước em (chắc nhiều người cũng vậy) tin tưởng hàm tính này. Tuy nhiên nó gặp rắc rối ở một số tình huống mà ta không lường tới. Điều đó dẫn đến lỗi mà ta không bao giờ biết được. Vô tình google hàm này thấy Microsoft nói mới để ý chứ mấy khi dùng
Ví dụ cả hàm Vlookup, sơ ý bỏ qua tham số tìm chính xác (1) thì cho ngay kết quả tương đối (mặc định mới đau). Chuối 1 cái là ban đầu thì ok, nhưng làm nhiều lần mới dính. Tham chiếu sai thì hỏng ngay.
Còn hàm Match cũng vậy, ít người chú ý về sắp xếp theo giá trị tăng hay giảm dần ở 1 số tình huống nhất định...

Mình đâu có kiến gì về cái vụ "tìm hiểu" đâu chứ? Mình chỉ không đồng ý với ý kiến cho rằng hàm này hoặc hàm kia "không chinh xác" mà thôi. Bởi hàm người ta viết ra nó hoạt động như vậy là như vậy, ta chẳng thay đổi được gì cả. Ngoài ra thì cũng có đầy hàm hoạt động theo kiểu "không chính xác" kia chứ đâu riêng DATEDIF... rồi ta.. làm sao đây? Nghỉ xài chắc?

 

[eke_rula]

Bởi vậy mình đã nói trước rằng:

Chứ hàm người ta đã viết vậy rồi, mình chỉ có 2 quyết định: Hoặc là xài, hoặc là không thôi chứ phân tích nó chính xác hay không chính xác cũng không giải quyết được vấn đề gì
Nói về vụ KHÔNG CHÍNH XÁC thì cũng có đầy hàm "dính" chứ không riêng gì DATEDIF đâu (COUNTIF chẳng hạn)

Anh cho em trường hợp countif chạy không chính xác với anh???

 

[ndu96081631]

Anh cho em trường hợp countif chạy không chính xác với anh???

Xem hình và tự thí nghiệm nhé
Tuy nhiên tôi vẫn không cho là nó "không chính xác". Tại anh Bill viết nó thế thì nó.. phải thế. Đành chịu!

 

[eke_rula]

Xem hình và tự thí nghiệm nhé View attachment 180129
Tuy nhiên tôi vẫn không cho là nó "không chính xác". Tại anh Bill viết nó thế thì nó.. phải thế. Đành chịu!

Theo em nghĩ đây là các trường hợp đặc biệt thôi anh ạ, các chuỗi text dạng đặc biệt như là dạng format ngày tháng , hay giờ phút có thể xem như là dạng lai của text và number ,thường thì ta viết --"ABC" thì sẽ lỗi #VALUE còn các trường hợp này sẽ chuyển về number ví dụ --"1/1"=1/1/2017 hay--"7:59" là 7 giờ 59 phút. Nên trong trường hợp này em nghĩ countif chạy đúng!!

 

[ndu96081631]

Theo em nghĩ đây là các trường hợp đặc biệt thôi anh ạ, các chuỗi text dạng đặc biệt như là dạng format ngày tháng , hay giờ phút có thể xem như là dạng lai của text và number ,thường thì ta viết --"ABC" thì sẽ lỗi #VALUE còn các trường hợp này sẽ chuyển về number ví dụ --"1/1"=1/1/2017 hay--"7:59" là 7 giờ 59 phút. Nên trong trường hợp này em nghĩ countif chạy đúng!!

Hầu như hàm nào cũng có mấy vụ "đặc biệt" ấy cả. Vậy thì.. làm sao?

 

[eke_rula]

Hầu như hàm nào cũng có mấy vụ "đặc biệt" ấy cả. Vậy thì.. làm sao?

Thì như anh nói tùy trường hợp mà tùy biến thôi, anh sửa công thức bài #27 của anh lại như vầy xem: =COUNTIF($A$1:$A$10,42736). Trường hợp này nó hiểu "1/1" là number.

 

[ndu96081631]

Thì như anh nói tùy trường hợp mà tùy biến thôi, anh sửa công thức bài #27 của anh lại như vầy xem: =COUNTIF($A$1:$A$10,42736). Trường hợp này nó hiểu "1/1" là number.

Nhưng tôi muốn đếm chuỗi "1/1" cơ mà!
Trường hợp này đã có nhiều người dính và đã được khuyên là chuyển sang dùng SUMPRODUC đấy

 

[ndu96081631]

Cho các bạn thêm 1 ví dụ về "không chính xác" của các hàm đây
Như ta biết 2 dữ liệu TRUE và FALSE mà AND với nhau thì sẽ cho kết quả FALSE (quá cơ bản)
Vậy các bạn có bao giờ thấy tình trạng kỳ cục như hình dưới đây chưa?

 

[eke_rula]

Nhưng tôi muốn đếm chuỗi "1/1" cơ mà!
Trường hợp này đã có nhiều người dính và đã được khuyên là chuyển sang dùng SUMPRODUC đấy

Các trường hợp này thì nên chuyển về sumproduct, em nghĩ countif và sumif quá mạnh nên nó nghĩ các trường hợp đặc biệt này là như nhau, như kiểu mặc định của excel khi nhập 1/1 mà không có dấu nháy trước nó sẽ tự động chuyển thành 1/1/2017

 

[eke_rula]

Cho các bạn thêm 1 ví dụ về "không chính xác" của các hàm đây
Như ta biết 2 dữ liệu TRUE và FALSE mà AND với nhau thì sẽ cho kết quả FALSE (quá cơ bản)
Vậy các bạn có bao giờ thấy tình trạng kỳ cục như hình dưới đây chưa?

View attachment 180134

Anh cho xem công thức ở A1, A2 đi anh???!!!

 

[ndu96081631]

Anh cho xem công thức ở A1, A2 đi anh???!!!

Hổng có công thức gì ở A1 và A2 cả, dữ liệu nhập bình thường
Ẹc.. Ẹc... vậy mới kỳ chứ
Bạn cứ thử từa lưa đi, hồi nó.. ra hà

 

[quocgiacan]

Công nhận thầy có mấy lưu ý ngộ mà hay hay.

Nhưng tôi muốn đếm chuỗi "1/1" cơ mà!
Trường hợp này đã có nhiều người dính và đã được khuyên là chuyển sang dùng SUMPRODUC đấy

Phải là dùng COUNTIF(A1:A9,"1/1*") không thầy!!

Như ta biết 2 dữ liệu TRUE và FALSE mà AND với nhau thì sẽ cho kết quả FALSE (quá cơ bản)

Chắc cái thứ 2 có Type(...)=2

Chúc thầy một ngày vui.

 

[ndu96081631]

Phải là dùng COUNTIF(A1:A9,"1/1*") không thầy!!

Thì nó đúng cho riêng ví dụ ở trên thôi (sẽ sai nếu trong dữ liệu có dạng '1/1_ABCXYZ...)

Chắc cái thứ 2 có Type(...)=2
.

Bạn có thể thí nghiệm bằng cách mở cửa sổ Function Arguments xem có giống cái của tôi không thì biết liền chứ gì (tin là hổng có giống)
---------------------------
Đưa lên ví dụ này không phải cố ý giới thiệu bí mật của hàm AND mà tôi muốn nói rằng hầu hết các hàm đều có bí mật, thậm chí một số bí mật ấy còn khiến chúng ta cảm thấy nó "không chính xác". Vậy thì sao? Ta buộc phải sống chung với nó mà thôi. Biết để "né" trong một vài tình huống cụ thể nào đó chứ không thể "kết tội" là nó "không chính xác" được

 

[quocgiacan]

Bạn có thể thí nghiệm bằng cách mở cửa sổ Function Arguments xem có giống cái của tôi không thì biết liền chứ gì (tin là hổng có giống)

Chắc giống nhau thầy,


Chúc thầy ngày cuối tuần nghỉ vui.

 

[ndu96081631]

Chắc giống nhau thầy,
View attachment 180188

Chúc thầy ngày cuối tuần nghỉ vui.

Tôi biết chắc cái cell A2 đó là bạn "ăn gian" mà có (bạn gõ 'FALSE)
Vẫn còn 1 trường hợp nữa cho A2 và hoàn toàn không "ăn gian" nha!
Ẹc... Ẹc.... Thế đấy! Thấy vậy chứ đâu có dễ

 

[phihndhsp]

Còn 1 trường hợp Countif mà đếm vùng nào đó khác rỗng "<>"&"", mà cái kết quả khác rỗng đó được trả về từ if thì countif cũng không tính được.