Bí ẩn hàm DATEDIF đã có lời giải! (1 người xem)

[PhanTuHuong]

Chúng ta đã biết hàm DATEDIF sử dụng để tính khoảng thời gian giữa 2 mốc thời gian theo ngày, tháng hoặc năm. Tuy nhiên nó bị ẩn, không hiển thị trong danh sách và cũng không được hỗ trợ gợi nhớ như các hàm khác. Đầu tiên tôi cũng nghĩ là sai sót, nhưng đến Excel 2016 vẫn bị vậy. Hóa ra ra nguyên nhân ở đây:

https://support.office.com/en-us/article/DATEDIF-function-25dba1a4-2812-480b-84dd-8b32a451b35c

Nguyên nhân: Hàm DATEDIF được Excel hỗ trợ các workbook cũ hơn từ Lotus 1-2-3. Có thể kết quả tính toán không chính xác ở một số tình huống (khi sử dụng tham số “d” hoặc “m”).
Chúng ta thử tính khoảng thời gian ngày 1/5/2017 đến 31/5/2017. Hàm DATEDIF trả về 0 tháng.

 

[befaint]

Híc! Anh giật cái "tít" ghê thế.

 

[PhanTuHuong]

Híc! Anh giật cái "tít" ghê thế.

Chuẩn mà, hàm này được coi là bí ẩn của Excel, giờ mới có lời giải thích chính thức từ Microsoft. Đây là các link hỏi về sự bí ẩn của hàm này:

https://www.auditexcel.co.za/blog/excels-hidden-function-datedif/

http://www.pcworld.com/article/3131...ret-date-time-function-thats-still-handy.html

http://excelchamps.com/blog/datedif-function-in-excel/

https://www.mrexcel.com/forum/excel-questions/621871-hidden-excel-functions-ie-datedif.html

 

[ndu96081631]

Chúng ta đã biết hàm DATEDIF sử dụng để tính khoảng thời gian giữa 2 mốc thời gian theo ngày, tháng hoặc năm. Tuy nhiên nó bị ẩn, không hiển thị trong danh sách và cũng không được hỗ trợ gợi nhớ như các hàm khác. Đầu tiên tôi cũng nghĩ là sai sót, nhưng đến Excel 2016 vẫn bị vậy. Hóa ra ra nguyên nhân ở đây:

https://support.office.com/en-us/article/DATEDIF-function-25dba1a4-2812-480b-84dd-8b32a451b35c

Nguyên nhân: Hàm DATEDIF được Excel hỗ trợ các workbook cũ hơn từ Lotus 1-2-3. Có thể kết quả tính toán không chính xác ở một số tình huống (khi sử dụng tham số “d” hoặc “m”).
Chúng ta thử tính khoảng thời gian ngày 1/5/2017 đến 31/5/2017. Hàm DATEDIF trả về 0 tháng.

Mới nghe cũng giật mình nên thử, kết quả thế này:




Hổng thấy bị vụ =0 gì cả
Còn chuyện "bí mật" gì đó của DATEDIF thì trên GPE đã đề cập lâu rồi thầy à!

 

[eke_rula]

Mới nghe cũng giật mình nên thử, kết quả thế này:

View attachment 180085


Hổng thấy bị vụ =0 gì cả
Còn chuyện "bí mật" gì đó của DATEDIF thì trên GPE đã đề cập lâu rồi thầy à!

Hình như là 0 tháng anh ạ!!!

 

[ndu96081631]

Hình như là 0 tháng anh ạ!!!

Nguyên tắc tính toán của DATEDIF là phải TRÒN NĂM, TRÒN THÁNG, TRÒN NGÀY (tính luôn cả giờ phút giây luôn đấy)
Vậy dữ liệu như trên ra 0 tháng thì trúng hay trật?

 

[PhanTuHuong]

Mới nghe cũng giật mình nên thử, kết quả thế này:

View attachment 180085


Hổng thấy bị vụ =0 gì cả
Còn chuyện "bí mật" gì đó của DATEDIF thì trên GPE đã đề cập lâu rồi thầy à!

