Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

GenericTensor 2.0

オープン
  • 何か問題がありますか？
#27 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
csharp
領域
data, performance

調査の方向性

まず、issue に記載されている現在の大きなインターフェース、汎用テンソル型、スパース変換、既存のエントリーポイントを洗い出します。次元に関する未解決の問題を解決する前に、提案されているアクション固有のインターフェース、dense Tensor と TensorView の API、アクセラレーションの選択肢、命名の変更、ConvolutedMap 操作を比較します。完了とは、単一の孤立した編集ではなく、設計が確定し、互換性のある API 計画が実装されていることを意味します。

索引モデルが issue の本文から書いたものです。

説明

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?

主要言語
C#
スター
52
フォーク
6
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ASC-Community/GenericTensor のほかの issue

ASC-Community/GenericTensor の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。