I need know what best of weps

lkhafopieh

LV:one (Fist) Phys Att 3-4 OR LV:one (Claw) Phys Att 9-12 what best use it and more Att hard?

Loomer - Lost City

The question is a bit difficult to understand.

Michael_Dark - Lost City

At low levels, it doesn't really matter.

Olbaze - Sanctuary

Is 9 smaller or larger than 4?

b:cute

Deora - Lost City

Olbaze - Sanctuary wrote: »

Is 9 smaller or larger than 4?

b:cute

wellllllllllllllllllllllllllllllllllllllllllllllllll

4 can be larger then 9 IF 9 is a unsigned integer and 4 is signed, then yes, 4 is bigger

From a computer memory address standpoint anyway

jemima

Deora - Lost City wrote: »

wellllllllllllllllllllllllllllllllllllllllllllllllll

4 can be larger then 9 IF 9 is a unsigned integer and 4 is signed, then yes, 4 is bigger

From a computer memory address standpoint anyway

Not really. 9 is still larger than 4.
Maybe if you argue that you're storing your data in nibbles and interpreting unsigned 9 (1001) as a signed integer, but that would just be completely ridiculous, and you may as well argue that you're using a field in reverse order.

Deora - Lost City

jemima wrote: »

Not really. 9 is still larger than 4.
Maybe if you argue that you're storing your data in nibbles and interpreting unsigned 9 (1001) as a signed integer, but that would just be completely ridiculous, and you may as well argue that you're using a field in reverse order.

How it is stored in memory technically makes it larger, and a signed 4 is 32,773 unsigned, at least that is how a computer sees it, therefore making it larger then 9 IF the 9 happens to be unsigned it is just plain 9

Borsuc - Raging Tide

Deora - Lost City wrote: »

How it is stored in memory technically makes it larger, and a signed 4 is 32,773 unsigned, at least that is how a computer sees it, therefore making it larger then 9 IF the 9 happens to be unsigned it is just plain 9

Wow when was the last time you programmed a computer? Hello? Today's CPUs use two's complement not sign-bit bias.

4 signed is 4 unsigned in two's complement. Numbers 32768 and above (for 16 bit integers) are "negative" in signed form, with them having this "cool" property that, adding them together with same addition arithmetic as unsigned form, and discarding everything above the integer limit (i.e truncate to the integer size you use), and you have a valid signed addition.

Some explanation for others. To get two's complement invert all bits and add 1.

Example:

signed 1 is 00000001
unsigned 1 is 00000001

unsigned 255 is 11111111 which is -1 signed

why?

invert 1 -> 11111110
add 1 -> 11111111
-1 = 11111111 in two's complement

This is why it's used: What happens when we add let's say, 3 (which is 00000011) with -1 (which is 11111111)?

00000011 +
11111111

= 100000010, truncate to 8-bits, wow you have the number '2' by using the same addition as in unsigned form! Basically CPU doesn't even need to know what type of number you have!

Don't believe me? Pop up windows calculator, write -1 then go to bin and check "byte" (since I gave examples with 8-bit integers). b:bye

Lenley - Dreamweaver

Sometimes I just love this game's playerbase. Unfortunately this is a rare feeling

Alphae - Lost City

This thread is fantastic, I learned so much. b:thanks

About LV:one weapons. b:avoid

Gryphyyn - Heavens Tear

Michael_Dark - Lost City wrote: »

At low levels, it doesn't really matter.

Short, simple, and to the point.

Cun - Lost City

jemima wrote: »

Not really. 9 is still larger than 4.
Maybe if you argue that you're storing your data in nibbles and interpreting unsigned 9 (1001) as a signed integer, but that would just be completely ridiculous, and you may as well argue that you're using a field in reverse order.

Deora - Lost City wrote: »

How it is stored in memory technically makes it larger, and a signed 4 is 32,773 unsigned, at least that is how a computer sees it, therefore making it larger then 9 IF the 9 happens to be unsigned it is just plain 9

Borsuc - Raging Tide wrote: »

Wow when was the last time you programmed a computer? Hello? Today's CPUs use two's complement not sign-bit bias.

