I'm new to OCL and currently trying to figure out how to do invariants.
I attached a picture with the diagramm I'm working on.
https://imgur.com/1ucZq5w
The invariants that I'm trying to resolve are :
a) A player has 0 or 2 cards in hand.
Context Player
inv i1: self.card->size()=0 or self.card->size()=2
b) A player, who has not played any rounds, can't have more Game Capital than the maximal Buy-In of the table.
Context Player
inv i2: self.numberOfRounds=0 implies (self.gameCapital < self.Table.maxBuyIn)
c) At every table can be only players that belong to different users
Context Player
inv i3: Player.UserAccount.allInstances().userID->isUnique()
I'm not sure if 'allInstances()' is supposed to go after Player or after PlayerAccount.
And I don't know what I'm supposed to do with the 'At every table' part of the text.
There are two more points that I really don't know how to do.
d) In the deck are 52 cards, which differ from eachother through color or value
e) The inputs of all players that still have cards in the hand are equal when bidDone True.
Can you please tell me if what I've done until now is correct and maybe some advice or solution for d) and e)?
Any help is appreciated!
Seems plausible, but I would recommend sensible names, since a validation tool will tend to report that e.g Constraint Player::i2 is not satisfied for ...
b) looks to have a < / <= bug
c) allInstances takes a type source so "Player." is wrong. allInstances is generally very inefficient to execute so should only be used as a last resort. In your case it is clearly wrong since your scope is "at every Table". You should be using context Table and then reasoning about the players at the table.
d) if you rephrase "differ from" as "is unique with respect to", you can perhaps see how you could use a Tuple of color+value as the basis for uniqueness.
e) no idea what an input is, but it just seems like a cascade of implies clauses.
During analyzing the lifetime of a GameplayEffect modifier and execution, I've stumbled across attribute aggregators or GameplayEffect aggregators (both terms are used in source code). These are used to evaluate modified attribute values (they are modified by GameplayEffects).
However, I don't understand how those aggregators influence the actual GameplayAbilitySystem attributes which are attached (as part of an AttributeSet) to the actor:
Does an attribute/GameplayEffect aggregator FAggregator influence the base value or the current value of a gameplay attribute FGameplayAttributeData?
Is the base value of an attribute/GameplayEffect aggregator float FAggregator::BaseValue related to the base value of a gameplay attribute float FGameplayAttributeData::BaseValue?
The vital components of attribute/GameplayEffect aggregators are
so called gameplay modifier evaluation channels EGameplayModEvaluationChannel, which are used sequentially during value evaluation (the result of channel0 is passed as base value to channel1 etc)
storing modifiers (with its magnitude, operation, tags and link to the applying GameplayEffect) in certain channels, which define the actual numerical evaluation
Those are used for doing the evaluation of
a final value
a base value by evaluating a final value in reverse, attempting to determine the base value from the modifiers (deprecated b/c GAS now has struct-based attributes - according to documentation)
a bonus value (final value - base value)
(all of them are just return values of functions and are not member variables of the aggregator)
To notify other classes of an evaluation (or changes to the aggregator), two methods are used
a delegate FOnAggregatorDirty is broadcasted which contains a reference to the aggregator
every GameplayEffect, which is registered in the AbilitySystemComponent, updates the change to its affected attribute(s) (via FActiveGameplayEffectsContainer::UpdateAggregatorModMagnitudes()) by updating the aggregator FAggregator for the attribute (which is determined or set via FindOrCreateAttributeAggregator()) in FAggregator::UpdateAggregatorMod())
I don't see, how one or both of those notification methods update the actual attribute values.
(The official documentation/source code as well as the excellent GAS: Comprehensive Analysis and GAS and you unfortunately don't shed light on GameplayEffect aggregators.)
The attribute/GameplayEffect aggregator influences the current value of a gameplay attribute.
Partly yes. They are related in one direction: the base value of the gameplay attribute is used to set the base value of the attribute/GameplayEffect aggregator, but not the other way around. The aggregator does not change the attribute base value.
Explanation for (1)
I was on the right track by looking at the notification methods. In fact, both in conjunction are updating the gameplay attribute:
FActiveGameplayEffectsContainer::FindOrCreateAttributeAggregator() applies UAbilitySystemComponent::OnAttributeAggregatorDirty() to the OnDirty delegate (that delegate is executed when the aggregator changes as written in the question).
OnAttributeAggregatorDirty() calls FActiveGameplayEffectsContainer::InternalUpdateNumericalAttribute(), which calls
UAbilitySystemComponent::SetNumericAttribute_Internal(), which calls
FGameplayAttribute::SetNumericValueChecked(). That sets the current value of a gameplay attribute.
Explanation for (2)
The base value of the attribute/GameplayEffect aggregator is set only using the gameplay attribute base value FGameplayAttributeData::BaseValue in:
FActiveGameplayEffectsContainer::OnAttributeAggregatorDirty()
FActiveGameplayEffectsContainer::SetAttributeBaseValue()
The base value of the gameplay attribute is set by:
UAttributeSet::InitFromMetaDataTable()
FActiveGameplayEffectsContainer::SetAttributeBaseValue()
In both functions, the attribute base value has no relation to the base value of the aggregator.
I am reading Category Theory for Programmers, and I cannot figure out what exactly a category is.
Let's consider the Bool type. Is Bool a category and True or False are objects (inhabitants)?
One reason you're getting a lot of potentially confusing answers is that your question is a little like asking: "Let's consider a soccer ball. Is the soccer ball a 'game' with the black and white polygons its 'pieces'?"
The answer might be #arrowd's answer: "No, you've confused the game of soccer (Hask) with its ball (Bool), and the polygons (True and False) don't matter." Or, it might be #freestyle's answer: "Yes, we could certainly create a game using the soccer ball and assign one player to the black polygons and the other player the white polygons, but what would the rules be?" Or, it might be #Yuval Itzchakov's answer: "Formally, a 'game' is a collection of one or more players, zero or more pieces, and a set of rules such that, etc., etc."
So, let me add to the confusion with one more (very long) answer, but maybe it will answer your question a little more directly.
Yes, but it's a boring category
Instead of talking about the Haskell type Bool, let's just talk about the abstract concept of boolean logic and the boolean values true and false. Can we form a category with the abstract values "true" and "false" as the objects?
The answer is definitely yes. In fact, we can form (infinitely) many such categories. All we need to do is explain what the "objects" are, what the "arrows" (sometimes called morphisms) are, and make sure that they obey the formal mathematical rules for categories.
Here is one category: Let the "objects" be "true" and "false", and let there be two "arrows":
true -> true
false -> false
Note: Don't confuse this -> notation with Haskell functions. These arrows don't "mean" anything yet, they are just abstract connections between objects.
Now, I know this is a category because it includes both identity arrows (from an object to itself), and it satisfies the composition property which basically says that if I can follow two arrows from a -> b -> c , then there must be a direct arrow a -> c representing their "composition". (Again, when I write a -> b -> c, I'm not talking about a function type here -- these are abstract arrows connecting a to b and then b to c.) Anyway, I don't have enough arrows to worry too much about composition for this category because I don't have any "paths" between different objects. I will call this the "Discrete Boolean" category. I agree that it is mostly useless, just like a game based on the polygons of a soccer ball would be pretty stupid.
Yes, but it has nothing to do with boolean values
Here's a slightly more interesting category. Let the objects be "true" and "false", and let the arrows be the two identity arrows above plus:
false -> true
This is a category, too. It has all the identity arrows, and it satisfies composition because, ignoring the identity arrows, the only interesting "path" I can follow is from "false" to "true", and there's nowhere else to go, so I still don't really have enough arrows to worry about the composition rule.
There are a couple more categories you could write down here. See if you can find one.
Unfortunately, these last two categories don't really have anything to do with the properties of boolean logic. It's true that false -> true looks a little like a not operation, but then how could we explain false -> false or true -> true, and why isn't true -> false there, too?
Ultimately, we could just as easily have called these objects "foo" and "bar" or "A" and "B" or not even bothered to name them, and the categories would be just as valid. So, while technically these are categories with "true" and "false" as objects, they don't capture anything interesting about boolean logic.
Quick aside: multiple arrows
Something I haven't mentioned yet is that categories can contain multiple, distinct arrows between two objects, so there could be two arrows from a to b. To differentiate them, I might give them names, like:
u : a -> b
v : a -> b
I could even have an arrow separate from the identity from b to itself:
w : b -> b -- some non-identity arrow
The composition rule would have to be satisfied by all the different paths. So, because there's a path u : a -> b and a path w : b -> b (even though it doesn't "go" anywhere else), there would have to be an arrow representing the composition of u followed by w from a -> b. Its value might be equal to "u" again, or it might be "v", or it might be some other arrow from a -> b. Part of describing a category is explaining how all the arrows compose and demonstrating that they obey the category laws (the unit law and the associative law, but let's not worry about those laws here).
Armed with this knowledge, you can create an infinite number of boolean categories just by adding more arrows wherever you want and inventing any rules you'd like about how they should compose, subject to the category laws.
Sort of, if you use more complicated objects
Here's a more interesting category that captures some of the "meaning" of boolean logic. It's kind of complicated to explain, so bear with me.
Let the objects be boolean expressions with zero or more boolean variables:
true
false
not x
x and y
(not (y or false)) and x
We'll consider expressions that are "always the same" to be the same object, so y or false and y are the same object, since no matter what the value of y is, they have the same boolean value. That means that the last expression above could have been written (not y) and x instead.
Let the arrows represent the act of setting zero or more boolean variables to specific values. We'll label these arrows with little annotations, so that the arrow {x=false,y=true} represents the act of setting two variables as indicated. We'll assume that the settings are applied in order, so the arrow {x=false,x=true} would have the same effect on an expression as {x=false}, even though they're different arrows. That means that we have arrows like:
{x=false} : not x -> true
{x=true,y=true} : x and y -> true
We also have:
{x=false} : x and y -> false and y -- or just "false", the same thing
Technically, the two arrows labelled {x=false} are different arrows. (They can't be the same arrow because they're arrows between different objects.) It's very common in category theory to use the same name for different arrows like this if they have the same "meaning" or "interpretation", like these ones do.
We'll define composition of arrows to be the act of applying the sequence of settings in the first arrow and then applying the settings from the second arrow, so the composition of:
{x=false}: x or y -> y and {y=true} : y -> true
is the arrow:
{x=false,y=true}: x or y -> true
This is a category. It has identity arrows for every expression, consisting of not setting any variables:
{} : true -> true
{} : not (x or y) and (u or v) -> not (x or y) and (u or v)
It defines composition for every pair of arrows, and the compositions obey the unit and associative laws (again, let's not worry about that detail here).
And, it represents a particular aspect of boolean logic, specifically the act of calculating the value of a boolean expression by substituting boolean values into variables.
Hey, look! A Functor!
It also has a somewhat interesting functor which we might call "Negate". I won't explain what a functor is here. I'll just say that Negate maps this category to itself by:
taking each object (boolean expression) to its logical negation
taking each arrow to a new arrow representing the same variable substitutions
So, the arrow:
{a=false} : (not a) and b -> b
gets mapped by the Negate functor to:
{a=false} : not ((not a) and b) -> not b
or more simply, using the rules of boolean logic:
{a=false} : a or (not b) -> not b
which is a valid arrow in the original category.
This functor captures the idea that "negating a boolean expression" is equivalent to "negating its final result", or maybe more generally that the process of substituting variables in a negated expression has the same structure as doing it to the original expression. Maybe that's not too exciting, but this is just a long Stack Overflow answer, not a 500-page textbook on Category Theory, right?
Bool as part of the Hask category
Now, let's switch from talking about abstract boolean categories to your specific question, whether the Bool Haskell type is a category with objects True and False.
The answers above still apply, to the extent that this Haskell type can be used as a model of boolean logic.
However, when people talk about categories in Haskell, they are usually talking about a specific category Hask where:
the objects are types (like Bool, Int, etc.)
the arrows are Haskell functions (like f :: Int -> Double). Finally, the Haskell syntax and our abstract category syntax coincide -- the Haskell function f can be thought of as an arrow from the object Int to the object Double).
composition is regular function composition
If we are talking about this category, then the answer to your question is: no, in the Hask category, Bool is one of the objects, and the arrows are Haskell functions like:
id :: Bool -> Bool
not :: Bool -> Bool
(==0) :: Int -> Bool
foo :: Bool -> Int
foo b = if b then 10 else 15
To make things more complicated, the objects also include types of functions, so Bool -> Bool is one of the objects. One example of an arrow that uses this object is:
and :: Bool -> (Bool -> Bool)
which is an arrow from the object Bool to the object Bool -> Bool.
In this scenario, True and False aren't part of the category. Haskell values for function types, like sqrt or length are part of the category because they're arrows, but True and False are non-function types, so we just leave them out of the definition.
Category Theory
Note that this last category, like the first categories we looked at, has absolutely nothing to do with boolean logic, even though Bool is one of the objects. In fact, in this category, Bool and Int look about the same -- they're just two types that can have arrows leaving or entering them, and you'd never know that Bool was about true and false or that Int represented integers, if you were just looking at the Hask category.
This is a fundamental aspect of category theory. You use a specific category to study a specific aspect of some system. Whether or not Bool is a category or a part of category is sort of a vague question. The better question would be, "is this particular aspect of Bool that I'm interest in something that can be represented as a useful category?"
The categories I gave above roughly correspond to these potentially interesting aspects of Bool:
The "Discrete Boolean" category represents Bool as a plain mathematical set of two objects, "true" and "false", with no additional interesting features.
The "false -> true" category represents an ordering of boolean values, false < true, where each arrow represents the operator '<='.
The boolean expression category represents an evaluation model for simple boolean expressions.
Hask represents the composition of functions whose input and output types may be a boolean type or a functional type involving boolean and other types.
If you are talking about Hask category, then no. Hask is the category and the objects are Haskell types. That is, Bool is an object, and True/False aren't even talked about here. The description of Hask can be found on Haskell wiki. There are also talks, that Hask isn't even a proper category, read this.
Connections have at least two important variables. The flow variable and not-flow variable (and then stream stuff but lets not talk about those). For clarity I will reference the Fluid connector and its variables m_flow (flow variable) and p (not flow variable).
When your building components it is important to specify if that component is setting the value for the m_flow or p. For example, you do not want to connect two pressure loss components (sets m_flow) together.
The fluid connectors in MSL are defined as port_a (design inlet) and port_b (design outlet). To specify if a port sets m_flow or not, DynamicPipe opts to use the PartialTwoPort component that has an object (black ellipse) in the icon layer that toggles its visibility based on a parameter (port_a_exposesState) which can be modified when PartialTwoPort is extended (i.e., PartialTwoPortFlow).
However, this feature does not work. The parameter will not change its display when the parameter is changed (i.e., the black ellipse on DynamicPipe never goes away).
Below is a simple example demonstrating the concept. When the model "RunMe" is simulated the parameter showBall = false because number <> 1. However, the ball is still visible.
Partial Model setting the object that should appear/disappear:
partial model ballIcon
// input Boolean showBall; // Tried this as well to no avail.
protected
parameter Boolean showBall = true;
annotation (Icon(coordinateSystem(preserveAspectRatio=false), graphics={
Ellipse(
extent={{-40,40},{40,-40}},
lineColor={0,0,0},
fillPattern=FillPattern.HorizontalCylinder,
fillColor={255,255,0},
visible=showBall)}),
Diagram(coordinateSystem(
preserveAspectRatio=false)));
end ballIcon;
Extending model:
model extendsBallIcon
extends ballIcon(showBall=(number==1));
parameter Real number = 1;
end extendsBallIcon;
Model that should show a ball that appears or disappears based on "number":
model RunMe
extendsBallIcon Ball(number=3)
annotation (Placement(transformation(extent={{-10,-10},{10,10}})));
end RunMe;
Is there something that can be corrected to this approach so the GUI of a component when used (i.e., on the diagram layer) will work? Or do connectors GUI need to capture the flow/not-flow element that is defined by a component to assist in model usage (i.e., change port_a from description design inlet to defined flow variable).
Using Dymola 2017 (tested with the same results on Dymola 2016 as well)
Update:
Knowing the simple case works using DynamicSelect leads me to a real application. The following change appears to cause the icon to not toggle its visiblity.
In extendsBallIcon replacing:
extends ballIcon(showBall=(number==1));
parameter Real number = 1;
with
// Boolean Example
extends ballIcon(showBall=(number==true));
final parameter Boolean number = (modelStructure==Modelica.Fluid.Types.ModelStructure.av_b);
parameter Modelica.Fluid.Types.ModelStructure modelStructure = Modelica.Fluid.Types.ModelStructure.av_b;
Modelica language specification states in section 18.6.6: "Any value (coordinates, color, text, etc) in graphical annotations can be dependent on class variables using the DynamicSelect expression." That is, visible=DynamicSelect(true, showBall) in your example will display the ellipse only if showBall is true.
Using Enterprise Architect (version 7.5), I'm trying to refine the code generation for C#. To make an attribute with an initial value that is a string generate properly, the only way I've been successful is with the code below. Does anyone know if a simpler way to do this? It currently seems a little bloated.
%if attType=="string" and attInitial!=""%
= "
%elseIf attInitial!=""%
=
%endIf%
%attInitial ? value%
%if attType=="string" and attInitial!=""%
"
%endIf%
%if attInitial!=""%
=
%attInitial%
%endIf%
EA's attInitial corresponds to Property.default in UML.
default : String [0..1]
A string that is evaluated to give a default value for the attribute when an object of the owning class is instantiated. -- UML 2.2 infrastructure 10.2.5, emphasis added
So according to UML, if the type of the property is string, then the value attInitial should be an expression which evaluates to a string, not the content of a string literal.
If you do want it to be a non-UML-complient extension string literal value, you have to write something a bit more complicated that what you have done above to handle escaping.