I'm trying to implement drawing Pifagor's Tree in PostScript via recursion, but something went wrong - my right cathet of each triangle is't painting so my right part is empty. What am i doing wrong?
here's the code:
newpath
300 300 moveto
size 0 rlineto
/tree{
1 sub /n exch def
n 0 le { 1}
{
/size exch def %takes size from past stroke(for this case it is number 90 in row №18)
0 size rlineto
size -1 mul 0 rlineto
0 size -1 mul rlineto
0 size rlineto
45 rotate
/size size 2 sqrt mul 0.5 mul def
size 0 rlineto
size n tree
270 rotate
size 0 rlineto
size n tree
}ifelse
} def
90 31 tree %size of square's side, number of iterations
stroke showpage
Well, your program uses 'size' before you define it, in line 3, so it immediately throws an 'undefined' error before drawing anything. I fixed that by changing it to 90:
newpath
300 300 moveto
size 0 rlineto
Your program draws the left side of the tree first, recursing through 'tree'. Then it steps back up a level and draws the matching right side at each level, again recursing as required.
But after we've descended to the smallest object, size has been defined as a tiny number, so the other side is drawn, just so small you can't see it.
You seem to be trying to treat PostScript dictionary entries as if they were local variables in a C function, PostScript doesn't work that way. There are no variables, there are only dictionaries and their contents.
Your code defines /n and /size in the current dictionary. Then it calls 'tree' again, which redefines /n and /size in the current dictionary and so on.
Instead of defining n and size in the current dictionary, you probably want to leave them on the stack. This does mean that if recursion goes deep enough you will get a stackoverflow error, but that's what you would get with any language eventually.
Note that your current program doesn't leave the stack untouched, if n is less than or equal to zero you don't pop 'size' from the stack and you push a '1' onto the stack. So you'll have to address that too.
As an addendum to Ken's answer, you can simulate local variables by installing a new dictionary when the function starts and removing it at the end.
/tree {
1 dict begin
%...
end
} def
If the recusion goes too deep, you will get a dictstackoverflow error.
Related
So my monitor is using raster graphics and is therefore full of pixels.
However, I have heard that Adobe Illustrator uses vector graphics.
So how can vector graphics be shown "real-time" on my monitor that is pixel-based?
From articles like this one, vector and raster graphics are completely different? So why can the they show each other - like they were the same?
The fact that Adobe Illustrator is a "vector program" only means that it is designed to help users work with vectors... just as Audacity, for example, helps users to work with sound, or Notepad lets a user work with characters.
There is no difference between Adobe Illustrator and any other program as far as what the Operating System (OS) and/or hardware expects from it in terms of the way it represents graphics.
Take these three examples:
We can use the idea of a "+" symbol to show the difference between a raster and a vector:
RASTER: A 3 x 3 pixel, black-and-white RASTER of the "+" symbol:
0 1 0
1 1 1
0 1 0
VECTOR: The same symbol as a Vector:
[draw a line from point ( 1/3 X, 1/2 Y ) to point ( 2/3 X, 1/2 Y )]
[draw a line from point ( 1/2 X, 1/3 Y ) to point ( 1/2 X, 2/3 Y )]
These are abstract representations -- they still need to be coded, stored, and displayed.
You can literally see how a raster is coded, stored, and displayed -- as a discrete matrix of values... a mosaic, if you will.
A vector on the other hand is coded and stored as a set of instructions. The x and y co-ordinates are stored as fractions of the total canvas space available (relative as opposed to absolute)... as the dimensions of the canvas space are not yet known... and this is the reason why you can infinitely expand a vector without losing resolution.
Now... if a vector is going to be displayed on an actual "vector display" monitor (very rare), then you could theoretically just send the vector instructions straight to the monitor. BUT... as you ask: "What happens if you're displaying a vector on a conventional monitor (a mosaic of pixels)?"
And... the answer to that is, once again: The same thing that happens when any other abstract concept is being illustrated by any program.
But... the vectors do end up on the screen, so here is a minimal example of how that happens:
Using the "plus symbol" example from above, imagine a really terrible monitor that is only 3 x 3 pixels in resolution. The OS would say to the program (Illustrator, presumably): "I need your raster output to be 3 x 3 pixels wide."
So the program would do this:
1) Draw a line from point ( 1/3 X, 1/2 Y ) to point ( 2/3 X, 1/2 Y )... but convert those points to points within that 3 x 3 pixel matrix... and draw the line by filling the first pixel, the last pixel, and all pixels in-between.
2) Do the same for the second instruction.
3) Hand the resulting 3 x 3 pixel matrix to the OS.
PS - You ask how they can "show each-other." A conventional monitor can show a vector that has been converted to pixels, but I don't think it's ever been done the other way around.
I am new to using PsychoPy and I have programmed a few simple tasks. I am currently really struggling to program a word dot probe. I do not want to use coder, simply because the rest of my research team need to be able to easily edit the program, and work and use it.
In case anyone is wondering what my specific problem is, I cannot seem to get the pictures to load at the same time correctly and do not know how to get a probe to appear behind one of the pictures once the pictures have disappeared.
Timing
The timing issue can be solved by inserting an ISI period in the beginning of the trial, e.g. during a fixation cross. This allows psychopy to load the images in the background so that they are ready for presentation.
Truly random dot position
In your case, you want the dot position to be random, independently of image. This is one of the cases that TrialHandler does not handle and I suspect you need to insert a code component to make this work. For true randomness but only 50% probability in the limit of infinite trials, simply put this in a code component under "begin routine":
x = (np.random.binomial(1, prob) - 0.5) * xdist
y = 0
dot.pos = [x, y]
and change dot to the name of your dot stimulus, y is the vertical offset, x is the horizontal offset (here varying between trials), xdist is the distance between the dot positions, and prob is the chance of the dot appearing to the right. You probably want to set this to 0.5, i.e. 50 %.
Balanced dot position
If you want the dot to appear at each side exactly the same number of times, you can do the following in the code component:
Under "begin experiment", make a list with the exact length of the number of trials:
dotPos = [0, 1] * int(round(numberOfTrials/2)) # create the correct number of left/right (coded as 0 and 1). [0,1] yields 50%. [0,0,0,1] and /4 would yield 25 % etc.
np.random.shuffle(dotPos) # randomize order
Then under "begin routine" do something akin to what we did above:
x = (dotPos.pop() - 0.5) * xdist # dotPos.pop() takes returns the last element while removing it from the list.
y = 0
dot.pos = [x, y]
Naturally, if the number of trials is uneven, one position will be occupied one more time than the other.
Two dot positions for each condition
For the record, if the dot position is to be shown at each position for each image-combination, simply count each of these situations as conditions, i.e. give them a separate rows in the conditions file.
I have problem with rotation check with QGraphicsItemGroup. Several items are grouped into group which is rotating in scene. After rotation, the QGraphicsItem.rotation() always returns 0. The group is flagged with setHandlesChildEvents(False) - if it matters.
Furthermore, all child items are also rotated with group, and same method returns 0 for them as well (...maybe this is OK ).
Am I doing something wrong in checking group rotation ?
EDIT:
item_group.rotate(90)
print item_group.rotation() #prints 0
or
for i in item_group:
i.rotate(90)
print i.rotation() #also prints 0 for each
I'm adding lines to my 3D world like we see in 3D studio max. To draw lines I'm using a cylinder mesh and simply stretching/rotating it appropriately. That's all working fine but my problem is scale. Since it's 3D geometry rendering in perspective its size changes, from a distance it's small to invisible, up close it's huge.
I want to make it so the size of the line geometry stays the same. I tried toying around with orthographic projection but came up with nothing. Any ideas?
Well you could easily write a shader to get round that problem. Basically you need to push it out proportionally to the w value you generate. ie if the cylinder has a width of r. then you can cancel out the perspective by pushing it out to (r * w). This way when the w divide occurs it will ALWAYS give you r.
A cylinder, though, could be a tad excessive you could get a similar effect by drawing a billboarded line and applying a texture to it.
I wrote a shader in DX8 many years ago to do this (mind this is with perspective). Basically I defined the vertex data as follows:
struct BillboardLineVertex
{
D3DXVECTOR3 position;
D3DXVECTOR3 otherPosition;
DWORD colour;
D3DXVECTOR2 UV;
};
Assuming the line goes from A to B then position is A and otherPosition is B for the first 2 vertices. Furthermore I encoded into the V (or y) of the UV either a -1 or 1. This told me whether I would push out from the line up or down the screen. Finally the 3rd coordinate for the triangle had the A & B in position and otherPosition the other way round (I'll leave you to figure out how to build the other triangle. Note that the U texture coord (or x) was settable to allow for texture repeating along the line.
I then had the following bit of shader assembly to build the lines ... This had the added bonus that it took exactly 2 triangles to do one line... I could then pack them all into 1 big vertex buffer and render several hundred in one Draw call.
asm
{
vs.1.1
// Create line vector.
mov r1, v0
sub r3, r1, v4
// Get eye to line vector
sub r6, v0, c20
// Get Tangent to line vector lieing on screen plane.
mul r5, r6.yzxw, r3.zxyw
mad r5, -r3.yzxw, r6.zxyw, r5
// Normalise tangent
dp3 r4.w, r5.xyz, r5.xyz
rsq r4.w, r4.w
mul r5.xyz, r5.xyz, r4.w
// Multiply by 1 or -1 (y part of UV)
mul r5.xyz, r5.xyz, -v9.y
// Push tangent out by "thickness"
mul r5.xyz, r5.xyz, c16.x
add r1.xyz, r1.xyz, r5.xyz
// Transform position
m4x4 oPos, r1, c0
// Work out UV (c16.y is assumed to contain 0.5, c16.z is assumed to contain 1)
mov r2.xy, v9.xy
mul r2.y, v9.y, v9.x
add r2.xy, r2.xy, c16.z
mul oT0.xy, r2.xy, c16.y
// Move colour into diffuse output channel.
mov oD0, v3
};
Such a setup would be easily modifiable to give you the same size regardless of distance from the camera.
I can't seem to find a definitive answer for this, I'm trying to do some elementary proofs on heaps but here's what's throwing me off a little bit:
Is an empty tree valid? If so, what is its height?
I would think this would be 0.
What is the height of a tree with a single node?
I would think this would be 1 but I have seen definitions where it is 0 (and if this is the case then I don't know how to account for an empty tree).
Height of a tree is the length of the path from root of that tree to its farthest node (i.e. leaf node farthest from the root).
A tree with only root node has height 0 and a tree with zero nodes would be considered as empty. An empty tree has height of -1. Please check this.
I hope this helps.
I think you should take a look at the Dictionary of Algorithms and Data Structures at the NIST website. There definition for height says a single node is height 0.
The definition of a valid tree does include an empty structure. The site doesn't mention the height of such a tree, but based on the definition of the height, it should also be 0.
I have seen it used in both ways (counting a single node as 0 or 1), but the majority of sources would define a root-only tree as a tree of height 0, and would not consider a 0-node tree valid.
If your tree is a recursively defined data structure which may be either empty or a node with a left and right subtree (for example search trees, or your heap), then the natural definition is to assign 0 to the empty tree and 1 + the height of the highest subtree to a nonempty tree.
If your tree is a graph then the natural definition is the longest path from the root to a leaf, so a root-only tree has depth 0. You normally wouldn't even consider empty trees in this case.
The height of a tree is the length of the longest path to a terminal node in either of its children.
Wikipedia says the height of an empty tree is -1. I disagree. An empty tree is literally just a tree containing one terminal node (a null or special value which represents an empty tree). Since the node has no children, the length of its longest path must be the empty sum = 0, not -1.
Likewise, a non-empty tree has two children, so by definition there is at least a path >= 1 to a terminal node.
We might define our tree as follows:
type 'a tree =
| Node of 'a tree * 'a * 'a tree
| Nil
let rec height = function
| Node(left, x, right) -> 1 + max (height left) (height right)
| Nil -> 0
According to Wikipedia, the height of a (sub-)tree with one single node is 0. The height of a tree with no nodes would be -1. But I think it's up to you, how you define the height and your proofs should work with either definition.
The definition of the height of a rooted tree is the length of the longest path from the root to a leaf, expressed in the number of edges. This definition does not cover the case of an empty tree, as there is no path at all.
However, for practical reasons, it is convenient to define the height of an empty tree as −1. Here are some of those reasons:
For non-empty trees we have this rule: the height of the tree is equal to the number of levels in that tree, minus 1. If we extrapolate this rule to an empty tree, then we have 0 levels, and thus a height of −1.
A tree with height ℎ has at least ℎ+1 nodes. If the tree is binary, then it has at most 2ℎ+1−1 nodes. If we substitute −1 for ℎ we get 0 for both expressions, and indeed an empty tree has zero nodes.
The height of a tree is one more than the maximum among the heights of the root's subtrees. If the root happens to have no children, we could say it only has "empty" subtrees. And if we consider the height of those empty subtrees to be −1, then we come to the (correct) conclusion that this tree's height is 0.
It would be impractical to define the height of an empty tree as 0, as you would need to define exceptions to the points raised above.
actully a perfect defn for height of tree is d level of leaf of d longest path from root plus 1..accordin 2 this defn f a tree s empty,it wont b havin any level n v cant consider it had zero,coz level of a root s zero ..so empty tree level is -1,than accordin 2 defn its -1+1=0..so ZERO s d height of empty tree...bt n many book they hav given -1 bt no explanation s given