ASCA v0.1.6 - NEW

[Boşkoventi]

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.

Ahhh. You mean I can't just stick the file somewhere and run it, like before?

[Morrígan]

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.

Ahhh. You mean I can't just stick the file somewhere and run it, like before?

You should be able to as long as you preserve the internal directory structure that's in the folder. At this point, I should probably go back to packaging ASCA as an executable; also, I should make sure I test it better.

maybe in a couple of weeks, when I'm not overworked.

[Morrígan]

Now that I have some time off from school, I'm working on adding a few features to ASCA. The main one is the Kleene's Star operator, but in a slightly more interesting way. My intention at this point it to write ASCA so that C* is evaluated as zero or more instances of C, but C** is evaluated as zero or more instances of a specific element of C. Gemination would be similar, but would really need another operator (maybe C< would mean exactly two of a specific element of C ?)

Similarly, I also want to have the operator +, meaning one or more, with ++ working the same way.
OR, we could just use * for one or more, and use it with optionals to mean zero or more (C)*.

Thoughts on this issue?

[Cedh]

My intention at this point it to write ASCA so that C* is evaluated as zero or more instances of C, but C** is evaluated as zero or more instances of a specific element of C. Gemination would be similar, but would really need another operator (maybe C< would mean exactly two of a specific element of C ?)

Similarly, I also want to have the operator +, meaning one or more, with ++ working the same way.

Thoughts on this issue?

I like these plans very much, especially the proposed treatment of ** and ++.

OR, we could just use * for one or more, and use it with optionals to mean zero or more (C)*.

* for "zero or more" and + for "one or more" are standard regex notation, so I'd stick with that.

(C)* and (C)+ should not be accepted and give an error message IMO, because when (C) evaluates as an empty string, the */+ operator would logically apply to something that doesn't exist. (C+) could still give the same result as C* though.

[Bedelato]

Using Zeroes to insert characters has been temporarily removed, but there are other ways to write epenthesis rules

Why? Are there any plans to put this feature back in?

[Morrígan]

Using Zeroes to insert characters has been temporarily removed, but there are other ways to write epenthesis rules

Why? Are there any plans to put this feature back in?

I didn't so much remove the feature as rewrite the core algorithm completely so that it ran in polynomial rather than exponential time It shouldn't be too hard to implement in the new engine, but since I'm in the middle of adding Kleene-type operators, it will need to wait until I finish.

[Thomas Winwood]

Code: Select all

@SHORT = a e i o u
@LONG = ā ē ī ō ū

@SHORT @LONG > a ɛ e ɔ o a e i o u

This tells me that I've got a mismatch in the number of elements in the Initial and Final. Dividing the actual transformation line into two (one covering @SHORT, one covering @LONG) doesn't work. What am I doing wrong?

[Morrígan]

Code: Select all

@SHORT = a e i o u
@LONG = ā ē ī ō ū

@SHORT @LONG > a ɛ e ɔ o a e i o u

This tells me that I've got a mismatch in the number of elements in the Initial and Final. Dividing the actual transformation line into two (one covering @SHORT, one covering @LONG) doesn't work. What am I doing wrong?

Yeah, you are not allowed to do it that way. Like VSCA and Sounds, you have to write the variables out, or introduce a variable @LAX = a ɛ e ɔ o. I could change this, in principal, but I'm still working on the Kleene Operators.

[Morrígan]

OK, small update. I think I finished implementing the gemination operator "<" which matches exactly two of something. This puts me in a very good condition to implement the other Kleene Operators I've planned on, and after that I will go back and look at some of the issues users have had recently, and try to take care of some of those problems. Additionally, it should be relatively straightforward to implement exceptions that work like "UNLESS" statements in VSCA.

And I've been trying to comment my code more thoroughly; I realized this might be a problem when some methods I wrote were not well documented and I couldn't remember exactly how a particular recursive method worked. Also my site is messed up because some jagoff in IT decided it would be a good idea to have the Apache server ignore encoding metatags in HTML and just feeds everything out (incorrectly) as ISO-8859-1. I'm still trying to figure out who I have to threaten to get this fixed.

[Bedelato]

Okay, it's been a few days since my last big post that wasn't a TC, so I've got quite a few things to dump here.
__________

Additionally, it should be relatively straightforward to implement exceptions that work like "UNLESS" statements in VSCA.

I loved VSCA's UNLESS statements, but it's too darn slow. I look forward to being able to use them here.

In the meantime, here's a workaround I came up with. (some might already know this, but there's no harm in trying to help, right?):

Code: Select all

