rapidsai / cudf

cuDF - GPU DataFrame Library
https://docs.rapids.ai/api/cudf/stable/
Apache License 2.0
8.45k stars 908 forks source link

[DOC] Group libcudf column APIs into doxygen modules page #5046

Closed davidwendt closed 4 years ago

davidwendt commented 4 years ago

Proposal to organize libcudf column APIs documentation into doxygen groups that can be displayed on the generated Modules page. Using the @*group tags in the comments can generate an organized page of common functions. Proposal is to use the current include/cudf external API headers to organize into groups.

header group
binaryop.h BinaryOps
concatenate.hpp Concatenate
copying.hpp Copying
dlpack.hpp DLPack
filling.hpp Filling
groupby.hpp GroupBy
hashing.hpp Hashing
join.hpp Join
merge.hpp Merge
partitioning.hpp Partition
quantiles.hpp Quantiles
reduction.hpp Reduction
replace.hpp Replace
reshape.hpp Reshape
rolling.hpp Rolling Window
search.hpp Search
sorting.hpp Sorting
stream_compaction.hpp Stream Compaction
transform.hpp Transform
transpose.hpp Transpose
unary.hpp UnaryOps

These can be subgroups of a Columns API as well. This should make it easier to locate documentation without scrolling through the entire cudf namespace page.

davidwendt commented 4 years ago

Here is a picture of the modules page with the proposed groupings.

modules_page

Clicking on a group will show just the functions for that group.

harrism commented 4 years ago

I think we can get even more consistency in the naming... we just need to decide if we like the gerund ("ing") names used in many libcudf headers. I like it -- it is consistent with Thrust documentation, and to some extent STL documentation. e.g. partitioning. Wonder if we should use "grouping" instead of "GroupBy".

Also, are two-word group names allowed? If so, then "Unary Operations", and "Binary Operations", not "UnaryOps".