The Beast Within -- A Guide To Blue Mage

We can't use Regal, so Ilabrat/Epona's is good. Begrudging/Epona's might pull ahead given that we're sacrificing some crit rate for WSD now, but it's likely dependent on your set and I haven't checked.

For SB, Ifrit +1/Karieyh +1 or Rufescent/Karieyh +1 are the best options outside of Epaminondas'.

No I don not understand that.
Please tell me how it would not add up
I believe i already explained how this would work in practice, but I would like to hear why you think this would not ad up.

and also how a computer does decimal math at all to begind with if you still stand on the ground its decimal math.
All registers and instructions in the CPU is based on binary math

How current are the Expiacion, Requiescat, and physical spell sets in the OP?

Few questions regarding these:

- Why not both Fotia neck/waist for Expiacion?

- Barring the pieces/augs listed, just go for max STR/MND on Req, max STR/attack on Expiacion, and max STR/Attack for physical spells?

WSD all the things

CDC & Expiacion was updated, but not req or vorpal

Fotia waist because fotia, no fotia neck because the mirage+2 has 25 STR

I don't think he's saying bit shifting couldn't work, just that if you actually started testing other WSD values besides 2, your numbers would likely be off. I agree with him. The fascination with 2^n bases because a select few parts of the game are better modeled that way is silly.

In regards to how the computer performs the calculations, it's all binary because that's how computers work although I think what's being implied is that the values for gear are stored as integers and either converted to a floating point number and multiplied or some integer math is performed (D * (100 + WSD)/100). If you think bit shifting is being used then you'll need to find a case to prove that.

you are trying to shift the burden of prof here.
Im not saying there is prof of bitshifting beeing used.
om saying the previous claims that is for sure is decimal is incorrect.

The burden of prof is on the person claiming there is only one possible outcome.
Which was not me.

If there is any other WSD number to play with then lets us her it as it could guide is in one direction or another


in short:
my claim was simply that because x/256 and x/1204 does not works is not prof of decimal math (or full floating math). Other solutions are still possible.


which is indeed incorrect.

Just because we cant see the sign of something does not mean its not present. if the resolutions a high enough we would nor be able to see it until we find a case where the resolutions is an issue (Exactly like now).

There might be tons of other functions that use this type of division but the resolutions is good enough for us to not see a difference.

But to be curiuous do we have any other divisions we know for sure is not done with simply bitshift within a decent size ?

im evn curios as where the limitations perception of only /256 and /1204 comes from as all of these can be moddeled with /665536 as well or as in my first attempt /~4bill

They would all come out the same

so what exactly is your point? that there could be literally an infinite amount of fractions to equal the number? because that's silly. it's very likely coded as a float or an integer and when you start adding in other sources of WSD, your posted examples won't always add up. The only logical way to calculate it would be as a decimal.

yes.
but al lthe fractiosn has to be a product of x^2 because that is how computers works.
and if you thinks it silly you probably havent done much code optimization at all.
And again nothing is done in decimal in a computer.
It all done in binary at its bottom level.


one of the suggestion is the possibility that

/256 and /1204 was never correct to begin with.
those number are assumed because they fit nice