4 signed is 4 unsigned in two's complement. Numbers 32768 and above (for 16 bit integers) are "negative" in signed form, with them having this "cool" property that, adding them together with same addition arithmetic as unsigned form, and discarding everything above the integer limit (i.e truncate to the integer size you use), and you have a valid signed addition.

Some explanation for others. To get two's complement invert all bits and add 1.

Example:

signed 1 is 00000001
unsigned 1 is 00000001

unsigned 255 is 11111111 which is -1 signed

why?

invert 1 -> 11111110
add 1 -> 11111111
-1 = 11111111 in two's complement

This is why it's used: What happens when we add let's say, 3 (which is 00000011) with -1 (which is 11111111)?

00000011 +
11111111

= 100000010, truncate to 8-bits, wow you have the number '2' by using the same addition as in unsigned form! Basically CPU doesn't even need to know what type of number you have!

Don't believe me? Pop up windows calculator, write -1 then go to bin and check "byte" (since I gave examples with 8-bit integers). b:bye

Can you guys do my math homework? Or perhaps fix my computer?

Deora - Lost City

Borsuc - Raging Tide wrote: »

Wow when was the last time you programmed a computer? Hello? Today's CPUs use two's complement not sign-bit bias.

4 signed is 4 unsigned in two's complement. Numbers 32768 and above (for 16 bit integers) are "negative" in signed form, with them having this "cool" property that, adding them together with same addition arithmetic as unsigned form, and discarding everything above the integer limit (i.e truncate to the integer size you use), and you have a valid signed addition.

Some explanation for others. To get two's complement invert all bits and add 1.

Example:

signed 1 is 00000001
unsigned 1 is 00000001

unsigned 255 is 11111111 which is -1 signed

why?

invert 1 -> 11111110
add 1 -> 11111111
-1 = 11111111 in two's complement

This is why it's used: What happens when we add let's say, 3 (which is 00000011) with -1 (which is 11111111)?

00000011 +
11111111

= 100000010, truncate to 8-bits, wow you have the number '2' by using the same addition as in unsigned form! Basically CPU doesn't even need to know what type of number you have!

Don't believe me? Pop up windows calculator, write -1 then go to bin and check "byte" (since I gave examples with 8-bit integers). b:bye

I regret being half asleep when I posted that... I will admit I got that wrong...

Either way here is basically the reasoning behind how my train of thought went through when I posted those above

My Fail Thought Train wrote:

First lets start off with some basics and assume 8 bit numbers for the sake of simplicity

If the number is signed (meaning it can be negative) you have a number range of -128 to 127

If the number is unsigned (meaning it CAN NOT be negative) you have a range of 0 to 255

Now that we have that down we can break it down and see right off that bat that signed 4 will obviously be larger then unsigned 9

Signed 4's position from lowest possible number is 132

Unsigned 9's position from the lowest possible number is 9

Anyway here is a nice explanation of binary for those who don't know, it really isn't that hard after you see it, just a bit different...

This is the basic number system for an 8 bit number, which a bit is either on or off, considering that electricity can only be in those two states we made the binary number system which if we have 8 ons and offs turns into this

128 64 32 16 8 4 2 1


0 0 0 0 0 0 0 0


Then lets say you wanted -1, how would that look?

This is the negative sign, and why it gets limited to a "smaller" range
|
1 1 1 1 1 1 1 1

And that is what -1 looks like

Why does it look like that? -1 is 127 spaces away from -128 which is

1 0 0 0 0 0 1 0

Now lets say we have the number 127, how would that look?

0 1 1 1 1 1 1 1

See how 1 + 2 + 4 + 8 + 16 + 32 + 64 adds up to 127?

Alright what if we were to add 1?

1 0 0 0 0 0 0 0

Uh oh, we just had an "overflow" if this were a signed integer, what would it be now?
-128

This is where unsigned numbers come into play and are particularly useful

1 0 0 0 0 0 0 0

Is actually 128 unsigned as unsigned numbers do not use the first bit as a denotation for the sign of the number (either positive or negative)

From there you can continue counting up and get 129
1 0 0 0 0 0 0 1
130
1 0 0 0 0 0 1 0
131
1 0 0 0 0 0 1 1

And so on, signed numbers though are a bit different

