--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/a1ce47b2-9dab-4b33-b50b-557bfef7e331n%40googlegroups.com.
I'm no expert on algebras, but I think the way to work on this is not to think "what Racket constructs are close that I might coopt to express what I want?" but instead to think "what do I want my programs to look like" and then design the language from there, reusing libraries as they seem helpful or designing new ones that do what you want. Racket's language-implementation facilities are pretty powerful (of course, if there is nothing like what you end up needing, there will still be actual programming to do ;).
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CABefVgwbdetq%2BWBa4h6MPLt1XxnhFQSiOACPC46xsx6cVA9imQ%40mail.gmail.com.
Den ons. 20. jan. 2021 kl. 08.43 skrev Stuart Hungerford <stuart.h...@gmail.com>:On Wednesday, 20 January 2021 at 12:34:59 UTC+11 Robby Findler wrote:I'm no expert on algebras, but I think the way to work on this is not to think "what Racket constructs are close that I might coopt to express what I want?" but instead to think "what do I want my programs to look like" and then design the language from there, reusing libraries as they seem helpful or designing new ones that do what you want. Racket's language-implementation facilities are pretty powerful (of course, if there is nothing like what you end up needing, there will still be actual programming to do ;).Thanks Robby -- that's a very interesting way to look at library design that seems to make particular sense in the Racket environment.An example of such an approach is racket-cas, a simple general purpose cas, which
represents expressions as s-expression.
The polynomial 4x^2 + 3 is represented as '(+ 3 (* 4 (expt x 2))) internally.
The expressions are manipulated through pattern matching. Instead of
using the standard `match`, I wanted my own version `math-match`.
The idea is that `math-match` introduces the following conventions in patterns:
Depending on what you're trying to accomplish, you may find the relation/composition module (which I authored) to be of interest. It doesn't model algebraic structures explicitly but uses them to generalize common composition operators like + (as a group), and .. (as a monoid). It also provides derived functions like power.If this is the kind of thing you're trying to do, also take a look at generic interfaces (used in the above library) which resemble typeclasses, and which could be used to define monoids, groups, and so on as interfaces, which particular Racket types could implement.There's also the Algebraic Racket library which I believe uses classes and objects rather than generic interfaces, and has a lot of other algebraic goodies as far as I can tell.
On Thursday, 21 January 2021 at 10:22:45 UTC+11 Jens Axel Søgaard wrote:
> Back to your project - what is the goal of the project?> Making something like GAP perhaps?> Do you want your users to supply types - or do you want to go a more dynamic route?My project is really aimed at supporting self-directed learning of concepts from abstract algebra.
I was taught many years ago that to really understand something to try implementing it in a high level language.
That will soon expose any hidden assumptions or misunderstandings.
That's a very interesting project. You are so to speak optimizing for readability.
I immediately get a vision of a SICM-like book, but for algebra instead of classical mechanics.
Racket will be a good choice, since macros give you the possibility
of experimenting with suitable, easily understood syntax.
A tricky choice is to be made: how are the concepts going to be represented
as Racket values. Normal structs does not allow multiple inheritance.
Looking at a diagram such as the one below, raises the question whether the
relationship between the various concepts are to be modelled explicitly or implicitly.
Maybe some kind of interface for each concept is needed?
Link to SICM in case you haven't seen it already.
https://mitpress.mit.edu/books/structure-and-interpretation-classical-mechanics
Note that the authors of SICM wrote a CAS in Scheme that is used in the book.
My project is really aimed at supporting self-directed learning of concepts from abstract algebra.
I was taught many years ago that to really understand something to try implementing it in a high level language.
That will soon expose any hidden assumptions or misunderstandings.An early attempt (in Rust) is at: https://gitlab.com/ornamentist/un-algebraBy using the Rust trait system (and later Haskell typeclasses) I could create structure traits/typeclasses that don't clash with the builtin numeric types or with the larger more production oriented libraries in those languages in the same general area of math.Once I added generative testing of the structure axioms I could experiment with, e.g. finite fields and ensure all the relevant axioms and laws were (at least probabilistically) met.
Den tor. 21. jan. 2021 kl. 05.06 skrev Stuart Hungerford <stuart.h...@gmail.com>:
[...]
By using the Rust trait system (and later Haskell typeclasses) I could create structure traits/typeclasses that don't clash with the builtin numeric types or with the larger more production oriented libraries in those languages in the same general area of math.Once I added generative testing of the structure axioms I could experiment with, e.g. finite fields and ensure all the relevant axioms and laws were (at least probabilistically) met.
Not knowing Rust nor traits, I have amused myself writing a very simple version of traits.
#lang racket
(require (for-syntax syntax/parse racket/syntax))
;;;
;;; TRAITS
;;;