Rou are fiscally saying they made 3 different division method
/256 (8bits)
/1024 (10bits)
/float ( "decimal") (

and claim its less silly and more complex than a simple model of e.g.
/65536 (16 bits)


because all of the above different models all fits into this single simple one ( from the data in this thread so far

anything that is done in /256 can be done in /1024 and anything done in /1024 can be done in /65536 which again can be done in /~4bill

so you are claiming its silly to have a simple unified division models because its to complex over a more complex and abitary model?


If you have example where it doesnt add up pleas enlighing me.
But at least know that anything you do in a computer is calculated in bineary form. Because ts going to be a long way uphill if you Think a computer calculates in decimals to begin with

okay so you're not reading at all. x/1024 is common with a lot of other stats in this game, see haste and fTP values, which is why it was originally thought of. i know what the *** the computer does to the code, but what you don't understand is if something is coded in a float or an integer can produce results that you're suggesting and they can also not when you factor in other amounts of it.

which goes back to the fact that calculating it as a decimal for the purposes of damage is the most logical way to do it.

No, I'm not. I'm saying there are two coded methods. On one side you have an obvious x / 1024, the 256 is just a common denominator of four. And the other is coded as a decimal.

You are right sometimes code is a float. Sometimes it not.
However you claimed the only possible solutions would be decimal.
which is incorrect, as there where other solutions.

it could be a float. Im not debating against that.
but you claimed it would be THE ONLY SOLUTION
which is incorrect, as I have proven another model that fits the provided data



now about my not reading. i perfectly read what you said about /1024.
however /1024 could also be /2048 or /4096.
The test numbers would still be the same, and you seem to either not read that or not understand that part.

you're right, there are literally an infinite number of solutions. so which one do you use?

ok so if you undestand that /256 could be /1024 but with 4 times the steps interval in the data.
You should be able to understand that both of these could be X times intervall of something with and even higher precision like like /65536

You use any of them until further data eliminates the incorect ones.
however what you DO NOT do.
Is select a favorite on and ignore any other possible solutions.
because that kind of mentality obstruct for openness of improving models.
It's simply just bad science.

That was my point to begin with.
You claimed there was only one solution. That was indeed incorrect.


That and that all math is done in binary in a computer.

you still aren't getting the point I see.

I think we all understand what you're trying to say, but for the purpose of optimizing WS sets, it doesn't actually matter if ishvara earring is 1310/65536 in 16-bit or 20million'ish/4billion'ish in 32-bit. Our damage is only rounded to whole numbers up to 99,999 and we don't need to determine that sort of precision. "0.02 in decimal" is enough as an understanding when we're just trying to determine if Ishvara is better than the other options.

[
I'm not sure what point you are are trying to make.
The only point ive been debating about was that you claimed only one possible solution.
Which I found incorrect as a statement.

any other point is kinda irrelevant as i was never debating on anything besides this single incorrect statements.

Correct
But people that where right was told there where incorrect which leave a trail if incorrect information in a public forum that other ppl will read and learn the wrong information.

The point was not if the model was incorrect or not to begin with.
but that we need to not write this in stone as later data might suggest otherwise.


Ramuh.Austar might be total correct that its done in float.
buts its a might. not a for sure. we can't just close our self of from gathering more correct information just because we want and answer rather than looking for the correct answered.

We need to keep mind that what was really proven was that its not a /256 or /1024 fractions.

An any small rounding errors might seem important now but once its applied enough time the issue might be severe.

The same thing I've been saying the whole damn time, that it's likely coded as a float or int and the most logical way to calculate damage with the piece is as a decimal.

everything you've even suggested has been pointless because we all know what binary is and most of us know floats and ints will give results that will align with base 2 fractions.

1: You are back pedaling on your statement.
You did not use the word likely.
You claimed it as the only possible solution.

There is a big difference but im happy to see you concur with my correction now.

2:
I believe you are once again incorrect
Due to how the coefficient and exponent interacts,
working in floats you do not have a linary scale like with intergers
I might be wrong as its getting late.


But as long as you agreed your debated statement was incorrect I think we have arrived at a common conclusion.

i did. i said it's likely coded that way since the beginning.

originally, because the only way a human should calculate it is as a decimal. and I still stand by the fact that it's the only solution you should use, particularly since when you factor in other forms of wsd, your shifts may not line up.

depends on how it's coded. you can get answers like 10.999999999999999 instead of 11 when if you do it by hand, the result should be an 11. which is my point about how your answers may not line up once you bring in multiple forms of wsd, which goes back to my point about decimal being the only way to do it.

1:
That was not the statement I was debating you about.
Is this a try at moving the goalpost or do i really have to quote your statement again?

2:
So you DID not use likely... You are now confirming that you made claim with 100% certanity.. which is it?
Whatever reason you stated something incorrectly still makes it incorrect.
That was my only point.


#3
So I was correct in you being incorrect again?
also the accuracy of floating points was not really what I was trying to inform you about.
It was the scale of floating points are not linary liek with intergers
aka there is not the same step value from a bit addition in the LSB when you value is in the middle of the range, as if its in the extreme of the range.
You have that with interges
If you want a linary scale you would probably need to use fixed points math instead.

But this is really going down a long nerdy talk just because you can yet to admit this wrong statement


Even though you are kinda seem to be backpedaling in a attempt to what appears to move the goalpost

Can you just answer straight if the quoted statement is correct is its fullness?
no adding if's and buts.
But do you mathematically believes that is the only possible to mathematiccally reach that data point ?
You can't figure out any other way to do it?

Please quote me then, because out of context, nothing you're saying makes sense. I've used the word likely in reference to both how it's coded and how your bitshift values wouldn't line up with other wsd factored in. So please, make some *** sense with your quotes, preferably not out of context.

What the *** are you talking about? I did use the word likely (in reference to how it's coded,) and I just said it in the post above yours.

No, you just refuse to accept that a bitshift is not how the result is obtained and want to continue on and on about how computers communicate in binary, completely ignoring the fact that this one instance lines up with the numbers you're suggesting, but may or may not when you add in other forms of WSD. And until then you can prove every value is a perfect bitshift, the only way you should calculate it is as a decimal.

Can you two do that ***in a not guide thread

I think you're being pedantic. I agree that there could be an implementation using bit shifted integers (and for server performance reasons there might be) but I also agree with the crux of his logic. For the sake of game mechanics analysis there's no compelling reason to model it that way unless you can find data that can't be explained by the accepted floating point model.

Mirage Stole is barely superior to Fotia. Something like .2% better. However, I suggest Fotia because it's massively easier to obtain and also has the chance to not use TP, which is fantastic.

The Savage Blade set in the OP is up-to-date. For Vorpal, just use your CDC set but STR/cdmg instead of DEX/cdmg.

CDC is best used with Almace/Sequence or Tizona/Almace. You almost never want to use Sequence as a MH if you're doing CDC unless you have no other options. For SB, Sequence and an HQ Hepatizon Sapara is an excellent combo.

That Colada would be so minimally better than an HQ Sapara that it's not even worth the hassle. Just stick with Sequence/Sapara for SB, Tizona/Almace for Expiacion, and either Almace/Sequence or Tizona/Almace for CDC.