how to choose a tiGmmmmmmmmm ^ 1625

To make a verb, we add a tense after a root. These are some of the rules that help us to choose a tense --

laT laG liG loT lRT luT

As soon as the tense is added it must be replaced with a tiG. How do we know which of the eighteen tiG is the right one?

First, we choose if we want the tiG to be a doer affix or a nondoer affix. When in doubt, choose doer.

how to choose a tiG that represents the doer

how to choose a tiG that does not represent the doer

how to choose a tiG that represents the doermmmmmmmmm ^ 1626

Find the person of the doer of the root. That means: if the doer includes me, we need a first person affix, if the doer includes you but not me, we need first person, otherwise we need third person.

Find the number of the doer. Can be singular, dual or plural.

Now we take the affixes in the tiG list that have the same person and number as our doer. There are two of them, one flat and one bent.

We use the flat unless any rule tells us that we have to use the bent.

how to choose a tiG that does not represent the doermmmmmmmmm ^ 1627

If the root is objectful, we must choose the bent tiG that has the same number and person as the object of the root, not the doer.

If the root is objectless, we always choose ta.

...

examples of using inria to disassemble verbsmmmmmmmmm ^ C+ 1633

In the following pages, I show some examples of how to use inria to disassemble a verb. This machine, most of the time, shows us the root, tense and tiG from which the verb was made, but does not show which grammar rules were used to make it. So I'll show those rules myself in the pages below. This way you can find some of the most commonly used rules.

analyzing admi

building admi

analyzing adanti

building adanti

analyzing carati

building carati

analyzing caranti

building caranti

analyzing nayati

building nayati

analyzing nayanti

building nayanti

analyzing dveSmi

building dveSmi

analyzing adveSam

building adveSam

analyzing dviSanti

building dviSanti

analyzing cakratus

building cakratus

analyzing cakAra

building cakAra

analyzing bhaveyus

building bhaveyus

analyzing acarat

building acarat

analyzing plavate

building plavate

analyzing dRzyate

building dRzyate

analyzing bibheti

building bibheti

analyzing bibhyati

building bibhyati

analyzing admimmmmmmmmm ^ C+ 1634

Typing admi into inria reader we get a red admi, and clicking the red we see --

ad_1 pr [2] ac sg 1

ad_1 means the root ad that means "eat". It has _1 because in the inria dictionary ad_1 is a root and ad_2 is a nounbase (a rootnoun).

pr means that the tense affix laT was added after the root

ac means that this laT was replaced with a flat affix

sg 1 means singular first person. Therefore the flat affix was mip.

The "[2]" thing means that rule [2] in page verb classes worked here, therefore none of the affixes in that page was added to the root.

Therefore inria is telling us that admi was built this way --

ad + laT → ad + mip → admi "I eat"

building admimmmmmmmmm ^ C- 1635

how to build admi using the rules

how to build admi using inria conjugation

how to build admi using hyderabad

how to build admi using the rulesmmmmmmmmm ^ C- 1636

One way of building a verb that means "I am eating" is using the pANini rules --

(1) choose a root that carries the meaning of "eating", like ad (there are many others, like bhuj, khAd, gras, carv).

(2) add to it the tense laT, which, according to rule vartamAne laT, may be used to express that the action of eating is happening now.

(3) apply rule lasya and replace the laT with the affix mip, which, according to several rules, may be used to express that the doer of the action of eating is singular and first person. In less words, that the doer is "I". We know that mip is first person because rule tiGas trINi trINi says so, and we know that it is singular because of rule tAnyeka.

So far we have --

ad + laT →lasya ad + mip

Now, mip is hard and expresses the doer of the action of the root, as it says who is eating. So we might think that kartarizap should work. However, it doesn't, because of the exception adi-prabhRtibhyaH zapaH, which says that after some roots, such as ad, rule kartarizap does not work and the root gets no affix.

As it happens, no other rules can apply at this point. So we are already done, and all that we have to do to get our verb is removing the label letter p (we know that p is a label because rule halantyam says so). So we have --

ad + laT →lasya ad + mip → admi "I eat"

