I also think this "paper then code" approach is now obsolete. The modern way, in AI-assisted workflows, is to first iterate on "derivation sketch <-> machine-checkable proof" incrementally building out your result. You can of course leave `sorry` placeholders along the way and fill them in, so it's not like you're restricted to going entirely bottom-up. Finally, once you have a `sorry`-free proof of your top-level statements (theorems) of interest, you can then work on writing up the exposition in LaTeX based on the lean code.

1. See https://arxiv.org/abs/2610.08144 for details, but an example they point out is that a key bound required 5 additional orders of derivatives (and stated in Lean that way), but the paper claimed that the bound held with only four more derivatives.

To call the approach obsolete and refer to a "modern way" to use an LLM seems like a stretch when critiquing the approach used by a frontier lab a month ago.

As a non-mathematician who sometimes works on mathematical problems, I find this really puzzling. Why aren't mathematicians excited about the frontiers being unlocked by AI? The ability to discover more of the mathematical universe more readily?

For the mathematicians who still are in academia: I guess because the competition for research positions (in particular permanent ones) is already insane; they probably feel that AI makes this kind of competition even worse.

I want lower energy bills, lower rent, better understanding of health etc. more than I want theorems.

These efforts aren't mutually exclusive. I hate to be snide, but a lot of people would criticize you for being a mathematician because they want lower energy bills, lower rent, better understanding of health etc

And yes, nobody is that excited about vatsachak's mathematician-ism. it's just a thing he do. And now it's just a thing AI do.

I’m personally pretty excited by the results coming from these labs, but trying to dismiss the capital allocation objection with “but what about” is really silly.

Edit: I'm fine saying we're spending too much money on AI, in fact I agree, but "theorems" are not the only output of these companies. It's almost definitely not going to be worth the expenditure, but the benefits are not going to be only lean proofs

This is already the situation that we have: because of the fierce competition for temporary academic positions, and very little hope for permanent positions, large quantities of really good mathematicians leave academia and work in a job that has basically nothing with mathematics (many mathematicians consider these jobs as bullshit jobs, but they pay the bill).

The value of LLM is not "Ha curious look what it can do". It's not entertainment.

Well, I wouldn't generalize based off of the thread OP (and people on social media, including me). I think a lot of us are very excited! Most of my collaborators are, including myself.

There's a lot of simultaneous social change that's accompanying these tools, not all of which is positive. Agonized screaming is pretty loud, relatively speaking to the rest of the conversation.

But maybe that's the difference between shipping a controller for F1 versus shipping one for an industrial or consumer product? shrug.

These cars are in a perpetual Q&A state, they are getting modified between races. That's true for the "big teams", small teams don't have the resources, they're just "happy to be there". That's why it's possible to see stories like Brawn GP[^1]. That's what makes the sport fascinating, because the overtakes are not as much as one would hope for a ~2-3 hours race. But every little thing counts. In the last race 1st and 2nd had ~103ms diff or something like that for example, which is something that didn't happen for 15-20 years (maybe more).

[^1]: https://www.youtube.com/watch?v=jd3miTpvUmI

This isn't really the case anymore. There's a budget cap, and all of the teams are financially sound most of the time. While the poorer teams might bring fewer upgrades in a year, they still bring upgrades all year long, and R&D is a continuous process in every F1 factory these days. Smaller teams also get additional R&D, compute, and testing time compared to the big teams.

Two important informations are buried like „now smaller teams take podium 5% of time instead of of 10%” and „cost cap administration is a burden” and they there are no clear guidelines on what is in the cap and what not.

Not really. The budget cap does not include the salaries of active drivers and the three highest paid non-driver employees, as well as some other odds and ends.

In most major league sports in the US, there is some form of salary cap, but it really only applies to players. Organizations can spend money on other things as they wish. That applies to coaching, front office, facilities, etc.

In motorsport and in Formula 1 not so much. If a team has a dominant car, let's say half a second faster than the second best, the championship is an internal matter between its drivers. Any second tier driver sitting in one of those two cars can be world champion. The only opponent is the team mate. So most of the money goes into the car.

The Formula 1 cost cap applies to all expenses with few exceptions. Most notably drivers and the (3?) highest paid employees. Of course you must keep the bosses happy, right? Drivers could become subject to the cap in one of the next years. They won't be happy but what can they do? Furthermore teams will always find somebody to drive their cars even at one tenth of what they are paying now.

