sferes2 /
sferes2
A lightweight, generic C++11 framework for evolutionary computation
56/100 healthLoading repository data…
genbattle / repository
A generic C++11 k-means clustering implementation
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
This is a generic k-means clustering algorithm written in C++, intended to be used as a header-only library. Requires C++11.
The algorithm is based on Lloyds Algorithm and uses the kmeans++ initialization method.
The library is located in the include directory and may be used under the terms of the MIT license (see LICENSE.md). The tests in the src/test directory are also licensed under the MIT license, except for lest.hpp, which has its own license (src/test/LICENSE_1_0.txt), the Boost Software License. The benchmarks located within the bench directory also fall under the MIT license. Benchmark data was obtained from the UCI Machine Learning Repository here and the University of Eastern Finland here.
dkm.hpp contains the standard serial implementation which depends only on C++11 support. dkm_parallel.hpp contains the parallel implementation which relies on OpenMP for acceleration; make sure to add -fopenmp (for GCC), -fopenmp=libiomp5 (for Clang) or equivalent to your compiler flags to enable OpenMP if you use this implementation.
A simple benchmark can be found in the bench folder. An example of the current results on an Intel i5-4210U @ 1.7GHz:
# BEGINNING PROFILING #
## Dataset iris.data.csv ##
..............................
DKM: 0.0425224ms
DKM parallel: 0.0819724ms
OpenCV: 0.0532497ms
## Dataset s1.data.csv ##
..............................
DKM: 7.19246ms
DKM parallel: 4.95625ms
OpenCV: 4.56927ms
## Dataset birch3.data.csv ##
..............................
DKM: 5747.78ms
DKM parallel: 2985.93ms
OpenCV: 2367.55ms
## Dataset dim128.data.csv ##
....................
DKM: 36.7438ms
DKM parallel: 15.6721ms
OpenCV: ---
DKM is at least as fast as OpenCV for small datasets (< 500 points) and can handle any amount of dimensions (OpenCV is limited to 1D/2D data). At larger data sizes the parallel DKM implementation is significantly faster, and only slightly slower than the OpenCV implementation (in my testing).
iris.data.csv natural data taken from measurements of different iris plants. 150 points, 2 dimensions, 3 clusters. Source: UCI machine learning repository.
s1.data.csv synthetic data. 5000 points, 2 dimensions, 15 clusters. Source: P. Fränti and O. Virmajoki, "Iterative shrinking method for clustering problems", Pattern Recognition, 39 (5), 761-765, May 2006.
birch3.data.csv synthetic data large set. 100000 points, 2 dimensions, 100 clusters. Source: Zhang et al., "BIRCH: A new data clustering algorithm and its applications", Data Mining and Knowledge Discovery, 1 (2), 141-182, 1997
dim128.data.csv synthetic data with high dimensionality. 1024 points, 128 dimensions, 16 clusters. Source: P. Fränti, O. Virmajoki and V. Hautamäki, "Fast agglomerative clustering using a k-nearest neighbor graph", IEEE Trans. on Pattern Analysis and Machine Intelligence, 28 (11), 1875-1881, November 2006
To use the DKM k-means implementation, simply include include/dkm.hpp and call dkm::kmeans_lloyd() with your data (std::vector<std::array<>>) and the number of cluster centers the algorithm should calculate for the data set. It is recommended that float or double are used for the input data types; with integer data types the algorithm may not converge.
Example:
std::vector<std::array<float, 2>> data{{1.f, 1.f}, {2.f, 2.f}, {1200.f, 1200.f}, {2.f, 2.f}};
auto cluster_data = dkm::kmeans_lloyd(data, 2);
The parallel implementation works in the same way, except the header to include is include/dkm_parallel.hpp and the function to call is dkm::kmeans_lloyd_parallel().
The return value of the kmeans_lloyd function is a std::tuple<std::vector<std::array<T, N>>, std::vector<uint32_t>> where the first element of the tuple is the cluster centroids (means) and the second element is a vector of indices that correspond to each of the input data elements. The indices returned in the second element of the tuple are cluster labels that map each corresponding element of the input data to a centroid in the first element of the tuple.
Printing the contents of the tuple for the example gives the following output:
Means:
(1200,1200)
(1.66667,1.66667)
Cluster labels:
Point: (1,1) (2,2) (1200,1200) (2,2)
Label: 1 1 0 1
We can see from the output that the means are at (1200, 1200) and (1.66667, 1.66667). The cluster labels show that the third data point is the only member of the first cluster. The first, second and fourth data points are members of the second cluster. The code used for this example is available in src/example/main.cpp.
For tests and benchmarks DKM uses a standard CMake out-of-tree build model.
To make everything:
mkdir build
cd build
cmake .. && make
To build only the tests run make dkm_tests instead of make. To build only the benchmarks run make dkm_bench.
The tests can be run using the make test command or executing ./dkm_tests in the build directory, and the benchmarks can likewise be run with ./dkm_bench.
When building on Windows you may encounter build errors if OpenCV is not on the system PATH. In that case you will need to supply the path to OpenCV to CMake directly, e.g. -DOpenCV_DIR=D:\opencv\build.
The following compilers are officially supported on Linux and tested via Travis:
GCC/Clang versions prior to the above are intentionally unsupported due to poor C++11 support. Other versions between or after the supported versions should work: if they don't, please create a bug report or pull request. Microsoft VC++ 12.0+ (Visual Studio 2013 or later) is intended to be supported, and CI is currently running against VC++ 17 (MSVS 2022).
Selected from shared topics, language and repository description—not editorial ratings.
sferes2 /
A lightweight, generic C++11 framework for evolutionary computation
56/100 healtheggs-cpp /
Eggs.Variant is a C++11/14/17 generic, type-safe, discriminated union.
68/100 healthjpmorganchase /
A modern C++11 library that provides a number unique capabilities, idiomatic blocks and wrappers which are generic, flexible, compose-able and can be used in many generic contexts for development of both applications and system level components
PhongPham101190 /
MEGA SDK - Client Access Engine Coverity Scan Build Status MEGA --- The Privacy Company --- is a Secure Cloud Storage provider that protects your data thanks to end-to-end encryption. We call it User Controlled Encryption, or UCE, and all our clients automatically manage it. All files stored on MEGA are encrypted. All data transfers from and to MEGA are encrypted. And while most cloud storage providers can and do claim the same, MEGA is different – unlike the industry norm where the cloud storage provider holds the decryption key, with MEGA, you control the encryption, you hold the keys, and you decide who you grant or deny access to your files. This SDK brings you all the power of our client applications and let you create your own or analyze the security of our products. Are you ready to start? Please continue reading. SDK Contents In this SDK, you can find our low level SDK, that was already released few months after the MEGA launch, a new intermediate layer to make it easier to use and to bind with other programming languages, and example apps for all our currently supported platforms (Windows, Linux, OSX, Android, iOS and Windows Phone). In the examples folder you can find example apps using: The low level SDK: megacli (a powerful command line tool that allows to use all SDK features) megasimplesync (a command line tool that allows to use the synchronization engine) The intermediate layer: An example app for Visual Studio in examples/win32 An example app for Android (using Java bindings based on SWIG) in examples/android An example app for iOS (using Objective-C bindings) in examples/iOS An example app for Windows Phone (using Windows Phone bindings) in examples/wp8 Building If you plan to develop an app using this SDK, please use the stable branch or the last released tarball. The master branch is continuously evolving, could be unstable and could change very often. For platforms with Autotools, the generic way to build and install it is: sh autogen.sh ./configure make sudo make install That compilation will include the examples using our low level SDK (megacli and megasimplesync) You also have specific build instructions for OSX (doc/OSX.txt) and FreeBSD (doc/FreeBSD.txt) and a build script to automatically download and build the SDK along with all its dependencies (contrib/build_sdk.sh) For other platforms, or if you want to see how to use the new intermediate layer, the easiest way is to get a smooth start is to build one of the examples in subfolders of the examples folder. All these folders contains a README.md file with information about how to get the project up and running, including the installation of all required dependencies. Usage The low level SDK doesn't have inline documentation yet. If you want to use it, please check one of our example apps (examples/megacli, examples/megasimplesync). The new intermediate layer has been documented using Doxygen. The only public header that you need to include to use is include/megaapi.h. You can read the documentation in that header file, or download the same documentation in HTML format from this link: https://mega.co.nz/#!c5FzhBJL!HUVjsOJTylwkmXPZ0AxT66Wuu4YvZInyHbWGYgvTHt4 Additional info Platform Dependencies Dependencies are different for each platform because the SDK uses generic interfaces to get some features and they have different implentations: Network (cURL with OpenSSL/c-ares or WinHTTP) Filesystem access (Posix or Win32) Graphics management (FreeImage, QT or iOS frameworks) Database (SQLite or Berkeley DB) Threads/mutexes (Win32, pthread, QT threads, or C++11) POSIX (Linux/Darwin/BSD/OSX ...) Install the following development packages, if available, or download and compile their respective sources (package names are for Debian and RedHat derivatives, respectively): cURL (libcurl4-openssl-dev, libcurl-devel), compiled with --enable-ssl c-ares (libc-ares-dev, libcares-devel, c-ares-devel) OpenSSL (libssl-dev, openssl-devel) Crypto++ (libcrypto++-dev, libcryptopp-devel) zlib (zlib1g-dev, zlib-devel) SQLite (libsqlite3-dev, sqlite-devel) or configure --without-sqlite FreeImage (libfreeimage-dev, freeimage-devel) or configure --without-freeimage pthread Optional dependency: Sodium (libsodium-dev, libsodium-devel), configure --with-sodium Filesystem event monitoring: The provided filesystem layer implements the Linux inotify and the MacOS fsevents interfaces. To build the reference megacli example, you may also need to install: GNU Readline (libreadline-dev, readline-devel) For Android, we provide an additional implementation of the graphics subsystem using Android libraries. For iOS, we provide an additional implementation of the graphics subsystem using Objective C frameworks. Windows To build the client access engine under Windows, you'll need the following: A Windows-native C++ development environment (e.g. MinGW or Visual Studio) Crypto++ zlib (until WinHTTP learns how to deal with Content-Encoding: gzip) SQLite or configure --without-sqlite FreeImage or configure --without-freeimage pthreads (MinGW) Optional dependency: Sodium or configure --with-sodium To build the reference megacli.exe example, you will also need to procure development packages (at least headers and .lib/.a libraries) of: GNU Readline/Termcap Folder syncing In this version, the sync functionality is limited in scope and functionality: There is no locking between clients accessing the same remote folder. Concurrent creation of identically named files and folders can result in server-side dupes. Syncing between clients with differing filesystem naming semantics can lead to loss of data, e.g. when syncing a folder containing ABC.TXT and abc.txt with a Windows client. On POSIX platforms, filenames are assumed to be encoded in UTF-8. Invalid byte sequences can lead to undefined behaviour. Local filesystem items must not be exposed to the sync subsystem more than once. Any dupes, whether by nesting syncs or through filesystem links, will lead to unexpected results and loss of data. No in-place versioning. Deleted remote files can be found in //bin/SyncDebris (only when syncing to the logged in account's own cloud drive - there is no SyncDebris facility on syncs to inbound shares), deleted local files in a sync-specific hidden debris folder located in the local sync's root folder. No delta writes. Changed files are always overwritten as a whole, which means that it is not a good idea to sync e.g. live database tables. No direct peer-to-peer syncing. Even two machines in the same local subnet will still sync via the remote storage infrastructure. No support for unidirectional syncing (backup-only, restore-only). Syncing to an inbound share requires it to have full access rights. megacli on Windows The megacli example is currently not handling console Unicode input/output correctly if run in cmd.exe. Filename caveats: Please prefix all paths with \\?\ to avoid the following issues: The MAX_PATH (260 character) length limitation, which would make it impossible to access files in deep directory structures Prohibited filenames (con/prn/aux/clock$/nul/com1...com9/lpt1...lpt9). Such files and folders will still be inaccessible through e.g. Explorer! Also, disable automatic short name generation to eliminate the risk of clashes with existing short names.
48/100 healthjhadida /
ndArray: single-header generic n-dimensional array class using C++11
56/100 healthverri /
Header-only, generic C++11 implementation of a standard genetic algorithm
36/100 health