1. Boolean Variable Type
Something I find really annoying... during my games and application
programming I have always found I needed "flag" variables, just to hold
On/off, True/false type data. However, using an integer type for this is a
waste of memory... surely it is time we had a boolean variable type, called
FLAG or something, that can only hold true or false, and would only be 1
bit in size? It would improve the efficiency of euphoria programs in terms
of memory.
2. Re: Boolean Variable Type
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM>
Feb 17, 2000
-
Last edited Feb 18, 2000
Hello Pete,
>Something I find really annoying... during my games and application
>programming I have always found I needed "flag" variables, just to hold
>On/off, True/false type data. However, using an integer type for this is a
>waste of memory... surely it is time we had a boolean variable type, called
>FLAG or something, that can only hold true or false, and would only be 1
>bit in size? It would improve the efficiency of euphoria programs in terms
>of memory.
I agree that this would be useful.
However, considdering the average processor speed and
memory available on PCs today, the memory problem is
hardly an issue. Also, considdering how little we (the programmers) know
about Euphoria's internal variable
storage system, this may not be all that efficient
either.
What would be nice is to have a boolean type that
doesn't require the overhead of a user defined type
(kinda like "integer"). But I don't really care if it
takes up 32 bytes of space or not.
later,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
3. Re: Boolean Variable Type
On Thu, 17 Feb 2000 21:21:54 GMT, Lewis Townsend wrote:
>But I don't really care if it
>takes up 32 bytes of space or not.
I think would really concern me if it took up 32 bytes of space... unless
you meant to say 32 bits (4 bytes). 8^)
But I'd have to agree that the memory 'wasted' on storing flags in an
integer is trivial these days. And I would bet that there would be a
performance hit from the need to (internally) mask a bit to determine a
boolean value.
-- Brian
4. Re: Boolean Variable Type
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM>
Feb 17, 2000
-
Last edited Feb 18, 2000
Hello,
> >But I don't really care if it
> >takes up 32 bytes of space or not.
>
>I think would really concern me if it took up 32 bytes of space... unless
>you meant to say 32 bits (4 bytes). 8^)
Oops, yes, I meant bits @@ <-- me rolling eyes
>But I'd have to agree that the memory 'wasted' on storing flags in an
>integer is trivial these days. And I would bet that there would be a
>performance hit from the need to (internally) mask a bit to determine a
>boolean value.
>
>-- Brian
Wouldn't the space needed to store the memory address
of the bool have to be a 32 bit value anyway?
I considdered offering a solution in which you would
peek and poke to memory to store and retrieve boolean
values. I then realized that the memory address would
still have to be stored in a value much greater than
one bit in size.
:)
later,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
5. Re: Boolean Variable Type
You can store 32 flags in 1 memory location by using the bit-wise
operators.
6. Re: Boolean Variable Type
- Posted by Steve Mosher <farq at KILN.ISN.NET>
Feb 17, 2000
-
Last edited Feb 18, 2000
On Thu, 17 Feb 2000, Brian Broker wrote:
> On Thu, 17 Feb 2000 21:21:54 GMT, Lewis Townsend wrote:
>
> >But I don't really care if it
> >takes up 32 bytes of space or not.
>
> I think would really concern me if it took up 32 bytes of space... unless
> you meant to say 32 bits (4 bytes). 8^)
>
> But I'd have to agree that the memory 'wasted' on storing flags in an
> integer is trivial these days. And I would bet that there would be a
> performance hit from the need to (internally) mask a bit to determine a
> boolean value.
>
> -- Brian
>
You'd better believe it. The minimum a CPU can write to memory is
8 bits. Most C programs use 32-bit integers for flags. They should be
using 8-bit ints, but rarely do. The problem with a data type of only one
bit is that it takes far more to address it than it contains. Furthermore,
the only thing you can put in those remaining seven bits are other 1 bit
types.
If you've only got 1 flag in your programn, a boolean type will
save you no memory (it will actually waste some, address & bit vs.
address). 32 bits will address (by byte) 4,294,967,296 bytes. To do this
by bit, you need 35 bits, three bits wasted per address. Then there's the
overhead involved in translating the address into a readable form, and
back. Generally, there's no real advantage.
To demonstrate this, think about writing flag handling routines in
euphoria. You'll notice that no matter how you do it, it will waste both
memory and speed. Same deal if it were compiled into the language.
7. Re: Boolean Variable Type
----- Original Message -----
From: Lewis Townsend <keroltarr at HOTMAIL.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, February 17, 2000 4:50 PM
Subject: Re: Boolean Variable Type
> Hello,
>
> > >But I don't really care if it
> > >takes up 32 bytes of space or not.
> >
> >I think would really concern me if it took up 32 bytes of space...
unless
> >you meant to say 32 bits (4 bytes). 8^)
>
> Oops, yes, I meant bits @@ <-- me rolling eyes
>
> >But I'd have to agree that the memory 'wasted' on storing flags in an
> >integer is trivial these days. And I would bet that there would be a
> >performance hit from the need to (internally) mask a bit to determine a
> >boolean value.
> >
> >-- Brian
>
> Wouldn't the space needed to store the memory address
> of the bool have to be a 32 bit value anyway?
> I considdered offering a solution in which you would
> peek and poke to memory to store and retrieve boolean
> values. I then realized that the memory address would
> still have to be stored in a value much greater than
> one bit in size.
True, but that one 32bit memory addy is the addy for 32 boolean bits, but if
you add one to the addy, you get another 32bits of boolean, which is where
the only payoff is. If there is a payoff, once you count the masking and
such involved. I got too accustomed to bytebool and wordbool tho, for more
fuzzy uses, so i wouldn't use bitbools. Besides, like you said, with 96Meg
of memory, and running a hog OS (any modern OS), throwing 100 bytes at
boolean storage isn't a problem anymore.
Kat
8. Re: Boolean Variable Type
Kat wrote:
>----- Original Message -----
>From: Lewis Townsend
>Subject: Re: Boolean Variable Type
>
>
>> Hello,
>>
>> >But I'd have to agree that the memory 'wasted' on storing flags in an
>> >integer is trivial these days. And I would bet that there would be a
>> >performance hit from the need to (internally) mask a bit to determine a
>> >boolean value.
>> >
>> >-- Brian
>>
>> Wouldn't the space needed to store the memory address
>> of the bool have to be a 32 bit value anyway?
>> I considdered offering a solution in which you would
>> peek and poke to memory to store and retrieve boolean
>> values. I then realized that the memory address would
>> still have to be stored in a value much greater than
>> one bit in size.
>
>True, but that one 32bit memory addy is the addy for 32 boolean bits, but if
>you add one to the addy, you get another 32bits of boolean, which is where
>the only payoff is. If there is a payoff, once you count the masking and
>such involved. I got too accustomed to bytebool and wordbool tho, for more
>fuzzy uses, so i wouldn't use bitbools. Besides, like you said, with 96Meg
>of memory, and running a hog OS (any modern OS), throwing 100 bytes at
>boolean storage isn't a problem anymore.
>
>Kat
You knew that I couldn't leave this one alone forever. Let's buy the argument
that space doesn't matter for now. We'll leave alone the memory needs of
generalized speech recognition and generation...let alone semi-intelligent
interaction. All the speed and all the space...won't be enough...ever. But,
let us move on. However boolean or flag data is stored and handled in the
algorithmic side of Euphoria, many times, it will have to be sent and
received as flag bytes or bit words. Because of the total inefficiencey of
non-aligned byte variables in any kind of modern hardware, most bit
containing storage units will be 32 bits, period. We don't have to use all
the bits, but that is the unit that they will be stored and retrieved in.
Now, if only we could describe the external data efficiently from within
Euphoria. I would not mind being forced to convert that structured data to
Euphoria native types when doing other than IO, but it would be most useful
and efficient to have that transformation be internal to Euphoria. There will
never be an automatic way to deal with compression schemes or other items
that are truly bitstream oriented, but most other types of external data can
be easily broken into a finite, even fairly compact set of data types and
therefore builtin conversions. As a matter of fact, we have most of the
conversions already as internal functions. With the creation of internal
structures, it is a small step to the external structure descriptions that then
give us access to the world without peeking and poking everything in sight.
Everett L.(Rett) Williams
rett at gvtc.com
