How can I draw the parse tree for 4*(3+5*7).
The sum of the above expression is 152.
first 5*7=35, then 35+3=38, finally 38*4=152.
I am not sure about what I drew. Please Help. Many thanks!
Something like this, perhaps? (pardon my crappy ASCII art skills)
*
/ \
4 (
/ \
+ )
/ \
3 *
/ \
5 7
(an AST would omit the parenthesis, not required for evaluation)
Related
I'm toying with Rakudo Star 2015.09.
If I try to stringify an integer with a leading zero, the compiler issues a warning:
> say (~01234).WHAT
Potential difficulties:
Leading 0 does not indicate octal in Perl 6.
Please use 0o123 if you mean that.
at <unknown file>:1
------> say (~0123<HERE>).WHAT
(Str)
I thought maybe I could help the compiler by assigning the integer value to a variable, but obtained the same result:
> my $x = 01234; say (~$x).WHAT
Potential difficulties:
Leading 0 does not indicate octal in Perl 6.
Please use 0o1234 if you mean that.
at <unknown file>:1
------> my $x = 01234<HERE>; say (~$x).WHAT
(Str)
I know this is a silly example, but is this by design? If so, why?
And how can I suppress this kind of warning message?
Is there a reason you have data with leading zeroes? I tend to run into this problem when I have a column of postal codes.
When they were first thinking about Perl 6, one of the goals was to clean up some consistency issues. We had 0x and 0b (I think by that time), but Perl 5 still had to look for the leading 0 to guess it would be octal. See Radix Markers in Synopsis 2.
But, Perl 6 also has to care about what Perl 5 programmers are going to try to do and what they expect. Most people are going to expect a leading 0 to mean octal. But, it doesn't mean octal. It's that you typed the literal, not how you are using it. Perl 6 has lots of warnings about things that Perl 5 people would try to use, like foreach:
$ perl6 -e 'foreach #*ARGS -> $arg { say $arg }' 1 2 3
===SORRY!=== Error while compiling -e
Unsupported use of 'foreach'; in Perl 6 please use 'for' at -e:1
------> foreachâ #*ARGS -> $arg { say $arg }
To suppress that sort of warning, don't do what it's warning you about. The language doesn't want you to do that. If you need a string, start with a string '01234'. Or, if you want it to be octal, start with 0o. But, realize that stringifying a number will get you back the decimal representation:
$ perl6 -e 'say ~0o1234'
668
I got the following question wrong on a test, but he didn't offer correct answers, and now the semester is over.
Does anyone know this?
I would love to know where I went wrong.
The question was to draw a parse tree for the following expression: (a+b)*(c+d) - 4
I would draw it something like this:
-
/ \
* 4
/ \
+ +
/ \ / \
a b c d
(Pardon my ASCII art skills)
I'm trying to make create a correct huffman tree and was wondering if this was correct. The top number is the frequency/weight and the bottom number is the ASCII code. The string is
"hhiiiisssss". If I entered this into a text file, there would be only one LF correct? I'm not sure why my program is reading in two.
14
-1
/ \
9 5
-1 s(115)
/ \
5 4
-1 i(105)
/ \
3 2
h(104) LF(10)
In a text file there would only be one LF if there is only one line of text, correct.
Something else is wrong though. There are only two 'h' in your string but your tree shows three, and a total of 14 characters. I'm guessing it's a typo?
Aside from that it looks ok and your huffman codes would be (depending on whether you pick '0' for left or right):
s: 1
i: 01
LF: 001
h: 000
If I run grep -C 1 match over the following file:
a
b
match1
c
d
e
match2
f
match3
g
I get the following output:
b
match1
c
--
e
match2
f
match3
g
As you can see, since the context around the contiguous matches "match2" and "match3" overlap, they are merged. However, I would prefer to get one context description for each match, possibly duplicating lines from the input in the context reporting. In this case, what I would like is:
b
match1
c
--
e
match2
f
--
f
match3
g
What would be the best way to achieve this? I would prefer solutions which are general enough to be trivially adaptable to other grep options (different values for -A, -B, -C, or entirely different flags). Ideally, I was hoping that there was a clever way to do that just with grep....
I don't think it is possible to do that using plain grep.
the sed construct below works to some extent, now I only need to figure out how to add the "--" separator
$ sed -n -e '/match/{x;1!p;g;$!N;p;D;}' -e h log
b
match1
c
e
match2
f
f
match3
g
I don't think this is possible using plain grep.
Have you ever used Python? In my opinion it's a perfect language for such tasks (this code snippet will work for both Python 2.7 and 3.x):
with open("your_file_name") as f:
lines = [line.rstrip() for line in f.readlines()]
for num, line in enumerate(lines):
if "match" in line:
if num > 0:
print(lines[num - 1])
print(line)
if num < len(lines) - 1:
print(lines[num + 1])
if num < len(lines) - 2:
print("--")
This gives me:
b
match1
c
--
e
match2
f
--
f
match3
g
I'd suggest to patch grep instead of working around it. In GNU grep 2.9 in src/main.cpp:
933 /* We print the SEP_STR_GROUP separator only if our output is
934 discontiguous from the last output in the file. */
935 if ((out_before || out_after) && used && p != lastout && group_separator)
936 {
937 PR_SGR_START_IF(sep_color);
938 fputs (group_separator, stdout);
939 PR_SGR_END_IF(sep_color);
940 fputc('\n', stdout);
941 }
942
A simple additional flag would suffice here.
Edit: Well, d'oh, it is of course not THAT simple since grep would not reproduce the context, just add a few more separators. Due to the linearity of grep, the whole patch is probably not that easy. Nevertheless, if you have a good case for the patch, it could be worth it.
This does not appear possible with grep or GNU grep. However it is possible with standard POSIX tools and a good shell like bash as leverage to obtain the desired output.
Note: neither python nor perl should be necessary for the solution. Worst case, use awk or sed.
One solution I rapidly prototyped is something like this (it does involve overhead of re-reading the file, and this solution depends on whether this overhead is OK, and the give-away is the original question's use of -1 as fixed number of lines of context which allows simple use of head & tail) :
$ OIFS="$IFS"; lines=`grep -n match greptext.txt | /bin/cut -f1 -d:`;
for l in $lines;
do IFS=""; match=`/bin/tail -n +$(($l-1)) greptext.txt | /bin/head -3`;
echo $match; echo "---";
done; IFS="$OIFS"
This might have some corner case associated with it, and this resets IFS when perhaps not necessary, though it is a hint for trying to use the power of POSIX shell & tools rather than a high level interpreter to get the desired output.
Opinion: All good operating systems have: grep, awk, sed, tr, cut, head, tail, more, less, vi as built-ins. On the best operating systems, these are in /bin.
I have some .rst files and I convert them to .tex file using standard sphinx converter.
In some .rst I have tables with special width like:
.. list-table::
:widths: 50 50
The resulting .tex always contains tables like:
\begin{tabulary}{\textwidth}{|L|L|}
So, the column width is lost.
How can I preserve column width when converting rst to latex?
I used comma separator too,
.. list-table::
:widths: 50 , 50
:header-rows: 1
* - SETTING
- DESCRIPTION
* - Enable
- Enables or disables internal tracing.
* - Verbose
- Enables or disables extended internal tracing.
but it doesn't work.. maybe I used a bad converter? What converter do you recommend?
actually the command
.. tabularcolumns:: |p{4.5cm}|p{8.5cm}|
is needed just before .. list-table::
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-tabularcolumns
try:
:widths: 50, 50
with a comma separator.
The output also depends on how your table is written in rst.
I assumed that you were using the standard rst table syntax, not making tables from bulleted lists (as is possible). For more help, try http://docutils.sourceforge.net/docs/ref/rst/directives.html#tables
Also, if the 50, 50 is the column width, your latex code should look like this:
\begin{tabulary}{ 1\textwidth}{ | p{0.5} | p{0.5} | }
and:
\begin{tabulary}{total width of table}{| column width| column width|}
The docutils rst2latex writer has some issues with tables: http://docutils.sourceforge.net/docs/dev/todo.html#tables , so maybe your problem is related to that? I think the Sphinx writer is based on rst2latex and might thus have the same issues.
I can confirm that this:
.. list-table::
:widths: 10 40 50
* - Module
- Link
- Description
Works with rst2latex
\setlength{\DUtablewidth}{\linewidth}
\begin{longtable*}[c]{|p{0.104\DUtablewidth}|p{0.375\DUtablewidth}|p{0.465\DUtablewidth}|}
\hline
Module
&
Link
&
Description
\\
\hline
But with sphinx, I get what the OP put. So not an rst2latex issue I would gather.
The "Auto" width stuff the docs talk about is also not very functional for me, links tend to bleed over.
Since I have a huge documentation, I tried to fix the latex generation. Also, I consider Latex notation in rst files a disadvantage, because it's inconsistent and requires editors to partly learn a touchy markup language.
I replaced LaTeXTranslator.depart_table with my own version. I copied the original depart_table and added this code (shortened):
def my_depart_table (self, node):
totalColwidth = 0
givenColwidth = []
hasColwidth = False
for tgroup in node:
for tableColspec in tgroup:
try:
if tableColspec.has_key('colwidth'):
totalColwidth += tableColspec['colwidth']
givenColwidth.append(tableColspec['colwidth'])
hasColwidth = True
except:
print "colspec missing. \n"
# original code
if hasColwidth:
colspec = ""
for thisColwidth in givenColwidth:
colspec += ('>{\RaggedRight}p{%.3f\\linewidth}' % (0.95 * thisColwidth / totalColwidth))
#print "using widths: %.3f %s %s" % ((0.95 * thisColwidth / totalColwidth), thisColwidth, totalColwidth)
self.body.append('{' + colspec + '}\n')
# more original code
LaTeXTranslator.depart_table = my_depart_table
Im neither fluent in Python nor Sphinx, so use at own risk. I hope you get the idea or can even give advice.
If you use Python < 3.0 and want to remove the factor 0.95 completely, remember to either cast one of the integers to float or import division from __ future __.