I've watched F1 for more than 2 decades, from the paragraph above I realize this year's F1 is basically comparable to AI slop...

F1 has been unsatisfying since the move to hybrid power trains.

The real issue is the cars are just too big and heavy. There was a point in time when you could pass someone even in Monaco.

Lewis vs Nico was at least crazy entertaining. Then there was a Vettel threat one year, then there was the Max vs. Lewis era...

What IS annoying is nobody bothered to test this "rain mode" (or whatever setting it was that they removed between the aborted formation lap and actual race start) prior to racing in Sepang on the cusp of monsoon season.

Every GP is a slightly different car running bleeding edge tech and code.

Williams even rolled out completely new chassis (with full homologation/crash) mid-season this year because the first design couldn't come down to minimum weight.

Ah, a student of the old masters....

(For the uninitiated, or those who wish to relive the memory: https://www.ibiblio.org/harris/500milemail.html )

What they probably could do yesterday, on top of checking a ton of telemetry, is understand which inputs were weird and put those into a simulator and get some hints for the FIA to work with. If you’re not aware, the FIA provides the ECU to all teams so that the telemetry used to check compliances and power modes are fair across all teams, and things like traction control are not there. This is why the FIA had to provide the firmware update.

That's... not how it works at all, though. There are no prizes for individual races and the championship money is also pennies to the teams.

Mercedes's Kimi Antonelli is going to win the WDC anyway for sure at this point, given the points difference.

> Isn't that the entire point of a simulator to learn things that are too expensive to learn in the real world?

You're right but this is not those expensive things. Track time is extremely limited, so the primary role of the sim is to develop the car and how it feels to the drivers, mainly so the setup feels perfect to them.

System-level bugs etc must have their own testing but sim is mainly for driver-engineer testing. Many drivers also don't like using the sim at all like Hamilton.

The constructors championship money is absolutely a massive impact for the teams. Last place (11th) is estimated at ~$50 million, 5th place is estimated ~$100 million, and 1st place ~$140 million. For a team like Williams or Haas, every position they move up the ranking makes a substantial budget impact (both of those have estimated total budgets ~$230 million). Even for one of the big 4, with budgets in the $400 million range, the $40 million swing from 4th to 1st is not insignificant.

Heck, Otmar had to pay his staff out of his own pocket back in the day (I don't remember what cost-cap was in place back then - I think that was during his time at Force India). Those lower teams are more stable now that 20 years ago, but still struggle to get enough sponsor money to compete.

Wind tunnel time and aerodynamics simulator time are included in the cost cap, as are car parts and most staff (but not driver salaries, travel or marketing)

Drivers can spend all the time they want in standard consumer sim racing rigs, practising the tracks. But when it's the type of extra-high-fidelity simulator that lets you make the car better - that's subject to the cost cap.

I assume someone is already offering an extremely high-fidelity CFD simulator (or a wind tunnel) to help companies shoot awesome videos of their cars, for purposes of including them in TV spots, of course.

I worked on engine and powertrain simulations, and my compiler was used for vehicle and driver simulations. This was built for Honda, but Honda left, bought by Mercedes, and won them several championships.

Sometimes we bring down whole services with "just" config (looking at you, DNS).

[1] https://gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-t... (the last paragraph, search for "remote debugging" in the page)

Restarting in Hamilton's case "fixed" it because it removed the condition it was in, if he would have done the lap again, it would have happened again.

[1] https://en.wikipedia.org/wiki/Allegations_of_cheating_during...

https://youtube.com/@actuallyven

The initial formation lap was aborted due to the glitch (caused drivers to slow to a crawl or stop). The cars all went back to the pits. Then there was a long delay while FIA/teams/ECU provider figured out what was wrong. And eventually fixed it via a software update.

I think the idea is that a small program can organize its allocations and data structures to minimize number of calls to malloc, e.g. with preallocated workspace structs, or slab allocation, and similar approaches. But as a program gets bigger, there's a pressure to have looser coupling, to have subsystems with simple convenient APIs which leads to them doing on-demand malloc calls internally, rather than having consumers pre-allocate their needed workspace. Because that kind of workspace management results in more complex APIs and more burden on the consumer.

That said, I don't really believe it either, at least for the kind of codebase where it would matter (scientific computing, in-memory DB server, etc). A codebase that places an emphasis on minimizing heap operations in hot codepaths can do so by consistently using workspaces and allocation-avoiding APIs. I don't think it's so difficult really, but it does take a conscious design decision to do so. But writing something like a web browser in this way could be annoying due to most data having wildly variable sizes, and zig's arena concept would be very handy -- but rust has crates like bumpalo for that purpose.

My personal mantra: "Think in FORTRAN, code in Rust/Julia/C++". But I'm mostly working on HPC-style code where I don't have to do with wildly varying input or output sizes.

Except that's not composable - not only do you need specialised data structures, but all (transitively) allocating calls need to be specialised. That's the exact same issue we have in C++, and that's the issue Zig seeks to address. BTW, just the other day there was a post here about a language with another interesting approach, but I have yet to give it a close look: https://github.com/aardappel/goose/

> But I'm mostly working on HPC-style code where I don't have to do with wildly varying input or output sizes.

There you have it. The problems arise more quickly in concurrent rather than parallel code, and when there are lots of features added over the years that touch the hot paths.

> in-memory DB server

Actually, here there can be big problems (as it's also about concurrency rather than parallelism). Last week a colleague of mine looked at Moka and saw that it could only offer half the throughput as Java's Caffeine at the same latency and RAM footprint (almost; the Java program used 5% more RAM). When he looked into it, he saw that over 40% of the program's CPU was spent on the epoch-based reclamation.

Most crates for containers will be written such that the container types take an optional allocator type parameter that defaults to the global allocator. You can set it and it transparently uses the other allocator.

To improve the ergonomics, you'd define local aliases that use that allocator.

    type MyVec = Vec;

   with_allocator(&arena, || {
      third_party_library::do_work()
   });

but custom allocators are rarely used in rust because they're simply not needed the vast majority of the time. if your language is not memory safe and you need to manage memory yourself, they're more important. but this isn't the case with rust.

c and zig folks are obsessed with arena allocators particularly because they can group lifetimes of individual objects, reducing the amount of malloc/free calls and thus the amount of use after free, double free, nullptr derefs, or leaks that can occur.

in rust this isn't a concern so custom allocators are only used for performance reasons.

but it turns out that in performance sensitive areas, you generally use custom data structures or those that already have their own allocation strategy baked in, like the generational_arena crate.

most of the time you are not calling thirdparty crates that allocate in performance-sensitive regions. either the crate is designed for this usecase and already uses a performant allocation strategy, or you're writing your own code here.

and in the rare case, you can trivially vendor the crate and pass your own allocator into it, or toggle the global allocator for callers.

but you also need to benchmark first before choosing an allocation strategy because it's not clear that a custom allocator will always guarantee better performance anyways.

and btw zig doesn't guarantee this anyways. you could pull in a dependency that instantiates their own allocator. at least in rust almost all crates use the global allocator as a default which lets you swap it out. if a zig dependency uses their own allocator the only recourse is to fork it.

rust doesn't have a performance problem, so any claims about it's custom allocator support leading to poor performance is unfounded. and thus so are claims about the superiority of zig's approach to allocators.

You say I outright lie for not mentioning the existence of something that doesn't exist??? I guess you're saying it's possible to create such a mechanism (or that some libraries do create ad-hoc ones), but that's not the point.

> there is nothing stopping you from using custom allocators with your own code or with calls to thirdparty dependencies

I didn't say there's anything in the language stopping C++ and Rust from having such a standard library and ecosystem of libraries. They just don't have that yet.

> if your language is not memory safe and you need to manage memory yourself, they're more important. but this isn't the case with rust. c and zig folks are obsessed with arena allocators particularly because they can group lifetimes of individual objects, reducing the amount of malloc/free calls and thus the amount of use after free, double free, nullptr derefs, or leaks that can occur. n rust this isn't a concern so custom allocators are only used for performance reasons.

This is simply untrue. I won't call it an outright lie, as it's probably just a lack of experience with low-level programming.

First, I'm trying to point out the problems we've had in C++, most of which only became apparent when evolving large codebases over time. People who have not had experience evolving large C++ or Rust codebases over years simply don't know about these problems and certainly can't claim they don't exist. Writing smaller programs in C++ or even large but young programs has always been a pleasure. The language is expressive and productive. Some of the biggest issues only arise years later, when the program gets either expensive to maintain or slow.

Second, experienced C and C++ folks cannot be "obsessed" with arenas for the reasons you mentioned because until maybe 20 or even 15 years ago memory safety wasn't a widespread obsession. It was a correctness issue like all others, and its outsized role as the cause of security vulnerabilities wasn't widely known until more recently.

Lastly, you don't pick Rust for safety. Most software in the world today is already written in languages that are at least as memory-safe safe as Rust, sometimes more so. These days, you pick C, or C++, or Rust, or Zig when you want to do something that's largely low-level. Things that are low-level often also need to be reasonably fast, and large low-level codebases that evolve over years tend to suffer serious performance issues because of memory management (because, being low-level, they can't move pointers and so can't use things like a moving GC to reduce the overheads of their malloc/free runtimes; this is why companies with actual experience with long-maintained large low-level codebases make huge runtimes like TCMalloc to help them to a degree, which you also may not have needed yet), and arenas are the primary way to get memory performance similar to what you see with modern moving GCs (and even somewhat better).

Now, you could say that C++ only started moving in that direction with pmr in C++ 17, and that's true. But the need was recognised as early as 2005, traditionally C++ codebases didn't rely on many libraries so interoperability has typically not been a large concern, and the number of large C++ programs that would benefit from such a thing declined over the years because of the low-level maintenance issues I mentioned and the growing availability of fast high-level languages.

My distaste for Rust isn't because I like C++ so much. Even though it's been one of my primary programming languages for the past 25 years, I "hate" it for the very same reasons. Most Rust superfans are people who have not had enough experience with it and they don't know about the problems. Not all, of course, and even C++ has superfans, which is why I said that among the people who are experienced in low-level programming, there are people who like the C++/Rust approach (of trying to make low-level code appear high-level) and people who don't.

It's nice to have this perspective validated by someone like Serre! I felt like I was missing something when I first encountered that formalism. In fact, all of my introductory calculus classes sucked and turned me off of math for a few years.

Edit: added semi-source

[0]: https://en.wikipedia.org/wiki/Nonstandard_analysis

[1]: https://math.stackexchange.com/questions/51453/is-non-standa...

[2]: https://people.math.wisc.edu/%7Ehkeisler/keislercalc-06-03-2...

The formalism is very simple symbolically. But the mathematical machine behind it is very complex.

This is treated more rigorously and generically in the subject of synthetic differential geometry.

Also conceptually it feels just right to use nilpotents to probe the smooth structure. In a way nilpotents are violently smaller than even non standard analysis infinitesimals, as the laters’ powers are incredibly small but never vanishing.

Another way to see this is that it makes Taylor expansion exact by killing terms above a bound so it works naturally with the ecosystem surrounding it

Finally duals are very similar to complex in a way. i can be defined as root of X^2 + 1 = 0 even if it felt impossible initially, the dual number as a non nul solution of X^2 = 0 even if it is as counterintuitive.

No. Let's take a nonstandard proof of the intermediate value theorem on [0,1] by Nelson.

By the transfer principle it is enough to prove this for a standard continuous function f on [0,1] with f(0)<0Take a finite subset of [0,1] containing every standard point. Colour its points blue, green, or red according to whether f is negative, zero, or positive at tha point.

The first point of the interval is blue and the last red. Hence either awe can find some green point, or we can find two neighbouring points that have different colours, the first blue and the second red.

In the first case there is a zero, so we are done. In the second, let the neighbouring points be p and q. By the completeness of the real numbers, every nonstandard real in [0,1] is infinitesimally close to exactly one standard real. So p and q are infinitesimally close to some standard real number, let's call it z.

Standard continuous functions send infinitesimally close points to infinitesimally close points. So f(p) and f(q) are both infinitesimally close to f(z). But f(p) is negative and f(q) is positive. The only standard number infinitesimally close to both positive and negative numbers is zero. Thus f(z) is zero. This proves the theorem.

You tell me, which standard proof is this? It's certainly not the nested interval proof. Not the supremum proof. Not the bisection proof in disguise. Which argument does it wrap in slightly different language? Can you point to a single textbook, course note or lecture that gives such an argument?

No. One could of course argue that this is not simpler/shorter than the usual arguments. But it is very different from them. Saying that it's the same arguments repackaged in a different language is just wrong, and detracts from an otherwise valid point.

It is not.

I'll be honest: your one sentence response tells me you did not read the proof above in any detail.

I chose Nelson's proof precisely because its construction is well-studied and well-understood. The same construction of a mesh containing all standard points, with the coloring forcing a tiny multicolored cell, extends from the interval to the triangle. In one dimension you get two adjacent differently colored points; in two dimensions you get an infinitesimal triangle whose three vertices have the three relevant colors. Taking their common standard part and applying continuity gives a short proof of Brouwer's fxied-point theorem on the triangle.

But it is well-understood (there's a whole field studying such questions [2]) that the nested interval proof of the Intermediate Value Theorem does not generalize to proving Brouwer's fixed point theorem on the triangle [1]. This fact can be derived from a computability argument as well [3].

Nelson's argument does generalize to prove Brouwer, so it's not the nested intervals argument. But really, nobody cares about these technical reasons. It's obvious to most math undergraduates that Nelson's proof is not the nested interval proof, the clear absence of any nested construction kinda gives it away. The only reason it was necessary to get technical is that you did not really inspect the proof before claiming it was nested intervals. The technical results cited above are just a formal way to show that any correspondence you might imagine between the two proofs is just not there.

[1] Shioji/Tanaka: "Fixed Point Theory in Weak Second-Order Arithmetic", Annals of Pure and Applied Logic v47, pp 167188 (1990).

[2] https://en.wikipedia.org/wiki/Reverse_mathematics

[3] Potgieter: "Computable counter-examples to the Brouwer fixed point theorem", https://arxiv.org/abs/0804.3199 (2008).

In the standard formulation, you apply the Sperner's lemma to find smaller and smaller triangles, and apply compactness, precisely as in the standard proof of intermediate value theorem.

The rest of your post, where you quote reverse mathematics stuff, is completely irrelevant to the point I was making. Nothing I said is about what theorems follows from what axioms, but rather whether nonstandard analysis is meaningfully different, clearer, or more useful language than standard one. It is not.

1. Two comments ago you confidently claimed that Nelson's IVT proof is "the standard nested interval proof" with the limiting step written in nonstandard language. That is a straightforward claim about the structure of the proof, one that you didn't bother to substantiate, and that is straightforwardly false.

2. After I explained why it's false (Nelson's construction proves BFPT, which no nested interval type proof can do), you changed your response: now the Sperner lemma was a "crucial additional ingredient". But Nelson's combinatorial step, that opposite endpoint colors force a blue-red interval, _is_ the one-dimensional instance of the Sperner lemma (and indeed the base case when you prove Sperner's lemma for arbitrary dimensional simplices by induction; the analytic part is independent of dimension, once you find an infinitesimal multicolored simplex, you take its common standard part and apply continuity exactly as before).

3. Then you wrote this:

> In the standard formulation, you apply the Sperner's lemma to find smaller and smaller triangles, and apply compactness, precisely as in the standard proof of intermediate value theorem.

There is a standard proof of Brouwer via the Sperner lemma, and it is _also_ not of the same form as the standard nested interval proof of the IVT. In the nested interval proof, you find a sign-change interval, then find a smaller sign-change interval inside it, and so on. The intersection of all of these contains a point, and that's your zero. Nelson's proof does not do this, and neither does the standard proof of Brouwer via the Sperner lemma: you do not, and cannot, take a 3-color interior triangle, then find a smaller 3-color interior triangle inside it and so on. Even the first step would not work, since the inherited labelling does not satisfy the right boundary condition relative to the small triangle!

And this is also why the computability paper I cited ("where I quote reverse mathematics stuff" ;) was very much relevant. There can be no effective "nested triangle" proofs of the Brouwer fixed point theorem at all, because such a proof would let you compute a Brouwer fixed point, and there are examples of computable maps on the triangle without computable fixed points. If Nelson's IVT proof was the nested interval proof, then swapping in the higher-dimensional Sperner step would give a nested-type proof of BFPT. No such proof can exist. Since Nelson's argument proves the BFPT without any change to the analytic part, it is not a nested interval type argument.

You first misidentified Nelson's proof as nested intervals, and then treated Sperner as an additional ingredient even though the coloring step in Nelson's proof is already the corresponding Sperner argument. Those are both fairly serious misunderstandings about these proof. Given this, I don't think our exchange leaves readers with much confidence in your assessment of NSA's drawbacks and benefits. That's a disappointing outcome, as far as I'm concerned. There are good arguments to make that NSA adds little value to undergraduate education, such as simplicity or the difficulty of the prerequisites, and good conversations to be had about them. But "NSA proofs are the same proofs wrapped in a different language" is not one, and I wish you had just narrowed it instead of doubling down.

If that makes it easier for you to understand it, in the standard proof, you also color every point of the rectangle, with the color of the edge it retracts to (picking the colors of the vertices of the big triangle arbitrarily, just making sure that the color of each vertex is a color of one of the edges it belongs to, not one of the opposite edges). Then, an easy argument from continuity shows that no interior point will have points of three different colors arbitrarily close to it. Finally, applying Sperner's lemma as above proves that such point must nevertheless exist, obtaining contradiction with the existence of the retraction.

and then treated Sperner as an additional ingredient even though the coloring step in Nelson's proof is already the corresponding Sperner argument.

I don't understand what are you saying here. What I'm saying is that for the coloring proof of BFPT to work, whether clothed in standard or nonstandard language, you must perform a combinatorial argument that uses a topology of a triangle as a necessary ingredient, similar in shape to the proof of Sperner's lemma.

One post later, you answered that Nelson's IVT argument is in fact the "standard nested interval proof" with the limiting step rewritten in nonstandard language.

That claim is simply wrong. Why? Because Nelson's construction straightforwardly generalises to Brouwer, while the nested intervals proofs cannot. The discussion of reverse mathematics / computability is not a tangent, it explains precisely why Nelson's proof can generalise to give the BFPT in two dimensions, whereas the nested intervals proofs (which you claim is the same) cannot.

You then brought up that the BFPT generalisation of Nelson's argument needs the Sperner lemma as "crucial additional ingredient". Now you make the same point again:

> What I'm saying is that for the coloring proof of BFPT to work, whether clothed in standard or nonstandard language, you must perform a combinatorial argument that uses a topology of a triangle as a necessary ingredient, similar in shape to the proof of Sperner's lemma.

Presumably you keep pointing this out because you think it justifies some claim like '1D Nelson is actually nested intervals with the limiting step recast in nonstandard language, even if the 2D generalization of Nelson is not'.

But it does not. The combinatorial content is the same, the 1-dimensional interval case uses the topology of the domain just as much as the 2-dimensional triangle case does. The 2D argument wouldn't work on the annulus, and the 1D version would not work on the union of two disjoint intervals. The Sperner lemma is present in 1D, and present in 2D. If instead your point is only that proving the BFPT requires a harder case of the Sperner lemma than IVT, then of course it does. But what relevance does that have to the original claim that Nelson's IVT proof is the nested-interval proof? The proof of the Sperner lemma is pure combinatorics, it does not involve any (standard or nonstandard) analysis.

Or have you changed your mind on your earlier claim that Nelson's proof is "is the standard nested interval proof"?

If so, I think that's great, and closes the thread on whether NSA is largely the same arguments, since even the first proofs of the basic results are different.

If you still think that it's the nested interval proof, well, I am not sure what else to say, apart from linking the literature which studies this exact question, that I've already done, and that you dismissed as a tangent.

Either way, this discussion went on for too long at this point, so I won't monitor it further.

Serre's reply was "But we never wrote those books for students! We wrote them for researchers to have a handy reference for all proofs of basic results."

I agree with you in principle but I don't think that market cap is the right metric. Market cap captures a lot of assumptions around product mix and growth rates that have been in Stripe's favor for a long time.

The most apples-to-apples comparison is just looking at payments volume and ignoring all their other products. In that case, Stripe just recently overtook PayPal! PayPal is enormous! But Stripe has that compounding growth on its side and GP's argument has become outdated in a short amount of time.

This is ignoring the bit about pc which I just disagree with.

But that value is not tested or backed by the wider market.

Market cap of paypal is.

Also having just spaffed "$8bn" on openrouter, I would be surprised that they have enough resources to get the ~$50bn to buy paypal. Much less the work it would take to integrate a much larger company in to the "stripe" way