Re: [Axiom-developer] A student comment

[C Y]

--- Bill Page <address@hidden> wrote:

> On 9/1/07, Alasdair McAndrew wrote:
> > As some of you may know, this semester I am using Axiom in a
> > cryptography subject.  I have asked my students to comment briefly
> > on what they like/dislike about it.  Some like it, and find it
> > "intuitive", while others dislike it.
> 
> As a "first impression" I think this feedback is quite valuable. I
> wonder how these same students will feel at the end of a semester of
> using Axiom. Do you plan to ask them again? I would also like to know
> exactly what aspects of Axiom some students found "intuitive".

Actually I find the fact that some students found it intuitive to be
intriguing - I would not have expected any of them to react in that
fashion.

> I think the decision to
> distinguish commands by this peculiar syntactic convention was
> probably already "out of fashion" even at the time Axiom was
> originally implemented. Plus this makes it difficult to extend the
> user interface in a natural manner simply by writing new library
> code.

If I understand correctly, the objection is to the use of the ")"
prefix when processing system commands?

I think the current interpreter will need to be re-thought regardless
in light of the Bnatural papers and ideas - perhaps this convention
should also be re-examined at that time.  In any case, there should be
documented reasons for its use if any are found or deduced.

> Certainly there are some reasonable alternatives that would be more
> nature and extensible.

It is worth looking into.

> It seems quite fair to claim that during most of Axiom's "nine lives"
> user interface was given lower priority than the implementation of
> mathematical algorithms.

Certainly.  That's a natural consequence of focusing the development
resources on the core mathematical system.  User interaction
considerations are non-trivial.

> (The work that NAG did on the Techexplorer
> interface for Windows was an exception, unfortunately that was lost
> when the commercial version died.) Even the output of the Spad
> library compiler demonstrates this apparent "lack of interest" in
> user interface. As a research platform I suppose this made a certain
> kind of sense but for the use you are trying to make of Axiom, I 
> think it could be a problem.

I would expect that it is.  The intersection between strict
mathematical correctness and "user friendliness" is not well mapped as
yet, and doing so will be an ongoing challenge.  Since (IMHO) the
strong foundation must be present before the question can even be
considered seriously, Axiom's original focus was quite logical.

> Thanks. I would like to know more. But apparently some people here
> really do not care to know. :-(

I think it's more of a case that they already know, but are not able to
shift resources from current efforts to attempt to address that
shortcoming at this time (which is not easy to address.)

> The suggestion to turn these comments
> back on the student surely can not be of much use since it seems
> rather unlikely to me that cryptography students will be motivated to
> solve these sort problems with the Axiom user interface when there
> are so many other alternatives available.

If an alternate environment already solves the problem, why not use it?
 Axiom brings something new to the table in the form of potentially
having much higher degrees of mathematical rigor, but this comes at a
price in terms of development time.  The solution to this particular
problem in the Axiom environment requires some prerequisites that are
themselves non-trivial and time consuming.  In my opinion, to map
concretely and usefully the strong correctness intended for the core of
Axiom to a "working" environment you need at least:

1.  The strong "foundation" containing the necessary mathematical
knowledge and algorithms to solve the problems in the target problem
space (cryptography, in this case.)

2.  User interface tools, toolkits, and interaction environments
sufficiently "friendly" (whatever that means) to provide the expected
aids to problem solving.

3.  Solid knowledge of the conventions used in the problem space and
how to express those conventions in terms of Axiom's foundations.

This has the consequence of restricting the "casual" user to previously
defined mathematical libraries for hard core reliable solutions, but
that's as it should be since rigorous, trustworthy and probably correct
solutions to most problems are not possible in a casual context. (It
might be possible in some cases for Axiom to generate "rigorous" code
for library inclusion using Bnatural input and environmental knowledge,
but that will need looking into.) "Unspoken assumptions" made in a
field must be made explicit, so when and if they break down the
breakage is clear and not "glossed over" by insufficiently rigorous
symbol manipulation.

Of the three stages above, we are still a long way from having #1 or
#2.  Once we do have those #3 will hopefully be possible using
collaborations between specialists in the various fields and
mathematicians.  One example that has been mentioned in the past is the
possibility of implementing something like distributions (a.k.a
generalized functions) for the treatment of Dirac Deltas in advanced
physics.  There are undoubtedly others, and with hard work that's where
Axiom will someday begin to show its real strength.

Cheers,
CY


      
____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel 
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7