(as rule lasya works every single time we build a verb, I will write this, for short --

ad + laT mip → admi "I eat"

this " ad + laT mip" means that we add laT after ad and then replace the laT with mip. It does NOT mean that we first add laT and then we add mip.)

Now, if you try to build a verb in this way you will fail horribly, because to do this, you need to know all the rules. Otherwise, you don't know even WHEN to stop. We apply changes as long as some rule says we must, and we are done only when no more rules apply.

So even though using pANini rules to build verbs is what "we are supposed to learn eventually", beginners will not be able to do this for a long time. Meanwhile students are supposed to use shortcuts, like asking the teacher "how do you say I'm listening?". Since the 20th century we can use inria tools and hyderabad tools to build verbs, and maybe at some point in the 21th century the AI chatbots will learn to do that.

how to build admi using inria conjugationmmmmmmmmm ^ 1637

...

Beginners are strongly encouraged to learn to use the inria conjugation gadget to build their verbs.

Go to inria reader, and, at the bottom of the page, you will find a link called "grammar". Click it and go to the "conjugation" gadget, that is the verb maker.

Now we want the forms of the root ad that means "eat". Look up that root in a dictionary and the dictionary will tell you it is a class 2 root (see verb classes ). In the conjugation gadget, type ad, choose KH, choose 2 and click "Send". This will take you to a page which shows all the tenses of this root.

The top tables of that page, where it says "present", shows the laT forms.

The top left table of that page, where it says "active", shows the flat forms, that is, those for,ms made by replacing the laT affix with affixes tip tas jhi etc. These forms are shown as--

admi advaH admaH

atsi atthaH attha

atti attaH adanti

and carry the affixes --

mip vas mas

sip thas tha

tip tas jhi

respectively. Notice that the first person affixes are in the first line, second person in the second, third person in the third. So, as we want to say "I eat", we need the first person singular, and we'll find it in the first line. The verbs in all lines are singular dual plural, so the singular is the one in the left, admi.

how to build admi using hyderabadmmmmmmmmm ^ C- 1638

The hyderabad tools are more accurate than the inria tools, but quite more inconvenient for the average European or American student. The problem is that as they have been made in an Indian university, they take for granted that you can read devanAgarI fluently. That is a very reasonably assumption to make if your students are all in India.

But MY students are mostly outside India and are the kind of lazy folks that won't learn devanAgarI until the last possible moment, so I tell them to compensate for their illiteracy by using a transliterator gadget, such as this one.

So how do we get admi out of the hyderabad tools?

Go to the hyderabad tools page and choose "verb forms generator" from the menu. In the gadget, choose your alphabet, your root, and parasmaipada (parasmaipada because you want the flat affixes, ac). Choose the output alphabet, and click "generate". You get to a table that shows all the tenses. The present is laT.

The verb tables in hyderabad are written in the Indian order: third person affixes go at the top, second person in the middle and first person are last. So here for "I eat" you need the form that is at the bottom left of the laT table.

analyzing adantimmmmmmmmm ^ C+ 1639

Writing adanti into inria reader , it tells us --

ad_1 pr ac pl 3

This means that the tense affix added was the present (a.k.a. laT) and it was replaced with the plural third person flat affix (a.k.a. jhi). So adanti means "they eat" or "they are eating". It was built like this --

ad + laT →lasya ad + jhi adanti "they eat"

and it is clear that some rule or rules changed jhi into anti.

