In RST for a sphinx documentation and using the sphinx.ext.imgmath extension for maths equations, I would like to add an equation in the middle of a bullet point list but have a second paragraph after the said equation and keep the indentation level of the bullet point. I think the problem would be the same with any other kind of directive than math.
My current RST code looks like this:
Introducing the bullet list on zero-th level indentation:
- First bullet point on first level indentation.
.. math::
centered math equation
I would like this to be at the first level indentation because it belongs to the first bullet point but it lands on zero-th level indentation.
- Second bullet point on first level indentation.
And this gives:
Introducing the bullet list on zero-th level indentation:
- First bullet point on first level indentation.
centered math equation
I would like this to be at the first level indentation because it belongs to the first bullet point but it lands on zero-th level indentation.
- Second bullet point on first level indentation.
but I would like:
Introducing the bullet list on zero-th level indentation:
- First bullet point on first level indentation.
centered math equation
I would like this to be at the first level indentation because it belongs to the first bullet point but it lands on zero-th level indentation.
- Second bullet point on first level indentation.
Indent the math block and the paragraph after it.
Introducing the bullet list on zero-th level indentation:
- First bullet point on first level indentation.
.. math::
centered math equation
I would like this to be at the first level indentation because it belongs to the first bullet point but it lands on zero-th level indentation.
- Second bullet point on first level indentation.
Consistent indentation is very important. See https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#indentation.
Related
In the "A Faster Scrabble Move Generation Algorithm" written by Steven a. Gordon, a move generation algorithm for scrabble is introduced. However, the pseudocode provided was a little confusing.
The move generation algorithm laid out in the paper describes the following process:
start on an anchor square, for each letter on the rack, put it on the anchor square, move leftwards, recording complete words along the way, at each step, look for the delimiter in the arcs, go on the arc for the delimiter, and start moving rightward starting on square right of the anchor, record complete words along the way.
Let's say we have a line with the word "log" in the middle of a row. As I understand it, the square before "l" and the square after "g" would be the two anchor squares of this row (assuming "log" is the only word on the board). However, this doesn't make any sense. The algorithm starts from the anchor, move leftward first, and then move rightward, so in the entire time it's moving leftward, the existing "log" on the board doesn't play any role in move generation, so I can easily end up with things like "happy", which makes "happylog" on the board, which wouldn't be a word. I feel like I'm not understanding this correctly. What am I getting wrong?
Anchor squares also have direction (vertical or horizontal) and a list of allowable tiles for that direction. If log is horizontal, the anchor square in front of log is vertical and would only allow the letters B, C, F or S (and possibly V is some future lexicons).
For playing through LOG, the anchor square would be the L and the algorithm would have to travers the L O and G through the GADDAG before trying the play any tiles on the rack. For example if the rack contained the tiles AHOMR, then it could follow the path LOGRAM*OH through the GADDAG to play HOLOGRAM.
Steven Gordon
So I have an image with 3 dots on it.
This is the correct orientation of the image but it can be at any degree of rotation. My goal is to identify the dots for ease we'll call them Left dot, right dot and bottom dot.
Now getting the bottom dot is easy as you just take the distances between the 3 dots and which ever dot isn't on the longest line is the bottom one.
So that leaves me with problem of identifying the left and right dot. I feel like I've forgotten some basic trig for figuring this out but my google-foo has failed me at uncovering a formula to determine the left and right side.
The 2D cross-product of two vectors, , is a scalar which is positive for when a is clockwise rotated with respect to b, and vice versa. So in the diagram below:
The left and right points satisfy and respectively.
I will begin by saying that I am very new to Prolog, and that it is still very hard for me to come up with a solution and not think it in a procedural or a functional way.
The context of the problem is as follows: I have to move in four directions starting from the initial position (0,0). When I move up I update my position to (0,1), down to (0, -1), left to (-1,0) and right to (1, 0). At some point I have to go back to my initial position.
I have solved the problem by memorizing all the moves that I do to a certain point and then do the reverse. So if the moves I did were down, left I just go up, west. The solution works, but it is very inefficient and dumb.
So the thing I want to do is to make a procedure that takes the current position (X,Y) and evaluates to one of the four moves if by updating the position I am closer to (0,0).
I have tried to write some code, but the truth is that I don't really know how to think the problem in Prolog. Can someone give me some hints how I can solve it ? Thank you!
First, you need a way to represent the legal directions to where you can move. A simple solution is to use the atoms up, down, left, and right. Next, you can define a predicate that, given a position and a direction, computes the resulting position. For example:
move((X,Y), up, (X,NewY)) :- NewY is Y + 1.
...
If you want to perform a sequence of moves, e.g. [up, left, up, up, right, down], you can define another predicate that takes a sequence and an initial position and computes the final position while keeping track of all intermediate positions (using an additional argument). You can also, in alternative, work the sequence backwards, back-tracing your moves. Can you try it and update your question with the results?
does anybody know of a good algorithm for this task:
a multi polygon contains the reserved areas
find an empty position for the given polygon which is closest to its original position but does not intersect the reserved areas
I have implemented some very basic algorithm which does the job but far from optimally.
Thank You!
Edit:
my solution basically does the following:
move given polygon in all possible directions dx and dy
check wether the new intersection is less than the previous intersection
if so, use new position and make sure that you don't move your polygon back and forth at the same position
repeat these steps a maximum of N times
Example: it is intended for placing text which should not overlap with each other.
One method that immediately pops into my mind is to shoot a ray (i.e. measure a line segment) from the original position to every vertex of the polygon. Do a comparison on those distances, and then based on those comparisons, narrow it down to the minimally far away line segment of the polygon. Compute the perpendicular intersection of that line with the origin, and you'll get the minimally far away point. If the vertex comparisons don't lead you down the right path, just shoot off lines in random directions, and just stop when you're happy with the result. It doesn't sound like you require optimality.
Let's look at the original problem: making sure that one piece of text doesn't overlap another. Presumably this is for labelling a map. The way I do it is this: draw the text invisibly, checking for overlap (by using a specialised graphics context that instead of drawing a pixel, checks whether a pixel is already there) then try another position along the line on which the text is to be placed - usually a street. I try the middle of the line first, then successive positions further and further left and right of the middle. If that fails I try again with a condensed (narrower) font.
I have to make a flash game like this:
There is a board with holes in it (more than 1000). Initially, there are 3 pegs placed on the board and a rubber band around them.
We have 3 possible operations:
1. Add peg - adds a peg on the board
2. Remove peg - removes a peg ( if there are more than 3 pegs) - the rubber band must take the shape of the remaining pegs.
3. Move peg - rubber band must be updated with current positions of the pegs.
How would you solve the problem of finding the rubber band's shape optimally?
I have 2 ideeas, but I have to work on them a little bit. The main ideea is that we have to change the rubber band's shape only at "Move" operation, and we use the same number of pegs, only one is changing position:
A derivation from convex hull algorithm. We have to know wich pegs are inside the rubber band and wich are outside. It might get a little complicated.
We work with only 3 pegs: 2 anchors and 1 middle. The 2 anchors form a boundary line for the interaction of the 1 middle peg. On the active side of the line the rubber band functions as 2 segments between the 2 anchor pegs and the middle peg. On the inactive side the 1 middle peg is free to move while the rubber band functions as a straight line between the 2 anchor pegs. The caveat to the above is that there are cases in which movement of the 1 middle peg in the active side of the boundary line can can cause one of the 2 segments to contact a 4th peg. The program must detect this occurrence and update the new anchor pegs accordingly. These are just suggestions from some limited experience with this concept. The developer should determine the best approach based on his experience and judgement.
Do you have any other ideeas, or suggestions?
"The developer should determine the best approach based on his experience and judgement." — did you copy and paste this from the spec you were given? :)
You ask for an "optimal" solution but if I were you I'd aim for a "correct, and fast enough" solution. You've got a contract to fulfil, you can leave the asymptotics to the academics.
Anyway, your plan to update the band only when the player moves a peg looks like a good one. We are going to need to remember all the pegs that are touching the rubber band, and for each peg we have to remember which side of the rubber band it's on (in order to draw the band correctly).
Now, suppose the player moves peg A from a to a'.
As a general principle, it's worth bearing in mind that even if your time segments are short, and the distance from a to a' is small, nonetheless there might be multiple things that happen. So you're going to have to consider all the events that might happen in that time segment, pick the earliest such event, update your data structures accordingly, and then continue with the remainder of the time segment.
So what kind of events are there?
Peg A "picks up" the band. (It does so if peg A was not already on the band, and the line a–a' crosses one of the lines between pegs on the band.)
Peg A "puts down" the band. (It does so if peg A was on the band, with neighbours B and C, and the line a–a' crosses the line B–C.)
Peg A gains a neighbour on the band. (This happens when peg A is on the band, B is a neighbour of A and the triangle a–a'–B contains another peg C.)
Peg A loses a neighbour on the band. (This happens when peg A is on the band, the neighbouring pegs on the band go A–B–C, and peg B is in the triangle a–a'–C.)
So you should determine all such events; work out the time that each event would happen; sort the events into order by time; handle the earliest event (only); repeat for the remainder of the time segment.
(What to do if two events happen simultaneously? I'll leave that up to your experience and judgement.)
Edited to add: a complication is that a peg may appear on more than one segment of the rubber band (for example, the band may go A-B–A-C-A). But I think the above sketch of an algorithm still works.
A further wrinkle is that even with a small number of pegs, you can make arbitrarily twisty configurations of the band. For example, suppose the band is stretched between pegs B and C. Now take peg A and move it in a figure-of-8 around pegs B and C (clockwise around B, anti-clockwise around C, let's say). Each time round the loop, peg A picks up another couple of pieces of the band. You can't afford to let the complexity of the configuration grow without bound, so need some way of stopping things getting out of hand. I suggest imposing a maximum limit on the length of the band, so that any attempt to stretch it too far causes it to snap (of course you'd have warning signs before this happens, e.g. band getting thinner, changing colour, ominous creaky sounds).