I agree with Aaron that trying to keep exact expressions makes the most sense in an interactive environment (IPython, Jupyter, etc.). Sagemath uses a preparser <https://doc.sagemath.org/html/en/reference/repl/sage/repl/preparse.html> before passing the code to Python. I'm not sure if Sympy could adopt this.
Jonathan On Sunday, May 16, 2021 at 6:20:58 AM UTC-5 da...@dbailey.co.uk wrote: > On 16/05/2021 05:42, Aaron Meurer wrote: > > On Sat, May 15, 2021 at 3:02 PM David Bailey <da...@dbailey.co.uk> > wrote: > >> On 14/05/2021 23:01, Oscar Benjamin wrote: > >> > >> That's a great video but it's describing something very different. > There he types exact input into the calculator and then calculator somehow > makes a numeric/symbolic approximation that goes wrong. I'm not talking > about changing anything for exact input. I'm only referring to the first > step of passing a float to sympy. Maybe we need a more limited version of > nsimplify for this. I can certainly see the reasons for not trying to > convert float to Rational but I can also see how much of a problem it is > for users. The "power users" will not have so much of a problem converting > their input to Float if that's what they meant. > >> > >> > >> Yes, but surely that would just lead to a new set of anomalies because > the float has finite precision. I mean it would be possible to translate > floats back into fractions for simple fractions like 3/4, but what about > 123456789123456788/123456789123456789? Also, people sometimes pass > intentional floats to SymPy without being power users! > >> > >> Wouldn't it be possible to persuade the Python team to implement > auto_int_to_Integer outside of IPython - it can't be hard to do? > > My argument is that it's really only a good idea to do this in an > > interactive environment. In that case, you are probably using > > something like IPython or Jupyter notebook. > > > > It would in theory be possible to make it work in a Python script > > using a codec trick > > (https://rahul.gopinath.org/post/2019/12/25/python-macros/). At that > > point, you are more or less creating your own DSL. > > > > For any kind of upstream change to Python itself, you have to remember > > that 99% of Python users don't want this feature. So you'd have to > > implement it in a way that doesn't affect them. > > > > Aaron Meurer > > Well to be clear, I was primarily disagreeing with Oscar's suggestion, > which (very unusually!) seemed a seriously retrograde step - trying to > recover fractions from floating point representations. > > I suppose I find it frustrating that while SymPy run from Python > provides something very, very close to a general algebraic manipulation > language, it has problems inputting expressions like 2/3*x. I could > imagine some potential users encountering that 'feature' on their first > experiments with SymPy, and just abandoning SymPy without further thought. > > If Python gave users a hook that would let them preprocess every line of > input, that would solve this problem and perhaps be really useful for > some other Python based applications. I really don't know the politics > of whether such a change would be accepted or not - so it may not be > worth further discussion. > > David > > -- 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/611ca60a-8eda-4e6b-9492-32ebdb760e6bn%40googlegroups.com.
