Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dutrius]

Today I learned something about division in C#.

Code: [Select]

int aNumber = 30;
double result;

result = aNumber / 100;       //This returns 0, which is wrong.
result = aNumber / 100.0;     //This returns 0.3, which is correct.

Apparently, if you divide by an integer, you get an integer.
If you divide by a real number, you get a real number.

[Telgin]

That kind of behavior is pretty typical in C-like languages, and has definitely caught me off guard a few times.  It's also annoying to have to sprinkle a lot of (double) casts all over the place in math heavy code as a result, but it is what it is.

[itisnotlogical]

Speaking of numbers and weird behavior, here's a helpful video on floating point errors and why it happens.

Linky dinky

[TheBiggerFish]

Java's BigDecimal class FTW.

[Skyrunner]

Java's BigDecimal class is terrible, not because of any fault in itself, but because Java is stupid and doesn't support arithmetic overloading >:l

I mean, if you want to do math with BigDecimal, your code will look really ugly.

// with primitives a, b, c
return (-b + Math.sqrt(b*b - 4 * a * c) ) / a / 2
// with BigDecimal a, b, c
return b.negate().add((b.pow(2).subtract(BIGSQRT(a.multiply(c).multiply(BigDecimal(4)))).divide(a)

and so on. BigInt doesn't have a sqrt method for obvious reasons (impossible to ensure infinite precision), but I feel like it would look so much simpler if Java just had operator overloading.... All the maths libraries of the world cry :v It's probably worse for vector and matrix math.

[TheBiggerFish]

*shrug*
That's what documentation is for.

[Putnam]

i say we should all just switch to prefix notation

[Orange Wizard]

#reversepolishmasterrace

[Gatleos]

I remember one of my programming professors going off on a digression about reverse polish notation just so that he could drop that reverse polish sausage xkcd at the end of class and everyone would understand it.

[Bumber]

I think you might have to convert them into bytearrays, but there's something about needing to set encoding (i.e., utf8, etc.) and I don't know how to specify that.

Code: [Select]

b"this string is converted to a bytearray, usually UTF-8 encoding, I think"
bytes ("the bytes function will return an encoded bytearray", "utf-8")
I know zilch about networking though so I can't really help further.

Thanks. Looks like it's working:

Spoiler: Client Code (click to show/hide)

Code: (cli.py) [Select]

from socket import *
import os, sys

def recvAll(sock, numBytes):
recvBuff = b"" #The buffer
tmpBuff = b"" #The temporary buffer

while len(recvBuff) < numBytes: #Keep receiving until all is received
tmpBuff = sock.recv(numBytes) #Attempt to receive bytes
if not tmpBuff: #The other side has closed the socket
break
recvBuff += tmpBuff #Add the received bytes to the buffer

return recvBuff

def main():
if len(sys.argv) < 3: #Command line checks
print("USAGE python " + sys.argv[0] + " <Server Address> <Server Port>")

serverAddr = sys.argv[1] #URL or IP of server
serverPort = int(sys.argv[2]) #Port number of control channel
connSock = socket(AF_INET, SOCK_STREAM) #Create a TCP control socket for sending and receiving

print("Attempting to connect to server...")
try:
connSock.connect((serverAddr, serverPort)) #Connect to the server
except:
sys.exit("Connection failed.")
print("Connection established.\nHandshaking...")
while connSock.send(b'\x01') < 1: #Send 'hello'
continue
while connSock.recv(1) != b'\x01': #Wait for 'hello'
continue
print("Handshaking complete.\nAwaiting commands.\n")
cmd = input("FTP> ")

#Stuff goes here

print("\nTerminating connection...")
while connSock.send(b'\x02') < 1: #Send 'goodbye'
continue
while connSock.recv(1) != b'\x02': #Wait for server to terminate
continue
connSock.close()
print("Connection terminated.")

main() #Start the program


Spoiler: Server Code (click to show/hide)

Code: [Select]

from socket import *
import os, sys

def recvAll(sock, numBytes):
recvBuff = b"" #The buffer
tmpBuff = b"" #The temporary buffer

while len(recvBuff) < numBytes: #Keep receiving until all is received
tmpBuff = sock.recv(numBytes) #Attempt to receive bytes
if not tmpBuff: #The other side has closed the socket
break
recvBuff += tmpBuff #Add the received bytes to the buffer

return recvBuff

def main():
if len(sys.argv) < 2: #Command line checks
print("USAGE python " + sys.argv[0] + " <Port>")

serverPort = int(sys.argv[1]) #Port number of control channel

serverSock = socket(AF_INET, SOCK_STREAM) #Create a TCP control socket for sending and receiving
serverSock.bind(('', serverPort)) #Bind the socket to the port
serverSock.listen(1) #Start listening for incoming connections

while True: #Forever accept incoming connections
print("The server is ready to receive...")
ctrlSock, addr = serverSock.accept() #Accept a connection; get client's socket
print("Connection established.\nWaiting for handshake...")

while ctrlSock.recv(1) != b'\x01': #Wait for 'hello'
continue
print("Handshake recieved. Returning handshake...")
while ctrlSock.send(b'\x01') < 1: #Reply 'hello', we're ready to accept commands
continue
print("Handshaking complete.")

cmd_id = None
while cmd_id != b'\x02': #Keep accepting commands until 'quit'
cmd_id = None
print("Waiting for command...")
while not cmd_id: #Wait for command
cmd_id = ctrlSock.recv(1)
print("Recieved command: {}".format(cmd_id[0]))
#Stuff goes here

print("Tearing down connection...")
while ctrlSock.send(b'\x02') < 1: #Say 'goodbye'
continue
ctrlSock.close()
print("Connection terminated.\n")

main() #Start the program


[Reelya]

That kind of behavior is pretty typical in C-like languages, and has definitely caught me off guard a few times.  It's also annoying to have to sprinkle a lot of (double) casts all over the place in math heavy code as a result, but it is what it is.

Everything needs to be cast before the CPU can do maths operations, because the machine code instructions are different for int, float, double.

C-like languages are designed for speed. Automatically casting everything to doubles on the off chance that is what you want would actually make programs that run slower because they're always casting things to double even when you don't want it. Doubles use more bytes too, meaning you can't have as many working variables in the cpu registers at once if all your variables were cast as doubles. So the CPU would be doing a pile of useless additional effort if the compiler assumed you wanted doubles for literally every maths operation.,The compiler needs to make a decision every time it sees two non-matching variable being added/multiplied etc, it needs to throw a cast in there to make them compatible, and they err on the side of efficiency/speed.

*shrug*
That's what documentation is for.

documentation doesn't help if you can't work out the nesting of the parenthesis. Sure, maybe you can concoct that nightmare of code then comment the line. But lets hope you never have to debug a bug in that code.

[Bumber]

Doubles use more bytes too, meaning you can't have as many working variables in the cpu registers at once if all your variables were cast as doubles. So the CPU would be doing a pile of useless additional effort if the compiler assumed you wanted doubles for literally every maths operation.

I don't think this is true for x86-64 architecture. The 32-bit mov instructions clear the upper half of 64-bit registers, and you have to shift bits left and right to get 32-bit numbers in and out of the upper halves. You're no better off with a float than a double unless you're on an x86 (a.k.a., i386.) You can pretty much forget about doing this on the SSE (xmm 128-bit, ymm 256-bit, and soon zmm 512-bit) vector registers. It's difficult enough to get doubles in and out of the upper areas of those (efficiently, anyway.) More to the point, I'm pretty sure C compilers simply don't put two floats into one register.

Edit: And if you were comparing doubles to ints: 'int' is 64-bit (a.k.a, long int) by default now on most C compilers. The vector registers are absolutely useless for ints, so you actually get more registers from doubles.

There's no reason not to use doubles over floats. There is good reason not to convert between ints and doubles (it's slow, so preferably use a double to begin with unless you really need an int.)

[Gentlefish]

The only reason I can ever remember casting (double) from int was when I needed to multiply x by 0.y or 1.y; It always came out as an int, but I needed to cast the double to ensure I got the division correct.

[Reelya]

Today I learned something about division in C#.

Code: [Select]

int aNumber = 30;
double result;

result = aNumber / 100;       //This returns 0, which is wrong.
result = aNumber / 100.0;     //This returns 0.3, which is correct.

Apparently, if you divide by an integer, you get an integer.
If you divide by a real number, you get a real number.

Actually, that's the correct result it should produce, come to think of it. C is modular and tries to produce consistent code for the same input.

"aNumber/100" is integer-integer division. This statement will always produce an int/int opcode.

the "=" operator is just a binary operator that takes the output from the RHS and tries to store it in the LHS, it will implicitly cast things if needed/possible, but it only does that on the entire result for the RHS, not any component parts thereof.

So, here, producing consistent code for the same input trumps trying to second-guess where the programmer made a mistake and arbitrarily cast variables by itself based on non-local code. Such automatically mutating code behaviour might be helpful sometimes to avoid manual casts, but many other times, producing basically arbitrary code for the same input would be sure to produce untrackable bugs. So the compiler goes for consistency of individual operations.

[Telgin]

That kind of behavior is pretty typical in C-like languages, and has definitely caught me off guard a few times.  It's also annoying to have to sprinkle a lot of (double) casts all over the place in math heavy code as a result, but it is what it is.

Everything needs to be cast before the CPU can do maths operations, because the machine code instructions are different for int, float, double.

C-like languages are designed for speed. Automatically casting everything to doubles on the off chance that is what you want would actually make programs that run slower because they're always casting things to double even when you don't want it. Doubles use more bytes too, meaning you can't have as many working variables in the cpu registers at once if all your variables were cast as doubles. So the CPU would be doing a pile of useless additional effort if the compiler assumed you wanted doubles for literally every maths operation.,The compiler needs to make a decision every time it sees two non-matching variable being added/multiplied etc, it needs to throw a cast in there to make them compatible, and they err on the side of efficiency/speed.

Oh, sure, I'm not denying that.  I'm mostly just saying that if someone is accustomed to scripting languages, it would probably catch them by surprise, and the fix is verbose.  "What?  Why doesn't 1 / 2 give me 0.5?  What do you mean I have to tell the compiler that 2 is a floating point value here?  It's a whole number!"  Of course, this kind of boils down to the difference between strongly and weakly typed languages in general.

And of course, let's not forget that doubles don't solve all math problems like you want anyway.  Good luck representing values like 1/3 as a double or float.  Or in the case of a game, which might use integers over some fixed base to represent fractions.  Diablo II, for example, represents HP in increments of 1/256, so 1 HP is 256.  That way it can very rapidly perform calculations that keep track of tiny amounts of damage or healing.  Instead of using floats or doubles, you just add integers.  Dwarf Fortress does this a lot too.