i've started code elsewhere that is unlikely to be completed. right now i'm [doing things I try not to do] away from other code. I wonder if following the ideas below is workable or if they make some unrealistic assumption. On Sat, Feb 12, 2022, 3:02 PM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:

here's the last draft doc that reached github:

# for designing an interface of system simulation

# a simple system where some property is a function of time.

# goal 1: user has access to a state containing a number, and can produce # another state based on a time change from the first # number = constant * time

class NumberAgent(TimeShiftable): def __init__(self, prev_states : List[Tuple[TimePoint, float]] = [], avg_changes_per_second = 0.25): .. Okay, i'm thinking here that normalising an interface for functions of probability is really important for things guided by simple rules of chance. I don't know much about probability at this stage of my life. I have some random variable, and I have records of how it's behaved in the past. I want to be able to sample its possible state after a given duration in the future (or the past) from a known state. Y'know, I'm sure that's been well studied and solved, but maybe it's cognitively simplest to just procedurally write down how something like that behaves, and brute force it, for now. Additionally, that approach would let agents be programmed intuitively, rather than in a new language based on probability primitives. It would likely later be possible to translate to probability primitives by sending tracer values through: numbers that track their mathematical operations. Doing that means using a pure conditional function rather than "if" block control flow primitives.

Futzing around thinking of distribution trees. class UniformValue: min: float max: float UniformValue(1, 2) + UniformValue(0, 4) Now we're back in probability again. If we use uniform distributions, then summing them will sum their range, but the output won't be uniform any more ... it'll be uh ... (websearches ..) an Irwin-Hall distribution? regardless it's a function that can be looked up. So say we have an Irwin-Hall distribution from 0 to 6 with specific PDF and CDF. And suddenly we know that its value is 3. UniformValue(1, 2) + UniformValue(0, 4) == 3 I don't know probability, but there must be some way to give new distributions here. Basically the two values completely depend on each other. I guess it simplifies to: UniformValue(1,2) + Dependent_Value == 3 . Is this a ridiculous avenue? Or is this easily generalisable?

Writing a distribution algebra tracer or such sounds hard, but it doesn't have to be, since this is only a proof of concept. We could restrict ourselves entirely to summation of uniform distributions, for example. This approach seems workable, so maybe I can add a bullet to that draft doc around it.

Let's see if I can simplify these ideas. Do they make a good bullet point to later pursue implementing? Parts - tracking simulated agents is transformable to tracking trees of probability distributions, choice processes, or simulation processes - in a simple example, if everything is a sum of uniform distributions, a possible state can be found by solving for the widest distribution in an equation, based on sampling the others. this is simple subtraction, but likely produces an incorrect output distribution and should be treated as a heuristic. so each agent has a function that calculates state at a time point I came up with a class of agent where state is decided based on discrete difference from previous state, using uniform distributions the proposal is to make a uniform distribution class that produces trees when summed. these trees can then sample their state given constraints on some of their operands. it's still big for a bullet point, but sounds meaningful to pursue.

trying to stabilise this idea part a big component of simulating time is considering outcome and causality trees. a simple useful outcome tree might be sums of uniform distributions. an example could possibly handle them with a heuristic class that can solve them given known values for some of them. however, real probability transformation to brownian-like distributions provides the correct answer here.

attempt to summarise again - it seems fun to make value tracers for uniform sums. this might involve three classes: uniform distributions, scalars, and sums. - example heuristic tracers could produce a possible value with incorrect distribution - later, real tracers could consider a range of trees and calculate distributions backward from the distribution of sums simplify: - heuristic "+" expression value tracers for uniform distributions could open design options up. all they would do would be to produce a possible sample given known values. - it might not end up being productive to do, but gives an avenue of work. another consideration is brownian distributions.

from 2 days ago: I ended up looking a little into the brownian distribution. It's an equation with a value called D inside a square root and an exponent this morning: i'm looking into implementing the simple uniform distribution tracing idea. i'd like to do it with some generality, but working with my short term memory issues, it's very hard to discern how much generality doesn't expand the problem space too much. right now i'm stashing some tiny work with a class called UniformDistributionSum to instead use a class called maybe Expr. the reason for a more general class is partly to relate with introduction of untracked values like ints or ndarrays. Base classes that can be shared across parts help make code workable. I don't actually have the topical working memory at the moment to make something that functions at all, so it's an exploration.

now I spam to handle my inhibitions As a computer programmer, generalisation and reuse is one of my highest design values.

I switched to python some years ago because: - it is used by mainstream open source ai research and many hobbyists - it has language support to reference, mutate, and recompile its own bytecode while executing it, and has some syntax mutability - it's concise There are downsides to python. Notably it is hard to debug interpreter problems from chip or kernel misbehavior. C is much better in my opinion. Anyway, I've been using python for some time without understanding __new__, which is an important construct. Here's how the manual says __new__ works. It's not complicated. 1. python calls Class.__new__(cls, ...) when Class(...) is called. 2. Unlike all other methods, __new__ is never passed a self object, and always passed a class object, no matter how it is decorated. 3. The return value of __new__ is passed on to __init__, after __new__ returns, if and only if it is an object of the class. Then it is returned to the user. 4. New objects can be constructed via super().__new__(cls), to return. This lets one write constructors that for example instantiate a child class selected from arguments and perform other tricks.

Here are pastes of draft base classes. These are design level, not work level. They don't relate to the project and would, in a larger project, go in a dependant library. They are small and simple, and I've at other times made forms of them that I prefer over these. They're intended to be refactorable, changing the concepts around for other uses. Notably, in this implementation there is no way yet to add further methods to "Interpretations". I'm still learning effective uses of __new__. This is the first time I've used it. I made a prototype norm of leaving @staticmethod off of the Interpretation method implementations. This is poor style but saves typing. # OpExpr is prototype base class for expressions class OpExpr: def __init__(self, op, *operands): self.op = op self.children = operands def __getitem__(self, idx): return self.children[idx] def __instancecheck__(self, cls): if issubclass(cls, Interpretation): return cls.test(self) else: return super().__instancecheck__(self, cls) def __add__(left, right): return OpExpr(op.add, left, right) def __radd__(right, left): return self.__add__(left) # Interpretation acts like a function associated with a form, that can either create a form of an existing object, or a new object of the form. # I think of it kind of like a proxy without the proxying implemented yet. class Interpretation: def __new__(cls, obj, *params): if len(params) = 0: try: return cls.form(obj) except: return None else: return cls.new(obj, *params) def new(*params): raise NotImplementedError() def form(obj): raise NotImplementedError() @classmethod def test(cls, obj): try: return cls.form(obj) is not None except: return False # Reordered is an interpretation of an expression that changes operand order def _Reordered(*order): class Reordered(Interpretation): def form(expr): return OpExpr(expr.op, [expr[idx] for idx in order]) Reordered.__name__ += '_' + '_'.join(str(idx) for idx in order) return Reordered Reordered10 = _Reordered(1, 0) # Op is an interpretation of an expression that can just be used to check if it has a given operator, without having to type "." and "==" on my phone with my finger issues. def _Op(op): class Op(Interpretation): def new(*operands): return OpExpr(op, *operands) def form(expr): assert expr.op is op return expr Op.__name__ = op.__name__.title() return Op Add = _Op(op.add) Mul = _Op(op.mul)