Support for generic distance calculation delegate #9

amaid · 2023-09-24T08:35:43Z

Closes #8
This pull request appears to be making changes to a C# codebase, likely related to a machine learning or data analysis library. The changes seem to be focused on introducing generic types and refining the code structure. Below is a description of the changes made in this pull request:

DistanceCalculation Delegate Change:
- A delegate called DistanceCalculation is modified to become a generic delegate DistanceCalculation<T> where T must implement the IUmapDataPoint interface. This change allows for more flexible distance calculations that can work with different types of data points.
IUmapDataPoint Interface Addition:
- A new interface named IUmapDataPoint is added to the UMAP namespace. This interface represents a single data point that will be processed by the UMAP algorithm. It requires implementing classes to provide a Data property, likely representing the data associated with the data point.
NNDescent Changes:
- The NNDescent class, which appears to be related to nearest neighbor descent, is updated to be a generic class NNDescent<T> where T must implement the IUmapDataPoint interface. This change ensures that the class can work with different types of data points.
SIMD and SIMDInt Changes:
- The SIMD and SIMDInt classes are updated to become generic classes SIMD<T> and SIMDInt<T>. This change likely reflects the need to work with different data types (possibly floating-point and integer) depending on the data points used.
Tree Changes:
- The Tree class is updated to become a generic class Tree<T> where T must implement the IUmapDataPoint interface. This change ensures that the class can work with different types of data points.
Umap Class Changes:
- The Umap class is updated to become a generic class Umap<T> where T must implement the IUmapDataPoint interface. This change allows the UMAP algorithm to operate on different types of data points.
- The DistanceCalculation field is changed to DistanceCalculation<T> to reflect the use of a generic distance calculation delegate.
- Various methods and internal structures within the Umap class are adjusted to accommodate the use of generic data types.
Distance Functions:
- The DistanceFunctions class defines different distance calculation functions such as cosine and Euclidean distance. These functions are updated to accept generic data types (T) instead of float arrays.
OptimizationState Class:
- The OptimizationState class appears to store various parameters and state information related to the UMAP algorithm. It is not directly impacted by the generic changes but is part of the UMAP class.

In summary, this pull request introduces generic type support for the UMAP algorithm, allowing it to work with different data point types while maintaining flexibility in distance calculations and optimizations. Additionally, it adds an interface (IUmapDataPoint) for representing data points processed by UMAP.

amaid · 2023-09-24T08:41:19Z

@theolivenbaum - Pull request created to address issue #8 (Distance calculation using additional data)

Arlodotexe · 2023-09-26T23:43:41Z

👋 @amaid You've essentially abstracted away each separate vector in the embedding, rather than abstracting away the vector array float[]. I'm going to open a PR to your fork to fix this, which will show here once merged.

This was abstracting away each separate vector in the embedding, rather than abstracting away the vector array float[]

Arlodotexe · 2023-09-27T15:53:58Z

@amaid I've got a PR opened on your fork. Once merged, the changes should show in this PR automatically.

Needed for https://github.com/Arlodotexe/OwlCore.AI.Exocortex

Implemented IUmapDataPoint, cleanup IUmapDistanceParameter.

amaid · 2023-09-27T17:46:32Z

@amaid I've got a PR opened on your fork. Once merged, the changes should show in this PR automatically.

Needed for https://github.com/Arlodotexe/OwlCore.AI.Exocortex

Awesome! merged.

Arlodotexe · 2023-09-27T17:59:29Z

@theolivenbaum I recommend squashing this PR when merging/closing.

I'm also aware that this is a breaking change to the library, which will need a bit of discussion and possibly a migration guide.

Or, maybe we should just ship an inbox non-generic implementation to polyfill what we had before? Something like:

public class RawVectorArrayUmapDataPoint : IUmapDataPoint
{
    public RawVectorArrayUmapDataPoint(float[] data) => Data = data;

     public float[] Data { get; }

    /// <summary>
    /// Define an implicit conversion operator from <see cref="float[]"/>.
    /// </summary>
    public static implicit operator RawVectorArrayUmapDataPoint(float[] data)  => new(x);   
        
    /// <summary>
    /// Implicit conversation back to <see cref="float[]"/>.
    /// </summary>
    public static implicit operator float[](RawVectorArrayUmapDataPoint x) => x.Data;   
}

public class Umap : Umap<RawVectorArrayUmapDataPoint>
{
    public Umap(
            DistanceCalculation<RawVectorArrayUmapDataPoint> distance = null,
            IProvideRandomValues random = null,
            int dimensions = 2,
            int numberOfNeighbors = 15,
            int? customNumberOfEpochs = null,
            ProgressReporter progressReporter = null)
                : base(distance, random, dimensions, numberOfNeighbors, customNumberOfEpochs, progressReporter)
        {
             // ...
        }
}

The implicit conversion in RawVectorArrayUmapDataPoint should allow the library consumer to use the library as they were before, passing a float[] directly to a new Umap(...).InitializeFit(someFloatArray); without the generics.

amaid · 2023-11-19T20:02:44Z

@theolivenbaum I recommend squashing this PR when merging/closing.

I'm also aware that this is a breaking change to the library, which will need a bit of discussion and possibly a migration guide.

Or, maybe we should just ship an inbox non-generic implementation to polyfill what we had before? Something like:

public class RawVectorArrayUmapDataPoint : IUmapDataPoint
{
    public RawVectorArrayUmapDataPoint(float[] data) => Data = data;

     public float[] Data { get; }

    /// <summary>
    /// Define an implicit conversion operator from <see cref="float[]"/>.
    /// </summary>
    public static implicit operator RawVectorArrayUmapDataPoint(float[] data)  => new(x);   
        
