Some more fixes

[HechtiDerLachs]

Today's harvest from working on the elliptic surfaces.

[thofma]

I think a lot of changes from #4133 and #4126 are undone here. I guess this was not on purpose.

[HechtiDerLachs]

Yes, I'm already working on it. It's a bit annoying, because I had to work on the compute-server today, but there I can't put my login-credentials for GH. Thus, I manually copied the files via scp and this is what you get...

unwanted changes removed

[lgoettgens]

Suggested change

	pre_result = filter!(!is_one, vcat([minimal_primes(j; algorithm, factor_generators=false) for j in J]...))
	pre_result = filter!(!is_one, reduce(vcat, [minimal_primes(j; algorithm, factor_generators=false) for j in J]))

save some allocations

[HechtiDerLachs]

I advocate for this solution now. It is a matter of fact that ideals can not be hashed in general and even for polynomial rings this is probably expensive if not impossible (we need to choose an ordering which might be a dead end for a specific ideal). Yet, the == function is vital to how we use ideals and we need to be able to use them in vectors/lists/dictionaries.

[simonbrandhorst]

Is it safe to hash the type? After all two mathematically equal objects may have different types.
(Thinking e.g. of IdealSheaf, RadicalIdealSheaf, PrimeIdealSheaf etc.)

[lgoettgens]

Is it safe to hash the type? After all two mathematically equal objects may have different types. (Thinking e.g. of IdealSheaf, RadicalIdealSheaf, PrimeIdealSheaf etc.)

It is only safe if you don't implement == between this type and other types. In your example, you shouldn't include the type in hashes.

[HechtiDerLachs]

Ok, good to know. I was only following the suggestion by @benlorenz . But you're probably right.

[fieker]

On Fri, Sep 27, 2024 at 01:30:28AM -0700, Simon Brandhorst wrote: @simonbrandhorst commented on this pull request. > +# Since most ideals implement `==`, they have to implement the hash function. +# See issue #4143 for problems entailed. Interestingly, this does not yet fix +# the failure of unique! on lists of ideals. +function hash(I::Ideal, c::UInt) + return hash(typeof(I), hash(base_ring(I), c)) +end Is it safe to hash the type? After all two mathematically equal objects may have different types. (Thinking e.g. of IdealSheaf, RadicalIdealSheaf, PrimeIdealSheaf etc.)

Tough one: Julia tries/ tried to make sure any number comparing equal have the same hash. We don't - way too expensive. Is there any situation where you want a dict or a set where the keys/ elements are different types and then catch that 2 objects of different types are "the same"?

…

-- Reply to this email directly or view it on GitHub: #4142 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[HechtiDerLachs]

Is there any situation where you want a dict or a set where the keys/ elements are different types and then catch that 2 objects of different types are "the same"?

Probably yes. For instance, it would make sense to introduce a lazy type for radical ideals, say RadicalIdeal. This would have a special dispatch for ideal membership so that the computation of the radical can be avoided. Yet, comparison with the standard types of ideals for the respective ring could give that two ideals are equal, even though their type differs.