Jump to content
Eternal Lands Official Forums
Amaara

Bots with Bad Math

Recommended Posts

I am annoyed when I find a bot that will give the wrong amount of gc. I cancel the trade and go to a different bot, and if the item is priced the same, find the same math error on a second bot. This shows that there is some very sloppy coding on many bots. For example: How in the world does .61 x 100 = 60 and not 61?

 

Not sure who is doing the math or the programming code, but come on get the math right!!

Share this post


Link to post
Share on other sites

Yeah, Dogbreath, Learner. ummm Quesar, Get the MATH! Your bots have been ripping me off for YEARS!

 

Until you get the math right I am boycotting all bots.

 

Stealing 1 gc's at a time making you all ebul rich.

 

 

bah

Share this post


Link to post
Share on other sites

Maybe to someone like you who have been playing the game for years and every single gc doesn't count, but for the new player who is counting every gc to buy that special book or item, it does matter! And not only, it gives them a bad impression of the game. :(

Share this post


Link to post
Share on other sites

Probably a combination of several things is whet you are seeing. The first is to the computer 0.61, might be 0.6099999999 . The second is that most bot code would round the answer in it's favor so that it can't be ripped of and instead depends on your intelligence. They don't round in your favor to prevent people from getting extra gold from them or people would abuse it by selling tiny qty's but just enough to drain gc from constant rounding.

Share this post


Link to post
Share on other sites