Most of the verbs that end in anti were built with a jhi affix. And most of the verbs with jhi affix end up ending in anti'''. That being so, you might ask: why does the list of affixes start with tiptasjhi instead of starting tip tas anti?

The true answer to that question is quite long. But for now we can say that the list has jhi because some of the third person plural verbs end in ati, not anti, such as for instance bibhyati "they fear", or dadati "they give". We'll see examples of that WAY later, as seeing examples right now would confuse you.

building adantimmmmmmmmm ^ C- 1640

The rules that build adanti "they eat" are these --

ad + laT → ad + jhi →jhontaH ad + anti → adanti "they eat"

Rule jhontaH (literally, "jh to ant") replaces the jh of all affixes that have jh with ant. In this example, it changed the jh part of jhi into ant, and the i of jhi stayed unchanged, so we got anti. This same rule will change jha into anta, jhu into antu and so on. It works only on the jh that is inside an affix.

This rule will work on nearly all jhi, excepting only the ones that come after zlu and the ones that come after one the seven jakSi roots. In those cases, jhontaH does not work, because its exception adabhyastAt turns jhi into ati.

analyzing caratimmmmmmmmm ^ C+ 1641

Inria says --

carati = car pr. [1] ac sg 3

So the root is car. The pr means that we added laT after the root, and the "ac. sg. 3" means that we replaced laT with tip.

Here the [1] means that car is an class one root, and that rule kartarizap worked (thats rule number [1] in page verb classes ).

This kartarizap rule says that we must add the affix (z)a(p) right after the root whenever the root is in front of ac or a mo. Here tip is an ac, so we added zap.

Therefore --

car + laT tip →kartarizap car + zap + tip → carati "he moves"

So, no special rules worked.

building caratimmmmmmmmm ^ C+ 1642

To make a verb that means "he is moving" --

take a root that means some kind of movement, such as car

add the present affix laT

replace laT with tip which is the singular third person flat affix

car + laT → car + tip

Now tip is a hard affix that means the doer, therefore rule kartarizap must work --

car + laT → car + zap + tip

Now no further rules apply, so we just remove the labels and we are done --

car + laT tip carati "moves"

analyzing carantimmmmmmmmm ^ C- 1643

caranti means they move, and this word is made by adding the plural affix jhi. Inria says --

car pr. [1] ac pl 3

the "ac pl 3" (plural third person) means that we added jhi.

car + laT

car + jhi

the [1] means that kartarizap worked, so zap was added after the root, and inria is saying that --

car + zap + jhi → cara + jhi caranti

Apparently, jhi turned into nti by some special rules.

building carantimmmmmmmmm ^ C+ 1644

Now, the special rules. Rule jhontaH says that jhi must be replaced with anti''' most of the time (to be precise, jhi becomes anti after anything that is not a stammered, and cara is not a stammered). So we get --

car + zap + anti

Now another special rule works: atoguNe. It says that when we have two a touching inside a word, we erase the first one. So our verb is --

car + a + anti →atoguNe caranti "they move"

Summarizing --

