特征工程机器学习数据分析【免费下载链接】tsfreshAutomatic extraction of relevant features from time series:项目地址https://gitcode.com/gh_mirrors/ts/tsfresh点击查看免费下载tsfresh 是一个用于从时间序列中自动提取相关特征的开源 Python 库项目核心实现位于 tsfresh/feature_extraction 与 tsfresh/feature_selection 等模块。本文以官方贡献文档 docs/text/how_to_contribute.rst 为骨架结合仓库内真实的配置文件与测试代码系统梳理贡献者的完整工作流开发环境的安装、单元测试与多版本兼容测试、文档构建、代码风格规范以及 PR 提交要求。读完本文你将掌握从克隆仓库到提交可合并 PR 的全套实操步骤。贡献方式任何形式的帮助都欢迎tsfresh 的社区愿景是让该项目成为 Python 生态中最大的特征提取方法库因此所有形式的贡献都受欢迎bug 报告、bug 修复、文档改进、功能增强与 idea 建议。无论你想新增一两个有趣的特征计算器feature calculators如 feature_calculators.py 中已内置的数百个计算函数还是实现一种新的特征选择流程或者只是修正 1-2 个拼写错误都会得到认可。最直接的贡献方式是向项目提交 Pull RequestPR。如果你不熟悉 Git 的工作流也可以通过邮件联系项目维护者参见 docs/authors.rst。三条编码范式与两条版权底线编码范式简单、文档化、可测试贡献者需要遵循三条核心编码范式Keep it simple保持简单项目信奉程序首先是给人读的其次才是给机器执行的。代码应追求简洁可读而非炫技。Keep it documented保持文档化每个方法和类至少要有 docstring。docstring 的重点不是描述做了什么而是解释为什么这样做——让后来者理解设计意图。Keep it tested保持可测试项目追求高测试覆盖率。新增代码应同步补充对应测试仓库中 tests/units 与 tests/integrations 即按模块组织的大量测试用例即是佐证。版权底线保护整个项目的许可证项目特别强调两条与版权相关的硬性约束不要引入许可证不可用或禁止商业使用的数据集——这类数据可能侵蚀整个项目的许可证本项目采用 MIT 许可证见 LICENSE.txt。不要使用许可证不可用或禁止商业使用的代码片段例如来自 StackOverflow 的某些回答——同理这会危及整个项目的法律合规性。技术决策清理 Notebook 输出另一条技术性约定是提交 iPython Notebook 前务必清除输出。这能显著提升 Git diff 的可读性避免无关的 base64 输出噪音污染变更记录仓库中的示例笔记本位于 notebooks 目录。开发环境搭建三步安装可编辑安装与 pre-commit 钩子在仓库根目录执行以下三条命令即可完成开发环境安装cd /path/to/tsfresh pip install -e .[testing] pre-commit installpip install -e .[testing]以可编辑editable模式安装 tsfresh并带上测试所需的全部依赖。testing这一 extras 的完整依赖清单定义在 setup.cfg 的[options.extras_require]段包括pytest4.4.0、pytest-cov2.6.1、pytest-xdist1.26.1、pytest-benchmark3.0.0、mock2.0.0、matplotlib、seaborn、notebook以及pre-commit等同时它通过%(dask)s引用了dask[dataframe]2.9.0与distributed2.11.0等 dask 相关依赖。可编辑安装意味着对代码的改动会直接反映到测试运行中无需重复安装。pre-commit install会在本地 Git 仓库中注册 pre-commit 钩子此后每次 commit 都会自动触发格式检查详见下文代码风格一节。补充说明从 pyproject.toml 可以看到本项目基于 PyScaffold 3.x 构建setuptools70的版本上界正是为了规避 PyScaffold 3 与较新 setuptools 的兼容性问题因此setup.py本身极简仅调用setup(use_pyscaffoldTrue)并将所有配置委托给 setup.cfg。测试框架从单机 pytest 到多版本矩阵运行单元测试套件完成改动后在仓库根目录执行pytest即可运行完整的单元测试套件。仓库的 pytest 配置同样集中在 setup.cfg 的[tool:pytest]段testpaths tests指定测试目录为 testsaddopts默认开启--cov tsfresh --cov-report term-missing覆盖率统计与--verbosefilterwarnings可统一配置警告过滤规则。测试按功能模块组织特征提取相关测试在 tests/units/feature_extraction如test_feature_calculations.py、test_extraction.py、test_settings.py特征选择相关测试在 tests/units/feature_selection另有 tests/integrations 承载端到端的集成测试如test_full_pipeline.py、test_relevant_feature_extraction.py。跨 Python 版本测试tox项目要求代码在多个 Python 版本下保持兼容使用 tox 批量执行tox -r -p auto-r表示强制重建虚拟环境-p auto表示并行运行多个环境的测试。测试的 Python 版本由 setup.cfg 的[tox:tox]段中的envlist决定当前为py39, py310, py311, py312对应 Python 3.9–3.12。skip_missing_interpreters True意味着本地缺少某个 Python 版本时不会报错而是跳过该环境。每个[testenv]会依次执行打印 Python 版本python -V、安装测试依赖python -m pip install .[testing]、运行测试python -m pytest tests/。具体的 Python 微版本如 3.11.7 还是 3.11.8取决于本地安装的解释器envlist只锁定大版本。管理多版本 Pythonpyenv官方推荐的本地多版本 Python 管理工具是pyenv它可以有序地安装并在不同 Python 版本间切换配合tox的envlist即可在本地复现项目声明的全部受支持版本。仓库的 Dockerfile.testing 正是基于这一思路构建的它以 Ubuntu 22.04 为基础镜像通过pyenv编译安装 Makefile 中指定的 Python 版本默认PYTHON_VERSIONS : 3.9 3.10 3.11 3.12再在容器内运行tox -r -p auto。其中对 Python 3.7.x 使用clang编译的细节是该镜像处理 pyenv 编译问题的既有方案。Docker 化测试环境除了本地运行还可以在 Docker 容器中执行测试make test-all-testenv这条命令依次触发 Makefile 中的三个目标build-docker-testenv基于Dockerfile.testing构建名为tsfresh-test-image的镜像并通过--build-arg PYTHON_VERSIONS注入要编译的 Python 版本run-docker-tests以只读方式挂载当前仓库-v .:/tsfresh并将 build、.tox、egg-info 等构建产物用命名卷隔离build_artifacts、tox_artifacts、egg_artifacts保证宿主目录不被污染clean清理.tox、build/、dist/与*.egg-info。首次运行会因编译多个 Python 版本而耗时较长但后续调用会显著加快镜像层与 tox 缓存均被复用。这种方式保证了无论本地环境如何都能在干净、一致的测试环境中验证代码。顺带一提Makefile 还提供了一个调试利器make bisect GOOD_COMMITcommit_hash。它利用git bisect自动二分定位坏提交——假设当前检出的提交已知有问题执行该命令后 git 会在pytest作为判定命令的情况下自动二分出首个引入问题的提交。构建文档tsfresh 的文档由 Sphinx 生成源码位于 docs 目录如 docs/text/feature_calculation.rst、docs/api 等。在完成上文的基础安装后执行pip install -e .[docs] cd docs make htmldocsextras 在 setup.cfg 中定义为Sphinx6.1.3、sphinx_rtd_theme1.2.0、b2luigi、docutils0.18.1。make html实际调用 docs/Makefile 中的sphinx-build默认将源码目录设为docs、构建目录设为docs/_build。构建完成后成品文档位于docs/_build/html目录可直接用浏览器打开index.html预览。文档改动应与代码改动一样遵循清晰、可读的原则。代码风格black isort pre-commit项目统一使用black与isort进行代码格式化。安装 pre-commit 后这两个工具会在每次 commit 时自动触发无需手动运行。仓库根目录的 .pre-commit-config.yaml 展示了完整的钩子配置blackrev 22.12.0代码格式化器exclude: ^docs/.*$表明文档目录不参与格式化isortrev 5.12.0import 排序器并显式指定--profile black使 isort 的排序风格与 black 兼容pre-commit-hooksrev v4.4.0一组通用检查包括trailing-whitespace去除行尾空白、end-of-file-fixer保证文件以换行结尾、check-yaml校验 YAML 语法、check-added-large-files阻止误提交大文件。这套钩子机制将风格检查前置到提交阶段确保进入仓库的每一行代码都符合统一风格也从机制上减轻了 PR 评审的负担。PR 描述规范提交 Pull Request 时需要做到清晰且描述性的标题让维护者一眼看出改动意图详细的变更说明包括改了什么、解决了什么问题为评审者提供提示说明评审时应重点关注哪些地方以及相关的背景信息。好的 PR 描述能显著降低评审成本这也是开源协作中文档化思维的延伸——正如编码范式所强调的不仅代码要解释为什么变更本身也要向协作方解释为什么。小结为 tsfresh 做贡献的完整闭环可以概括为可编辑安装pip install -e .[testing]→ pre-commit 风格钩子 →pytest本地单测 →tox -r -p auto多版本矩阵可选make test-all-testenv的 Docker 化方案→ Sphinx 文档构建 → 提交规范化的 PR。这三条编码范式、两条版权底线与一条技术约定加上仓库中 setup.cfg、.pre-commit-config.yaml、Makefile、Dockerfile.testing 等配置文件的落地构成了一个可复制、可验证、可审计的贡献流程。无论你的贡献是一个特征计算器、一个选择算法还是一个错别字修复这套流程都能保证改动质量与项目的长期可持续性。赞分享特征工程机器学习数据分析【免费下载链接】tsfreshAutomatic extraction of relevant features from time series:项目地址https://gitcode.com/gh_mirrors/ts/tsfresh点击查看免费下载相关推荐BorgBackup 贡献指南从开发环境搭建、代码风格到测试与合入的完整实践BorgBackup 贡献指南从开发环境搭建、代码风格到测试与合入的完整实践 本篇指南围绕开源备份工具 BorgBackupborg仓库的 CONTRIB运维存储TileLang 贡献者开发指南从环境搭建、代码规范到本地测试的完整流程TileLang 贡献者开发指南从环境搭建、代码规范到本地测试的完整流程 TileLang 是一个基于 TVM 之上、用 Pythonic 语法编写高性能 G编译器编程语言高性能计算人工智能深度学习Nexent开发者指南从环境搭建到代码贡献的完整流程Nexent开发者指南从环境搭建到代码贡献的完整流程 Nexent是一个开源智能体SDK和平台能够将单个提示转换为完整的多模态服务无需复杂的图表和连线操作AI AgentAI 应用后端前端大模型RAG上一篇Buzz 完全指南如何用本地 Whisper 实现离线音频转录下一篇告别重复求职JobFunnel一站式职位聚合神器全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 tsfresh 贡献指南：从环境搭建、代码风格到多版本测试的完整开发流程
特征工程机器学习数据分析【免费下载链接】tsfreshAutomatic extraction of relevant features from time series:项目地址https://gitcode.com/gh_mirrors/ts/tsfresh点击查看免费下载tsfresh 是一个用于从时间序列中自动提取相关特征的开源 Python 库项目核心实现位于 tsfresh/feature_extraction 与 tsfresh/feature_selection 等模块。本文以官方贡献文档 docs/text/how_to_contribute.rst 为骨架结合仓库内真实的配置文件与测试代码系统梳理贡献者的完整工作流开发环境的安装、单元测试与多版本兼容测试、文档构建、代码风格规范以及 PR 提交要求。读完本文你将掌握从克隆仓库到提交可合并 PR 的全套实操步骤。贡献方式任何形式的帮助都欢迎tsfresh 的社区愿景是让该项目成为 Python 生态中最大的特征提取方法库因此所有形式的贡献都受欢迎bug 报告、bug 修复、文档改进、功能增强与 idea 建议。无论你想新增一两个有趣的特征计算器feature calculators如 feature_calculators.py 中已内置的数百个计算函数还是实现一种新的特征选择流程或者只是修正 1-2 个拼写错误都会得到认可。最直接的贡献方式是向项目提交 Pull RequestPR。如果你不熟悉 Git 的工作流也可以通过邮件联系项目维护者参见 docs/authors.rst。三条编码范式与两条版权底线编码范式简单、文档化、可测试贡献者需要遵循三条核心编码范式Keep it simple保持简单项目信奉程序首先是给人读的其次才是给机器执行的。代码应追求简洁可读而非炫技。Keep it documented保持文档化每个方法和类至少要有 docstring。docstring 的重点不是描述做了什么而是解释为什么这样做——让后来者理解设计意图。Keep it tested保持可测试项目追求高测试覆盖率。新增代码应同步补充对应测试仓库中 tests/units 与 tests/integrations 即按模块组织的大量测试用例即是佐证。版权底线保护整个项目的许可证项目特别强调两条与版权相关的硬性约束不要引入许可证不可用或禁止商业使用的数据集——这类数据可能侵蚀整个项目的许可证本项目采用 MIT 许可证见 LICENSE.txt。不要使用许可证不可用或禁止商业使用的代码片段例如来自 StackOverflow 的某些回答——同理这会危及整个项目的法律合规性。技术决策清理 Notebook 输出另一条技术性约定是提交 iPython Notebook 前务必清除输出。这能显著提升 Git diff 的可读性避免无关的 base64 输出噪音污染变更记录仓库中的示例笔记本位于 notebooks 目录。开发环境搭建三步安装可编辑安装与 pre-commit 钩子在仓库根目录执行以下三条命令即可完成开发环境安装cd /path/to/tsfresh pip install -e .[testing] pre-commit installpip install -e .[testing]以可编辑editable模式安装 tsfresh并带上测试所需的全部依赖。testing这一 extras 的完整依赖清单定义在 setup.cfg 的[options.extras_require]段包括pytest4.4.0、pytest-cov2.6.1、pytest-xdist1.26.1、pytest-benchmark3.0.0、mock2.0.0、matplotlib、seaborn、notebook以及pre-commit等同时它通过%(dask)s引用了dask[dataframe]2.9.0与distributed2.11.0等 dask 相关依赖。可编辑安装意味着对代码的改动会直接反映到测试运行中无需重复安装。pre-commit install会在本地 Git 仓库中注册 pre-commit 钩子此后每次 commit 都会自动触发格式检查详见下文代码风格一节。补充说明从 pyproject.toml 可以看到本项目基于 PyScaffold 3.x 构建setuptools70的版本上界正是为了规避 PyScaffold 3 与较新 setuptools 的兼容性问题因此setup.py本身极简仅调用setup(use_pyscaffoldTrue)并将所有配置委托给 setup.cfg。测试框架从单机 pytest 到多版本矩阵运行单元测试套件完成改动后在仓库根目录执行pytest即可运行完整的单元测试套件。仓库的 pytest 配置同样集中在 setup.cfg 的[tool:pytest]段testpaths tests指定测试目录为 testsaddopts默认开启--cov tsfresh --cov-report term-missing覆盖率统计与--verbosefilterwarnings可统一配置警告过滤规则。测试按功能模块组织特征提取相关测试在 tests/units/feature_extraction如test_feature_calculations.py、test_extraction.py、test_settings.py特征选择相关测试在 tests/units/feature_selection另有 tests/integrations 承载端到端的集成测试如test_full_pipeline.py、test_relevant_feature_extraction.py。跨 Python 版本测试tox项目要求代码在多个 Python 版本下保持兼容使用 tox 批量执行tox -r -p auto-r表示强制重建虚拟环境-p auto表示并行运行多个环境的测试。测试的 Python 版本由 setup.cfg 的[tox:tox]段中的envlist决定当前为py39, py310, py311, py312对应 Python 3.9–3.12。skip_missing_interpreters True意味着本地缺少某个 Python 版本时不会报错而是跳过该环境。每个[testenv]会依次执行打印 Python 版本python -V、安装测试依赖python -m pip install .[testing]、运行测试python -m pytest tests/。具体的 Python 微版本如 3.11.7 还是 3.11.8取决于本地安装的解释器envlist只锁定大版本。管理多版本 Pythonpyenv官方推荐的本地多版本 Python 管理工具是pyenv它可以有序地安装并在不同 Python 版本间切换配合tox的envlist即可在本地复现项目声明的全部受支持版本。仓库的 Dockerfile.testing 正是基于这一思路构建的它以 Ubuntu 22.04 为基础镜像通过pyenv编译安装 Makefile 中指定的 Python 版本默认PYTHON_VERSIONS : 3.9 3.10 3.11 3.12再在容器内运行tox -r -p auto。其中对 Python 3.7.x 使用clang编译的细节是该镜像处理 pyenv 编译问题的既有方案。Docker 化测试环境除了本地运行还可以在 Docker 容器中执行测试make test-all-testenv这条命令依次触发 Makefile 中的三个目标build-docker-testenv基于Dockerfile.testing构建名为tsfresh-test-image的镜像并通过--build-arg PYTHON_VERSIONS注入要编译的 Python 版本run-docker-tests以只读方式挂载当前仓库-v .:/tsfresh并将 build、.tox、egg-info 等构建产物用命名卷隔离build_artifacts、tox_artifacts、egg_artifacts保证宿主目录不被污染clean清理.tox、build/、dist/与*.egg-info。首次运行会因编译多个 Python 版本而耗时较长但后续调用会显著加快镜像层与 tox 缓存均被复用。这种方式保证了无论本地环境如何都能在干净、一致的测试环境中验证代码。顺带一提Makefile 还提供了一个调试利器make bisect GOOD_COMMITcommit_hash。它利用git bisect自动二分定位坏提交——假设当前检出的提交已知有问题执行该命令后 git 会在pytest作为判定命令的情况下自动二分出首个引入问题的提交。构建文档tsfresh 的文档由 Sphinx 生成源码位于 docs 目录如 docs/text/feature_calculation.rst、docs/api 等。在完成上文的基础安装后执行pip install -e .[docs] cd docs make htmldocsextras 在 setup.cfg 中定义为Sphinx6.1.3、sphinx_rtd_theme1.2.0、b2luigi、docutils0.18.1。make html实际调用 docs/Makefile 中的sphinx-build默认将源码目录设为docs、构建目录设为docs/_build。构建完成后成品文档位于docs/_build/html目录可直接用浏览器打开index.html预览。文档改动应与代码改动一样遵循清晰、可读的原则。代码风格black isort pre-commit项目统一使用black与isort进行代码格式化。安装 pre-commit 后这两个工具会在每次 commit 时自动触发无需手动运行。仓库根目录的 .pre-commit-config.yaml 展示了完整的钩子配置blackrev 22.12.0代码格式化器exclude: ^docs/.*$表明文档目录不参与格式化isortrev 5.12.0import 排序器并显式指定--profile black使 isort 的排序风格与 black 兼容pre-commit-hooksrev v4.4.0一组通用检查包括trailing-whitespace去除行尾空白、end-of-file-fixer保证文件以换行结尾、check-yaml校验 YAML 语法、check-added-large-files阻止误提交大文件。这套钩子机制将风格检查前置到提交阶段确保进入仓库的每一行代码都符合统一风格也从机制上减轻了 PR 评审的负担。PR 描述规范提交 Pull Request 时需要做到清晰且描述性的标题让维护者一眼看出改动意图详细的变更说明包括改了什么、解决了什么问题为评审者提供提示说明评审时应重点关注哪些地方以及相关的背景信息。好的 PR 描述能显著降低评审成本这也是开源协作中文档化思维的延伸——正如编码范式所强调的不仅代码要解释为什么变更本身也要向协作方解释为什么。小结为 tsfresh 做贡献的完整闭环可以概括为可编辑安装pip install -e .[testing]→ pre-commit 风格钩子 →pytest本地单测 →tox -r -p auto多版本矩阵可选make test-all-testenv的 Docker 化方案→ Sphinx 文档构建 → 提交规范化的 PR。这三条编码范式、两条版权底线与一条技术约定加上仓库中 setup.cfg、.pre-commit-config.yaml、Makefile、Dockerfile.testing 等配置文件的落地构成了一个可复制、可验证、可审计的贡献流程。无论你的贡献是一个特征计算器、一个选择算法还是一个错别字修复这套流程都能保证改动质量与项目的长期可持续性。赞分享特征工程机器学习数据分析【免费下载链接】tsfreshAutomatic extraction of relevant features from time series:项目地址https://gitcode.com/gh_mirrors/ts/tsfresh点击查看免费下载相关推荐BorgBackup 贡献指南从开发环境搭建、代码风格到测试与合入的完整实践BorgBackup 贡献指南从开发环境搭建、代码风格到测试与合入的完整实践 本篇指南围绕开源备份工具 BorgBackupborg仓库的 CONTRIB运维存储TileLang 贡献者开发指南从环境搭建、代码规范到本地测试的完整流程TileLang 贡献者开发指南从环境搭建、代码规范到本地测试的完整流程 TileLang 是一个基于 TVM 之上、用 Pythonic 语法编写高性能 G编译器编程语言高性能计算人工智能深度学习Nexent开发者指南从环境搭建到代码贡献的完整流程Nexent开发者指南从环境搭建到代码贡献的完整流程 Nexent是一个开源智能体SDK和平台能够将单个提示转换为完整的多模态服务无需复杂的图表和连线操作AI AgentAI 应用后端前端大模型RAG上一篇Buzz 完全指南如何用本地 Whisper 实现离线音频转录下一篇告别重复求职JobFunnel一站式职位聚合神器全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考