Subject: Odd float behavior
Author: Massaria
Posted: 03/24/2006 07:51AM
This pertains to version 2.7, as I've decided not to migrate just yet - I want to make a final touch-up and get some feedback before going on.
I can't say exactly when this started, much less why, but my floats have suddenly begun to change slightly with each boot of tmud. A room, for example, should have had attributes like:
meat: 10.0
fat meat: 3.0
leaf: 10.0
but suddenly they read:
meat: 9.95935083808007
fat meat: 2.97436037579237
leaf: 9.95935083808007
And with each subsequent boot-up, another fraction disppears! I thought I might have forgotten some timer method (since I've had something like that before), but I'm quite sure I haven't. This is supported by the fact that attributes on the players are behaving in the same way, attributes which has never been involved in any kind of loop or such.
The organization level of the nerves system, for example, starts at 1.0, but after several boots, it's now at 0.701144709187229. One would think it keeps getting smaller, like with the rooms, but no - yet more boots produced these values:
0.701144801020307
0.701144833877042
0.701144845632774
Even the date of creation, which is completely isolated from commands and loop and all that, now reads:
:created: 2006-03-23 20:23:48.816836 +01:00
That's fairly precise - A little too precise, in fact :-(
What makes it even odder, is that if I replace those long floats with the original value (i.e. making it 'meat: 10.0' again), the value remains unchanged, while the rest keeps changing.
What the hell is going on?
Thanks
Mass.
reply
Subject: Odd float behavior
Author: Tyche
Posted: 03/25/2006 05:01AM
Massaria wrote:
> I can't say exactly when this started, much less why, but my floats have suddenly begun to change slightly with each boot of tmud. A room, for example, should have had attributes like:
>
> meat: 10.0
> fat meat: 3.0
> leaf: 10.0
>
> but suddenly they read:
> meat: 9.95935083808007
> fat meat: 2.97436037579237
> leaf: 9.95935083808007
>
I tried to duplicate that with this:
require 'yaml'
require 'pp'
class A
def initialize a_
@a = a_
end
end
b = A.new(10.000987)
pp b
x = YAML::dump b
pp x
y = YAML::load x
pp y
That's really all that Tmud itself is doing with new properties on objects. It writes them out to yaml and reads them in. I tried a number of different floating point numbers in the above and they didn't change.
> Even the date of creation, which is completely isolated from commands and loop and all that, now reads:
> :created: 2006-03-23 20:23:48.816836 +01:00
> That's fairly precise - A little too precise, in fact :-(
Time is floating point under the covers. I don't know how meaningful the precision is. I expect it's either milliseconds or microseconds depending on the OS.
reply
Subject: Odd float behavior
Author: Massaria
Posted: 03/26/2006 04:49PM
Tyche wrote:
>
> I tried to duplicate that with this:
>
>
> require 'yaml'
> require 'pp'
>
> class A
> def initialize a_
> @a = a_
> end
> end
>
> b = A.new(10.000987)
> pp b
> x = YAML::dump b
> pp x
> y = YAML::load x
> pp y
>
>
> That's really all that Tmud itself is doing with new properties on objects. It writes them out to yaml and reads them in. I tried a number of different floating point numbers in the above and they didn't change.
>
> > Even the date of creation, which is completely isolated from commands and loop and all that, now reads:
> > :created: 2006-03-23 20:23:48.816836 +01:00
> > That's fairly precise - A little too precise, in fact :-(
>
> Time is floating point under the covers. I don't know how meaningful the precision is. I expect it's either milliseconds or microseconds depending on the OS.
>
Dangit. This is just impossible.
It doesn't even record the right values first time around. If I boot up, log in, create a room and then log out, the values are already messed up.
I can't imagine what would cause this bahaviour in tmud - could it have something to do with ruby, yaml or my OS?
Would it help if I posted some code?
I welcome any and all suggestions to get this fixed - I can't have a mud where I can't depend on the values of my variables.
Some times I think this glorified pile of sand has made up its' mind to make my life suck, suck, triple suck!
hmpf
Tobias
reply
Subject: Odd float behavior
Author: Tyche
Posted: 03/26/2006 07:37PM
Massaria wrote:
> Dangit. This is just impossible.
> It doesn't even record the right values first time around. If I boot up, log in, create a room and then log out, the values are already messed up.
> I can't imagine what would cause this bahaviour in tmud - could it have something to do with ruby, yaml or my OS?
>
I don't think it's the OS or the new Ruby because I am also running the one-click installer preview 3 version on Windows XP, the same as you.
> Would it help if I posted some code?
I forgot to ask, are the dates changing also? I remember you added a create date or something to your objects. Does that stay the same? Reason I ask is because I put timestamps on the objects in the 2.9 version and they do stay the same.
Another thing to check is to GREP those field names that keep changing, and find every spot they are used in your code.
Of course beyond just knowing that floats are used in Time, I don't believe I use floats anywhere in tmud. I'll add a property to an object that stores a float and see if it occurs for me with the whole tmud running.
reply
Subject: Odd float behavior
Author: Massaria
Posted: 03/27/2006 12:48PM
Tyche wrote:
> I forgot to ask, are the dates changing also? I remember you added a create date or something to your objects. Does that stay the same? Reason I ask is because I put timestamps on the objects in the 2.9 version and they do stay the same.
Just to be sure: This problem is with 2.7.
My 'created' property doesn't change, but those extra digits did appear at the same time as the floats started messing up.
>
> Another thing to check is to GREP those field names that keep changing, and find every spot they are used in your code.
>
I've done that, now, but I pretty much knew I wouldn't find anything. The code for setting up the rooms is very simple:
def initialize(name, owner, habitat)
super(name, owner)
self.exits={}
self.habitat = habitat
self.r_energy = set_habitat_energy(habitat)
end
def set_habitat_energy(habitat)
case habitat
when "jungle"
nrg = {"meat" => 10.0, "lean meat" => 5.0, "fat meat" => 3.0, "grasses" => 7.0, "leaf" => 10.0, "nuts, seeds & grain" => 5.0, "fruit & berries" => 10.0, "nectar" => 7.0, "detritus" => 0.0, "filter" => 0.0 }
when "desert"
nrg = {"meat" => 3.0, "lean meat" => 1.0, "fat meat" => 0.5, "grasses" => 2.0, "leaf" => 1.0, "nuts, seeds & grain" => 1.0, "fruit & berries" => 1.0, "nectar" => 0.1, "detritus" => 0.0, "filter" => 0.0 }
when "shallows"
nrg = {"meat" => 6.0, "lean meat" => 10.0, "fat meat" => 2.0, "grasses" => 8.0, "leaf" => 8.0, "nuts, seeds & grain" => 0.0, "fruit & berries" => 0.0, "nectar" => 0.0, "detritus" => 10.0, "filter" => 10.0 }
else
nrg = {"meat" => 0.0, "lean meat" => 0.0, "fat meat" => 0.0, "grasses" => 0.0, "leaf" => 0.0, "nuts, seeds & grain" => 0.0, "fruit & berries" => 0.0, "nectar" => 0.0, "detritus" => 0.0, "filter" => 0.0 }
sendto("Habitat missing. Default r_energy set")
end
nrg
end
Still, as simple as it is, creating a room and shutting down tmud results in a yaml file with values like:
:habitat: jungle
:contents:
- 2
:r_energy:
fat meat: 2.99855348198084
meat: 9.99517827326948
detritus: 0.0
leaf: 9.99517827326948
fruit & berries: 9.99517827326948
filter: 0.0
nectar: 6.99662479128863
grasses: 6.99662479128863
nuts, seeds & grain: 4.99758913663474
lean meat: 4.99758913663474
Perhaps the most weird part is that the values seem correct when i list them within the mud, using:
when "room", "r"
r = $engine.world.db.get(location)
if r
sendto("Stats on : " + r.name.upcase + " (id: " + r.id.to_s + ")")
sendto("Habitat : " + r.habitat) if r.habitat
sendto("Available Energy (relative):")
r.r_energy.each {|food, amount| sendto(sprintf(" %-20s %10.2f", food, amount)) } if r.r_energy
end
Floats on player objects are misbehaving too. The neural organization is initialized to 1.0, but a small portion is deducted at each boot-up:
(from yaml file, after shutdown)
organize: 0.999614939936022 (created character)
organize: 0.807933746104842 (no log-in, just boot-up & shutdown)
organize: 0.739352593370035 (log-in)
organize: 0.714815107889966 (room creation)
Hm, the intervals doesn't appear consistent - perhaps the amount of time that tmud runs has some impact... I'll look into that.
On the other hand, no. Seems more likely it's deducting a certain percentage or something along those lines (which, incidently, many of my timed loops do - but not to rooms! hmpf).
> Of course beyond just knowing that floats are used in Time, I don't believe I use floats anywhere in tmud. I'll add a property to an object that stores a float and see if it occurs for me with the whole tmud running.
>
That would be super, but I'm beginning to suspect you may need to have my code in order to really have a chance.
What say you - can I send it your way?
Thanks Tyche, it's very good of you to help me so much.
Tobias
___________
EDIT:
Well, it seems with enough reboots, some values on the room does show the reduction (4 or 5 times and some values will list as "2.99" - for example - but why it doesn't report the value of nectar (6.99662479128863) as "6.99", in stead of "7.00", as it does now, is beyond me).
reply