1. Using include and namespaces
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
----- 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
-------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
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
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
> > 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
----- 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
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
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
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
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?
