axiom-math
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-math] Re: [Axiom-mail] Dynamically constructed return types


From: Martin Rubey
Subject: [Axiom-math] Re: [Axiom-mail] Dynamically constructed return types
Date: Mon, 10 Jan 2005 17:53:03 +0100

I just realized that there was a comma in the CC list missing.

Martin Rubey writes:
 > Tim: I  get failures from your idsi adress, I guess...
 > 
 > Dear Marcus,
 > 
 > 
 > I'm not quite sure whether you followed the thread of the same name. I'm not
 > even sure whether all mails I sent were received, so I copy it here:
 >  
 > > I just tried it out, it works. Another reason to use Aldor as future
 > > language. Tim: can you estimate how much of an effort it would be to get
 > > Aldor at least as external compiler going? (Currently, one cannot use 
 > > domains
 > > compiled with the Aldor compiler within Axiom)
 > > 
 > > Here's the proof of concept, using the domain IntegerMod defined in
 > > Aldorug.pdf:
 > > 
 > > FOO: with {f:(n:Integer)->IntegerMod(n) } == add 
 > > {f(n:Integer):IntegerMod(n)
 > > == coerce(10)$IntegerMod(n) }
 > > 
 > > Try it out:
 > > 
 > > lift(f(6)$FOO2)$IntegerMod(6)
 > > 4 @ AldorInteger
 > 
 > So indeed, in Aldor you can do what you want to. In fact, the with part can
 > contain any calculations, too. That is, you could even write
 > 
 >   with {f:(n:Integer)->IntegerMod(hairyfunction(n)) }
 > 
 > which would fit your case exactly, I suspect.
 > 
 > Unfortunately, compiling domains with Aldor and using them in Axiom does not
 > work currently. It did, once. I managed with a lot of help from Mike Dewar,
 > Stephen and Zork to compile functions, as described on
 > 
 > http://page.axiom-developer.org/zope/mathaction/AldorForAxiom
 > 
 > 
 > So really, it is a problem of Axioms language, but only in the sense in that 
 > it
 > is slightly behind Aldor... I think, it's about time to spend some money on
 > this.
 > 
 > Marcus Better writes:
 > 
 >  > After all, when I call my function (returning Any) from the command line
 >  > interface, it correctly decapsulates the Any object, so that I can do
 >  > algebra on the returned value. I am trying to imitate some of this magic 
 > in
 >  > my spad program.
 > 
 > Unfortunately, I did not manage myself. Sorry. I tried to get
 > definingPolynomial working on your result, no success.
 > 
 >  > For this, the caller really only needs to know that the returned value
 >  > belongs to a domain having a certain category, CommutativeRing, or Field,
 >  > say. That should make it possible to do some matrix calculations without
 >  > knowing the exact type of the code. This sounds like it should be simple
 >  > enough?
 > 
 > Yes, but Axiom requires that you know the type...
 > 
 >  > So, how can I declare the function f to return "CommutativeRing"?
 > 
 > With every Category, there is also a Domain containing only the default
 > operations, you get it by appending an (within spad: escaped) ampersand. For
 > example, in algfunc.spad, you have the definition
 > 
 >     rootsOf(p:SparseUnivariatePolynomial $, y:Symbol) ==
 >       (r := retractIfCan(p)@Union($,"failed")) case $ => rootsOf(r::$,y)
 >       rootsOf(p, y)$AlgebraicallyClosedField_&($)
 > 
 > but this is only package calling: use the definition of rootsOf as given in
 > AlgebraicallyClosedField. I don't think you can return something of type
 > AlgebraicallyClosedField_&...
 > 
 >  > In usual statically typed languages like Java I would specify a return 
 > type
 >  > of Ring, which would be an "interface" definition (or abstract base class 
 > in
 >  > C++). Can I do the same thing in Axiom using categories?
 > 
 > I think that the concepts are very similar, but as I said, you cannot compute
 > with categories...
 > 
 > Maybe you can use a type that contains all elements of
 > SimpleAlgebraicExtension? 
 > 
 > Or, if you will stay within one such depending domain as you described, you
 > might be able to split your package into two, such that the first package
 > computes the equation and the second takes it as parameter. Note that the
 > function signatures may depend on the *package* parameters (even in 
 > complicated
 > ways)!
 > 
 > Martin
 > 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]