Outlier in the Alpha_Shapes_2 CGAL demo - cgal

I started using CGAL for a project, and I wanted to test alpha shapes with the alpha shapes 2 demo, furnished with CGAL. My input file has been correctly formatted (cf http://pastelink.me/dl/c83d1b warning 22087 lines), but I still have an outlier (cf http://bit.ly/YYZjtp). Is it due to a bug in the demo or too much points on the input ?

The file format is not the correct one, it should be:
x1 y1
...
xn yn
Simplices in the Alpha-complex will be displayed in light blue.

You should remove the first line that indicates the number of points, because the "open()" function of the demo just read points until end-of-file. The file formats in CGAL are not consistent at all. I fell guilty: as a developer myself, I made my own file formats without trying to unify with others. We all did that. :-(

Related

Pentaho - Spoon Decimal from Text File Input

I'm new to Pentaho and have a little problem with the Text file Input.
Currently I have to have several data records written to a database. In the files, the decimal numbers are separated by a point.
Pentaho is currently transforming the number 123.3659 € to 12.33 €.
Can someone help?
When you read the file, do you read it as a csv, excel or something like that? If that's the case, then you can specify the format of the column to interpret the number correctly (I think, I'm talking from memory now) Or maybe playing with the language of the file might work.
If it's a file containing a string, you can use some step like the string operator to replace the point with a comma.
This problem might come from various reasons.
Although I think that by following the next steps you can solve the issue.
-First, you must get a "Replace in String" step;
-Then search for the dot and replace it with nothing as I show in the following image, or with a coma if the number you show is a float;
Example snip
Hope this helped!
Give feedback if so!
Have a good day!

Vector Source block in GNU Radio PSK tutorial

I don't understand the inputs in the Vector Source block in the fourth flowchart in the GNU Radio Guided PSK Tutorial. What is behind the three dots? Please state, in full, the input to the Vector line in the first couple of Vector Source blocks so that I can see and understand the inputs. The tutorial is at: https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation.
The problem I have is in the section called Recovering Timing. There is no link to any file that explains the inputs to the Vector Source blocks. The tutorial shows the surface of the block but not the input. The surface shows 49*[0,]+[1,]+5... and then the next one is 50*[0,]+[1,]+4... I don't understand the input to these Vector Source blocks.
When we updated that tutorial to 3.8, it was decided that only the final flowgraph source would be included in the active gnu radio tree. However, all of the previous ones from 3.7 can be found in https://github.com/gnuradio/gr-tutorial/tree/master/examples/tutorial7 You can get the specific parameters there.
Also note that both the old and new versions of mpsk_stage6.grc were incorrect. Look at https://github.com/gnuradio/gnuradio/issues/3599 to find the solution. NOTE: As of 9 July 2020, that flowgraph has been incorporated into the gnu radio tree, so the link in the tutorial is correct.
that's just a pythonic way of making vectors that are
0,0,0,0,…,0,1,0,…,0
49*[0,] is of the shape integer * list, and that just means "generate a list containing integer repetition of list. So 49*[0,] is a list containing 49 zeros. You can append more lists using +.
Here, the first source contains data that's 49 zeros, followed by a single one, followed by more zeros (likely, 50).
The secons source contains 50 zeros, followed by a one, followed by more zeros (probably 49), and so on.
The idea here is just that they contain the same signal, but shifted!

Fortran write array tab delimited to text file

Is there a way to write an array in one line (without do-loop) (in fortran) and have it being tab-delimited?
I have tried the following two versions without success.. (the first writes just one number and the second writes them all padding with spaces)
real :: var(10)
var = 1
write(*,'(10(t1,f7.2))')
write(*,'(t1,10f7.2)')
I have looked here without finding out howto. (although it gave some info).
real :: var(10)
var=1
write(*,"(10(f7.2,a))") (var(i),achar(9),i=1,10)
The original answer is 100% correct for the question, but a more generic answer I made based on a csv format string Steve Lionel gave on the Intel Fortran forums (I can't seem to find that post right now) is the following:
tsvFormat = '(*(G0.6,:,"'//achar(9)//'"))'
write(*, tsvFormat) ValueArr, moreRealValues, 64.0, maybeAnIntegerArrayToo, string

identify paragraphs of pdf fiiles using itextsharp

Because of some semantic analysis work, I need identify paragraphs from pdf files with iTextSharp. I know the coordinates of iTextSharp live in the left bottom corner of a page. I find three features to define the paragraph boundaries:
if the horizontal axis of the first word in one line is less than that of the general lines;
if the leading of two consecutive lines is larger than that of the general ones;
if one line ends with "." and the horizontal axis of the ending word is less than that of the other lines
However, I am stuck on the second one. How can I know the general leading between two lines in a paragraph? I mean there are different gaps between two consecutive lines, because some letters like 'f','g' need more space than the others like 'a','n' and so on.
Thanks for your help!
I'm assuming that you are parsing your PDF files using the parser functionality available in iTextSharp. See for instance Extract font height and rotation from PDF files with iText/iTextSharp to see how others have done this before you. A more elaborate article can be found here: Using Open Source PDF Technology to Solve the Unstructured Data Problem in Healthcare
Your question is: how can I calculate the leading? That is: how do I know the distance between the base lines of two consecutive lines?
When you parse a PDF using iTextSharp, you see each line as a series of TextRenderInfo object. These objects allow you to get the base line of the text:
LineSegment baseline = renderInfo.GetBaseline();
Vector startpoint = baseline.GetStartPoint();
This Vector consists of different elements: Getting Coordinates of string using ITextExtractionStrategy and LocationTextExtractionStrategy in Itextsharp
You need startpoint[Vector.I2]. See also: How to detect newline from PDF using iTextSharp
The difference between that value for two consecutive lines give you the value of the leading in its modern meaning. In the old times of printing, every character was a block of a fixed size. Printers (the people, not the machines) put a strip of lead between the rows of blocks to create some extra space between the lines. In modern computing, the word was preserved, but its meaning changed. There are no "blocks" anymore, but you could work with the font size. The font size is an average size of the glyphs in a font. Some glyphs will take more space in the height, some will take less, but taking both the leading (distance between baselines) and the font size (average height of each glyph) into account, you can get a fair idea of the "space between the lines".

reading unformatted data, intel ifort vs Ibm xlf

I'm trying to shift from intel ifort to IBM xlf, but when reading "unformatted output data"(unformatted I mean they are not the same length), there is problem. Here is an example:
program main
implicit none
real(8) a,b
open(unit=10,file='1.txt')
read (10,*) a
read (10,*) b
write(*,'(E20.14E2)'),a,b
close(10)
end program
1.txt:
0.10640229631236
8.5122792850319D-02
using ifort I get output:
0.10640229631236E+00
0.85122792850319E-01
using xlf I get output:
' in the input file. The program will recover by assuming a zero in its place.e invalid digit '
0.10640229631236E+00
0.85122792850319E-01
Since the data in the 1.txt is unformatted, I can't use a fixed format to read the data. Dose anyone know how to solve this warning?
(Question answered in the comments. See Question with no answers, but issue solved in the comments (or extended in chat) )
#M.S.B wrote:
Is there an apostrophe in the input file? Or any character besides digits, decimal point and "D"? Your reads are "list directed".
The OP Wrote:
Yes it seems to have some character after 0.10640229631236 that costs this warning. When I write those numbers to a new file by hand(change line after 0.10640229631236 by the enter key), this warning goes away. I cat -v these two files: With the warning file I get 0.10640229631236^M 8.5122792850319D-02 while the no warning files I get 0.10640229631236 8.5122792850319D-02 Do you know what that M stands for and where it comes from?
#agentp gave the link:
'^M' character at end of lines
Which explains that ^M is the windows character for carriage return