integer-division

Why does a division result differ based on the cast type?

最后都变了- 提交于 2019-12-06 21:11:23
问题 Here's a part of code that I dont understand: byte b1 = (byte)(64 / 0.8f); // b1 is 79 int b2 = (int)(64 / 0.8f); // b2 is 79 float fl = (64 / 0.8f); // fl is 80 Why are the first two calculations off by one? How should I perform this operation, so its fast and correct? EDIT: I would need the result in byte 回答1: EDIT: Not entirely correct, see: Why does a division result differ based on the cast type? (Followup) Rounding issue: By converting to byte / int, you are clipping of the decimal

Why is math.floor(x/y) != x // y for two evenly divisible floats in Python?

帅比萌擦擦* 提交于 2019-12-06 18:22:12
问题 I have been reading about division and integer division in Python and the differences between division in Python2 vs Python3. For the most part it all makes sense. Python 2 uses integer division only when both values are integers. Python 3 always performs true division. Python 2.2+ introduced the // operator for integer division. Examples other programmers have offered work out nice and neat, such as: >>> 1.0 // 2.0 # floors result, returns float 0.0 >>> -1 // 2 # negatives are still floored

Round with integer division

馋奶兔 提交于 2019-12-06 16:50:53
问题 Is there is a simple, pythonic way of rounding to the nearest whole number without using floating point? I'd like to do the following but with integer arithmetic: skip = int(round(1.0 * total / surplus)) ============== @John: Floating point is not reproducible across platforms. If you want your code to pass tests across different platforms then you need to avoid floating point (or add some hacky espilon stuff to your tests and hope it works). The above may be simple enough that it would be

64 bit / 64 bit remainder finding algorithm on a 32 bit processor?

点点圈 提交于 2019-12-06 16:01:30
I know that similar questions has been asked in the past, but I have implemented after a long process the algorithm to find the quotient correctly using the division by repeated subtraction method. But I am not able to find out the remainder from this approach. Is there any quick and easy way for finding out remainder in 64bit/64bit division on 32bit processor. To be more precise I am trying to implement ulldiv_t __aeabi_uldivmod( unsigned long long n, unsigned long long d) Referenced in this document http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf What? If you do

Fast floor of a signed integer division in C / C++

女生的网名这么多〃 提交于 2019-12-06 06:33:06
问题 In C a floor division can be done, eg: int floor_div(int a, int b) { int d = a / b; if (a < 0 != b < 0) { /* negative output (check inputs since 'd' isn't floored) */ if (d * a != b) { /* avoid modulo, use multiply instead */ d -= 1; /* floor */ } } return d; } But this seems like it could be simplified. Is there a more efficient way to do this in C? Note that this is nearly the reverse of this question: Fast ceiling of an integer division in C / C++ 回答1: Less assembly instructions in the

Why is math.floor(x/y) != x // y for two evenly divisible floats in Python?

依然范特西╮ 提交于 2019-12-04 23:50:56
I have been reading about division and integer division in Python and the differences between division in Python2 vs Python3. For the most part it all makes sense. Python 2 uses integer division only when both values are integers. Python 3 always performs true division. Python 2.2+ introduced the // operator for integer division. Examples other programmers have offered work out nice and neat, such as: >>> 1.0 // 2.0 # floors result, returns float 0.0 >>> -1 // 2 # negatives are still floored -1 How is // implemented? Why does the following happen: >>> import math >>> x = 0.5 >>> y = 0.1 >>> x

Round with integer division

不打扰是莪最后的温柔 提交于 2019-12-04 22:22:56
Is there is a simple, pythonic way of rounding to the nearest whole number without using floating point? I'd like to do the following but with integer arithmetic: skip = int(round(1.0 * total / surplus)) ============== @John: Floating point is not reproducible across platforms. If you want your code to pass tests across different platforms then you need to avoid floating point (or add some hacky espilon stuff to your tests and hope it works). The above may be simple enough that it would be the same on most/all platforms, but I'd rather not make that determination as it is easier to avoid

Fast floor of a signed integer division in C / C++

℡╲_俬逩灬. 提交于 2019-12-04 13:05:36
In C a floor division can be done, eg: int floor_div(int a, int b) { int d = a / b; if (a < 0 != b < 0) { /* negative output (check inputs since 'd' isn't floored) */ if (d * a != b) { /* avoid modulo, use multiply instead */ d -= 1; /* floor */ } } return d; } But this seems like it could be simplified. Is there a more efficient way to do this in C? Note that this is nearly the reverse of this question: Fast ceiling of an integer division in C / C++ Less assembly instructions in the generated code and quicker path to the result I think. For the RISC machines with huge numbers of registers

Division in C# to get exact value [duplicate]

别来无恙 提交于 2019-12-04 04:01:00
问题 This question already has answers here : Why does integer division in C# return an integer and not a float? (7 answers) Closed 6 years ago . If I divide 150 by 100, I should get 1.5. But I am getting 1.0 when I divided like I did below: double result = 150 / 100; Can anyone tell me how to get 1.5? 回答1: try: double result = (double)150/100; When you are performing the division as before: double result = 150/100; The devision is first done as an Int and then it gets cast as a double hence you

Integer division algorithm

允我心安 提交于 2019-12-03 03:43:43
问题 I was thinking about an algorithm in division of large numbers: dividing with remainder bigint C by bigint D, where we know the representation of C in base b, and D is of form b^k-1. It's probably the easiest to show it on an example. Let's try dividing C=21979182173 by D=999. We write the number as sets of three digits: 21 979 182 173 We take sums (modulo 999) of consecutive sets, starting from the left: 21 001 183 356 We add 1 to those sets preceding the ones where we "went over 999": 22