The CBB

Finally finished part one of a story I was working on in Hóubenk Xúuuatxia. Whew! Part two could be up today or tomorrow (but no promises )

I posted the intro to Akatennaji, in Conworlds/Concultures.
Hopefully I can update it soon, because it's a very tiny thing.

I have just reached word #6,089 in the alphabetical list of words from the IGCE corpus, "bombproof". That means I am now exactly one-tenth of the way through my wordlist! I have 90,686 Kankonian words now.

Khemehekis wrote: ↑04 May 2024 04:36 I have just reached word #6,089 in the alphabetical list of words from the IGCE corpus, "bombproof". That means I am now exactly one-tenth of the way through my wordlist! I have 90,686 Kankonian words now.

Is it a coincidence that the number of Kankonian words is composed of the same array of digits as the place in the list of words?

Arayaz wrote: ↑04 May 2024 04:40

Khemehekis wrote: ↑04 May 2024 04:36 I have just reached word #6,089 in the alphabetical list of words from the IGCE corpus, "bombproof". That means I am now exactly one-tenth of the way through my wordlist! I have 90,686 Kankonian words now.

Is it a coincidence that the number of Kankonian words is composed of the same array of digits as the place in the list of words?

Wow, I thought in the back of my mind that they looked similar, but I didn't look closely! Yes, it IS a coincidence! It's a cool coincidence, though.

once again adding signs on a picture...

a path to elsewhere (NSFW)

When I was 1% of the way through the wordlist, I did a calculation with how many new words I had added to Kankonian and predicted I would get about 22,000 new words out of that, ending up with 109K-110K Kankonian words.

Now that I'm 10% of the way through, I calculated again. Going from 87,780 to 90,686 Kankonian words meant Kankonian's vocabulary had increased by 2,906 words, so I should get about 29,000 new words out of the IGCE wordlist. That means finishing with about 116K-117K words in Kankonian's lexicon.

Finished part two of Toxèix Haio iu!!

Set my Kankonian work aside for the day after kametwa, meaning kametua (a Povoian chocolate ball filled with crème and cocoa powder and covered with chocolate sprinkles). The kametua is Kankonia's answer to the brigadeiro.

Upon creating dukdzhiph, the Kankonian word for "bytecode" that was borrowed from the Achel dukdibb, I finished my trek through the B-words on the IGCE corpus list. I now have 91,369 words. The 91,592-word milestone, whereupon Kankonian will surpass Classical Yiklamu in lexicon size, is fast approaching.

I guess word #91,592 is going to be a C-word!

I've still more testing to do, but I've made a lot of progress on making my sound changer capable of handling unordered searches* in all sorts of configurations. I can't go into all the details due to there being so many, but the progress is very satisfying.

* unordered searches is what I call the notation used to say "find the following phonemes in any order and regardless of whether there are other things in between". An actual use case in applying sound changes would be when writing a rule such as "turn /s/ to /z/ if there was a voiced consonant at any point before it in the word", with the search for a voiced consonant being expressed as an unordered search, surrounded by the delimiter '|'. The full notation in my sound changer would be:

s → z / |C[+voice]|_

After spending all my time on pure comparison mechanisms, I've now taken the time to reintroduce actual sound changing to my sound changer. There were a few hiccups and there still is stuff to figure out, but progress has been much swifter. In its current state, it can take a word list such as:

bat
buut
beit
sibeat

And correctly apply the following rules:

Rule 1 :
t → l / bV+_

Rule 2 :
l → le / _

To produce the result:

bale
buule
beile
sibeale

The next "to-do" is a pretty big one though - modifying the internal mechanics of my changer so that it can correctly apply a more "common sense" notation of rule 2:

∅ → e / l_

I'll have to modify my comparison handler and its results to account for a third kind of "valid": a scenario where only a location is transmitted for something to be inserted, rather than a segment that is due to be replaced (e.g. the previous notation for rule 2 essentially operates by replacing /l/ with /le/, rather than just inserting an /e/ after /l/).

