Skip to content

Conversation

@michael-schwarz
Copy link
Member

This was needed to not report spurious precision differences for the benchmarks in my thesis.
If we want this on the main branch, we can merge, otherwise we can close it.

@sim642
Copy link
Member

sim642 commented Dec 18, 2024

I haven't thought about it much or checked if this would completely break something, but I wonder if such thing could/should be non-optional. I think ValueDomain.join has cases for joining blobs with non-blobs by lifting the joining into the blob, etc. Perhaps something similar should be in leq unconditionally to maintain its algebraic consistency with join, etc.

I suspect domain quickchecking doesn't really work on ValueDomain, so such consistency might not be too easy to check that way.

@michael-schwarz
Copy link
Member Author

I am also not sure if one wants to have this in general, but I think having it in the compare scripts and having the option to dis/enable it, seems like it is generally a step in the right direction?

@michael-schwarz
Copy link
Member Author

Do we want to merge this or close it? I'm fine with either!

@sim642
Copy link
Member

sim642 commented Feb 18, 2025

I was wondering about these join cases:

| Blob (x,s,o), y
| y, Blob (x,s,o) -> Blob (join (x:t) y, s, o)

But they're actually after these:
| (Bot, x) -> x
| (x, Bot) -> x

So the special cases don't even trigger for such things. Indeed, then this isn't what should normally happen, but I'm ok with having it for comparison.

@sim642 sim642 added this to the v2.6.0 milestone Feb 18, 2025
@michael-schwarz michael-schwarz merged commit 746d436 into master Feb 18, 2025
20 checks passed
@michael-schwarz michael-schwarz deleted the bot_in_blob_leq_bot branch February 18, 2025 09:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants