zompist bboard

Trying to make some things work in the SCA2.

Question: is there any way to have an optional segment in the conditions that stands for any number of instances of that segment? Basically, I want to be able to have an "if X occurs later in the word, anywhere in the word" rule. Is that possible?


EDIT: in my particular situation, I can fudge this by just including a stupid number of optional segments and assuming words won't ever be longer than that. But it would be nice if there were a proper way to do it.

The bad news-- no, there's no way to do this. I'll think about it... it's due for some debugging anyway.

While we're on that, here's a bug that needs to be fixed:

Define a category H=123, and then the rule uH/ū/_. It doesn't work: the word u1mi stays u1mi.

Now rewrite it: u[123]/ū/_

U1mi now becomes ūmi as desired.

You also can't change members of categories into respective members of other categories of other categories if there's some other term in the etymon or product slots. So if

A=aiu
L=āīū

you can write A/L/_, and (say) rami will become rāmī. But if you wrote (in my case):

H=123
Ĥ=ēāō

you can't write
eH/Ĥ/_

and expect to get (say) stāmi from ste2mi. This would be extremely useful (I'm trying to get the PIE laryngeal rules to work right now. It's doable, certainly, but it takes more rules than I'd like.)

Finally, you can't mix categories and phones in an ad hoc category. If H=123, and W=iu, then the rule

H//_[Woaāēīōū]

doesn't do anything.

FearfulJesuit wrote:While we're on that, here's a bug that needs to be fixed:

Define a category H=123, and then the rule uH/ū/_. It doesn't work: the word u1mi stays u1mi.

Now rewrite it: u[123]/ū/_

U1mi now becomes ūmi as desired.

You also can't change members of categories into respective members of other categories of other categories if there's some other term in the etymon or product slots. So if

A=aiu
L=āīū

you can write A/L/_, and (say) rami will become rāmī. But if you wrote (in my case):

H=123
Ĥ=ēāō

you can't write
eH/Ĥ/_

and expect to get (say) stāmi from ste2mi. This would be extremely useful (I'm trying to get the PIE laryngeal rules to work right now. It's doable, certainly, but it takes more rules than I'd like.)

Finally, you can't mix categories and phones in an ad hoc category. If H=123, and W=iu, then the rule

H//_[Woaāēīōū]

doesn't do anything.

I found you couldn't have categories inside ad hoc categories at all. And a couple of times now I've had to spell out a category in ad hoc terms to get it to work, though I didn't note the precise situation.

I think I have the wildcard working. Try it out.

It's … (one character; you can cut and paste from here or the IPA display). So a rule like

S/Z/_…s

would change S to Z so long as there's an s somewhere later in the word.

It should allow categories, nonce categories, etc., though I didn't try hard to break it.

(Edit: it should work before or after the _, but it may still have quirks. I wish I had a better Javascript debugger...)

Any way to identify the weak and strong yers in Slavonic roots?

dini > din
dini: > dni:
dinesu > dnes

etc.

I'm not following... you can use Unicode, why not just use the characters directly?

I mean that, if the old Slavonic is input, is there a way to identify the weak and strong yers using SCA2's existing rules?

(strong yers precede a yer in the next syllable, all other yers are weak)

Something like
Y/S/_(C)(C)(C)Y where Y = any yer and S = corresponding strong yer
didn't work last time I tried it...

The yers behave pretty damn strange, so even if he uses the symbols for the yers, instead of his current convention to denote them with short vowels, he probs can't think of a way to make Havlík's Law to work which is what I think he was gettin at

(damn ninjas)

I think that the SCA2 trick for adding in some geminated consonants like Japanese, as in the help page, is still problematic. I keep getting q's back instead of the proper <pp tt kk> like I should be. It's not much of a problem though, as I believe my conlang should only have geminated consonants through some derivations, and not as regular phonemes.

If you are still working on the SCA2, and retain the bug report I PM'd you last December, perhaps this would be a good time re-draw your attention to it; I can re-send if needed. Assuming you haven't already done something - even if only an explanatory note in the helpfile. (If you did, you didn't say, though in the particular case that had been at hand not using rewrite rules sufficed as a workaround.)

Thanks for the addition.

another question: is there a way to turn one input into multiple outputs to... oh, bugger it, I'll give an example.

In VSë sequences (ë is a schwa, S is a sonorant), ë should turn into whatever V was.
Do I have to specify this rule for every possible value of V, or is there a shortcut?

OK, now there is. With the default lexicon, try this:

V/V²/_Su
VS/\\/_u
u//SV_

That is, we generate an extra V, move it across the S boundary, and then delete the u (standing in for your ë). So we get focus focos, and secundus secendus.

The tricky bit was the second rule— matching wasn't working if there was a second category in the target. Now it does. This also allows other interesting variations, such as

SS/S²/_

which will match S + S and then duplicate only the first S, e.g. doctor doccor. Or

SC/\\/_

which will metathetize any S + C combination, e.g. doctor dotcor.

Hello, there is a bug causing the script to fall into an infinite loop and crash, if the third argument is null (q/'//_V).

Can the third argument be null?

Shouldn't (q/'//_V) be (q/'/_/_V)?

Pole wrote:Hello, there is a bug causing the script to fall into an infinite loop and crash, if the third argument is null (q/'//_V).

I came across another one of these, but I can't remember what i was doing. It was a mistake of mine, though, and when I fixed it it worked.
I've come across quite a few things that seem to be bugs, mostly around optional items (which it sometimes seems to treat as non-optional) and ad hoc categories. Also for quite a long time it was insisting on treating one symbol (which I hadn't included in any of the categories) as a consonant (i.e. as part of the category 'C'), and then when I added it to a non-consonant category it stopped considering it a consonant. But I've not been keeping track, since at least 3/4 of the apparent bugs are me failing to spot a loophole or something, and I can't be bothered working out whose fault it is every time (I just find a workaround and move on).

[I'm now kind of pissed off, because I spent hours finally working out some really difficult and time-consuming stuff in the SCA, then turned my back for ten minutes and windows decided to install upgrades. I'd even copied all the SCA stuff into a word file so I didn't lose it if the browser crashed, but I hadn't gotten around to saving it, and, of course, when windows decides to upgrade, it doesn't bother autosaving open windows. So... bugger.]

ivazaéun wrote:Can the third argument be null?

Shouldn't (q/'//_V) be (q/'/_/_V)?

It can't be, although typing an illegal rule shouldn't make the browser freeze. (Also, it appeared as a type, what I intended to write was q/'/_V.)
Alternatively, it could be automatically parsed as another way to write the same (A/B/ →A/B/_), couldn't it?

What is the quickes way of applying stress marks before commencing with proper sound changes? I've been working with a language that has regular stress so I don't have it marked, but I want to apply some stress-related sound changes. Is there a separate app that does this perhaps? Or is there a way of doing this neatly in SCA? I would love to be able to apply both primary and secondary stress (both 100% regular).

vecfaranti wrote:What is the quickes way of applying stress marks before commencing with proper sound changes? I've been working with a language that has regular stress so I don't have it marked, but I want to apply some stress-related sound changes. Is there a separate app that does this perhaps? Or is there a way of doing this neatly in SCA? I would love to be able to apply both primary and secondary stress (both 100% regular).

? If it's regular, you shouldn't need stress marks. And if you do want them, surely you can just add them via the SCA, if they're regular?

If I want to tell the SCA2
stressed a becomes e
or whatever,
then I have to first tell SCA2 which a-s are stressed, right?

How do I tell SCA2 to add a stress marker on the penultimate syllable?

V(C)(C)(C)(V)(C)#/Á(C)(C)(C)(V)(C)#/_

?

Why not? If you want to mark stress by having a different category of vowels.
In the project I'm working on at the moment, I'm marking stress as a symbol instead, so I'd have the rule:
"//_C(C)V(C)(C)(C)V(C)#
Assuming that your syllable structure is C(C)V(C), of course.
You might also be able to do it with the new ellipsis symbol?
/"/_C(C)V
"//_..."..."
"//_(C)#
But I don't know whether you can use the ellipsis twice in the conditions.
Or you could just manually add stress to your word list before you start.

[I prefer using a stress symbol, because at the moment I have multiple classes of vowels, and some stressable non-vowels, and I think it's easier not to complicate things by adding parallel stressed and unstressed versions of them. On the other hand, using the stress symbol means remembering to add in (") all the time. Though that, I think, does simplify things sometimes, because it makes it really easy to do rules of the 'unless onset to a stressed syllable' kind. But I think which you find easier may depend on how your brain works, and on the details of your language and how you've decided to approach the diachronics]

All that said, there are a whole bunch of things, including this, that would probably work better with syllables built into the SCA, rather than having to be second-guessed through phonotactic specifications.

Oh, and of course doing things on a syllable basis with explicit syllable markers (here '.') would be another way to do it under the existing system. Something like (sorry if I've not thought this through):
C/D/_#
V/W/_D
C/D/_W
C/D/_D
C/D/_D
C/D/_D
C/D/_D
./:/_D
./:/_W
C/E/_:
V/X/_E
V/X/_:
(D/C/_
E/C/_
W/V/_
:/./_)
This would give you X as your stressed vowel class.
This is obviously a lot more complicated than the above approaches. It has the advantage of taking it step-by-step, which for some people may reduce errors and oversights, and more importantly it could conceivably be useful if you find terms like "in final syllable" and "in penultimate syllable" continually cropping up in your sound-changes (basically, because this way lets you split your phonemes out by what syllable they're in from the start, and then you can change them accordingly however often you want).

[Or, perhaps most elegantly of all, by combining the ellipsis route with the syllable marker (here '!') route, you could go:
!/:/_...!
V/Á/_(C)!
:/!/_]

Wait, no, the most elegant way would probably have to be:
V/Á/_...V
Á/V/_...Á

Anyway, that's five, possibly six different ways of doing it.

Thanks for all of that. I'll try some different things out and see what works.

It would be really wonderful if SCA2 had definable variables like this:

!=syllabic nucleus
"=primary stress syllable
'=secondary stress syllable
.=unstressed syllable

And you would define them by saying
VF=! (meaning V and F are syllable-bearing)
!2#/"/_ (meaning second syllable from the end is a primary stress syllable
or
#!2/"/_ (meaning second syllable from the beginning is a primary stress syllable
And then you could say
!246"/'/_ (meaning second, fourth and sixth syllable in front of a primary stressed syllable is a secondary stress syllable, giving a trochaic stress pattern)

And none of this would be visible in the word list, SCA2 would just know this. And then you could tell it:

s/z/!_!/._

meaning s is voiced between syllables unless the preceding syllable bears no stress. (Verner's law).

And so forth.

Make any sense?

(Disclaimer: I'm not a programmer and very barely programming-literate so some of this may not be easily executable the way I describe here).

(I think) I got that. You were describing something already possible. I was suggesting taking what you wrote one step further and making it a feature of the program.

Sorry Vec, didn't mean to shout you down - I'd actually tried to edit my post to remove a mistake, and I ended up quoting myself instead.

It's not trivial to model the concept of "syllable" in such a way that it's useful for arbitrary languages. (Modeling it based on the sonority hierarchy is fairly easy, and it works for a majority of situations, but some syllables in some languages break that hierarchy, or treat it in an unusual manner [e.g. by syllabifying medial same-sonority clusters as an onset instead of onset+coda, or by assigning single intervocalic consonants to the coda of a preceding stressed syllable]. And sometimes you even get conflicting syllabifications within the same language [Wikipedia gives shell·fish vs. self·ish as an example in English].) Also, a sound change applier with a built-in syllabification algorithm would ideally re-apply syllabification after each change (or at least at several stages of the sound change list) because the sound changes may change where the syllable boundary is, and the allowed syllable structure may also change as the sound changes are applied. So while it would be useful to have, this function won't be easy to implement (and as a perfect and maximally versatile automatic algorithm without the need to specify additional options and/or exceptions, it would likely even be impossible).

(I've done some work in that direction in my Frequentizer, which is also written in Javascript, so it might be possible to adapt parts of that code to use it in SCA2, or to split it off as an independent syllabification library. I don't think it's stable enough at this point though, and I'd have to look at it in detail to see whether it's at least remotely compatible with SCA's approach in its design, because it's used for a completely different purpose.)

EDIT:
Is there anyone on this board with professional expertise in Computational Linguistics? If yes, do you know of any good software for automatic phonological* syllabification?

*) as opposed to orthographic