division problem

ckb

ckb

Minion
Staff member
I am working with Build 9027, but I cannot get division to work as I expect it to.

I expect to_float(14/15) = 0.93333
but it returns 0.0

I expect ceil(14/15) = 1
but it returns 0

what am I doing wrong here?

ckb
 
"14" and "15" are ints, so if you divide one by the other, the result will still be an int.
Code: 
> ash print( 14/15 )

0

It's the same thing as doing floor( 14 / 15 ). If you want a float result, at least one of them has to be a float:
Code: 
> ash print( 14/15.0 )

0.93333334
 
When you do division with two integers, you get the integer result, which for 14/15 is 0. Converting the integer 0 to a float will give you 0.0. What you need to do is convert those integers to floats before you do your division, and you'll get the number you expected.
 
Last edited:
Is this intuitive behavior, though? Ignoring how C and Java do things, it seems like division is a natural candidate for everything to be cast into floats.

(3 / 6) * 2 = 0

When I look at it, that doesn't make much sense to me.
 
It's intuitive if programming is something you've done. If you work with ints, you expect things to be ints, which means you get used to increasing values... In your (3/6)*2 example, if I needed it to be as such, I'd end up doing something like this...
> ash ((((100*3)/6)*2)/100)

Returned: 1
Click to expand...
 
Changing division to always return a float breaks all scripts that use a division result as an array index, for example dividing a skill ID by 1000 to look up the skill's category in an array.
 
Hm... Jason has a point. The language is too mature at this point to do automatic coercion for the primitive types. =\
 
holatuwol said:
Is this intuitive behavior, though?
Click to expand...

Depends where you developed your intuition. Seems to me that it became intuitive about the time I took college Algebra in my third year as a math major. It became ingrained as soon as I learned my second typed programming language. If "rings, groups and fields" have any technical meaning for you then the fact that a division operator applied to integers is different from a division operator applied to real numbers almost has to become second nature.
 
fronobulax said:
Depends where you developed your intuition.
Click to expand...

Actually, it depends on who we are targetting. My feeling is that for the most part ASH is better documented than many languages, and for a lot of users, is the first language they actually write in. If that is our aim (and since the language is designed to help people play a stick figure game more efficiently, then I think it is a fair aim), then intuition has to be considered in terms of a non-specialist, new scripter.

This is probably not intuitive behaviour. I would agree with fronobulax that it appears obvious to me, but that's not fair on people who don't spend their free time coding in other languages. However, as jason pointed out, it being unintuitive isn't sufficient reason to change things, if other scripts depend on a predictable output that this would break.
 
While I enjoy the philosophical discussion and delight in pointing out exceptions to generalizations, the fact that implementing implicit conversions will break a whole lot of stuff is a very good reason not to change code, and possibly a reason to upgrade documentation or tutorials.
 
You must log in or register to reply here.
Back
Top