Modelica web colors - colors

I thought it might be convenient to define some colors as constants to use later on in Modelica color annotations. As it seems the web colors are an accepted standard, I copied all of them into a package of constant arrays:
https://en.wikipedia.org/wiki/Web_colors
https://gist.github.com/thorade/a1298571938231ef90d3bedf6b514967
But it seems I cannot use them as intended, the following example fails.
It seems literals work, or if I define the constant in the same class, but not if I import it.
Am I doing something wrong, or is it a limitation of the tool I am using?
within ;
package Modelica_Colors
type RealColor = Modelica.Icons.TypeReal[3] (each min=0, each max=255);
package BasicColors
final constant RealColor Aqua={0,255,255};
final constant RealColor Black={0,0,0};
final constant RealColor Blue={0,0,255};
final constant RealColor Fuchsia={255,0,255};
final constant RealColor Gray={128,128,128};
final constant RealColor Grey={128,128,128};
final constant RealColor Green={0,128,0};
final constant RealColor Lime={0,255,0};
final constant RealColor Maroon={128,0,0};
final constant RealColor Navy={0,0,128};
final constant RealColor Olive={128,128,0};
final constant RealColor Purple={128,0,128};
final constant RealColor Red={255,0,0};
final constant RealColor Silver={192,192,192};
final constant RealColor Teal={0,128,128};
final constant RealColor White={255,255,255};
final constant RealColor Yellow={255,255,0};
end BasicColors;
package Colors
final constant RealColor Crimson={220,20,60};
final constant RealColor Cyan={0,255,255};
final constant RealColor DarkBlue={0,0,139};
final constant RealColor DarkCyan={0,139,139};
final constant RealColor OliveDrab={107,142,35};
final constant RealColor Orange={255,165,0};
final constant RealColor OrangeRed={255,69,0};
final constant RealColor Orchid={218,112,214};
final constant RealColor PaleGoldenRod={238,232,170};
final constant RealColor PaleGreen={152,251,152};
final constant RealColor Yellow={255,255,0};
final constant RealColor YellowGreen={154,205,50};
end Colors;
model Test
// works
constant RealColor test_const1={255,20,147}; // pinkish
// does not work
final constant RealColor test_equal=Modelica_Colors.Colors.OrangeRed;
constant RealColor test_pi={Modelica.Constants.pi,2*Modelica.Constants.pi,3*Modelica.Constants.pi};
import Modelica_Colors.BasicColors.Yellow;
protected
// works
constant RealColor test_const2={147,20,255};
annotation (Icon(coordinateSystem(preserveAspectRatio=false), graphics={
Rectangle(
extent={{-100,100},{0,0}},
lineColor=test_const2,
fillColor=test_const1,
fillPattern=FillPattern.Solid),
Rectangle(
extent={{0,0},{100,-100}},
lineColor=Modelica_Colors.Colors.Cyan,
fillColor=Yellow,
fillPattern=FillPattern.Solid),
Rectangle(
extent={{0,100},{100,0}},
lineColor=test_equal,
fillColor=test_equal,
fillPattern=FillPattern.Solid),
Rectangle(
extent={{-100,0},{0,-100}},
lineColor=test_equal,
fillColor=test_pi,
fillPattern=FillPattern.Solid)}), Diagram(coordinateSystem(
preserveAspectRatio=false)));
end Test;
annotation (uses(Modelica(version="3.2.3")));
end Modelica_Colors;

the reason is simple: graphical annotations depending on variable, work only if the variable is present in the result file.
So, as your color annotation is calling data using import, the Yellow code is not included inside the result file, hence your test box cannot be colored.
The same logic can be applied to protected variables: it will fail to be applied to any graphical annotation.

Related

Types with Math.net numerics

