[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] (no subject)
From: |
daly |
Subject: |
[Axiom-developer] (no subject) |
Date: |
Fri, 6 Mar 2015 05:32:15 -0600 |
>> It is vital that we make the strong connection between group theory
>> and Spad completely transparent. People need to have a presentation
>> that makes it easy to move between group theory and Spad.
>
>There is a book, which I like, called 'Visual Group Theory' [Nathen
>Carter, 2009]. This looks at the various ways to start learning about
>group theory: Cayley diagrams, multiplication tables and so on and a
>very graphical way. I think that this combination of looking at a
>subject from multiple viewpoints and in a visual way is very powerful.
>This would be even more powerful if both of these things could be done
>in an interactive way using Axiom.
I ordered a copy of the book.
Have you seen "Visual Complex Analysis" by Tristan Needham?
>Unfortunately the nature of Axiom seems to be against these things.
>First Axiom only defines groups in one way, as permutations, this makes
>sense if we want to make our definition as scalable as possible but it
>does mean that Axiom is not a tool for learning about mathematics.
>Secondly, although Axiom has some graphics, it is clunky and does not
>produce the sort of graphics shown in the book above. It seems to me,
>that for discrete mathematics, a command line interface is very
>unhelpful. What is needed is an interactive graphical interface.
I am working on a new browser-based version of the system
(see bookvol11: Axiom Browser). The long term plan is to merge
hyperdoc and graphics (using Canvas) into a single front-end.
At the moment, the notebook portion works (type an expression,
see the evaluated results) and a portion of the hyperdoc page
set has been converted. I'm searching for technologies that will
make the new interface interesting. WebSockets is one and I am
trying to learn it.
There is a technology called d3.js that looks especially interesting:
https://github.com/mbostock/d3/wiki/Gallery
and I have spent a little time looking at it. It is data driven
so Axiom can feed it data just like it does for the current graphics.
A websocket connection would allow two-way interaction with Axiom.
>I realise that what you are interested in is teaching people about
>Axiom, not teaching people about mathematics (using Axiom). However
>perhaps there is some link between these. Personally I might question if
>concentrating on teaching mathematics using Axiom rather than just
>teaching Axiom might be a more successful approach?
As for "teaching people about mathematics", I have worked with world
class mathematicians and I'm clearly not even 3rd string on that team.
I'm interested in the next generation of computational mathematicians.
It seems to me we're at the birth of this area and that it will
continue to grow. Unfortunately the new computational mathematicians
have a long, difficult, and steep hill to climb. My generation developed
research-level computational mathematics but did not explain how they
reduced these ideas to code. The usual response is to try to develop
yet-another-system from scratch. I have a collection of over 100
attempts. What a waste of time and talent.
When looking at Spad algorithms it does not matter if you are able
to understand the mathematics and are able to program. If you don't
know the "trick" of the algorithm (e.g. bob's magic identity) then
the code is unreadable.
My goal is to make it possible to communicate the ideas. My ideal
goal is to communicate the ideas so clearly that there is an
isomorphism between the presentation and the code. I want to be
able to look at the presentation and be able to clearly see where
the code must be wrong, weak, or lacking. This goes WAY beyond
commenting the code. Better yet would be the ability to develop
the presentation and have the code be written automatically.
I am currently doing Field Programmable Gate Array (FPGA) development.
The tools allow me to develop a circuit diagram and they compile it
into code (VHDL). Why can't we do this in Axiom?
If the next generation cannot understand the code then Axiom will die.
Why write code that will die?
Tim
- [Axiom-developer] (no subject),
daly <=