ASCA v0.1.6 - NEW

[Opera]

Very useful tool. Suited my needs better than any other SCA yet, good job!

However, one thing I really like from Zompist's is that you can make it so the output is of this form:

Code: Select all

changed_word [source_word]

If you could make such an option, it would be perfect.

Another thing I've run into had to do with stress. In the language I'm deriving, stress falls on the next-to-last syllable, so I had to use a condition like:

Code: Select all

[FrontV]	> [Diph2]		/	_(C)(C)V(C)#

But for some reason, the program just seemed to hang at "Writing Lexicon...".

If you have any tips on how to work with stress-related sound changes, that'd be cool as well.

[Morrígan]

Another thing I've run into had to do with stress. In the language I'm deriving, stress falls on the next-to-last syllable, so I had to use a condition like:

Code: Select all

[FrontV]	> [Diph2]		/	_(C)(C)V(C)#

But for some reason, the program just seemed to hang at "Writing Lexicon...".

I actually had this problem once, but I didn't feel like tracking the problem down (kinda regretting that now). I forget exactly the circumstances, but I had problems with 'a but not á. Chances are it involves the way I handled optionals. I must have missed something.

I think this happens when, for example, you change e to ei, and the Final contains the Initial as a substring. But it only happens if the condition has optionals in it. You could try changing e to ɛ and then to ei. I'll try to recreate the problem.

[Morrígan]

OK, fixed a dumb error that would cause infinite loops; pretty sure I fixed it already, but I must have forgotten about it when I rewrote the algorithm.

Check it out here or in my sig.

[edit] My fix makes deletion not work; I'll rerelease the new version once I get some sleep and fix this shit.

[Nortaneous]

How about a debug mode, where the user can pass in a line number and it'll show what changes (including the line numbers of those changes) apply to it and the result given after the application of that change? That would be useful, especially since I've spent the last half hour trying to figure out why the hell things are palatalizing in places where I don't think they should be palatalizing.

[Morrígan]

How about a debug mode, where the user can pass in a line number and it'll show what changes (including the line numbers of those changes) apply to it and the result given after the application of that change? That would be useful, especially since I've spent the last half hour trying to figure out why the hell things are palatalizing in places where I don't think they should be palatalizing.

Yeah, this is a pretty good idea. Shouldn't be much of a problem.

oh, BTW, in the meantime, you can insert the statement BREAK into your rules file, and the system will stop parsing them at that point. This is a less elegant way of doing a similar thing. Y'know, until I add this other feature.

[Nortaneous]

Optionals in the initial? Or is there a better way with the current system to do something like:

Code: Select all

śśś sss tśś tss > śś ss tś ts
śśʷś ssʷs tśʷś tsʷs > śśʷ ssʷ tśʷ tsʷ
śʷśś sʷss tʷśś tʷss > śśʷ ssʷ tśʷ tsʷ
śʷśʷś sʷsʷs tʷśʷś tʷsʷs > śśʷ ssʷ tśʷ tsʷ

or

Code: Select all

aã eẽ iĩ oõ uũ yỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ãa ẽe ĩi õo ũu ỹy > ã: ẽ: ĩ: õ: ũ: ỹ:
ãă ẽă ĩă õă ũă ỹă > ã: ẽ: ĩ: õ: ũ: ỹ:
ăã ăẽ ăĩ ăõ ăũ ăỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ãõ ẽõ ĩõ õõ ũõ ỹõ > ã: ẽ: ĩ: õ: ũ: ỹ:
õã õẽ õĩ õõ õũ õỹ > ã: ẽ: ĩ: õ: ũ: ỹ:

a:ã e:ẽ i:ĩ o:õ u:ũ y:ỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ã:a ẽ:e ĩ:i õ:o ũ:u ỹ:y > ã: ẽ: ĩ: õ: ũ: ỹ:
ã:ă ẽ:ă ĩ:ă õ:ă ũ:ă ỹ:ă > ã: ẽ: ĩ: õ: ũ: ỹ:
ă:ã ă:ẽ ă:ĩ ă:õ ă:ũ ă:ỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ã:õ ẽ:õ ĩ:õ õ:õ ũ:õ ỹ:õ > ã: ẽ: ĩ: õ: ũ: ỹ:
õ:ã õ:ẽ õ:ĩ õ:õ õ:ũ õ:ỹ > ã: ẽ: ĩ: õ: ũ: ỹ:

