# Tag Info

1

Performance Problems Your current solution works decent for small cases, but there are a few problems when the problem starts to scale up, which causes the performance to drop. I will mention the two biggest I have found. You construct all paths toward the goal, even the unviable ones, in full until you remove them. This causes an exponential amount of ...

3

I have a few suggestions for you: You should get in the habit on wrapping all code that isn't in a function in a main guard, to ensure that that code only runs if that file is running, and to protect it from import mishaps Running your code with pylint, a few warnings that popped up were: Returns: All return statements should return something or none of ...

0

As mentioned, expanding the iterable into a list is probably not always desired. Also a class seems to be overkill, since it needs to carry around an instance dict that's not being used. An implementation as a generator function seems more lightweight and feasible. def enumerate(iterable, start=0): for item in iterable: yield (start, item) ...

1

I'm sorry to be so straightforward: This is madness! Your code seems to indicate a sincere lack of several language features. Pointer to const You define MEM to be of type uint8_t*, but it actually points to values of const uint8_t. To account for this difference you cast the const away in both constructors. If you'd ever (accidentally) write to the ...

3

I think this is mistake: self.iterable = list(iterable) It requires loading the entire iterable into memory. Being able to avoid this and work with large collections efficiently is one of the big benefits of iterators. It won't work on non-ending iterators like itertools.count() If instead, you make an iterator from the iterable, you can avoid both those ...

5

Here are some suggestions. Non conformance Many of your functions are marked constexpr. This is non-conforming. Per [constexpr.functions]: This document explicitly requires that certain standard library functions are constexpr ([dcl.constexpr]). An implementation shall not declare any standard library function signature as constexpr except for ...

3

Self-assignment may be expensive, but it should be a no-op instead of UB. I suggest copy-and-swap. Omitting move-semantics will most certainly cost you. Your naming of the internal class suggests all callables are lambdas. Not true! You cannot store any move-only callables. Admittedly std::function is also crippled in that respect. Just throw an exception if ...

1

L. F. gave a good review, but there is more: Exceptions are not for programmer errors. That's what asserts are for. Modularise your code: Extract down_heap() and up_heap() as free functions, making the algorithm available for anyone wanting to manipulate a heap. They should accept an iterator-range and a comparator, with the default being std::less<>(...

5

Here's my two cents: Do not using namespace std;. It causes serious problems and is considered bad practice. See Why is using namespace std; considered bad practice?. Consider wrapping your class in a header so that it can be reused. Use an include guard. MinHeap is a common name that may cause name clash. Consider placing it in a namespace. MinHeap ...

0

There is no need for reinvention of the wheel and complex pattern matching. Use urllib.parse.urlparse to check for the URL's scheme. from urllib.parse import urlparse def is_http_or_https(url): return urlparse(url).scheme in {'http', 'https'}

1

This is a simpler way. EDIT: The original way works fine. With regards to my solution, it's just with less code. The algorithm itself covers all the cases and we don't need to put if-else conditions to catch edge cases. fun searchInsert(array: IntArray, num: Int): Int { var head = 0 var tail = array.lastIndex while (head <= tail) { ...

1

Duplicated Ids!!! 😲 I notice in the comments there is mention of more than 1 element with the same Id and that getElementById will only return one element, which is correct for the majority of browsers depending on the version. Even if getElementById acted the same across browsers As a developer intentionally using duplicated Id is VERY BAD! as it will ...

3

General points if statements that return should not be followed by an else. Eg if (foo) { return bar } else if (bar) {.. The else is redundant. typeof is not a function it is an operator (language token). Thus typeof(foo) === "foo" is the same as typeof foo === "foo" Use the function isNaN to test if a value (number like) can not be parsed to a Number. Use ...

2

dfhwze has said the most, I just miss the point of: duplicateIndexes.Add(index); duplicateIndexes.Add(j); Recursion is an important pattern when programming, and sometimes it is inevitably, but in most circumstances you can find an iterative solution for the same problem. The advantages with iterative solutions are that they often are easier ...

3

Review You make a special branch to distinguish odd from even array lengths. if (subject.Length % 2 != 0) This is not required because getting the mid of an array can just be retrieved as (end - start) / 2. In case of an even array, you get the left index of the mid index pair. This is not a bad thing, we are not calculating a median here. You write alot of ...

0

Some small structure feedback: 1. The template keyword should be above the function definition Templated functions is usually written like you have written your constructor with the template keyword ontop of the function definition. Like this: template<class T> T ArrayList<T>::get(int index) { //Implementation here } It is easier to ...

4

I'm not a Rust user, so I can't say much about style, but I can see an optimisation in trial_composite: x = a.modpow(&e,n); You already have $x^{e/2}$, so all you need to do is square it. I.e. this line should be (suitably corrected to compile) x = x.modpow(2u32,n); or x = x * x % n; There may also be a further, minor, ...

4

I am looking for advice on how to improve performance and how to improve my Rust style code. Not so applicable, but some minor C comments Over specifying array size trial_divisors[] array size is specified with a constant and initialized with maybe the correct number of initializers. Avoid that maybe. Instead initialize, then form the size. const int ...

3

Nice, clean and functional. Still, there are a few things: If you don't have to declare a special member-function, just don't: bad_function_call::bad_function_call(), callable::~callable(), and function::~function() are superfluous. If you actually have to declare a special member-function, explicitly default it in-class where that is enough: callable_base::...

Top 50 recent answers are included