[Zero]

I didn't understand, LOCKSUIT.

Can someone understand this?

[spydaz]

I didn't understand, LOCKSUIT.

Can someone understand this?

I have read a similar paper (for DNA Genome Encoding and Searching) its the same technique ....) They Create trees First (try trees) then reduce them with compression algorithms... by Combining pathways, and reducing the Pathways.... then applying Referencing to the nodes..essentially looking up the required node rather than Parsing the tree..... the tree Stores the locations therefore the tree becomes compressed. Less nodes... Yet each combined end leaf node, which may have pointers to lower end nodes which contain the previous end node... (node are considered to be end nodes although having sub-nodes) ...Combined Prefixes to the final end nodes.... it seems very complex in construction terms as first a optimised tree needs to be created, then optimised... then Locations applied.... by combining locations which point to sub locations to complete a Suffix or "piece of data"....

I have recently been playing with tree/tries/binary trees.... and am currently meditating on the same compression methods.... it the look up process where i'm trying to get straight....the tree reduction process depends on the data being stored and how your storing it in the tree... so that's tailored to your own project.... Videos on suffix tries and suffix arrays .... is helping me along.... i also keep getting sidetracked with understanding the Lambda functions in lisp ... and how it might be useful for me....i like the idea of being able to rewrite functions with the lambda function....

that paper would take me a few days to read and understand....

[ranch vermin]

I think I just solved the NP problem..........I instantly realized the answer to a NP question on the wiki page in polynomial time. I'm NOT telling yous how just yet haha! That was fast!                                                   ?

It said above it:
There are many important NP problems that people don't know how to solve in a way that is faster than testing every possible answer. Here are some examples:

EDIT: This is the easiest thing everrrrrrrrrrrrrrrr

Sorry I just joined this thread,  this one is an old one from locksuit.   

Locksuit,  you dont even know what I think about transforms and equations!!!!  I think its definitely possible to solve "non polynomial" functions,  but all inputs must be read at least once and no data can be concocted from nothing, with an added cost to your system, and u havent defied logical reality,  but NP problems are solvable IN P time, making them not NP really.   But u have to realize the specifics of your problem better.

Why do I think this?  Because the public key encryption is cracked by an ordinary method that runs on an ordinary computer NOW.  (if u could call it ordinary.)  All this quantum mechanics stuff is just a big smoke screen and u dont even need it.   So get on working out *decent optimizations* but dont flip out when you work one out.

That Yolo,  look only once, method for computer vision is a leading contender for *optimizing* classification of images.   once somethings optimized, unless youve got a whole lot of crapper optimizations to compare it to you just take the function for granted, as if it always was that fast to operate. 
How much work was circumvented becomes from then on expected.

Comparing the naive approach, to the optimized approach is a big difference is it not, sometimes. But its just the "better way" its not quantum computing,  but it tends to be alot faster.

[Zero]

Are you aware of this paper? Basically it's a space/time tradeoff technique you might like to use in your project ivan. There's also an implementation.

Also, is there a relation between your project and minikanren?

[LOCKSUIT]

@ranch, you have to brute force a password no heuristics. Only hints can become heuristics ex. the password is the name of a cat.

Trying a 0-8 digit password is already a heuristic, you know jumping on a trampoline or shooting Mars 67 times is not the answer!

[Zero]

I didn't understand, LOCKSUIT.

Can someone understand this?

I have read a similar paper (for DNA Genome Encoding and Searching) its the same technique ....) They Create trees First (try trees) then reduce them with compression algorithms... by Combining pathways, and reducing the Pathways.... then applying Referencing to the nodes..essentially looking up the required node rather than Parsing the tree..... the tree Stores the locations therefore the tree becomes compressed. Less nodes... Yet each combined end leaf node, which may have pointers to lower end nodes which contain the previous end node... (node are considered to be end nodes although having sub-nodes) ...Combined Prefixes to the final end nodes.... it seems very complex in construction terms as first a optimised tree needs to be created, then optimised... then Locations applied.... by combining locations which point to sub locations to complete a Suffix or "piece of data"....

