capabilityLangugaeFlow - computeResultSpec

2007-12-18 Thread Michael Baessler
Hi, I got the request on my table that the computation of the result spec for the capabilityLanguageFlow takes to much time. I looked at the code and found something interesting... maybe I'm wrong, I'm not sure. When looking at the ASB_impl.java at processUntilNextOutputCas() I found the foll

Re: capabilityLangugaeFlow - computeResultSpec

2007-12-18 Thread Adam Lally
On Dec 18, 2007 8:55 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: > Hi, > I got the request on my table that the computation of the result spec > for the capabilityLanguageFlow takes to much time. > I looked at the code and found something interesting... maybe I'm wrong, > I'm not sure. > > When

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-07 Thread Michael Baessler
Adam Lally wrote: On Dec 18, 2007 8:55 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: Hi, I got the request on my table that the computation of the result spec for the capabilityLanguageFlow takes to much time. I looked at the code and found something interesting... maybe I'm wrong, I'm not

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-08 Thread Adam Lally
On Jan 7, 2008 6:56 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: > I tried to figure out how the ResultSpecification handling in uima-core > works with all side effects to check how it can be done > to detect when a ResultSpec has changed. Unfortunately I was not able > to, there are to much ope

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-08 Thread Michael Baessler
Adam Lally wrote: On Jan 7, 2008 6:56 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: I tried to figure out how the ResultSpecification handling in uima-core works with all side effects to check how it can be done to detect when a ResultSpec has changed. Unfortunately I was not able to, there

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-09 Thread Michael Baessler
Michael Baessler wrote: Adam Lally wrote: On Jan 7, 2008 6:56 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: I tried to figure out how the ResultSpecification handling in uima-core works with all side effects to check how it can be done to detect when a ResultSpec has changed. Unfortunately

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-11 Thread Marshall Schor
Michael - I'm confused about how this test is setup. The test descriptor this code uses loads an aggregate, and then runs a process method which ends up calling some dummy process method called SequencerTestAnnotator. This process method dumps (to a file) the result spec. Is that the case

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-21 Thread Michael Baessler
Yes, I think so. This test dumps the result spec for each AE to a file to check if it was computed correctly. The computation of the result spec is done during the initialization of the aggregate AE when the capability language flow is created. The precomputed result spec can later be used in the

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-22 Thread Marshall Schor
The class CapabilityLanguageFlowObject has 2 defined constructors, but one is never used/referenced: CapabilityLanguageFlowObject(List aNodeList, ResultSpecification resultSpec) Can this be removed? -Marshall

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-22 Thread Marshall Schor
If this is removed or if it is never called, then there is a section of the logic in CapabilityLanguageFlowObject which is never used, because mNodeList == null: if (mNodeList != null) { // 80 or lines of code elided } Can this logic be removed? -Marshall Marshall Schor wrote: The class C

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-22 Thread Marshall Schor
In looking thru the code for ResultSpecification_Impl, it seems there seems to be an inconsistency - unless I (quite possible :-) ) missed something. The calls to the containsType(...) method operate in one of 2 ways, depending on whether or not the result specification has been "compiled" by

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-22 Thread Marshall Schor
I'm thinking of simplifying the CapabilityContainer class. Right now it has code to process input and well as output capabilities, but the input ones appear never to be used. Can anyone confirm that? If confirmed, I would propose to remove the part related to input capabilities. There is a

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
In older UIMA versions the CapabilityLanguageFlowObject(List aNodeList, ResultSpecification resultSpec) constructor was used when the result was set by an application using the process method with the resultSpec argument. In the current version it seems that only the version with the precomput

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
Thanks. I'll see about comparing the older method with the current method, to verify this. -Marshall Michael Baessler wrote: In older UIMA versions the CapabilityLanguageFlowObject(List aNodeList, ResultSpecification resultSpec) constructor was used when the result was set by an application

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
Marshall Schor wrote: In looking thru the code for ResultSpecification_Impl, it seems there seems to be an inconsistency - unless I (quite possible :-) ) missed something. The calls to the containsType(...) method operate in one of 2 ways, depending on whether or not the result specification

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
When looking at the tests for the capability language flow I see both tests one with the result spec argument in the process() method and one without. In older UIMA versions, when using the debugger I see that both constructors are used there. -- Michael Marshall Schor wrote: Thanks. I'll se

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
Marshall Schor wrote: I'm thinking of simplifying the CapabilityContainer class. Right now it has code to process input and well as output capabilities, but the input ones appear never to be used. Can anyone confirm that? If confirmed, I would propose to remove the part related to input cap

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
OK. This would confirm that the other constructor is no longer needed, since the test that passes a result-spec arg in the process method no longer calls that. Thanks. -Marshall Michael Baessler wrote: When looking at the tests for the capability language flow I see both tests one with the

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
But it would still be interesting why this is never needed and how it works now. -- Michael Marshall Schor wrote: OK. This would confirm that the other constructor is no longer needed, since the test that passes a result-spec arg in the process method no longer calls that. Thanks. -Marsha

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
Given that (as far as I can tell - let's see, that would be AFAICT), the resultSpec is *always* used in compiled mode (because the wrapper always compiles it), the current implementation would have the effect that 1) the allFeatures flag would work 2) subtypes of a type specified in the resul

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
Easy to see- just trace the test case... -Marshall Michael Baessler wrote: But it would still be interesting why this is never needed and how it works now. -- Michael Marshall Schor wrote: OK. This would confirm that the other constructor is no longer needed, since the test that passes a r

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
I did this trace. Here's how it works now, without calling this. The process(cas, result-spec) call goes to AggregateAnalysisEngine_Impl which calls setResultSpecification on the AEEngine_impl object, which 1) clones the result-spec object 2) adds capabilities to it from the *inputs* of all co

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
OK, will do. -- Michael Marshall Schor wrote: Easy to see- just trace the test case... -Marshall Michael Baessler wrote: But it would still be interesting why this is never needed and how it works now. -- Michael Marshall Schor wrote: OK. This would confirm that the other constructor is

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
Fine with me. Seems to be the way it works in the past, so we should not change it! -- Michael Marshall Schor wrote: Given that (as far as I can tell - let's see, that would be AFAICT), the resultSpec is *always* used in compiled mode (because the wrapper always compiles it), the current impl

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
Here's the trace of how this works, when run from a top level process(cas) call: 1) the call goes to the AnalysisEngine_Impl process method, which calls processAndOutputNewCASes in the same object. This calls the ASB_impl process method, which creates a new AggregateCasIterator(aCAS). This

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Michael Baessler
So in the older version of the capabilityLanguageFlow the inputs where not recognized. But I think it is not bad that these are added automatically since the flow can't work if those are missing! -- Michael Marshall Schor wrote: I did this trace. Here's how it works now, without calling this

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Adam Lally
On Jan 23, 2008 10:07 AM, Marshall Schor <[EMAIL PROTECTED]> wrote: > Given that (as far as I can tell - let's see, that would be AFAICT), the > resultSpec is *always* used in compiled mode (because the wrapper always > compiles it), the current implementation would have the effect that > > 1) th

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Adam Lally
On Jan 23, 2008 8:06 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: > In older UIMA versions the CapabilityLanguageFlowObject(List aNodeList, > ResultSpecification resultSpec) constructor was used when the result > was set by an application using the process method with the resultSpec > argument.

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
Eddie - this is for you to check I think: There is code in UimacppEngine in method serializeResultSpecification which adds result spec types and features to 2 IntVector arrays (one for Types, one for Features). As currently designed, these "miss" getting the subtypes of types, and all the fea

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-23 Thread Marshall Schor
Some corner cases. Case 1: If using the method to alter an existing result spec by adding a single type with an associated set of languages, the passed in "allAnnotatorFeatures" boolean will now be "unioned" with any existing setting of this. Javadocs updated to reflect this. Case 2: If y

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Marshall Schor
Without actually testing this (so this may be a wrong conclusion) - it seems to me that the code in CapabilityLanguageFlowController that sets up the result specs for components, by language, in the mFlowTable, ignores the typesOrFeatures that the result spec adds when compile() is called. If

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Michael Baessler
Marshall Schor wrote: Without actually testing this (so this may be a wrong conclusion) - it seems to me that the code in CapabilityLanguageFlowController that sets up the result specs for components, by language, in the mFlowTable, ignores the typesOrFeatures that the result spec adds when co

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Marshall Schor
What about allAnnotatorFeatures? Supposed the aggregate says it needs a particular Feature of a particular type. Suppose a delegate is marked as producing that type, and has allAnnotatorFeatures marked. This wouldn't work. You could say in this case that the output capability of the delegat

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Michael Baessler
From this point of view.. +1 to deprecate allAnnotatoreFeatures -- Michael Marshall Schor wrote: What about allAnnotatorFeatures? Supposed the aggregate says it needs a particular Feature of a particular type. Suppose a delegate is marked as producing that type, and has allAnnotatorFeatures

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Adam Lally
On Jan 24, 2008 7:54 AM, Marshall Schor <[EMAIL PROTECTED]> wrote: > If you recall, the compile method for results specifications augments > the set of types/features by doing 2 things: if the type has > allAnnotatorFeatures=true, it adds all the features of the type; and if > the type has subtype

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Michael Baessler
Adam Lally wrote: On Jan 24, 2008 7:54 AM, Marshall Schor <[EMAIL PROTECTED]> wrote: If you recall, the compile method for results specifications augments the set of types/features by doing 2 things: if the type has allAnnotatorFeatures=true, it adds all the features of the type; and if the

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Marshall Schor
The thing that adds allAnnotatorFeatures and subtypes is "compiling" the result spec. The builder of the mFlowTable doesn't compile the resultspec before using it - so it doesn't have these consequences. -Marshall Adam Lally wrote: On Jan 24, 2008 7:54 AM, Marshall Schor <[EMAIL PROTECTED]> w

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-24 Thread Adam Lally
On Jan 24, 2008 9:51 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: > > Without looking at the code, I didn't understand why this is a > > consequence of the behavior you described above. I thought you said > > "and if the type has subtypes, it adds those too"? Anyway, I > > definitely think tha

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-25 Thread Marshall Schor
The code which checks if a type or feature is in a result spec, for a particular language, always includes generalizing the language specifier by dropping the part beyond the first "-". For example, "en-us" and "en-uk" are simplified to en. Because of this, I'm thinking of shrinking the resul

RE: capabilityLangugaeFlow - computeResultSpec

2008-01-25 Thread LeHouillier, Frank D.
s analysis engines too. -Original Message- From: Marshall Schor [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 5:06 AM To: uima-dev@incubator.apache.org Subject: Re: capabilityLangugaeFlow - computeResultSpec The implementation for checking if a feature is in the result spec

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-25 Thread Marshall Schor
The implementation for checking if a feature is in the result spec does the following: If the result-spec is not "compiled", it says the feature is present if it specifically put in, or if its type has the allAnnotatorFeatures flag set. If the result-spec is "compiled", it says the feature i

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-25 Thread Marshall Schor
Message- From: Marshall Schor [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 5:06 AM To: uima-dev@incubator.apache.org Subject: Re: capabilityLangugaeFlow - computeResultSpec The implementation for checking if a feature is in the result spec does the following: If the result-spec is not

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-25 Thread Marshall Schor
Michael Baessler wrote: Michael Baessler wrote: Adam Lally wrote: On Jan 7, 2008 6:56 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: I tried to figure out how the ResultSpecification handling in uima-core works with all side effects to check how it can be done to detect when a ResultSpec h

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-25 Thread Michael Baessler
Adam Lally wrote: On Jan 24, 2008 9:51 AM, Michael Baessler <[EMAIL PROTECTED]> wrote: Without looking at the code, I didn't understand why this is a consequence of the behavior you described above. I thought you said "and if the type has subtypes, it adds those too"? Anyway, I definitely t

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-26 Thread Marshall Schor
Can I replace the class CapabilityContainer with the much more efficient (now) ResultSpecification class? It seems to me they do the almost same thing, and the ResultSpecification may be handling the corner cases better. Is there some subtle difference I'm missing? It would be nice to elimi

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-26 Thread Marshall Schor
The Capability Language Flow for an aggregate is computed in CapabilityLanguageFlowController.computeFlowTable. This starts with the aggregates output capabilities, and figures out a flow for each language, that produces all the outputs. Should this computation also include in the set of need

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-28 Thread Michael Baessler
Marshall Schor wrote: The Capability Language Flow for an aggregate is computed in CapabilityLanguageFlowController.computeFlowTable. This starts with the aggregates output capabilities, and figures out a flow for each language, that produces all the outputs. Should this computation also inc

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-28 Thread Michael Baessler
Marshall Schor wrote: Can I replace the class CapabilityContainer with the much more efficient (now) ResultSpecification class? It seems to me they do the almost same thing, and the ResultSpecification may be handling the corner cases better. Is there some subtle difference I'm missing? It

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-28 Thread Marshall Schor
I may have missed something - I don't see what would need to be added to the ResultSpecification class. The method hasOutputTypeOrFeature(...) is always called with doFuzzySearch== true, which is how the containsType or containsFeature methods operate (always) in the Result Specification class

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-28 Thread Marshall Schor
I went back and checked the Javadocs for the ResultSpecification, prior to my reworking of it. I think I treated the x-unspecified slightly wrong, and if I had done it right, then the anomaly noted in the previous note (below) would not be there. The previous Javadocs all say that the setters

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-28 Thread Michael Baessler
Yes, that is correct! - Michael Marshall Schor wrote: While experimenting with this approach, I found some tests wouldn't run. (By the way, the test cases are great - they have been a great help :-) ). Here's a case I'm want to be sure I understand: Let's suppose that the aggregate says it

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-28 Thread Michael Baessler
Ok, I didn't follow that... so fine with me to do the change! -- Michael Marshall Schor wrote: I may have missed something - I don't see what would need to be added to the ResultSpecification class. The method hasOutputTypeOrFeature(...) is always called with doFuzzySearch== true, which is h

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-28 Thread Marshall Schor
While experimenting with this approach, I found some tests wouldn't run. (By the way, the test cases are great - they have been a great help :-) ). Here's a case I'm want to be sure I understand: Let's suppose that the aggregate says it produces type Foo with language x-unspecified. Let's

Re: capabilityLangugaeFlow - computeResultSpec

2008-01-29 Thread Michael Baessler
Marshall Schor wrote: I think my change is ready for code review. I kept all the idiosyncratic behavior of the old code, so users should not notice any difference. All the tests run, and test case above runs at the 6000ms range. There are 3 areas changed: 1) ResultSpecification_impl is restr

RE: capabilityLangugaeFlow - computeResultSpec

2008-02-01 Thread LeHouillier, Frank D.
nks for your comments :-) -Marshall > > -Original Message- > From: Marshall Schor [mailto:[EMAIL PROTECTED] > Sent: Friday, January 25, 2008 5:06 AM > To: uima-dev@incubator.apache.org > Subject: Re: capabilityLangugaeFlow - computeResultSpec > > The implementatio

Re: capabilityLangugaeFlow - computeResultSpec

2008-02-01 Thread Marshall Schor
lto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 3:57 PM To: uima-dev@incubator.apache.org Subject: Re: capabilityLangugaeFlow - computeResultSpec LeHouillier, Frank D. wrote: We have an annotator that wraps a black box information extraction component that can return objects of a var

Re: capabilityLangugaeFlow - computeResultSpec

2008-03-22 Thread Eddie Epstein
Very possible that results specification doesn't work correctly through the JNI. Nobody has ever used them in C++ since I've been working with it. Eddie On Wed, Jan 23, 2008 at 4:02 PM, Marshall Schor <[EMAIL PROTECTED]> wrote: > Eddie - this is for you to check I think: > > There is code in Uim

Re: capabilityLangugaeFlow - computeResultSpec - Question on ResultSpecification

2008-01-21 Thread Marshall Schor
I'm doing a redesign for the result spec area to improve performance. The basic idea is to put a hasBeenChanged flag into the result spec object, and use it being "false" to enable users to avoid recomputing things. Why not use "equal" ? because a single result spec object is shared among mult

Re: capabilityLangugaeFlow - computeResultSpec - Question on ResultSpecification

2008-01-23 Thread Marshall Schor
I'll fix the Javadocs to correspond to what the code does. This will have the result that addResultFeature(1-feature, languages) will *add* to the existing languages, while addResultFeature(1-feature) will *replace* all existing languages with x-unspecified. -Marshall Marshall Schor wro