Em chỉ biết hàm này bí ẩn, chưa thấy GPE giải mã mà

 

[ndu96081631]

Em chỉ biết hàm này bí ẩn, chưa thấy GPE giải mã mà

Nó có đề cập đến vụ Lotus ở bài 4 topic này:
http://www.giaiphapexcel.com/diendan/threads/danh-mục-các-hàm-thuộc-bộ-analysis-toolpak.30596/
Bài có từ năm 2009

 

[Kiều Mạnh]

Nó có đề cập đến vụ Lotus ở bài 4 topic này:
http://www.giaiphapexcel.com/diendan/threads/danh-mục-các-hàm-thuộc-bộ-analysis-toolpak.30596/
Bài có từ năm 2009

vậy là 2017- 2009 = ~~ 10 năm ...??!!! vậy đâu keo là bí ẩn nữa

 

[PhanTuHuong]

Nó có đề cập đến vụ Lotus ở bài 4 topic này:
http://www.giaiphapexcel.com/diendan/threads/danh-mục-các-hàm-thuộc-bộ-analysis-toolpak.30596/
Bài có từ năm 2009

Do trong Lotus mà không hỗ trợ mặc dù vẫn dùng được. Ngày trước mò ở bên ngoài, mà bâycó trong Help chính thức của Microsoft 2016 rồi bác.
Mặt khác nó bị cảnh báo về không chính xác ở 1 số tình huống.

 

[ndu96081631]

vậy là 2017- 2009 = ~~ 10 năm ...??!!! vậy đâu keo là bí ẩn nữa

Kiến thức trên GPE mình nhiều lắm, có khi không nhớ hết được một chủ đề nào đó đã có hay chưa đâu. Nhưng tôi tin là gần như chủ đề nào có đều có cả
Có thể nói www.giaiphapexcel.com là trang web hàng đầu về Excel tại Việt Nam

 

[eke_rula]

Nguyên tắc tính toán của DATEDIF là phải TRÒN NĂM, TRÒN THÁNG, TRÒN NGÀY (tính luôn cả giờ phút giây luôn đấy)
Vậy dữ liệu như trên ra 0 tháng thì trúng hay trật?

Đúng anh ạ, em thấy anh gắn công thức sai so với bài #1 thôi ạ!!!!!!

 

[quocgiacan]

Chúng ta đã biết hàm DATEDIF sử dụng để tính khoảng thời gian giữa 2 mốc thời gian theo ngày, tháng hoặc năm. Tuy nhiên nó bị ẩn, không hiển thị trong danh sách và cũng không được hỗ trợ gợi nhớ như các hàm khác. Đầu tiên tôi cũng nghĩ là sai sót, nhưng đến Excel 2016 vẫn bị vậy. Hóa ra ra nguyên nhân ở đây:

https://support.office.com/en-us/article/DATEDIF-function-25dba1a4-2812-480b-84dd-8b32a451b35c

Nguyên nhân: Hàm DATEDIF được Excel hỗ trợ các workbook cũ hơn từ Lotus 1-2-3. Có thể kết quả tính toán không chính xác ở một số tình huống (khi sử dụng tham số “d” hoặc “m”).
Chúng ta thử tính khoảng thời gian ngày 1/5/2017 đến 31/5/2017. Hàm DATEDIF trả về 0 tháng.

Thấy vui vui cũng muốn góp lời cùng anh Hướng.

Đúng như anh nói: Hàm DATEDIF() có một số trường hợp không chính xác. Ví dụ:

• A1=01/05/2017; A2=31/05/2017; thì =DATEDIF(A1,A2,"m") = 0
• nhưng nếu A1=01/05/2017; A2=01/06/2017; =DATEDIF(A1,A2,"m") = 1
  