Actually Wizzy does not care if he losses 100K gc, he is not playing any more :(

Share this post


Link to post
Share on other sites

Hi,

 

I've noticed this behavior of certain bots as well - for quite some time actually. But I've never got around to more than PMing the bot owner who was more or less helpless as to the coding as well, usually.

 

BUT: (addressing Learner's message in particular here) The curious thing is, that the root cause of this issue must be way beyond simple rounding problems: Take Bot Islena for example (not intending to ruin somone's business here, seriously! I love this bot and whenever I'm in the vicinity I'm still enjoying doing business with her by all means - you just have to know how to "deal with her properly" :happy: )

So, Islena has quite a few calculations on her that should really challenge any serious programmer for an explaination (I'm not in-game right now, so I'll try to get it right as best as I can from memory):

 

Coal for example: buying at 2.3

-> Player sells 100 coal: she offers 229 gc :inquisitive:

-> Player sells 40 coal: she offers (the correct) 92 gc :wacko:

80 coal work as well, but 20 don't (I think) ... something like that.

 

... ah, I found a log describing exactly what I mean:

 

 

[PM from Islena: Hello Gwaew, I am a trade bot]
[20:45:06] [PM from Islena: To sell me an item, just drop it in the trade window]
[20:45:06] [PM from Islena: To buy an item, use the BUY command eg buy 1 pickaxe]
[20:45:06] [PM from Islena: At any time during the trade you may click accept or use the #total command to get the trade details.]
[20:45:07] [PM from Islena: I won't put coins in the trade window until you click accept once.]
[20:45:10] [PM from Islena: I am buying an unlimited number of Sulfur for 2.3 gc each.]
[20:45:12] [PM from Islena: I owe you: 229gc (/Islena #total to see the details)]
[20:45:22] [PM to Islena: total]
[20:45:23] [PM from Islena: Hello Gwaew, my name is Islena. ]
[20:45:23] [PM from Islena: ===== Displaying your transaction details =====]
[20:45:23] [PM from Islena: ===============================================]
[20:45:24] [PM from Islena: *** Items you put in the trade window: ***]
[20:45:24] [PM from Islena: 100 Sulfur @ 2.3gc = 230gc]
[20:45:24] [PM from Islena: ===============================================]
[20:45:24] [PM from Islena: *** Items I put in the trade window: ***]
[20:45:24] [PM from Islena: 229 Gold Coins @ 1gc = 229gc]
[20:45:24] [PM from Islena: ===============================================]
[20:45:24] [PM from Islena: All coin amounts are correct!]
[20:45:24] [PM from Islena: ===============================================]

 

So in other words: in some way she's doing the correct math - just not following up on it :P

 

Again, to Krrick, rhyddler and whoever else in Riva: I love your bot and I do apologize if my using her as a "bad example" causes any harm.

To all others reading this: Islena is NOT alone - many other bots probably act just like her, so please don't stop business with her or anything - just trade her the amounts she's paying correctly for (40 or 80 pieces or soemthing...), if you want that one "extra" gc you deserve.

 

(for those interested here are some more examples just to illustrate:)

 

20:52:45] [PM from Islena: I am buying an unlimited number of Sulfur for 2.3 gc each.]
[20:52:46] [PM from Islena: I owe you: 114gc (/Islena #total to see the details)]
[20:53:00] [PM to Islena: total]
[20:53:00] [PM from Islena: Hello Gwaew, my name is Islena. ]
[20:53:01] [PM from Islena: ===== Displaying your transaction details =====]
[20:53:01] [PM from Islena: ===============================================]
[20:53:02] [PM from Islena: *** Items you put in the trade window: ***]
[20:53:02] [PM from Islena: 50 Sulfur @ 2.3gc = 115gc]
[20:53:02] [PM from Islena: ===============================================]
[20:53:02] [PM from Islena: *** Items I put in the trade window: ***]
[20:53:02] [PM from Islena: 114 Gold Coins @ 1gc = 114gc]
[20:53:02] [PM from Islena: ===============================================]
[20:53:02] [PM from Islena: All coin amounts are correct!]
[20:53:02] [PM from Islena: ===============================================]
=> wrong
[21:03:06] [PM from Islena: Hello Gwaew, my name is Islena. ]
[21:03:06] [PM from Islena: ===== Displaying your transaction details =====]
[21:03:07] [PM from Islena: ===============================================]
[21:03:07] [PM from Islena: *** Items you put in the trade window: ***]
[21:03:07] [PM from Islena: 90 Sulfur @ 2.3gc = 207gc]
[21:03:07] [PM from Islena: ===============================================]
[21:03:07] [PM from Islena: *** Items I put in the trade window: ***]
[21:03:07] [PM from Islena: 206 Gold Coins @ 1gc = 206gc]
[21:03:08] [PM from Islena: ===============================================]
[21:03:08] [PM from Islena: All coin amounts are correct!]
[21:03:08] [PM from Islena: ===============================================]
=> wrong
[21:03:31] [PM from Islena: Hello Gwaew, my name is Islena. ]
[21:03:32] [PM from Islena: ===== Displaying your transaction details =====]
[21:03:32] [PM from Islena: ===============================================]
[21:03:32] [PM from Islena: *** Items you put in the trade window: ***]
[21:03:32] [PM from Islena: 40 Sulfur @ 2.3gc = 92gc]
[21:03:32] [PM from Islena: ===============================================]
[21:03:33] [PM from Islena: *** Items I put in the trade window: ***]
[21:03:33] [PM from Islena: 92 Gold Coins @ 1gc = 92gc]
[21:03:33] [PM from Islena: ===============================================]
[21:03:33] [PM from Islena: All coin amounts are correct!]
[21:03:33] [PM from Islena: ===============================================]
=> correct

Share this post


Link to post
Share on other sites

Probably a combination of several things is whet you are seeing. The first is to the computer 0.61, might be 0.6099999999 . The second is that most bot code would round the answer in it's favor so that it can't be ripped of and instead depends on your intelligence. They don't round in your favor to prevent people from getting extra gold from them or people would abuse it by selling tiny qty's but just enough to drain gc from constant rounding.

 

Then if the bot owners are allowed to input a price as 0.6099999999 (infinity), then when queried the bot should respond with the full price and not a rounded up price!

 

And no matter how you cut it, 100 x 0.60999999 would be 61 and not 60!

Share this post


Link to post
Share on other sites

60.999999 is not valid number of gc. If the bot rounds up to 61, then people will start selling one at a time @ 0.6099999 to 1 gc each instead of the intended 0.61. If the bot rounds down, then you get this problem.

Share this post


Link to post
Share on other sites

[20:45:23] [PM from Islena: ===============================================]
[20:45:24] [PM from Islena: *** Items you put in the trade window: ***]
[20:45:24] [PM from Islena: 100 Sulfur @ 2.3gc = 230gc]
[20:45:24] [PM from Islena: ===============================================]
[20:45:24] [PM from Islena: *** Items I put in the trade window: ***]
[20:45:24] [PM from Islena: 229 Gold Coins @ 1gc = 229gc]
[20:45:24] [PM from Islena: ===============================================]
[20:45:24] [PM from Islena: All coin amounts are correct!]
[20:45:24] [PM from Islena: ===============================================]

 

[20:53:01] [PM from Islena: ===============================================]
[20:53:02] [PM from Islena: *** Items you put in the trade window: ***]
[b][20:53:02] [PM from Islena: 50 Sulfur @ 2.3gc = 115gc][/b]
[20:53:02] [PM from Islena: ===============================================]
[20:53:02] [PM from Islena: *** Items I put in the trade window: ***]
[b][20:53:02] [PM from Islena: 114 Gold Coins @ 1gc = 114gc][/b]
[20:53:02] [PM from Islena: ===============================================]
[20:53:02] [PM from Islena: All coin amounts are correct!]
[20:53:02] [PM from Islena: ===============================================]


[21:03:07] [PM from Islena: ===============================================]
[21:03:07] [PM from Islena: *** Items you put in the trade window: ***]
[b][21:03:07] [PM from Islena: 90 Sulfur @ 2.3gc = 207gc][/b]
[21:03:07] [PM from Islena: ===============================================]
[21:03:07] [PM from Islena: *** Items I put in the trade window: ***]
[b][21:03:07] [PM from Islena: 206 Gold Coins @ 1gc = 206gc][/b]
[21:03:08] [PM from Islena: ===============================================]
[21:03:08] [PM from Islena: All coin amounts are correct!]
[21:03:08] [PM from Islena: ===============================================]

 

The amount is being calculated correctly in one instance, and then later incorrectly when it comes to calculating the final value.

 

I accept the logic that converting from a float (the actual per item value) to an integer (the final value in gc) you have to round down, but the bot seems to be rounding down even when it's not appropriate.

 

Edit: Somehow I thought you might be able to bold stuff in a code block. Reduced the size of the quote to make it more obvious what I'm referring to.

Edited by tork_unib

Share this post


Link to post
Share on other sites

The difference between the 2 calculations is that the first one gives out the float value ([PM from Josi: 101 Fire Essence @ 2.55gc = 257.55gc]), only the final gold coin calculation gives out an integer.

As Learner alredy explained, the problem is the conversion itself; float or even double are simply not that precise for financial calculations.

Edited by Sir_Odie

Share this post


Link to post
Share on other sites

Ok, I've sat down and looked at this myself, and it turns out, you're right, my assumptions are wrong, so apologies Learner.

 

<?php
$float_val = 100 * 2.3;
$int_val = intval($float_val);
echo 'Float: '.$float_val."\n";
echo 'Int: '.$int_val."\n";
?>

 

The integer value for 230.0 ends up being 229, not 230 like you really would expect.

 

Mind now slightly blown, but that's how we learn, right?

Share this post


Link to post
Share on other sites

Ok, I've sat down and looked at this myself, and it turns out, you're right, my assumptions are wrong, so apologies Learner.

 

<?php
$float_val = 100 * 2.3;
$int_val = intval($float_val);
echo 'Float: '.$float_val."\n";
echo 'Int: '.$int_val."\n";
?>

 

The integer value for 230.0 ends up being 229, not 230 like you really would expect.

 

Mind now slightly blown, but that's how we learn, right?

Yes, and if we take steps to try to adjust the result, we risk pushing it in the other direction in different special cases.

Share this post


Link to post
Share on other sites

Mind you, I haven't tested this idea, but could calculations be done in integer form instead of float? I have not tested the idea, but the basic concept would be:

 

Prices can only have one decimal place (i.e. 0.6 not 0.43).

All numbers would be stored as integers

- Look for decimal point in string. Only allow 1 digit after the decimal point (truncate anything else)

- if decimal point exists and not last position in string, remove decimal point and convert to integer (effectively multiplying it by 10 without a float math function)

- else, add 0 at end of string and convert to integer (effectively multiplying it by 10 without a float math function)

 

- - Example: cost of 2.3 > remove the decimal becomes 23 > convert to integer becomes 23

- - Example: quantity 100 > no decimal so add a 0 becomes 1000 > convert to integer becomes 1000

 

Do integer math (i.e. 1000 * 23 = 23000)

 

Then, either convert to float (23000 / 100 = 230)... or if that introduces a float error as well:

- convert to string

- add decimal 2 positions from the right (i.e. 23000 = 230.00)

Share this post


Link to post
Share on other sites

As all the stored values and calculations are invisible to the customer, you can do all the math in

integer format using 0.1 gc as unit (i.e. a price/item of 2.3 gc is stored as 23).

 

Bots customers never need to put in prices, so there's no problem with needing float input there.

 

For the output:

- if selling items: check last digit of the total price, if it's not zero, divide by 10 and add 1 (rounding up fractions)

- if buying, just divide by 10, an eventual fraction will be discarded

(in both the case, you'll have to use integer division of course, so no fractions and conversions to float)

 

For output of the final prices, why would you bother with a decimal point, as you can only deal in whole coins anyway?

 

And for output of the inventory prices: write "price\10" "." "price modulo 10" "0", no conversions to float or string

needed.

 

(@Ghrae: with your exemple you are dividing by 100 to get the final displayed value, using 0.1 gc as unit; it looks like

that would give you prices that are 1/10th of what they should be. Nice for buyers, bad for sellers ;) )

Share this post


Link to post
Share on other sites

Came across that approach myself during a rather sleepless night of floating-point bug rtfm. One article I came across (http://www.theregister.co.uk/2006/09/20/floating_point_numbers_2/) referred to it as 'scaled integers'.

 

The idea behind scaled integers is to fix a precision at the outset and use it consistently for all the operations involving a particular type of value. Take working with dollars and cents as an example. Instead of using a floating point to represent the value '$1.37' we would use an integral number to hold the value '137' and remember that the value has an implicit a scaling factor of 10-2.

 

The advantage of this approach is its simplicity; we can use native data types and the integral operations built into our hardware so the storage is efficient and the calculations are fast.

 

However, the problem with this approach is its inflexibility. The least significant place is chosen early in a project and it's difficult to change afterwards. If calculations result in numbers more precise than the representation then the extra precision is lost by truncation. Such errors accumulate and while steps can be taken to reduce them they are inhibited by encapsulation across function and class boundaries. Because flexibility and extensibility are important in software architecture, this is probably a sufficiently severe shortcoming to render this attractively simple solution unusable in many cases.

Share this post


Link to post
Share on other sites

There are very good reasons to have prices like 0.0152 such as to give a slightly better price to players selling the bot large qty's of an item.

 

Another is when multiple items are involved, you want keep as much precision for all the items as possible before any rounding, enhancing the benefit to people doing larger transactions or buying & welling items at the same time.

 

Also keep in mind, stuff like this actually happens in real life. Buy 10.1 gallons of gas at $3.99 and see how much they charge you!

Share this post


Link to post
Share on other sites

Then please show the entire price for the bot so a player knows exactly what the price is and not some truncated version of the price.

 

/botname inv :

sulfur 0.44999999 and not sulfur 0.5

Share this post


Link to post
Share on other sites

Then please show the entire price for the bot so a player knows exactly what the price is and not some truncated version of the price.

 

/botname inv :

sulfur 0.44999999 and not sulfur 0.5

 

Well... IFF I remember correctly 0.5 would still be 0.5 but 0.3 is "impossible" to store correctly in a float...

This is because a float is stored in base 2. so just as we have 1, 2, 4, 8 etc for the integer part, we get 1/2, 1/4, 1/8 etc.. so 0.5, 0.25, 0.125 etc is possible to represent. but 0.3 is 0.25+0.03125+0.015625+... thus "never" reaching the exact value. Using the three first numbers we end up at 0,296875 (and probably a few more decimals)

 

So it is impossible to show the entire price as it might have infinite decimals...

 

Regarding the problem at hand, there should be ways to handle this. Perhaps add a small amount before rounding down allowing for some small errors in the calculations (0.00001 might be enough, this could be tested by calculating a lot of different cases)

Share this post


Link to post
Share on other sites

As all the stored values and calculations are invisible to the customer, you can do all the math in

integer format using 0.1 gc as unit (i.e. a price/item of 2.3 gc is stored as 23)

 

That's all good until you're actually selling an item at 23gc. ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×