Waldek Hebisch <[email protected]> writes: | Gabriel Dos Reis wrote: | > | > For has-tests cases, the complexity can be bad in practice. There is | > one constructor in the AXIOM algebra that takes a looong time, more time | > to compile that others; most of the time is spent in simplifying | > conditionals while building the predicate vector and generating codes to | > set up the 'right' functions to call. Yet, definition of the | > constructor is very simple (in apparance.) | | IIRC compilation of ExponentialExpansion used to spend a lot | of time in simplifying conditionals.
Indeed. | In FriCAS this is no longer a problem: | | - results of knownInfo are cached, which cuts number of | tests On several occasions I considered caching results of category instantiations; each time, I decided to back out because when I have SomeCategory(X,Y,Z), the expressions X, Y, Z (usually symbols) may have properties depending on the environments, so I would have to cache each argument with its known set of properties... That is probably not too bad in practice but that wasn't appealing at the time. | - JoinInner and few other routnes involved in "atomic" tests | are much faster than before | - there was misguided optimization in knownInfo, introduced | in 2003. I do not know if it made sense then, but now | it helped a little (if any) on average, but lead to very | bad worst case behaviour. which optimization do you have in mind? | Of course, more "interesting" conditions (and such tend | to pop up when writing generic code) are likely to find | weak spot in current FriCAS version. -- Gaby -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
