[Trigger] Simple, Quick Questions about Real Numbers, Math - Random Number b/w... & A Few Others

[iSkyi]

I am starting to get the hang of this, I promise. I just wanted to get some clarifications on how certain things behave. I've prepared a tiny sample snippet based on a trigger I made recently to refer to below:

1. When I "Set RandomReal = (Random real number between 0.00 and 100.00)," can the value returned be any number between 0.00 and 100.00? [1.08, 46.23, 99.99, 45.00, 10.01, etc.?]
2. Do these potential values actually include 0.00 and 100.00? The same question goes for random integers, if I use "Random Integer between 3 and 6," are the possible integers = 3, 4, 5, and 6?

Also, I realize I'm being overly cautious, but I get really scared to use the same variable in multiple places, even though I know that this only becomes an issue if there is time included at some point (timer, wait function, periodic event trigger, etc.). Can I just get some confirmation that I can use something like "RandomReal" here repeatedly in the same trigger and not worry about conflict with previous values?

Example:
Set "RandomReal to a random real number b/w (number1) & (number2)"
If RandomReal is less than (some number), save 0 as 0 of 0 in Hashtable, else...
If Random Real is greater than (some number), save 1 as 0 of 0 in Hashtable.
Set "RandomReal to a random real number b/w (number1) & (number2)"
If RandomReal is less than (some number), save 0 as 0 of 1 in Hashtable, else...
If Random Real is greater than (some number), save 1 as 0 of 1 in Hashtable.

There is nothing wrong with doing this example above, right? The only issue is if I wanted to use the first value again later on, since I overwrite it?

As a final question: Converting reals to integers, they'll just round, right?

• Ir Copy
  • Events
  • Conditions
  • Actions
    • Set RandomReal = (Random real number between 0.00 and 100.00)
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • RandomReal Less than or equal to 2.70
      • Then - Actions
        • Set TempInteger1 = 0
      • Else - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • RandomReal Greater than 2.70
            • RandomReal Less than or equal to 5.48
          • Then - Actions
            • Set TempInteger1 = 1
          • Else - Actions

 

[Rigborn]

1) Yes. Random real numbers can only have 3 more digits after the dot. So it can be like 1.345 but can't 1.2345.
2) Yes. Those values include those numbers. And yes
3) Yes. It truncates because integers can't store non-integer real numbers.

You can use arrays in this case and use loop or you can use another variable to store value of your first variable.

 

[iSkyi]

1) Yes. Random real numbers can only have 3 more digits after the dot. So it can be like 1.345 but can't 1.2345.
2) Yes. Those values include those numbers. And yes
3) Yes. It truncates because integers can't store non-integer real numbers.

You can use arrays in this case and use loop or you can use another variable to store value of your first variable.

So for the variable situation, I used that as an example for a consideration I face very frequently. I came across a much better example today. I am storing a LOT of information (strings, mostly) in a hashtable with child keys ranging from 0 to ~15 for all parents keys (each) from 3 to 30. They all have completely unique data so I can't loop.

I chose to do it this way:
Set TempInteger = (Parent Key of the Next Section)
Save String1 as 1 of TempInteger in ...
Save String2 as 2 of TempInteger in ...
...
Save String15 as 15 of TempInteger in...
Set TempInteger = (Next Parent Key)
Save String1 as 1 of TempInteger in ...
Save String2 as 2 of TempInteger in ...
...
So on, so forth. That way I don't have to go through and change the parent key for every single one of these 15 values being saved, I only have to copy/paste the 1st one I do and change the values being saved. I guess my fear is that using that integer over and over again like that might have some interaction I am unaware of...

Edit: I'd also like to add that there is context to why I am choosing to use a hashtable over something like an array of arrays. It has to coincide with another hashtable system I've made since they work off each other.

 

[Pyrogasm]

Yes doing what you did with TempInteger will cause no problems and is actually a preferred way to do it! No reason to keep recomputing the key (or any variable, really, as long as you use it multiple times) every time you need it. GUI isn't super efficient so if you're using something like Player Number of (Owner of (Triggering Unit)) repeatedly it's wise to save that into a temp variable too.

Re: Real -> Int as Aeryn said it truncates and never rounds so 1.999999999 converted to an int is 1.

You should be aware there is also a StringHash() function which allows you to use strings as keys in your hashtables, if you find that easier or more readable than integers. It will show up like Key(String You Use), should be pretty easy to find in the hashtable menus.

 

[iSkyi]

Yes doing what you did with TempInteger will cause no problems and is actually a preferred way to do it! No reason to keep recomputing the key (or any variable, really, as long as you use it multiple times) every time you need it. GUI isn't super efficient so if you're using something like Player Number of (Owner of (Triggering Unit)) repeatedly it's wise to save that into a temp variable too.

Re: Real -> Int as Aeryn said it truncates and never rounds so 1.999999999 converted to an int is 1.

You should be aware there is also a StringHash() function which allows you to use strings as keys in your hashtables, if you find that easier or more readable than integers. It will show up like Key(String You Use), should be pretty easy to find in the hashtable menus.

Thank you so much! This was a great answer. As for the StringHash() I will keep that in mind for the future, that will be great, actually. However, for this specific system, the number that serves as key for any of the strings serves to tie that string to 3 other quantities (a real number determined at the end, another string & its corresponding color, and a real number saved in another table). The key, 9 for example, ties all of these quantities together as being associated with that value so I can call for it later in the correct order. Seriously, thank you again, especially regarding the information on the Player Number of (Ow-... information, because that is something I've done a lot of LOL..