I've implemented my own A* algorithm and while it works it seems quite slow. It seems to cover a lot of unnecessary ground.
This is a string representation of my graph where a ground tile is "HHH", a blocked square are three spaces and areas searched are "XXX". The algorithm starts from the bottom left area and heads to behind the two blocked squares up to the right. And while this grid seems very small it's reduced in size to display the issue. This seems to be a similar result as when I run it on this site. With euclidian distance as I am and with a "weight" of 1.
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXX XXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXX HHHXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXX HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXX HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHH XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHXXX XXXXXXXXX HHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH
HHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH
HHHHHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH
HHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH HHHHHHHHHHHH
HHHHHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH HHHHHHHHHHHH
HHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH HHHHHHHHHHHH
HHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH HHHHHHHHHHHH
HHHHHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH
HHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH
HHHHHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH
HHHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HHHHHHHHHHHH
HHHXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHXXXXXXXXX XXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
XXXXXXXXXXXX XXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHXXXXXXXXX XXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHXXXXXXXXXXXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHXXXXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHXXXXXXXXXXXXXXXHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
Pathfinding.js with weight of 1
If I then change weight to a higher number like 3 it ends up looking very different.
Pathfinding.js with weight of 3
Is there any way I could get my implementation to make a similar calculation instead. I don't really understand what the "weight" is in this context. The only weight I can think of in my implementation is that between the nodes. But if I multiply that weight it does not result in a similar calculation. I see that the path produced isn't the shortest possible which isn't an issue because I process it after anyway.
Related
I am wondering what the documentation of cumulativeCost() in GEE exactly means by "nearest source location".
"nearest" in terms of "the closest starting pixel, linearly computed" or
"nearest" in terms of "the closest in terms of cumulative cost" ?
For my analysis I would like to know if the algorithm already reduces the number of potential routes in advance (by choosing only 1 starting point in advance) OR if it first tries the routes from one pixel to all possible starting points, and then takes the value to the starting pixel with the lowest total cost. Does anyone have more detailed information on how the algorithm works in that case? Thanks.
I'm actually working on the pathways of inpatients during their hospital stay. These pathways are represented as states sequences (the current medical unit at each time unit) and I'm trying to find typical pathways through clustering algorithms.
I create the distance matrix by using the seqdist function from the R package TraMineR, with the method "OMspell". I've already read the R documentation and the related articles, but I can't find how to set the arguments tpow and expcost.
As the time unit is an hour, I don't want any little difference of duration to have a big impact on the clustering result (contrary to a medical unit transfer for example). But I don't want the duration not to have any impact either...
Also, is there a proper way to choose their value ? Or do I just continue to grope around for a good configuration ? (I'm using Dunn, Davies-Bouldin and Silhouette criteria to compare the results of hierarchical clustering, besides the medical opinion on the resulting clusters)
The parameter tpow is an exponential coefficient applied to transform the actual spell lengths (durations). The default value is 1 for which the spell lengths are taken as are. With tpow=0, you would just ignore spell durations, and with tpow=0.5 you would consider the square root of the spell lengths.
The expcost parameter is the expansion cost, i.e. the cost for expanding a (transformed) spell length by one unit. In other words, when in the editing of one sequence into the other a spell of length t1 has to be expanded to length t2, it would cost expcost * |t2^tpow - t1^tpow|. With expcost=0 spells in a same state (e.g. AA and AAAAA) would be equivalent whatever their lengths.
With tpow=.5, for example, increasing the spell length from 1 to 2 costs more than increasing a spell length form 3 to 4. If you do not want to give to much importance to small differences in spell lengths use a low expcost. However, note that the expcost applies to the transformed spell lengths and you may want to adjust it when you change the tpow value.
I have recently been looking into Bitcoin and the proof of work system.
In this system, when mining, a user has a "challenge string" that they need to concatenate with the CORRECT "proof string"(nonce) and hash, the outcome of that hash starts with a prefix of leading zeros and that's how they verify the block.
My question is, when combining that "challenge string" and the CORRECT "proof string"(nonce), why does the corresponding hash of those values start with the prefix of zeros? How does that work?
The combination of "Challenge string" and "proof of string" is sent to a hashing function, which is a one way function and results in a "random string" (The condition on "random string" is that it should have x number of zeroes in the beginning. The difficulty of guessing increases day to day, which is nothing but x increases).
The job of a Miner is to guess the "proof of string" until the condition on the "random string" is met.
So, it is a pure guessing game. GPUs are very good at generating random numbers very quickly. That is why miners around the world are using top class GPUs to mine the bitcoin transactions.
Not specific to Bitcoin but Bitcoin uses the same mechanism, see https://en.wikipedia.org/wiki/Hashcash for a description of how Proof Of Work "works" and why it works that way.
The short answer is that you are creating a hash collision (https://en.wikipedia.org/wiki/Collision_resistance) and the more leading zeros there are the more difficult it is to create the collision.
In Bitcoin, the difficulty is algorithmically chosen based on the compute on the bitcoin network. This typically only goes up, but should the compute go down the dificulty will also go down. The algorithm adjusts dificulty to keep transaction verification time around 10 minutes.
Say I have an set of string:
x=c("a1","b2","c3","d4")
If I have a set of rules that must be met:
if "a1" and "b2" are together in group, then "c3" cannot be in that group.
if "d4" and "a1" are together in a group, then "b2" cannot be in that group.
I was wondering what sort of efficient algorithm are suitable for generating all combinations that meet those rules? What research or papers or anything talk about these type of constrained combination generation problems?
In the above problem, assume its combn(x,3)
I don't know anything about R, so I'll just address the theoretical aspect of this question.
First, the constraints are really boolean predicates of the form "a1 ^ b2 -> ¬c3" and so on. That means that all valid combinations can be represented by one binary decision diagram, which can be created by taking each of the constraints and ANDing them together. In theory you might make an exponentially large BDD that way (that usually doesn't happen, but depends on the structure of the problem), but that would mean that you can't really list all combinations anyway, so it's probably not too bad.
For example the BDD generated for those two constraints would be (I think - not tested - just to give an idea)
But since this is really about a family of sets, a ZDD probably works even better. The difference, roughly, between a BDD and a ZDD is that a BDD compresses nodes that have equal sub-trees (in the total tree of all possibilities), while the ZDD compresses nodes where the solid edge (ie "set this variable to 1") goes to False. Both re-use equal sub-trees and thus form a DAG.
The ZDD of the example would be (again not tested)
I find ZDDs a bit easier to manipulate in code, because any time a variable can be set, it will appear in the ZDD. In contrast, in a BDD, "skipped" nodes have to be detected, including "between the last node and the leaf", so for a BDD you have to keep track of your universe. For a ZDD, most operations are independent of the universe (except complement, which is rarely needed in the family-of-sets scenario). A downside is that you have to be aware of the universe when constructing the constraints, because they have to contain "don't care" paths for all the variables not mentioned in the constraint.
You can find more information about both BDDs and ZDDs in The Art of Computer Programming volume 4A, chapter 7.1.4, there is an old version available for free here.
These methods are in particular nice to represent large numbers of such combinations, and to manipulate them somehow before generating all the possibilities. So this will also work when there are many items and many constraints (such that the final count of combinations is not too large), (usually) without creating intermediate results of exponential size.
I am trying to model linear feedback shift registers in haskell. These can be modeled by polynomials over finite fields, so I am using numeric-prelude to get type classes that resemble mathematical algebraic structures more closely than those in the normal prelude.
I am by no means an expert in abstract algebra, so I have become a little confused about the IntegralDomain type class. The problem is that my book on abstract algebra (A book of abstract algebra by Charles C. Pinter) and the type classes seem to be conflicting with each other.
According to the book, the ring of polynomials over an integral domain, is itself an integral domain. Also, a ring of polynomials over a field is only an integral domain, but with the special(the fact that it is special is mentioned) property that the division algorithm holds.
That is, if F[x] is a polynomial over a field, then for a in F[x] and b!=0 in F[x], there exists q,r in F[x] such that b*q+r=a, and the degree of r is less than that of b.
The fact that this property is special to polynomials over a field, to me implies that it does not hold over any integral domain.
On the other hand, according to the type classes of numeric prelude, a polynomial over a field (that is zeroTestable) is also an IntegraldDomain. But according to the documentation, there are several laws of integralDomains, one of the being:
(a `div` b) * b + (a `mod` b) === a
http://hackage.haskell.org/packages/archive/numeric-prelude/0.4.0.1/doc/html/Algebra-IntegralDomain.html#t:C
This to me looks like the division algorithm, but then the division algorithm is true in any integral domain, including a polynomial over an integral domain contradiction my book. It is also worth noting that a polynomail over an integral domain does not have an instance for IntegralDomain in numeric-prelude(not that I can see at least, the fact that every type class is simply called C, make the documentation a little hard to read). So maybe the IntegralDomain in numeric prelude is an integral domain with the extra property that the division algorithm holds?
So is the IntegralDomain in numeric-prelude really an integral domain?
rubber duck debugging post script: While writing this question I got an idea for part of a possible explanation. Is it the requirement that "the degree of r is less than that of b." which makes the whole difference? That requirement is not in the numeric-prelude IntegralDomain. Then again, some of the other laws might imply this fact...
According to the book, a polynomial over an integral domain, is itself an integral domain.
That's not correctly phrased. The ring of polynomials over an integral domain is again an integral domain.
The ring of polynomials in one indeterminate over a field is even a principal ideal domain, as witnessed by the division algorithm, since every polynomial of degree 0 is a unit then.
In a general integral domain R, you have nonzero non-units, and if a is one, then you cannot write
X = q*a + r
with the degree of r smaller than that of a (which is 0).
Is it the requirement that "the degree of r is less than that of b." which makes the whole difference?
Precisely. That requirement guarantees that the division algorithm terminates. In a general integral domain, you can have a "canonical" choice of remainders modulo any fixed ring element, but the canonical remainder need not be "smaller" in any meaningful way, so an attempt to use the division algorithm need not terminate.
Then again, some of the other laws might imply this fact
None of the laws in Algebra.IntegralDomain imply that.
The law
(a+k*b) `mod` b === a `mod` b
is, I believe, hard to implement for a completely general integral domain, which could somewhat restrict the actual instances, but for something like Z[X] or R[X,Y] which are not PIDs, an instance is possible.