Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

GenericTensor 2.0

Offen
  • Stimmt etwas nicht?
#27 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
20/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
csharp
Bereich
data, performance

Rechercherichtung

Beginne damit, das aktuelle große Interface, den generischen Tensor-Typ, die Sparse-Transformationen und die im Issue beschriebenen vorhandenen Einstiegspunkte zu inventarisieren. Vergleiche die vorgeschlagenen aktionsspezifischen Interfaces, die APIs von dichtem Tensor und TensorView, Beschleunigungsoptionen, Namensänderungen und die Operation ConvolutedMap, bevor du die offenen Fragen zur Dimensionalität klärst. Erledigt bedeutet ein festgelegtes Design und ein implementierter, kompatibler API-Plan statt einer einzelnen isolierten Änderung.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Opinions wanted proposal

GenericTensor 2.0: plan

Alright, time for improvement

1 action - 1 interface

Currently we have a large interface which forces the user to implement all its methods. It's not as good as it was thought to be:

  1. You may want not to implement a method, but you can't guess whether some GT's function uses it or not
  2. The interface is not extendable - adding a new method immediately breaks backward comaptibility

Instead, we will have one method in each interface (there will be multiple interfaces - like IAddAction<A, B, C> etc.).

Now we will be able to constrain each function separately, and the tensor itself won't be constrained (the type will have only one type argument - T). It makes all things much more convenient, and it also allows for more advanced API - for example, adding tensors would look like:

Tensor<C> AddElementwise<A, B, C, TAdd>(Tensor<A> a, Tensor<B> b) where TAdd : IAdd<A, B, C>

Non-generic entry point class API

Currently we need to type the typename with its arguments. Instead, there will be a non-generic static class to handle those things: thanks to type inference, we will type less.

No sparse transformation

Currently, there are some transformations, like transposition and slicing, which makes the tensor "sparse" - that is, instead of rewriting elements themselves, they rewrite the meanings of indices. That means, that going over a just created 2D tensor by width and height would be much faster than if we transpose that tensor beforehand.

In new API such a feature will remain in some different more explicit form, for example, TensorView<T>. It behaves similarly to BCL's Span<T>, which is basically a view on some piece of memory. Likewise, TensorView just allows to read/write to a tensor, but is not a tensor itself. Might be useful for some operations, where the user doesn't want to think about the order of axes or size of a tensor. Though not all API will be available for TensorView<T>.

But tensors itself will be strictly linear/dense. Slicing and transposition will produce a new dense tensor.

Hardware acceleration

Now, with dense tensors we can use three types of acceleration:

  1. Multithreading
  2. SIMD (HonkPerf.NET.GenericSIMD)
  3. GPU

Though the third one is questioned, the first two are definitely doable and will require new methods with type constrained to unmanaged. As simple as that.

New project name - GenericTensor.NET. New type name - Tensor.

Alright, this one is questionable. Should we rename to a more "modern" name? It would mean a new "slot" in nuget packages, and hence, not visible by current users (if there are any aside from AngouriMath, hehe).

New operations

We could implement convoluted map for it. Example of convoluted map:
Imagine matrix A

1 2 3
4 5 6
7 8 9

and then code:

B = A.ConvolutedMap(width: 2, height: 2, step: 1, view: TensorView -> view[0, 0] + view[0, 1] + view[1, 0] + view[1, 1]);

then B is

12 16
24 28

This way we can basically process, reshape, "bend", collapse or add axes anyhow we need. Upscale for instance:

A =
    1 2 3
    4 5 6
    7 8 9

B = A.ConvolutedMap(
    inputWidth: 2,
    inputHeight: 2,
    step: 2,
    outputWidth: 3,
    outputHeight: 3,
    (source: TensorView, destination: TensorView) ->
        destination[0, 0] = source[0, 0]
        destination[0, 2] = source[0, 1]
        destination[2, 0] = source[1, 0]
        destination[2, 2] = source[1, 1]
        destination[0, 1] = (destination[0, 0] + destination[0, 2]) / 2
        destination[1, 0] = (destination[0, 0] + destination[2, 1]) / 2
        etc...
)

Note, that we don't limit to 2d convolution here, though not sure where we could ever need 4D+ convolutions.

Unresolved questions

Should there be single type Tensor or by dimension - Tensor1D, Tensor2D, etc.? If the latter, should there be TensorND or just cover a fixed number of dimensions?

Vorherrschende Sprache
C#
Sterne
52
Forks
6
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus ASC-Community/GenericTensor

Alle Issues in ASC-Community/GenericTensor

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.