evgenykarkan / ekalgorithms Goto Github PK

Following my previous issue #34:

I think that your original implementation of reversedArrayWithArray can be improved by using the technique similar to what is used in #30 and #31:

Only first n/2 elements should be traversed exchanging i and count-i on each step - the middle element (if it exists - stays one the same position - hm, nice!).

Let me know, what do you think.

Error:(33, 53) no visible @interface for 'NSNumber' declares the selector 'isLessThan:'
Error:(52, 26) no visible @interface for 'NSNumber' declares the selector 'isGreaterThan:'

etc. It seems podspec has some dependency missing. Strange enough, no invalid imports detected.

EDIT:
Well, NSComparisonMethods is only available on macosx. Well, I guess I make a fix and a pull request.

hi i once wrote longest common subsequence and Levenshtein distanc algorithm as an NSString category in this tiny reop but when i came across this repo of yours i feel that maybe i could add the two methods into your project. is it okay for me to make a pull request then?

I would like to add the Fisher–Yates method to shuffle an array.

Cool?

Hi! @EvgenyKarkan
the error:
pod search EKAlgorithms
[!] Unable to find a pod with name matching `EKAlgorithms'

Jack

All works fine now.

There were problems with MapKit on OS X - it is supported only in 10.9, while Travis machines still have 10.8.5. I mocked all the geometry needed for now, so EKAlgorithms does not depend on any external frameworks: nor CoreLocation, nor MapKit.

The changed proposed #14 is good but only partially - it is good to know that Apple's reverseObjectEnumerator does its job - and as of Apple recommends to "use highest API possible" - it would be a better choice than to implement it by hands, but I think it would still be great to have both variant of methods to be kept in EKAlgorithms.

What I suggest is to keep both methods side by side, the only trick is again to invent a good convention to handle this:

My initial thought was something like:

+ (NSArray *)reversedArrayWithArray:(NSArray *)arrayToReverse
+ (NSArray *)native_reversedArrayWithArray:(NSArray *)arrayToReverse

or

+ (NSArray *)reversedArrayWithArray:(NSArray *)arrayToReverse
+ (NSArray *)CocoaImplementation_reversedArrayWithArray:(NSArray *)arrayToReverse

But I personally dislike using underscores in method names that is why I also thought about something like

+ (NSArray *)reversedArrayWithArray:(NSArray *)arrayToReverse
+ (NSArray *)reversedArrayWithArrayImplementedByCocoa:(NSArray *)arrayToReverse

For now I think that "CocoaImplementation_reversedArrayWithArray" is the best naming convention to be used for methods showing usage of highest-level of API suggested by Cocoa.

Let me know what you think.

Here are more examples we could write using Cocoa API:

Index of maximum element: [array valueForKeyPath:@"@max.integerValue"]
Binary search from awesome objc.io Issue n7, Binary Search.

After taking a look at the classes, I found that most of the methods could be simplified if moved to categories instead of their own class.

Example:
+ (NSUInteger)indexOfMaximumElementInArray:(NSArray *)array;
could become
- (NSUInteger)indexOfMaximumElement;

+ (NSInteger)indexOfObjectViaLinearSearch:(id)object inArray:(NSArray *)arrayToSearch;
could become
- (NSInteger)indexOfObjectViaLinearSearch:(id)object;

+ (NSMutableArray *)bubbleSortedArrayWithUnsortedArray:(NSMutableArray *)unsortedArray;
could become
- (NSArray *)bubbleSort;

+ (BOOL)isGivenStringPalindrome:(NSString *)string;
could become
- (BOOL)isPalindrome;

and so on..
Do you agree with this? If yes, I will move methods to categories so that their interface will be easier to use.

I'm quite a fan of unit testing (not necessarily TDD), and while refactoring methods of EKSearchStuff, EKSortStuff and EKArrayStuff I found myself in the position of having to check the console (for the output of the main file) to see if I broke something or not.
I would like to create a unit tests suite (if you don't mind I would use Kiwi framework) to make it easier in the future to refactor things and also for new people to add new algorithms.
Of course I won't be able to write the whole suite by myself, so I will need some help.
What do you think?

See amazing http://fauxpasapp.com tool.

E.g
https://github.com/stanislaw/FoundationExtensions/blob/master/FoundationExtensions.podspec

Hi, I'm new to programming, and I chose Objective-C as my first programming language. I've been search for a while but I couldn't find any book about Data Structure and Algorithms in Objective-C. So can you give me some source for learning these things.

Thanks.

for (int i = 2; i <= (int)sqrt(givenNumber); i++) {
         if (givenNumber % i == 0) {
           return YES;
         }
     }

should be:

for (int i = 2; i <= (int)sqrt(givenNumber); i++) {
         if (givenNumber % i == 0) {
           return NO;
         }
     }

I'll open a PR soon.

I really liked both the problem and solution proposed:

http://en.wikipedia.org/wiki/Josephus_problem
http://tristan-interview.blogspot.com/2012/03/about-josephus-problem.html

I will implement it myself later when I have enough time. Or I welcome you or anybody else to step in.

Thanks!

Before today I wasn't aware that besides creating mutable array -[NSArray mutableCopy] also makes copy of each element.

Now, having this in mind, I am pretty sure, that for general consistency of the whole algorithms base we need to eliminate all these mutableCopy strings and replace them with corresponding [NSMutableArray arrayWithArray:] strings.

https://github.com/EvgenyKarkan/EKAlgorithms/blob/master/EKAlgorithms/Data%20Structures/Graph/EKGraph.m#L188

The function 'clearVisitHistory', breaks the algorithm

Suggested fix:

#105

I found AppKit framework have already implement tree structure, and I will rewrite tree related code if possible.

Every single loop will be faster without any additional computations and methods call.
E.g "[array count]" in loop such as "for (NSUinteger i = 0; i < [array count]; i++)" should be extracted to independent local variable NSUinteger counter = [array count].
So the loop will be faster & look like "for (NSUinteger i = 0; i < counter; i++)".

Hi,

In EKGraph.m, I see code like this

NSMutableArray *parent = [@[] mutableCopy];
NSMutableDictionary *dist     = [@{} mutableCopy];

why not

NSMutableArray *parent = [NSMutableArray array];
NSMutableDictionary *dist     = [NSMutableDictionary dictionary];

Is this kind of code relative to special function or just a way of style?

Hello, @EvgenyKarkan.

How about adding section with similar repositories? I think this growing one is a good candiate to start section.

I haven't been doing anything on this algorithms topic during these latest months because of almost entire focus on patterns/architecture area so no contributions 😄 Anyway I like it a lot that we created and now have this basic base of algorithms just in case if a need in some of them raises! Good work!

Thanks,

Stanislaw

Candidates to 0.2 release notes:

• Added KMP algorithm.

Please fix:

EKAlgorithmsExamples crashes (XCode 5.1.1, OS 10.9): main.m, line 72, message:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSDictionary dictionaryWithObjectsAndKeys:]: second object of each pair must be non-nil. Or, did you forget to nil-terminate your parameter list?'

[oneArray addObject:[NSDictionary dictionaryWithObjectsAndKeys:@"EKAlgorithms100", nil]];

should be:

[oneArray addObject:[NSDictionary dictionaryWithObjectsAndKeys:@"EKAlgorithms100", someKey, nil]];

Hello, Evgeny!

Are you aware of the following simultaneous MIN/MAX finding trick: http://tristan-interview.blogspot.com/2012/02/get-max-and-min-simultaneously.html?

I've just found it occasionally and decided to report it here.

I have no time now to prepare a PR. Let me know if it is worth including into EKAlgorithms or be virtous to implement it yourself.

Thanks.

[NSNumber primeNumbersFromSieveEratosthenesWithMaxNumber:] returns non-prime number (zero):

2016-02-21 06:23:50.983 EKAlgorithmsExamples[88910:27191955] Primes from sieve (
    0,
    2,
    3,
    5,
    7,
    11,
    13,
    17,
    19,
    23,
    29,
    31,
    37,
    41
)