ssandban wrote
Are there and hardware or memory requirements for using planner in solaris
environment
I like to use a max memory of 512M, but most examples (which have real-sized
data, see reference manual for numbers) run fine with far less memory (the
default of 64M is fine IIRC).
Op 14-12-11 18:40, Patrik Dufresne schreef:
Hi,
I'm still in process to model my planning problem and I have some
difficulties in defining the correct weight of soft constraints. I
have soft constraints with different priorities : C1, C2, C3, ..., Cn
where C1 are higher then C2. Currently,
Hi,
I have a question regarding pattern binding and eval().
The following rule calculates 4 different sums from a list of
Positions and determines whether the ratio of the first 2 sums
is smaller than the ratio of the latter 2 sums.
The first version reads quite intuitively but it uses
eval()
With those four accumulates to compute the four sums I wouldn't worry
about the eval.
If there are many Position facts in WM and they are all A1 or A2 or B1
or B2 and you want an efficient solution: consider a single-pass
accumulate with custom code to compute the sums, returning a boolean.
-W
Hi Geoffrey,
Thanks for your opinion. I will try to implement what I call a
HardAndSoftPriorityScoreDefinition and give it back to the community. Where
is the best place to post a 'patch' ?
2011/12/19 Geoffrey De Smet ge0ffrey.s...@gmail.com
**
Op 14-12-11 18:40, Patrik Dufresne schreef:
Op 19-12-11 15:04, Patrik Dufresne schreef:
Hi Geoffrey,
Thanks for your opinion. I will try to implement what I call a
HardAndSoftPriorityScoreDefinition and give it back to the community.
Where is the best place to post a 'patch' ?
Create a pull request :) on
Op 19-12-11 15:22, Geoffrey De Smet schreef:
Op 19-12-11 15:04, Patrik Dufresne schreef:
Hi Geoffrey,
Thanks for your opinion. I will try to implement what I call a
HardAndSoftPriorityScoreDefinition and give it back to the community.
Where is the best place to post a 'patch' ?
Create a
You are not mistaken.
For POJO models we use reflection (class.getMethods) to determine whether a
Type's methods members are available in the LHS or RHS or both, according
to Java Bean conventions. Declarative models have their members available
in both the LHS and RHS by default as we generate
On 19/12/2011 16:04, Michael Anstis wrote:
You are not mistaken.
For POJO models we use reflection (class.getMethods) to determine
whether a Type's methods members are available in the LHS or RHS or
both, according to Java Bean conventions. Declarative models have
their members available in
I'm not clear on what you are saying.
We reflect the methods of existing beans:-
- If the member has a getter it is available in the LHS
- If the member has a setter it is available in the RHS
- If the member has a getter and a setter it is available in both the
LHS and RHS
Members
Folks:
My co-workers and I have been using Drools to great success, but we ran smack
into a performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large numbers
of associated facts in working memory (BINNING_INPUT has more than 8 million
facts in
Oops... This e-mail went out too quickly.
There are 8M BINNING_INPUT facts that will eventually be reasoned upon... But
only 10k at a time.
In other words, the matrix of BINNING_INPUT x LU_DEVICE_TYPE should be about
10k x 10k
Dave
From: David Martin
Sorry I misread what you said. I thought you said that beans are only
usable in the IDE if it has both a getter and a setter - my misundestanding.
M
On 19/12/2011 16:19, Michael Anstis wrote:
I'm not clear on what you are saying.
We reflect the methods of existing beans:-
* If the member
If you can write a more restrictive rules, you will be able to not
generate that 10kx10k matrix.
If you activate the log you will see 10kx10k activations that I'm sure
that it's causing the delay.
Can you write a more restrictive rule?
I'm not sure to understand this join - $call.device_type ==
How is the ration of different device_type values to BINNING_INPUT facts?
-W
On 19/12/2011, David Martin david.mar...@mercedsystems.com wrote:
Folks:
My co-workers and I have been using Drools to great success, but we ran
smack into a performance brick wall recently.
In the example below,
Hi Mauracio!
THANK YOU!
I tried the following and things just lit up!
rule Binning for Attribute: Device_type_desc
when
$call : BINNING_INPUT( device_type_desc != null )
$device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
then
Nested accessors are not currently indexed, because we cannot assure
their immutability:
$call.device_type
If people changed indexed nested accessors, without correctly notifying
the engine it would result in integrity problems.
If you have a large number of these, trying flattening the
sorry I misread that, you've put the binding first, not using a nested
accessor.
Currently you have
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
try rewriting it as:
$call : BINNING_INPUT()
$device_typeLookup :
It looks like you have a lot of objects that are not matching with
that guard (device_type_desc != null) that means that the number of
activations are less than 10k x 10k and can be processes quickly.
2011/12/19 Mark Proctor mproc...@codehaus.org:
Nested accessors are not currently indexed,
On 19/12/2011 16:58, Mark Proctor wrote:
sorry I misread that, you've put the binding first, not using a nested
accessor.
Currently you have
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
try rewriting it as:
$call :
No, Mark... You nailed it. My guards were reversed and my rules were no
longer matching anything.
The change you suggest below seems to do the trick though... Putting the nested
accessor first took a 90s process of 10k records down to 12s.
Phew! I will double and triple check my work now, but
On 19/12/2011 17:03, David Martin wrote:
No, Mark... You nailed it. My guards were reversed and my rules were
no longer matching anything.
The change you suggest below seems to do the trick though... Putting
the nested accessor first took a 90s process of 10k records down to 12s.
Phew! I
For References, one possible, simple solution
Initialized with Employee.NONE
Changed Hard constraints :
1. task must Match Employee Role and must not be Employee.NONE
-2 Constraint Occurrence
2. one Task Per Employee and must not be Employee.NONE
-2 Constraint Occurrence
3. Task contains
23 matches
Mail list logo
