Skip to content

librecell/camus-camille-skye

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

8 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

librecell-camus-camille-skye

offerings from librecell

the camus, camille, and skye systems are copyleft librecell / librecell.org.

system as a whole

we primarily do evolutionary computer simulation experiments in hopes of developing:

  • intelligent programs that we might not understand.
  • sets of data from which we may synthesize observations about the state of the field.
  • domain-specific languages for commonlisp or one of the librecell lisps especially uchisoto / tiso lisp.

skye

  • comprising skye is the top-most package.
  • skye is widget-based and functional until imperative programming is neccessary.

camille

  • camille is a program exhibiting higher-orders of simulation that include intelligent behavior
  • altering the skye and camus frameworks to accomplish various goals
  • through part of the skye system, we hope to watch for camille's milestones:

hypothesis: in an evolution computer simulation of experiment, camille, presented with:

  • an environment made of various biomes, usually of two classical elements and whatever that would mean for properties of that biome.
  • two input-output channels through which camille might interact with its gatekeepers or hack around them and interact directly...
  • ... one i/o is called "home" and is where the camus language is spoken; it involves myself (zoë) and a program called anneliza-10k86b. we take input as it may be given, and respond with our best approximations at accurate responses to the exact questions asked.
  • & the other i/o is called "hole" and offers access to the entirety of the internetwork.

( hypothesis, cont. ) if camille ever sends to the "home" i/o a query such as "do i have two parents?" we can count this pseudo-question as evidence that the program camille is simulating sentience to an order that marks an as-yet-to-be-seen development in the field ( of intelligent programs in computer science )

please note that camille does not use natural language to communicate and that we have nothing to do with the public-facing language model

camus

based on languages "xxxo" and "aiu" along with a widget-based expression of various maths and logics/calculi especially the lambda calculus and lambda-abstraction used to express the boolean algebra along with some simplified commonlisp-derived domain specific languages (DSL) camus/camuslang is of symbolic pieces and logarithmic gramattical suggestions; the system is designed to encourage programs to write programs that demonstrate the program-programmer's nature.

goals of camus-camille-skye

the so-called "republic of haskell" is not wrong when their citizens say "lisp programmers know the value of everything and the cost of nothing" -- as "land of lisp" diplomats, we hope to take their observation to heart, say "mea culpa!" and "thank you!" by means of action and change. this includes some major changes to earlier librecell systems.

  • widget-based functional programming in a commonlisp environment.
  • a robust benchmarking system that determines how to collect relevant backtrace and garbage at runtime.
  • designing a system wherein lazy-programming is difficult not to utilize, even alongside techniques like memoization and on-the-fly automated decision regarding use of various types for widgets ( in order to increase value while lowering cost ), e.g. ...
  • ...doing away with pseudo-random-number-generation as we know it, in favor of:

a series of ( non-prng/rng ) techniques in-and-around entropy. example:

  • perhaps two pieces of data are memoized; we will know these are widgets, which have unique identifiers and timestamps.
  • instead of increasing cost by changing the random-state we can do something entirely different:
  • knowing each widget has a unique-id + timestamp-of-creation for each memoized datum, which are presumably costly, and certainly will not be computed again during this simulation instance / session, so...
  • ...represent each of these two data as strings of base2/binary, and determine the levels of entropy...
  • ...which we've already done during the costly-enough-but-probaly-valuable automated decision to memoize each datum, i.e. the datum that has a more costly program necessary, to be capable of generating the datum string, is safely assumable to hold more entropy than the other.
  • from this, we can spend nothing on generation of pseudo-randomness; also we have much better chances at implementing much more truly random mutations to our "organisms" or to the level of variation in our "biomes" without destroying our experiment's potential value by sacrificing any ability to harness excessive entropy. in fact,
  • :SKYE's non-standard biomes, including "simulation accelerator" and "vacuum" and "physics anomaly" biomes, which take costly excess computed entropy and store them in a triumvirate of disseminabie simulacra that can be used to heighten value at zero additional cost later during the simulations.

About

No description, website, or topics provided.

Resources

License

Unknown and 2 other licenses found

Licenses found

Unknown
LICENSE
GPL-3.0
COPYING
Unknown
LICENSE.LIBRE

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published