Add support for calling gemm or dot, for example, directly on Array objects. This could dramtically simplify the implementation of the code as well :)

This is a test issue with some code which should be Carbonited

for i in range(100):
    print("Hello, World")

print("Goodbye, World")

Does this work?

https://github.com/BigNerd95/CUDASamples/blob/master/samples/0_Simple/cudaTensorCoreGemm/cudaTensorCoreGemm.cu

Allow for integer dot products, for example

Write and check documentation for the vector library

Add support for matrix transpositions.

This should also allow the conversion of a vector array into a column vector with dimensions Nx1.

Can this be lined with matrix multiplication (#141) to provide higher performance matrix operations? Transposing a matrix and then doing a matrix product with it automatically uses the gemm with transposed arguments?

Below is a code block which should be turned into an image :)

for i in range(123):
    print("Hello, World!")

Matrix transposition works fine if all the arrays are the correct size, but it's possible that memory errors could arise if the arrays are not correctly sized.

Currently, float16_t has limited support in the main math library. This needs to be supported somewhat soon.

Not sure exactly where the error is, but the following code doesn't work under the current Development and Master branches.

lrc::Array<float> val(lrc::Shape({2, 2}));
lrc::Array<float> lower1(lrc::Shape({2, 2}));
lrc::Array<float> upper1(lrc::Shape({2, 2}));
lrc::Array<float> lower2(lrc::Shape({2, 2}));
lrc::Array<float> upper2(lrc::Shape({2, 2}));

val << 1, 2, 3, 4;
lower1 << 0, 0, 0, 0;
upper1 << 10, 10, 10, 10;
lower2 << 0, 0, 0, 0;
upper2 << 100, 100, 100, 100;

fmt::print("{}\n\n", val);
fmt::print("{}\n\n", lower1);
fmt::print("{}\n\n", upper1);
fmt::print("{}\n\n", lower2);
fmt::print("{}\n\n", upper2);
fmt::print("{}\n", lrc::map(val, lower1, upper1, lower2, upper2));

Hopefully, by the end of Q3 2022, GitHub Actions will support more powerful, custom runners. This will dramatically reduce the build-times for LibRapid wheels as well as allowing for a more fully-featured package due to fewer limitations on RAM and CPU power

github/roadmap#161

Support 2D gemm functionality, as well as higher-dimensional products

CUDA support is also required

Create a function for strided array copying, otherwise the entire array library will crash with non-trivial arrays.

The main issue will occur within the multiarray_operations.hpp file, as makeSameAccelerator does not take into account strides, which will lead to some form of segfault or simply using the wrong values.

Is your feature request related to a problem? Please describe.
There is currently no way of accessing sub-arrays without manually iterating over them, which is sometimes difficult and inconvenient.

Describe the solution you'd like
Some sort of ArraySlice object that can be used as a strided view of an Array object.

Describe alternatives you've considered

• Use a strided array to begin with? Doesn't feel optimal
• Do not allow strided access, but allow for sub-array access (parent data pointer)

Benchmark the Array type and other classes and helpers

Compare against

• Numpy
• XTensor
• Eigen
• Boost multidimensional array

BLAS gemm support

The code is becoming increasingly fragmented -- this makes development more difficult and leads to unwanted and unexpected bugs.

Each file should implement only one thing, and header files should not include any other headers. Instead, files should be included in librapid.hpp in the correct order, and STL includes should be at the top of config.hpp

Tested in Python

import librapid as lrp

x = lrp.Array(lrp.Extent((1000, 1000)), "f32")
x.transpose() # This doesn't work -- list type is invalid
x.transpose(lrp.Extent()) # This gives the wrong output. Possibly a missing copy?

Can the constructors in the multiarray_constuctors.cpp file be converted into a single, templated constructor which makes use of datatype inspection?

Describe the bug
The patch() functions defined in the multiprecision source files when multiprecision is NOT enabled should be removed/fixed

To Reproduce
Steps to reproduce the behavior:

1. Include LibRapid without LIBRAPID_USE_MULTIPREC

Minimal Reproducable Example

#include <librapid>

int main() {
    fmt::print("Hello, World\n");
    return 0;
}

Expected behavior
No warnings

Stack Traces

multiprecModAbs.cpp.obj : warning LNK4006: "int __cdecl patch(int)" (?patch@@YAHH@Z) already defined in multiprecTrig.cpp.obj; second definition ignored
multiprecHypot.cpp.obj : warning LNK4006: "int __cdecl patch(int)" (?patch@@YAHH@Z) already defined in multiprecTrig.cpp.obj; second definition ignored
multiprecFloorCeil.cpp.obj : warning LNK4006: "int __cdecl patch(int)" (?patch@@YAHH@Z) already defined in multiprecTrig.cpp.obj; second definition ignored
multiprecExpLogPow.cpp.obj : warning LNK4006: "int __cdecl patch(int)" (?patch@@YAHH@Z) already defined in multiprecTrig.cpp.obj; second definition ignored
multiprecCasting.cpp.obj : warning LNK4006: "int __cdecl patch(int)" (?patch@@YAHH@Z) already defined in multiprecTrig.cpp.obj; second definition ignored

Add support for:

• Matrix-matrix multiplication
• Matrix-vector multiplication
• Vector product

Matrix Transposition is currently trivially implemented, and it quite slow compared to other libraries. This should be optimized for all dimensions of array, though specifically for matrices where the matrix transpose is performance critical in many applications.

Ideas:

1. OpenBlas *omatcopy
2. Hard-coded matrix transpose for 2D
3. Vectorised transpose (See transpose.hpp)
4. Help me...

Fundamental data structures required for an efficient Vector library

Array slicing is functional, but is not optimised to the extent required by LibRapid. Additionally, while it does work with CUDA, there are no specific routines for it and hence device->host->device copies are required for every value, making it incredibly slow.

Can the code in multiarray_operations.hpp at the top of the functions (to ensure everything is in the same place) be altered to use only malloc and memcpy?

Online documentation does not have a search bar for some reason...

Create a full testing suite for the vector library

Does what it says on the can. Write some ****ing documentation.

Vector library is currently unmaintainable. A rewrite is needed to improve functionality and ease of development

This is some code:

# -*- coding: utf-8 -*-
import os
import platform
import shutil
import sys
import site
from packaging.version import LegacyVersion
from skbuild import setup
from skbuild.cmaker import get_cmake_version
from skbuild.exceptions import SKBuildError

# Copy OpenBLAS build if present in the root directory
if os.path.exists("openblas_install") and not os.path.exists(os.path.join("src", "librapid", "openblas_install")):
    shutil.copytree("openblas_install", os.path.join("src", "librapid", "openblas_install"))

# Remove _skbuild directory if it already exists. It can lead to issues
if os.path.exists("_skbuild"):
    shutil.rmtree("_skbuild")

# Remove the _librapid_python_cmake directory if it's present. This can cause more issues...
if os.path.exists("_librapid_python_cmake"):
    shutil.rmtree("_librapid_python_cmake")

# If the directory "src/librapid/blas" is empty and "src/librapid/openblas_install" is empty,
# run CMake to automatically detect BLAS before installing the Python library
if not os.path.exists(os.path.join("src", "librapid", "blas")) and not os.path.exists(os.path.join("src", "librapid", "openblas_install")):
    out = os.system("mkdir _librapid_python_cmake && cd _librapid_python_cmake && cmake ..")
    if out != 0:
        print("\nCMake failed to run correctly, so it is likely that BLAS will not be installed with LibRapid")

# Add CMake as a build requirement if cmake is not installed or is too low a version
setup_requires = []
install_requires = []

try:
    if LegacyVersion(get_cmake_version()) < LegacyVersion("3.10"):
        setup_requires.append('cmake')
        install_requires.append("cmake")
