Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

> > Shall the Euler constant, the imaginary number, the numerical > > approximation and the R interpreter be locally diabled ? What about > > 2*i*pi*j ? > > If I could do things over, then none of those would be in the global > namespace by default. This is very difficult to change now,

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Mon, Mar 19, 2018 at 2:06 PM, Nicolas M. Thiery wrote: > On Thu, Mar 15, 2018 at 08:49:02AM -0700, William Stein wrote: >> On Thu, Mar 15, 2018 at 7:43 AM, Emmanuel Charpentier >> wrote: >> > [...] However, most CASes now available do

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Fri, Mar 16, 2018 at 6:13 PM, William Stein wrote: > On Fri, Mar 16, 2018 at 9:47 AM, Nils Bruin wrote: >> On Thursday, March 15, 2018 at 7:43:45 AM UTC-7, Emmanuel Charpentier wrote: >>> >>> Two chronic offenders are Maxima's solver and differential equation

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Related ticket, mentioning var and automatic_names: - SageMath #9048: inconsistencies between the terminal version and the notebook https://trac.sagemath.org/ticket/9048 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Mon, Mar 19, 2018 at 12:43 PM, Thierry wrote: > On Mon, Mar 19, 2018 at 08:32:23AM -0700, Nils Bruin wrote: >> On Monday, March 19, 2018 at 8:04:07 AM UTC-7, Emmanuel Charpentier wrote: >> > >> > >> > >> >- Some functions (mostly inherited from Maxima) *do*

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Mon, Mar 19, 2018 at 08:32:23AM -0700, Nils Bruin wrote: > On Monday, March 19, 2018 at 8:04:07 AM UTC-7, Emmanuel Charpentier wrote: > > > > > > > >- Some functions (mostly inherited from Maxima) *do* already create > >new symbolic variables, but do not inject them in the relevant >

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Monday, March 19, 2018 at 8:04:07 AM UTC-7, Emmanuel Charpentier wrote: > > > >- Some functions (mostly inherited from Maxima) *do* already create >new symbolic variables, but do not inject them in the relevant namespace. >In *this* case (and this case only), I'd like to have this

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Addendum to the previous answer : solve at least may generate symbolic constants with domain constraints. If we accept the idea of auto-declaring them, should we add the relevant constraints ? Example : sage: var("x,y") (x, y) sage: solve([3*x+y==0,6*x==-2*y],[x,y]) [[x == -1/3*r1, y == r1]]

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

To summarize the previous answers (and nitpick a bit) : automatic_names - may come handy ; - shouldn't be mandatory - shouldn't be the default - should print a warning when fired. I also liked the idea of introducing a new magic controlling that feature. However, I have a couple

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On 19/03/18 15:06, Nicolas M. Thiery wrote: On Thu, Mar 15, 2018 at 08:49:02AM -0700, William Stein wrote: On Thu, Mar 15, 2018 at 7:43 AM, Emmanuel Charpentier wrote: [...] However, most CASes now available do away without this mandatory declaration. And

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Thu, Mar 15, 2018 at 08:49:02AM -0700, William Stein wrote: > On Thu, Mar 15, 2018 at 7:43 AM, Emmanuel Charpentier > wrote: > > [...] However, most CASes now available do away without this mandatory > > declaration. > > And hence Sage should have

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Fri, Mar 16, 2018 at 9:47 AM, Nils Bruin wrote: > On Thursday, March 15, 2018 at 7:43:45 AM UTC-7, Emmanuel Charpentier wrote: >> >> Two chronic offenders are Maxima's solver and differential equation >> solver(s), which routinely add new symbolic constants as required by their

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Thursday, March 15, 2018 at 7:43:45 AM UTC-7, Emmanuel Charpentier wrote: > > Two chronic offenders are Maxima's solver and differential equation > solver(s), which routinely add new symbolic constants as required by their > inputs. In these cases, getting the names of these new variables and

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On 2018-03-15, William Stein wrote: > I don't remember, but automatic_names can (or should) print a message > when it automatically creates a new symbolic variable -- this helps > deal with some people's concerns... Indeed. Having a warning message alerting the user of

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Thu, Mar 15, 2018 at 7:43 AM, Emmanuel Charpentier wrote: > [...] However, most CASes now available do away without this mandatory > declaration. And hence Sage should have automatic_names as a non-default *option*. See the mission statement, which is to create

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Hi Emmanuel, On 2018-03-15, Emmanuel Charpentier wrote: > One has also to consider the case (important in Sage) of the > indeterminate(s) of a polynomial. Do we risk introducing an ambiguity if > allowing automatic variable declaration ? Of course. If you create

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Such a feature might come in handy so solve a couple of cases where sage creates (or receives from its subsystems) a symbolic expression with "new" variables. Two chronic offenders are Maxima's solver and differential equation solver(s), which routinely add new symbolic constants as required

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

> > Anyway, certainly it should (in principle) be *implemented* for any Sage > > interface, including Jupyter. I just don't know about it becoming the > > default. > > Certainly nobody's talking about turning it on by default--just that > the feature exists, people do use it, and there's no

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Wed, Mar 14, 2018 at 12:52 PM, kcrisman wrote: > I recall discussions about this quite a few years ago, and the consensus was > to be careful what you wish for. Too many typos would then mysteriously > become variables. So (even though I certainly think it is a very

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

I recall discussions about this quite a few years ago, and the consensus was to be careful what you wish for. Too many typos would then mysteriously become variables. So (even though I certainly think it is a very useful facility in many case) the potential for confusion was pretty great. I

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Hi! On 2018-03-13, Erik Bray wrote: > I see no reason this feature needs to be confined to the legacy > Notebook, as opposed to being in Sage proper. Then that feature would > be usable at the command-line, as well as in the Jupyter Notebook. If I understand correctly,

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Tue 2018-03-13 17:32:11 UTC, Erik Bray: > > Paul Zimmerman pointed out to me that there's a feature of the legacy > Sage Notebook, automatic_names() [1], which turns on automatic > creation of symbolic variables and functions when they are not already > defined. [...] > I see no reason this