for n = 2, n^n^n^n returns 65536. for n = 3, javascript thinks its infinity.
i guess BOAT should start using decimal values for n so we can detect this problem.
52 karma · joined May 15, 2016
for n = 2, n^n^n^n returns 65536. for n = 3, javascript thinks its infinity.
i guess BOAT should start using decimal values for n so we can detect this problem.
I think one could execute source code with varying size inputs to get an idea of a function's growth (assuming the function does halt), but I haven't thought about what that entails
PS: maybe I should have named it BOFAT (Big O Formula Analyzer Tool)
The list of big O classes is the following:
var classes = [
define_func("0"),
define_func("1"),
define_func("lg(n)"),
define_func("sqrt(n)"),
define_func("n"),
define_func("n * lg(lg((n)))"),
define_func("n * lg(n)"),
define_func("n * sqrt(n)"),
define_func("n**2"),
define_func("n**3"),
define_func("n**4"),
define_func("2**n"),
define_func("n**n"),
define_func("factorial(n)"),
define_func("2**(2**n)"),
define_func("n**(n**n)"),
];
lg(lg(N)) is very small, for 1e30, the value is
approximately ~6 and at 1e60 it is ~7.6, at which point lg(lg(N)) is pretty much a constant value (or trivial), but yes - it is technically included in the growth rate, but for practical purposes can probably be ignoredIf it's given two functions, it will try to locate their crossover point (if any) using a binary search, as well as compare their growth rates to determine which will eventually grow faster. It might get some wrong (I'm curious which) as it only has a handful of function classes.
The last feature it has is an automated master/muster theorem solver. It's pretty simple - you give it the values of a recurrence relation and it tells you the big O.
Thanks for looking!
yaml was a format I chose because it is easy to write (close to human), but can not express full programming concepts (but yes to some metaprogramming). i did not want the templates to be full powered as they are meant to be able to express relationships between variables, but not much more (especially not side effects). they also support lazy evaluation - statements do not need to be in order. this is closer to a "mathematical language" for me.
the choice for yaml was also based on the premise that if performance becomes an issue, can hopefully move to another language but retain templates (will have to re-implement python's "random" compat, though)
joke2k/faker is python and the data is stored in code (all or most of the random values are in .py files around the codebase), perhaps leading to its slowness.
stympy/faker is ruby and its random values are in yaml files, with some fields defined as ruby functions (those are not supported by plait.py).
can use 'plait -l' and 'plait -ll name' and 'plait -ll name.name' (more info in the README) to get a list of fake fields available.
PS. that's a really cool python tip!
if that function uses an import, you might also need to add an "imports" field, like in this example: https://github.com/plaitpy/plaitpy/blob/master/templates/web...
otherwise, that's a feature that can be added here: https://github.com/plaitpy/plaitpy/blob/master/src/fields.py..., if it works for you (and is added as a flag), i'd be happy to take patches.