car + laT jhi →kartarizap car + zap + jhi →jhontaH car + zap + anti''' →atoguNe caranti "they move "

analyzing nayatimmmmmmmmm ^ C- 1645

Writing nayati into inria reader , it gives us two options, one red and one blue. That's because this word can be a noun or a verb. We are interested only in the verb, so we click the red. Doing this shows --

nI_1 pr [1] ac sg 3

The [1] there means that the rule [1] of the table verb classes worked and added the affix zap after the root. The root nI means to carry or lead, so, so far, we can say that nayati means "leads", and was built like this --

nI + laT tip → nI + zap + tip nayati "he leads"

as in

senAnM nayati zalyo 'yam "this zalya leads the army"

or

grAmaGM kRSNo nayaty ajAM "K. leads the goat to the village"

It's clear that some rule or rules turned nI + zap into naya. We'll see those in a moment.

building nayatimmmmmmmmm ^ C- 1646

The rules that build nayati are these --

nI + laT tip →kartarizap nI + zap + tip →hardsoft ne + a + ti →ecoyavAyAvaH nayati "he leads"

Rule kartarizap teaches: "whenever a root is right in front of a hard affix that means the doer, add the affix (z)a(p) after the root".

In this example, kartarizap works because

(1) tip is hard, because rule tiGzit says so.

(2) tip means the doer, because it expresses that the doer is third person and singular (he or she does the leading, not you or me)

(3) None of the dozen plus exception rules that stop kartarizap from working applies in this example. We'll worry about those rules later. For now, just remember that the class one roots (nI, car, plu and all the roots that inria labels sometimes with a [1]) get zap, and roots of classes two to nine never do.

Here you have some more examples of the root nI getting zap --

nI + laT sip → nI + zap + sip nayasi "you lead"

nI + laG sip → nI + zap + sip anayas "you led"

nI + loT sip → nI + zap + sip naya "lead!"

nI + liG sip → nI + zap + sip nayes "you would lead"

Now, in all these examples, nI plus zap turned into naya. Why? Because of rules hardsoft and ecoya.

Let's go back to explaining nayati. We had reached this point --

nI + laT tip →kartarizap nI + zap + tip

Now, rule hardsoft teaches, among other things,

" I turns into e in front of all root affixes "

In our example, zap is a root affix because it is hard, and it is hard because it has z label (see tiGzit). It also happens that none of the many exceptions to hardsoft prevent it from working in this example. Therefore we must replace the I with e --

nI + laT tip →kartarizap nI + zap + tip →hardsoft ne + a + ti

At this point rule ecoyavAyAvaH must work. This is not a verb building rule, but a letter rule that affects all of the e o ai au that are inside a word and before a vowel. Using it is compulsory. After that, no more rules can apply, so we are done --

nI + laT tip →kartarizap nI + zap + tip →hardsoft ne + a + ti →ecoyavAyAvaH nayati "he leads"

analyzing nayantimmmmmmmmm ^ C- 1647

nayanti shows in inria almost like nayati, the only difference being that nayati has ac sg 3 (namely tip) and nayanti has ac pl 3 (namely jhi). As inria shows [1], zap was added to the root. So nayanti means "they lead", and has jhi affix --

nI + laT jhi →kartarizap nI + zap + jhi nayanti "they lead"

so it looks like some rules changed jhi into nti. We'll see those rules right below.

building nayantimmmmmmmmm ^ C- 1648

The rules that build nayanti "they lead" are these --

nI + laT jhi →kartarizap nI + zap + jhi →jhontaH nI + a + anti →hardsoft ne + a + anti →ecoya naya + anti →atoguNe nayanti "they lead"

The jhi ending is almost always affected by jhontaH and turned into anti.

Here atoguNe is not a verb construction rule, but a sandhi rule (a general rule about letter changes). Ordinarily, two a will combine into one long A by rule akassa. But when the two a belong to the same word, like here, they make a short a, by exception atoguNe.

analyzing dveSmimmmmmmmmm ^ C- 1649

Inria shows --

dveSmi = dviS pr [2] ac sg 1

which means

dviS + laT mip → dviS + mi dveSmi "I hate"

The [2] means that rule adipra worked, so no affix (such as zap) was added after dviS.

As we were expecting dviSmi, this means that some rule changed dviS into dveS.

building dveSmimmmmmmmmm ^ C- 1650

The rule that changed diS into dveS was puganta. This rule, among other things, teaches --

"replace the nexttolast i of a root with e before all root affixes"

Here no exception prevents puganta from working, so we say --

dviS + laT mip → dviS + mi →puganta dveSmi "I hate"

analyzing dviSantimmmmmmmmm ^ C+ 1651

Inria shows --

dviSanti = dviS pr [2] ac sg 3

which means

dviS + laT jhi → dviS + jhi dviSanti "they hate"

there was no change of dviS into dveS this time. We'll see why below.

building dviSantimmmmmmmmm ^ C+ 1652

dviSanti is built this way --

dviS + laT jhi → dviS + jhi →jhontaH dviS + anti → dviSanti "they hate"

This time, puganta did not work. Why? Because of the exception kGitica, which teaches, among other things --

" puganta will not work before affixes that have G label"

and it happens that jhi is such an affix.

In fact, jhi is just an abbreviation of jhiG. When jhi is turned into anti, by jhontaH, it keeps its G label, because rule sthAnivadAdezo says so. So the real affix is anti(G).

So, how do we know that jhi has G label?

Because rule hard apit is Git says so. This jhi is hard by tiGzit, and has no p label. Therefore it has G.

The smart student will have now figured out that when we have laT after dviS, the dviS will only become dveS before tip sip mip, because of the eighteen tiG affixes, only these three have p label. This conclusion is perfectly correct. However, some of my students end up imagining that there is a rule that says "change dviS to dveS before affixes that have p label". That is a hallucination, there is no such rule. What the rules say is a bit more complicated than that. The rules actually say --

(1) puganta does not work before affixes with G or k

(2) a hard that has no p always has G

Therefore, when a hard affix carries BOTH G and p, rule puganta will NOT work, and the hallucinated rule "apply puganta before affixes that have p label" will fail horribly. Be very careful with this set of rules, it is a minefield.

analyzing adveSammmmmmmmmm ^ C+ 1653

inria reader paints adveSam red and says --

adveSam = dviS_1 impft [2] ac sg 1

Here the root is dviS, impft means that laG was added, [2] means that rule adipra worked, and " ac sg 1" is the mip affix,

So, Inria tells us that --

dviS + laG mip adveSam

which means "I hated".

Here dviS plus mi made adveSam, so we have three questions. Why did an a appear in front? Why did mip change into am? And why did dviS become dveS?

building adveSammmmmmmmmm ^ C+ 1654

adveSam is built this way --

dviS + laG mip →luGlaG adviS + mip →tasthas adviS + am →puganta adveSam "I hated"

Incidentally, rule adipra worked and told us that rule kartarizap must not work after ad, dviS and other roots. This is why we did not add zap after the root like we did earlier in nayati and nayanti.

The a in adviS comes from rule luGlaG --

"whenever the tense is laG luG or lRG, and the root starts with a consonant, add a in front of that consonant"

(This rule applies to luG laG lRG only.)

Therefore, as dviS starts with a consonant --

dviS + mip →luGlaG adviS + mip

Now. When mip has replaced a Git tense, such as laG or liG or luG, rule tasthas always replaces the affix mip with the affix am'''.

