oldk1331 wrote:
>
> I think the correct way is to have 2 domains for lists:
> one potentially with cycle, one guaranteed to not have cycle.
> Adding checks in setrest! should be enough to prevent
> the creation of cyclic lists.
Such check would have to travel to the end of added part
to be effective. I would say that this would slow down
setrest! so much that is would be effectively useless.
It is used either for speed or to create cyclic list,
with cyclic list beeing forbidden and with slow checking
what remains?. You could simply remove 'setrest!' and
get similar effect.
I think it make more sense to have List essentially as
now, saying that it may loop on cycles and does not
check and another domain or package offering operations
that correctly handle cycles. Package may be more
appropriate because once list is verfied to be acyclic
normal List function will do.
To put it differently: it seems that normal typechecking
can not usefuly distinguish between acyclic and cyclic
lists. So having separate types buys as almost nothing,
but has cost due to increased complexity.
> I think over 95% usage of lists doesn't require this "cyclic" feature.
> Having a non cyclic list domain will increase performace.
>
> Also, it's a disaster to have cycles in Tree. Trees with cycles
> are graphs.
Yes. Actually it is a bit tricky to convert such graph made
of nodes and links into more traditional representation.
--
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.
