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]]
Similarly :
sage: solve(sin(x)==1/2, x, to_poly_solve="force")
[x == 5/6*pi + 2*pi*z37, x == 1/6*pi + 2*pi*z39]
It seems straightforward to add "assume(z39, 'integer')" to the actions
taken by an hypothetic %auto_constants magic in the second case. In the
first case, it is less obvious : r1 could be any complex.
Ideas ?
-
Emmanuel Charpentier
Le lundi 19 mars 2018 16:04:07 UTC+1, Emmanuel Charpentier a écrit :
>
> 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 of remarks :
>
> - 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 injection done
> by default, but controllable via an option. *Prima facie,* our targets
> are solve and desolve + their friends. But I forget some other ones almost
> surely... Hints ?
> - The idea of a line magic (i. e. enabling automatic_variables for the
> next instruction or block) should be paired with a corresponding cell
> magic.
> - Another pair of magics could control the *silent* automatic
> declaration of new symbolic variables.
>
> The first case might be covered by patching the current implementation of
> the target functions ; the control of the injection of the new variables
> (in fact, symbolic constants) in the relevant name space could be
> controlled by yet another (pair of) magic(s).
>
> Hence the possible design of the new magics :
>
> - %(%)auto_constants : control whether Maxima-generated constants are
> injected in the relevant namespace. Default : True.
> - %(%)auto_variables : control whether unknown names trigger the
> creation of symbolic variables thus named. Triggers a message. Defaulf :
> False.
> - %(%)silent_auto_variables : control if the message signaling the
> creation of an automatic variable should vbe supressed. Defaulf : False.
>
>
> Critics ? Suggestions ? Lazzi ?
>
> This just leaves the $10000 question : who implements this ? ;-).
>
> --
> Emmanuel Charpentier
>
> Le lundi 19 mars 2018 14:06:15 UTC+1, Nicolas M. Thiéry a écrit :
>>
>> On Thu, Mar 15, 2018 at 08:49:02AM -0700, William Stein wrote:
>> > On Thu, Mar 15, 2018 at 7:43 AM, Emmanuel Charpentier
>> > <emanuel.c...@gmail.com> wrote:
>> > > [...] However, most CASes now available do away without this
>> mandatory declaration.
>> >
>> > And hence Sage should have automatic_names as a non-default *option*.
>>
>> Yeah; it's all a balance between simplicity vs risk of confusion. From
>> using, teaching, and witnessing people teach SageMath, there are some
>> contexts where you (or more likely your teacher!) know what you are
>> doing, there is no risk of confusion, and simplicity primes. Most of
>> the time we don't want it though. So +1 as well on automatic_names as
>> an option not set by default. Also +1 on the message when a variable
>> is created.
>>
>> Finally, I could suggest to write it as:
>>
>> %automatic_names
>>
>> to highlight that this is a magic command that alters the behavior of
>> the interpreter.
>>
>> Cheers,
>> Nicolas
>> --
>> Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
>> http://Nicolas.Thiery.name/
>>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
