The announcement topic for SymJ (and friends) derailed into a discussion not about those package themselves, but rather about the general strategy for symbolic/CAS support in the ecosystem at large. I’m opening this dedicated topic to bring that discussion here.
Is there a reason to not take an open source approach and collaborate on projects?
Why two rule systems? I mean, we can put agents to copy each other’s rules or… we can just have a repo of rules parsed differently?
So we just update SymbolicLimits.jl?
The only thing that can be fundamentally different in the symbolic space is the expression representation. But that isn’t something that is better or worse, it’s tailored to different algorithms. The best thing to do is to have a litany of different representations so that different algorithms can use alternative representations. For example, the Groebner basis representation is very different from even the SymbolicUtils.jl one.
So, why is this not just another tree representation with a few algorithms pointing it down that line?
I mean, I can just claude this all to be pulled from these repos, but it seems silly to be wasting tokens like this. Let’s just collaborate? I can start by pulling this all in but, I hope to see a first pull request somewhere. They could even keep separate repos: if GruntzLimits.jl is strictly better, then Symbolics.jl just needs a PR to its docs saying SymbolicLimits.jl is deprecated and point people to use the new limits subpackage, and then we delete the other package.
But I am wondering what isn’t transparently said here: if it all is strictly better… these are the obvious things to do… and you didn’t do that so… why? More directly, what is the expression representation and what are things that are traded off in its choices?
I don’t see anything about function registrations for example, so I assume it must’ve taken a closed tree approach?
I have actively contributed back to SymEngine.jl, bug reports to SymPy.jl (and probably had a few PRs here and there?), have been securing funding for CI machines for symbolics libraries, and have been helping get students into the topic. And I have given the reigns to many people, as these aren’t my libraries but those of the community. I’d prefer to help get new students into the topic, train new long term contributors, and not have to maintain all of it. Not to mention we are rolling out local LLMs which hopefully should improve the handling rate on “simple” PRs, now that there’s a lot more throughput.
I’m happy to bring anyone in.
Giac is pretty good. It is fairly restricted so it can’t do most of the things people are using the Julia CASes for, but yes there are some improvements we should make based on it. For the most part, the performance difference measured there seems to come down to the tuned C++ allocator, which we could compete by making an alternative Julia allocator but instead the route we’ve taken is to upstream requirements into GC improvements, many of which are making it into the v1.14. But for some algorithms we probably should have a restricted tree representation to move into, which we were doing with Metatheory.jl but need to probably do a new start to it.
But I don’t know the purpose of that post: it seems to be treating this as a competition when the goal is to just make nice interfaces for the community, and yes we should interface with the new Giac.jl stuff more but haven’t gotten to it.
I think people are trying to derail this discussion in their own odd ways here so let me just clarify something. I’ve interacted with @j_verzani for like a decade now through Roots.jl and SymPy.jl, been to his JuliaCon talks, and have lots of respect for him. The reason I ask these questions is legitimate because it is a bit of a behavioral change.
My guess is that the reason for SymJ.jl being a separate repo and all of that is because the repo was mostly vibe coded. I assume that he didn’t want to send a barrage of agents onto Symbolics.jl with changes and updates. That is very well intentioned but… I don’t think that should be the future. If a vibe coding repo ends up doing some things better then, we change to it. We are in the process of updating our processes and we need some way to pool efforts like this. I don’t want to maintain what isn’t needed and @j_verzani probably doesn’t want to either, but how standard open source maintained works with the velocity of agents is pretty unsolved. But I will say that we are happy to try new processes with trusted members of the community and try to get our velocities up, for example by allowing agents to auto merge in repos based on risk rankings and CI results.
Is there a reason to not take an open source approach and collaborate on projects?
I’ll answer even though the question wasn’t addressed to me. As the author of Giac.jl and OpenSymbolicRules (still WIP), I’m one of the people it is implicitly about.
I remember a very short private discussion we had at JuliaCon 2026 in Mainz, where you told me:
We don’t want to compete against M*
(* put your favorite proprietary CAS name here)
I also think you should admit that the positioning of Symbolics.jl in the general-CAS area is unclear. Your own tracker shows it. In August, a user asked on #59 whether parity with SymPy was still being pursued, and you answered:
The main focus of Symbolics is definitely very different from sympy, but we should continue to try and superset sympy anyways.
(question · your reply)
I took you at your word, so here is my answer to your question, with links.
You write:
I can just claude this all to be pulled from these repos, but it seems silly to be wasting tokens like this. Let’s just collaborate? … I hope to see a first pull request somewhere.
Chris, the first pull requests already exist. They are in your repos, and some of them have been there for most of a year:
- JuliaSymbolics/Symbolics.jl#1843:
factor,sqrfree,discriminant,resultant, the bread and butter of a general CAS. Opened April 21, 2026. As of today: 202 days, zero comments, zero reviews. - JuliaSymbolics/Symbolics.jl#1844: preserve exact
πin periodic transcendental solve. Opened April 21, 2026. Still open after about 7 months. - JuliaSymbolics/Symbolics.jl#1983 and #1984: mathematical assumptions and variable domains. Opened September 13, 2026. The only review #1984 ever received came 13 days in, from an automated AI agent running under your account, and it begins with not written or reviewed by Chris.
- JuliaSymbolics/SymbolicIntegration.jl#136, #138, #140, #141: exact algebraic numbers in Risch antiderivatives, removal of deprecated calls, correct sign decisions on non-real algebraic numbers, exact roots from the rule-based backend. All opened September 13, 2026. All still open.
To be fair, my small soundness fixes (SymbolicUtils.jl#1077, #1081) were merged within days. What stays unreviewed is the substantive general-CAS work, the work that would make Symbolics.jl more than an expression layer for a numerical stack.
So when an AI agent running under a maintainer’s account reviews my PRs faster than any human does, and the proposal on the table is I can just claude this all to be pulled from these repos, I don’t read that as an offer to collaborate. PRs go in, tokens come out, and no human is involved. I would call that an ingestion pipeline with a queue problem.
You also ask:
Why two rule systems? I mean, we can put agents to copy each other’s rules or… we can just have a repo of rules parsed differently?
That repo exists. It is called OpenSymbolicRules. It is a language-neutral JSON format with a validated JSON Schema, carrying RUBI’s integration rules, designed so that any CAS (Julia, Python/SymPy, Java/SymJa, Rust, JavaScript) can consume them with a standard JSON parser. A rule is only worth something once it is proved, so the project goes further than a pile of JSON: 101 rules across trigonometry, algebra, logic and calculus are authored in Lean 4 and proved against Mathlib. Every proof is replayed in the Lean kernel, the soundness of the reference rewriter itself is proved (OSR.normalize_sound), and the verification reports are published so that anyone can rebuild them from source without trusting the publisher. One of my early calculus rules did not survive that treatment. Lean refuted it with a counterexample, and catching that kind of error is the reason the project exists. A "certified": true field should mean a kernel-checked proof and nothing less. I invite you to contribute there. Mathematical rules can live outside any single language, in a neutral format consumed by different clients.
One thing your side did recently deserves credit: SciMLBenchmarks.jl#1887, which compares Symbolics.jl, SymEngine.jl and SymPy side by side on identical workloads, and was merged within two days of you asking for SymPy to be added. The instinct is right, so please follow it through and look at which engine is missing from the table: Giac.jl. The announcement that opened this thread names it: Performance exceeds SymPy.jl, but not Giac.jl, and SymJ.jl is beaten by Giac.jl in many areas. The benchmark includes SymEngine.jl, which is one C++ wrapper, and leaves out the C++ wrapper that outperforms the rest on speed. The workloads chosen are also symbolic-numerics ones (expansion, substitution, codegen, CSE), the axis where SciML wins by design. A general CAS is also judged on coverage: how many integrals, limits and equations it actually gets right, on suites nobody in the chart can cherry-pick. The 1680-integral suite compiled by SymbolicIntegration.jl and the 72k+ RUBI problems are available to anyone honest enough to run them, and John’s four packages ship with badges linking to comparative reports against Giac and SymPy. A CAS benchmark that leaves out the strongest open-source baselines (Giac, Maxima) and the proprietary systems measures a selection of opponents and tells us little about the field. Leaving M* off the chart while repeating that you don’t want to compete against M* is the same fuzzy positioning I mentioned above. If you truly do not compete with it, publishing its numbers costs you nothing, and the community finally gets an honest picture of where the Julia ecosystem stands against the systems people actually use for computer algebra.
About not wanting to compete against M*: on general-purpose computer algebra you are not even competing with Giac or SymPy, and the tracker shows it. Assumptions (#98), the defining feature of a general CAS, has been open since March 2021. So have wrong results from simplify (#1725), integer overflow in simplify (#1290), sqrt simplification (#958) and common-factor extraction (#686), some of them for four years. As I argued in Why open-source timelines/roadmaps don’t work, what matters is knowing which problems have been identified and what is preventing progress. On general CAS features, Symbolics.jl documents none of this: no roadmap, no design space, not even an explicit refusal.
Devrait être réduit
The thread moved while I was writing this, so let me respond to your last answers. @kahliburke already said it more bluntly than I will:
it’s mostly due to your attitude towards others in the Julia community. It does not inspire that spirit.
In your defense you listed your contributions to SymEngine.jl and your bug reports to SymPy.jl, and you announced:
rolling out local LLMs which hopefully should improve the handling rate on ‘simple’ PRs
That confirms the ingestion pipeline better than anything I could have written: the plan for the review queue is to hand it to language models. My #1843 is not a simple PR, and I suppose that is why it has been waiting 202 days. On Giac you wrote:
we should interface with the new Giac.jl stuff more but haven’t gotten to it.
Chris, I am the new Giac.jl stuff. The interface you haven’t gotten to is a review queue with my name on it, open since April. As for Giac being fairly restricted: a CAS is not restricted because it does not do SciML. John uses Giac as both the coverage reference and the speed reference in the very reports you dismiss as treating this as a competition. It seems comparisons only count as competition when they don’t flatter.
So, to answer the original question: yes, there is a reason to not take an open source approach and collaborate. I have been trying to, in your own repositories, since April. From where I stand, collaboration here is something you request and do not practice.
One last thing, because in the end it is the real answer to your question. Open source runs on volunteers. Nobody owes Symbolics.jl a pull request: not John, not me, not anyone. The same freedom that lets you set the direction of your projects lets each of us decide where our unpaid evenings go, whether into a review queue or into GruntzLimits.jl, RischIntegrate.jl, SymJ.jl, Giac.jl and OpenSymbolicRules. When a maintainer treats volunteer PRs as an inbox that can wait 200+ days, contributors who build their own packages are not defecting. They are using the freedom that makes open source work. We are volunteers, not an unpaid backlog.
The first pull request is somewhere. It has been there for 202 days. Token waste, indeed.
Yeah are ones I wasn’t sure what the right approach to take with it would be. I dropped the ball here and should’ve gotten to them earlier. I think @cryptic.ax might be one to review it or another thing would be to just add you to the maintainer pool since we need more people in.
To clarify this, I said I won’t do. I have finite time, and tracking down every feature against SymPy takes time. We need to get other people into the project focusing on different areas. Something like a CAS is too large of a project for 1 or 2 people to focus on all use cases, even though there are cross dependencies so that improving one area does naturally improve another.
I have been traveling quite a bit and need to catch up. Sorry. This is a reason why I would prefer to get other maintainers in these repos, because far too many Julia repos personally depend on me and it would help to distibute that a bit more.
It’s not really fair to blame only Chris for not reviewing in a timely manner, anyone can submit a review to those PRs. Because your PRs are huge and fully AI generated it takes far more time to give the final review (by a human) than writing such a PR. As of your post #1843 is still marked as draft so I’m not sure why you would expect a review on that one anyway?
I think we are having a breakdown of our open source systems more generally though. It’s hitting in multiple ways:
- We are getting more PRs than ever, and they are more complex than ever, making it harder to review everything that comes in. Until last January, I would inbox zero all GitHub emails every night. As of right now, I have 600 unanswered and get about 200 per day.
- It’s harder to build trust. A year ago, if someone came and did a few big PRs to the core, then you could know that they reasonably understand the project and know you can give them the reins. Some folks may not know this but SciML and JuliaSymbolics have traditionally been very liberal at giving merge privileges, some would say far too liberal, where in a month working on a repo we could pull people in. However, now it is much harder to know when that trust is built, since a complex PR is more likely to be “bad vibecoding” rather than good, and if complexity was the gate we would just get bombarded by a few really complex PRs that would more be about gaming the system (and this actually did happen around March and April because of GSoCs)
- It is not clear the old GitHub model of human PR review is scaling. I have been testing some automated systems that run a risk evaluation and auto merge based on that. If you got a PR in that was rated low risk and shortly merged, there is a good chance I never saw that PR
. We are still experimenting there but this is the growing “software factory” approach.
The obvious idea is to then scale the software factory: no one merges and just let agents say merge/no merge based on clear criteria, and continue to build the criteria. But the issue with such a factory is system is building it with safety, and also making it distributed. At the end of the day, if the factory only runs on my machines, then it’s too reliant on me, the point of these distributed systems is that they should outlive everybody.
But the end result of this year seems to be, at least by the tail end of it, a sharp U-turn in the wrong direction. As agentic AI usage grew, yes my productivity grew, but so did the ecosystem centralization, i.e. a lot more projects have been becoming dependent on my and that has then accelerated. That is not good, but it’s a consequence of 1 and 2, where the repos are requiring more velocity than ever while also making it harder to onboard new maintainers.
So, we need to change something. I just finished some new factory designs that are being rolled out soon but I think there is even more to be done to fix the distribution problem. I don’t think we can shrug it off as a “ehh slop slop we are fine” because the world has changed and if we keep like this, then we all start to use AI but we all ignore each other’s AI, and that seems like a really bad local minimum.
Symbolic computing and CASes seems like a great area to experiment on this because:
- I am not very invested in most of it. Like okay, I am maintaining some big widely used repos but some of the scope I hadn’t intended before. But I am happy to pass on large areas of the topic and help others be things like academic first authors on the topic, etc.
- It has some new blood coming in. @j_verzani and I are old blood, but @cryptic.ax is now at MIT for this general topic, @scelles is a player, Alex is going strong in other areas, etc. there is energy here. And @MilesCranmer does a lot in a different domain that should be integrated better.
- It’s a topic where there isn’t one good way to do things. My general hypothesis here is that all symbolic representations have different pros and cons, and the best way to build a symbolic system is to build out each of those representations with their optimized algorithms and then have a layer on topic that does representation conversions as needed for the right algorithms. This has always been the purpose of Symbolics, which is why SymbolicUtils.jl is a separate package, but it never really got there yet. But you can see some of this in things like the extensions for integrals and equation solving that use SymPy.
So the question of “is it even possible to contribute or are we wasting tokens?”, sorry I was about to take off and just trying to jot down the response really fast but I didn’t mean it flippantly, I meant it fully as a true question: is this possible or have things changed?
I can see this going a few ways:
- We all build out separate repos and compete on benchmarks. That seems suboptimal but it is a way.
- Different libraries build out separate representations, and then Symbolics.jl interfaces to them. So there’s a faster limit computation? Okay just make a Symbolics extension that calls it. We all work in different repos but then connect at an interface level. We all set our AIs doing their own things and don’t worry about merging processes.
- We start to do this interface level in more parts of Symbolics, but handoff parts of Symbolics to folks who care by domain. So symbolic integration vs codegen, everyone goes ham with AI in their areas.
- Symbolics.jl maintenance becomes more AI rule based and benchmark based. Each area becomes like symbolic integration where you have a call to a bunch of different implementations, and the AIs benchmark it all and define the default algorithm based on what is currently the most efficient. Different people work on improving different areas and we don’t call anything slop, it’s just all benchmark based and we don’t care how you get there as long as other areas don’t regress.
- We split at the representation level but not at the algorithmic level.
I think there is probably a future in 4, but I still think something is lost there.
While 4 would seemingly give us the best user experience with little fuss that we all want, it still hides the learnings from each other. So 4 today would call Giac.jl on most things symbolic solver based and Symbolics.jl most things codegen based today, and that would be a better repo. And for the record, now that I know about these projects, I have kicked off the agents to start doing that. But, it misses the learnings, the why.
Notice that in the other posts I talked about representations. Sure, it’s nice that Giac is a little bit faster in general, but why? How much of it is a a fundamental trade off vs something we can learn from? What I mean is that SymbolicUtils.jl is an open graph system, i.e. it has the ability to on the fly define new functions and operators into the system, and that is probably it’s biggest departure from most CASes and one of the big reasons why people use it. But if Giac is faster, is some of that due to an alternative tree representation? If so, we could learn from it and put that into SymbolicUtils.jl. Or is it a consequence of closing the world? If that’s the case then that is good to know because it means certain algorithms will be strictly better in a closed world, and we should then do a “search and call” default on that world, i.e. you call integration and only use those functions, then use the Giac approach. I say the Giac approach because to keep growing we should make a Julia version (how close is DynamicExpressions.jl, which IMO should also get incorporated for similar reasons) and continue to improve it. So what I mean is, done incorrectly we will grow fast and think we are good but hit lower ceilings.
Anyways, I had 4 months of heavy travel, I am taking off to finally get back in a few hours. On this last month I built out some new factory processes and will be trying new things. I think Symbolic computing in Julia needs some major process changes, and I’d like to chat with folks about experimenting in a way where we take into account this generative AI future as an asset, and understand that Symbolic computing is the very topic-distributed area where different people can be doing things that development wise are a world apart (Groebner basis calculations vs symbolic integration feel like very different maths!) but look similar from a user perspective. Because of that, it’s probably the best place to start trying a new open source model.
Made me think of: Stay away from my trash! – tldraw: Infinite Canvas SDK for React
Where this leaves us
This leaves us at a place where the best thing to do for our codebase is to shut down external contributions, at least until GitHub offers better support for controlling who can contribute, when, and where. Assuming the social contract of code contribution remains unchanged, then we need better tools to maintain the peace.
But if you ask me, the bigger threat to GitHub’s model comes from the rapid devaluation of someone else’s code. When code was hard to write and low-effort work was easy to identify, it was worth the cost to review the good stuff. If code is easy to write and bad work is virtually indistinguishable from good, then the value of external contribution is probably less than zero.
If that’s the case, which I’m starting to think it is, then it’s better to limit community contribution to the places it still matters: reporting, discussion, perspective, and care. Don’t worry about the code, I can push the button myself.
Have you considered limiting the ability to open PRs to collaborators only and working instead through issues? The flood of AI generated PRs is only going to get worse, if the bottleneck is human reviews by a handful of people I don’t see how that’s going to be sustainable long term. Instead of having an external agent drafting a PR, having an internal agent read and review it, you might as well let the internal agent draft the PR in the first place. I think the end result will be the same. At least on an issue you could have some discussion with a human first.
I’m not sure the problem is big AI slop PRs vs. just many more PRs (that can be quite good, but need some thought before merging). Making a change in one SciML library can have impacts across many others, and traditionally Chris is the person to handle the ultimate decision in such cases. i.e. I am comfortable merging stuff into Catalyst or JumpProcesses, but when I need to update OrdinaryDiffEq, or StochasticDiffEq, or SciMLBase, I have to wait on Chris (because he is really the only person who keeps an eye across the entirety of SciML). But with AI, each person who is making updates to just a few libraries can hit a velocity that Chris can’t keep up with now. I can’t even keep up with the velocity of PRs that AI generates for me as I go back and forth planning and reviewing my own AI-guided PRs.
I think Chris is right that we need to figure out a way forward in SciML, and the symbolics issues with sitting PRs are reflective of this. Symbolics is not Chris’ main concern, beyond its use for ModelingToolkit codegen. He likely doesn’t have the time to keep a close eye on it anymore for other types of PRs (like those that have sat unreviewed). Since Shashi graduated and moved on, no one has taken over his role as the Symbolics maintainer, leaving it as another thing to fall to Chris.
@ChrisRackauckas do you think it might make sense to have a SciML-wide discussion of how to reduce the burden on you? At least to me, it is most helpful if you are able to focus on things that have impact beyond one specific repo, so perhaps that means trying to identify others to take the lead on PRs for many repos where that is currently you? (Of course, the issue is perhaps that in many cases there is no one currently.)
By the way, this is also, I think, reflective of a lack of funding directly to SciML. SciML isn’t able to hire people to work on SciML full time to reduce Chris’ burden. Yes, many maintainers work at JuliaHub and other companies or are Ph.D. students contributing as part of their research, but SciML itself would really benefit with sustained funding to be able to employ people full time for several years to work 100% on SciML. That would provide time for them to take ownership of specific projects and reduce the burden on Chris.
Yes, this is pretty much spot on.
I had wanted to (personally) extend SymbolicLimits and the RUBI part of SymbolicIntegration for awhile now. I even had a PR for SymbolicIntegration at one point. But to be honest, I wasn’t up to the task of pushing those code bases forward. I recently wanted to see what an LLM could do, having been a bit resistant to the technology I wanted to explore what I was missing. So I pointed one at these two areas (extend to just TermInterface, limits and integration). I was impressed at how far they could go. The resulting GruntzLimit.jl and RischIntegrate.jl seemed worth sharing, as they extended by a real amount the coverage in these two areas. The RUBISymbolicIntegration package was more for personal completion. I’d hope dthe rules were setup in a separate repository, that would be great, as the only contribution in my package is a slighly modified pattern matching algorithm which picks up very few cases at the cost of performance. (To that end, it appears someone is working on just that). These packages were vibe coded, so I didn’t think of trying to make PRs against those code bases.
As for SymJ, I’ve had a few small issues with the python/julia bridge over the years with SymPy maintenance and was curious if a more SymPy-like CAS in Julia was possible. (There are some riches here available to Julia users already with Giac and SymPy.) I’ve personally been impressed with how far an LLM can go. I haven’t registered this and am not sure I should. I think it might be useful for some, but am concerned about long-term maintenance and managing expectations. This kind of project seems like it should be more than one person feeding an LLM.
Just writing as I read things, quite a bit to catch up on here.
I’m really excited to see the new symbolic integration packages. SymbolicIntegration.jl was a GSOC project that worked out pretty well in my opinion. I haven’t really kept up with it, but new symbolic integration packages are a win in my book.
SymJ.jl is interesting, I’m curious to see how it represents expressions internally. Maybe SymbolicUtils.jl can learn a few new tricks.
It’s possible I’m not seeing the full picture here, or misinterpreting things, but I’m more than happy to keep the packages separate and for Symbolics.jl to integrate with them all. Or maybe the other way around. Shoving everything into one package bloats precompile/load times, and is a much larger maintenance burden on the rare occasion we do a breaking change to that infrastructure (ask me how I know 
). Symbolics.jl has a bit of history to it, even I don’t know how all the internals work, and it’s certainly not a fully fledged CAS. By virtue of how it’s used, it tends to mainly be good at the things ModelingToolkit.jl needs. This is merely a function of where developer time comes from.
On the topic of the long-open issues in Symbolics.jl (and family) and comparison to other packages, I’ll add my two cents as succinctly as I can.
I don’t think any of the maintainers are in the business of intentionally ignoring PRs/issues. There’s just very limited developer time to go around. Other PRs pile on top, and things get lost in the weeds.
I vibe-coded those benchmarks because it’s been on my todo list for months, and because those were the other two CAS implementations I came up with off the top of my head. If you want to add Giac.jl to the list, please feel free. The intention was never to omit software better than Symbolics.jl.
It’s because those are the most heavily optimized in that stack, because I worked on them for almost 3 years with the explicit objective of making ModelingToolkit.jl as fast as possible. I can vouch that those algorithms are about as fast as I can get them to be, barring major API/algorithmic changes. Since I spent so much time on them, those are the ones I’m most interested in seeing how we perform on. That’s not to say other benchmarks are unimportant, they just weren’t the focus of my attention.
I’ll close this out with:
For better or worse, Symbolics.jl is a CAS whose primary development comes from ModelingToolkit.jl developers. Those are the things it is best at. I’m happy to have a litany of benchmarks where Symbolics.jl loses, because that means one of two things:
- There’s a cool trick we didn’t think of, maybe we can use it.
- Symbolics.jl knows exactly what package to call for each task.
I was expecting a new topic, or for this one to be split. In any case, I haven’t much time these days. But I just wanted to tell @cryptic.ax that asking me to add Giac.jl myself to your benchmark is problematic. It’s the kind of asymmetry that bothers me. Moreover will it be a PR that will be on bottom? What are priorities of Symbolics? Where can I see its ROADMAP? Is there some kind of MoSCoW?
I think your last paragraph clearly shows that you understand interest of benckmark and I appreciate that, it’s not about competition, it’s all about performances, features coverage and making all open source CAS knowing where they need to be stronger.
Huh, why? It is your package, you are best positioned to integrate it into the benchmark. The goal is to make the ecosystem better for everyone so this does not seem very constructive.
I find it very odd that this comment is in a completely different writing style from your previous huge wall of text. So I assume that was all AI generated then?