The code is very hard to follow. Here's a possible refactor to make its intent
clearer. Some key ideas in the simplification: (1) use loops to manage counters
rather than manually incrementing/decrementing; (2) use more
meaningful variable names when context isn't clear; and (3) delegate some of
the complexity to a helper function. The third idea is the most ...
First improvement I see is mathematical: to check if a number n is prime, it's sufficient to verify that it's not divisible by any integer between 2 and math.ceil(math.sqrt(n)) (don't forget to import math at the top of your file). That's going to make your program more efficient.
Another improvement would be to split the code that deals with getting the ...
You have docstrings in your code which illustrates function inputs and expected outputs. Why not format these using the style of the doctest module?
Returns an ...
Micropython may not ...
As far as we discussed it, this is the most efficient answer found:
uses wincrt, sysutils;
function f(n : LongInt): LongInt;
//Result : LongInt;
if n mod 2 = 0 then
Result:= n div 2
Result:= (n div 2) - n;
According to the help of Mr Andreas, i have come up with this code, which was helpful, but it gave a runtime error, in this test : 1000000000000000, I have to disapprove the answer as it wasn't the best performance. But i still greatly thank you for your attention.
uses wincrt, sysutils;
function f(n : LongInt): ...
Seems trivial. Pair them, each pair is worth -1.
f(1000) = 1 - 2 + 3 - 4 + ... + 999 - 1000
= (1 - 2) + (3 - 4) + ... + (999 - 1000)
= -1 -1 + ... + -1
Odd n left as exercise for the reader.
(I wrote this when the question title still said "1 − 2 + 3 − 4 + · · ·", can't be bothered to switch all ...
Avoid storing points unnecessarily
The function getLine() creates a list of pixel coordinates, and then drawLine() iterates over it once, drawing each individual pixel, and then discards the list. Consider changing the function getLine() to be a generator instead, so it returns a point at a time. It is quite easy to modify the function to be a generator; ...
Make sure you add #include for everything you use directly
Your code happens to compile without errors because some other header file #includes the necessary header files for you to be able to use functions like std::acos() (from <cmath>), std::abs() (from <cstdlib>), std::min() (from <algorithm>), std::unique_ptr (from <memory>), and ...
Handling n < 0
The computation is entirely integer-based. When x := 1 / x is computed, that means the new x is usually zero, though if x was 1 to begin with then the new x is still 1.
As it currently is, with an integer computation, handling negative n makes very little sense. It almost never gives a useful result. It makes more sense to just not handle ...
Testing for n == 1 before handling a negative n seems like a bug. Consider what would have happen with n == -1:
n is not 1. Branch to _notEqualsOne.
n is less than 0. Branch to _lessthan. Now n becomes 1.
The code falls through all the way to _loop1.
n is odd. Branch to _odd.
y := x * y; x := x * x; n := 0`
_condition fails; fall through the return x * y.
When running code outside a function / class, it is a good practice to put the code inside the main guard. See here for more explanation.
It is a good practice to provide docstrings for functions. See here for more details. In Python 3.5+, adding type hints to function parameters and return values is also a good habit. (...