From my understanding, the modal quantifier possibly relaxes the behaviour of logical conjunction:
(true) and (possibly false) => true
(true) and (possibly unknown) => true
(possibly true) and (possibly false) => true
(possibly true) and (possibly unknown) => true
(necessarily true) and (possibly false) => true
(necessarily true) and (possibly unknown) => true
(unknown) and (possibly false) => unknown
(possibly unknown) and (possibly false) => unknown
(necessarily unknown) and (possibly false) => unknown
My question is: does it have any specific impact on other operations (like exclusive disjunction, implication and equivalence)? What about these examples (which can't figure out myself):
(true) xor (possibly true) => true | false ?
(true) xor (possibly unknown) => true | unknown ?
Related
I am missing something obvious, but I can't see it
export const subjectSelector: MemoizedSelector<
any,
Subject[]
> = new EntitySelectorsFactory().create<Subject>('subject').selectEntities;
this.store.pipe(
select(entitySelectors.subjectSelector),
map((s:Subject) => return {...s, z: {}}),
filter((subject:Subject) => subject.z.evidence && subject.z.evidence.length > 0)
);
select(entitySelectors.subjectSelector) is returning an array of Subject objects, but the compiler complains
Type 'Subject' is missing the following properties from type 'Subject[]': length, pop, push, concat, and 28 more.
map((s:Subject) => return {...s, z: {}}),
What am I missing?
Seems like you are confusing list and Observable map() function. This works for me assuming selectEntities returns the Ngrx Entity type Dictionary. The Parenthteses are hell though:
this.store.pipe(select(subjectSelector),
map((subjects: Dictionary<Subject>) => Object.values(subjects).map(s => ({...s, z: {}}))));
if 'subjects' is just a plain array, this will do:
this.store.pipe(select(subjectSelector),
map((subjects: Subject[]) => subjects.map(s => ({...s, z: {}}))));
Is there a way to achieve some kind of recursively-typed functions in Ceylon? For example, I can define combinatory logic in Ceylon in a type-safe way like so:
class Fi(shared Fi(Fi) o) { }
Fi veritas =
Fi((Fi t) =>
Fi((Fi f) =>
t));
Fi perfidas =
Fi((Fi t) =>
Fi((Fi f) =>
f));
Fi si =
Fi((Fi l) =>
Fi((Fi m) =>
Fi((Fi n) =>
l.o(m).o(n))));
print(si.o(veritas).o(veritas).o(perfidas) == veritas);
print(si.o(perfidas).o(veritas).o(perfidas) == perfidas);
print(si.o(veritas).o(perfidas).o(veritas) == perfidas);
print(si.o(perfidas).o(perfidas).o(veritas) == veritas);
This code works as intended. However, for clarity, brevity, and applicability to other problems, I would like to be able to do implement this behavior using only functions. Take something like the following (non-working) example:
alias Fi => Fi(Fi);
Fi veritas(Fi t)(Fi f) => t;
Fi perfidas(Fi t)(Fi f) => f;
Fi si(Fi l)(Fi m)(Fi n) => l(m)(n);
print(si(veritas)(veritas)(perfidas) == veritas);
print(si(perfidas)(veritas)(perfidas) == perfidas);
print(si(veritas)(perfidas)(veritas) == perfidas);
print(si(perfidas)(perfidas)(veritas) == veritas);
In the function alias version, the Fi type represents functions whose operands and return values can be composed indefinitely. Note that due to their recursive nature, the types Fi, Fi(Fi), and Fi(Fi)(Fi) could be considered functionally equivalent; all that the consumer of any of them knows is that if they have a function that, if called on a Fi, will given them another Fi.
Here is my understanding of what Ceylon currently supports:
Recursive aliases are not supported due to being erased during compilation.
I am unaware of any current Ceylon feature that could be used to specialize the Callable type recursively or otherwise get the needed kind of infinite chaining.
A possibly related question got a negative response. However, that was two and a half years ago, before some potentially related features like type functions were implemented in Ceylon 1.2 and a pair of blogs written by Gavin King on new type function support.
There is a github issue on higher order generics.
There is another github issue on allowing custom implementations of Callable.
Can the desired behavior be implemented in the current version of Ceylon? Or would it definitely require one or both of the aforementioned backlog features?
I'm working my way through the Data Science courses at DataCamp. (Not a plug.) One of the practice lessons has the following completed solution:
# logs is available in your workspace
extract_info <- function(x, property = "success", include_all = TRUE) {
info <- c()
for (log in x) {
if (include_all || !log$success) {
info <- c(info, log[[property]])
}
}
return(info)
}
# Call extract_info() on logs, no additional arguments
extract_info(logs)
# Call extract_info() on logs, set include_all to FALSE
extract_info(logs, include_all = FALSE)
The first call (extract_info(logs)) works as I would expect it to: it returns a vector containing all the log entries (regardless of the value of log$success).
The second call (extract_info(logs, include_all = FALSE)) does not return the results I would expect. It returns a vector containing only those results where log$success evaluates to FALSE.
It seems to me that the use of the || operator should cause the if block to short-circuit, and the second call should return nothing. From what I can tell, R evaluates expressions from left to right; but this looks like it's evaluating from right to left.
Can someone explain what's going on here?
(According to the site, this is the correct solution, and there's nothing wrong with the code. I want to know why it works the way it does. Even if the answer is that I'm overlooking something painfully obvious and stupid.)
Well || is the "or" operator. You don't short circuit the "or" operator with a FALSE value; you basically ignore that parameter and just look at the next one because you are looking for any TRUE value.
Assume a is a boolean value. These should be equivalent (<==>).
# or
FALSE || a <==> a
TRUE || a <==> TRUE
# and
TRUE && a <==> a
FALSE && a <==> FALSE
It seems like this was a temporary confusion.
|| is OR and so if either condition evaluates to TRUE, the compound expression evaluates to TRUE. If include_all was TRUE, you could short-circuit the expression, but when include_all is FALSE, you must wait to see what the other part is.
I am using PhpExcel 1.8.0 and I have faced with the problem. PhpExcel can't calculate formula OFFSET() with 4 arguments:
"Price Sheet!A27 -> Program Settings!H2 -> Formula Error: Wrong number
of arguments for OFFSET() function: 4 given, either 3 or 5 expected"
But in description of this formula i have found that this argument "width"
is optional:
"It is the number of columns that you want the returned range to be.
If this parameter is omitted, it is assumed to be the width of range."
Can someone tell me how to fix this problem?
Open the file Classes/PHPExcel/Calculation.php and find the entry in the $PHPExcelFunctions array for OFFSET which looks like:
'OFFSET' => array(
'category' => PHPExcel_Calculation_Function::CATEGORY_LOOKUP_AND_REFERENCE,
'functionCall' => 'PHPExcel_Calculation_LookupRef::OFFSET',
'argumentCount' => '3,5',
'passCellReference' => true,
'passByReference' => array(true)
),
and change the argumentCount block to
'argumentCount' => '3-5',
This represents what I want, but which doesn't work:
syntax
"_F_hex" :: "any => any" ("F;")
translations
"F;" => "True,True,True,True"
I would use F; like this:
[F;,F;] == [True,True,True,True,True,True,True,True]
Isabelle must be able to parse the right-hand side of a translation, but True,True,... does not yield a valid syntax tree. If you use F; only in list enumerations, you can extend the syntax translation rules for list enumerations as follows.
syntax "_F_hex" :: "logic" ("F;")
translations
"[F;, xs]" => "CONST True # CONST True # CONST True # CONST True # [xs]"
"[F;]" => "CONST True # CONST True # CONST True # CONST True # []"
Note that _F_hex does not take any argument, so its "type" is logic (and not something of the form _ => _) which stands for a parse tree node for a term. In the translations, you have to mark constants in the logic such as True with CONST. Otherwise, Isabelle would treat True as a variable.