1

Topic: the cubic Concept.

Greetings friends.
There is a subject over which I think the last some weeks.
I will try not to be verbose (it is my jamb) and to throw snippets instead of set of letters.
1. creation (I Write in pseudo-language which can be C#/D/Rust/Java).

Cube cube = new MCube (2580,2580,2580).withStaticAllocation ();

2. filling by the facts . In this case the predicate isMutuallySimple is stated that by triple of numbers - mutually simple.

for (i in 0. 2599) for (j in 0. 2599) for (k in 0. 2599)
if (isMutuallySimple (i, j, k)) cube.set (i, j, k);

3. Cube check .

cube.check (7,9,16) == true

Gives true since 7 and 9 and 16 mutually simple. It simply example. In a predicate
There can be your business logic. Check of the physical-person. The enterprises. Technical-means.
.
Zadljanafiga. . The answer - I searched for analog data structures of type HashTable. A possible point - saving.
Digits. For a cube with the storage expenditure in 2Gbyte. (~17 179 869 184 boolean an element)
[CSV =;] Size; Dimensions
131072; 2
2580; 3
362; 4
Translating into our language. Storage of the fact table with three columns with cardinality
The order 2 and a half thousand demands in the worst case 2 .
Further - think. Estimate.
Where to apply. Hm... Initially I thought about  Hibernejt. A bit later the task became more the general. I began to think of favor of cubes.
Still points.
Digits it is not sad. The reference manual of a line - digits is necessary.
Dimensionality of a cube should be floppy. Well... At least it should not
To fall at access to an element with an index 2581 in our case. I think over
It.
The iterator. Actually it is possible to support. But there will be waybills. Think.
That does not lay down in cubic Real values. Dates. Time. Money.
That abruptly lays down in cubic Listings. Reference manuals.
Well  all.
Write .  while is not present.

2

Re: the cubic Concept.

I so understand too most it is possible to receive creating type

class my_type_t {
public:
int i, j, k;
}

To register in it necessary operator, and further to use standard containers. For example HashTable <my_type_t> or HashSet <my_type_t>
Or I something ?

3

Re: the cubic Concept.

mayton wrote:

Digits. For a cube with the storage expenditure in 2Gbyte. (~17 179 869 184 boolean an element)
[CSV =;] Size; Dimensions
131072; 2
2580; 3
362; 4
Translating into our language. Storage of the fact table with three columns with cardinality
The order 2 and a half thousand demands in the worst case 2 .

you  N-dimensional invented, the index from N-dimensional to one-dimensional here suffices to result and use as usual.
For example according to your example:

if (isMutuallySimple (i, j, k)) cube.set (i, j, k);

Equivalently

if (isMutuallySimple (i, j, k)) bitmap [i * 2580 * 2580 + j * 2580 + k] = true;

4

Re: the cubic Concept.

Yes. Truly. This task dares the hash-tablet but in my variant the data storage circuit spends 1 bit for each record.
Generally. It not cubic Generally it  a parallelepiped.

5

Re: the cubic Concept.

Dima T, I did not invent a multidimentional array. I think of that how to use all known structure for  string keys or type keys enum.

6

Re: the cubic Concept.

mayton wrote:

Dima T, I did not invent a multidimentional array.

it invented. More precisely multidimentional  invented, and it as a matter of fact a normal array, only an element of 1 bit.
I.e. as a result obtaining of an index of the necessary element will be reduced to its calculation by the same rules, as well as in multidimentional arrays.

mayton wrote:

I think of that how to use all known structure for  string keys or type keys enum.

enum it is perfectly inscribed in your system. They should be enumerated simply 0... N-1
Will worse be inscribed ID  by counters, but it is possible .
And with lines all is bad, personally I only one variant see: to store them in a separate array, and an index of this array to use in your cube. I think guessed that the problem will search a line for each time in an array.
I do not understand where it is possible to apply your invention? In terms  you invented check of composite primary key. Is/is not present.
As I understand as a result your task it is reduced to comparing of characteristics of the hash table and . Or to  still any storage with similar properties. If so then there is no the general-purpose decision, it is necessary to start with a specific case, i.e. statistics of usage of the specific data is necessary.

7

Re: the cubic Concept.

I will not insist on . It here is not present. I will try to recall that  with which started to think about .

8

Re: the cubic Concept.

The thing can be necessary. If it is not stupid  "a multidimentional array" - "one-dimensional", and what  structures intended for operation with the discharged data a la a compression on the fly.
If to look at a label mayton', becomes clear that at kol-ve > = 4, the elementary cube becomes well very small, for any tasks comprehended business.

9

Re: the cubic Concept.

It is better to start with the assumption what not all measurements equally big. The field gender will have 2 values male, female and it gives in storage easier doubling . But in any way on 2000 as I drew multiplication in an educational example.

10

Re: the cubic Concept.

To me it was necessary in due time certain similarity Subj. But not . And a cube of integer numbers.
There is a flight by the plane. There is a dial-up of its characteristics. It is necessary to select "optimal" from hundreds millions variants of flight
I.e. some kind of a cube, where measurements actually characteristics (the ticket price, flight time, kol-in changes, time of changes, day/night changes), value -  a certain estimation of "optimality" of the given variant.
Another matter that storage of all variants was not necessary for me. Simply at pass of calculations stored "100 best", everything that is certainly worse than these "best", at once discarded. If criteria of an estimation changed, launched search on the column repeatedly.
But if there was a possibility somewhere to add at least , probably it would be useful. But dimensionality at such cubes in real business tasks should be "wild" (in my case, probably,> 10 measurements).

11

Re: the cubic Concept.

Leonid Kudryavtsev;
. Interesting. And how much densely your cube was filled inside? Also there was any rank of its axes? Well the father-in-law. My variant of a cube assumes total absence of criteria of proximity of two facts.

12

Re: the cubic Concept.

mayton wrote:

Leonid Kudryavtsev;
. Interesting. And how much densely your cube was filled inside? Also there was any rank of its axes? Well the father-in-law. My variant of a cube assumes total absence of criteria of proximity of two facts.

Cube in storage as that was not (stored only 100 or even less values), the cube was "logical" during calculations.
The rank and criteria were, in it and there was a principal idea. A rank (weight) of separate characteristics changed depending on a choice of the user/interface (in  is not left, .. The design was so-so). Including, the weight could be made "0" or "much" then the system understood that all variants with this characteristic need or to be discarded as absolutely improper or, on the contrary, to try to search for variants with such characteristic.
The majority of characteristics have been presented as discrete values on certain measurement cubed. For example the price - it is simple with step in 10$ (the step dynamic changed, i.e. implementation was not so "", but idea exactly such), time - with step to 15 minutes, kol-in changes from 0 to 7 (have been found such routes where it is less than for 8 flights of "slices" not to reach!, competitors generally were not able/jut to find such routes).
A row of characteristics transferred as the list. For example the airports where change is carried out. .. Even requests of type "I do not want to fly through London", were fulfilled under the same circuit.
Actually following the results of, the criterion of proximity/range also turned out. Actually "close" variants "" (since dimensionality was discrete, the close variants simply got to one "cell" and there was the best), most "left/garbage" - were discarded, residual .

13

Re: the cubic Concept.

mayton wrote:

densely your cube was filled inside

Absolutely not densely.

14

Re: the cubic Concept.

Leonid Kudryavtsev;
Powerfully. It is similar to the transport task. But not in a plane and in volume.

15

Re: the cubic Concept.

mayton wrote:

Leonid Kudryavtsev;
Powerfully. It is similar to the transport task. But not in a plane and in volume.

Well in general the task also was ""
To find a route from A in B
The problem was in criteria. Since initially the task was put "cheapest", but on an operation course was clarified that "round-the-world flight with 5 changes within a week for 15$" is abruptly, but for the majority of the users, hardly the necessary thing)))
And criteria of an estimation became much