except SKBuildError:
    setup_requires.append('cmake')
    install_requires.append("cmake")

Add functionality for converting arrays to strings for printing purposes.

Hey! This library looks really cool. For your awareness, I've raised a request for a recipe for this library to be created for the Conan Center Index . Conan is a C++ package manager that I think would help distribute your library with dependency management, especially with respect to pulling openblas in. If you're interested in supporting a conan recipe, I'm sure they would love to receive a pull request.

• conan-io/conan-center-index#7880
• Conan - How to add packages

Allow the creation of a string representation of a vector object (ideally with formatting options)

Have a look into cuda-toolkit and think about getting CUDA support in Python Wheels. This would require some sort of pip install librapid_cuda_11_5, for example, which would also need to be set up

This is a test issue

while True:
    print("This is going to be made into an image!")

print("Hehehe this won't run")

Arrays do not get freed (or get over-freed) when iterating in python.

To replicate:

import librapid as lrp
x = lrp.Array([1, 2, 3])
for val in x:
    print(val)

When using cuBLAS functions in the python library, the cuBLAS handles are not being initialised and hence an error is thrown.

Example:

import librapid as lrp

x = lrp.Array(lrp.Extent(1000, 1000), "f32", "gpu")
res = x.dot(x)

Should be fixable by changing where the handle initialisation occurs.

Functions

• Trigonometry
  • sin
  • cos
  • tan
  • csc
  • sec
  • cot
  • inverse
  • hyperbolic
• Arithmetic
  • add
  • sub
  • mul
  • div
  • inplace?
• Logical
  • greaterThan
  • lessThan
  • equalTo
  • notEqualTo

need to have a closer look, but this feels wrong:

ScalarSum<LHS, RHS> &operator=(const ScalarSum<LHS, RHS> &other) { return *this; }

Currently, Boolean arrays pose a few issues, the first of which is that each element is stored as a single bit, not a whole byte. This dramatically improves memory efficiency and increases performance, however it also causes a lot of problems with algorithm design and interoperability with other array datatypes.

Currently, the major issue is that any form of logical operation will result in a Vc::Mask being returned from the SIMD packet instruction, whereas the result will be expecting a Vc::Vector type. This will, of course, produce a compile-time error.

Current steps to solve problem

1. Logical operation factory -- define a logical operation which automatically returns a Boolean array, regardless of input type
2. Rewrite Boolean array class to operate more nicely with Vc::Mask datatypes
   • This includes adding a loadFrom function which will accept a Vc::Mask to allow for direct loading from a Vc logical comparison
3. Casting support to and from Vc::Mask datatypes?

Other ideas:

• Can Boolean arrays be stored directly as arrays of Vc::Mask?

IN THE MEANTIME, SUPPORT FOR BOOLEAN ARRAYS IN THE PYTHON LIBRARY WILL BE DISABLED

Add Complex Number support to LibRapid (with support for MPFR types)

complexlib
GCC

Add support for inplace array operations, such as:

x *= y;
x -= y;
// etc.

Once again, more problems with the boolean array.

This must be fixed by #102

Reproducable example:

lrc::Array<int, lrc::device::CPU> arr(lrc::Extent(10));
arr = lrc::Array<int>(lrc::Extent(100));
arr.fill(123);
fmt::print("Array: {}\n", arr);

File: src/librapid/internal/config.hpp

Line: 52

Request: Improve printing to support a wider range of arguments and configuration options

Issue when freeing memory -- must cast from T* to unsigned char *

Add CUDA support back to the new library!

For some reason, the following code errors after 4 iterations. Most likely a missing copy somewhere, but not quite sure.

lrc::Array<float, lrc::device::GPU> gpuArray(lrc::Extent(3, 4));
lrc::Array<float, lrc::device::CPU> cpuArray(lrc::Extent(3, 4));
for (lrc::i32 i = 0; i < 10000; i++) {
    fmt::print("Doing thing {}\n", i);
    cpuArray = (gpuArray * 2);
}