-
Notifications
You must be signed in to change notification settings - Fork 112
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
Semantics of ==
not good for generic programming
#520
Comments
Same problem here. For example, we cannot use Polynomials.jl with symbolic expression coefficients. |
What are you proposing If there is a reasonable answer, we can implement it. But
julia> missing == 2
missing
I hope it's also about correctness. |
That it does what |
The current behavior of
This will result in wrong code as I mentioned. |
I mean that Because It looks like 1.0 was released a couple of months ago. That's unfortunate. This limits the usability of Here is a related problem shield Base.require from invalidations when loading Symbolics.jl. I think this kind of thing is quite common. I have some packages that should be released at v1 and this is a good reminder to vet them for gratuitous extensions, which I know I have made in the past. Like everyone else, I was over-enamored with multiple dispatch. It's probably the relatively recent focus on invalidations that has brought this problem to light. |
btw Convex.jl also works this way, where |
If there is a strong desire for this, I think one can make a number type which behaves in the way need, just as we have
|
Having
==
construct an equation might be a good idea if this package were a standalone CAS, like Mathematica. But it's meant to work with the larger Julia ecosystem. The semantics of==
in Julia at large is consistent. The semantics here is completely different, which means you usingSym
in generic code will often do the wrong thing, in fact throw an error.I can't find a single instance in Julia where
a == b
does not returnBool
. Maybe there is one, but I can't find it. This line inBase.jl
is largely responsible:You have...
As a result, this assumption is made everywhere in the Julia ecosystem.
This issue is similar to #15. I did not check this against the version of SymbolicUtils in that issue, but I think the problem there was also that
==
does not return aBool
, not simplification.I noticed this a couple of years ago, and may have posted something somewhere. But I want to state the issue clearly. I can't think of a function in Julia that is more widespread and with more consistent semantics than
Base.==
. And the method defined for::Sym
breaks this consistency for the sake of giving the frontend experience of Mathematica. This makesSymbolicUtils
more like a DSL and less like a library for use in other Julia projects.A response could be "just use
isequal
". But that would miss my point. Julia is about composability an genericness. (Andisequal
has a different, specified, semantics.)(btw. +100 on performance of rules and of load time of
SymbolicUtils
! This makes it easier to argue for Julia.)The text was updated successfully, but these errors were encountered: