Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Revisit format/transform interface and implementation (datasets 4 lazy Columns)

Aperta
  • Qualcosa non va?
#48 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
julia, numpy, python
Ambito
data

Direzione di ricerca

Inizia da src/dataset.jl e dalla sezione della guida “The "julia" format and transforms” per comprendere il comportamento attuale con un singolo slot. Esegui l’harness di perf/ sia su dataset numerici sia su dataset di immagini, confrontando il formato attuale con un’alternativa basata su numpy. Il lavoro è completato quando i risultati dei benchmark sono stati registrati e utilizzati per decidere se sia giustificata un’ottimizzazione interna o un secondo asse del formato attivabile tramite opt-in.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Revisit the format / transform interface (and its implementation) now that
datasets >= 4 returns lazy Column objects for column access. The current
behavior is intentional and documented — this issue is a placeholder to
reconsider the design, not a bug report.

Current model

A Dataset has two independent underlying slots:

  • the python format pyds._format_type (set via datasets' own
    set_format): nothing, "numpy", "torch", "pandas", "arrow",
    "polars", …
  • the julia jltransform field: py2jl, identity, or a user function.

The public API couples them into a single "format" slot (src/dataset.jl,
set_format!):

  • "julia" ≡ (_format_type = nothing, jltransform = py2jl)
  • any python format X ≡ (_format_type = X, jltransform = identity)

So the two slots are mutually exclusive through the API: setting "julia"
resets the python format to nothing; setting a python format installs
identity. The one combination that cannot be expressed is "python format X
and py2jl on top."

What prompted this

With datasets >= 4, ds["col"] returns a lazy datasets.Column, which we now
wrap in a lazy HuggingFaceDatasets.Column <: AbstractVector (added alongside
the datasets >= 4 support). It was observed that the "julia" format calls reset_format(),
so ds.pyds["col"] is always a Column.

Worth recording: resetting to nothing is not what forces the Column. In
datasets 4, Dataset.__getitem__(str) returns a Column for every format
except arrow/pandas/polars:

python format ds["col"] returns
nothing (our "julia") datasets.Column (lazy)
"numpy" datasets.Column (lazy)
"torch" datasets.Column (lazy)
"pandas" pandas.Series (native)
"arrow" pyarrow.ChunkedArray (native)
"polars" polars.Series (native)

So decoupling the two formats would not avoid Columns in general — the lazy
Column is simply the v4 default for column access.

Points to reconsider

  1. One format slot vs. two independent axes. Conceptually the python format
    and the julia conversion are orthogonal (what datasets produces vs. a
    julia-side transform). Exposing both is more faithful but roughly doubles the
    state space; most combinations are redundant (py2jl already absorbs numpy
    copylessly via DLPack) or ill-defined (py2jl has no branch for a pandas
    Series / arrow table / torch tensor). Current stance: keep the single slot;
    with_jltransform / MLUtils.mapobs are the intended composition points.

  2. The one real limitation — numeric throughput. Under nothing, a numeric
    batch comes back as a python list and py2jl copies it element-by-element;
    under "numpy" it would be an np.ndarray → numpy2jl (zero-copy). This is
    the single case where "numpy" + py2jl genuinely wins.

  3. Possible internal optimization (benchmark first). Rather than exposing a
    second format knob, consider whether the "julia" format should sit on
    "numpy" instead of nothing, so numeric columns transfer copyless. Tradeoff:
    image columns currently arrive as PIL.Image (→ Gray/RGB ImageCore
    views) under nothing; under "numpy" they'd be raw transposed arrays and we
    lose that clean path. Best validated with the perf/ harness on both numeric
    and image datasets before changing anything.

Non-goals / decision so far

  • Keep the current format behavior as-is for now (intentional, documented in the
    guide's "The "julia" format and transforms" section).
  • No API change until the numeric zero-copy question (2/3) is benchmarked and we
    decide whether the win justifies either an internal base-format change or a
    second, opt-in axis.
Lingua principale
Julia
Stelle
38
Fork
1
Merge medio
3h 30m
PR unite (30g)
20

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JuliaGenAI/HuggingFaceDatasets.jl

Tutte le issue di JuliaGenAI/HuggingFaceDatasets.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.