I have got a big audio file foo and a hash file h with h = sha256sum(foo);
Third parties can check the integrity of foo provided h is published somewhere.
I now want the third party only to have parts of foo. However they shall be able to verify these parts being a subset of (the unpublished) foo.
Generally speaking:
Considering File foo = foo0.concat(foo1).concat(foo2).....concat(fooN);
Exists a Function where func(sha256sum(foo)) == func(sha256sum(foo0),....,sha256(fooN)) ?
Related
After this
restart; about(x); assume(x>0); f:=3*x; x:='x': about(x);
Originally x, renamed x~:
is assumed to be: RealRange(Open(0),infinity)
f := 3*x~
x:
nothing known about this object
I can use indets to access the variable x (looks like it's still x~ in f), for example
eval(f,indets(f)[1]=2);
6
but it's not efficient when f has many variables. I've tried to access variable x (or x~) directly, but it didn't work:
eval(f,x=2);
eval(f,x~=2);
eval(f,'x'=2);
eval(f,'x~'=2);
eval(f,`x`=2);
eval(f,`x~`=2);
eval(f,cat(x,`~`)=2);
since the result in all those cases was 3*x~ (not 6).
Is there a way to access a specific variable directly (i.e. without using indets) after its assumptions are cleared?
There is no direct way, if utilizing assume, without programatically extracting/converting/replacing the assumed names in the previously assigned expression.
You can store the (assumed) name in another variable, and utilize that -- even after unassigning x.
Or you can pick off the names (including previously assumed names) from f using indets -- even after unassigning x.
But both of those are awkward, and it gets more cumbersome if there are many such names.
That is one reason why some people prefer to utilize assuming instead of the assume facility.
You can construct lists/sets/sequences of the relevant assumptions, and then re-utilize those in multiple assuming instances. But the global names are otherwise left alone, and your problematic mismatch situation avoided.
Another alternative is to utilize the command Physics:-assume instead of assume.
Here's an example. Notice that the assumption that x is positive still allows some simplification that depend upon it.
restart;
Physics:-Assume(x>0);
{x::(RealRange(Open(0),
infinity))}
about(x);
Originally x, renamed x:
is assumed to be:
RealRange(Open(0),infinity)
f:=3*x;
f := 3 x
simplify(sqrt(x^2));
x
Physics:-Assume('clear'={x});
{}
about(x);
x:
nothing known about this object
eval(f, [x=2]);
6
As for handling the original example utilizing assume, and substituting in f for the (still present, assumed names), it can be done programmatically to alleviate some awkwardness with, say, a larger set of assumptions. For example,
restart;
# re-usable utility
K:=(e,p)->eval(e,
eval(map(nm->nm=parse(sprintf("%a",nm)),
indets(e,And(name,
satisfies(hasassumptions)))),
p)):
assume(x>0, y>0, t<z);
f:=3*x;
f := 3 x
g:=3*x+y-sin(t);
g := 3 x + y - sin(t)
x:='x': y:='y': t:='t':
K(f,[x=2]);
6
K(g,[x=2,y=sqrt(2),t=11]);
(1/2)
6 + 2 - sin(11)
It's a common methodology to keep assertions, cover points, etc. separate from the design by putting them in a separate module or interface, and use bind to attach them to the design, e.g.,
module foo (input a);
wire b = a;
endmodule
interface foo_assertions (input a, b);
initial #1 assert (b == a);
endinterface
bind foo foo_assertions i_foo_assertions(.*);
One problem with this is that it requires maintenance of the port list in foo_assertions. However, if foo has a bar submodule, signals inside bar can be accessed conveniently using hierarchical references in the assertions file relative to foo, e.g., assert (i_bar.sig == a).
Is there a way to use the hierarchical path syntax for accessing variables declared directly in foo as well, eliminating the need for the port list in foo_assertions? Note that foo is not necessarily the top-level module, so $root.b will not work. It looks like foo.b works, however is this safe when multiple instances of foo exist at the top level?
Verilog has always had upwards name referencing which is why foo.b works (See section 23.8 in the IEEE 1800-2017 SystemVerilog LRM). It does not matter how many instances of foo there are, as long as you only bind foo_assertions into a module named foo. Each upward reference applies to the specific instance that reference is underneath.
When referring to the top-level module in a hierarchical path, you have been using an upwards reference without necessarily realizing it.
what I am looking for
Let T be an OCaml data type, (example: type t = A | B of int), and x be a value of type T, is there a function f that satisfies the following requirements:
f maps x to a string, i.e. f(x) is a string representation of x
for all u, v in T, u = v if and only if f(u) = f(v)
f can be derived automatically, like type t = ... [##deriving yojson]
the string representation of a value of a relatively simple type, like the one defined above, should be human editable
(not essential, but nice to have) locality, i.e., if you extend the type t above to type t = A | B of int | C of something, then f("A the one before the extending") should be equal to f("A the one after the extending"), in another word, it should make upgrading an old version of a type to the new version easy
why I want this
Store an OCaml data into Postgres column. I have a small web app that uses PGOCaml to fetch data from Postgres, and PGOCaml type checks the SQL statement at compile time, so if you create domain some_type as text in Postgres, and change the source code of PGOCaml a bit (to use the above f to convert a Postgres text into an OCaml type), you can store ADT into a Postgres table, while maintain type safety.
The second point in the requirements is important, for on the Postgres side, you likely need to test for equality on that column, and such tests are done on Postgres text type.
I looked into Sexp, didn't find information about the second point.
PS, new to OCaml, does this kind of thing already have a mature solution?
Update
I end up using yojson, since my type is very simple, just nullary variants, I can get away with it, it's a galaxy away from perfect though.
Update 2
For those who has the similar problem, I think the current best solution is to use yojson, and instead of storing it in a text column, storing it in a jsonb, this way, you get white space and order insensitive comparison, (though I cannot find pg's documentation on the equality of jsonb type).
Upgrading RichouHunters comment to an answere as I think Sexplib is a good module for this:
I think the way s-expressions may (or may not) satisfy your second requirement will depend a lot on your type T and on the way you define the serializer. You'll find more about them (and Sexplib) here.
A "lens" and a "partial lens" seem rather similar in name and in concept. How do they differ? In what circumstances do I need to use one or the other?
Tagging Scala and Haskell, but I'd welcome explanations related to any functional language that has a lens library.
To describe partial lenses—which I will henceforth call, according to the Haskell lens nomenclature, prisms (excepting that they're not! See the comment by Ørjan)—I'd like to begin by taking a different look at lenses themselves.
A lens Lens s a indicates that given an s we can "focus" on a subcomponent of s at type a, viewing it, replacing it, and (if we use the lens family variation Lens s t a b) even changing its type.
One way to look at this is that Lens s a witnesses an isomorphism, an equivalence, between s and the tuple type (r, a) for some unknown type r.
Lens s a ====== exists r . s ~ (r, a)
This gives us what we need since we can pull the a out, replace it, and then run things back through the equivalence backward to get a new s with out updated a.
Now let's take a minute to refresh our high school algebra via algebraic data types. Two key operations in ADTs are multiplication and summation. We write the type a * b when we have a type consisting of items which have both an a and a b and we write a + b when we have a type consisting of items which are either a or b.
In Haskell we write a * b as (a, b), the tuple type. We write a + b as Either a b, the either type.
Products represent bundling data together, sums represent bundling options together. Products can represent the idea of having many things only one of which you'd like to choose (at a time) whereas sums represent the idea of failure because you were hoping to take one option (on the left side, say) but instead had to settle for the other one (along the right).
Finally, sums and products are categorical duals. They fit together and having one without the other, as most PLs do, puts you in an awkward place.
So let's take a look at what happens when we dualize (part of) our lens formulation above.
exists r . s ~ (r + a)
This is a declaration that s is either a type a or some other thing r. We've got a lens-like thing that embodies the notion of option (and of failure) deep at it's core.
This is exactly a prism (or partial lens)
Prism s a ====== exists r . s ~ (r + a)
exists r . s ~ Either r a
So how does this work concerning some simple examples?
Well, consider the prism which "unconses" a list:
uncons :: Prism [a] (a, [a])
it's equivalent to this
head :: exists r . [a] ~ (r + (a, [a]))
and it's relatively obvious what r entails here: total failure since we have an empty list!
To substantiate the type a ~ b we need to write a way to transform an a into a b and a b into an a such that they invert one another. Let's write that in order to describe our prism via the mythological function
prism :: (s ~ exists r . Either r a) -> Prism s a
uncons = prism (iso fwd bck) where
fwd [] = Left () -- failure!
fwd (a:as) = Right (a, as)
bck (Left ()) = []
bck (Right (a, as)) = a:as
This demonstrates how to use this equivalence (at least in principle) to create prisms and also suggests that they ought to feel really natural whenever we're working with sum-like types such as lists.
A lens is a "functional reference" that allows you to extract and/or update a generalized "field" in a larger value. For an ordinary, non-partial lens that field is always required to be there, for any value of the containing type. This presents a problem if you want to look at something like a "field" which might not always be there. For example, in the case of "the nth element of a list" (as listed in the Scalaz documentation #ChrisMartin pasted), the list might be too short.
Thus, a "partial lens" generalizes a lens to the case where a field may or may not always be present in a larger value.
There are at least three things in the Haskell lens library that you could think of as "partial lenses", none of which corresponds exactly to the Scala version:
An ordinary Lens whose "field" is a Maybe type.
A Prism, as described by #J.Abrahamson.
A Traversal.
They all have their uses, but the first two are too restricted to include all cases, while Traversals are "too general". Of the three, only Traversals support the "nth element of list" example.
For the "Lens giving a Maybe-wrapped value" version, what breaks is the lens laws: to have a proper lens, you should be able to set it to Nothing to remove the optional field, then set it back to what it was, and then get back the same value. This works fine for a Map say (and Control.Lens.At.at gives such a lens for Map-like containers), but not for a list, where deleting e.g. the 0th element cannot avoid disturbing the later ones.
A Prism is in a sense a generalization of a constructor (approximately case class in Scala) rather than a field. As such the "field" it gives when present should contain all the information to regenerate the whole structure (which you can do with the review function.)
A Traversal can do "nth element of a list" just fine, in fact there are at least two different functions ix and element that both work for this (but generalize slightly differently to other containers).
Thanks to the typeclass magic of lens, any Prism or Lens automatically works as a Traversal, while a Lens giving a Maybe-wrapped optional field can be turned into a Traversal of a plain optional field by composing with traverse.
However, a Traversal is in some sense too general, because it is not restricted to a single field: A Traversal can have any number of "target" fields. E.g.
elements odd
is a Traversal that will happily go through all the odd-indexed elements of a list, updating and/or extracting information from them all.
In theory, you could define a fourth variant (the "affine traversals" #J.Abrahamson mentions) that I think might correspond more closely to Scala's version, but due to a technical reason outside the lens library itself they would not fit well with the rest of the library - you would have to explicitly convert such a "partial lens" to use some of the Traversal operations with it.
Also, it would not buy you much over ordinary Traversals, since there's e.g. a simple operator (^?) to extract just the first element traversed.
(As far as I can see, the technical reason is that the Pointed typeclass which would be needed to define an "affine traversal" is not a superclass of Applicative, which ordinary Traversals use.)
Scalaz documentation
Below are the scaladocs for Scalaz's LensFamily and PLensFamily, with emphasis added on the diffs.
Lens:
A Lens Family, offering a purely functional means to access and retrieve a field transitioning from type B1 to type B2 in a record simultaneously transitioning from type A1 to type A2. scalaz.Lens is a convenient alias for when A1 =:= A2, and B1 =:= B2.
The term "field" should not be interpreted restrictively to mean a member of a class. For example, a lens family can address membership of a Set.
Partial lens:
Partial Lens Families, offering a purely functional means to access and retrieve an optional field transitioning from type B1 to type B2 in a record that is simultaneously transitioning from type A1 to type A2. scalaz.PLens is a convenient alias for when A1 =:= A2, and B1 =:= B2.
The term "field" should not be interpreted restrictively to mean a member of a class. For example, a partial lens family can address the nth element of a List.
Notation
For those unfamiliar with scalaz, we should point out the symbolic type aliases:
type #>[A, B] = Lens[A, B]
type #?>[A, B] = PLens[A, B]
In infix notation, this means the type of a lens that retrieves a field of type B from a record of type A is expressed as A #> B, and a partial lens as A #?> B.
Argonaut
Argonaut (a JSON library) provides a lot of examples of partial lenses, because the schemaless nature of JSON means that attempting to retrieve something from an arbitrary JSON value always has the possibility of failure. Here are a few examples of lens-constructing functions from Argonaut:
def jArrayPL: Json #?> JsonArray — Retrieves a value only if the JSON value is an array
def jStringPL: Json #?> JsonString — Retrieves a value only if the JSON value is a string
def jsonObjectPL(f: JsonField): JsonObject #?> Json — Retrieves a value only if the JSON object has the field f
def jsonArrayPL(n: Int): JsonArray #?> Json — Retrieves a value only if the JSON array has an element at index n
consider the following situation:
I have a string s and hash function H generating the hash "h".
I send both s and h to another.
he sends back s and h back to me.
On the s and h received , I perform h'=H(s) and compare it with the h received , if they are identical that means the s i received on step 3 is exactly as i sent in step 2.
Is that correct?
If someone has h and s but does not has the H hash function, can he discover(or create) the H function?
thanks
Yes, if the hash is the same, both strings are the same, with the possible exception of a hash collision.
In general case it's not possible to reverse-engineer the hash function from the string and its hash value. Obviously, if the hash function is something common (SHA1), it's trivial for the “attacker” to try different standard hashing algorithms and see which one was used. But this can be fixed by hashing s together with some secret.