1. Using include and namespaces
- Posted by OthelloVivaldi at hotmail.com Aug 14, 2002
- 612 views
Hello everyone, I have written a small lib called heap.e (see below), but I'm not=20 certain about how to deal with Euphoria's namespaces. A user will often need to have several heaps, so my first thought was to keep them all in a sequence. The problem is that doing so seems to severely increase access time, i.e.: heap[ id ][ element ] is a much slower reference than simply heap[ element ] My current solution is therefore to use the include ... as feature. For example, to implement the typical a* routine, you will need two heaps, which are often given the names 'open' and 'close'.=20 So the question is: what do you think about the following: include heap.e as Open include heap.e as Close Open:push(X)=20 Close:push(Y) X =3D Open:pop() Y =3D Close:pop() Would you recommend this kind of programming style? Is there some horrible way this can backfire or otherwise turn out to be a member of the set of bad things? Sincerely Yours, Barbarella =20 Here follows my current version of heap.e. in case you're interested. -- heap.e = -- (Standard claimer): -- I take complete responsibility for ANY damage this file may do to=20 -- you, your computer, your pets or anything else in your environment. -- If anything bad happens, please try to evaluate the humanitarian and=20 -- material pains and costs, convert it to a sum in the currency of your -- country and send the figure to me. I will pay through my nose to=20 -- compensate your losses. Should I run out of money, I will come and=20 -- work for you as your personal slave until you are satisfied. without type_check without warning global sequence heap global integer size heap =3D {} size =3D 0 global procedure push(object x) integer parent, child object parent_value size +=3D 1 heap =3D append(heap, x) -- this looks strange, I know. child =3D size while child > 1 do parent =3D floor(child / 2) parent_value =3D heap[parent] if compare(parent_value, x) =3D 1 then -- if parent greater heap[child] =3D parent_value child =3D parent else heap[child] =3D x return end if end while heap[child] =3D x end procedure global function pop() integer parent, left, right object out, parent_value, left_value, right_value out =3D heap[1] parent =3D 1 parent_value =3D heap[size] size -=3D 1 heap =3D heap [1 .. size] while size do left =3D parent + parent -- left =3D parent * 2 if left > size then -- there was no children to this parent heap[parent] =3D parent_value return out end if left_value =3D heap[left] if compare(left_value, parent_value) =3D - 1 then -- if left < = parent -- swap parent with left unless right is even better right =3D left + 1 if right > size then -- swap with left and exit heap[parent] =3D left_value heap[left] =3D parent_value return out else -- compare left and right right_value =3D heap[right] if compare(left_value, right_value) =3D 1 then -- if = left > right -- swap with right, set new parent heap[parent] =3D right_value parent =3D right else -- swap with left, set new parent heap[parent] =3D left_value parent =3D left end if end if else -- left was not better, check right right =3D left + 1 if right > size then -- nothing to the right, set parent and exit heap[parent] =3D parent_value return out else right_value =3D heap[right] if compare(right_value, parent_value) =3D -1 then -- swap with right, set new parent heap[parent] =3D right_value parent =3D right else -- set parent, exit heap[parent] =3D parent_value return out end if end if end if end while return out end function global function top() return heap[1] -- look, but don't touch... end function -- -- A typical sanity check; see if the heap sorts correctly: -- -- constant NUM =3D 100 -- sequence random_sequence, ordinary_sort, heap_sort=20 -- -- -- 1. create a random sequence to be sorted -- random_sequence =3D repeat({}, NUM) -- for i =3D 1 to NUM do -- if rand(5) =3D 1 then -- -- create strange sequences -- random_sequence[i] =3D rand(repeat(10, rand(10))) -- else -- -- create random integers and atoms -- random_sequence[i] =3D rand(1000) / 3 - 500 -- end if -- end for -- -- -- -- 2. sort the sequence using standard sort -- include sort.e -- ordinary_sort =3D sort(random_sequence) -- -- -- -- 3. sort the sequence on the heap -- heap_sort =3D repeat({}, NUM) -- for i =3D 1 to NUM do -- push(random_sequence[i]) -- end for -- -- for i =3D 1 to NUM do -- heap_sort[i] =3D pop() -- end for -- -- -- -- 4. see if there is any difference -- if equal(heap_sort, ordinary_sort) then -- puts(1, "Everything ok.\n") -- else -- puts(1, "Oops! Something is wrong!\n") -- end if
2. Re: Using include and namespaces
- Posted by 10963508 at europeonline.com Aug 15, 2002
- 627 views
----- Original Message ----- From: <OthelloVivaldi at hotmail.com> > My current solution is therefore to use the include ... as feature. > > For example, to implement the typical a* routine, you will need > two heaps, which are often given the names 'open' and 'close'. > So the question is: what do you think about the following: > > include heap.e as Open > include heap.e as Close > > Open:push(X) > Close:push(Y) > X = Open:pop() > Y = Close:pop() > > Would you recommend this kind of programming style? > Is there some horrible way this can backfire or otherwise > turn out to be a member of the set of bad things? If this would work in Euphoria I would be very happy, but it doesn't. Second include file is just ignored. (Or does it?? :\) This is my number one wish item for any Euphoria feature (second are structures). That each include file has instance in memory, like a class. Now for every library which will have more than one object in program you have to keep id for each object of library and have global sequences in library file and access properties of objects from those global sequences and with id of object. This slows down coding time, clarity of code is reduced and also speed of program is slower I imagine.
3. Re: Using include and namespaces
- Posted by kbochert at copper.net Aug 15, 2002
- 601 views
-------Phoenix-Boundary-07081998- You wrote on 8/14/02 10:28:10 PM: > For example, to implement the typical a* routine, you will need > two heaps, which are often given the names 'open' and 'close'. > So the question is: what do you think about the following: > > include heap.e as Open > include heap.e as Close > > Open:push(X) > Close:push(Y) > X =3D Open:pop() > Y =3D Close:pop() > >If this would work in Euphoria I would be very happy, but it doesn't. Second >include file is just ignored. (Or does it=3F=3F :\) How about making a copy of heap.e and naming it heap2.e =3F then: include heap.e as Input include heap2.e as Output Along the same lines, how about: include sort.e as EU -- normal sort function EUcompare(object a, object b) -- save eu's compare if needed return compare (a, b) end function function compare (object a, object b) -- my custom compare .... end function include sort1.e as Custom -- sort uses custom compare Karl Bochert -------Phoenix-Boundary-07081998---
4. Re: Using include and namespaces
- Posted by jbrown105 at speedymail.org Aug 15, 2002
- 620 views
On 0, 10963508 at europeonline.com wrote: > > > ----- Original Message ----- > From: <OthelloVivaldi at hotmail.com> > > > My current solution is therefore to use the include ... as feature. > > > > For example, to implement the typical a* routine, you will need > > two heaps, which are often given the names 'open' and 'close'. > > So the question is: what do you think about the following: > > > > include heap.e as Open > > include heap.e as Close > > > > Open:push(X) > > Close:push(Y) > > X = Open:pop() > > Y = Close:pop() > > > > Would you recommend this kind of programming style? > > Is there some horrible way this can backfire or otherwise > > turn out to be a member of the set of bad things? > > > If this would work in Euphoria I would be very happy, but it doesn't. Second > include file is just ignored. (Or does it?? :\) > This is my number one wish item for any Euphoria feature (second are > structures). That each include file has instance in memory, like a class. > Now for every library which will have more than one object in program you > have to keep id for each object of library and have global sequences in > library file and access properties of objects from those global sequences > and with id of object. This slows down coding time, clarity of code is > reduced > and also speed of program is slower I > imagine. > This is a very interesting use of namespaces. I'll modify my namespace parser to support this type of "classes". (My parser rewrites all include statements, replacing them with direct code, so Eu's own version of include is ignored.) jbrown -- http://fastmail.fm/ - Access your email from home and the web
5. Re: Using include and namespaces
- Posted by jbrown105 at speedymail.org Aug 15, 2002
- 618 views
On 0, 10963508 at europeonline.com wrote: > > > ----- Original Message ----- > From: <OthelloVivaldi at hotmail.com> > > > My current solution is therefore to use the include ... as feature. > > > > For example, to implement the typical a* routine, you will need > > two heaps, which are often given the names 'open' and 'close'. > > So the question is: what do you think about the following: > > > > include heap.e as Open > > include heap.e as Close > > > > Open:push(X) > > Close:push(Y) > > X = Open:pop() > > Y = Close:pop() > > > > Would you recommend this kind of programming style? > > Is there some horrible way this can backfire or otherwise > > turn out to be a member of the set of bad things? > > > If this would work in Euphoria I would be very happy, but it doesn't. Second > include file is just ignored. (Or does it?? :\) > This is my number one wish item for any Euphoria feature (second are > structures). That each include file has instance in memory, like a class. > Now for every library which will have more than one object in program you > have to keep id for each object of library and have global sequences in > library file and access properties of objects from those global sequences > and with id of object. This slows down coding time, clarity of code is > reduced > and also speed of program is slower I > imagine. > This is a very interesting use of namespaces. I'll modify my namespace parser to support this type of "classes". (My parser rewrites all include statements, replacing them with direct code, so Eu's own version of include is ignored.) jbrown -- http://fastmail.fm - Get back to work
6. Re: Using include and namespaces
- Posted by OthelloVivaldi at hotmail.com Aug 15, 2002
- 641 views
> > My current solution is therefore to use the include ... as feature. > > > > For example, to implement the typical a* routine, you will need > > two heaps, which are often given the names 'open' and 'close'. > > So the question is: what do you think about the following: > > > > include heap.e as Open > > include heap.e as Close > > > > Open:push(X) > > Close:push(Y) > > X =3D Open:pop() > > Y =3D Close:pop() > > > > Would you recommend this kind of programming style? > > Is there some horrible way this can backfire or otherwise > > turn out to be a member of the set of bad things? >=20 >=20 > If this would work in Euphoria I would be very happy, but it doesn't. = Second > include file is just ignored. (Or does it?? :\) > This is my number one wish item for any Euphoria feature (second are > structures). That each include file has instance in memory, like a = class. > Now for every library which will have more than one object in program = you > have to keep id for each object of library and have global sequences = in > library file and access properties of objects from those global = sequences > and with id of object. This slows down coding time, clarity of code is > reduced > and also speed of program is slower I > imagine. Blush! Ugh! Oops! You are quite right, my "oh so elegant solution" has = the little problem that it doesn't work at all... ;) I must have been = dreaming, but it seemed such a logic thing! The Euphoria reference = manual says: "Different files might define different namespace identifiers to refer = to the same included file." Which I (in blissful ignorance) understood as:=20 "Any files might define different namespace identifiers to refer to the=20 same included file." A subtle difference there.=20 Now then, unless I'm making a fool of myself again, one way around this = mess, would be to simply name the files differently, e.g.: =20 include heap.e as Open include heap2.e as Close -- heap2.e is an EXACT copy of heap.e ! =20 Which is obviously plain silly.=20 Couldn't the Euphoria precompiler simply create a different=20 namespace whenever it was explicitly told to do so?=20 Oh, well, no programming language is perfect I guess. Yours Sincerely, Barbarella
7. Re: Using include and namespaces
- Posted by 10963508 at europeonline.com Aug 16, 2002
- 624 views
----- Original Message ----- From: <jbrown105 at speedymail.org> To: "EUforum" <EUforum at topica.com> Subject: Re: Using include and namespaces > > On 0, 10963508 at europeonline.com wrote: > > > > > > ----- Original Message ----- > > From: <OthelloVivaldi at hotmail.com> > > > > > My current solution is therefore to use the include ... as feature. > > > > > > For example, to implement the typical a* routine, you will need > > > two heaps, which are often given the names 'open' and 'close'. > > > So the question is: what do you think about the following: > > > > > > include heap.e as Open > > > include heap.e as Close > > > > > > Open:push(X) > > > Close:push(Y) > > > X = Open:pop() > > > Y = Close:pop() > > > > > > Would you recommend this kind of programming style? > > > Is there some horrible way this can backfire or otherwise > > > turn out to be a member of the set of bad things? > > > > > > If this would work in Euphoria I would be very happy, but it doesn't. Second > > include file is just ignored. (Or does it?? :\) > > This is my number one wish item for any Euphoria feature (second are > > structures). That each include file has instance in memory, like a class. > > Now for every library which will have more than one object in program you > > have to keep id for each object of library and have global sequences in > > library file and access properties of objects from those global sequences > > and with id of object. This slows down coding time, clarity of code is > > reduced > > and also speed of program is slower I > > imagine. > > > > This is a very interesting use of namespaces. I'll modify my namespace > parser > to support this type of "classes". (My parser rewrites all include > statements, > replacing them with direct code, so Eu's own version of include is > ignored.) If you're going to do it then do it that way that you can create as many objects as you want in a loop, I don't know how exactly should it work, something like this: include circle.e as CIRCLE sequence one_object CIRCLE one_object for i = 1 to 100 do one_object = new (CIRCLE) objects = append (objects, one_object) end for
8. Re: Using include and namespaces
- Posted by Juergen Luethje <jluethje at gmx.de> Aug 17, 2002
- 605 views
jbrown <jbrown105 at speedymail.org> wrote: <snip> > (My parser rewrites all include statements, replacing them with > direct code, so Eu's own version of include is ignored.) This will change the scope of local variables in the "included" files (and also the effect of with/without statements inside there). Couldn't this lead to undesirable results? Regards, Juergen
9. Re: Using include and namespaces
- Posted by Juergen Luethje <jluethje at gmx.de> Aug 17, 2002
- 644 views
Irv <irv at take.maxleft.com> wrote: <snip> > Dave Cuny had this feature - the ability to create multiple instances > from a single file included multiple times - in an > early version of his Py (mmm... pie!) interpreter. > As soon as I pointed out how handy it was, he removed it. > Too bad. I was using it somewhat as follows > (using Euphoria syntax, not Py) > include address.e as customer > include address.e as vendor > include address.e as company > customer:name = "Joe Smith" > company:name = "Footless Corp." > etc.. > The alternative, to copy the same file under three different names, > is exactly as you say, plain silly. > Irv Maybe I don't understand the problem ... I assume address.e will contain functions and procedures, why should they be duplicated? The same functions and procedures can work on different data, so what's wrong with the "classic" approach: ------------------------------------------------------------- include address.e -- say it defines a global type address, -- global constants SIZEOF_ADDRESS, -- NAME, ... address customer, vendor, company customer = repeat(0, SIZEOF_ADDRESS) vendor = repeat(0, SIZEOF_ADDRESS) company = repeat(0, SIZEOF_ADDRESS) customer[NAME] = "Joe Smith" company[NAME] = "Footless Corp." etc.. ------------------------------------------------------------- Regards, Juergen
10. Re: Using include and namespaces
- Posted by jbrown105 at speedymail.org Aug 17, 2002
- 596 views
On 0, Juergen Luethje <jluethje at gmx.de> wrote: > > jbrown <jbrown105 at speedymail.org> wrote: > > <snip> > > (My parser rewrites all include statements, replacing them with > > direct code, so Eu's own version of include is ignored.) > > This will change the scope of local variables in the "included" files > (and also the effect of with/without statements inside there). > Couldn't this lead to undesirable results? > > Regards, > Juergen > Well, the answer is yes. However, I got around this problem by renaming local variables in such a way that they would not comflict. For example, in ex.ex: include file1.e ... in file1.e atom a a = 1 ? a ... include file2.e ... in file2.e atom a a = 2 ? a ... ? a my parser would rewrite it as something like this: atom a_1 a_1 = 1 ? a atom a_2 a_2 = 2 ? a_2 ? a_3 It would show the first 2 variables corectly, and Eu would crash on the third ? statement, since it is undeclared both ways. With/without is more tricky, I based my parser on David Cuny's contcat program (renamed fix I believe) which simply commented them out. jbrown -- http://fastmail.fm - Taking the "ail" out of email!
11. Re: Using include and namespaces
- Posted by jbrown105 at speedymail.org Aug 17, 2002
- 598 views
On 0, 10963508 at europeonline.com wrote: > > > ----- Original Message ----- > From: <jbrown105 at speedymail.org> > To: "EUforum" <EUforum at topica.com> > Subject: Re: Using include and namespaces > > > > On 0, 10963508 at europeonline.com wrote: > > > > > > > > > ----- Original Message ----- > > > From: <OthelloVivaldi at hotmail.com> > > > > > > > My current solution is therefore to use the include ... as feature. > > > > > > > > For example, to implement the typical a* routine, you will need > > > > two heaps, which are often given the names 'open' and 'close'. > > > > So the question is: what do you think about the following: > > > > > > > > include heap.e as Open > > > > include heap.e as Close > > > > > > > > Open:push(X) > > > > Close:push(Y) > > > > X = Open:pop() > > > > Y = Close:pop() > > > > > > > > Would you recommend this kind of programming style? > > > > Is there some horrible way this can backfire or otherwise > > > > turn out to be a member of the set of bad things? > > > > > > > > > If this would work in Euphoria I would be very happy, but it doesn't. > Second > > > include file is just ignored. (Or does it?? :\) > > > This is my number one wish item for any Euphoria feature (second are > > > structures). That each include file has instance in memory, like a > class. > > > Now for every library which will have more than one object in program > you > > > have to keep id for each object of library and have global sequences in > > > library file and access properties of objects from those global > sequences > > > and with id of object. This slows down coding time, clarity of code is > > > reduced > > > and also speed of program is slower I > > > imagine. > > > > > > > This is a very interesting use of namespaces. I'll modify my namespace > > parser > > to support this type of "classes". (My parser rewrites all include > > statements, > > replacing them with direct code, so Eu's own version of include is > > ignored.) > > If you're going to do it then do it that way that you can create as many > objects as you want in a loop, I don't know how exactly should it work, > something like this: > > include circle.e as CIRCLE > > sequence one_object i think you mean "sequence objects" > > CIRCLE one_object > for i = 1 to 100 do > one_object = new (CIRCLE) > objects = append (objects, one_object) > end for > That would be extremely difficult due to the way my namespace parser handles the rewritting of code. Actually, with my parser that would be flat out impossible. It doesn't matter, I've changed my mind and now I'm writing a real class/OOP parser, which will be capabile of converting your code and making it run properly when it is complete. jbrown -- http://fastmail.fm - Ever wonder why we aren't named snailmail.sm?