Hello, > 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:
I don't. *You* wanted to connect to Axiom. Fine. I want to keep the AC code (mostly) clean from unnecessary #if Axiom conditions. A layer is the best form. > * it is a lot of work to make it work well I don't require that it works well. It should work sufficiently well. > * it won't work really well in the end anyway. Maybe we throw it away in the end. But until then I would like something that I also understand in one year, not just a quick hack. Quick hacks are what has been done previously in Axiom and you see how the code looks like and how many people understand it. > 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. No we don't need to wait. I think that I am right that AC never exports PrimitiveArray. I know that I have Array somewhere, but if that is a problem, it can be switched off in the Axiom version and replaced by something else. It is just a efficiency consideration that made me introduce that signature. To make it simple. Forget about the "extend" if it makes problems. We should then simply implement "ACArray" and "ACPrimitiveArray" (similar to what is PrimitiveArray now. So they inherit quite a lot of functionality of Array and PrimitiveArray from Axiom, but otherwise behave like Array and PrimitiveArray from LibAldor. We only need to implement the functions we are using in AC. Furthermore, since we cannot use "extend" for Axiom, AC actually also "exports" ACArray to Axiom user. And ACArray(T) comes with functions coerce: % -> Array T coerce: Array T -> % That is simple. > Then output and coercion will work fine. I haven't quite checked it, but I rather intend to implement a stupid TextWriter domain in axal.as so that the << functions as they are now in AC just work without modification. Ooops, simply implementing TextWriter as OutputForm will probably not quite work... :-( Hmmm, but perhaps it will... > As it is now, APrimitiveArray is simply a new type for Axiom, > disjoint from the rest. No problem. >> 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 know you like hacks. ;-) I very much hope that you will be around in a year to explain what you did. >> 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... OK, it seems you want me to write the layer. > I'd suggest to introduce NonNegativeInteger in Aldor. That would kill many > #if's. Wrong. AC combinat currently works without NonNegativeInteger. There is absolutely no reason to introduce it. Even if you like it, it is unnecessary. >> 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? I don't understand why you introduce a dependancy on Axiom that is unnecessary. I've programmed MultinomialTools and not taken it from LibAlgebra, since i cache quite a lot of binomials which makes the computation of binomial(n,k) for n<50 an O(1) operation. That is not done in Axiom and also not in LibAlgebra. And if you want to port IntegerCombinatoricFunctions to LibAldor then do it. You can take MultinomialTools as a start. The problem with Aldor is that it is not free. So I programm the stuff I want, myself. (And by the way, it is much better documented than any of the others. --- I care about documentation.) >> 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. Which I don't like anyway. Aldor/Axiom is not functional, so the constant "empty: %" and the function "empty: () -> %" are two diferent things. The second could have side effects, the first not. If Axiom doesn't understand it than it should be changed or Axiom should be made functional. Until then, I rather like to do as above: export ACArray and coerce: ACArray(T) -> Array(T). > 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: %. And I don't need to. I've just looked at the use of "empty$List(T)" in trunk and found 3 places: 1. structures$SetPartition 2. new$DataStream 3. testStream8 (in test/stream.as) In all 3 cases I would rather replace "empty" by "[]" than introduce an "#if Axiom". So that avoids the problem with extending List. > I'd rather vote for a macro EMPTY as you suggested some days ago. I withdraw that and take the suggestion above. At least for (1.) it should be clearly written why "[]" and not "empty" for the others I don't care since they are not time critical. And if one introduces a variable emptyList: List(L) := []; and uses that variable instead of "empty" in the code of "structures$SetPartition" the code only becomes less efficient by a constant amount of time for creating that list *once*. > 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. I don't argue. Everything should merge anyway. But I would rather start from zero and use things from here and there as they fit instead of building on the Axiom library where one doesn't even know which domain depends on another. The ground domains are too much interrelated still. Suggestion: I modify axal.as in the way I would like to see that layer and you get rid of the "#if Axiom" stuff in axiom-port. Would you allow me to commit to axiom-port? First thing that I'll do... svn mkdir src/axiom-compatibility svn cp src/axal.as.nw src/axiom-compatibility/axal.as.nw together with a few changes to have that new file in the documentation. So you could watch me. By the way, I would rather like that file to live in a separate directory anyway. Ralf ------------------------------------------------------------------------- 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
