This seems to be going down the same path as previous conversations. I don't think that anyone will come away satisfied.
I recommend that both sides resist the urge to fight. Alternatively Richard and Joachim, perhaps the two of you would enjoy continuing this conversation privately off list? On Mon, Apr 28, 2014 at 3:43 AM, Richard Fateman <fate...@gmail.com> wrote: > > > On Monday, April 28, 2014 12:29:32 AM UTC-7, Joachim Durchholz wrote: >> >> >>> Worse, it is reproducing the chain of errors in design that led >> >>> to existing computer algebra systems. >> >> >> >> Which ones do you mean? >> >> >> > managing assumptions. treating algebraic roots. fo 2 examples. >> >> That's areas. >> What are the design errors? What would be better designs? >> For the assumptions - do you mean the existing system, or the new system >> that's being implemented? >> > > The previous system apparently made the same mistakes as previous > computer algebra systems. Perhaps because the programmers were > not sufficiently aware of what was done before. I don't know what has > been done for the new system, but if the programmers are STILL ignorant > of the history of this problem, I wonder if it will be better. > > >> >> >> And in general, if you think this is all misguided - what are you >> >> doing here? >> >> >> > trying to educate. the world does not need more crappy duplicative >> > software. even in python. >> >> We have a saying in Germany: If you wish to give advice, pick the people >> up where they stand. >> > > We have a saying in this country that "three months in the programming lab > can > save you half an hour in the library" > > >> >> What I'm reading from you is theory, with no indication how to apply, or >> where to start, or anything. > > > I'm sorry, but I'm not paid enough to direct you from day to day. Reading > a book or > some papers, maybe taking a course, would help. > > >> You do not seem to even have looked into >> the overall code structure, to identify the low-hanging fruit. > > I'm not interested in picking low-hanging fruit and reprogramming stuff in > python. > I'm interested in noticing the high-level bad design which will make the > system > no better, and probably worse, than what has been done before > > >> You don't >> even have a plan to identify which fruit are hanging at what altitude... >> and I'm not seeing how telling us "you're doing it all wrong" is going >> to help SymPy along if you stay silent on what's wrong, or in what ways >> it is wrong, or (most importantly) how it could be done better. >> > > If you think you are doing it all right, and that the only changes needed > are incremental fixes to low hanging fruit, then feel free to continue > exactly the way you are going. Maybe sympy II will be better. Or > maybe some other post-python language will become popular and > another group of people will write sympy (I) in that language and > re-invent > the same problematical designs. > > >> >> Not that I can't sympathize with your points, or your position. Being >> specific requires work, and I guess you don't have an unlimited time >> budget. > > > It is not my job or interest to rewrite programs (some of which I have > written) > in python for the sake of python > > >> I can even sympathize with your Lisp preference (though I'd >> prefer Haskell since it's 90% of Lisp's capabilities but ten times the >> guarantees, plus performance aspects would be so different that it's an >> experiment worth actually doing). >> > You are welcome to write in Haskell, but that doesn't improve the design, > ordinarily. > > >> But... it's not going to lead anywhere at the level I'm seeing here. >> >> >> Just curious what thinking is motivating you. >> > >> > what motivates you? >> >> The realization that it was a repeated case of unhelpful feedback. >> > I'm not going to read the python code and tell you how to diddle it. > > >> The wish to improve that situation. >> > > I observed the behavior and from that deduced the design errors. > > It is your job to study existing literature and systems if you want to do > something at least as good. There are thousands of "commands" constituting > numerous computational subsystems and interacting data structures in > a system like Mathematica, Maple, Maxima. > > Re-programming in python is one possibility. Studying and improving them > while > programming in python is another, better idea. Re-inventing them from > scratch > is, with high probability, a worse idea. > > If you find this unhelpful, it is probably because you are re-inventing, > and don't want to > hear... > ' > > -- > 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 post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/c4d75d90-8bfd-4a90-adce-43e1e5998012%40googlegroups.com<https://groups.google.com/d/msgid/sympy/c4d75d90-8bfd-4a90-adce-43e1e5998012%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Ehr-iL6ZXxjZBRJnKxvUsNFHA7YzeXZM6kqj%2Bf0k9Ycg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
