Talk:Square root - Revision history

StDoodle at 08:28, 30 June 2010

2010-06-30T08:28:19Z

← Older revision		Revision as of 08:28, 30 June 2010
Line 56:		Line 56:

	If you included all of the overloaded versions of division(), what would you get? See, defining both parameters as floats in your only function declaration means they're converted to such before anything else is done with them, so of course you get the "normal math" result. In fact, I can pretty much guarantee from this that in mafia's source, there is no overloaded version of square_root() that implicitly takes an int type. You can go as far as to think of all the mathematical operator as functions that are overloaded to accept both int and float datatypes. Bleh. --[[User:StDoodle\|StDoodle (#1059825)]] 08:24, 30 June 2010 (UTC)		If you included all of the overloaded versions of division(), what would you get? See, defining both parameters as floats in your only function declaration means they're converted to such before anything else is done with them, so of course you get the "normal math" result. In fact, I can pretty much guarantee from this that in mafia's source, there is no overloaded version of square_root() that implicitly takes an int type. You can go as far as to think of all the mathematical operator as functions that are overloaded to accept both int and float datatypes. Bleh. --[[User:StDoodle\|StDoodle (#1059825)]] 08:24, 30 June 2010 (UTC)

			Edit to add; my whole point is that it isn't what the function RETURNS that controls whether or not "normal math" is followed for cases where the "int only" result will not equal the "float result," it's what the PARAMETERS are defined as. The confusion comes in the fact that division (the mathematical operator, treated as a function) is overloaded to accept int types even when the answer will be "wrong." Which could lead a newbie to assume that you need to specify at least one float type to get the "correct" answer, but this isn't COMPLETELY true; it depends on whether or not the function (including mathematical operators) in question is overloaded to accept just int parameters as well as float types. Blah, semantics. --[[User:StDoodle\|StDoodle (#1059825)]] 08:28, 30 June 2010 (UTC)

StDoodle at 08:24, 30 June 2010

2010-06-30T08:24:49Z

← Older revision		Revision as of 08:24, 30 June 2010
Line 54:		Line 54:
	5/3 = 1.6666666</pre>		5/3 = 1.6666666</pre>
	Some data types are actually converted automatically when required. --[[User:Bale\|Bale]] 07:18, 30 June 2010 (UTC)		Some data types are actually converted automatically when required. --[[User:Bale\|Bale]] 07:18, 30 June 2010 (UTC)

			If you included all of the overloaded versions of division(), what would you get? See, defining both parameters as floats in your only function declaration means they're converted to such before anything else is done with them, so of course you get the "normal math" result. In fact, I can pretty much guarantee from this that in mafia's source, there is no overloaded version of square_root() that implicitly takes an int type. You can go as far as to think of all the mathematical operator as functions that are overloaded to accept both int and float datatypes. Bleh. --[[User:StDoodle\|StDoodle (#1059825)]] 08:24, 30 June 2010 (UTC)

Bale: amazing and irksome, but TRUE!

2010-06-30T07:18:38Z

amazing and irksome, but TRUE!

← Older revision		Revision as of 07:18, 30 June 2010
Line 37:		Line 37:

	As we don't have any other functions that accept a numerical paramters without being specifically overloaded to return a type matching the least restricted parameter type, it's hard to tell what's "normal" behavior for a math function in KoLmafia; which is why I pointed out that one might be tempted to use mathematical operators as one's basis. By the way, by this logic, square_root(5) would return 2.0; which is a float, but after conversion from its int counterpart (similar to what happens in the division above). BTW, I'm not saying I personally thought that was how square_root() would behave; I'm just trying to defend the assumption that was made in the original code sample as being not unreasonable. --[[User:StDoodle\|StDoodle (#1059825)]] 23:31, 29 June 2010 (UTC)		As we don't have any other functions that accept a numerical paramters without being specifically overloaded to return a type matching the least restricted parameter type, it's hard to tell what's "normal" behavior for a math function in KoLmafia; which is why I pointed out that one might be tempted to use mathematical operators as one's basis. By the way, by this logic, square_root(5) would return 2.0; which is a float, but after conversion from its int counterpart (similar to what happens in the division above). BTW, I'm not saying I personally thought that was how square_root() would behave; I'm just trying to defend the assumption that was made in the original code sample as being not unreasonable. --[[User:StDoodle\|StDoodle (#1059825)]] 23:31, 29 June 2010 (UTC)



			{{CodeSample\|description=That sounds great, but try out this little program and be surprised at the output.\|
			code=<syntaxhighlight>
			float division (float a, float b) {
			return a/b;
			}

			void main() {
			print("5/3 = "+ division(5,3));
			}
			</syntaxhighlight>}}
			<pre>> call division.ash

			5/3 = 1.6666666</pre>
			Some data types are actually converted automatically when required. --[[User:Bale\|Bale]] 07:18, 30 June 2010 (UTC)

StDoodle at 23:31, 29 June 2010

2010-06-29T23:31:24Z

← Older revision		Revision as of 23:31, 29 June 2010
Line 10:		Line 10:

	* Whoa, whoa, WHOA! What the heck are you going on about? <code>square_root()</code> is a function that returns a float. It's not a mathematical operator. Like any other function it will always return a value of the appropriate type, even if its parameters are integers. Do you think it is somehow tricky for a function that takes integer parameters to return a float? That's just silly. --[[User:Bale\|Bale]] 20:10, 29 June 2010 (UTC)		* Whoa, whoa, WHOA! What the heck are you going on about? <code>square_root()</code> is a function that returns a float. It's not a mathematical operator. Like any other function it will always return a value of the appropriate type, even if its parameters are integers. Do you think it is somehow tricky for a function that takes integer parameters to return a float? That's just silly. --[[User:Bale\|Bale]] 20:10, 29 June 2010 (UTC)

			Though I'm sure the semantics differ between languages, a mathematical operator is essentially just a shorthanded function. As my code sample shows, you can "return a float" without that float necessarily being what one would expect from the mathematical operation (assuming you can accept the idea that a mathematical operation is essentially a function). For some idea what I mean, check this out:

			{{CodeSample\|
			code=
			<syntaxhighlight>
			float division(int a, int b) {
			return a / b;
			}

			float division(float a, int b) {
			return a / b;
			}

			float division(float a, float b) {
			return a / b;
			}

			void main() {
			print("Integers: 5 / 2 = " + division(5,2));
			print("Mixed: 5.0 / 2 = " + division(5.0,2));
			print("Integers: 5.0 / 2.0 = " + division(5.0,2.0));
			}
			</syntaxhighlight>
			}}

			As we don't have any other functions that accept a numerical paramters without being specifically overloaded to return a type matching the least restricted parameter type, it's hard to tell what's "normal" behavior for a math function in KoLmafia; which is why I pointed out that one might be tempted to use mathematical operators as one's basis. By the way, by this logic, square_root(5) would return 2.0; which is a float, but after conversion from its int counterpart (similar to what happens in the division above). BTW, I'm not saying I personally thought that was how square_root() would behave; I'm just trying to defend the assumption that was made in the original code sample as being not unreasonable. --[[User:StDoodle\|StDoodle (#1059825)]] 23:31, 29 June 2010 (UTC)

Bale: A function is not an operator!

2010-06-29T20:10:40Z

A function is not an operator!

← Older revision		Revision as of 20:10, 29 June 2010
Line 8:		Line 8:

	This is, of course, because the operation has only integers to use, and thus computes an integer result; THEN it converts this to a float. If either of the two numbers is a float (ie "5.0 / 2" or "5 / 2.0") the result would be 2.5, as "expected," because when two different datatypes are used, an implicit conversion to the most precise type is the norm. So it is a bit "unexpected" that square_root() will accept an int, and make an automatic float conversion. We should probably note this somewhere... --[[User:StDoodle\|StDoodle (#1059825)]] 15:32, 29 June 2010 (UTC)		This is, of course, because the operation has only integers to use, and thus computes an integer result; THEN it converts this to a float. If either of the two numbers is a float (ie "5.0 / 2" or "5 / 2.0") the result would be 2.5, as "expected," because when two different datatypes are used, an implicit conversion to the most precise type is the norm. So it is a bit "unexpected" that square_root() will accept an int, and make an automatic float conversion. We should probably note this somewhere... --[[User:StDoodle\|StDoodle (#1059825)]] 15:32, 29 June 2010 (UTC)

			* Whoa, whoa, WHOA! What the heck are you going on about? <code>square_root()</code> is a function that returns a float. It's not a mathematical operator. Like any other function it will always return a value of the appropriate type, even if its parameters are integers. Do you think it is somehow tricky for a function that takes integer parameters to return a float? That's just silly. --[[User:Bale\|Bale]] 20:10, 29 June 2010 (UTC)

StDoodle at 15:32, 29 June 2010

2010-06-29T15:32:49Z

← Older revision		Revision as of 15:32, 29 June 2010
Line 1:		Line 1:
	It won't truncate -- integer truncation only occurs when you have one integer divided by another. If one of the two terms is a float, then the other will be automatically converted to a float before performing the operation. --[[User:Heeheehee\|Heeheehee]] 17:43, 26 June 2010 (UTC)		It won't truncate -- integer truncation only occurs when you have one integer divided by another. If one of the two terms is a float, then the other will be automatically converted to a float before performing the operation. --[[User:Heeheehee\|Heeheehee]] 17:43, 26 June 2010 (UTC)

			It can be a bit confusing for some. square_root() works a little differently than most math operations. For example:

			float f; f = 5 / 2;

			will return 2.0

			This is, of course, because the operation has only integers to use, and thus computes an integer result; THEN it converts this to a float. If either of the two numbers is a float (ie "5.0 / 2" or "5 / 2.0") the result would be 2.5, as "expected," because when two different datatypes are used, an implicit conversion to the most precise type is the norm. So it is a bit "unexpected" that square_root() will accept an int, and make an automatic float conversion. We should probably note this somewhere... --[[User:StDoodle\|StDoodle (#1059825)]] 15:32, 29 June 2010 (UTC)

Heeheehee: Created page with 'It won't truncate -- integer truncation only occurs when you have one integer divided by another. If one of the two terms is a float, then the other will be automatically convert…'

2010-06-26T17:43:36Z

Created page with 'It won't truncate -- integer truncation only occurs when you have one integer divided by another. If one of the two terms is a float, then the other will be automatically convert…'

New page

It won't truncate -- integer truncation only occurs when you have one integer divided by another. If one of the two terms is a float, then the other will be automatically converted to a float before performing the operation. --[[User:Heeheehee|Heeheehee]] 17:43, 26 June 2010 (UTC)