winterize-users team mailing list archive
-
winterize-users team
-
Mailing list archive
-
Message #00010
Re: Architecture is moving forward
Hi- not sure if this is the way you want to entertain comments, let me
know if there's a better way.
The A(n) = B(m) + 1 primitive is a great example building block of
problems that could be computed in Winter more efficiently than
otherwise. Thinking about a specific implementation for A, B, and
respective generations m, n upon which some kind of result is computed
(+1), this could be a pool of actors { A, B, C, ... } executing
pairwise computations where the question is for the effective average
result. Say, e.g., your actors { A, B, C, ... } would be different
computers with same hardware configuration and OS, and they interact
through one another by playing different chess programs or algorithms
each. A Winter program could instruct the actors doing so, and
calculate effective win/loss ratings. Winning against another actor who
has one more often in the past will give a higher score as opposed to
winning against an actor who has only lost so far. All calculations are
done pairwise, at any time, and there is no requirement for a common or
synchronized state of the overall system. Of course you can request a
readout of scores from all actors at any given time, and you'll get a
more precise answer the more generations have passed. In this very
specific example, the result would be a fairly representative score of
strength for the various programs. Winter would help coding the entire
process.
Of course this is an extreme example with very highly structured
actors; I'm sure there are better ones where the A, B, ... are
primitives but still something meanigfull can be calculated.
JK
On Fri, 7 Feb 2014 10:19:15 -0500, Max Polk wrote:
I've been away helping webplatform.org with a conversion of JavaScript
reference information, and that effort reached a milestone, read about
it at:
http://blog.webplatform.org/
Back to Winterize. Note that the final name will be "Winter" and if
launchpad.net won't let me have a project with that name, I'll move to
github or somewhere else. From now on, I'll call it by its true name
"Winter."
I've come up with some pretty solid architectural ideas about solving
the problem of resource mutual resource consistency. By resource I
mean the value of an URL hosted by the Winter server, or any other URL
on the WWW. A core feature of Winter is the ability for a resource to
be a function. You can state that the value of a resource is a
function performed against the value of another resource.
So then if resource A is declared to be resource B + 1, and resource B
is declared to be resource A + 1, what would that even mean, and how
would you handle it? A friend pointed out that what you are really
saying A(n) = B(n-1) + 1, and B(n) = A(n-1) + 1. You declare that a
value is a function applied to the other resource's previous value.
If the other resource is an external value, you declare that a value
is a function applied to that external resource's previous value (a
point in time).
For this to work, calculations must progress in rounds. Each round of
values depends on the previous round's values. Progress through all
calculations as one "generation" and finish. Then repeat. While each
group of related resources can independently progress through
generations independently, perhaps for simplicity all resources
progress on the same generation.
So if A = B + 1, and B = A + 1, we have initial values to start it all
off, let's say, 0 and 0. Then:
Generation 0:
A=0, B=0 (fixed intiial values)
Generation 1:
A=1, B=1
Generation 2:
A=2, B=2
At no point can a resource assert its current generation's value is
equal to another resource's current generation's value. The other
external resource is out of date possibly as soon as you obtain it's
value. The other internal resource is out of date as soon as you
complete that generation. A and B will progress, as fast as possible,
unending. While this example is trivial and pointless, it will be
useful to declare A to be the next prime number, and B to be the last
calculated value. Winter can then calculate prime numbers as fast as
possible forever.
One thing to remember is that resources on the WWW across domains are
impossible to be correct. As soon as you obtain your bank account
value, it's out of date the moment your eyes see it in the web
browser. Couple that with the fact that one can never obtain two
resources having mutually consistent values at the same time. You can
only do an HTTP GET of one resource, then another HTTP GET of another
resource.
To save the day, Winter will always return the previous generation's
values for all resources while processing a new round of values.
Users obtaining A and then B during the round of processing of a new
generation of their values can obtain mutually consistent values for A
and B, risking the change that the round of processing completes after
obtaining A and before obtaining B. So it may be worth being able to
ask for A, and with the response you have an http response header that
declares what generation number it represents. Then you can request B
and ask for that same generation. You then have mutually consistent
values of A and B even though http as a protocol won't let you obtain
both in one request.
While no code has been pumped out into the revision control system,
architecture is moving forward.
--
Mailing list: https://launchpad.net/~winterize-users
Post to : winterize-users@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~winterize-users
More help : https://help.launchpad.net/ListHelp
Follow ups
References