I am starting to use the Math.net numerics library and I can't find examples, so I'm running into a few issues:
To make a simple example, I have two arrays of doubles. I want to divide one by the other and then calculate the moving average.
So, the code looks like this:
var VD1 = Vector<double>.Build.Dense(Data1.ToArray());
var VD2 = Vector<double>.Build.Dense(Data2.ToArray());
var R = VD1 / VD2;
var SMA = R.MovingAverage(15);
The problem is that, on the way, the data type changes. It starts as 2 Vectors, the division result is a Vector and the SMA result is not, it's an IEnumerable<double>.
So, now if I want to plug that result into more functions, for example multiply it by another array, I can't. I have to rebuild a Vector from the result.
Am I somehow doing this wrong? I can't imagine that the API would bounce back and forth between different but similar types.
You are doing it right. That is how MathNet is designed. E.g., var R = VD1 / VD2; calls
// Summary: Pointwise divides two Vectors.
public static Vector<T> operator /(Vector<T> dividend, Vector<T> divisor);
and returns Vector<T>.
var SMA = R.MovingAverage(15); calls
public static IEnumerable<double> MovingAverage(this IEnumerable<double> samples, int windowSize);
and returns IEnumerable<double>.
You can call MovingAverage with Vector<double> R, because Vector<double> implements IEnumerable<double> and you get implicit casting. But MovingAverage does not know its argument is Vector<double>, it's designed to return IEnumerable<double>.
And that makes sense. As far as I remember from colledge, moving average is about time series and it has no explicit relationship to vectors.
But you can have some workarounds. For example your own overload for MovingAverage:
static class VectorHeplper
{
public static Vector<double> MovingAverage(this Vector<double> samples, int windowSize)
{
return DenseVector.OfEnumerable(samples.AsEnumerable().MovingAverage(windowSize));
}
}
Then var SMA = R.MovingAverage(15); is Vector<double>.
Anyway, building a new instance of Vector is the right and logical way.

What does the dot mean at the end of an association?

I reversed some Java code to get a uml class diagram using Visual Paradigm. The diagram shows some associations with little black circles on one end, which I never saw before.
Image
It's definitely not a composition and not a containment! Can anybody explain to me, what kind of association this is?
Here's the related code:
public class DataAdapter extends RecyclerView.Adapter<DataAdapter.ViewHolder> {
public static final String TAG = DataAdapter.class.getSimpleName();
private static Context mContext;
private ArrayList<DataClass> mData;
private static OnItemClickListener<DataClass> mListener;
public static class ViewHolder extends RecyclerView.ViewHolder {}
public DataAdapter(Context context, ArrayList<DataClass> data) {}
public void setOnClickListener(OnItemClickListener listener) {}
#Override
public int getItemCount() {}
#Override
public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {}
#Override
public void onBindViewHolder(ViewHolder holder, int position) {}
}
public interface OnItemClickListener<T> {
public void onItemClick(T item);
}
What you are seeing is the ownership indicator, commonly known as the dot
In this case it indicates that the property at right side of the association is owned by the class on the left side.
From the UML specs v2.5:
Ownership of Association ends by an associated Classifier may be
indicated graphically by a small filled circle, which for brevity we
will term a dot. The dot is to be drawn integral to the graphic path
of the line, at the point where it meets the Classifier, inserted
between the end of the line and the side of the node representing the
Classifier. The diameter of the dot shall not exceed half the height
of the aggregation diamond, and shall be larger than the width of the
line. This avoids visual confusion with the filled diamond notation
while ensuring that it can be distinguished from the line. The dot
shows that the model includes a Property of the type represented by
the Classifier touched by the dot. This Property is owned by the
Classifier at the other end. In such a case it is normal to suppress
the Property from the attributes compartment of the owning Classifier.
To adorn Geert's correct answer: In former UML versions navigability (an open arrow at either side) was (mis-) used for that purpose. So now that you see a dot it also means you can navigate towards it (because it renders an attribute of the class type it's touching). It is still possible to mix both notations. But it does not make much sense. Personally I'd use (if ever) navigational arrows only in a conceptual phase.

