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/3ec034b7-afc1-4fd6-b081-8500e7797dcen%40googlegroups.com.