adviS + mip →tasthas adviS + am

Because of rule sthAnivad, this am still carries label p. Therefore, rule hard apit is Git does not work on it, and am does not have G label, just like mip does not have G label. Therefore, puganta works before am just like it works before mip --

adviSam →puganta adveSam

analyzing cakratusmmmmmmmmm ^ C+ 1655

Type cakratuH into inria (cakratuH is the same as cakratus, but cakratus will not work in inria, by some reason).

According to inria, cakratuH is --

kR pft ac du 3

ac du 3 means the affix tas, so the verb was built this way --

kR + liT tas cakratus "the two of them make"

Here kR became cakR before a liT affix, tas, and the liT affix tas turned into atus, and the two pieces cakR and atus combined by ikoyaNaci, which turns R into r before the a of atus.

Notice that inria did not show a verb class, even though kR belongs to class [8]. That's because the rules mentioned in verb classes never add any affix to the root that is before a liT. Those rules only work before hard affixes, and the affix ( tip, tas, jhi...) that replaces liT is never hard, because rule liTca says so. So the liT verbs are always made the same way no matter the class of the root, and inria does not show the class number because doing that would not help you.

building cakratusmmmmmmmmm ^ C+ 1656

There are many rules involved into making cakratus. In a nutshell --

kR + liT tas →parasmaipadAnANNa kR + atus →liTidhA cakR + atus →ikoyaNaci cakratus "the two of them made"

The first rule parasmaipadAnANNa replaces tip tas jhi... with Nal atus us... respectively. Here it replaced tas with atus.

The second rule liTidhA says that we must reduplicate most roots when they are before liT. The process of reduplication is quite complicated and it is described in ekAcodve and the rules that follow. In this case it is done in three steps:

ekAcodve turns kR into kRkR

urat and another rule turn the first kR into ka

kuhozcuH replaces that ka with ca.

So far we got --

kR + liT cakR + atus

and now rule ikoyaNaci turns R into r, making cakratus.

analyzing cakArammmmmmmmm ^ C- 1657

According to inria, cakAra is --

kR pft ac sg 3

as " ac sg 3" means tip, here we had

kR + liT tip cakAra "he made"

This is the same thing as !"cakratus above, only that we added tip ( singular third person) instead of tas ( dual third person). Here kR turned into cakAr before tip, not into cakR, and tip turned into a. Again inria did not show a verb class.

building cakArammmmmmmmm ^ C- 1658

There are many rules involved into making cakAra. In a nutshell --

kR + liT tip →parasmaipadAnANNa kR + Nal →acoJNiti kAr + Nal →liTidhA cakAr + Nal → cakAra "he made"

Here rule parasmaipadAnANNa replaces tip with Nal.

As Nal has N label, rule acoJNiti works and replaces R with Ar.

Next, rule liTidhA reduplicates the root kAr into cakAr. Reduplicating kAr works a bit different than earlier --