Computation of ROC curve data points (Receiver operator characteristic)

Given a particular threshhold e, I am able to generate two sets of the following format :-
Set<String> observedDocs;
Set<String> actualDocs;
Now I have to come up with True Positive Rate and False Positive Rates. The TPR is easy to calculate, its a really intuitive definition of recall which I do in the following manner:-
private double recall(final Set<String> observedDocs, final Set<String> actualDocs) {
Set<String> relevantAndRetrieved = new HashSet<>(observedDocs);
relevantAndRetrieved.addAll(actualDocs);
return relevantAndRetrieved.size() / actualLabels.size();
}
I need some equivalent set manipulation based way to compute the False Positive rate. I dont want to compute the False positive, False Negative counts etc.
Well, the FPR is proportion of negative examples which are marked positive by the classifier. But I don't see how to express that in terms of the variables you have. How is your recall function working anyway? observedLabels and actualLabels are going to have at most 2 elements, right? Did you mean to make those List instead of Set ??

Statistical String Comparison

I am looking for a method to compare string similarity. Specifically, given two addresses I would like a measure of their similarity.
E.G.
Given 8219 Lime Forest Blvd
and 8219 Lime Forst Boulevard
The output of the comparison should give me an idea of how similar the strings are.
Levenshtein distance is way to go. Just out of box idea - two addresses can be different a lot (one can be postal code, another one street with number) and a lot of money were spend to create awesome geocoding services (like https://developers.google.com/maps/documentation/geocoding/?hl=cs). So alternative approach would be to calculate longitude/latitude for both addresses via geocoding service and see if the latitude/longitude matches :)
you could use something like this
import org.apache.commons.lang.StringUtils;
public class StringComparison {
/**
* #param args
*/
public static void main(String[] args) {
String s1 = "8219 Lime Forest Blvd";
String s2 = "8219 Lime Forst Boulevard";
//number of chars that differ
int distance = StringUtils.getLevenshteinDistance(s1, s2);
//"relative" difference
float d = (float)distance / (float)s1.length();
System.out.println(d);
}
}
getLevenshteinDistance will give you a number of chars that differ from s1 to s2.
I think it's more useful if you divide this number by the string length (careful with division by zero) and try to manually find a sweet spot where the difference is small enough to detect the same address (for me, this is usually around 20~30%)
This example is in JAVA, the lib used is at http://commons.apache.org/proper/commons-lang/index.html
Also, you could improve this just replacing known abbreviations and trying with them too.

Trouble Naming Constants: Two Right-Angled Triangles

i'm trying to come up with appropriate constant names for two right-angled triangles that can be rotated.
the image above shows the two different versions of a right-angled triangle. the right angle of the orange triangle is in the bottom-right while the right angle of the blue triangle is in the bottom-left.
from that, let's assume i will name each constant as:
public static const RIGHT_ANGLE_BOTTOM_RIGHT:String = "rightAngleBottomRight";
public static const RIGHT_ANGLE_BOTTOM_LEFT:String = "rightAngleBottomLeft";
besides those constant names being quite long and not very descriptive, these triangles can be rotated. therefore, if the orange triangle (RIGHT_ANGLE_BOTTOM_RIGHT) is rotated -90ยบ, its name is now misleading (and conflicting) since its right angle is now in the bottom left of the triangle shape.
so i'm searching for constant names for these rotatable, right-angled triangles which are clear and distinguishing (and ideally short). currently, my "best" is simply calling them type 1 and type 2. while those names are unmistakably distinguishing, it certainly isn't at all clear of their shape, especially since they can be rotated.
package
{
public final class TriangleStyle
{
public static const ISOSCELES:String = "isosceles";
public static const RIGHT_Type1:String = "right1";
public static const RIGHT_Type2:String = "right2";
}
}
any thoughts?
Perhaps HOA and HAO -- I'll leave the derivation to you -- and note that these names are invariant under rotation.

Resources