16

Re: the cubic Concept.

Leonid Kudryavtsev;
It is the simple task

17

Re: the cubic Concept.

It not simple in target function. Quickly and cheaply. It already a dial-up of mutually exclusive criteria. Also new target function is necessary.

18

Re: the cubic Concept.

mayton;
Quickly it is then cheap (cheapest of the fastest)
Cheaply then quickly (fastest of the cheapest)
Speed * w1 + cost * w2 (here it is necessary to pick up very well w1; w2)
At me also quality is added in the schedule (: the best are selected - the equipment, a material, staff from possible)

19

Re: the cubic Concept.

Throughout a cube subject. As generally there was a setting.
Case No1
Years a little back I optimized application. Big bank. A web. Management system HR.
There was . The circuit safety. A sheaf of tables many-to-much. Through the intermediate.

Entitlement <-> Entitlement2UiElement <-> UiElelement

Essence Entitilement it something like a role or the privilege in system. Or the horse-radish them knows groups of roles.
They are connected many-to-much. Further on a subject me can ask -  ... Why you did not make group.
I will answer that it and there are groups. Simply all is difficult.
Honor  was in operation. The part died. The part doubled other honor. Also were UI elements which
Had generally no possibility to be displayed. Not an essence. . It is a matrix. Technically Hibernejt solved this task.
There was Dao which derives the user then it  and then its graphic elements. But as
I -  that I thought of optimization ways.  - as a special case. As a matter of fact Dao should answer
On a question. Whether it is possible to display given ID UI an element for given  the given user.
I was not in time  the matrix decision. The project was completed. But it is convinced that  on the basis of a hyper-cube
It was successful. Conditions - were favorable. Politicians  changed rarely. Time a day the system was overloaded.
even without control of updates  it was effective.
Case No2
The table with Boolean attributes. The following setting - is not real and reconsideration is faster.
There is a class of tasks where DB indexes - are ineffective. For example physical-persons and some attributes.
ID,Name,Gender,IsClient,CreditWorthy,Adult,DrawnToCriminal,DrivingACar,WasAbroad,SocialClass
0, mayton, male, n, n, n, n, n, n, Extra
1, Dima, male, y, y, y, y, y, n, Classic
2, Leonid, male, y, n, y, n, y, n, Extra
,,,,,;
The 9-dimensional cube with non-uniform cardinality takes place. In 9-dimensional space is
Drawn out "" where the greatest dimensionality corresponds ID the user. Further - a class
Sots-insurance (there can be 10-20 records in the reference manual a horse-radish knows how many but explicitly less
Than clients). Remaining attributes - two-dimensional. Despite apparent
And complexity of representation -  . Also stores all information volume enough
It is easy. As I already spoke the given data structure badly supports the iterator yes to us and it is not necessary.
Fact extraction.  check for example that that Mejton was not we judge and was not abroad
Occupies - microseconds and the moderate volume of resources lays down.
Technically the DB solves this task by creation special bitmap-indexes.
But (we know that) that they are effective only R/O and in aggregate with sampling on another
To signs.  a DB - not . B-trees badly work with sampling of low cardinality.
Here it is possible to theorize long but as the fact - take big ( billion records)
The table also try  set of signs. Running forward I will tell
That I know one more workaround type of facet search - but a subject not about it. A subject - cubes
And low cardinality. We can unless-that disperse in  estimations.
To whom 10 - low. And to whom and 100 thousand. . Think.
I am sorry for a certain stiffness and synthetical character of setting but I expect further
Sentences on usage from you. From  a forum.

