Code center > Suggestions

Make position a Single, not a Long

<< < (2/4) > >>

PurpleYouko:

--- Quote ---I think they know them - PY or Numsgil added this feature. Initially I thought it was very stupid: everything was designed to give organisms only relative views on the environment. Well, I'm a bit less fundamentalist about that now. Most animals are able to orientate in the environment, and this is an important feature. Obviously, they do not have a GPS in their head, but, to some extent, it is like they do. But developing such a feature is probably impossible in the DarwinBots universe, not only because organisms are very simple, but also because of the nature of the DarwinBots environment, so poor of landmarks and allowing so limited senses.
So, maybe, it is not so bad that robots know their approximate position.
--- End quote ---

I added the xpos, ypos and depth features for V2.15 pond mode about a year and a half ago.
The feature enabled us to explore whole new behavioural patterns including territoriality and ant-bots that return home to feed the queen.
In pond mode, the depth control (actually the same memory location as ypos) allows for bouyancy to control exact depth in the water column. Again this allows for organisms to sink during the day time and rise to the surface at night. Unfortunately very few people ever seem to use pond mode even though it provides one of the very few areas where it is possible to have diverse environments.

Anonomous Guest Person:
xpos and ypos are both programmable as a single gene. Not very cost efficient, but not all bots need such a gene.

It might also, as time goes on, become inaccurate, but who knows?

cond
start
  25 .veldx addstore
  26 .velsx addstore
stop

The only difference is that it's relative to it's starting position.
Which, for antbots, is good, because the queen can pass it along to it's children, and then they simply go back to 0,0.

Hence, xpos and ypos are practically useless. Even if you wanted to make bots communicate the location of food, they'd say where the food is relatively rather then based on their oppinion where the center of the world is.

And as time goes on, it'd become (realistically) inaccurate. requiring antbots to search for their queen, and reestablish where they are based on her being the center of the world. (Which would be loads more amazing if xpos and ypos were removed.)

So, simply put, xpos and ypos aren't actually needed to make a location system, assuming you're creative enough. (And if you want it for evolution, then I remind you that evolution rarely creates anything good, and this isn't exactly helped by all the functional memory locations. It'd be like making a random word generator, and running it until we get something good; except instead of 26 letters, we'd have 260.)

PurpleYouko:
I don't see how the gene that you showed could do this.

veldx and velsx only tell the bot how fast it is currently travelling in its own sx and dx vectors. Those vectors are directly related to its current aim angle so they would be utterly useless as cumulative distance counters, as would vel, or velup.

If a robot is travelling to the right at a speed of 20 with no up or down movement then vel and velup would be 20 while both veldx and velsx would return zero

If the same robot were travelling straight up with no left or right movement then vel, velup, velsx and veldx would return exactly the same values as before.

In fact any robot travelling at a speed of 20 in any direction would return the same numbers to all its "vel" sysvars.

In other words a robot can only know its rate of movement relative to its current direction of travel. It has absolutely no way to tell anything at all relative to a specific location unless it has xpos and ypos sysvars. It can't count how far it has travelled along the x axis or y axis because it can't tell how far it has travelled due to having no direct reference to either of them.

To make your example work the robot would need to use its direction and rate of travel to calculate x and y vectors using trigonometry along with veldx, and velup. Robots do not have trig capabilities since that is even more unrealistic than having direct xpos and ypos knowledge.
Even if the robots could count how far they have travelled along x and y coordinates, they would probably soon hit the 32767 size limit of the memory locations and so completely lose themselves.

Real organisms such as ants use sight to align themselves with specific landmarks. Experiments in the dessert have proven this. DB has no landmarks so the xpos, ypos system just makes it work as if it did have.

Sprotiel:

--- Quote ---In VB, the largest number that can be held in a single precision floating point variable is 32767.
--- End quote ---
:blink:  :blink:

Please try

--- Code: ---Private Sub Command1_Click()
Dim count As Single
While count < 400000000#
 Print count
 count = count + 10000
Wend
End Sub
--- End code ---

PurpleYouko:
OK so it would appear that I was a little remis in assuming that singles worked the same way as integers. From this example they obviously don't. They go negative pretty well too.

Just goes to show that I don't know as much as I think I do sometimes.  :redface:

But the problem still remains in many places that the program has a real tendency to crash when singles are used. The crashes mysteriously go away when the variables are redefined as longs. I am pretty sure this isn't because of numbers in vast excess of 32000 as in many cases the actual number being stored into the variable can be read directly from the program in debug mode. It is often only around 40,000.

The main problem though is that large numbers of variables in the program are actually integers and these definitely can't hold more than 32767. Changing them into singles would result in things like fractions being stored into the robot's memory locations. Maybe some kind of long integer could be used.

I don't think VB supports "long integer" as a variable type

Well whadya know?

A quick look through the help files tells me that "Long" is actually an integer variable anyway. It is the same thing as "Long Integer"
That is a little counter intuitive I would say.

Still looks to me as if all the robot memory locations need to be upgraded to longs though. This will eliminate SOOO many routines that exist solely to limit values that are saved to memory, to 32000

Navigation

[0] Message Index

[#] Next page

[*] Previous page