https://github.com/chakravala/abstracttensors.jl

Tensor algebra abstract type interoperability setup

https://github.com/chakravala/abstracttensors.jl

Science Score: 23.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
  • DOI references
  • Academic publication links
    Links to: zenodo.org
  • Committers with academic emails
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (10.7%) to scientific vocabulary

Keywords

applied-category-theory category-theory compositionality functor linear-algebra manifold manifolds math tensor tensor-algebra type-system
Last synced: 5 months ago · JSON representation

Repository

Tensor algebra abstract type interoperability setup

Basic Info
Statistics
  • Stars: 44
  • Watchers: 4
  • Forks: 5
  • Open Issues: 0
  • Releases: 55
Topics
applied-category-theory category-theory compositionality functor linear-algebra manifold manifolds math tensor tensor-algebra type-system
Created about 7 years ago · Last pushed 7 months ago
Metadata Files
Readme License

README.md

AbstractTensors.jl

Tensor algebra abstract type interoperability with vector bundle parameter

DOI Docs Stable Docs Dev Gitter Build Status Build status Coverage Status codecov.io

The AbstractTensors package is intended for universal interoperability of the abstract TensorAlgebra type system. All TensorAlgebra{V} subtypes have type parameter V, used to store a TensorBundle value obtained from DirectSum.jl.

For example, this is mainly used in Grassmann.jl to define various SubAlgebra, TensorGraded and TensorMixed types, each with subtypes. Externalizing the abstract type helps extend the dispatch to other packages. By itself, this package does not impose any specifications or structure on the TensorAlgebra{V} subtypes and elements, aside from requiring V to be a Manifold. This means that different packages can create tensor types having a common underlying TensorBundle structure.

Additionally, TupleVector is provided as a light weight alternative to StaticArrays.jl.

If the environment variable STATICJL is set, the StaticArrays package is depended upon.

Interoperability

Since TensorBundle choices are fundamental to TensorAlgebra operations, the universal interoperability between TensorAlgebra{V} elements with different associated TensorBundle choices is naturally realized by applying the union morphism to operations.

```Julia function op(::TensorAlgebra{V},::TensorAlgebra{V}) where V # well defined operations if V is shared end # but what if V ≠ W in the input types?

function op(a::TensorAlgebra{V},b::TensorAlgebra{W}) where {V,W} VW = V ∪ W # VectorSpace type union op(VW(a),VW(b)) # makes call well-defined end # this option is automatic with interop(a,b)

alternatively for evaluation of forms, VW(a)(VW(b))

`` Some of operations like+,-,*,⊗,⊛,⊙,⊠,⨼,⨽,⋆and postfix operators⁻¹,ǂ,₊,₋,ˣforTensorAlgebraelements are shared across different packages, some of the interoperability is taken care of in this package. Additionally, a universal unit volume element can be specified in terms ofLinearAlgebra.UniformScaling, which is independent ofVand has its interpretation only instantiated by the context of theTensorAlgebra{V}` element being operated on.

Utility methods such as scalar, involute, norm, norm2, unit, even, odd are also defined.

Example with a new subtype

