# GMLscripts.com

Discuss and collaborate on GML scripts

You are not logged in.

## #1 2009-01-05 18:28:03

xDanielx
Member
Registered: 2009-01-02
Posts: 38

### sum_interval -- handling non-integer inputs?

I know you say m and n should be integers, so it shouldn't really matter if you apply floor or ceil to them, but you could make it work for all real m and n by changing the first floor to a ceil. Say the input is 3.5 and 5.5 -- then the "positive integers between m and n" would be 4 and 5, so the result should be 9, which is the output if you make that change. If nothing else, it will give users who "misuse" the script the results they expect.

Offline

## #2 2009-01-05 22:14:51

xot
Registered: 2007-08-18
Posts: 1,239

### Re: sum_interval -- handling non-integer inputs?

But why should the sum of reals in the interval between 3.5 and 5.5 be equal to 9 as opposed to any other number? If we are going to allow reals, why should the step-factor between numbers in the set be limited to exactly 1.0? The set of integers within a finite range is finite, but the set of reals within a finite range is infinite. To me, this looks more like an opportunity for a new script, rather than a need to change the existing one.

Abusing forum power since 1986.

Offline

## #3 2009-01-05 23:36:14

xDanielx
Member
Registered: 2009-01-02
Posts: 38

### Re: sum_interval -- handling non-integer inputs?

My reasoning was that the integers between 3.5 and 5.5 are 4 and 5, so it would make some sense to return 9 with those inputs, but I take your point -- users who use give non-integer inputs might also expect a continuous sum (difference*average) or something entirely different.

I guess I would suggest just getting rid of the floor's, then. They might give users the idea that they can somehow use non-integers (despite the argument descriptions) and expect them to be handled in a predictable way.

BTW, you can simplify the return clause a tiny bit:

Expandreturn (n - m + 1) * (n + m) / 2;

Offline

## #4 2009-01-05 23:36:14

xot
Registered: 2007-08-18
Posts: 1,239

### Re: sum_interval -- handling non-integer inputs?

Thanks for the changes. A better than 33% reduction in math is a serious optimization. I knew the math could be simplified, I just couldn't quite figure it out. The way you've expressed it makes more sense to me than the old code.

I also agree about removing the floors(), they are arbitrary and are not needed when the function is used as described. I see now that the min() and max() could be replaced with an abs() in the formula.

Expandreturn (abs(argument0 - argument1) + 1) * (argument0 + argument1) / 2;

Abusing forum power since 1986.

Offline