• Để ý thấy rằng nếu lấy cùng ngày đầu tháng mà dùng hàm DATEDIF(,..) với đối số "m" hoặc "d" thậm chí "md" sẽ chính xác hơn lấy cùng ngày cuối tháng. Ví dụ:
  • A1=30/04/2017 và A2=31/05/2017, thì dùng "d"= 31 ngày, dùng "m"=1 tháng, dùng "md"=1 ngày!!?
  • Hay, A1=31/05/2017 và A2=30/06/2017, thì dùng "d"= 30 ngày, dùng "m"=0 tháng, dùng "md"=30 ngày!?
  • Nhưng nếu đầu tháng thì khác, Vd: A1=01/04/2017 và A2=01/05/2017, thì dùng "d"= 30 ngày, dùng "m"=1 tháng, dùng "md"=0 ngày; Hay, A1=01/05/2017 và A2=01/06/2017, thì dùng "d"= 31 ngày, dùng "m"=1 tháng, dùng "md"=0 ngày.

Do vô tình trong lúc giải bài cho các bạn tính phép năm mới bị điều này "hành hạ", cứ hễ tính như anh nói thì tính phép năm bị sai ngay:
(tham khảo: http://www.giaiphapexcel.com/diendan/threads/cùng-một-công-thức-nhưng-cho-ra-2-kết-quả-khác-nhau.127903/#post-800997)

Cho nên khi đụng đến DATEDIF() dùng đối số "m" thường mình đưa về so (nếu có thể) hai ngày đầu tháng với nhau.

Chúc anh em ngày thiệt vui.

 

[dazkangel]

Đúng anh ạ, em thấy anh gắn công thức sai so với bài #1 thôi ạ!!!!!!

0 tháng thì có gì sai nhỉ ??

 

[PhanTuHuong]

Nó có đề cập đến vụ Lotus ở bài 4 topic này:
http://www.giaiphapexcel.com/diendan/threads/danh-mục-các-hàm-thuộc-bộ-analysis-toolpak.30596/
Bài có từ năm 2009

Đúng là em đã từng trao đổi, lâu không để ý
Chỉ biết là ngày trước khai thác từ nguồn không chính thức, giờ thì Microsoft có đề cập một cách chính thống, nhưng thực tế hàm vẫn bị ẩn trong Excel.

 

[eke_rula]

0 tháng thì có gì sai nhỉ ??

Ý em nói là bài #1 tác giả đưa vậy mà!!!

 

[PhanTuHuong]

Thấy vui vui cũng muốn góp lời cùng anh Hướng.

Đúng như anh nói: Hàm DATEDIF() có một số trường hợp không chính xác. Ví dụ:

• A1=01/05/2017; A2=31/05/2017; thì =DATEDIF(A1,A2,"m") = 0
• nhưng nếu A1=01/05/2017; A2=01/06/2017; =DATEDIF(A1,A2,"m") = 1
  
• Để ý thấy rằng nếu lấy cùng ngày đầu tháng mà dùng hàm DATEDIF(,..) với đối số "m" hoặc "d" thậm chí "md" sẽ chính xác hơn lấy cùng ngày cuối tháng. Ví dụ:
  • A1=30/04/2017 và A2=31/05/2017, thì dùng "d"= 31 ngày, dùng "m"=1 tháng, dùng "md"=1 ngày!!?
  • Hay, A1=31/05/2017 và A2=30/06/2017, thì dùng "d"= 30 ngày, dùng "m"=0 tháng, dùng "md"=30 ngày!?
  • Nhưng nếu đầu tháng thì khác, Vd: A1=01/04/2017 và A2=01/05/2017, thì dùng "d"= 30 ngày, dùng "m"=1 tháng, dùng "md"=0 ngày; Hay, A1=01/05/2017 và A2=01/06/2017, thì dùng "d"= 31 ngày, dùng "m"=1 tháng, dùng "md"=0 ngày.

Do vô tình trong lúc giải bài cho các bạn tính phép năm mới bị điều này "hành hạ", cứ hễ tính như anh nói thì tính phép năm bị sai ngay:
(tham khảo: http://www.giaiphapexcel.com/diendan/threads/cùng-một-công-thức-nhưng-cho-ra-2-kết-quả-khác-nhau.127903/#post-800997)

Cho nên khi đụng đến DATEDIF() dùng đối số "m" thường mình đưa về so (nếu có thể) hai ngày đầu tháng với nhau.

Chúc anh em ngày thiệt vui.

Mấy tình huống của bác chuẩn và hay thật. Mai em trao đổi thêm sau.

 

[dazkangel]

Ý em nói là bài #1 tác giả đưa vậy mà!!!

ừm a xem qua rồi, công nhận hàm này cũng khá khó hiểu

 

[ndu96081631]

Thấy vui vui cũng muốn góp lời cùng anh Hướng.

Đúng như anh nói: Hàm DATEDIF() có một số trường hợp không chính xác. Ví dụ:

• A1=01/05/2017; A2=31/05/2017; thì =DATEDIF(A1,A2,"m") = 0
• nhưng nếu A1=01/05/2017; A2=01/06/2017; =DATEDIF(A1,A2,"m") = 1

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

 

[eke_rula]

Em thấy trên mạng chỉ có nói datedif không chính xác ở một số trường hợp trong phiên bản excel 2007 là do lỗi của phiên bản đó, còn các vấn đề khác thì không thấy đề cập đến!!!

 

[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.

 

[befaint]

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.

Ủa, em tưởng chỉ cần "<>" thôi chứ

 

[ndu96081631]

Ủa, em tưởng chỉ cần "<>" thôi chứ

Chưa chắc đâu! Bài 40 có nói rõ:

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.

Thử COUNTIF(A1:A10, "<>") mà trong vùng A1:A10 có 1 cell ta đặt công thức ="" thì nó xem như cell nào có dữ liệu và đếm luôn

 

[befaint]

Chưa chắc đâu! Bài 40 có nói rõ:

Em đọc kỹ và kiểm tra kỹ trước khi trả lời. Chắc chưa tới.

Chúc anh ngày vui!

 

[HieuCD]

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.

Liên quan đến từ "rỗng" khá rắc rối
1 ô không có gì là ô rỗng, nhưng nếu nhập công thức các dạng như ="", if(...,"")... mặc dù nhìn không thấy gì nhưng vẫn có giá trị dạng Text "rỗng"
Vấn đề sẽ rỏ ràng hơn khi so sánh 2 công thức
=COUNTIF($A$1:$A$20,"")
Sẽ đếm tất cả các ô rỗng và những ô có giá trị Text "rỗng"
=COUNTIF($A$1:$A$20,"="&"")
Sẽ đếm tất cả các ô rổng và không tính những ô có giá trị Text "rỗng"
Như vậy 2 dấu nháy kép đứng riêng 1 mình ( "" ) trong công thức xét điều kiện, Excel hiểu là ô rỗng và cả giá trị Text "rỗng"
Nếu "" ghép với điều kiện như: "="&"", "<>"&"" thì Excel hiểu là ô rỗng
=COUNTIF($A$1:$A$20,"<>"&"") sẽ tính các ô có giá trị kể cả giá trị Text "rỗng" và kết quả giống như hàm Counta($A$1:$A$20)
File test thử

 

[suga229]

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

 

[mthangk99]

Không cần nói đến những hàm này, chỉ cần những phép tính cộng bình thường thôi mà trước đây mình đã gặp trường hợp cộng số đấy bị sai hoàn toàn (Chỉ là phép cộng 5 - 7 chữ số). Mình phải dùng máy tính tay bấm lại rồi dùng giấy bút tính lại mới biết được điều này. Giờ mình không nhớ cụ thể nó sai trên Excel 2003 hay sai ở Calculator của máy tính nữa.

 

[PhanTuHuong]

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

Bạn copy nguyên bài của tôi là có ý gì???

 

[PhanTuHuong]

Không cần nói đến những hàm này, chỉ cần những phép tính cộng bình thường thôi mà trước đây mình đã gặp trường hợp cộng số đấy bị sai hoàn toàn (Chỉ là phép cộng 5 - 7 chữ số). Mình phải dùng máy tính tay bấm lại rồi dùng giấy bút tính lại mới biết được điều này. Giờ mình không nhớ cụ thể nó sai trên Excel 2003 hay sai ở Calculator của máy tính nữa.

Những phép tính bình thường thì do mình chứ Excel không sai