Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing statistics and forced to quickly abort executions #51

Open
Yewzir opened this issue Jun 27, 2024 · 1 comment
Open

Confusing statistics and forced to quickly abort executions #51

Yewzir opened this issue Jun 27, 2024 · 1 comment

Comments

@Yewzir
Copy link

Yewzir commented Jun 27, 2024

All this time I figured I was one of the few who couldn't get it to work but it does actually. Well, sort of.

After cloning the repository for another attempt and prior to running cargo run --release, I checked the contents of the params.rs file in order to verify if the search parameters are still identical to your example. They are, and so I ran it just like that to see what would happen this time.

Eventually it terminates successfully with the following results and although it actually processed 6,758 expressions, it appears as if it spent twenty seconds on nothing.

Finding length 14...
.
.
.
Explored 0 expressions in 19.8816743s
Total: 7694843 expressions in 84.4192928s

Going all the way up to the results of length 13, I noticed how it already knew how many expressions it'd process in total. Uh, I cannot understand how. Am I possibly missing something important in all of this?

Finding length 13...
.
.
.
Explored 0 expressions in 5.6641441s
Total: 7694843 expressions in 64.5369573s

Everything looks normal prior to processing lengths 11-14 and the results of length 10 already show a current total of 7,694,843 expressions.

Regarding the expressions it finds, I'm not succeeding in obtaining the following example output.

--- Length 5 ---
n%5-3

I have to abort execution really quick in order to see the shortest results and that's when I noticed that it does find your example.

$ cargo run --release
    Finished `release` profile [optimized] target(s) in 0.06s
     Running `target\release\pysearch.exe`
sizeof(Expr) = 40
Finding length 1...
Explored 10 expressions in 20.3µs
Total: 10 expressions in 357.8µs

Finding length 2...
Explored 43 expressions in 15.5µs
Total: 53 expressions in 988.2µs

Finding length 3...
Explored 100 expressions in 103.2µs
Total: 153 expressions in 1.7371ms

Finding length 4...
Explored 396 expressions in 52.2µs
Total: 549 expressions in 2.1059ms

Finding length 5...
n%5-3
Explored 2123 expressions in 456.9µs
Total: 2672 expressions in 2.8153ms

After modifying the search parameters and aborting execution really quick to see if it finds the second expression, it appears to have found three expressions of the same length and although all of them seem valid, the example of yours, 1-n//2%3, is nowhere to be found.

Finding length 8...
3-n%6>>1
4-n%6>>2
1-n%6//2
Explored 278791 expressions in 171.0213ms
Total: 354731 expressions in 199.1973ms

Would you be so kind to shed some light on everything that's going on here, please? Thank you.

@JayXon
Copy link
Collaborator

JayXon commented Jul 5, 2024

pysearch has been changed significantly since that example was written, we probably need a better example.

The number of expressions are the cached expressions, notice MAX_CACHE_LENGTH is set to 10, so after that pysearch is in DFS mode, and it no longer cache expressions nor track how many expressions were evaluated.

Having to abort really quickly is because pysearch is now significantly faster.

1-n//2%3 is not found because 1-n%6//2 is equivalent, pysearch doesn't keep both n%6//2 and n//2%3, because these two expressions has the same output, depending on the execution order it could choose either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants