oldk1331 wrote: > > > Well, I against tying complexity to types. Types will not > > prevent writing inefficient code. Actually, unnecessary restrictions > > may lead to workarounds which decrease efficiency. > > Having complexity constraint is like axioms in catdef.spad, > and those axioms do not prevent writing wrong code. I think > these restrictions will discourage unoptimal usage and lead > to "the right way".
Using list rarely is "optimal" from point of view of speed. Typical use cases are relativly short lists, say below 100 elements. In many cases one can get faster code by using array, possibly with using integers like pointers. But such array code is messy. In noncritical code O(n) behaviour does not matter, particularly if n is of order 100. So we go for easy coding. I would much more encourage people to use profiler and optimize code which is responsible for most of runtime. This may mean avoiding indexing on lists. But also avoiding linear searches. > > And any extra type distincion means less opportunity to > > share code, so works against generic coding. > > Have you seen my other mail about leftTrim/rightTrim? These > generic functions should have 2 implementations, the default > one is O(n^2) for lists. Do _you_ need fast trimming? IIRC I never used them. But they may be handy someday. Of course if you put them in inner loop your program will be slow. But frequently you have a "workhorse" routine which is relatively simple, but needs some hairy one-time setup. Setup routines may be dog slow, if "workhorse" routine is fast and responsible for most of runtime, then slowness of setup does not matter. > And do you think OneDimensionalArrayAggregate should have > UnaryRecursiveAggregate to promote "generic coding"? No. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.