Replies: 2 comments 3 replies
-
|
@MagusMachinae @light-matters here are some thoughts on the API that would make your project in #270 much easier! Let me know what you think. |
Beta Was this translation helpful? Give feedback.
-
|
Great, I'll have a look soon! |
Beta Was this translation helpful? Give feedback.
-
|
Can't say that I follow everything yet (are sym:and, sym:or etc. already implemented?) but I think using the existing categories of mathematics would make a lot of sense. As well as being appealing in a purity sense, I think it's inevitable that this is where you would end up in the end anyways if you keep trying to abstract everything. So going there consciously in advance allows you to plan for any potential performance hits and really frees the developer to use their existing knowledge (about maths) rather than try and learn your new language and rules.The points about higher level combinators similarly ring true and would be very elegant as well as practical. If I can create new abstract types by pinning terms like associative, commutative etc. to them then the Dirac algebra could be written overnight. |
Beta Was this translation helpful? Give feedback.
-
|
Another note here from GJS... |
Beta Was this translation helpful? Give feedback.
-
|
I think an 'operator' type would be key. This usually takes the form of a matrix of course but it would be better not to tie it down too quickly. |
Beta Was this translation helpful? Give feedback.
-
I have been having design twitches the past few weeks. These arrived while thinking about how to efficiently implement
ABSTRACT-UP,ABSTRACT-DOWNand friends.(This is related to the new
symb:and,symb:orandsymb:not, because those new functions operate on ABSTRACT-BOOLEAN instances, which don't currently have any treatment in the simplifier. So how to build an abstract-bool simplifier, abstract-up simplifier etc and share rules?)Note that there is a strong connection between
For the case of abstract complex numbers:
(1) lives in numsymb.scm
(2) is spread across numsymb.scm, rules.scm and other places where toggles for the simplifier live
(3) only works for expressions of abstract complex numbers; it's not currently possible to compile a function of abstract-matrix operations down to some concrete numerical matrix implementation, for example
(4) doesn't exist yet
I think we can tease apart some ideas combined in numsymb.scm and rules.scm, and make it easy for users to write simplifiers for all sorts of abstract types of different generalities.
Many numsymb.scm functions are combining (non-pattern-matching) simplification rules with expression building. For example:
Is actually a combination of these two ideas:
The problem here is that the baked-in simplification rules need to be re-implemented in `rules.scm', which you might not do because of the required duplication. (and the rules in CONJUGATE-RULES are in fact missing in rules.scm.)
Without the rules, you could replace much of numsymb.scm with a form like
And then some association of a subset of all simplification rules to each constructor.
Add to this the observation that many of the rules we care about can be built out of higher-level combinators, like ASSOCIATIVE, COMMUTATIVE, IDEMPOTENT, UNARY-ELIMINATION, CONSTANT-ELIMINATION etc, and you see how it would become easy to define new abstract types. Here is my simplifier for operators, for example:
More on this idea below.
An abstract type (I proclaim!) is defined by
the set of operations that the system should allow between symbolic representations of elements of the type (AND, NOT, OR, IMPLIES, EQUALS etc, for an ABSTRACT-BOOL)
a set of simplification rules that can operate on symbolic instances of the
type, for example: (NOT (NOT (? x))) => (? x), etc etc
metadata on each rule, saying WHEN it should run. (options are at-construction plus many user-defined toggles, like all of the toggles in rules.scm)
Nothing too special yet. But take these observations:
If you have a concrete implementation of your type, you get efficient function compilation for free, since compilation ==
pass symbolic arguments instead of concrete,
run simplifier on resulting expression
call eval on (lambda (a,b,c) )
If you can tell the system how to generate concrete instances of your type, every simplification rule comes with an automatic generative test. (Check that expressions before and after each rule application evaluate to the same thing, given many concrete inputs.)
because many types share operations and simplification rules, we could offer quite a nice API for pre-specifying bundles of rules for the user. Now we are getting into abstract algebra as API.
it is possible to declare very general abstract types like ABSTRACT-SEMIGROUP, ABSTRACT-FIELD etc and have simplifiers for these make sense.
ABSTRACT-SEMIGROUP expressions can only do associative addition:
But I can add more structure by "specializing" this expression into ABSTRACT-RING, ABSTRACT-FIELD, or ABSTRACT-UP, ABSTRACT-MATRIX, which will add more allowed operations AND turn on more simplification rules.
Beta Was this translation helpful? Give feedback.
All reactions