?

[Morrígan]

Optionals in the initial?

I'd like to add this in the future, which may not be too hard.

Code: Select all

śśś sss tśś tss > śś ss tś ts
śśʷś ssʷs tśʷś tsʷs > śśʷ ssʷ tśʷ tsʷ
śʷśś sʷss tʷśś tʷss > śśʷ ssʷ tśʷ tsʷ
śʷśʷś sʷsʷs tʷśʷś tʷsʷs > śśʷ ssʷ tśʷ tsʷ

You might be able to use

Code: Select all

ś s śʷ sʷ> 0 / {ś s śʷ sʷ}_

It isn't strictly equivalent, but should be functionally equivalent, depending on the clusters that show up in your lexicon.

As for

Code: Select all

aã eẽ iĩ oõ uũ yỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ãa ẽe ĩi õo ũu ỹy > ã: ẽ: ĩ: õ: ũ: ỹ:
ãă ẽă ĩă õă ũă ỹă > ã: ẽ: ĩ: õ: ũ: ỹ:
ăã ăẽ ăĩ ăõ ăũ ăỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ãõ ẽõ ĩõ õõ ũõ ỹõ > ã: ẽ: ĩ: õ: ũ: ỹ:
õã õẽ õĩ õõ õũ õỹ > ã: ẽ: ĩ: õ: ũ: ỹ:

a:ã e:ẽ i:ĩ o:õ u:ũ y:ỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ã:a ẽ:e ĩ:i õ:o ũ:u ỹ:y > ã: ẽ: ĩ: õ: ũ: ỹ:
ã:ă ẽ:ă ĩ:ă õ:ă ũ:ă ỹ:ă > ã: ẽ: ĩ: õ: ũ: ỹ:
ă:ã ă:ẽ ă:ĩ ă:õ ă:ũ ă:ỹ > ã: ẽ: ĩ: õ: ũ: ỹ:
ã:õ ẽ:õ ĩ:õ õ:õ ũ:õ ỹ:õ > ã: ẽ: ĩ: õ: ũ: ỹ:
õ:ã õ:ẽ õ:ĩ õ:õ õ:ũ õ:ỹ > ã: ẽ: ĩ: õ: ũ: ỹ:

Maybe not at the moment. Do all of these sequences even occurs as a result of previous rules?

I think you can define

Code: Select all

[VNasal] = ã ẽ ĩ õ ũ ỹ
[Vowel]  = a e i o u y

[Vowel][VNasal] > [VNasal]:
[VNasal][Vowel] > [VNasal]:

But the rules might give errors about how many variables you have.

I'll need to revise some of those sanity checks to allow this (since it is very useful) but I'll need to do a lot of testing to ensure that one is getting the expected results.

[Nortaneous]

You might be able to use

Code: Select all

ś s śʷ sʷ> 0 / {ś s śʷ sʷ}_

It isn't strictly equivalent, but should be functionally equivalent, depending on the clusters that show up in your lexicon.

Except that also kills geminates. But yeah, it wouldn't be that hard to modify that to make it work.

Do all of these sequences even occurs as a result of previous rules?

I think so. All of the ones ending in a nasal are possible.

I think you can define

Code: Select all

[VNasal] = ã ẽ ĩ õ ũ ỹ
[Vowel]  = a e i o u y

[Vowel][VNasal] > [VNasal]:
[VNasal][Vowel] > [VNasal]:

But the rules might give errors about how many variables you have.

Yeah, that errors. And that would shift, for example, aỹ to ỹ:.

Hmm. Some sort of index feature might be useful. So I could do something like:

Code: Select all

[Vowel]{a}[VNasal]{a} > [VNasal]{a}:

Or something like this to nasalize the vowels in the first place:

