Dear Ralf, first, please note that axal.as.nw is simply a hack. At first I thought it would be nice to have such a compatibility layer between libaldor and libaxiom, but meanwhile I think it's a waste of time:
* it is a lot of work to make it work well * it won't work really well in the end anyway. In any case, if you *really* want such a layer, we need to wait until we have "extend", because otherwise Axiom won't be able to use the types as we would like it to be. For example, APrimitiveArray should really just extend PrimitiveArray with the missing functionality. Then output and coercion will work fine. As it is now, APrimitiveArray is simply a new type for Axiom, disjoint from the rest. Ralf Hemmecke <[EMAIL PROTECTED]> writes: > What I thought was that APrimitiveArray should exactly simulate > PrimitiveArray of LibAldor. That would avoid any rewrite (any #if Axiom) in > the code of Aldor-Combinat. Well, PrimitiveArray in axiom is a little more clever then PrimitiveArray in Aldor. Thus I decided to use that functionality. It saved me quite a lot of time. > I also don't really like the macro > > MachineInteger == Integer; The point is that # returns a MachineInteger in Aldor and a NonNegativeInteger in Axiom. (I rather like the Axiom point of view, by the way). However, I cannot exclude the possibility of other functions returning MachineIntegers, which then might not be nonnegative... I'd suggest to introduce NonNegativeInteger in Aldor. That would kill many #if's. > And > MultinomialTools == IntegerCombinatoricFunctions(Integer); > > I don't understand either. I suggest to get rid of MultinomialTools and port IntegerCombinatoricFunctions to libAldor. But hey, that's the only clean macro in axal.as.nw. (Apart from, maybe, Partial and the ExpressionTree stuff) What is it that you don't understand? > can you explain why you have to use > > empty(): % == per empty(); > > in the definition of APrimitiveType instead of simply > > empty: % == per empty(); Of course, for the moment we could do it as you suggest. However, as soon as Peter succeeds with making extend available, that's only the second best solution: Axiom doesn't understand exported constants. Thus, in the Aldor interface, they are translated automatically to void functions. However, when we want to extend Axiom types, we have to follow Axiom's rules, otherwise it won't work, I'd guess. And I'd rather stay consistent. I don't think that you will be able to provide Axiom's List with a constant empty: %. I'd rather vote for a macro EMPTY as you suggested some days ago. In fact, since it doesn't seem to be the case that libaldor and libalgebra become free in the near future, I'd rather port things from libaldor and libalgebra to libaxiom, instead of the other way round. ExpressionTree and Partial are first steps in that direction, I guess. Martin ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Aldor-combinat-devel mailing list Aldor-combinat-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aldor-combinat-devel