    /// <summary>
    /// Implicit conversation back to <see cref="float[]"/>.
    /// </summary>
    public static implicit operator float[](RawVectorArrayUmapDataPoint x) => x.Data;   
}

public class Umap : Umap<RawVectorArrayUmapDataPoint>
{
    public Umap(
            DistanceCalculation<RawVectorArrayUmapDataPoint> distance = null,
            IProvideRandomValues random = null,
            int dimensions = 2,
            int numberOfNeighbors = 15,
            int? customNumberOfEpochs = null,
            ProgressReporter progressReporter = null)
                : base(distance, random, dimensions, numberOfNeighbors, customNumberOfEpochs, progressReporter)
        {
             // ...
        }
}

The implicit conversion in RawVectorArrayUmapDataPoint should allow the library consumer to use the library as they were before, passing a float[] directly to a new Umap(...).InitializeFit(someFloatArray); without the generics.

This is implemented.

Arlodotexe · 2023-11-20T17:04:28Z

You changed all the internal T to a hardcoded type (the new one), the code I provided works without making further changes to Umap<T>. We'll need to correct this.

This reverts commit 7bf1936.

…onsumers

amaid · 2023-11-20T19:44:06Z

You changed all the internal T to a hardcoded type (the new one), the code I provided works without making further changes to Umap<T>. We'll need to correct this.

This has been fixed, the implicit typecasting has been implemented to support explicit float[][] data to support existing class consumers without changing the existing implementation of Umap

@theolivenbaum The PR is ready to be merged. The changes have been tested for existing class consumers as well. The unit tests are passing.

Arlodotexe · 2024-05-27T13:36:44Z

Great, thanks @amaid!

@theolivenbaum Bumping

Arlodotexe · 2024-12-18T20:48:27Z

You changed all the internal T to a hardcoded type (the new one), the code I provided works without making further changes to Umap<T>. We'll need to correct this.

This has been fixed, the implicit typecasting has been implemented to support explicit float[][] data to support existing class consumers without changing the existing implementation of Umap

@theolivenbaum The PR is ready to be merged. The changes have been tested for existing class consumers as well. The unit tests are passing.

@theolivenbaum Any chance we could get eyes on this?

amaidniazi added 5 commits September 23, 2023 15:42

Added support for generic distance function for umap.

15a4937

cleaned up IUmapDistaance.

b657049

Renamed parameter class for distance calculation in umap

6d6b258

optimized the use of the IUmapDistance array+ code cleanup.

0ea33e8

reverted formatting in optimizationState.

b6a1ecc

Implemented IUmapDataPoint, cleanup IUmapDistanceParameter.

1750fc7

This was abstracting away each separate vector in the embedding, rather than abstracting away the vector array float[]

Arlodotexe mentioned this pull request Sep 27, 2023

Implemented IUmapDataPoint, cleanup IUmapDistanceParameter. amaid/umap-sharp#1

Merged

Arlodotexe added 4 commits September 26, 2023 20:02

Remove public modifier (C# 8+ only)

e832242

Fixed conflicting generic name

1c28b9f

Reverted nullable annotations (C# 8+ only)

aa8fe99

Removed generic from DistanceFunctions, now inherits from Umap<T>

99767f1

Merge pull request #1 from Arlodotexe/master

a3eb8e3

Implemented IUmapDataPoint, cleanup IUmapDistanceParameter.

Added implicit operator overloading for datapoints.

7bf1936

amaidniazi added 3 commits November 20, 2023 18:30

Revert "Added implicit operator overloading for datapoints."

496a55d

This reverts commit 7bf1936.

Fixed implict cast for Umap.

6232e95

Added ability to support explicit float[][] type for existing class c…

372a99c

…onsumers

fixed doc reference on the umap class.

18b02a1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for generic distance calculation delegate #9

Support for generic distance calculation delegate #9

amaid commented Sep 24, 2023 •

edited

Loading

amaid commented Sep 24, 2023 •

edited

Loading

Arlodotexe commented Sep 26, 2023 •

edited

Loading

Arlodotexe commented Sep 27, 2023

amaid commented Sep 27, 2023

Arlodotexe commented Sep 27, 2023 •

edited

Loading

amaid commented Nov 19, 2023

Arlodotexe commented Nov 20, 2023 •

edited

Loading

amaid commented Nov 20, 2023 •

edited

Loading

Arlodotexe commented May 27, 2024 •

edited

Loading

Arlodotexe commented Dec 18, 2024

Support for generic distance calculation delegate #9

Are you sure you want to change the base?

Support for generic distance calculation delegate #9

Conversation

amaid commented Sep 24, 2023 • edited Loading

amaid commented Sep 24, 2023 • edited Loading

Arlodotexe commented Sep 26, 2023 • edited Loading

Arlodotexe commented Sep 27, 2023

amaid commented Sep 27, 2023

Arlodotexe commented Sep 27, 2023 • edited Loading

amaid commented Nov 19, 2023

Arlodotexe commented Nov 20, 2023 • edited Loading

amaid commented Nov 20, 2023 • edited Loading

Arlodotexe commented May 27, 2024 • edited Loading

Arlodotexe commented Dec 18, 2024

amaid commented Sep 24, 2023 •

edited

Loading

amaid commented Sep 24, 2023 •

edited

Loading

Arlodotexe commented Sep 26, 2023 •

edited

Loading

Arlodotexe commented Sep 27, 2023 •

edited

Loading

Arlodotexe commented Nov 20, 2023 •

edited

Loading

amaid commented Nov 20, 2023 •

edited

Loading

Arlodotexe commented May 27, 2024 •

edited

Loading