I'm currently trying to learn Swift for iOS app development. I'm fairly new to programming in general but do have some experience in other languages
I've just learnt about the modulo operator, or the remainder operator depending on what you call it. (%)
It should return the remainder of an equation, right?
var equation = 500 % 30
When I print equation, it writes '20' but I can't figure out why? 30 does not fit into 500 20 times, it's 16.6. The / operator would return 16 so I expected % to return whatever the remainder is?
Please tell me if I'm being stupid but I can't figure it out.
a % b does not determine how many times b fits into a. The modulo operator determines what remains when you subtract the largest multiple of b that is smaller than a from a. In this case, the largest multiple of 30 that is smaller than 500 is 480, and 500 - 480 = 20, so 500 % 30 = 20.
I feel stupid. Sorry.
480 is the highest number 30 can perfectly fit into, which leaves 20 remaining.
Related
This is related to the Zeller's Congruence algorithm where there is a requirement to use Modulo to get the actual day of an input date. However, in the software I'm using which is Blueprism, there is no modulo operator/function that is available and I can't get the result I would hope to get.
In some coding language (Python, C#, Java), Zeller's congruence formula were provided because mod is available.
Would anyone know a long method of combine arithmetic operation to get the mod result?
From what I've read, mod is the remainder result from two numbers. But
181 mod 7 = 6 and 181 divided by 7 = 25.857.. the remainder result are different.
There are two answers to this.
If you have a floor() or int() operation available, then a % b is:
a - floor(a/b)*b
(revised to incorporate Andrzej Kaczor's comment, thanks!)
If you don't, then you can iterate, each time subtracting b from a until the remainder is less than b. At that point, the remainder is a % b.
I would like to round up the numbers by using math.ceil in Lua.
Some of the cases are make sense like:
ceil(260.5) -> 261
But some of the cases are weird like:
ceil(2.2*100) -> 221 # Suppose there is no round up and the answer is 220
I have no idea why it acts like this, what should I do if I would like to round up the number when there are digits after decimal point, and no rounding up if there is just an integer?
-- Update:
Thanks for the answering from #cyclaminist:
2.2 * 100 is actually a little larger than 220.0 because 2.2 can't be represented exactly as a floating point number. Try ('%.15f'):format(2.2 * 100): for me, it gives '220.000000000000028'
Ceil will return the integer which is the closest and not smaller than 220.000000000000028, so that 221 is returned.
The solution to get 220 is:
math.floor(2.2*100 + 0.5) -> return 220, Since math.floor return the closest but not larger than 220.000000000000028
Try tonumber(string.format("%.0f",2.2*100)).
Can somebody explain why multiplying by 100 here gives a less accurate result but multiplying by 10 twice gives a more accurate result?
± % sc
Loading development environment (Rails 3.0.1)
>> 129.95 * 100
12994.999999999998
>> 129.95*10
1299.5
>> 129.95*10*10
12995.0
If you do the calculations by hand in double-precision binary, which is limited to 53 significant bits, you'll see what's going on:
129.95 = 1.0000001111100110011001100110011001100110011001100110 x 2^7
129.95*100 = 1.1001011000010111111111111111111111111111111111111111011 x 2^13
This is 56 significant bits long, so rounded to 53 bits it's
1.1001011000010111111111111111111111111111111111111111 x 2^13, which equals
12994.999999999998181010596454143524169921875
Now 129.95*10 = 1.01000100110111111111111111111111111111111111111111111 x 2^10
This is 54 significant bits long, so rounded to 53 bits it's 1.01000100111 x 2^10 = 1299.5
Now 1299.5 * 10 = 1.1001011000011 x 2^13 = 12995.
First off: you are looking at the string representation of the result, not the actual result itself. If you really want to compare the two results, you should format both results explicitly, using String#% and you should format both results the same way.
Secondly, that's just how binary floating point numbers work. They are inexact, they are finite and they are binary. All three mean that you get rounding errors, which generally look totally random, unless you happen to have memorized the entirety of IEEE754 and can recite it backwards in your sleep.
There is no floating point number exactly equal to 129.95. So your language uses a value which is close to it instead. When that value is multiplied by 100, the result is close to 12995, but it just so happens to not equal 12995. (It is also not exactly equal to 100 times the original value it used in place of 129.95.) So your interpreter prints a decimal number which is close to (but not equal to) the value of 129.95 * 100 and which shows you that it is not exactly 12995. It also just so happens that the result 129.95 * 10 is exactly equal to 1299.5. This is mostly luck.
Bottom line is, never expect equality out of any floating point arithmetic, only "closeness".
I am trying to convert an erlang time format tuple, {megasec,sec,microsec}, into a floating point number and back again.
I can do this one way, e.g.:
{Megasec,Sec,Usec} = erlang:now().
Total = Megasec*1000000+Sec+Usec/1000000.
1352802601.427
But I am struggling to convert this number back to the time format. I have a general idea to divide by 1000000 and round but I get rounding errors. e.g.
Mega = erlang:round(Total/1000000).
1353
If I could get this accurately I could apply similar steps to get Seconds and Microseconds.
Any ideas?
You can use erlang:trunc instead of erlang:round.
Following #Falco Hirschenberger's suggestion here's how I did it:
Mega = erlang:trunc(Total/1000000).
1352
Sec = erlang:trunc(Total - Mega*1000000).
802601
Usec = erlang:round((Total - Mega*1000000 - Sec)*1000000).
427000
Note. I had to use erlang:round to get Usec (else the answer would have been 427000.0457763672 - I think this is due to a rounding error introduced when I divided by 1000000)
I am doing the following in actionscript in Coldfusion Flash Forms:
90 / 3.7
Gives me:
24.3243243243243
Whereas the calculator gives me:
24.32432432432432
Note the extra 2 at the end.
So my problem occurs when I am trying to get the original value of 90 by taking the 24.3243243243243 * 3.7 and then I get 89.9999999999 which is wrong.
Why is Actionscript truncating the value and how do I avoid this so I get the proper amount that the calculator gets?
Thanks so much.
Round your number using a routine like this
var toFixed:Function = function(number, factor) {
return (Math.round(number * factor)/factor);
}
Where the factor is 10, 100, 1000 etc, a simple way to think about it is the number of 0's in the factor is the number of decimal places
so
toFixed(1.23341230123, 100) = 1.23
Good explanation of numeric in ActionScript can be found at http://docstore.mik.ua/orelly/web2/action/ch04_03.htm. See section 4.3.2.1. Floating-point precision
A relavant quote:
"In order to accommodate for the minute discrepancy, you should round your numbers manually if the difference will adversely affect the behavior of your code. "