Changes to ecg processing functions and team code in order to insert the ecg features extraction

.dockerignore

@@ -0,0 +1,23 @@
+# Datasets
+data/
+**/training_set/
+**/supplementary_set/
+**/*.edf
+
+# Artifacts
+model/
+model_smoke/
+model_full_smoke/
+outputs/
+outputs_smoke/
+__pycache__/
+*.pyc
+*.pkl
+*.sav
+*.joblib
+
+# OS / IDE
+.DS_Store
+Thumbs.db
+.vscode/
+.idea/

.gitignore

@@ -0,0 +1,238 @@
+# Dataset
+data/
+
+# Model artifacts
+model/
+model_smoke/
+*.pkl
+*.sav
+*.joblib
+
+# Outputs
+outputs/
+outputs_smoke/
+
+# Python
+__pycache__/
+*.pyc
+
+# OS
+.DS_Store
+Thumbs.db
+
+# IDE
+.vscode/
+.idea/
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+graphs/
+
+graphs
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#  you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Cursor
+#  Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
+#  exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
+#  refer to https://docs.cursor.com/context/ignore-files
+.cursorignore
+.cursorindexingignore
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+results_summaryEEG_I0002.csv
+results_summaryEEG_I0004.csv
+results_summaryEEG_I0006.csv
+results_summaryEEG_I0007.csv

AUTHORS.txt

@@ -0,0 +1,4 @@
+Sofia Romagnoli - Universidad de Zaragoza
+Diego Cajal - CIBER-BBN
+Josseline Madrid - Universidad de Zaragoza
+Rodrigo Lozano - Universidad de Zaragoza

docs/01_overview.md

@@ -0,0 +1,35 @@
+# CINC 2026 – Visión General del Proyecto
+
+Estamos participando en el Challenge 2026 de Computing in Cardiology.
+
+El objetivo es predecir deterioro cognitivo a partir de datos de polisomnografía (PSG).
+
+## Cómo nos evaluarán
+
+La organización:
+
+1. Construirá nuestra imagen Docker.
+2. Ejecutará `train_model.py`.
+3. Ejecutará `run_model.py`.
+4. Evaluará las predicciones generadas.
+
+Por tanto, la reproducibilidad mediante Docker es obligatoria.
+
+Nuestro objetivo es garantizar que:
+- El código se ejecuta sin intervención manual.
+- El modelo se entrena correctamente.
+- Las predicciones se generan en el formato requerido.
+
+## Qué se puede modificar y qué no
+
+❌ No modificar
+
+- `train_model.py`
+- `run_model.py`
+- `helper_code.py`
+- `evaluate_model.py`
+
+✅ Modificar/Añadir
+
+- `team_code.py` <-- Toda la lógica científica y de modelado debe implementarse ahí.
+- Helpers, scripts, métodos: añadir a voluntad en `src/`

docs/02_docker.md

@@ -0,0 +1,46 @@
+# Uso de Docker
+
+Este documento define el contexto de ejecución con Docker.
+
+## Requisitos
+
+- Docker Desktop instalado (modo Linux containers)
+- Dataset descargado desde Kaggle
+- Dataset completo disponible en `data/training_set/` (ruta por defecto del proyecto)
+
+Si tu dataset está en otra ubicación, actualiza la variable de ruta en el script de ejecución.
+
+## Estructura de trabajo
+
+Entradas:
+
+- `data/training_set/` (dataset completo)
+- `data/training_smoke/` (dataset reducido para modo desarrollo (smoke))
+
+Salidas:
+
+- `model/` y `outputs/` (flujo completo)
+- `model_smoke/` y `outputs_smoke/` (flujo smoke/desarrollo)
+
+## Orden recomendado de ejecución
+
+1. Construir imagen Docker (`build`)
+2. Preparar dataset smoke (`smoke`)
+3. Iterar en modo desarrollo (smoke) (`train-dev` / `run-dev`)
+4. Ejecutar validación completa (`train` / `run`)
+5. Limpiar artefactos cuando corresponda (`clean`)
+
+La guía paso a paso está en `docs/04_run_script.md`.
+
+## Compatibilidad de scripts
+
+El flujo principal del equipo está documentado con `run.sh` (Git Bash).
+También existen equivalentes en PowerShell: `run.ps1` y `scripts/create_smoke.ps1`.
+
+## Resultado esperado
+
+Tras ejecutar la generación de predicciones (inferencia) completa, en `outputs/` se genera un `demographics.csv` con:
+
+- Columnas originales
+- `Cognitive_Impairment`
+- `Cognitive_Impairment_Probability`

docs/03_smoke_dataset.md

@@ -0,0 +1,41 @@
+# Dataset smoke (Modo desarrollo)
+
+Entrenar con el dataset completo tarda aproximadamente 30–40 minutos con el modelo de ejemplo.
+
+Para desarrollo utilizamos un dataset reducido (5 sujetos por defecto).
+
+Este documento describe cuándo y por qué usar smoke.
+Los comandos de ejecución están centralizados en `docs/04_run_script.md`.
+
+---
+
+## Qué incluye
+
+- Muestra reducida del dataset (5 sujetos por defecto)
+- Estructura compatible con el flujo oficial del proyecto
+- Directorio de salida en `data/training_smoke/`
+- `demographics.csv` filtrado para que solo incluya los registros copiados al smoke
+
+## Para qué se usa
+
+- Validar cambios de código rápidamente
+- Detectar errores de integración antes del entrenamiento completo
+- Iterar en modo desarrollo (smoke) sin esperar ciclos largos
+
+## Artefactos asociados
+
+- Entrenamiento smoke: `model_smoke/`
+- Predicciones (inferencia) smoke: `outputs_smoke/`
+
+## Relación con el flujo principal
+
+El dataset smoke se crea al inicio del ciclo de desarrollo y se usa junto con `train-dev` y `run-dev`.
+El orden detallado de ejecución está en `docs/04_run_script.md`.
+
+## ¿Cuándo usar smoke?
+
+- Desarrollo de nuevas funcionalidades
+- Comprobación rápida de que el código no rompe
+- Validación de cambios en `team_code.py`
+
+Nunca usar smoke para evaluar rendimiento final.