[Openmcl-devel] Strange LISP Clozure problems

[Lonnie Cumberland]

Hello Robert,

Thanks for the response and suggestion.

Actually, it not a database as the list grows both in number if
entries as well as the size of each of the two sub-list. It's more of
a collections of changing number theory patterns problem more so than
a database.

I actually have a dynamic lattice in which. The total number of
patterns is initialized to 10,000 and then after the first iteration a
great many of them have been deleted from another function that I
have. From that point and based upon the information in the
"sub-lists" (ie.. the 2 lists within each pattern entry) more patterns
are added back up to the approximate 10,000 value.

The process is then repeated on the next iteration such that
"patterns" that do not meet some criteria are deleted, the sub-lists
of each pattern are updated (appended), and then more patterns are
added.

The process continues until a stopping point and then the final
"surviving" patterns are evaluated for a solution. This process works
easily on a spreadsheet provided that the tests are small, so now it
is time to code it up into a full implementation.

Cheers,
Lonnie

On Fri, Oct 1, 2010 at 12:12 PM, Robert Goldman <rpgoldman at sift.info> wrote:
> On 10/1/10 Oct 1 -11:00 AM, Lonnie Cumberland wrote:
>> Thanks everyone. You have given me some really useful information
>> which should help me to re-organize a bit in my project.
>>
>> It still seems strange since it looks like I will have to use
>> "copy-tree" to manage the lists, and will have to find a clean
>> solution for my problem.
>>
>> I was using a single list approach as I described in the original
>> post, but am not sure how to cleanly implement that given that, if I
>> understand correctly that "replace-if and replace-if-not and rplacd
>> and others" include this same type of shared data approach.
>>
>> I just wanted to have a simple list of the format ((1 (1 2 ....) (2 3
>> ...) 2) ......) and cleanly grow "append" elements to each of the
>> internal lists as my code iterates.
>>
>> Lisp is a great language, but I can see that I have a lot to learn still.
>
> Just a suggestion --- why do you think a list is a good data structure
> for this db, anyway?  If the lists are always the same length, why not
> use a (fixed-length) array, which is more amenable to
> in-place/destructive modification?  And, for that matter, if the first
> element is the key (as it seems to be), then you could get constant time
> access with aref instead of linear time access with nth or find....
>
> Cheers,
> r
>
>>
>> Thanks again for all of the help,
>> Lonnie
>>
>> On Fri, Oct 1, 2010 at 11:49 AM, Jon S. Anthony <j-anthony at comcast.net> wrote:
>>>
>>> Hi,
>>>
>>> I would also suggest looking at copy-tree.  However, I would suggest
>>> even more strongly to reflect on why the general case of "make copy" is
>>> as vague and difficult as the general case of "is equal" and would refer
>>> you to:
>>>
>>> http://www.nhplace.com/kent/PS/EQUAL.html
>>>
>>> for some great elucidation.
>>>
>>>
>>> /Jon
>>>
>>>
>>> On Fri, 2010-10-01 at 09:57 -0400, Lonnie Cumberland wrote:
>>>> Greetings All,
>>>>
>>>> I am working on some code in lisp and basically have 2 lists now after
>>>> originally trying with just one where I had the same problem. (I also
>>>> had a plist version but still get the same problem.)
>>>>
>>>> I make a list for a format of
>>>>
>>>>
>>>> ((1  nil nil 1)
>>>> .
>>>> .
>>>> .
>>>> (n nil nil 1))
>>>>
>>>> call it *db*. I then add some values such that the first "nil" is made
>>>> into a list. [ie.. (1 (2) nil 1) ] and then do this for the whole list
>>>> in *db* with the function below.
>>>>
>>>> (defun add-mod-pres (b)
>>>>       (mapcar
>>>>          #'(lambda (row) (setf  (second row) (nconc (second row) (list
>>>> (mod (first row) b))))) *db*)
>>>> )
>>>>
>>>> The problem comes when I try to make a copy of the *db* and then
>>>> change some value in the "copied" db.
>>>>
>>>> (setf tempdb (copy-list (remove-if-not #'(lambda (row) (equal (first
>>>> (last row)) (list j))) *db*)))
>>>>
>>>> The result I am getting is that things as also being changed in the
>>>> original *db* as well and it look as though there is something going
>>>> on with LISP using pointers instead of actually making a copy.
>>>>
>>>> The basic code problem is to have my list like:
>>>>
>>>> ((1  nil nil 1)
>>>> .
>>>> .
>>>> .
>>>> (n nil nil 1))
>>>>
>>>> and while iterating over some other lists that I have, I grow each
>>>> list like the below example of a single sublist within *db*:
>>>>
>>>> Iteration 1
>>>> (1 (2) (1) 1)
>>>>
>>>> Iteration 2
>>>> (1 (2 1) (1 5) 1)
>>>>
>>>> .
>>>> .
>>>>
>>>> Iteration 10
>>>> (1 (2 1 3 4 5 4 3 2 1 0) (1 5 3 2 4 5 4 4 5 3) 1)
>>>>
>>>> etc....
>>>>
>>>> What I am currently getting is that when I modify the (1 5 .... ) list
>>>> then it also seems to modify the (2 1 .....) list in the *db* and this
>>>> also happens if I modify the (1 5 ....) list in the tempdb which also
>>>> modifies the *db* list.
>>>>
>>>> There seems to be some shared memory in the lists going on and I don't
>>>> know how to stop it.
>>>>
>>>> Could the "lambda" or "mapcar" functions be the problem?
>>>>
>>>> Kind Regards and have a great day,
>>>> Lonnie T. Cumberland
>>>>
>>>> "BTE, bringing people together today to meet the world's energy needs
>>>> of tomorrow......"
>>>>
>>>> < CONFIDENTIALITY NOTICE >
>>>>
>>>> The information contained in this transmission is intended only for
>>>> the person or entity to which it is addressed and may contain
>>>> confidential and/or privileged material. If you are not the intended
>>>> recipient of this information, do not review, retransmit, disclose,
>>>> disseminate, use, or take any action in reliance upon, this
>>>> information. If you received this transmission in error, please
>>>> contact the sender and destroy all printed copies and delete the
>>>> material from all computers.
>>>> _______________________________________________
>>>> Openmcl-devel mailing list
>>>> Openmcl-devel at clozure.com
>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>