On Thu, Jan 19, 2012 at 1:09 PM, Waldek Hebisch wrote: > ... > Bill Page wrote: >> When I see the prefix DoubleFloat and Float in the names of these >> packages I think immediately that something must be wrong with this >> design. DoubleFloat and Float are names of domains. Somehow here the >> programmer expects to make an implicit association with this domains. >> In fact it seems like this must be a post facto extension of these >> domains. Why are these functions on exported by the domains? > > The most of the functions _are_ exported by the domains. But > DoubleFloat and Float are long, code to implement special functions > is long so it makes sense to create separate package. > >> I realize that this is not your original design but most probably >> patterned after the older code in special.spad.pamphlet. Perhaps this >> design had some advantages when it took a long time to re-compile >> Axiom and memory space was limited but it does not seem like that to >> me today. > > My motivation is convenience of humans reading/extending this code. > Too many small pieces make things hard because with small pieces > we need many of them. But too big pieces are also inconvenient. > I am trying to find best split. In particular in those packages > functions (and their implementations) are closely related, while > relations to other parts are weak. >
I agree that convenience is important and that "packaging" related code is one way to achieve this. But in FriCAS we have other (better?) ways. For example we can inherit default code from categories and we have "add" inheritance for domains. It seems to me (although perhaps easier said, than done) that one can bundle related code and reduce code duplication by careful design of categories and domains. As you implied in another thread actually using PACKAGE in FriCAS should mostly be limited to those places where it is essential. >> If there really is some advantage to be gained from having this code >> in a separate package then why not write them in a generic manner >> something like this: >> >> EllipticIntegrals(F:Join(Field, TranscendentalFunctionCategory) ): with >> ellipticRC : (F, F) -> F >> ... >> if F has arbitraryPrecision then -- Float >> ... >> else -- DoubleFloat >> >> if F has ComplexCategory(F) then -- Complex >> ... >> >> Of given the often adhoc seeming design of some other parts of the >> library this might not be quite so straight forward but it seems >> sensible to me to work towards this. >> > > Did you notice that DoubleFloat... package used quite different > method of computation and exports different set of functions > than Float... package? > Yes, that is the reason I used Join(Field, TranscendentalFunctionCategory) since that seemed like the best we could do given the current categorical design. It seems likely to me that the differences in terms of exports between Float, DoubleFloat, Complex Float and Complex DoubleFloat, etc. could be further minimized. But of course the actual method of computation (implementation) must often be determined specifically by the domain. So I would rather this be tied directly to the domain rather than separated in a package. > ... >> >> I don't much like looking at ADDM_BODY. It seems to me that very >> little is gained by factoring it out. >> > > You mean you prefer to keep two copies? > In this case, yes. >... But you missed the point that > real versions and complex ones sometimes use exactly the > same code, sometimes need different code. AFAICS "generic" > version would need more packages (splitting code in IMHO > unnatural ways) and would be not more generic than > current one. > Yes I basically agree with you. That is the reason why I think the best approach is a more fundamental re-design of the domains and categories. Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to fricas-devel@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