Suppose we are dealing with a new subtype in another project, such as Julia using AbstractTensors, DirectSum struct SpecialTensor{V} <: TensorAlgebra{V} end a = SpecialTensor{ℝ}() b = SpecialTensor{ℝ'}() To define additional specialized interoperability for further methods, it is necessary to define dispatch that catches well-defined operations for equal TensorBundle choices and a fallback method for interoperability, along with a Manifold morphism: Julia (W::Signature)(s::SpecialTensor{V}) where V = SpecialTensor{W}() # conversions op(a::SpecialTensor{V},b::SpecialTensor{V}) where V = a # do some kind of operation op(a::TensorAlgebra{V},b::TensorAlgebra{W}) where {V,W} = interop(op,a,b) # compat which should satisfy (using the operation as defined in DirectSum) Julia julia> op(a,b) |> Manifold == Manifold(a) ∪ Manifold(b) true Thus, interoperability is simply a matter of defining one additional fallback method for the operation and also a new form TensorBundle compatibility morphism.

UniformScaling pseudoscalar

The universal interoperability of LinearAlgebra.UniformScaling as a pseudoscalar element which takes on the TensorBundle form of any other TensorAlgebra element is handled globally by defining the dispatch: Julia (W::Signature)(s::UniformScaling) = ones(ndims(W)) # interpret a unit pseudoscalar op(a::TensorAlgebra{V},b::UniformScaling) where V = op(a,V(b)) # right pseudoscalar op(a::UniformScaling,b::TensorAlgebra{V}) where V = op(V(a),b) # left pseudoscalar This enables the usage of I from LinearAlgebra as a universal pseudoscalar element.

Tensor evaluation

To support a generalized interface for TensorAlgebra element evaluation, a similar compatibility interface is constructible.

Julia (a::SpecialTensor{V})(b::SpecialTensor{V}) where V = a # conversion of some form (a::SpecialTensor{W})(b::SpecialTensor{V}) where {V,W} = interform(a,b) # compat which should satisfy (using the operation as defined in DirectSum) Julia julia> b(a) |> Manifold == Manifold(a) ∪ Manifold(b) true The purpose of the interop and interform methods is to help unify the interoperability of TensorAlgebra elements.

Deployed applications

The key to making the whole interoperability work is that each TensorAlgebra subtype shares a TensorBundle parameter (with all isbitstype parameters), which contains all the info needed at compile time to make decisions about conversions. So other packages need only use the vector space information to decide on how to convert based on the implementation of a type. If external methods are needed, they can be loaded by Requires when making a separate package with TensorAlgebra interoperability.

TupleVector

Statically sized tuple vectors for Julia

TupleVector provides a framework for implementing statically sized tuple vectors in Julia, using the abstract type TupleVector{N,T} <: AbstractVector{T}. Subtypes of TupleVector will provide fast implementations of common array and linear algebra operations. Note that here "statically sized" means that the size can be determined from the type, and "static" does not necessarily imply immutable.

The package also provides some concrete static vector types: Values which may be used as-is (or else embedded in your own type). Mutable versions Variables are also exported, as well as FixedVector for annotating standard Vectors with static size information.

Quick start

Add AbstractTensors from the Pkg REPL, i.e., pkg> add AbstractTensors. Then: ```julia using AbstractTensors

Create Values using various forms, using constructors, functions or macros

v1 = Values(1, 2, 3) v1.v === (1, 2, 3) # Values uses a tuple for internal storage v2 = Values{3,Float64}(1, 2, 3) # length 3, eltype Float64 v5 = zeros(Values{3}) # defaults to Float64 v7 = Values{3}([1, 2, 3]) # Array conversions must specify size

Can get size() from instance or type

size(v1) == (3,) size(typeof(v1)) == (3,)

Supports all the common operations of AbstractVector

v7 = v1 + v2 v8 = sin.(v2)

Indexing can also be done using static vectors of integers

v1[1] === 1 v1[:] === v1 typeof(v1[[1,2,3]]) <: Vector # Can't determine size from the type of [1,2,3] ```

Approach

The package provides a range of different useful built-in TupleVector types, which include mutable and immutable vectors based upon tuples, vectors based upon structs, and wrappers of Vector. There is a relatively simple interface for creating your own, custom TupleVector types, too.

This package also provides methods for a wide range of AbstractVector functions, specialized for (potentially immutable) TupleVectors. Many of Julia's built-in method definitions inherently assume mutability, and further performance optimizations may be made when the size of the vector is known to the compiler. One example of this is by loop unrolling, which has a substantial effect on small arrays and tends to automatically trigger LLVM's SIMD optimizations. In combination with intelligent fallbacks to the methods in Base, we seek to provide a comprehensive support for statically sized vectors, large or small, that hopefully "just works".

TupleVector is directly inspired from StaticArrays.jl.

Owner

  • Name: Dream Scatter
  • Login: chakravala
  • Kind: user

computational language algeber 🧐 abstract research mathematician

GitHub Events

Total
  • Create event: 3
  • Commit comment event: 6
  • Release event: 3
  • Push event: 2
Last Year
  • Create event: 3
  • Commit comment event: 6
  • Release event: 3
  • Push event: 2

Committers

Last synced: about 2 years ago

All Time
  • Total Commits: 58
  • Total Committers: 2
  • Avg Commits per committer: 29.0
  • Development Distribution Score (DDS): 0.017
Past Year
  • Commits: 4
  • Committers: 1
  • Avg Commits per committer: 4.0
  • Development Distribution Score (DDS): 0.0
Top Committers
Name Email Commits
Michael Reed 1****a 57
Erik Schnetter s****r@g****m 1

Issues and Pull Requests

Last synced: 6 months ago

All Time
  • Total issues: 6
  • Total pull requests: 1
  • Average time to close issues: 22 days
  • Average time to close pull requests: about 1 hour
  • Total issue authors: 5
  • Total pull request authors: 1
  • Average comments per issue: 3.5
  • Average comments per pull request: 0.0
  • Merged pull requests: 1
  • Bot issues: 0
  • Bot pull requests: 0
Past Year
  • Issues: 0
  • Pull requests: 0
  • Average time to close issues: N/A
  • Average time to close pull requests: N/A
  • Issue authors: 0
  • Pull request authors: 0
  • Average comments per issue: 0
  • Average comments per pull request: 0
  • Merged pull requests: 0
  • Bot issues: 0
  • Bot pull requests: 0
Top Authors
Issue Authors
  • eschnett (2)
  • jverzani (1)
  • UlrikBuchholtz (1)
  • Socob (1)
  • Orbots (1)
Pull Request Authors
  • eschnett (1)
Top Labels
Issue Labels
bug (3) enhancement (2) help wanted (1)
Pull Request Labels
docs (1)

Packages

  • Total packages: 1
  • Total downloads:
    • julia 58 total
  • Total dependent packages: 9
  • Total dependent repositories: 0
  • Total versions: 59
juliahub.com: AbstractTensors

Tensor algebra abstract type interoperability setup

  • Versions: 59
  • Dependent Packages: 9
  • Dependent Repositories: 0
  • Downloads: 58 Total
Rankings
Dependent packages count: 7.0%
Dependent repos count: 9.9%
Average: 14.0%
Stargazers count: 14.6%
Forks count: 24.5%
Last synced: 6 months ago