This seems like a lot of changes at once. I pulled your branch locally and the test suite errors out. Furthermore, many non-public functions defined in plotters-backend/src/math_guard.rs are not even used within the crate. Also many of the commit messages seem not to be fitting to the actual changes made. I.e. I cannot see how the message of commit e063303 fits to the underlying code changes.

Overall to me this looks a lot like it was generated by an AI/Coding Agent. Please explain yourself more carefully. Why did you choose this path? Unchecked math may be one problem but there are other considerations which might be made such as:

• unsanitized inputs
• incorrect types for input: avoid errors by only allowing proper values via the type system

For reference: I have also closed a PR by this account in the approx crate where a refactor was proposed which did not seem to add much value but rather was even considered a regression in my eyes.
brendanzab/approx#104

For reference: I am not a maintainer of the plotters crate although I have contributed previously. So I have no authority about the code within this crate and which PR to accept.

If you have worked on the project for a few weeks I am sure that you will not have a problem to justify your approach and go into more detail about the comments that I have made.

In general, there is nothing wrong with using Coding Agents but the changes made by them should be explainable and serve a particular purpose. My comments should be understood merely as a review of the produced code, regardless if these changes came from a human hand, were machine assisted or fully generated by a coding tool. A code review is essential in maintaining the quality of the solution. I am sure that you can understand this.

Speaking in more personal terms: I am sorry if I overstepped any boundaries. I did not wish to insult you. My comments were only meant to be of technical nature and not personally targeted against you.

For reference: I am not a maintainer of the plotters crate although I have contributed previously. So I have no authority about the code within this crate and which PR to accept.

If you have worked on the project for a few weeks I am sure that you will not have a problem to justify your approach and go into more detail about the comments that I have made.

In general, there is nothing wrong with using Coding Agents but the changes made by them should be explainable and serve a particular purpose. My comments should be understood merely as a review of the produced code, regardless if these changes came from a human hand, were machine assisted or fully generated by a coding tool. A code review is essential in maintaining the quality of the solution. I am sure that you can understand this.

Speaking in more personal terms: I am sorry if I overstepped any boundaries. I did not wish to insult you. My comments were only meant to be of technical nature and not personally targeted against you.

I wrote the code. The unit tests, sure I had an ML write them. there were none for the plotters files I was working in and they needed them. The math guard itself is a pretty simple file. I don't mind justifying changes. But this code base uses unsafe math everywhere. Moreover it was compiling and passing when I submitted the PR. I would be clear that I had planned to introduce the the math changes throughout the crate if this was approved. As some change needs to take place to avoid the unsafe arithmetic that occurs. Many of the planned changes I see as necessary will change API shapes because there are several public methods that return a primitive value, e.g. i32. When they will need to return Result<i32, SomeError> because of the need to do verified arithmetic. Why did I write a new file for this? Because math_guard looked like the simplest way to quickly make the arithmetic safe and handle errors. Why did I write a custom Error enum for MathErrors? because there needs to be one for this class of errors. And the math_guard module itself is meant to be pretty straightforwardly a convenience module, because the alternative to getting clippy compliance for arithmetic safety would be a much larger refactor and/or bringing in more external crates. I was trying to be surgical in the changes.

The plotters-backend had 3 separate places where an error was being defined, two were enums, and 1 was a struct. I unified those as well and implemented the math_error for them. As to why not do sanitizing inputs? Because the arithmetic is the problem, and not handling errors that are resulting in unnecessary panics. The code shouldn't be panicking if a user accidentally swaps two values, or an intermediary mathematical operation results in a divide by zero because it was not checked for. Moreover, I extended the math_guard to handle some of the issues that I saw with casting. There is a lot of casting and long term it would be good to make a decision on which data types to use and why, but for the time being, I saw the need to also try to clean up how casting was being done.

Beyond the commit, I still do not see how using the language based modularity to separate concerns for a code base is a regression. I do not need to dispute that though. I tried to follow coding standards. And again, with any codebase I work on I try to add unit testing where possible. I generated the unit tests for the backend model with an LLM, that is absolutely true, before implementing the changes I made, so I could be sure that my changes were not breaking the codebase. And since those modules didnt have any unit tests to begin with, and they are for verifying the code does what it is supposed to do locally. I had them generated.

I do not see that the changes I made were that unclear. I am happy enough to leave the codebase alone. It has several other issues I came across while working on it. I do not see the need to continue to contribute at this time. I thought this was evident in my PR comment.