Skip to content

DISCOntinuous Toolkit for Aquisition of Neighboring Global Optimizations.

Notifications You must be signed in to change notification settings

search-opt-crew/DISCOTANGO

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

95 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

DISCOTANGO

DISCOntinuous Toolkit for Aquisition of Neighboring Global Optimizations. (Don't worry, the acronym doesn't mean anything.)

Interface and Style

We're writing this to expose some cool algorithms to the general public who may wish to write programs in languages that aren't matlab. Hence, LGPL. We're using C because it's straightforward and interops with literally every language. The previous reasoning also explains why we prefer void * to any macro-based parameterized typing, or C++ templates.

To that end, while we appreciate the thoroughness with which libraries like gsl are able to fine-tune their output, accepting 11 parameters as in gsl_siman_solve is a bit much. Like most other C libraries, DISCOTANGO exposes functions and structs. The interface is typically:

int disco_some_fun(disco_fitness,
                   other_args...,
                   disco_options);

As you can see above, we use under_scores, and prefer the disco prefix for all non-static symbols. disco_fitness is a typedef found in typedefs.h. other_args depends upon the specific function called. Note that other_args is not variadic, the ellipses are just for description. disco_options is a struct containing common parameters to function calls, including an RNG, and constructor/destructors for any data. All exported functions should return int, which will be 0 on success, and some standardized error code on failure.

Each exported function should be defined in its own .c and .h file. Naming should be lowercase-with-hyphens. The LGPL notice should be on top of all files; add your name to the Copyright (c) 2015 <names> line on any file you modify.

External Libraries

Use as many as you want! Just put them in the libs directory and add them to the Makefile (talk to Danny if you don't know how). Make sure the licenses aren't screwy.

Testing

We're using a fork of Unity. Use this and test all exported functions as extensively as possible. Check out test for examples.

Hit List

Optimization

In opt. Take a good hard look at gsl, which has a lot of this already implemented and battle-tested.

Algorithms:

  • simulated annealing link
  • simplex (anna) link
  • linear programming
  • genetic programming (danny) link
  • ...

Search

In search.

Algorithms:

  • Boyer-Moore (max)
  • Levenshtein fuzzy matching
  • A*
  • Union-Find
  • ...

CSP

In csp.

Algorithms:

Hardware Operations

We wish 2 achieve massive speed 4 great good.

  • timeout or fixed iteration count
    • requires alg to keep some state somehow
  • Matrix ops: ATLAS & its variants
  • Multi-CPU
  • Multi-process/threads
  • use GPU

Questions: how to add this in a generic way? Will we have to rewrite all our code in a haze of #ifdefs? Hopefully not.

About

DISCOntinuous Toolkit for Aquisition of Neighboring Global Optimizations.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published