20

Re: the cubic Concept.

As I understand in both cases the task it is reduced to check of some properties of specific object, and the property set at each object is identical.
It is possible to reduce instead of many-to-much to one table: {id, name, attr1, attr2, attr3...}, actually the second example so is shown. On-essence it normal .
With a view of storage saving it is possible to go further, to replace {attr1, attr2, attr3...} on bit representation, i.e.  + structure declaration, for example attr1 - 0 bit, attr2 - 1 etc. For attributes not holding in one bit it is possible to select a little.
As a result it is received that it is necessary to cache {id, bitmap}, i.e. for the organization of a cache enough the associative array.

21

Re: the cubic Concept.

In general I to that that it is necessary to store a cache in a type: one object - one  with its properties.

22

Re: the cubic Concept.

mayton wrote:

Technically the DB solves this task by creation special bitmap-indexes.
But (we know that) that they are effective only R/O and in aggregate with sampling on another
To signs.  a DB - not . B-trees badly work with sampling of low cardinality.
Here it is possible to theorize long but as the fact - take big ( billion records)
The table also try  set of signs. Running forward I will tell
That I know one more workaround type of facet search - but a subject not about it. A subject - cubes
And low cardinality. We can unless-that disperse in  estimations.
To whom 10 - low. And to whom and 100 thousand. . Think.

As I understand here you you argue over the reverse task: to find object () on properties if so that there was such a topic

23

Re: the cubic Concept.

I would not want to drag here facet search. Its setting another. We find set of the goods of properties possessing a set.
And the cube simply checks that there is 1 such business the fact. And all.

24

Re: the cubic Concept.

To consider all night long in a DBMS, and to ask questions in the morning and to receive answers. If to count on the fly, in a DB it can be constant actual :-D

25

Re: the cubic Concept.

I will add that a cube does not love.
1. Changes of the size of axes.  reorganization of a cube it generally - re-creation new. Therefore it is better to put +20 lengths of axes for emergency.
2. Rare filling. In this case its favor is unobvious also to the programmer better to take hashtable.
3. Search in an incomplete dial-up of attributes. Instead of search of a point we will search for set of the facts on a hyper-straight line or hyperplane and  . O (1) turns to linear or polynomial.