When adding windows to mirador, they are displayed in a mosaic of increasingly small images. For example here with three windows.
The windows are draggable and resizable, but I would like to have directly this sort of display:
In mirador 2 I have seen a slotAddress option. Is there a way to do that as well with mirador 3?
This is an example with three images but there could be up to 6 or 7, I don't know that in advance.
EDIT
I have found an example here where the workspace layout is customized. I would have to adapt it depending on the actual number of windows. Where do the first/second options come from? Does it need to be a combination of first and second? Can I had 'third' or 'fourth' for instance?? Any help welcome!
workspace: {
layout: {
direction: "row",
first: {
first: "a",
second: "d",
direction: "column"
},
second: {
first: {
first: "b",
second: "e",
direction: "column"
},
second: {
first: "c",
second: "f",
direction: "column"
},
direction: "row"
},
splitPercentage: 33.33
}
}
The Mirador 3 layout is a binary tree data structure, allowing for a powerful way to customize the layout. first and second just references to the nodes in the branch of the tree, and the ordering implied by first/second is used with the split percentage.
These types are defined upstream in https://github.com/nomcopter/react-mosaic/blob/master/src/types.ts#L12
There is no concept of third/fourth here. To achieve the layout you are looking for you would want to represent the the equal column widths as a binary tree structure like this:
Example 6 columns
"layout": {
"first": {
"first": "a",
"second": "b",
"direction": "row"
},
"second": {
"first": "c",
"second": {
"first": "d",
"second": {
"first": "e",
"second": "f",
"direction": "row",
"splitPercentage": 50 // Last two nodes split the remaining space (note this is not required as 50 is the default)
},
"direction": "row",
"splitPercentage": 33.33 // First node (d) gets 1/3 of remaining space
},
"direction": "row",
"splitPercentage": 25 // First node (c) gets 1/4 of remaining space
},
"direction": "row",
"splitPercentage": 33.33 // First node (a + b windows) gets 1/3 of layout space for two columns (1/3 of total columns)
}
Related
I'm trying to write a Mongodb aggregation that do the following:
I have two collections, where there are two fields that apear in both collections, and I want to write a query that adds based on wether both of the fields are equal in both collections, a field that exists only in one of them.
Say that the first collection is A and the second is B. Say that these are the fields in both of them:
A: x, y, z, w.
B: x, y, u.
I want to add u to A, based on where x, y are both the same in A and B.
if this is a record in A: x=1, y=2, z=3, w=4 and B: x=1, y=2, u=6, I want:
A: x=1, y=2, z=3, w=4, u=6. (because x, y are equal in both collections).
I wrote the following:
db.A.aggregate([
{
"$lookup":{
"from":"B",
"let":{
"x":"$x",
"y":"$y"
},
"pipeline":[
{
"$match":{
"$expr":{
"$and":[
{
"$eq":[
"$x",
"$$x"
]
},
{
"$eq":[
"$y",
"$$y"
]
}
]
}
}
}
],
"as":"res"
}
}
])
I need to add a project part, but the problem is that i get the following error (means res is not working):
"message" : "arguments to $lookup must be strings, let: { x: '$x', y: '$y' } is type object"
and code 4570
Notes:
I use mongo version 4.4.5
x in my db is of type string and y is of type int32. I tried to convert y to string, this is not the problem.
If someone knows how to help I would appreciate that.
What are the differences between an item of type #table and a list of type #record in powerQuery? For example:
data = {
[id=1, name="tom"],
[id=2, name="sarah]
}
And:
data = #table(
{"id", "name"},
{
{1, "tom"},
{2, "sarah"}
},
)
Are they two ways to write the same thing, or should one be used over the other in certain cases?
The main difference is table may require strict data types, and only includes records, while list of records can also include values of other types, such as numbers or characters.
Your example can have column types defined in advance:
data = #table(
type table [id=Int64.Type, name=Text.Type],
{
{1, "tom"},
{2, "sarah"}
},
)
As opposite to a list:
data = {
[id=1, name="tom"],
[id=2, name="sarah"],
1,
"a"
}
I'll try to present the problem as generally as I can, and a response in any language will do.
Suppose there are a few sets of varying sizes, each containing arbitrary values to do with a category:
var colors = ["red", "yellow", "blue"] // 3 items
var letters = ["A", "B", "C", ... ] // 26 items
var digits = [0, 1, 2, 3, 4, ... ] // 10 items
... // each set has fixed amount of items
Each object in this master list I already have (which I want to restructure somehow to optimize searching) has properties that are each a selection of one of these sets, as such:
var masterList = [
{ id: 1, color: "red", letter: "F", digit: 5, ... },
{ id: 2, color: "blue", letter: "Q", digit: 0, ... },
{ id: 3, color: "red", letter: "Z", digit: 3, ... },
...
]
The purpose of the search would be to create a new list of acceptable objects from the master list. The program would filter the master list by given search criteria that, for each property, contains a list of acceptable values.
var criteria = {
color: ["red", "yellow"],
letter: ["A", "F", "P"],
digit: [1, 3, 5],
...
};
I'd like to think that some sort of tree would be most applicable. My understanding is that it would need to be balanced, so the root node would be the "median" object. I suppose each level would be defined by one of the properties so that as the program searches from the root, it would only continue down the branches that fit the search criteria, each time eliminating the objects that don't fit given the particular property for that level.
However, I understand that many of the objects in this master list will have matching property values. This connects them in a graphical manner that could perhaps be conducive to a speedy search.
My current search algorithm is fairly intuitive and can be done with just the master list as it is. The program
iterates through the properties in the search criteria,
with each property iterates over the master list, eliminating a number of objects that don't have a matching property, and
eventually removes all the objects that don't fit the criteria. There is surely some quicker filtering system that involves a more organized data structure.
Where could I go from here? I'm open to a local database instead of another data structure I suppose - GraphQL looks interesting. This is my first Stack Overflow question, so my apologies for any bad manners 😶
As I don't have the context of number of sets and also on the number of elements in the each set. I would suggest you some very small changes which will make things at-least relatively fast for you.
To keep things mathematical, I will define few terms here:
number of sets - n
size of masterlist - k
size of each property in the search criteria - p
So, from the algorithm that I believe you are using, you are doing n iterations over the search criteria, because there can be n possible keys in the search criteria.
Then in each of these n iterations, you are doing p iterations over the allowed values of that particular set. Finally, in each of these np iterations you are iterating over the master list, with k iterations ,and checking if this value of record should be allowed or not.
Thus, in the average case, you are doing this in O(npk) time complexity.
So, I won't suggest to change much here.
The best you can do is, change the values in the search criteria to a set (hashset) instead of keeping it as a list, and then iterate over the masterlist. Follow this Python code:
def is_possible(criteria, master_list_entry):
for key, value in master_list_entry.items(): # O(n)
if not key in criteria or value not in criteria[key]: # O(1) average
return False
return True
def search(master_list, criteria):
ans = []
for each_entry in master_list: # O(k)
if is_possible(criteria, each_entry): # O(n), check above
ans.append(each_entry)
return ans
Just call search function, and it will return the filtered masterlist.
Regarding the change, change your search criteria to:
criteria = {
color: {"red", "yellow"}, # This is a set, instead of a list
letter: {"A", "F", "P"},
digit: {1, 3, 5},
...
}
As, you can see, I have mentioned the complexities along with each line, thus we have reduced the problem to O(nk) in average case.
I have been trying to get this dynamic query to work with dates as shown below in ArangoDB 3.1.
This works perfectly when I'm not trying to query dates, but returns an empty list as soon as I try to query with a date like below...
{
query:
'For c IN ##collectionName
FILTER ( c.#p0 == #v0 AND c.#p1 >= #v1 AND c.#p2 <= #v2 )
LIMIT #count RETURN c ',
bindVars: {
'#collectionName': 'Event',
p0: 'isPublished',
v0: true,
p1: 'dates[*].startsAt',
v1: '2018-06-01T04:00:00.000Z',
p2: 'dates[*].startsAt',
v2: '2018-07-01T03:59:59.999Z',
count: 9
}
}
Need some help getting past this
There are mistakes in your query, but they are actually not related to dates:
dates[*].startsAt is not a valid attribute path, but a shorthand expression for FOR date IN dates RETURN date.startsAt, which returns an array
The comparison operator >= does not work on arrays as you may think. null, true, false and every number and string are less than any array, see Type and Value Order. Your timestamp array will always be greater than any given timestamp string. What you probably want instead is an array comparison operator like ALL >=.
An expression dates[*].startsAt can not be used as bind parameter. With a document structure without array like { "date": { "startsAt": "..." } } it would be perfectly fine to bind ["date", "startsAt"] as p1 or p2. Note how the bind parameter value is an array of strings. "date.startsAt" on the other hand would describe the path for a top-level attribute
{ "date.startsAt": ... } and not a nested attribute startsAt of the top-level attribute date like { "date": { "startsAt": ... } }.
What your do with dates[*].startsAt is describing a top-level attribute like
{ "dates[*].startsAt": ... }, which does not exist. ["dates[*]", "startsAt"] does not work either. If you want to use the array expansion expression, then you have to write it like c.#p1a[*].#p1b in your query and use the bind parameters { "p1a": "dates", "p2a": "startsAt" }.
Query:
FOR c IN ##collectionName
FILTER c.#p0 == #v0
FILTER c.#p1a[*].#p1b ALL >= #v1
FILTER c.#p2a[*].#p2b ALL < #v2
LIMIT #count
RETURN c
bindVars:
{
"#collectionName": "Event",
"p0": "isPublished",
"v0": true,
"p1a": "dates",
"p1b": "startsAt",
"v1": "2018-06-01T04:00:00.000Z",
"p2a": "dates",
"p2b": "startsAt",
"v2": "2018-07-01T04:00:00.000Z",
"count": 9
}
I wrote a small memory benchmark for node.js: http://pastebin.com/KfZ4Ucn4
It measures memory usage using process.memoryUsage().heapUsed for 3 cases:
Array of objects with 10 properties, different property names for each element
Array of objects with 10 properties, same property names
Array of objects with 10 properties, same property names, represented as an object of arrays
The overhead turns out to be 1300 bytes for Case 1, 300 bytes for Case 2 and 150 bytes for Case 3. Also only Case 1 garbage collects, while in latter cases memory usage doesn't go down.
Is there any explanation or documentation for these effects? I'm trying to optimize memory usage for an array of objects of objects, something like
[ {
foo : { bar : 1, baz : 2 }
, bar : { bar : 2, baz : 7 }
}
, {
foo : { bar : 1, baz : 2 }
, bar : { bar : 2, baz : 7 }
} ]
Any clues?
I'm guessing that this has to do with the way that V8 uses "hidden classes" to represent similar objects, but what you are reporting seems to be a pretty dramatic difference in footprints...
You can read more about hidden classes here: https://developers.google.com/v8/design
although that article seems to be more focused on speed than memory usage.