I'm running the solver on a planning and between the various answer sets i get what I think is a warning (as it does not termiate the execution) saying the following:
Progression : [2;8] (Error: 3)
Progression : [3;8] (Error: 1.66667)
Progression : [4;8] (Error: 1)
Progression : [5;8] (Error: 0.6)
Progression : [6;8] (Error: 0.333333)
Progression : [7;8] (Error: 0.142857)
I can't find any reference to that warnings so I hope someone knows what they mean.
These lines give valuable information about the current state of the optimization: in your example, the solver has found a solution of cost 8 and not yet proved that the solution is optimal, but it is on the way to prove it: it has proved that the cost is at least 2, 3, 4, ..., 7. So if you abort the solver after the last line, you have a guarantee that the solution you found is either optimal or 1 away from optimum.
This information can help you to make comprimises between optimality and solver time. Often you are fine in applications if you have suboptimal results that are close enough to the optimum.
A quick search in the clasp source https://github.com/potassco/clasp/blob/master/src/clasp_output.cpp revealed that method TextOutput::printUnsat is responsible for these messages.
The comment in the base class shows for Output::printUnsat:
//! Called on unsat - may print new info.
Specifically, TextOutput::printUnsat comment is
//! Prints the given lower bound and upper bounds that are known to be optimal.
Related
I am new to Specman and trying to learn it by reading existing code.
I came across the following function and can't find an explanation in specman documentation...
VerifyNode(end_point:string, derived_value:uint) is also {
if ('(end_point)' === ~derived_value) {
message("Error1");
}
else if ('(end_point)' === derived_value) {
message("Error2");
}
else {
message("Error3");
}
}
I assume logically the '(end_point)' is getting actual value of end_point signal in run-time. Is that true?
Error1 will be the message if value of end_point at run time is negate the derived_value unsigned integer.
Error2 will be the message if value of end_point at run time is the same as the derived_value unsigned integer.
How can i explain the "Error3" condition?
Indeed this is the very old school of signal access based on string. I recommend you search for "simple_port".
The end_point is a string, that should be the full HDL path of the signal you want to read. Example of calling this method:
// check if signal has the value 3:
VerifyNode("top.module_a.sig_val", 3);
The official name of '' is called the tick notation in Specman documentation. Search for the term "tick notation" in cdnshelp and you will find it.
'(end_point)' is two things. It is old-school, non-port access to the device under test (DUT) and the (end_point) part of that snippet is the way to do string substitution directly in the '' access to the DUT. Using the old style of access to the DUT can drastically slow down simulation speed, if your design is big enough for that to be a concern for you. Also, this methodology lacks more static compile time checks as those strings can be anything and you'll only know the path is wrong when you simulate it and the DUT path cannot be found, creating an error.
When implementing a complex tactic in Ltac, there are some Ltac commands or tactic invocation that I expect to fail and where that is expected (e.g. to terminate a repeat, or to cause backtracking). These failures are usually raised at failure level 0.
Failures raised at higher level “escape” the surrounding try or repeat block, and are useful to signal unexpected failures.
What I am missing is a way to run a tactic tac and treat its failure, even at level 0, to be at a higher level, while retaining the message of the failure. This would let me make sure that repeat does not terminate due to a Ltac programming error on my side.
Can I implement such a failure-raising-level higher-order tactic in Ltac?
You can write a tactic to achieve that in Ocaml. I put that on GitHub here.
For example the following should raise an error instead of silently succeeding:
repeat (match goal with
| [ |- _ ] =>
raise_error_level (assert (3 = 3) by idtac)
end).
I do not know if it is possible to get exactly what you want, but I sometimes use the following idiom:
tactic_expression_that_may_fail_with_level_0
|| fail 1000 "There was some problem here"
If the first tactic fails with level 0, the || will try to run the second one, which will fail with a very high level and report it to you.
It would help if you could provide a concrete use case to see if some other technique would be better suited.
I feel like this is a dumb question, but when I'm in an IPython notebook and I do help on some numpy/scipy function, like say stat.norm.rvs, it frequently says, about *args and **kargs, "see docstring of the instance object for more information". How do I see this docstring if not with help(stat.norm.rvs)?
Don't feel dumb; sometimes it is hard to find the information you are looking for, especially when starting out. Moreover, much of the docstrings in scipy.stats are autogenerated, so they are somewhat generic, not custom-tailored. The good news is, once you undestand how to manipulate on distribution, all the others are basically the same since they share the same interface.
Let's work through an example. Since you are using IPython (great!), we can also
use the question mark after an object, e.g. obj?, to find out more about the
object. This shows the docstring, like help(obj), plus other useful info such
as its type, where it is defined, and (for callables) its call signature.
It helps to have a picture of how things are organized. scipy.stats is a module:
In [386]: from scipy import stats
The module docstring lists many kinds of distributions.
In [394]: stats?
...
Continuous distributions
========================
...
alpha -- Alpha
anglit -- Anglit
arcsine -- Arcsine
beta -- Beta
betaprime -- Beta Prime
...
norm -- Normal (Gaussian)
There are two main classes -- stats.rv_continuous and stats.rv_discrete.
Each of these distributions listed in the stats docstring is an instance of
one of these two classes. stats.norm for example, is an instance of
stats.norm_gen which is a subclass of stats.rv_continuous:
In [14]: type(stats.norm).mro()
Out[14]:
[scipy.stats._continuous_distns.norm_gen,
scipy.stats._distn_infrastructure.rv_continuous,
scipy.stats._distn_infrastructure.rv_generic,
object]
Notice that stats.norms.rvs is an instancemethod :
In [387]: stats.norm.rvs?
Type: instancemethod
String form: <bound method norm_gen.rvs of <scipy.stats._continuous_distns.norm_gen object at 0x7f1479ba2690>>
So when later it says
The shape parameter(s) for the distribution (see docstring of the instance
object for more information).
it is saying there is more information in the docstring of stats.norm:
In [401]: stats.norm?
Docstring:
A normal continuous random variable.
The location (loc) keyword specifies the mean.
The scale (scale) keyword specifies the standard deviation.
...
Methods
-------
``rvs(loc=0, scale=1, size=1, random_state=None)``
Random variates.
From this description you can see that stats.norm.rvs(loc=10, scale=2, size=5) will return 5 random variates with mean 10 and standard deviation 2:
In [402]: stats.norm.rvs(loc=10, scale=2, size=5)
Out[402]: array([ 9.82454792, 8.52106712, 7.33889233, 8.73638555, 10.90927226])
Alternatively, stats.norm is also callable -- you can pass the loc and scale "shape" parameters to "freeze" those parameters into the distribution. What you get back is called a "frozen distribution". For example, you can create a normal distribution with mean 10 and standard devation 2:
In [403]: norm = stats.norm(10, 2)
and now call the frozen distribution's rvs method to obtain 5 random variates:
In [404]: norm.rvs(5)
Out[404]: array([ 7.21018883, 12.98978919, 10.99418761, 11.2050962 , 8.27780614])
I'm trying to implement a simple cryptocurrency similar to bitcoin, just to understand it deeply down to the code level.
I understand that a bitcoin block contains a hash of the previous block, many transactions and an reward transaction for the solver.
the miner basically runs SHA256 on this candidate block combined with an random number. As long as the first certain digits of a hash result are zeros, we say this block is solved, and we broadcast the result to the entire network to claim the reward.
but I have never seen anyone proving that a block is solvable at all. I guess this is guaranteed by SHA256? because the solution size is fixed, after trying enough inputs, you are guaranteed to hit every hash result? but how can you prove that the solution distribution of a block is even (uniform), so that you can indeed cover all hash results?
now, suppose a block is indeed always solvable, can I assume that using 64bit for the random integer is enough to solve it? how about 32bit? or I have to use an infinite bit integer?
for example, in the basiccoin project:
the code for proof of work is the following:
def POW(block, hashes):
halfHash = tools.det_hash(block)
block[u'nonce'] = random.randint(0, 10000000000000000000000000000000000000000)
count = 0
while tools.det_hash({u'nonce': block['nonce'],
u'halfHash': halfHash}) > block['target']:
count += 1
block[u'nonce'] += 1
if count > hashes:
return {'error': False}
if restart_signal.is_set():
restart_signal.clear()
return {'solution_found': True}
''' for testing sudden loss in hashpower from miners.
if block[u'length']>150:
else: time.sleep(0.01)
'''
return block
this code randoms a number between [0, 10000000000000000000000000000000000000000] as a start point, and then it just increases the value one by one:
block[u'nonce'] += 1
I'm not a python programmer, I don't know how python handles the type of the integer. there is no handling of integer overflow.
I'm trying to implement similar thing with c++, I don't know what kind of integer can guarantee a solution.
but how can you prove that the solution distribution of a block is even (uniform), so that you can indeed cover all hash results?
SHA256 is deterministic so if you rehash the txns it will always provide the same 256 hash.
The client nodes keep all the txn and the hashes in the merkle tree for the network clients to propagate and verify the longest possible block chain.
The merkle tree is the essential data structure for recording the hashes of previous blocks.
From there the chain of hash confirmations can be tracked from the origin (genesis) block.
A Measured value consists of (typically nonnegative) floating-point number and unit-of-measure. The point is to represent real-world quantities, and the rules that govern them. Here's an example:
scala> val oneinch = Measure(1.0, INCH)
oneinch : Measure[INCH] = Measure(1.0)
scala> val twoinch = Measure(2.0, INCH)
twoinch : Measure[INCH] = Measure(2.0)
scala> val onecm = Measure(1.0, CM)
onecm : Measure[CM] = Measure(1.0)
scala> oneinch + twoinch
res1: Measure[INCH] = Measure(3.0)
scala> oneinch + onecm
res2: Measure[INCH] = Measure(1.787401575)
scala> onecm * onecm
res3: Measure[CMSQ] = Measure(1.0)
scala> onecm * oneinch
res4: Measure[CMSQ] = Measure(2.54)
scala> oncem * Measure(1.0, LITER)
console>:7: error: conformance mismatch
scala> oneinch * 2 == twoinch
res5: Boolean = true
Before you get too excited, I haven't implemented this, I just dummied up a REPL session. I'm not even sure of the syntax, I just want to be able to handle things like adding Measured quantities (even with mixed units), multiplying Measured quantities, and so on, and ideally, I like Scala's vaunted type-system to guarantee at compile-time that expressions make sense.
My questions:
Is there extant terminology for this problem?
Has this already been done in Scala?
If not, how would I represent concepts like "length" and "length measured in meters"?
Has this been done in some other language?
A $330-million Mars probe was lost because the contractor was using yards and pounds and NASA was using meters and newtons. A Measure library would have prevented the crash.
F# has support for it, see for example this link for an introduction. There has been some work done in Scala on Units, for example here and here. There is a Scala compiler plugin as well, as described in this blog post. I briefly tried to install it, but using Scala 2.8.1, I got an exception when I started up the REPL, so I'm not sure whether this plugin is actively maintained at the moment.
Well, this functionality exists in Java, meaning you can use it directly in Scala.
jsr-275, which was moved to google code. jscience implements the spec. Here's a good introduction. If you want a better interface, I'd use this as a base and build a wrapper around it.
Your question is fully answered with one word. You can thank me later.
FRINK. http://futureboy.us/frinkdocs/
FYI, I have developed a Scalar class in Scala to represent physical units. I am currently using it for my R&D work in air traffic control, and it is working well for me. It does not check for unit consistency at compile time, but it checks at run time. I have a unique scheme for easily substituting it with basic numeric types for efficiency after the application is tested. You can find the code and the user guide at
http://russp.us/scalar-scala.htm
Here is the summary from the website:
Summary-- A Scala class was designed to represent physical scalars and to eliminate errors involving implicit physical units (e.g., confusing radians and degrees). The standard arithmetic operators are overloaded to provide syntax identical to that for basic numeric types. The Scalar class itself does not define any units but is part of a package that includes a complete implementation of the standard metric system of units and many common non-metric units. The scalar package also allows the user to define a specialized or reduced set of physical units for any particular application or domain. Once an application has been developed and tested, the Scalar class can be switched off at compile time to achieve the execution efficiency of operations on basic numeric types, which are an order of magnitude faster. The scalar class can also be used for discrete units to enforce type checking of integer counts, thereby enhancing the static type checking of Scala with additional dynamic type checking.
Let me clarify my previous post. I should have said, "These kinds of errors ["meter/yard conversion errors"] are automatically AVOIDED (not "handled") by simply using my Scalar class. All unit conversions are done automatically. That's the easy part.
The harder part is the checking for unit inconsistencies, such as adding a length to a velocity. This is where the issue of dynamic vs. static type checking comes up. I agree that static checking is generally preferable, but only if it can be done without sacrificing usability and convenience.
I have seen at least two "projects" for static checking of units, but I have never heard of anyone actually using them for real work. If someone knows of a case where they were used, please let me know. Until you use software for real work, you don't know what sorts of issues will come up.
As I wrote above, I am currently using my Scalar class (http://russp.us/scalar-scala.htm) for my R&D work in ATC. I've had to make many tweaks along the way for usability and convenience, but it is working well for me. I would be willing to consider a static units implementation if a proven one comes along, but for now I feel that I have essentially 99% of the value of such a thing. Hey, the vast majority of scientists and engineers just use "Doubles," so cut me some slack!
"Yeah, ATC software with run-time type checking? I can see headlines now: "Flight 34 Brought Down By Meter/Yard Conversion"."
Sorry, but you don't know what you're talking about. ATC software is tested for years before it is deployed. That is enough time to catch unit inconsistency errors.
More importantly, meter/yard conversions are not even an issue here. These kinds of errors are automatically handled simply by using my Scalar class. For those kinds of errors, you need neither static nor dynamic checking. The issue of static vs. dynamic checking comes up only for unit inconsistencies, as in adding length to time. These kinds of errors are less common and are typically caught with dynamic checking on the first test run.
By the way, the interface here is terrible.