MESSAGE
DATE | 2015-01-23 |
FROM | Maneesh Kongara
|
SUBJECT | Re: [LIU Comp Sci] Algorithms Assignment 1 attempt
|
From owner-learn-outgoing-at-mrbrklyn.com Fri Jan 23 06:26:02 2015 Return-Path: X-Original-To: archive-at-mrbrklyn.com Delivered-To: archive-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix) id 8102D16116D; Fri, 23 Jan 2015 06:26:02 -0500 (EST) Delivered-To: learn-outgoing-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix, from userid 28) id 6ED38161174; Fri, 23 Jan 2015 06:26:02 -0500 (EST) Delivered-To: learn-at-mrbrklyn.com Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by mrbrklyn.com (Postfix) with ESMTP id E379016116D for ; Fri, 23 Jan 2015 06:26:01 -0500 (EST) Received: by mail-qa0-f46.google.com with SMTP id j7so5316945qaq.5 for ; Fri, 23 Jan 2015 03:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jjnlH8HoHOrXbkCQKD08GgcxqPFeqahPdNtXOAt2lEA=; b=oILjnOjjQb4Y1EejI/EH5mIellMjFM/VZ5LbN9kw3R5m1hJeCxIyhoMunMuriWiVNG m+sNAnZPadTeQNgOQGbx0zRZl+xP6yA3furSzfASPvVGCV+fhumTADKZPB6qa8ApPsp8 NemY2unTi35cIYaMAJ3QmCQwPuGB5Eylu3TRaeQtqq9Zvrfj+kdeaT0G8vHxZL+Ye8k4 tCn3mUj3APayK8KBnGNYpJhJcO9B/OTs9RWSW4KXcDHpQi0XwOISwLys2xIyox3Sw5xC 0menWXKjWJZeaCsM5tINCzHojWYjY05t8W0jB3p/NB0j84CZZ6y81abOlIo3lclYGjxr PR7g== MIME-Version: 1.0 X-Received: by 10.229.192.5 with SMTP id do5mr13046687qcb.12.1422012360521; Fri, 23 Jan 2015 03:26:00 -0800 (PST) Received: by 10.229.157.204 with HTTP; Fri, 23 Jan 2015 03:26:00 -0800 (PST) Received: by 10.229.157.204 with HTTP; Fri, 23 Jan 2015 03:26:00 -0800 (PST) In-Reply-To: <54C22F4B.1030808-at-panix.com> References: <54C19620.5070706-at-panix.com> <54C22F4B.1030808-at-panix.com> Date: Fri, 23 Jan 2015 06:26:00 -0500 Message-ID: Subject: Re: [LIU Comp Sci] Algorithms Assignment 1 attempt From: Maneesh Kongara To: learn-at-mrbrklyn.com Content-Type: multipart/alternative; boundary=001a11337bfc9d7d04050d500d6a Sender: owner-learn-at-mrbrklyn.com Precedence: bulk Reply-To: learn-at-mrbrklyn.com
--001a11337bfc9d7d04050d500d6a Content-Type: text/plain; charset=UTF-8
Arrays accept only sequential insertion rite? I don't know if you could insert data at random in arrays. Please correct me if I'm wrong. On Jan 23, 2015 6:23 AM, "Ruben Safir" wrote:
> 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 > >> > >
--001a11337bfc9d7d04050d500d6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Arrays accept only sequential insertion rite? I don't kn= ow if you could insert data at random in arrays. Please correct me if I'= ;m wrong.
On Jan 23, 2015 6:23 AM, "Ruben Safir"= < mrbrklyn-at-panix.com> wrote= : :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/22/2015 07:3= 4 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 happyr> with this result.=C2=A0 the problem is what happens if you drop a data poin= t
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.=C2=A0 Then I InsertByPosition,r> into spot 61.=C2=A0 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 * =3D L.a; and then do the math like that.=C2=A0 It is much cleaner a= nd
professional code.
> Maneesh.
> On Jan 22, 2015 7:30 PM, "Ruben Safir" <:mrbrklyn-at-panix.com">mrbrklyn-at-panix.com> wrote:
>
>> I've loaded my version of assignment 1 onto the NYLXS webserve= r at
>>
>>
>> _1_lists/list.cpp.html" target=3D"_blank">http://www.nylxs.com/docs/grad_sc= hool/algorithms/hw/ass_1_lists/list.cpp.html
>>
>> _1_lists" target=3D"_blank">http://www.nylxs.com/docs/grad_school/algorithm= s/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<= br> >> essential because they call each other.=C2=A0 Ideally, one would m= ake a .h file.
>>
>> Secondly, the given skeleton was essentially broken and I had to r= ewrite
>> all the functions.=C2=A0 As it was, it not only didn't track t= he last entries
>> correctly near L.n =3D=3D L.last, but also used an incorrect algor= ithm 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 assign= ment
>> specifications to correctly right the code.=C2=A0 This is all to c= ommon of a
>> problem.=C2=A0 Give me the Spec! (I guess UML might be good for so= mething).
>> 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.=C2=A0 Like= wise, for
>> InsertBegin, I push everything forward.=C2=A0 He wrote this, actua= lly, but I
>> filled in the case of what to do when the array is filled.=C2=A0 I= then give
>> a warning and bump the last value out of the array.
>>
>> Fifth:=C2=A0 See my makefile and do yourself a favor and copy it a= nd use it.
>> BTW - GVIM is your friend.
>>
>> Sixth:=C2=A0 I let debugging code in my code.=C2=A0 You can best r= un it like this
>>
>> list 2> /dev/nulll
>>
>> Even with that, it is quite chatty.
>>
>> Ruben
>>
--001a11337bfc9d7d04050d500d6a--
|
|