1 0 0 0 0 0 0 0

Since this starts out as -128 you have to count up from there and its a bit weird, such as

-127
1 0 0 0 0 0 0 1
-126
1 0 0 0 0 0 1 0
-125
1 0 0 0 0 0 1 1

And so on

So you can see how me being half asleep and not really pay attention to that half baked idea that did make sense at the time turned out to be very wrong

Either way I leave you with this just to show off (no its not me I just found it interesting) as it shows in a rather neat way how binary works (sort of)

Anyway I'm done with things related to math for now, I'll leave that up to the archers from now on

Olbaze - Sanctuary

Cun - Lost City wrote: »

Can you guys do my math homework? Or perhaps fix my computer?

Programmers don't necessarily do math.

And I don't think programmers are magic fairies that can touch their routers, causing it to turn your 1995 graphics card into something that was put on the market 2 months ago.

But I wouldn't know, I study math.

b:cute

Deora - Lost City

Olbaze - Sanctuary wrote: »

Programmers don't necessarily do math.

And I don't think programmers are magic fairies that can touch their routers, causing it to turn your 1995 graphics card into something that was put on the market 2 months ago.

But I wouldn't know, I study math.

b:cute

Exactly, I do a lot of programming and I never really do much with binary and math etc, you don't really need to be able to do it as every programming language out there already has all the functions for it built in so needing to know how all that math works is left up to the Archers of Perfect World to figure out

SecretFlame - Archosaur

I'm just gonna answer your question

9 is bigger than 4 look for the one with more attack, good luck

maybe what you want to know is what wep is better the Fist or the Claw, well the best you can get lol they will be diferent at very high levels in what is related to atacks per second,.. right now just enjoy the game and use whatever you want, check the blademaster subforum for more help

volst

Well Seven ate Nine, so get 4. Unless you want to get eaten too.

Boogiepanda - Raging Tide

Get a bow ffs.

Olbaze - Sanctuary

Deora - Lost City wrote: »

Exactly, I do a lot of programming and I never really do much with binary and math etc, you don't really need to be able to do it as every programming language out there already has all the functions for it built in so needing to know how all that math works is left up to the Archers of Perfect World to figure out

I'm the opposite: I do math but not programming. Though I'd hope that to change, since it's kinda annoying to go all corner of woe-ish when I realize that some problem I want to solve is too massive or too troublesome to do manually.

volst wrote: »

Well Seven ate Nine, so get 4. Unless you want to get eaten too.

But THIS IS PERFECT WORLD! so Seven is probably high on Ironguard Powder to begin with, he's no threat.

ThanosQRt - Dreamweaver

what if 4 is a float and 9 an unsigned int? b:avoid

ImReallyWhyt - Heavens Tear

awsome greatness on copy and pastingb:victory This is worse than a guide on dmg.

Deora - Lost City

ThanosQRt - Dreamweaver wrote: »

what if 4 is a float and 9 an unsigned int? b:avoid

*continues on to explain what floats are*

Alright so we had our

128 64 32 16 8 4 2 1

0 0 0 0 0 0 0 0

So you may be asking, what the hell does something like 4.1 look like? Since their isn't a decimal place in it

Nope, there isn't, this is were floating point numbers come into play, and well they are confusing and can be annoying, and Intel gets confused by them

Floating point numbers allow you to use decimal numbers at a price, what is that price? Remember how I said that numbers that are negative needed a sign bit (the 1 at the beginning, unsigned numbers just kept counting from 128)

The standard for how binary deals with floating point numbers is made by the IEEE (they make standards for everything electronic, the ISO does too but for other stuff)

So taking
0 0 0 0 0 1 0 0
Which is 4, how does it turn into 4.1?

Well we have to expand into 32 bits at least and that turns that binary string into something four times as long
4294967296 2147483648 1073741824 536870912 268435456 134217728 6710864 33355432 16777216 8388608 4194304 2097152 1048576 524288 262144 131072 65536 32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1

I honestly ran out of colors to think of for this... so white will have to do

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Big isn't it?

Well consider that most people's computers now a days use numbers 2 times as big as that (64 bit) even though 32 bit is still pretty widely used 64 bit is becoming very common to use

