imported>StDoodle |
imported>PhilmASTErpLus |
| 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)
| + | So here's my two questions: |
| | | | |
| − | It can be a bit confusing for some. square_root() works a little differently than most math operations. For example:
| + | * From my experience, nested imports and repeated imports do NOT cause function or variable collisions. Is this correct for all cases? |
| | + | * The <code>main()</code> function from any imported script is ignored. Not sure how it works for a main-less top level script, though. |
| | | | |
| − | float f; f = 5 / 2;
| + | --[[User:PhilmASTErpLus|PhilmASTErpLus]] 17:36, 28 June 2010 (UTC) |
| − | | |
| − | 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)
| |
| − | | |
| − | * 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)
| |
| − | | |
| − | | |
| − | | |
| − | {{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)
| |
| − | | |
| − | 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)
| |