i u > I U
I U > i u / _{m n}{C #}
I U > e o

__________

Also, I wonder how many people's sound-change files will be broken when you add new operators
__________

I looked the web site, and... Holy schmattenpooters, what's up with all those <İĨĮɰ>?
Actually, manually changing my browser's character encoding seems to fix it

[Morrígan]

I loved VSCA's UNLESS statements, but it's too darn slow. I look forward to being able to use them here.

I like to avoid using them as much as possible, but real sound changes are sometimes blocked in certain environments, so it's important to have as an option. Implementation should be easy, since it should be a matter of A UNLESS B simply being handled as A && !B using the same condition-checking algorithm.

Also, I wonder how many people's sound-change files will be broken when you add new operators

Hopefully none, I'm trying to ensure backwards compatibility with the rule formats. The only things that would be broken is if you were writing rules with "<", "+", "*", or "%" which you probably shouldn't be anyway.

I looked the web site, and... Holy schmattenpooters, what's up with all those <İĨĮɰ>?
Actually, manually changing my browser's character encoding seems to fix it

Yeah, the page is encoded with UTF-8 and that is specified in the html, but the server is producing http headers with the wrong encryption. I find this very frustrating.

[Morrígan]

Ok, see the manual for details, but this version now supports gemination and the Kleene Star. Also, you can sue % for full- and inline comments.

The parser produces the same changes as my old rules, but my test set isn't especially diverse, so see if you guys an find places where the new operators don't behave as expected.

Get it here

[Morrígan]

Ok, looks like the Kleene Star is broken after all. I'll be working on that, and adding support for the Plus.

[Bedelato]

It remains possible to use the hash sign # for a full line omment and double-hash-sign ## for full-line comments

What the heck is an omment?

[tezcatlip0ca]

A comment without the sea. lol

[Morrígan]

Ok folks, I think I fixed the problem. I knew what the problem was pretty much right away, but it took some time to figure out how to work around it. Turns out I've had the right solution in mind for a week, but I kept forgetting that Java likes to make deep copies of objects, which ultimately caused my algorithm to not work the way I expected.

I'll be doing some testing and will try to re-release tonight potentially with support for UNLESS statements. Stay tuned.

[Morrígan]

After some testing and adding a bit more code, I finished support for the Kleene Operators and rule exceptions!
For exceptions, just use UNLESS or EXCEPT.

http://www.acsu.buffalo.edu/~sgmccabe/ASCA/index.html

Do your worst, folks.

[Bedelato]

A couple bug reports:

Rule exceptions don't work right unless there's a positive condition. Just using a plain underscore for the condition will completely ignore the exception part, applying the rule unconditionally. (If I missed something here, let me know, but yeah.)

Also, ASCA seems to ignore the first line of the rules file. (This goes back to 0.1.3, actually, but I didn't get around to sharing it until now.)

[Morrígan]

Rule exceptions don't work right unless there's a positive condition. Just using a plain underscore for the condition will completely ignore the exception part, applying the rule unconditionally.

Yeah, this is not a surprise. I realized that it might be a problem this morning; also, you can't use OR with UNLESS, so each rule can only be blocked by one environment, which is obviously not good enough.

Also, ASCA seems to ignore the first line of the rules file. (This goes back to 0.1.3, actually, but I didn't get around to sharing it until now.)

This is most likely an encoding problem, where the file has a byte-order marker in it. I thought I was scrubbing the file for BOMs, but possibly not.

[Nortaneous]

--changes doesn't work for me with DOS-format linefeeds, but I converted them to Unix and it worked

running Win7

[Morrígan]

--changes doesn't work for me with DOS-format linefeeds, but I converted them to Unix and it worked
running Win7

I'll take a look at that; I'm probably just writing these using LF and not CR-LF.

There is also an outstanding problem with Kleene Star operators: C*_ won't work, but _C* will - I know basically why this is happening, but haven't had time to sift through the code to find out exactly why it's matching the wrong strings.

[Nortaneous]

Running A B > B C on an input of AB gives CC, not BC. That's tripped me up a few times.

[Morrígan]

Running A B > B C on an input of AB gives CC, not BC. That's tripped me up a few times.

That's not really a bug; ASCA applies rules left to right over the word, so it will first change all As to Bs, left-to-right acress the word, and then change Bs to Cs. If you split this rule into two rules with B > C and then A > B it will work, but as far as the algorithm itself goes, the alternative ways of doing this cause more trouble even this one.

However, I plan rewriting the ASCA codebase over the summer, so we'll see. There will be other ways of preventing this sort of thing when segments are object based.

[linguofreak]

Feature request (maybe it's already there, but I haven't found it in the documentation):

Is it / could it be possible to have comments in a lexicon file? It would be very convenient in terms of allowing English glosses to be made in the lexicon without having them mangled every time the lexicon was processed.

[Morrígan]

Feature request (maybe it's already there, but I haven't found it in the documentation):

Is it / could it be possible to have comments in a lexicon file? It would be very convenient in terms of allowing English glosses to be made in the lexicon without having them mangled every time the lexicon was processed.

That might be possible now, if you use CSV mode and start the cell with # it should work; but I'll implement something more usable for future versions.