Code: Select all

[Vowel]{a}[Nasal] > [VNasal]{a}

Also, I've been trying to implement a compensatory lengthening rule (word-final /@/ <ă>~<o> drops and lengthens the preceding vowel), but it hasn't been working properly. I ran this as a test:

Code: Select all

V = a o
C = s k

o > :
VC: > V:C
VCC: > V:CC
VCCC: > V:CCC

on a lexicon of

Code: Select all

ao
ako
aso
asso
akso
asko
akko
akkko
akkso
aksko
askko
askso
assko
aksso
assso

and got

Code: Select all

a:
ak:
as:
ass:
aks:
ask:
akk:
akkk:
akks:
aksk:
askk:
asks:
assk:
akss:
asss:

-- it apparently ignored the last three rules completely.

Then I ran

Code: Select all

V = a o
C = s k

o > :
V > V: / _(C)(C)(C):

and got the same thing.

Thinking it might be a problem with the condition or the <:>, I ran:

Code: Select all

[VOWEL] = a o
[CONSONANT] = s k

[VOWEL] > [VOWEL]: / _kkko
o > 0 / _#

and

Code: Select all

[VOWEL] = a o
[CONSONANT] = s k

o > : / _#
[VOWEL] > [VOWEL][VOWEL] / _([CONSONANT])([CONSONANT])([CONSONANT])o

and got the same result. But for some reason,

Code: Select all

[VOWEL] = a o
[CONSONANT] = s k

a > a: / _([CONSONANT])([CONSONANT])([CONSONANT])o
o > 0 / _#

gives the intended result.

[Morrígan]

Hmm. Some sort of index feature might be useful. So I could do something like:

Code: Select all

[Vowel]{a}[VNasal]{a} > [VNasal]{a}:

Or something like this to nasalize the vowels in the first place:

Code: Select all

[Vowel]{a}[Nasal] > [VNasal]{a}

Yeah, I've been thinking about this. In regular expressions, they are called 'capture groups' I think, but they use parentheses as delimiter. I was thinking about doing something like this, but I'm not sure how to demarcate them. Definitely something I'll try to add though.

Also, I've been trying to implement a compensatory lengthening rule (word-final /@/ <259>~<o> drops and lengthens the preceding vowel), but it hasn't been working properly. I ran this as a test:

Code: Select all

V = a o
C = s k

o > :
VC: > V:C
VCC: > V:CC
VCCC: > V:CCC

This I'm going to have to look into. Sounds like either a serious bug, or a really dumb programming error.

[Morrígan]

[quote="I"]This I'm going to have to look into. Sounds like either a serious bug, or a really dumb programming error.

Ok, apparently multiple variables in a single Initial or Final are not allowed. And shouldn't be.

If you white a rule like

Code: Select all

VR > RV

then the changes will be screwed up.

Until I can add support for capture groups, or can find another way to handle this more intelligently, it's going to have to remain the way it is.

You can re-write these like:

Code: Select all

VCCC: > V:CCC
becomes
V > V× / _C(C)(C):
C: >  / V×C(C)_
V× > V:

assuming C: > / V:C(C)_ is not a change you want in other contexts.

I need to correct the manual, because I think I said this feature was supported, even though even v0.0.4 would have been doing it wrong.

It is also computationally inefficient.

In any case, I'm working on a new version with a few minor changes and minor enhancements, but nothing serious; adding new iteration features and capture group may or may not be difficult and I haven't really had time to sit down with pot of coffee and a lab notebook to think about it.

[Morrígan]

I've been very busy lately and haven't had a lot of time to work on ASCA, even though I've been thinking about the features I want to implement and how to do so. I'd like to give a brief overview of the new features that I plan on supporting:

--diff command: Sounds-style difference printout old > [new] as Opera requested.

Kleene's Star -style operations: there are really two I had in mind, mainly because of Variables:
C* will match any sequence of any elements of C. So, if C = p t k then C* would match tptkptkptkptkptktpktpkktpptptktpktpktpppktpkt et al.

