> > BTW2: If you are worried that [...] is slower than
> > MAKELIST you should rather work on increasing speed
> > of list comprehesion (that is [....]). Current
> > version constructs list in reverse order and then
> > destructively reverses the result.
> It is possible to avoid the NREVERSE call?
> Unless you do it by recursion and risk the stack
> to explode?
Well, for 'new' formally the final NREVERSE is not
needed at all since all nodes have the same value.
In general there is well-know imperative idiom: after
creating next node one updates previous node. Essentially:
new(n, e) ==
e0 := empty()
n = 0 => e0
res := cons(e, e0)
old := res
for i in 2..n repeat
new := cons(e, old)
new := old
As you see the code is longer than version working in
reverse. For long list avoidning second scan should
give small win. For short lists (most important case)
that is more tricky: one needs to make sure that the
code (in particular loop setup) is well optimized
to have any gain. Also, there is tricky balance
between speed and code size: for rarely executed code
the main cost is reading it from RAM and evicting
from cache more useful code. That can negate gains
from faster execution.
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 post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.