Anyway, this is how it works (please note that this is big endian encoding to be able to work with windows calculator even though most hex editors show things in little endian but I don't feel like explaining how all that works so here it goes)

Well considering that is such a giant number... I made a nifty little PHP script that converts it to hexadecimal and I'm pretty sure everyone knows what hexadecimal is Windows Calculator Screenshot of hex

And that is how I'll explain it mostly since it is way shorter

[PHP]<?php
$f = 4.1; //This is the floating point number you want to see in hex
echo bin2hex(pack("f*", $f)); //returns 33338340
?>[/PHP]

So what does 3338340 look like in binary (how it would look in the above 32 bit binary anyway) just copy and paste that into Calculator in hex mode you can see
Disregard this, I almost forgot Windows Calc is big endian and the above hex string is little endian and that is how byte encodings work most of the time and Windows Calc just had to be different
0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 0 0 0
Which is giant isn't it?

This part is still true, mostly
You could possibly get rid of the first 16 bits and make it a half float, but that is incredibly out of date and not even calculators really use that anymore
End disregard

Anyway, other then the little mistake I made above, I do hope to have (sort of) explained how floats work

Borsuc - Raging Tide

@Deora: the negative number system you mentioned is called the biased representation or sign-bit bias to refer to all-sized integers.

All numbers are relative to the number that has '1' only to the sign (leftmost) bit and '0' everywhere else.

For 8-bits, this would be 128 (10000000). To do arithmetic with this system, all you have to do is an extra subtraction of 128 after every operation. Only problem compared to two's complement is that you need different addition/subtraction instructions for negative numbers.

It is a valid representation and used in some software implementations... but just not in today's CPUs (or the whole x86 line for that matter).

e.g:

'0' in sign-bit bias would be '10000000'
'-1' would be '01111111'
'1' would be '10000001'

It's a nice and rational system but just not as efficient (for a CPU, which relies on limited instructions to encode)

EDIT: Since you were talking about floats, it's also how the exponent in floating point is stored.

Deora - Lost City

Borsuc - Raging Tide wrote: »

@Deora: the negative number system you mentioned is called the biased representation or sign-bit bias to refer to all-sized integers.

All numbers are relative to the number that has '1' only to the sign (leftmost) bit and '0' everywhere else.

For 8-bits, this would be 128 (10000000). To do arithmetic with this system, all you have to do is an extra subtraction of 128 after every operation. Only problem compared to two's complement is that you need different addition/subtraction instructions for negative numbers.

It is a valid representation and used in some software implementations... but just not in today's CPUs (or the whole x86 line for that matter).

e.g:

'0' in sign-bit bias would be '10000000'
'-1' would be '01111111'
'1' would be '10000001'

It's a nice and rational system but just not as efficient (for a CPU, which relies on limited instructions to encode)

EDIT: Since you were talking about floats, it's also how the exponent in floating point is stored.

On x86 and ARM I know that it does it like I had in my post

-1 is 11111111
1 is 00000001

And well considering I only used 8 bit for simplicity, if I went higher to 32 or 64 for explanation on how it would work you'd see a whole bunch of 1s before it

64 bit -1
1111111111111111111111111111111111111111111111111111111111111111
32 bit -1
11111111111111111111111111111111
16 bit -1
1111111111111111
8 bit -1 (like I had)
11111111

As technically -1 is the highest possible number in signed binary (odd I know) as it counts from the lowest possible number because of the sign bit

Which in 64 bit
-9,223,372,036,854,775,808 is
1000000000000000000000000000000000000000000000000000000000000000

And it counts up from there until it hits -1 like the above and then it goes all 0 and counts up from there, either way, left most bit is still the negative sign and its 1 if negative, 0 if positive

And just for giggles, if you are using a 64 bit os and try and put that number in your Calculator as a positive number you can see a buffer overflow (well actually putting 9,223,372,036,854,775,807 and adding one to it) and then go negative

You can do the same thing by adding 1 to 2,147,483,647 on a 32 bit os

or adding one to 32,767 in 16 bit

or adding one to 127 in 8 bit

and adding 1 to 7 in 4 bit

DaKillanator - Raging Tide

su liek fist r da sheet?