C</b> \2\1. The backslash notation is POSIX regex syntax, and is probably what I will go with.

I'll have to write all of these features myself, since I can't really backload any of this functionality onto Java's regex engine.

So, if anyone has other feature ideas, I'll take them under consideration. Also, any complaints about proposed or current rule syntax.

[Morrígan]

Ok, I just finished fixing some features in v0.1.3 that I've been working on.

See the docs, but basically you can use --diff to show wordin > wordout and --changes LOG_FILE in addition to the normal output to print each word along with the rules which apply to it.

Also, I think I fixed the problem Nort was having with variable sequences in initials/finals; I never really intended people to be doing it that way and didn't test it well enough to find the error before.

Now it's fixed, AFAIKT.

[Opera]

I'm pleased you included the --diff feature. Makes it a bit easier not to have to switch between files to check what is the original word.

I had an issue lately:

I have these rules:

Code: Select all

# coarticulated consonants are all lost in Proto-Ori
gb             > w                /    {# V}_V
gb            > b                /    _#
kp            > ph            /    _V
kp            > kh            /    V_

# by analogy, th is created
t            > th            /    _{[BackV] [NasalV]}

So I wanted to redefine C, removing all of <gb> and <kp> and adding <ph> <kh> and <th>. It was necessary for this series:

Code: Select all

# accented vowels in plurisyllabic words move up or diphthong (for uppest ones)
i             > ë                /    _(C)(C)CV(:)(C)(C)#
e             > i                /    _(C)(C)CV(:)(C)(C)#
è             > e                /    _(C)(C)CV(:)(C)(C)#
a            > è                /    _(C)(C)CV(:)(C)(C)# 
u             > ö                /    _(C)(C)CV(:)(C)(C)#
o             > u             /    _(C)(C)CV(:)(C)(C)#
ò             > o                /    _(C)(C)CV(:)(C)(C)#
à             > ò                /    _(C)(C)CV(:)(C)(C)#
â             > a:            /    _(C)(C)CV(:)(C)(C)#
ê             > è:            /    _(C)(C)CV(:)(C)(C)#
ô             > ò:            /    _(C)(C)CV(:)(C)(C)#

So that words like <patu> would become <pèthu>.

However it seemed it didn't understand <th> as one consonant (C). It kept giving <pathu>.

For now I figured it out by putting the three aspirated stops directly in C at the top of the file.

Edit: the log file generated by the --changes parameter stopped mid-sentence at roughly 720 lines.

Edit2: could you make it so comments lines (##-starting) are also ignored in the lexicon files? It would be neat to divide or annote said lexicon.

[Morrígan]

So I wanted to redefine C, removing all of <gb> and <kp> and adding <ph> <kh> and <th>.

What is your rule for this?

However it seemed it didn't understand <th> as one consonant (C). It kept giving <pathu>.

Is <h> also a consonant?

Edit: the log file generated by the --changes parameter stopped mid-sentence at roughly 720 lines.

Weird.

[Opera]

What is your rule for this?

Code: Select all

gb             > w                /    {# V}_V
gb            > b                /    _#
kp            > ph            /    _V
kp            > kh            /    V_
kh            > x                /    _#
t            > th            /    _{[BackV] [NasalV]}

C = ny ng kp gb sh zh m n p t k q b d g s x r z ɣ w j l th kh ph

But I have it worked out now. Seems that by using the above code for redefining C but by putting <th kh ph> before <m> it works. Why should dipgraphs and all be put first?

[Morrígan]

What is your rule for this?

Code: Select all

gb             > w                /    {# V}_V
gb            > b                /    _#
kp            > ph            /    _V
kp            > kh            /    V_
kh            > x                /    _#
t            > th            /    _{[BackV] [NasalV]}

C = ny ng kp gb sh zh m n p t k q b d g s x r z ɣ w j l th kh ph

But I have it worked out now. Seems that by using the above code for redefining C but by putting <th> before <m> it works. Why should dipgraphs and all be put first?

Because they are longer and get read first when the system is checking to see if any element of the variable is a substring of your words.

Also, when defining variables which contain di- or -trigraphs, it is a good practice to place the longest strings first. Later versions will attempt to ensure that this is doen automatically.

For the next version, I can add code to sort variable definitions by length whenever they are defined.

[Circeus]

I think what Torco means is that two sound changes can start in different closely related dialects at the same time, eventually both applying to all words in the language, but not in the same order for all words. A natlang example can be found in the history of French, where the loss of unstressed medial vowels interfered with intervocalic voicing of obstruents. MANICA > manche did not undergo voicing of its medial *kʲ because the vowel was dropped before lenition could apply. In the phonologically parallel GRANICA > grange, however, *kʲ was still found between vowels at this time, and so it became *gʲ.

I think the best implementation then would be the ability of defining small rule sets (say two or three max) whose order of application can be randomized. This allows for the kind of "competing interests" as can arise in real languages.

[Opera]

Or being able to give a rule a "probability value" to be triggered for each word. That way you could have something like:

Code: Select all

V            > 0                /    C_C    (33)
k            > zh            /    V_V (60)

Would mean that 33% of the time, the first rule is triggered and does indeed affect the word, while the second is triggered 60% of the time.

However the issue would be that the results would change every time you fire the applier...

[Morrígan]

Or being able to give a rule a "probability value" to be triggered for each word. That way you could have something like:

Code: Select all

V            > 0                /    C_C    (33)
k            > zh            /    V_V (60)

Would mean that 33% of the time, the first rule is triggered and does indeed affect the word, while the second is triggered 60% of the time.

However the issue would be that the results would change every time you fire the applier...

But this really isn't how sound change happens; there is some randomness, but it tends a) to be very small and b) to get levelled over time and across the lexicon. I mean, ASCA isn't a model of Stochastic Optimality theory...

The Circeus / cedh audmanh idea is interesting, but will have to remain a very low priority for now.

[Opera]

Oh sure. I was only reacting Circeus' post, not really suggesting it should be added.

The ability to use (C*) meaning "any number of [items in variable C]" isn't available yet, right?

And what about commentaries in the lexicon? Think it can be added?

[Morrígan]

The ability to use (C*) meaning "any number of [items in variable C]" isn't available yet, right?

This is the next thing I want to add.

And what about commentaries in the lexicon? Think it can be added?

This might already be in there, if you want to try it. If not, it will be an easy addition.

[Boşkoventi]

Just got around to trying the latest version, and I got a strange new error (it wasn't doing this a few months ago):

Code: Select all

G:\Lingualia\conlang\Gzho\SC>java -jar ASCA.jar -f test\SCTest.utf -o testout.ut
f -r PG-OG_ab-1.asca
Getting Lexicon ...
Exception in thread "main" java.lang.NoClassDefFoundError: FileTools/FileReader
        at asca.Main.getLexicon(Main.java:192)
        at asca.Main.main(Main.java:82)
Caused by: java.lang.ClassNotFoundException: FileTools.FileReader
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
        ... 2 more

[Morrígan]

Just got around to trying the latest version, and I got a strange new error (it wasn't doing this a few months ago):

Code: Select all

G:\Lingualia\conlang\Gzho\SC>java -jar ASCA.jar -f test\SCTest.utf -o testout.ut
f -r PG-OG_ab-1.asca
Getting Lexicon ...
Exception in thread "main" java.lang.NoClassDefFoundError: FileTools/FileReader
        at asca.Main.getLexicon(Main.java:192)
        at asca.Main.main(Main.java:82)
Caused by: java.lang.ClassNotFoundException: FileTools.FileReader
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
        ... 2 more

Shit. Looks like a dependency problem with the /lib folder, maybe. I'll try to take a look at this soon.

[Bedelato]

I just tried out ASCA. Looks good and very powerful.

Do you think you might be able to put a GUI on it?

[Morrígan]

Do you think you might be able to put a GUI on it?

Maybe, but don't hold your breath. Improving functionality trumps interface.

Boşkoventi: are you sure you installed the new version correctly? Don't forget that this one has a subfolder with other libraries in it.