Anonymous user
User talk:Spoon!: Difference between revisions
→Dijkstra's algorithm permission
No edit summary |
|||
| (10 intermediate revisions by 6 users not shown) | |||
Line 50:
== Code edition ==
Hey Spoon!, you made some changes in my
The bug you created was in the method getChar( int a, int b ) -> the method accepts negative number to and for example: -1 % 5 = -1 not 0 - got it?!
--[[User:Paulo Jorente|Paulo Jorente]] ([[User talk:Paulo Jorente|talk]]) 19:22, 4 June 2013 (UTC)
== Python/Java infinite generator/iterator error ==
Spoon!, your Java Sieve of Eratosthenes infinite generator [http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Infinite_iterator translation to Java] (using 32-bit int's) as translated from [http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Infinite_generator infinite generator in Python] has an overflow problem for finding primes higher than 46,349 as I have noted [http://rosettacode.org/wiki/Talk:Sieve_of_Eratosthenes#Python_translated_to_Java in the Sieve of Eratosthenes Discussion Page]. You should fix this, perhaps by forcing the integer type to long.
A better fix would be to postpone the addition of the prime multiple culling sequences to the queue until needed as was done for the dictionary solution (the faster algorithm), in which case the algorithm will work up to the full numeric range of whatever number type is used, including 32-bit integers (2^31 - 1 or 2,147,483,647) otherwise limited to a rage of 46,349. This has the further advantage of much less memory use (by about the ratio of the square root of the memory used) and faster queue re-insertions (a large fraction of the total operations) as these access times are proportional of the log of the queue size, which would then be smaller by the given square root ratio.--[[User:GordonBGood|GordonBGood]] ([[User talk:GordonBGood|talk]]) 10:51, 24 June 2014 (UTC)
:Oh yeah, I hadn't thought about the types of the integer. In Python, integers automatically overflow into arbitrary-precision integers (2.x) or are already arbitrary-precision integers (3.x), so the correct translation would have been to use BigInteger. I'll think about the other solution, but a disadvantage of hash tables is that insertion and lookup are O(n) in the worst-case. Perhaps a binary search tree based dictionary will be good as insertion and lookup is amortized O(log n) in the worst case, the same as insertion and removal in a heap-based priority queue. --[[User:Spoon!|Spoon!]] ([[User talk:Spoon!|talk]]) 06:02, 25 June 2014 (UTC)
== Snake/Java ==
Team work, heheh. Those clunky enums look much better now. Thanks. [[User:Fwend|Fwend]] ([[User talk:Fwend|talk]]) 00:51, 14 April 2016 (UTC)
== Editing of Haskell's Lucky and even lucky numbers ==
Hi Spoon, thanks for your help. The Haskell code is now much cleaner and idiomatic.
Nevertheless you failed to test your changes and broke the code in a couple of places. I just fixed it.
== Dijkstra's algorithm permission ==
I'd like to ask your permission to use your implementation of Dijkstra's algorithm in Haskell as part of a benchmark suite for the pqueue package. [[User:Dfeuer|Dfeuer]] ([[User talk:Dfeuer|talk]]) 22:52, 10 December 2021 (UTC)
: Sure. --[[User:Spoon!|Spoon!]] ([[User talk:Spoon!|talk]]) 06:30, 11 December 2021 (UTC)
| |||