I have recently been playing with tree/tries/binary trees.... and am currently meditating on the same compression methods.... it the look up process where i'm trying to get straight....the tree reduction process depends on the data being stored and how your storing it in the tree... so that's tailored to your own project.... Videos on suffix tries and suffix arrays .... is helping me along.... i also keep getting sidetracked with understanding the Lambda functions in lisp ... and how it might be useful for me....i like the idea of being able to rewrite functions with the lambda function....

that paper would take me a few days to read and understand....

If I understood correctly this paper is about compressing a binary tree into an array of bits, which is not what I want. I think I'll just sit down in front of my notepad and spit out a few js functions, as usual, to see where it leads.

Actually, what I want is a bit like pattern learning, the way you'd  do it with NNs, except I want it on discrete data. Once trained, the machine could shrink a huge list of related cons cells into a smaller one, and then answer questions about it a lot faster (if you know it's a car, then it has 4 wheels, you don't have to check, you already know it). It could also fire an appropriate action response, if you want. This is all about creating a higher level representation of a situation.

[ivan.moony]

Are you aware of this paper? Basically it's a space/time tradeoff technique you might like to use in your project ivan. There's also an implementation.

Thanks for the reference, very nice idea there. I plan to use only pairs, but I might sort them in a similar way from that paper. That would boost up compilation process. Great stuff there, thanks

Also, is there a relation between your project and minikanren?

No relation other than being a s-expression based language. Syntax is different, and I use some other primitive operators: a dot and a quotation for forming s-expressions, and ? or ! for querying them.

[Zero]

You're welcome.

About minikanren, I thought there was a link, because db querying and logic programming are often "neighbours" conceptually.

I like what you're doing here, if there's anything I can do to help, don't hesitate.

[ivan.moony]

I like what you're doing here, if there's anything I can do to help, don't hesitate.

Thanks for the offer. Right now, I'm still writing the specification. Maybe in some later phase I might take that offer seriously.

There is a long way to go, and I guess this is a life span plan for me. Well, one thing at a time would hopefully get me somewhere.

[ivan.moony]

I've been busy lately finishing a draft about Sequela. When I came to the part about describing logic examples, I realized that all I wrote is about logic and predicates, just as they said loud and clear in Curry-Howard correspondence. Finally I decided to abandon the draft in a favor of logic. But I didn't go through all this trouble for nothing. You see, logic is a very messy place, starting with all the transformations including disjunctive normal form, and that makes logic code observations difficult. However, if we follow some patterns, it becomes easy to predict how the code behaves, and that is what I got from this journey - some practical patterns we can use to tame the beast, just to make general computation predictable. I don't know if I'm going to make a paper about this before I actually make a Javascript implementation, but when I finally do it, I think it will have an effect like "What?!! We were looking at this all the time, and a solution was right under our nose, but we didn't see it!"

This is almost finished Sequela paper I'm abandoning. You might want to take a look, but it is past already. I'm making a switch to almost pure classical logic.

[Zero]

What logic often lacks is temporality. Things seem to exist in a land where there's no notion of time. A logic programming paradigm that would take transformation into account would be really nice.

One way or another, you're still climbing the same mountain... 

[ivan.moony]

What logic often lacks is temporality. Things seem to exist in a land where there's no notion of time. A logic programming paradigm that would take transformation into account would be really nice.

I concluded the same thing about logic. There is no order in logic operators, they all seem to live in the same medium without a notion of time, finally resulting with only one true or false. But escape might be in something like functions (predicates are functions with Boolean result), especially like recursive ones. Function parameters may be used to represent sequences of data where it matters what comes before and what after.

But I'm not that much into classical predicates. I'm laying my bets in free concatenations of logical expressions that form sequences of data, while each sequence element is being under influence of all logical formulas in the same scope of reach. These concatenations would replace predicates and functions.