Papyrus why getdfactionrank(MyFac) 100 be an integer? : V

» Fri Jul 15, 2016 8:10 pm

What is the logic to Papyrus returning an integer for

float x = ((PlayerRef.getdfactionrank(MyFaction) / 100)

X gets set to 1 if the rank is 100 or zero if less than 100.

If I do this it is all fine:

float x = ((PlayerRef.getdfactionrank(MyFaction) / 100 as float)

Is this how it is in most code languages?

I just want to understand this because I am worried about other gotcahs like this I may not have discovered yet.

I mean

float x = (1/2)

returns a float without "casting" even though 1 and 2 are integers.

» Sat Jul 16, 2016 1:14 am

If (1/2) is working it's only because of some special compiler optimization. Normally if two integers are combined you get an integer. Personally, I would just use "/ 100.0" so the 100 is explicitly a float instead of casting it. And yes, that behavior is standard in virtually every modern programming language (and a major source of errors for beginning programmers in each one too).

» Sat Jul 16, 2016 9:11 am

I may only be assuming this because I had not seen any oblivious issues in game play. I will check all my scripts for / # and change to / #.0 just to be sure!

Wow....wow... thanks.

Edit:

I came back to write this as it may help other struggling pseudo-programmers.

OK, so while checking all my scripts I discovered that in SOME of my older scripts I had notes about this exact thing. So at one time long ago this issue came up for me and someone helped me and I FORGOT! (sorry about that cdcooley).

The reason I forgot I think is because I tried to commit the concept to memory but as I did not understand the logic of the it, it did not stick. Unfortunately that is how I am, I need understanding for DRY information to stay accessible in my mind.

So THIS time I went looking for the reasons why programming does this (counter intuitively to a layman's understating).

Here is what I found (googling) and it indeed makes logical sense to me now:

"While it is common for new programmer to make this mistake of performing integer division when they actually meant to use floating point division, in actual practice integer division is a very common operation. If you are assuming that people rarely use it, and that every time you do division you'll always need to remember to cast to floating points, you are mistaken.

First off, integer division is quite a bit faster, so if you only need a whole number result, one would want to use the more efficient algorithm.

Secondly, there are a number of algorithms that use integer division, and if the result of division was always a floating point number you would be forced to round the result every time. One example off of the top of my head is changing the base of a number. Calculating each digit involves the integer division of a number along with the remainder, rather than the floating point division of the number.

Because of these (and other related) reasons, integer division results in an integer ".