MESSAGE
| DATE | 2015-01-23 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [LIU Comp Sci] Algorithms Assignment 1 attempt
|
From owner-learn-outgoing-at-mrbrklyn.com Fri Jan 23 06:23:56 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id C57A716116D; Fri, 23 Jan 2015 06:23:56 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id B6149161174; Fri, 23 Jan 2015 06:23:56 -0500 (EST)
Delivered-To: learn-at-mrbrklyn.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 37B7C16116D
for ; Fri, 23 Jan 2015 06:23:56 -0500 (EST)
Received: from [10.0.0.19] (unknown [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id 1095F17D25
for ; Fri, 23 Jan 2015 06:23:55 -0500 (EST)
Message-ID: <54C22F4B.1030808-at-panix.com>
Date: Fri, 23 Jan 2015 06:23:55 -0500
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: learn-at-mrbrklyn.com
Subject: Re: [LIU Comp Sci] Algorithms Assignment 1 attempt
References: <54C19620.5070706-at-panix.com>
In-Reply-To:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
On 01/22/2015 07:34 PM, Maneesh Kongara wrote:
> Sure thing. I'll post mine on the group soon.
> Thanks,
I was thinking last night, as I was sleeping, that I'm not even happy
with this result. the problem is what happens if you drop a data point
far off the existing data, so that, say, you have an array of 100 and 10
items in the array in positions from 0-10. Then I InsertByPosition,
into spot 61. You have junk between L.a[L.last] and L.a[60] (the 61st
position).
You need to clean all that out so you have to have a third condition
within that function for insertions past last and before the end of the
array.
Also, this whole thing should be rewritten with pointers.
intpt * = L.a; and then do the math like that. It is much cleaner and
professional code.
> Maneesh.
> On Jan 22, 2015 7:30 PM, "Ruben Safir" wrote:
>
>> I've loaded my version of assignment 1 onto the NYLXS webserver at
>>
>>
>> http://www.nylxs.com/docs/grad_school/algorithms/hw/ass_1_lists/list.cpp.html
>>
>> http://www.nylxs.com/docs/grad_school/algorithms/hw/ass_1_lists
>>
>> Look it over and please edit and comment
>>
>> A few thoughts:
>>
>>
>> First, I changed to order of the function listings because we are not
>> using function declarations so the order that they are defined is
>> essential because they call each other. Ideally, one would make a .h file.
>>
>> Secondly, the given skeleton was essentially broken and I had to rewrite
>> all the functions. As it was, it not only didn't track the last entries
>> correctly near L.n == L.last, but also used an incorrect algorithm to
>> find is a list was full
>>
>> Thirdly, I reduced the size of the array from 100 to 5 so I could debug
>> it and show who it works.
>>
>> Fourthly, it takes some interpretation of the intent of the assignment
>> specifications to correctly right the code. This is all to common of a
>> problem. Give me the Spec! (I guess UML might be good for something).
>> As such, when the array is full and I'm adding from the last, then I
>> chose to push results forward and bump the first value. Likewise, for
>> InsertBegin, I push everything forward. He wrote this, actually, but I
>> filled in the case of what to do when the array is filled. I then give
>> a warning and bump the last value out of the array.
>>
>> Fifth: See my makefile and do yourself a favor and copy it and use it.
>> BTW - GVIM is your friend.
>>
>> Sixth: I let debugging code in my code. You can best run it like this
>>
>> list 2> /dev/nulll
>>
>> Even with that, it is quite chatty.
>>
>> Ruben
>>
|
|