first ekAcodve turns kAr into kAkAr

then hrasvaH turns the first kA into ka, making kakAr

finally kuhozcuH replaces that ka with ca, and we get cakAr.

Then we add (N)a(l) after cakAr --

cakAr + Nal → cakAra

The N label of Nal made us replace R with Ar, and the l label tells us that cakAra has the accent in the kA.

analyzing bhaveyusmmmmmmmmm ^ C- 1659

Typing bhaveyus into inria reader, we get --

bhU_1 opt [1] ac pl 3

An opt in inria means that the tense affix added was liG AND that rule liGAziSi was not applied, so the tiG that replaces the liG is hard. The [1] means that bhU is a zapclass root and rule kartarizap added zap here. So inria is telling us that the verb was formed this way --

bhU + liG → bhU + hard jhi → bhU + zap + jhi bhaveyus "they would be"

The student will remember that bhU before zap turns into bhav by hardsoft and ecoya, so we should have bhavajhi so far. Looks like some rules must be changing ajhi into eyus.

building bhaveyusmmmmmmmmm ^ C- 1660

When we must join a root and a liG replacer affix, like here --

bhU + liG → bhU + hard jhi

there are between fifteen or twenty rules that must work, I lost count. So I will mention here only a few of them.

First, rules kartarizap, hardsoft and ecoya turn bhU into bhava --

bhU + jhi →kartarizap bhU + a + jhi →hardsoft bho + a + jhi →ecoya bhava + jhi

Then rule jherjus works --

bhava + jhi →jherjus bhava + (j)us

Now, usually, when a flat affix replaces liG, rule yAsuTp should work and add yAs in front of that affix. However, when the affix is right after an a, like here after bhava, exception atoyeya says that the affix gets Iys instead of the usual yAs --

bhava + us →atoyeya bhava + Iysus

Now the first s disappears by liGassa,

bhava + Iysus →liGassa bhava + Iyus

and the a and the I merge into e by the general rule AdguNaH --

bhava + Iyus →AdguNaH bhaveyus

Putting everything together --

bhU + liG jhi →kartarizap bhU + zap + jhi → bhava + jhi →jherjus bhava + us →yAsuTpa bhava + yAsus →atoyeyaH bhava + Iysus →liGassa bhava + Iyus →AdguNaH bhaveyus "they would be"

analyzing acaratmmmmmmmmm ^ C+ 1661

inria reader paints acarat red and says

acarat = car impft [1] ac sg 3

Here ac sg 3 means tip, whic is flat and shows that the doer is third person singular. car is a root meaning move, and impft means laG. [1] means that zap was added by kartarizap. So the verb was assembled this way --

car + laG tip →kartarizap car + zap + tip acarat

and means "he moved" (any kind of movement, such as walking, galloping, swimming, jumping or slithering).

As we were expecting that car + a + ti would make carati, but we got acarat, it is clear that some rules added an a in front and removed the i at the end.

See also how to analyze with hyderabad tools

how to analyze with hyderabad toolsmmmmmmmmm ^ 1662

... half written

how to analyze acarat using the hyderabad tools

hyderabad tools do the same job inria does, but it is more inconvenient, particularly for the student that cannot read devanAgarI yet. The advantage is that it is more accurate -- it gets right some forms that inria gets wrong. So, I only use it when I suspect that inria is failing.

Go to hyderabat toolkit, and in the tools menu , select the morphological analyser. Set input ENcoding to KH, type acarat in the box, and hit Submit. It will say --

car kartari laG pra eka parasmaipadI bhvAdiH

Here

car is the root

bhvAdiH means it is a zapclass root (see verb classes )

laG is the tense

eka means ekavacana ( singular)

eka means singular

dvi means dual

bahu means plural

pra means third person

pra is third person

ma is second person

u is first person

kartari parasmaipadI means ac

kartari parasmaipadI means ac

kartari AtmanepadI means mo

karmaNi AtmanepadI means ps

so pra eka parasmaipadI means that tip replaced laG.

So this "car kartari laG pra eka parasmaipadI bhvAdiH" thing is saying the same thing inria says with "car impft [1] ac sg. 3", namely, that acarat was built this way --

