Stats

  • Locked Locked
  • Replies 3
  • Subscribers 142
  • Views 13786
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

conc functions

eDave

I'm using Allegro Skill but I think this might be a better place to post this question.

In the following code I would expect y to be unchanged and remain at (3 4). However it becomes (3 4 5 6). Is this expected behavior?

x = tconc(nil 1)

y = list(3 4)

lconc(x y)

lconc(x list(5 6)) 

  • Yes, this is expected behaviour. lconc is aiming to be as efficient as possible and so does not copy the second argument - it is documented as being destructive. 

    Andrew 

  • Thanks Andrew. The documentation is not clear on that.

    Would you expect lconc using a copy on the second list to still be markedy more efficient than append?

  • It's hard to compare. The expense of append is with copying the first list (the second list is not copied and so is just a matter of setting the cdr of the last element of the copy of the first list to point to the second list). With lconc, getting to the end of the first list is cheap, but having to copy the second list would be more expensive than just having to iterate to the end of the second list (which is what lconc normally has to do to preserve the integrity of the lconc structure).

    So the efficiency depends on the relative lengths of the two lists.

    Andrew 

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.