If you've not come across e-graphs and egg then you may find this interesting reading: https://egraphs-good.github.io
They allow the application of rewrite rules (until saturation) but the nature of the data structure also helps to ensure that the data structure representing the expression does not grow exponentially in certain situations. On Monday, January 2, 2023 at 12:33:38 PM UTC syle...@gmail.com wrote: > I think that simplify or evaluation should rather be decomposed in many > components > such that 'simplify' is not a silver bullet solution, > but users can mix in some components of 'simplify' to solve math problems > in the very precise way what they want to. > I still need some time to write out full proposal about this because I'm > studying some part of it to fill in the gaps. > > On Sunday, January 1, 2023 at 7:30:20 PM UTC+2 gu...@uwosh.edu wrote: > >> I agree that we should avoid arguments unrelated to the question at hand. >> >> For the part of this proposal that I think I understand (avoiding >> evaluation/simplification unless requested), does this imply you want the >> user to deal with collapsing expressions to avoid them becoming too large? >> >> Jonathan >> >> On Saturday, December 31, 2022 at 8:05:11 AM UTC-6 syle...@gmail.com >> wrote: >> >>> > I, like you, am not a mathematician by training. Your training is in >>> engineering mine is in physics/chemistry. I do not claim to be cognizant of >>> all details necessary to generate completely general representations of >>> many mathematical operations. >>> >>> If I have to apologize, I should be. >>> I would not want to see this thread contaminated by arguments by >>> university major, job experience, ... >>> and which makes the conversation toxic and look like a fallacy overall. >>> >>> On Thursday, December 29, 2022 at 2:34:54 AM UTC+2 S.Y. Lee wrote: >>> >>>> And at least the term-algebraic definition of computing total >>>> derivative, is not evaluating dy/dx -> 0. In that sense, >>>> if the chain rule is implemented faithfully, dy/dx itself becomes >>>> normal form, such that no further computation is done for it. >>>> And the triple product rule for derivative is implemented as something >>>> like viewing derivative as fraction, which may not be very mathematically >>>> sound reasoning, >>>> but for practices in term rewriting, we try to detach the semantics and >>>> try to solve problems only by syntax, which also gives a plausible >>>> reasoning how to combine problem solving skills, and even more abstract or >>>> deeper view of it. >>>> >>>> On Thursday, December 29, 2022 at 2:23:07 AM UTC+2 S.Y. Lee wrote: >>>> >>>>> I think that software engineers should be satisfied for solving 'easy' >>>>> and 'decidable' problems for derivative, like formal deriviative >>>>> <https://en.wikipedia.org/wiki/Formal_derivative>, >>>>> which is sometimes a sound reasoning for the actual >>>>> physical/analytical derivative, however, not always. >>>>> and even if you attempt to relate more physical implementation just by >>>>> 'software engineering', >>>>> I'd only warn that it would not be merely more than some 'heuristics', >>>>> and such 'heuristics' are just going to define less uniform and >>>>> awkward formal grammar <https://en.wikipedia.org/wiki/Formal_grammar> >>>>> about the inputs the software it accepts, >>>>> rather than making it more deeply connected with the physics. >>>>> >>>>> Similar as how you'd usually perceive that numeric analysis need >>>>> hypothesis about approximating the physical world problem by numeric >>>>> errors, >>>>> I also believe that any symbolic computation need hypothesis that it >>>>> just approximates the the physical/business world problem as syntactical >>>>> way. >>>>> And to develop the useful and stable library, the only thing to >>>>> concern is that we get at least the syntactical part correctly. >>>>> >>>>> On Thursday, December 29, 2022 at 12:13:19 AM UTC+2 gu...@uwosh.edu >>>>> wrote: >>>>> >>>>>> S.Y., >>>>>> >>>>>> The only part of what you are proposing that I believe I understand >>>>>> is that you suggest sympy should avoid automatic >>>>>> evaluation/simplification/collapse of expressions. The specific example >>>>>> I >>>>>> can think of where this would often be useful is with differentiation >>>>>> (the >>>>>> default behavior of Derivative() does this, but not the convenience >>>>>> implementation diff()). I have certainly had to be careful while trying >>>>>> to >>>>>> define a partial derivative operation that works the way we usually use >>>>>> it >>>>>> in the physical sciences (for thermodynamics in particular). Can you >>>>>> illustrate how your proposal would provide a clean and mathematically >>>>>> sound >>>>>> way of defining things such as a total differential (e.g. df = (df/dx)_y >>>>>> dx >>>>>> + (df/dy)_x dy) and the derivative relationships they imply? Would this >>>>>> ease the handling of the circularity of functional dependence implied by >>>>>> the Euler circular chain rule used to figure out what combinations of >>>>>> measurable quantities (partial derivatives) will provide values for >>>>>> partial >>>>>> derivatives that cannot be measured directly? >>>>>> >>>>>> I appreciate your interest in helping to improve the open source >>>>>> mathematical offerings. Can you provide a baby implementation that does >>>>>> not >>>>>> impinge on the intellectual property of your employer (Qanda) for us to >>>>>> consider? >>>>>> >>>>>> A word to the wise: I know you are not a native English speaker. >>>>>> However, I think you need to be more careful about broad statements such >>>>>> as >>>>>> the one below. >>>>>> >>>>>> On Wednesday, December 28, 2022 at 1:35:17 PM UTC-6 syle...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> I believe that my prompt can already address and solve the problem >>>>>>> below, and beyond the fact that the calculus is merely Turing-complete >>>>>>> (such that we can develop a library to be closed against >>>>>>> anti-pattern <https://en.wikipedia.org/wiki/Anti-pattern> practices >>>>>>> by developers for stability), >>>>>>> it also provides pretty much well-studied and uniform representation >>>>>>> for the application, without introducing some deviated object by some >>>>>>> nerds >>>>>>> and having poorly defined calculus over it. >>>>>>> >>>>>>> - Abstract algebra <https://github.com/sympy/sympy/pull/19750> >>>>>>> - Decimal object <https://github.com/sympy/sympy/issues/17648> >>>>>>> - Algebra with SymPy <https://github.com/gutow/Algebra_with_Sympy> >>>>>>> - ... >>>>>>> >>>>>> >>>>>> I, like you, am not a mathematician by training. Your training is in >>>>>> engineering mine is in physics/chemistry. I do not claim to be cognizant >>>>>> of >>>>>> all details necessary to generate completely general representations of >>>>>> many mathematical operations. Thus, I am always happy to get issues with >>>>>> my >>>>>> understanding corrected. However, I have been working with and teaching >>>>>> about the multidimensional partial differential equations of quantum >>>>>> mechanics and thermodynamics for longer than you've been alive. They are >>>>>> very specific applications of calculus over a well specified domain. >>>>>> Please >>>>>> do not belittle things that allow physical scientists such as myself to >>>>>> work effectively in that domain. I suggest in the future you provide >>>>>> specific examples of where these tools do not work and then we can >>>>>> address >>>>>> those specific issues. It may be that a more general implementation that >>>>>> can then be used to easily provide the same behavior is possible, but we >>>>>> need specific examples. >>>>>> >>>>>> Regards, >>>>>> Jonathan >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/37a38f7b-aa6b-480e-88d5-d93c22d98a67n%40googlegroups.com.