car + laG tip →kartarizap car + zap + tip acarat

building acaratmmmmmmmmm ^ C- 1663

To form acarat using inria, go to inria grammar, and under conjugation write car, set dropdown to KH, set present class to 1, and hit Send. In the resulting table the second paragraph says "imperfect", that's the laG. At the left side of that you have the active, that is the ac endings. Look at the third line for the third person. The sngular is acarat.

To form acarat using the rules, do this --

car + laG tip → acar + tip → acar + zap + tip →itazca acar + a + t → acarat

Rule itazca tells us that when tip, jhi, sip have replaced a Git tense, they lose their i.

analyzing plavatemmmmmmmmm ^ C+ 1664

In all the examples we have seen so far, the verb had one of the first nine affixes in list tiptas, and inria said ac to tell us had one of those affixes. When the verb has any of the other nine affixes, inria says either mo or ps. It says ps if yak was added after the root, mo otherwise.

To see an example, type plavate into inria reader. You get --

plu pr [1] mo sg 3

Here the root is plu, the tense is pr ( laT), and sg 3 means third person singular, like earlier. But here we have mo, not ac. mo and ps mean that one of the bent tiG affixes was added. Of those nine, only the affix ta is third person singular. As we do not have ps here, we know that yak was not added after the root, and as we have [1], we know that zap was added. So inria is saying that --

plu + laT ta → plu + zap + ta plavate

So, somehow plu turned into plav, and ta became te. See why below.

building plavatemmmmmmmmm ^ C+ 1665

Because of rule anudAtta;Gi, after some roots, we cannot use flat affixes like tip to show who the doer is. Instead, we must use bent affixes like ta. One of these roots is plu "jump, swim, fly", that must take bent only because rule anudAttaGi says so. So to make a verb meaning "he jumps" we start with the jumping root plu, add laT to it, and replace the laT with ta. In detail --

plu + laT ta →kartarizap plu + zap + ta →hardsoft plo + a + ta →ecoya plava + ta →Tita plava + te''' → plavate "he jumps"

Here the ta affix means that the doer is singular and third person, same thing that tip means. Being an affix that means the doer, kartarizap must work, and we get hardsoft and ecoya just like we saw earlier in nayati.

The Tita rule changed ta into te. This rule works on bent affixes that replaced a Tit tense, here laT.

In some cases we can use the same affix ta to mean that the object of the action is singular third person.

analyzing dRzyatemmmmmmmmm ^ C+ 1666

Writing dRzyate into [*inria reader] we get a red --

dRz_1 pr ps sg 3

dRz_1 means that the root is dRz "see". The pr is the tense, namely laT. The sg 3 means that a singular third person affix was added. There are two such affixes, the flat is tip and the bent is ta. Now the ps means three things--

(A) the affix is bent (here it is ta)

(B) the affix does not mean the doer

(C) there is yak after the root

Now, as dRz is an objectful root, the affix ta must mean the object, and therefore the object of the root is third person and singular, so our dRzyate translates to "it is being seen, someone sees it" .

dRz + laT → dRz + ta → dRz + yak + ta → dRz + ya + t → dRzyate "it is being seen"

Notice that dRz is a zapclass root, but inria did not say [1]. That is because zap was not added. yak was added instead. And yak is added to all roots the same way, no matter their verb class.

To see why yak was added, see building dRzyate below.

building dRzyatemmmmmmmmm ^ C- 1667

When we want to make a verb that means that one thing is being seen now, we do this --

dRz + laT ta

Here we must use either ta or tip to mean that the object of the root (the thing that is seen) is third person and singular, and only ta and tip are third person and singular. Here, we must use ta because rule bhAvakarmaNoH says that when the affix does not mean the doer it must be bent. So ta is now an affix that means the object.

Being hard affix that does not mean the doer, this ta makes makes rule sArvadhAtukeyak work

dRz + ta →sArvadhAtukeyak dRz + yak + ta

and as ta is a bent affix that replace a T tense ( laT), rule Tita must work --

dRz + yak + ta → dRz + yak + te'''

Putting everything together --

dRz + laT ta → dRz + yak + ta →Tita dRz + yak + te → dRzyate "it is being seen"

