Files
richard-churchman cc0a2bee21 Extensive modifications to the serialisation of Neural Network models to support Newtonsoft Json.net rather than Binary Serializer.
Included open-source Accord.net library code natively to the solution given the deprecated state of that project.  Accord.net will be supported inside Jube for own needs (such as upgrading to .Net 7+).

Accord.net libraries modified to compile to .Net 6.

Modified Accord.net libraries to better support Newtonsoft Json.net serialisation.

Included annotations in the Accord.net libraries to house important dependency statistics. Serialised json can be used independently of Jube to recall a Neural Network.

Removal of Binary Serializer totally as a precursor to the projects support of .Net 7+.

Extensive bug fixing in crucial functions of Neural Network training and recall.  While this part of the system remains in Alpha, it is substantially more fit for purpose.
2023-12-24 10:22:22 +01:00

124 lines
5.2 KiB
C#

// Accord Math Library
// The Accord.NET Framework
// http://accord-framework.net
//
// Copyright © César Souza, 2009-2017
// cesarsouza at gmail.com
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
//
namespace Accord.Math.Distances
{
/// <summary>
/// Common interface for distance functions (not necessarily metrics).
/// </summary>
///
/// <remarks>
/// <para>
/// The framework distinguishes between metrics and distances by using different
/// types for them. This makes it possible to let the compiler figure out logic
/// problems such as the specification of a non-metric for a method that requires
/// a proper metric (i.e. that respects the triangle inequality).</para>
///
/// <para>
/// The objective of this technique is to make it harder to make some mistakes.
/// However, it is generally possible to bypass this mechanism by using named constructors
/// available at each of the classes, such as Minkowski's <see cref="Minkowski.Nonmetric"/>
/// method, to create distances implementing the <see cref="IMetric{T}"/> interface that are not
/// really metrics. Use at your own risk.</para>
/// </remarks>
///
/// <typeparam name="T">The type of the first element to be compared.</typeparam>
/// <typeparam name="U">The type of the second element to be compared.</typeparam>
///
/// <seealso cref="IMetric{T}"/>
///
public interface IDistance<in T, in U>
{
/// <summary>
/// Computes the distance <c>d(x,y)</c> between points
/// <paramref name="x"/> and <paramref name="y"/>.
/// </summary>
///
/// <param name="x">The first point <c>x</c>.</param>
/// <param name="y">The second point <c>y</c>.</param>
///
/// <returns>
/// A double-precision value representing the distance <c>d(x,y)</c>
/// between <paramref name="x"/> and <paramref name="y"/> according
/// to the distance function implemented by this class.
/// </returns>
///
double Distance(T x, U y);
}
/// <summary>
/// Common interface for distance functions (not necessarily metrics).
/// </summary>
///
/// <remarks>
/// <para>
/// The framework distinguishes between metrics and distances by using different
/// types for them. This makes it possible to let the compiler figure out logic
/// problems such as the specification of a non-metric for a method that requires
/// a proper metric (i.e. that respects the triangle inequality).</para>
///
/// <para>
/// The objective of this technique is to make it harder to make some mistakes.
/// However, it is generally possible to bypass this mechanism by using named constructors
/// available at each of the classes, such as Minkowski's <see cref="Minkowski.Nonmetric"/>
/// method, to create distances implementing the <see cref="IMetric{T}"/> interface that are not
/// really metrics. Use at your own risk.</para>
/// </remarks>
///
/// <typeparam name="T">The type of the elements to be compared.</typeparam>
///
/// <seealso cref="IDistance{T}"/>
/// <seealso cref="IDistance{T, U}"/>
/// <seealso cref="IMetric{T}"/>
///
public interface IDistance<in T> : IDistance<T, T>
{
}
/// <summary>
/// Common interface for distance functions (not necessarily metrics).
/// </summary>
///
/// <remarks>
/// <para>
/// The framework distinguishes between metrics and distances by using different
/// types for them. This makes it possible to let the compiler figure out logic
/// problems such as the specification of a non-metric for a method that requires
/// a proper metric (i.e. that respects the triangle inequality).</para>
///
/// <para>
/// The objective of this technique is to make it harder to make some mistakes.
/// However, it is generally possible to bypass this mechanism by using named constructors
/// available at each of the classes, such as Minkowski's <see cref="Minkowski.Nonmetric"/>
/// method, to create distances implementing the <see cref="IMetric{T}"/> interface that are not
/// really metrics. Use at your own risk.</para>
/// </remarks>
///
/// <seealso cref="IDistance{T}"/>
/// <seealso cref="IMetric{T}"/>
///
public interface IDistance : IDistance<double[]>
{
}
}