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.

Reply via email to