Tree Formula Discussion

[novaalpha]

for example when you cut up a tree board, the sqrt(saw*treeq) works most of the time, however it will sometimes turn out better or worse than that formula shows.

lol what

K, you should probably stay out of formula threads and actually try them instead of assuming what people told you is correct. maybe thats why you think your tree formula is 100% acturate.

Clue. Get some.

board = int sqrt saw*log, always 100% working

maybe not for idiots like you, though? ...

[stickman]

you must not do much tree farming. from world 3 when I did it I recall that at certain tree q x saw q it would turn out 1 less the the formula would dictate. pretty sure this is known...

EDIT: I would also like to point out that from doing a bit of game programming... most programers would not use a true squareroot function. I beleive finding the true squareroot is very time consuming as it involves loops. When I worked on a mobile game we used a square root approximation forumula which was mostly right but not always correct.

[DatOneGuy]

If you have a formula that works for thousands of trees and fuck up with a few, isn't that already enough? Seems like a great estimate to me if it's 99+% correct.
Besides that - if the formula is correct for thousands of trees and suddenly doesn't work for very few - than its most likely not a wrong formula but wrong data sets. I mean, if you collect data for 1000 trees, there will be a few typos in it. You can quite safely assume then, that the formula is correct. Would you mind sharing?

No, it's not enough. Those 1% typically show themselves when I vary one of the variables widely, meaning that it's not even close.

i bet its the formula gato listed but with correction for the tree quality if that works most of the time. I think the tree formula has the same problem as with the board formula.

for example when you cut up a tree board, the sqrt(saw*treeq) works most of the time, however it will sometimes turn out better or worse than that formula shows.

however its not the rounding of the formula thats the problem with it, its something else. almost like the q of either the tree or the saw is keeping its decimals and not being floored like in all other formulas. its probably the same in your tree formula.

awhile ago i suspected it was legacy code left over from when trees could be reduced in quality that was causing the problem. so basically if you stole stuff from the tree it would reduce its q.

anyways, regardless of that last point, i suspect your problem is the same situation with board q and the tree might keep its decimal value somehow. I suggest using only q10 tree seeds for your testing if this is the case.

From what I recall quite some time ago, everything keeps (but doesn't show) one decimal point. That tree could be q120.8 but show q120.
I've noticed it with boards but it's definitely not some -/+ going on, it's just the decimal throwing you off. I try to account for this in every formula I can, with trees it's damn near impossible since it has a -/+ somewhere at the end.

Clue. Get some.

board = int sqrt saw*log, always 100% working

maybe not for idiots like you, though? ...

I hope you realize you just look like a condescending retard there, because you didn't even fully read the post or were too stupid to understand it. stickman's been around forever, not posting all the time or having a newer account doesn't mean much at all when it comes to knowledge of the game.

[Saphireking65]

From what I recall quite some time ago, everything keeps (but doesn't show) one decimal point. That tree could be q120.8 but show q120.
I've noticed it with boards but it's definitely not some -/+ going on, it's just the decimal throwing you off. I try to account for this in every formula I can, with trees it's damn near impossible since it has a -/+ somewhere at the end.

I got q104 boards using a q64 log and q175 saw. The formula said it was to be q105, but it came out q104. If there were non showing decimals it would be going up in quality not down. Also, yes I made sure the character cutting the boards had 105 carpentry.

[DatOneGuy]

From what I recall quite some time ago, everything keeps (but doesn't show) one decimal point. That tree could be q120.8 but show q120.
I've noticed it with boards but it's definitely not some -/+ going on, it's just the decimal throwing you off. I try to account for this in every formula I can, with trees it's damn near impossible since it has a -/+ somewhere at the end.

I got q104 boards using a q64 log and q175 saw. The formula said it was to be q105, but it came out q104. If there were non showing decimals it would be going up in quality not down. Also, yes I made sure the character cutting the boards had 105 carpentry.

That does sound strange, perhaps you had the wrong Q log somehow, someone moved it or something? Even if it rounded to closest number and you had 63.5 and 174.5 it would be a q105 board.
I haven't extensively checked this so I can't say 100% how it rounds or if that's the only problem here (the extra decimal), but I've had it work with everything I've tossed at it so far.

[Potjeh]

I think it's due to the sqrt function only being an approximation, as Stick said.

[DatOneGuy]

I think it's due to the sqrt function only being an approximation, as Stick said.

Do you guys have any idea how it approximates?

[Breon]

I got q104 boards using a q64 log and q175 saw. The formula said it was to be q105, but it came out q104. If there were non showing decimals it would be going up in quality not down. Also, yes I made sure the character cutting the boards had 105 carpentry.

Yeah, same thing happened to me in W3. However, I found that increasing Carpentry by a single point (to expected board Q + 1) corrected the problem. So that is an issue with the soft-capping rather than the base formula.

[stickman]

might be one of these ones, no way to be sure though:

http://ilab.usc.edu/wiki/index.php/Fast_Square_Root

as you can see some are dead on acurate and some are barely off.... but with rounding could result in one less.

[sabinati]