I am trying to make a 3D, surfaced graph using gnuplot (in C++). This is code I currently have.
//gp << "set dgrid3d\n";
//gp << "set samples 10,10\n";
//gp << "set isosamples 10,10\n";
//gp << "set contour\n";
//gp << "set hidden3d\n";
//gp << "set surface\n";
//gp << "set pm3d\n";
gp << "splot 't.dat' u 1:4:5 w linespoints pointtype 7 pointsize 1.5, \
't.dat' u 2:4:5 w linespoints pointtype 9 pointsize 1.5, \
't.dat' u 3:4:5 w linespoints pointtype 4 pointsize 1.5\n";
As you can see I have tried a number of commands (currently commented) to achieve the goal. I cannot seem to find a suitable combination of commands or a single command which gives me a 3D graph with a surface like which I seek.
This is 't.dat' - the data that I am attempting to plot:
#timeTaken1 timeTaken2 timeTaken3 D E
1.2342423 1.33 2.442 1 0
1.234234 1.55 2.236 1 20
2.56465 1.56 3.39 1 40
2.464 1.234 3.224 1 60
2.2747 1.768 3.552 1 80
2.34774 1.876 3.574 1 100
3.34747 2.94 4.795 2 0
3.34747 2.66 5.776 2 20
3.3747 3.234 5.666 2 40
3.787 3.66 6.503 2 60
3.456 3.88 6.37 2 80
4.345 3.345 5.853 2 100
Does someone know what needs to be done to make this work? Is there something wrong with the structure of the data? Is there some command I haven't seen?
With splot you can only plot your data points (and connect them) as you can in 2D. To draw a surface, you have to find out an f(x,y) function and also splot it. Or you can manually interpolate a hundred or thousand of the surface coordinates into 't2.dat' and splot 't2.dat' w l.
Related
When reading an off-file with cgal it appears that the vertex order of a face decides whether or not it is read in by read_OFF. But the off-file definition does not say anything about the vertex order of a face.
I am reading in self generated off-files using the read_OFF method of cgal:
using Kernel = CGAL::Exact_predicates_inexact_constructions_kernel;
using Point_3 = typename Kernel::Point_3;
...
CGAL::Surface_mesh<Point_3> test_mash;
CGAL::IO::read_OFF(file_name, test_mash);
std::cout << "Number of vertices: " << test_mash.vertices().size()
<< ", Number of faces: " << test_mash.faces().size() << std::endl;
two_faces_read.off:
OFF
4 2 0
1 1 1
2 -2 2
3 3 -3
-4 4 4
3 0 1 2
3 0 3 1
one_face_read.off:
OFF
4 2 0
1 1 1
2 -2 2
3 3 -3
-4 4 4
3 0 1 2
3 0 1 3
Reading two_faces_read.off works as expected, printing:
Number of vertices: 4, Number of faces: 2.
But when i read one_face_read.off i get Number of vertices: 4, Number of faces: 1. The only difference between these two files is the last line, the vertex order of the second face is different. After trying all possible combinations it seems that with 031, 103, 310 2 faces are read in, while with 013, 130, 301 only 1 face is read in.
The off-file specification referenced by cgal does not mention any rules concerning the vertex order of a face.
Why does this happen and how can i ensure that all faces are read in?
one_face_read.off does not define a valid surface mesh has the orientation of the two faces are not compatible. You can use the following function to read points and faces and call CGAL::Polygon_mesh_processing::is_polygon_soup_a_polygon_mesh() to check if the input is a valid surface mesh. The function CGAL::Polygon_mesh_processing::orient_polygon_soup() can be used to fix orientations. CGAL::Polygon_mesh_processing::polygon_soup_to_polygon_mesh() can be used to create the mesh.
I am currently developing a chess engine in C++, and I am in the process of debugging my move generator. For this purpose, I wrote a simple perft() function:
int32_t Engine::perft(GameState game_state, int32_t depth)
{
int32_t last_move_nodes = 0;
int32_t all_nodes = 0;
Timer timer;
timer.start();
int32_t output_depth = depth;
if (depth == 0)
{
return 1;
}
std::vector<Move> legal_moves = generator.generate_legal_moves(game_state);
for (Move move : legal_moves)
{
game_state.make_move(move);
last_move_nodes = perft_no_print(game_state, depth - 1);
all_nodes += last_move_nodes;
std::cout << index_to_square_name(move.get_from_index()) << index_to_square_name(move.get_to_index()) << ": " << last_move_nodes << "\n";
game_state.unmake_move(move);
}
std::cout << "\nDepth: " << output_depth << "\nTotal nodes: " << all_nodes << "\nTotal time: " << timer.get_milliseconds() << "ms/" << timer.get_milliseconds()/1000.0f << "s\n\n";
return all_nodes;
}
int32_t Engine::perft_no_print(GameState game_state, int32_t depth)
{
int32_t nodes = 0;
if (depth == 0)
{
return 1;
}
std::vector<Move> legal_moves = generator.generate_legal_moves(game_state);
for (Move move : legal_moves)
{
game_state.make_move(move);
nodes += perft_no_print(game_state, depth - 1);
game_state.unmake_move(move);
}
return nodes;
}
It's results for the initial chess position (FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1) for depths 1 and 2 match the results of stockfish's perft command, so I assume they are correct:
h2h3: 1
h2h4: 1
g2g3: 1
g2g4: 1
f2f3: 1
f2f4: 1
e2e3: 1
e2e4: 1
d2d3: 1
d2d4: 1
c2c3: 1
c2c4: 1
b2b3: 1
b2b4: 1
a2a3: 1
a2a4: 1
g1h3: 1
g1f3: 1
b1c3: 1
b1a3: 1
Depth: 1
Total nodes: 20
Total time: 1ms/0.001s
h2h3: 20
h2h4: 20
g2g3: 20
g2g4: 20
f2f3: 20
f2f4: 20
e2e3: 20
e2e4: 20
d2d3: 20
d2d4: 20
c2c3: 20
c2c4: 20
b2b3: 20
b2b4: 20
a2a3: 20
a2a4: 20
g1h3: 20
g1f3: 20
b1c3: 20
b1a3: 20
Depth: 2
Total nodes: 400
Total time: 1ms/0.001s
The results stop matching at depth 3, though:
Stockfish:
go perft 3
a2a3: 380
b2b3: 420
c2c3: 420
d2d3: 539
e2e3: 599
f2f3: 380
g2g3: 420
h2h3: 380
a2a4: 420
b2b4: 421
c2c4: 441
d2d4: 560
e2e4: 600
f2f4: 401
g2g4: 421
h2h4: 420
b1a3: 400
b1c3: 440
g1f3: 440
g1h3: 400
Nodes searched: 8902
My engine:
h2h3: 361
h2h4: 380
g2g3: 340
g2g4: 397
f2f3: 360
f2f4: 436
e2e3: 380
e2e4: 437
d2d3: 380
d2d4: 437
c2c3: 399
c2c4: 326
b2b3: 300
b2b4: 320
a2a3: 280
a2a4: 299
g1h3: 281
g1f3: 280
b1c3: 357
b1a3: 320
Depth: 3
Total nodes: 7070
Total time: 10ms/0.01s
I figured that my move generator was just buggy, and tried to track down the bugs by making a move the engine gives incorrect values for on the board and then calling perft() with depth = 2 on it to find out which moves are missing. But for all moves I tried this with, the engine suddenly starts to output the correct results I expected to get earlier!
Here is an example for the move a2a3:
When calling perft() on the initial position in stockfish, it calculates 380 subnodes for a2a3 at depth 3.
When calling perft() on the initial position in my engine, it calculates 280 subnodes for a2a3 at depth 3.
When calling perft() on the position you get after making the move a2a3 in the initial position in my engine, it calculates the correct number of total nodes at depth 2, 380:
h7h5: 19
h7h6: 19
g7g5: 19
g7g6: 19
f7f5: 19
f7f6: 19
e7e5: 19
e7e6: 19
d7d5: 19
d7d6: 19
c7c5: 19
c7c6: 19
b7b5: 19
b7b6: 19
a7a5: 19
a7a6: 19
g8h6: 19
g8f6: 19
b8c6: 19
b8a6: 19
Depth: 2
Total nodes: 380
Total time: 1ms/0.001s
If you have any idea what the problem could be here, please help me out. Thank you!
EDIT:
I discovered some interesting new facts that might help to solve the problem, but I don't know what to do with them:
For some reason, using std::sort() like this in perft():
std::sort(legal_moves.begin(), legal_moves.end(), [](auto first, auto second){ return first.get_from_index() % 8 > second.get_from_index() % 8; });
to sort the vector of legal moves causes the found number of total nodes for the initial position (for depth 3) to change from the wrong 7070 to the (also wrong) 7331.
When printing the game state after calling game_state.make_move() in perft(), it seems to have had no effect on the position bitboards (the other properties change like they are supposed to). This is very strange, because isolated, the make_move() method works just fine.
I'm unsure if you were able to pin down the issue but from the limited information available in the question, the best I can assume (and something I faced myself earlier) is that there is a problem in your unmake_move() function when it comes to captures since
Your perft fails only at level 3 - this is when the first legal capture is possible, move 1 and 2 can have no legal captures.
Your perft works fine when it's at depth 1 in the position after a2a3 rather than when it's searching at depth 3 from the start
This probably means that your unmake_move() fails at a depth greater than 1 where you need to restore some of the board's state that cannot be derived from just the move parameter you are passing in (e.g. enpassant, castling rights etc. before you made the move).
This is how you would like to debug your move generator using perft.
Given startpos as p1, generate perft(3) for your engine and sf. (you did that)
Now check any move that have different nodes, you pick a2a3. (you did that)
Given startpos + a2a3 as p2, generate perft(2) for your engine and sf. (you partially did this)
Now check any move that have different nodes in step 3. Let's say move x.
Given startpos + a2a3 + x as p3, generate perft(1) for your engine and sf.
Since that is only perft(1) by this time you will be able to figure out the wrong move or the missing move from your generator. Setup that last position or p3 on the board and see the wrong/missing moves from your engine compared to sf perft(1) result.
I plan to run the following cross-sectional regression for 10 years and plot the coefficient estimate for variable x in one graph.
Thanks to this post, I wrote the following and it works:
forvalues i=1/10 {
reg y x if year==1
estimates store year`i'
local allyears `allyears' year`i' ||
local labels `labels' `i'
}
coefplot `allyears', keep(grade) vertical bycoefs bylabels(`labels')
I want to add the following to the same graph but don't know how:
A horizontal line segment x=5 for year 1 to year 5, and another horizontal line segment x=4 for year 6 to year 10.
A shaded area ranging from x=4 to x=6 for year 1 to year 5, and another shaded area ranging from x=2 to 4 for year 6 to year 10.
(Note that my horizontal axis is year, and my vertical axis is coefficient for x.)
Any help is greatly appreciated!
Here's an example based on the nlswork toy dataset:
clear
use http://www.stata-press.com/data/r12/nlswork.dta
for values i = 70 / 73 {
regress ln_w grade if year==`i'
estimates store year`i'
local allyears `allyears'year`i' ||
local labels `labels' `i'
}
coefplot `allyears', keep(grade) vertical bycoefs bylabels(`labels') ///
addplot(scatteri 0.08 1 0.08 3, recast(connected) || ///
scatteri 0.09 1 0.09 3, recast(connected) || ///
scatteri 0.065 2 0.065 3 0.075 3 0.075 2, recast(area) lwidth(none))
Im trying to build a simple input/output matrix (where you can calculate the multiplier effect in a simple economy if demand increases). But for some reason the final result is not adding up.
#include <iostream>
#include <Eigen/Dense>
using namespace std;
using namespace Eigen;
void InputOutput(){
MatrixXf ProdA(5, 5);;
VectorXf Intd(5);
VectorXf Finald(5);
ProdA <<
10, 20, 0, 0, 5,
20, 30, 20, 10, 10,
10, 10, 0, 10, 10,
10, 40, 20, 5, 5,
20, 20, 30, 5, 5;
Intd << 55, 40, 20, 30, 10;
Finald << 0, 0, 0, 0, 0;
VectorXf ones(5);
ones << 1, 1, 1, 1, 1;
Finald = ProdA * ones + Intd;
MatrixXf AMatrix = MatrixXf::Zero(ProdA.rows(), ProdA.cols());
AMatrix = ProdA.array() / (Finald.replicate(1, ProdA.cols())).array();
cout << "Here is the Coefficient vector production needed:\n" << AMatrix << endl;
MatrixXf IminA(5, 5);;
IminA = MatrixXf::Identity(AMatrix.rows(), AMatrix.cols()) - AMatrix;
cout << "Here is the matrix of production:\n" << ProdA << endl;
cout << "Here is the vector Internal demand:\n" << Intd << endl;
cout << "Here is the vector Final demand:\n" << Finald << endl;
cout << "Here is the Coefficient vector production needed:\n" << AMatrix << endl;
MatrixXf IminAinv(5, 5);;
IminAinv = IminA.inverse();
cout << "The inverse of CoMatrix - Imatrix is:\n" << IminAinv << endl;
cout << "To check, final demand is:\n" << (IminAinv * Intd) << endl;
When I verify if the (I-A)inverse matrix (or IminAinv) is properly calculated it doesn't add up. By multiplying the IminAinv by Internal demand (int), I should get the same Intd. That is if Intd isn't changed. Instead I get a bigger number. Also if I calculate the inverse of the IminA matrix myself, I get something different then eigen.
So something goes wrong in getting the inverse of Identity matrix - Coefficient matrix. But what?
Thanks!
EDIT :
After some more digging into why there are some differences in the final results, I discovered that those "underlying mechanisms" mentioned in Case 2 were, in fact, my own mistake out of inadvertence while entering the matrices' values.
Here follows the original answer with these mistakes taken care of.
The actual problem does not lie in the inversion of the AMatrix but in a much more subtle detail.
You are using this command to perform the division in the definition of AMatrix:
AMatrix = ProdA.array() / (Finald.replicate(1, ProdA.cols())).array();
But if you check the results of this replicate operation on Finald you get:
...
cout << "Here is the replicated final demand vector:\n" << (Finald.replicate(1, ProdA.cols())).array() << endl;
...
>>
Here is the replicated final demand vector:
90 90 90 90 90
130 130 130 130 130
60 60 60 60 60
110 110 110 110 110
90 90 90 90 90
whereas the correct one should be:
90 130 60 110 90
90 130 60 110 90
90 130 60 110 90
90 130 60 110 90
90 130 60 110 90
You can transpose the replicated final demand vector like this:
MatrixXf Finaldrep(5,5);
Finaldrep = (Finald.replicate(1, ProdA.cols())).array().transpose();
and then of course:
AMatrix = ProdA.array() / Finaldrep.array();
which yields:
cout << "Here is the transposed replicated final demand vector:\n" << Finaldrep << endl;
...
>>
Here is the transposed replicated final demand vector:
90 130 60 110 90
90 130 60 110 90
90 130 60 110 90
90 130 60 110 90
90 130 60 110 90
So, let's see what are the differences in your intermediate and final results in both these cases:
Case 1
ie Your current approach
Here is the Coefficient vector production needed:
0.111111 0.222222 0 0 0.0555556
0.153846 0.230769 0.153846 0.0769231 0.0769231
0.166667 0.166667 0 0.166667 0.166667
0.0909091 0.363636 0.181818 0.0454545 0.0454545
0.222222 0.222222 0.333333 0.0555556 0.0555556
The determinant of IminA is: 0.420962
The inverse of CoMatrix - Imatrix is:
1.27266 0.468904 0.131153 0.0688064 0.13951
0.443909 1.68132 0.377871 0.215443 0.240105
0.451292 0.628205 1.25318 0.287633 0.312705
0.404225 0.841827 0.423093 1.20242 0.224877
0.586957 0.777174 0.586957 0.23913 1.27174
To check, final demand is:
94.8349
108.09
86.7689
102.689
95
I have also added the determinant of IminA
Case 2
ie using the reversed final demand vector
Here is the Coefficient vector production needed:
0.111111 0.153846 0 0 0.0555556
0.222222 0.230769 0.333333 0.0909091 0.111111
0.111111 0.0769231 0 0.0909091 0.111111
0.111111 0.307692 0.333333 0.0454545 0.0555556
0.222222 0.153846 0.5 0.0454545 0.0555556
The determinant of IminA is: 0.420962
The inverse of CoMatrix - Imatrix is:
1.27266 0.324626 0.196729 0.0562962 0.13951
0.641202 1.68132 0.818721 0.254615 0.346818
0.300861 0.289941 1.25318 0.156891 0.20847
0.494053 0.712316 0.77567 1.20242 0.27485
0.586957 0.538044 0.880435 0.195652 1.27174
To check, final demand is:
90
130
60
110
90
Now, I understand that the Finald check still does not produce the exact values of the originally defined Finald, but I believe that this has something to do with the precision or some other underlying mechanism. (see NOTE)
As a proof of concept here are some results obtained with MATLAB, using the second case (reversed) for the replicated Final Demand Vector (denom):
>> AMatrixcm = ProdA ./ Finaldfullcm
AMatrixcm =
0.1111 0.1538 0 0 0.0556
0.2222 0.2308 0.3333 0.0909 0.1111
0.1111 0.0769 0 0.0909 0.1111
0.1111 0.3077 0.3333 0.0455 0.0556
0.2222 0.1538 0.5000 0.0455 0.0556
>> IminAcm = eye(5) - AMatrixcm
IminAcm =
0.8889 -0.1538 0 0 -0.0556
-0.2222 0.7692 -0.3333 -0.0909 -0.1111
-0.1111 -0.0769 1.0000 -0.0909 -0.1111
-0.1111 -0.3077 -0.3333 0.9545 -0.0556
-0.2222 -0.1538 -0.5000 -0.0455 0.9444
>> det(IminAcm)
ans =
0.4210
>> IminAinvcm = inv(IminAcm)
IminAinvcm =
1.2727 0.3246 0.1967 0.0563 0.1395
0.6412 1.6813 0.8187 0.2546 0.3468
0.3009 0.2899 1.2532 0.1569 0.2085
0.4941 0.7123 0.7757 1.2024 0.2748
0.5870 0.5380 0.8804 0.1957 1.2717
>> Finaldcheckcm = IminAinvcm * Intdc
Finaldcheckcm =
90.0000
130.0000
60.0000
110.0000
90.0000
It is quite clear that the second case results are (almost) identical to the MATLAB ones.
NOTE: Here you can see that the MATLAB output is identical to the original Finald, however, if you perform the last matrix multiplication (the one in the validation of the Final Demand vector) by hand, you will see that in fact both MATLAB and Case 2 versions of IminAinv yield the same result as the final output of Case 2, ie [88.9219, 125.728, 59.5037, 105.543, 84.5808].
This is why I think that there is some other mechanism involved in these differences. (See EDIT on top of post)
I try to draw a normal XY plot using a TChart (TeeChart) component in Embarcadero RAD Studio. When I add new points that have evenly spaced x values, e. g.
x: 1 2 3 4 5
y: 10 20 5 8 100
everything is drawn OK.
But when I add points that are unevenly spaced on the x axis, e. g.
x: 1 2 100 120 150
y: 10 20 5 8 100
the chart is drawn in such a way that the points still have the same distance between each other on the x axis. That is the distance between points 1-2 is the same as between 2-100. Is it possible to draw a proportional XY plot?
This is my sample code:
Series1->Add(10, 1);
Series1->Add(20, 2);
Series1->Add(5, 100);
Series1->Add(8, 120);
Series1->Add(100, 150);
The style of Series1 is Line.
Instead of calling Add, you need to call AddXY to add XY points.