I built a register model of UVM.
I connected the model to the environment, But the reset values in the registers aren't affected.
i'm adding a link to the code in EDA playground
Here the code of one of the registers: I set the configation with has_reset param and initialized the values of the register but it didn't affect the values.
class ctrl_p2_reg extends uvm_reg;
`uvm_object_utils(ctrl_p2_reg)
rand uvm_reg_field EN_PORT;
rand uvm_reg_field CLIMIT;
rand uvm_reg_field VLIMIT;
rand uvm_reg_field unused;
function new (string name = "ctrl_p2_reg");
super.new (name,8, UVM_NO_COVERAGE);
endfunction
virtual function void build ();
EN_PORT = uvm_reg_field::type_id::create ("EN_PORT");
CLIMIT = uvm_reg_field::type_id::create ("CLIMIT");
VLIMIT = uvm_reg_field::type_id::create ("VLIMIT");
unused = uvm_reg_field::type_id::create ("unused");
// configure(parent, size, lsb_pos, access, volatile, reset,
has_reset, is_rand, individually_accessible);
EN_PORT.configure (this, 1, 0, "RW", 0, 1'b1, 1, 1, 0);
LIMIT.configure (this, 2, 1, "RW", 0, 2'b11, 1, 1, 0);
VLIMIT.configure (this,2, 3, "RW", 0, 2'b11, 1, 1, 0);
unused.configure (this,3, 5, "RW", 0, 3'b111, 1, 1, 0);
endfunction:build
endclass:ctrl_p2_reg
I checked by sending a sequence that the register is indeed connected and it went fine. So I think the problem is probably just in the reset values.
Related
I am using this code for assigning dfferent node to different agents
int[] node = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
for (int i = 0; i < node.length; i++) {
if(agent.participant == i + 1){
agent.setLocation(node[i]);
}
}
The only problem is setLocation() function only accept point arguments not integer.
I also try to make the list of points but it does not work. Let me know how to solve this issue.
As per Emile:
Node[] nodes = {node0, node1, ...};
int counter=0;
for (Node currNode : nodes) {
if(agent.participant == counter + 1){
agent.setLocation(nodes [i]);
counter++;
}
}
You need to understand function arguments. setLocation(...) cannot work with an int, it needs something that is an actual location. Check the API, code-complete help, etc
I'm trying to implement semantic hashing for the MNISTAutoencoder example, using DL4J. How would I binarize the middle layer activations? In the ideal case, I'm looking for some change to my network setup which gives (almost) binary activations for the middle layer out-of-the-box. Alternatively, I'm happy with some "receipt" to binarize the current RELU activations. Which of both approaches is favorable in terms of generalization capabilities?
My current network setup is:
MultiLayerConfiguration conf = new NeuralNetConfiguration.Builder()
.seed(12345)
.weightInit(WeightInit.XAVIER)
.updater(new AdaGrad(0.05))
.activation(Activation.RELU)
.l2(0.0001)
.list()
.layer(new DenseLayer.Builder().nIn(784).nOut(250)
.build())
.layer(new DenseLayer.Builder().nIn(250).nOut(10)
.build())
.layer(new DenseLayer.Builder().nIn(10).nOut(250)
.build())
.layer(new OutputLayer.Builder().nIn(250).nOut(784)
.activation(Activation.LEAKYRELU)
.lossFunction(LossFunctions.LossFunction.MSE)
.build())
.build();
After 30 epochs, typical middle layer activations look like:
[[ 11.3044, 12.3678, 7.3547, 1.6518, 1.0068, 0, 5.4340, 2.1388, 2.0708, 2.5764]]
[[ 9.9051, 12.5345, 11.1941, 4.7900, 1.2935, 0, 7.9786, 4.1915, 3.1802, 7.5659]]
[[ 6.4629, 11.1013, 10.8903, 5.4528, 0.8009, 0, 9.4881, 3.6684, 6.4524, 7.2334]]
[[ 2.3953, 0.2429, 3.7125, 4.1561, 0.8607, 0, 11.2486, 7.0178, 2.8771, 2.1996]]
[[ 0, 1.6378, 0.8993, 0.3347, 0.7708, 0, 3.7053, 0, 1.6704, 2.1380]]
[[ 0, 1.5158, 0.7937, 0, 0.8190, 0, 4.7548, 0.0655, 1.4635, 1.8173]]
[[ 6.8344, 5.9989, 10.1286, 2.8528, 1.1178, 0, 9.1865, 10.3677, 5.3564, 4.3420]]
[[ 7.0942, 7.0364, 4.8538, 0.5096, 0.0442, 0, 8.4336, 8.2783, 5.6474, 3.8944]]
[[ 3.6895, 14.9696, 6.5351, 8.0446, 0, 0, 12.7816, 12.7445, 7.8495, 3.8600]]
This can be established by assigning a custom IActivation function to the middle layer. For example:
public static class ActivationBinary extends BaseActivationFunction {
public INDArray getActivation(INDArray in, boolean training) {
in.replaceWhere(Nd4j.ones(in.length()).muli(-1), new LessThan(0));
in.replaceWhere(Nd4j.ones(in.length()), new GreaterThanOrEqual(0));
return in;
}
public org.nd4j.common.primitives.Pair<INDArray, INDArray> backprop(INDArray in, INDArray epsilon) {
this.assertShape(in, epsilon);
Nd4j.getExecutioner().execAndReturn(new TanhDerivative(in, epsilon, in)); // tanh's gradient is a reasonable approximation
return new org.nd4j.common.primitives.Pair(in, (Object)null);
}
public int hashCode() {
return 1;
}
public boolean equals(Object obj) {
return obj instanceof ActivationBinary;
}
public String toString() {
return "Binary";
}
}
I'm using the following method to create the object stated in the title:
from dateutil import relativedelta
MA_dict = {'years': 0,
'months': 0,
'weeks': 0,
'days': 1,
'hours': 0,
'minutes': 0,
'seconds': 0}
def dict2relativedelta(dict):
'''
creates relativedelta variable that can be used to calculate dates
'''
dt = relativedelta.relativedelta(years=dict['years'], months=dict['months'], weeks=dict['weeks'], days=dict['days'],
hours=dict['hours'], minutes=dict['minutes'], seconds=dict['seconds'])
return dt
However, I would like to simplify this so that I can just pass
MA_dict = {'days': 1}
and the function will return the same. How can I do that?
You don't need a special function for this as Python has argument unpacking with the ** operator. You can accomplish what you want with:
MA_dict = {"days": 1}
rd = relativedelta.relativedelta(**MA_dict)
I used the following code to add a journal article (liferay 6.1):
JournalArticle ja = JournalArticleLocalServiceUtil.addArticle(
userId, groupId, 0, 0, StringPool.BLANK, true,
JournalArticleConstants.VERSION_DEFAULT, titleMap, descriptionMap,
content, "general", structureId, templateId, StringPool.BLANK,
1, 1, 2008, 0, 0, 0, 0, 0, 0, 0, true, 0, 0, 0, 0, 0, true,
true, false, StringPool.BLANK, null, null, StringPool.BLANK,
serviceContext);
For simplicity, I omitted some parts of the code. As specified in the parameters, smallImage = false. However, when adding new journal article, in the journalarticle table, the column SmallImageId always added a number which I was expecting as 0. Does anyone have experience on that?
Reaseon eludes me, but this behaviour is as expected (as programmed) because of this part of JournalArticleLocalServiceUtil.addArticle method
article.setSmallImage(smallImage);
article.setSmallImageId(counterLocalService.increment());
article.setSmallImageURL(smallImageURL);
only later in method is
saveImages(smallImage, article.getSmallImageId(), smallImageFile, smallImageBytes);
which is only part that checks smallImage boolean parameter
protected void saveImages(
boolean smallImage, long smallImageId, File smallImageFile,
byte[] smallImageBytes)
throws PortalException, SystemException {
if (smallImage) {
if ((smallImageFile != null) && (smallImageBytes != null)) {
imageLocalService.updateImage(smallImageId, smallImageBytes);
}
}
else {
imageLocalService.deleteImage(smallImageId);
}
}
Funny part is that workflow for new article without small image is as follows (only relevant parts):
create new article
save image (which you do not want) which actualy tries to remove image that you do not have
I am in the process of building a temporal expression library that must be properly globalized and therefore work in all available Time Zones.
Now I seem to be stuck as I'm not sure how to retrieve adjusted dates from DateTimeOffset objects in the correct Daylight Savings Time (DST) when the transition boundary is crossed using any variety of .Add to move days, hours, etc.
Interestingly, I figured out a work around for the local system's Time Zone but haven't found any way to apply the same strategy to any arbitrary Time Zone.
I was able to find a snippet (didn't keep source, sorry!) which tries to reverse lookup the Time Zone Info by offset but as there are multiple potential results, each of which likely have different DST rules that will not work. (There may be some optimizations available but the base premis is flawed I think)
public TimeZoneInfo GetTimeZoneInfo(DateTimeOffset Value)
{
// Search available sytem time zones for a matching one
foreach (var tzi in TimeZoneInfo.GetSystemTimeZones())
{
// Compare value offset with time zone offset
if (tzi.GetUtcOffset(Value).Equals(Value.Offset))
{
return tzi;
}
}
}
This stuff can be a bit tedious to prove out so I've extracted the core issue into a couple methods and unit tests which will hopefully demonstrate the issue I'm facing.
public DateTimeOffset GetNextDay_Wrong(DateTimeOffset FromDateTimeOffset)
{
// Cannot create a new DateTimeOffset using simply the supplied value's UtcOffset
// because in PST, for example, it could be -7 or -8 depending on DST
return new DateTimeOffset(FromDateTimeOffset.Date.AddDays(1), FromDateTimeOffset.Offset);
}
[TestMethod]
public void GetNextDay_WrongTest()
{
var tz = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");
var workingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var failingDate = new DateTime(2009, 11, 1, 0, 0, 0);
var workingDate_tz = new DateTimeOffset(workingDate, tz.GetUtcOffset(workingDate));
var failingDate_tz = new DateTimeOffset(failingDate, tz.GetUtcOffset(failingDate));
var actual_workingDate_tz = GetNextDay_Wrong(workingDate_tz);
var actual_failingDate_tz = GetNextDay_Wrong(failingDate_tz);
var expected_workingDate = new DateTime(2009, 11, 3, 0, 0, 0);
var expected_failingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var expected_workingDate_tz = new DateTimeOffset(expected_workingDate, tz.GetUtcOffset(expected_workingDate));
var expected_failingDate_tz = new DateTimeOffset(expected_failingDate, tz.GetUtcOffset(expected_failingDate));
Assert.AreEqual(expected_workingDate_tz, actual_workingDate_tz, "Should have found the following day's midnight");
Assert.AreEqual(expected_failingDate_tz, actual_failingDate_tz, "Failing date does not have the correct offset for it's DST");
}
public DateTimeOffset GetNextDay_LooksRight(DateTimeOffset FromDateTimeOffset)
{
// Because we cannot create a new DateTimeOffset we simply adjust the one provided!
var temp = FromDateTimeOffset;
// Move back to midnight of the current day
temp = temp.Subtract(new TimeSpan(temp.Hour, temp.Minute, temp.Second));
// Now move to the next day
temp = temp.AddDays(1);
// Let the DateTimeOffset class do it's magic
temp = temp.ToLocalTime();
// Check if the time zone has changed
if (FromDateTimeOffset.Offset != temp.Offset)
{
// Calculate the change amount (could be 30 mins or even stranger)
var delta = FromDateTimeOffset.Offset - temp.Offset;
// Adjust the temp value by the delta
temp = temp.Add(delta);
}
return temp.ToLocalTime();
}
[TestMethod]
public void GetNextDay_LooksRightTest()
{
// Everything is looking good and the test passes now, so we're home free yeah?
// { To work this needs to match your system's configured Local Time Zone, I'm in PST }
var tz = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");
var workingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var failingDate = new DateTime(2009, 11, 1, 0, 0, 0);
var workingDate_tz = new DateTimeOffset(workingDate, tz.GetUtcOffset(workingDate));
var failingDate_tz = new DateTimeOffset(failingDate, tz.GetUtcOffset(failingDate));
var actual_workingDate_tz = GetNextDay_LooksRight(workingDate_tz);
var actual_failingDate_tz = GetNextDay_LooksRight(failingDate_tz);
var expected_workingDate = new DateTime(2009, 11, 3, 0, 0, 0);
var expected_failingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var expected_workingDate_tz = new DateTimeOffset(expected_workingDate, tz.GetUtcOffset(expected_workingDate));
var expected_failingDate_tz = new DateTimeOffset(expected_failingDate, tz.GetUtcOffset(expected_failingDate));
Assert.AreEqual(expected_workingDate_tz, actual_workingDate_tz, "Should have found the following day's midnight");
Assert.AreEqual(expected_failingDate_tz, actual_failingDate_tz, "Failing date does not have the correct offset for it's DST");
}
[TestMethod]
public void GetNextDay_LooksRight_FAILTest()
{
// Here is where the frustrating part is... aparantly the "magic" that DateTimeOffset provides only works for your systems Local Time Zone...
// { To properly fail this cannot match your system's configured Local Time Zone, I'm in PST so I use EST }
var tz = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
var workingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var failingDate = new DateTime(2009, 11, 1, 0, 0, 0);
var workingDate_tz = new DateTimeOffset(workingDate, tz.GetUtcOffset(workingDate));
var failingDate_tz = new DateTimeOffset(failingDate, tz.GetUtcOffset(failingDate));
var actual_workingDate_tz = GetNextDay_LooksRight(workingDate_tz);
var actual_failingDate_tz = GetNextDay_LooksRight(failingDate_tz);
var expected_workingDate = new DateTime(2009, 11, 3, 0, 0, 0);
var expected_failingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var expected_workingDate_tz = new DateTimeOffset(expected_workingDate, tz.GetUtcOffset(expected_workingDate));
var expected_failingDate_tz = new DateTimeOffset(expected_failingDate, tz.GetUtcOffset(expected_failingDate));
Assert.AreEqual(expected_workingDate_tz, actual_workingDate_tz, "Should have found the following day's midnight");
Assert.AreEqual(expected_failingDate_tz, actual_failingDate_tz, "Failing date does not have the correct offset for it's DST");
}
The underlying issue with this case is that there is not enough information to perform the appropriate Time Zone conversions. Simple offset is not specific enough to infer the Time Zone because for a given offset at a specific moment there can be multiple potential Time Zones. Because the DateTimeOffset object does not capture and maintain the information about the Time Zone it was created with it must be the responsibility of something external to that class to maintain this relationship.
The thing that threw me off the scent was the call ToLocalTime() which I later realized was in fact introducing an implied TimeZoneInfo into the calculation, that of the configured local time for the machine and I believe that internally the DateTimeOffset must be converting to UTC by simply removing the configured offset and then creating a new DateTimeOffset class using the constructor taking DateTime [in UTC] and TimeZoneInfo [from local system] to produce the correct dst aware resulting date.
Given this limitation I no longer see any value in the DateTimeOffset class over the equally accurate and more valuable combination of DateTime and TimeZoneInfo.