A Boolean variable definer

ID:103374
 
Oct 17 2010, 2:56 pm
Not Feasible
Applies to:Dream Maker
Status: Not Feasible
Implementing this feature is not possible now or in the foreseeable future
In my opinion, it would be useful if we were given the ability to define variables as boolean. Especially in large projects, when you're working with a ton of variables, accidentally setting a variable to a mistyped number could cause a mess of problems.

You could say something in response such as:

mob/var/bool_Shocked


but the variable is still defined as a float value if I'm correct anyways! Why not save the what, 2kb space? It'd be useful.

Please, just allow us to go like this:

mob/var/bool/Shocked


instead.
Oct 18 2010, 11:40 am
Well, generally speaking, boolean in this is 0, and anything else. Declaring variables as a specific type is a trait of a strongly-typed language. DM is not strongly-typed, so it'd be really out of place.
If, for some reason, if(var) isn't acceptable still, could you give more examples?
In addition, you could make your own data-type:
datum/bool
  var val;
  New(val)
      if(!isnum(val))CRASH()
      src.val = val
      checkVal()

  proc/checkVal()
    if(val!=0) val=1
    else val=0

.. Either way, you can do this yourself.
Oct 18 2010, 1:38 pm
If the goal was to reduce the 2kb spent on a float value compared to a Boolean, I don't see how creating an entire datum to handle it would be much help.
Oct 18 2010, 4:56 pm
Falacy wrote:
If the goal was to reduce the 2kb spent on a float value compared to a Boolean, I don't see how creating an entire datum to handle it would be much help.

I think it's being needlessly picky, that's all.
Oct 18 2010, 5:49 pm
A float is 32 bits, I'm not sure why people are saying "2kb". The most you'll save is 3 bytes and that assumes that they're using a 32-bit data type for booleans.

If you set "var/x = 7" I'm not sure if it uses a float or int. If you set "x = 'hello'" it clearly isn't using a float (or int) anymore. The internal data type can change without you noticing so it's possible that they're using a different data type for booleans already.
Oct 19 2010, 4:01 am
This is not actually an optimisation, as much as a naive understanding may see it.

A boolean may classically be storable in 1 byte (1 bit, if you wanted to go that far), but RAM will read in cycles of 4 bytes, caches are aligned on 4 byte barriers, and CPUs will be optimised for "full 32 bit width" register operations over other operations, as they are most common.

An explicit data-type would save physical memory (but not cache or registers most likely, unless cache alignment was closely tweaked) at the trade-off of performance in all operations on that value, under the hood. Explicit packing in a bit-table would save memory if executed properly, but cost in execution time of such values in the VM itself.

It's not worth the effort, basically.
Oct 19 2010, 4:07 am
I guess another issue is there may well not be an explicit boolean data-type, as it's implied. 456 is boolean true for example, but also has a number of integer properties, such as 456 + 3 = 459.

To store that in anything less than a suitable integer value risks attempting an integer operation on it at a later date, and having lost precision (thus to the programmer the result is incorrect).

The compiler doesn't have the good fortune of escape analysis currently (not do I suspect it will in the near future) so it can't guarantee that will only ever be used in boolean operations and thus optimise allocation accordingly.

But some type coersion from an integer to a boolean at runtime as required maintains appropriate precision with a far far simpler implementation.
Oct 19 2010, 4:10 am
A boolean may classically be storable in 1 byte (1 bit, if you wanted to go that far), but RAM will read in cycles of 4 bytes, caches are aligned on 4 byte barriers, and CPUs will be optimised for "full 32 bit width" register operations over other operations, as they are most common.

I agree but not for this reason.

If anything this won't save physical memory but could save cache space. Physical memory gets allocated in larger chunks. It's not worth the OS's time to keep track of who was assigned each byte so it gives you larger chunks. If you ask for a byte you'll be given more than you need. Converting all boolean values from 32 bits to 8 bits only saves physical memory if it drops you below a page boundary.

If memory is read 32 bits at a time, having 8-bit booleans means you can read four boolean values at a time (assuming they're stored sequentially). This means that the first cache miss on a boolean var brings the next three booleans into the cache with it.

But I do agree that this is a lot of work to fix something that isn't really a problem.