For accordion music sheet notation it is common to specify
the pitches in parenthesis, e.g. (E in parenthesis in the snippet below). This is my target:
The pitches in parenthesis (1) are not played and should not take up additional logical time in a measure (they are used for player's convenience when reading the music sheet), (2) they should stay near the chord.
My LilyPond code now is as follows:
\version "2.18.2"
\include "deutsch.ly"
#(set-global-staff-size 20.0)
\relative c {
\clef bass
e8 <gis d' e>^7 h, q
\override Stem.details.beamed-lengths = #'(0)
\grace \parenthesize e
\revert Stem.details
e <gis d' e> gis, q
\override Stem.details.beamed-lengths = #'(0)
\grace \parenthesize e'
\revert Stem.details
}
Using lilypond --pdf sample.ly I get the following as a result:
The result I obtain in LilyPond has several problems: (i) stem length has no effect on grace notes, (ii) grace note is moved to the next bar and ideally it should stay near the chord, (iii) the parenthesis are too small (although it is a minor remark).
How can I achieve the desired effect (i.e. as in the first picture) using LilyPond?
P.S. edit:
I was able to create a workaround (see below), which is not elegant, but does the job:
\version "2.18.2"
\include "deutsch.ly"
#(set-global-staff-size 20.0)
\relative c {
\clef bass
e8 <gis d' e>^7 h, \afterGrace q
{
\override Stem.thickness = #-1.0
\parenthesize e4
\revert Stem.thickness
}
e8 <gis d' e> gis,_B \afterGrace q
{
\override Stem.thickness = #-1.0
\parenthesize e'4
\revert Stem.thickness
}
}
The output of the above snippet is as follows:
Is there a better way to achieve it?
Instead of using \override Stem.thickness = #-1.0, a more elegant solution would be to use the stencil property. This property can be used to omit stems, flags, note heads, etc. Also, you can use the statement \once \override <something> if you want to override just a single note/chord and automatically revert back after it. Finally, you can also define a musical function to take care of all of this automatically, particularly if you are using this construction often. In this example below, the arguments are the note/chord immediately before the grace note and the grace note itself, see:
\version "2.18.2"
\include "deutsch.ly"
#(set-global-staff-size 20.0)
accordionGrace = #(define-music-function
(parser location firstNote secondNote)
(ly:music? ly:music?)
#{
\afterGrace
$firstNote
{
\once \override Stem.stencil = ##f
\once \override Flag.stencil = ##f
\parenthesize $secondNote
}
#}
)
\relative c {
\clef bass
e8 <gis d' e>^7 h,
\accordionGrace q e8
e8 <gis d' e> gis,_B
\accordionGrace q e'8
}
Related
For example, if we have a logic function F = (x1 or x2) and (not x2) then we can verify a solution [x1=true, x2=false] of equation F = true this way:
[> F:=(x1 or x2) and (not x2):
subs({x1=true,x2=false},F);
true
Maple Logic package has a nice function Satisfy, which can find a solution, but function F (now it's named as G) has to be written using symbol & (before and, or, not):
[> G:=(x1 &or x2) &and (¬ x2):
A:=Logic[Satisfy](G);
A := {x1 = true, x2 = false}
But I don't know an easy way how to verify a solution (I mean not in this specific case, but in general, functions may have hundreds of variables). My attempt was to use substitution and then use evalb, but it didn't work:
[> G1:=subs(A,G);
evalb(G1);
G1:= (true &or false) &and ¬(false)
(true &or false) &and ¬(false)
But for function F the substitution worked (even without evalb):
[> F1:=subs(A,F);
F1:=true
Also I couldn't find an easy way to remove ampersand symbol & from an expression (in order to construct function F from function G).
G := (x1 &or x2) &and (¬ x2):
cand := {x1=true, x2=false}:
Given the logical expression assigned to G in form of used by the Logic package (ie. operators with names prefixed by &), then the candidate solution assigned to cand can be tested as follows:
BG := Logic:-Export(G, form=boolean);
BG := (x1 or x2) and not x2
eval(BG, cand);
true
Combining those two steps,
eval(Logic:-Export(G, form=boolean), cand);
true
Another solution similar to #acer's, but the opposite direction. If you are not using anything else other than Satisfy from the Logic package and you are fine with having your logical formulas as in F in your example, then there is no need to have your formula saved in the Logic's style with ampersand operations. Instead of Export in #acer's answer, use Import. Here is how it works in your example.
F := (x1 or x2) and (not x2):
A := Logic:-Satisfy( Logic:-Import( F ) );
F1 := subs( A, F );
Note that Package:-Command is the same as Packae[Command] with tiny differences. You can also use eval( F, A ) instead of subs( A, F ). For their differences you can check Maple help pages. But here they give the same results as you want.
Click here for the answer. Turing Machine
The question is to construct a Turing Machine which accepts the regular expression,
L = {a^n b^n | n>= 1}.
I am not sure if my answer is correct or wrong. Thank you in advance for your reply.
You cannot "accept the regular expression", only the language it describes. And what you provide is not a regular expression, but a set description. In fact, the language is not regular and therefore cannot be described by standard regular expressions.
The machine from your answer accepts the language described by the regular expression a^+ b^+.
A TM could mark the first a (e.g. by converting it to A) then delete the first b. And for each n one loop. If you and up with a string only of A, then accept.
As stated before, language L = {a^nb^n; n >= 1} cannot be described by regular expressions, it doesn't belong into the category of regular grammars. This language in particular is an example of context-free grammar, and thus it can be described by context-free grammar and recognized by pushdown automaton (an automaton with LIFO memory, a stack).
Grammar for this language would look something like this:
G = (V, S, R, P)
Where:
V is finite set of non-terminal characters, V = { S }
S is finite set of terminal characters, S = { a, b }
R is relation that describes "rewrites" from non-terminal characters to non-terminals and terminals, in this case R = { S -> aSb, S -> ab }
P is starting non-terminal character, P = S
A pushdown automata recognizing this language would be more complex, as it is a 7-tuple M = (Q, S, G, D, q0, Z, F)
Q is set of states
S is input alphabet
G is stack alphabet
D is the transition relation
q0 is start state
Z is initial stack symbol
F is set of accepting states
For our case, it would be:
Q = { q0, q1, qF }
S = { a, b }
G = { z0, X }
D will take a form of relation (current state, input character, top of stack) -> (output state, top of stack) (meaning you can move to a different state and rewrite top of stack (erase it, rewrite it or let it be)
(q0, a, z0) -> (q0, Xz0) - reading the first a
(q0, a, X) -> (q0, XX) - reading consecutive a's
(q0, b, X) -> (q1, e) - reading first b
(q1, b, X) -> (q1, e) - reading consecutive b's
(q1, e, z0) -> (qF, e) - reading last b
where e is empty word (sometimes called epsilon)
q0 = q0
Z = z0
F = { qF }
The language L = {a^n b^n | n≥1} represents a kind of language where we use only 2 character, i.e., a, b. In the beginning language has some number of a’s followed by equal number of b’s . Any such string which falls in this category will be accepted by this language. The beginning and end of string is marked by $ sign.
Step-1:
Replace a by X and move right, Go to state Q1.
Step-2:
Replace a by a and move right, Remain on same state
Replace Y by Y and move right, Remain on same state
Replace b by Y and move right, go to state Q2.
Step-3:
Replace b by b and move left, Remain on same state
Replace a by a and move left, Remain on same state
Replace Y by Y and move left, Remain on same state
Replace X by X and move right, go to state Q0.
Step-5:
If symbol is Y replace it by Y and move right and Go to state Q4
Else go to step 1
Step-6:
Replace Y by Y and move right, Remain on same state
If symbol is $ replace it by $ and move left, STRING IS ACCEPTED, GO TO FINAL STATE Q4
I'm working on a simple LL(1) parser generator, and I've run into an issue with PREDICT/PREDICT conflicts given certain input grammars. For example, given an input grammar like:
E → E + E
| P
P → 1
I can remove out the left recursion from E, replacing it with a roughly equivalent right recursive rule, thus arriving at the grammar:
E → P E'
E' → + E E'
| ε
P → 1
Next, I can compute the relevant FIRST and FOLLOW sets for the grammar, and end up with the following:
FIRST(E) = { 1 }
FIRST(E') = { +, ε }
FIRST(P) = { 1 }
FOLLOW(E) = { +, EOF }
FOLLOW(E') = { +, EOF }
FOLLOW(P) = { +, EOF }
And finally, using PREDICT(A → α) = { FIRST(α) - ε } ∪ (FOLLOW(A) if ε ∈ FIRST(α) else ∅) to construct the PREDICT sets for the grammar, the resulting sets are as follows.
PREDICT(1. E → P E') = { 1 }
PREDICT(2. E' → + E E') = { +, EOF }
PREDICT(3. E' → ε) = { +, EOF }
PREDICT(4. P → 1) = { 1 }
So this is where I run into the conflict that PREDICT(2) = PREDICT(3), and thus, I cannot produce a parse table as the grammar is not LL(1), since parser wouldn't be able to choose which rule should be applied.
What I'm really wondering is whether it's possible to resolve the conflict or factor the grammar such that the conflict can be avoided, and produce a legal LL(1) grammar, without having to directly modify the original input grammar.
The problem here is that your original grammar is ambiguous.
E → E + E
E → P
means that P + P + P can be parsed either as (P + P) + P or P + (P + P). Eliminating left recursion doesn't fix the ambiguity, so the modified grammar is also ambiguous. And ambiguous grammars can't be LL(k) (or, for that matter, LR(k)).
So you need to make the grammar unambiguous:
E → E + P
E → P
(That's the common left-associative version.) Once you eliminate left recursion, you end up with:
E → P E'
E' → + P E'
| ε
Now + is not in FOLLOW(E').
(The example is drawn straight from the Dragon book, but simplified; it's example 4.8 in the rather battered old copy I have.)
It's worth noting that the transformation used here preserves the set of strings derived by the grammar, but not the derivation. The parse tree which results from the modified grammar is effectively right-associative, so it will need to be reprocessed to recover the desired parse. This fact is rather briefly mentioned by the Dragon book authors:
Although left-recursion elimination and left factoring are easy to do, they make the resulting grammar hard to read and difficult to use for translation purposes. (My emphasis)
They go on to suggest that operator precedence parsing can be used for expressions, and then mention that if an LR parser generator is available, dividing the grammar into a predictive part and an operator-precedence part is no longer necessary.
Currently I write lilypond code that looks like this:
\version "2.14.2"
P = #parenthesize
\relative c, {
\clef bass
<c \P c'> <e \P e'> <g \P g'>2 <c, \P c'>4 <d \P d'> <e \P e'>2
}
where I repeatedly mean 'this note, together with the same note one octave higher, parenthesized'.
I'd like a way to abbreviate this, so that I can write something like this:
\version "2.14.2"
poct = ...
\relative c, {
\clef bass
\poct c \poct e \poct g2 \poct c,4 \poct d \poct e2
}
As suggested in a helpful answer to an earlier question of mine, I have tried to use a music function, but there is no way I can get this to work. The closest I can get is
poct = #(define-music-function
(parser location note)
(ly:music?)
#{
<< $note \transpose c c \parenthesize $note >>
#})
but this uses << .. >> instead of < .. >, which does not render the way I want (and with warnings), and I have no idea why the \transpose c c actually transposes anything.
Finally, tangentially related, when experimenting with music functions I found it even impossible just to create a music function that mimicks \repeat unfold 2; the following jumps down an octave between the third and fourth c:
\version "2.14.2"
double = #(define-music-function
(parser location note)
(ly:music?)
#{
$note $note
#})
\relative c, {
\clef bass
\double c \double e \double g2 \double c,4 \double d \double e2
}
Ok, so here is a function I created for you, which will allow you to repeat single pitches. The only catch is that it won't use the \relative notation. This is because, in relative notation, the following sequence of notes c' c' c' will obviously be one octave higher than the preceding one. Unfortunately I still could not find a way to have a function such as \function #3 c' that would output c' c c. That said, here is my function and some examples:
\version "2.17.28"
times = #(define-music-function
(parser location N note)
(integer? ly:music?)
(cond
((>= N 2)
#{ \repeat unfold $N { \absolute $note } #}
)
((= N 1)
#{ \absolute $note #}
)
)
)
{
a4 \times #3 b4
R1
\times #4 { c'8 d' }
R1
\times #1 { c''1 }
}
So the syntax is simply \times #"number of repetition" { ...music... }. If only one note is to be repeated, you can omit both { and }: \times #"number of repetition" "single note".
You can use this function in the middle of a \relative passage, but then you should enter the pitches for the function as absolute pitches. Have a look:
\version "2.17.28"
times = #(define-music-function
(parser location N note)
(integer? ly:music?)
(cond
((>= N 2)
#{ \repeat unfold $N { \absolute $note } #}
)
((= N 1)
#{ \absolute $note #}
)
)
)
\relative c'' {
c4 d \times #4 e'' f g
}
Note that all notes above are in the same octave. The octave position the note f is also NOT influenced by this function, it is influenced by the note preceding the function, i.e., the d.
For sure there is a way to write a better code for this, but I wasn't able to do the trick with neither any \relative nor \transpose commands.
And here is some attempt to help you with your parenthesized octave (same function above but with some small alterations):
\version "2.17.28"
timesP = #(define-music-function
(parser location N note)
(integer? ly:music?)
(cond
((>= N 2)
#{
<<
\repeat unfold $N { \absolute $note }
\transpose c c' \repeat unfold $N { \absolute \parenthesize $note }
>>
#}
)
((= N 1)
#{
<<
\absolute $note
{ \transpose c c' \parenthesize $note }
>>
#}
)
)
)
{
a4 \timesP #3 b4
\timesP #8 c'16
\timesP #2 g4
\timesP #4 { c'8 d' } % no parenthesis here because there are two notes as arguments...
\timesP #1 { c''1 } % no parenthesis here because of the { }
}
\relative c'' {
c4 d \timesP #4 e'' f g
}
There are still some catches here: this function will only parenthesize when the argument is a single note written without { }. This is well commented on the code above.
I hope this will help you somehow. If I come across the solution for the octave transposition problem here, I will update this answer.
I just got this answer from David Kastrup, one of the developers of LilyPond:
The "octave transposition" happens because basically \transpose c c is the same as \absolute (as LilyPond does not apply \relative to transposed music).
\absolute is not necessary in connection with \repeat unfold: \repeat unfold knows how to deal with relative music.
Version 2.14.2 is awfully old. At any rate, there is currently issue http://code.google.com/p/lilypond/issues/detail?id=3673 in the LilyPond tracker, and the respective code can be found at https://codereview.appspot.com/30890043/diff/40001/scm/music-functions.scm
And there we get indeed into Scheme programming. The respective defmacro-public would likely work even in 2.14 though #{ #} might not work properly.
With that definition, your double definition would become:
double = #(define-music-function
(parser location note)
(ly:music?)
(make-relative (note) note
#{
$note $note
#}))
and would then work in both absolute and relative mode. If the 2.14 #{ #} does not jibe with make-relative, writing (make-sequential-music (list (ly:music-deep-copy note) (ly:music-deep-copy note))) should serve as a Scheme replacement.
The original problem becomes easier to understand once you realize that it's just a simple code replacement, so \relative { \double c' } becomes \relative { c' c' } using different octaves. The make-relative macro will to the \relative operation only on a single note, and then paste the results into the music expression.
Based on the code in your question and the answer from David Kastrup quoted in another reply, I built the following code to turn notes into chords with the same note one octave higher, not parenthesized:
#(define (octavate-pitch pitch octaves)
(ly:make-pitch
(+ (ly:pitch-octave pitch) octaves)
(ly:pitch-notename pitch)
(ly:pitch-alteration pitch)))
#(define (articulation-is-of-type? art type)
(string=? (ly:music-property art 'articulation-type) type))
#(define (copy-articulation? art)
(cond ((music-is-of-type? art 'tie-event)
#t)
((and (music-is-of-type? art 'articulation-event)
(articulation-is-of-type? art "fermata"))
#f)
; TODO add more cases
(else
#f)))
#(define (octNote note)
(if (null? (ly:music-property note 'pitch))
note
(make-relative (note) note
(let ((note2 (ly:music-deep-copy note))
(pitch (ly:music-property note 'pitch)))
(set! (ly:music-property note2 'pitch)
(octavate-pitch pitch 1))
(set! (ly:music-property note2 'articulations)
(filter copy-articulation? (ly:music-property note2 'articulations)))
(make-event-chord (list note note2))))))
oct = #(define-music-function
(parser location music)
(ly:music?)
(music-map octNote music))
It can be applied to an individual note or a full music expression:
\relative c' \oct {
c d e f |
g2 g |
}
It also works in the opposite order, \oct \relative c' { … }.
To parenthesize the added note, replace the last reference to note2 in octNote with (parenthesize note2) – I just prefer the non-parenthesized version for my own use. (You should probably rename the functions to octPNote and octP in that case, to avoid confusion. I briefly tried to write octPNote as a function that calls octNote and post-processes the result to parenthesize the second note, but wasn’t successful.)
You will also almost certainly need to expand the copy-articulation? predicate – ties and fermate are just the two kinds of articulation I encountered. (It defaults to not copying unknown articulations, so if the predicate is incomplete you’ll see it as missing articulations on the copied note.)
I'm trying to parse a string in a self-made language into a sort of tree, e.g.:
# a * b1 b2 -> c * d1 d2 -> e # f1 f2 * g
should result in:
# a
* b1 b2
-> c
* d1 d2
-> e
# f1 f2
* g
#, * and -> are symbols. a, b1, etc. are texts.
Since the moment I know only rpn method to evaluate expressions, and my current solution is as follows. If I allow only a single text token after each symbol I can easily convert expression first into RPN notation (b = b1 b2; d = d1 d2; f = f1 f2) and parse it from here:
a b c -> * d e -> * # f g * #
However, merging text tokens and whatever else comes seems to be problematic. My idea was to create marker tokens (M), so RPN looks like:
a M b2 b1 M c -> * M d2 d1 M e -> * # f2 f1 M g * #
which is also parseable and seems to solve the problem.
That said:
Does anyone have experience with something like that and can say it is or it is not a viable solution for the future?
Are there better methods for parsing expressions with undefined arity of operators?
Can you point me at some good resources?
Note. Yes, I know this example very much resembles Lisp prefix notation and maybe the way to go would be to add some brackets, but I don't have any experience here. However, the source text must not contain any artificial brackets and also I'm not sure what to do about potential infix mixins like # a * b -> [if value1 = value2] c -> d.
Thanks for any help.
EDIT: It seems that what I'm looking for are sources on postfix notation with a variable number of arguments.
I couldn't fully understand your question, but it seems what you want is a grammar definition and a parser generator. I suggest you take a look at ANTLR, it should be pretty straightforward with it to define a grammar for either your original syntax or the RPN.
Edit: (After exercising self-criticism, and making some effort to understand the question details.) Actually, the language grammar is unclear from your example. However, it seems to me, that the advantages of the prefix/postfix notations (i.e. that you need neither parentheses nor a precedence-aware parser) stem from the fact that you know the number of arguments every time you encounter an operator, therefore you know exactly how many elements to read (for prefix notation) or to pop from the stack (for postfix notation). OTOH, I beleive that having operators which can have variable number of arguments makes prefix/postfix notations not simply difficult to parse but outright ambiguous. Take the following expression for example:
# a * b c d
Which of the following three is the canonical form?
(a, *(b, c, d))
(a, *(b, c), d)
(a, *(b), c, d)
Without knowing more about the operators, it is impossible to tell. Of course you could define some sort of greedyness of the operators, e.g. * is greedier than #, so it gobbles up all the arguments. But this would beat the purpose of a prefix notation, because you simply wouldn't be able to write down the second variant from the above three; not without additinonal syntactic elements.
Now that I think of it, it is probably not by sheer chance that none of the programming languages I know support operators with a variable number of arguments, only functions/procedures.