This verb can also be translated as "it is seen", but i added the "being" word because in English "it is seen" may mean either present time or past time, while in Sanskrit you use laT for present time and kta or laG or liT or luG for past time --

dRz + kta →vrazca;bhrasja dRSta →STunA dRSTa- "it was seen"

dRz + laG ta →luGlaG adRz + ta → adRz + yak + ta → adRzyata "it was seen"

dRz + liT ta → dRz + ez →liTidhA dRdRz + e →urat dadRze "it was seen"

dRz + luG ta → dRz + cli + ta → dRz + ciN + ta →luGlaG adarz + i + ta →puganta adarz + i + ta →ciNoluk adarzi "it was seen"

example sentences --

candro dRzyate "the moon is being seen"

pratimAsaJM candro dRzyate pUrNimAyAm "the moon is seen every month in the fifteenth night"

candro dRSTaH "the moon was seen"

candro 'dRzyata "the moon was seen"

candro dadRze "the moon was seen"

candro 'darzi "the moon was seen"

building plUyatemmmmmmmmm ^ C+ 1668

According to rule laHkarmaNi, we can add ta after plu without meaning that the doer is third person singular. In that case, the ta is hard but does not mean the doer, so kartarizap will not work. But sArvadhAtukeyak will work, and add yak to the root. ( When there is yak, inria should show ps, this way --

plUyate = plu pr ps sg 3

instead of mo sg 3. )

The rules that build plUyate are --

plu + laT ta → plu + karmaNi ta →sArvadhAtukeyak plu + yak + ta →akRtsA plU + ya + ta →Tita plUya + te''' → plUyate "it is being jumped over"

analyzing bibhetimmmmmmmmm ^ 1669

Inria says --

bibheti bhI_1 pr [3] ac sg 3

The bhI_1 is the root in the form it appears in the inria dictionary (it is called bhI_1 because there is also a nounbase bhI_2 that means "fear").

As we know, ac sg 3 mans that this verb has tip, and pr means that laT was replaced with tip. The [3] means that this verb got the zlu affix by the rule [3] of page verb classes . Therefore the verb bibheti was formed this way --

bhI + laT tip → bhI + zlu + tip bibheti

So for some reason, when we added together bhI plus zlu we got bibhe. The rules that do that are explained below.

building bibhetimmmmmmmmm ^ 1670

We want to join --

bhI + zlu + tip

When we add the affix zlu after bhI we get bibhI. Why?

Rule zlau says that bhI must reduplicate when it is before zlu.

bhI + zlu + tip →zlau bhI bhI + zlu + tip

Rule pratyayasyaluk;zlu;lupaH says that we must erase the zlu --

bhI + zlu + tip →zlau bhI bhI + zlu + tip →pratyayasyaluk bhI bhI + ti

Rule hrasvaH says that the first I of a reduplicate must turn into a short --

bhI bhI + ti →hrasvaH bhibhI + tip

Rule abhyAsecarca says that we must replace the first bh with b --

bhi bhI + ti →abhyAsecarca bibhI + tip

Then rule hardsoft replaces I with guNa

bibhI + tip → bibheti "he fears"

analyzing bibhyatimmmmmmmmm ^ 1671

Inria says --

bibhyati bhI_1 pr [3] ac pl 3

so this is almost like bibheti, only that it is " pl 3" instead of " sg 3". Therefore it means "they are afraid", and got jhi instead of tip.

bhI + laT jhi → bhI + zlu + jhi bibhyati

So it looks like bhI became bibhy and jhi became ati. We'll see why below.

building bibhyatimmmmmmmmm ^ 1672

We want to join --

bhI + zlu + jhi

Adding together bhI + zlu we get bibhI, same rules we saw in building bibheti .

So far, all the examples we saw of laT jhi turned jhi into anti''' by rule jhontaH. But this rule has an exception -- adabhyastAt, which says that after a stammered, such as bibhI, jh turns into at, not ant. So we get to --

bhI + zlu + jhi → bibhI + ati'''

Here I is before a, so rule ikoyaNaci must apply --

bhI + zlu + jhi → bibhI + ati''' → bibhyati "they are afraid"