I added /l/ as a marginal phoneme in Abaniscen — it only contrasts with /ɾ/ in word-final position while preceded by /ɛ/. An example is the pair tenner (to cover, shield, protect) and niestel (to be named).

After a whole lot of rewriting, I've finally started on a smarter input-replacement mechanism for my sound changer. It's likely to get a bit more complicated very quick, but the basic form was at least decently easy, and I can now apply the following rule rather easily:

{a,e} → {e,i} / s_

Which, when applied to the word:

samilset

Converts it to:

semilsit

A human can do this with barely any effort, but a computer? It takes quite a bit of code. For a start, the "dumbest" possible approach of doing a simple "search and replace" would land you with "s{e,i}mils{e,i}t", and you don't want that. Heck, it requires the app to actually discern /a/ and /e/ in '{a,e}' when searching in the first place.

To solve this, I've implemented token "locations", which provide the exact position of a token within a hierarchy, represented as an array of indices up to the root token. E.g. the /e/ in /{a,e}/'s location is [0,2] because it is the third "child" token (yes, the ',' also counts as a child) of the case block (i.e. a structure of "{...}"), which is itself the first token of the input's root.
That same location is then searched for in the output, and if something is found, it is used as a replacement for the target token in the word.

However, this location-based approach becomes insufficient if the input and output do not have the same structure. Even unequal length would already cause trouble, e.g.:

{al,el} → {edj,idj} / s_

Pure location would end up replacing /al/ with /ed/ instead of the full /edj/. Worse yet, replacing /el/ purely by location would render /,i/ !

So, there's a lot of room for error here, and I'll have to smarten up my program to solve this. Probably the best and most economical way to do it would be to convert the found tokens and their location to cases and locations instead. We'll see.

I've made a lot of progress on the above, and the replacement mechanism is already very solid. But as expected, it's rather complicated, too complicated to go into at length. Long story short, differences in lengths seem to no longer be an issue, so my sound changer can take a rule such as:

a{j,d}e → ei

And apply it to something like:

sades

To spit out:

seis

It can also do the inverse, taking a rule such as:

s{ej,ad}s → s{ere,ara}z

And apply it to something like:

sads

To produce

saraz

-------------

What I'm now working on is for my SCA to correctly handle a null sign ("∅") in the output as an indicator that something has to be removed in all situations (even when retroactively padding replacements when the output at a particular index was longer than the input), but also account for targets that might now be missing due to such a deletion. It's complicated to explain, but thankfully not that complicated to implement - it just takes time.

And after that, I'll have to make sure that the replacement avoids jumping over case boundaries, and implement a check if it doesn't. For example:

eje,ada → i,ej

In the current state of the replacement mechanism, this could lead to:

sejes → si,es

Instead of:

sejes → sis

I could have avoided this if I had implemented this sort of case branching as part of the tokenisation hierarchy, but I was trying to be too minimalistic and hadn't thought of it at the time. Maybe I'll still implement it in a way that doesn't break everything I've done so far, so that I can at least save some time down the line.

I just now figured out that, on this thread,
SCA stands for Sound Change Applier,
not for Society for Creative Anachronism.

But for that, I would have no accomplishment to report!

eldin raigmore wrote: ↑29 May 2024 19:45 I just now figured out that, on this thread,
SCA stands for Sound Change Applier,
not for Society for Creative Anachronism.

But for that, I would have no accomplishment to report!

There's a thread for that . . .

eldin raigmore wrote: ↑29 May 2024 19:45 I just now figured out that, on this thread,
SCA stands for Sound Change Applier,
not for Society for Creative Anachronism.

But for that, I would have no accomplishment to report!

I also didn't know about "SCA" meaning "sound change applier" until I saw another conlanger use this initialism, some months ago. The only reason why I've been using it myself since then is because I assumed it was common parlance among conlangers on that basis.

I guess it illustrates nicely how extrapolating from a single event can lead to overconfidence, ha ha.

-----

Well, while I'm at it, I can report that the proper null insertion I was talking about in my previous post is implemented. Next up is the branching issue.