Re: [sage-support] Re: 2 questions on var

2022-04-16 Thread G. M.-S.
Thanks for the explanation, Nils (even if I am not sure to have understood
everything).

Guillermo

On Sat, 16 Apr 2022 at 22:56, Nils Bruin  wrote:

> On Saturday, 16 April 2022 at 05:37:16 UTC-7 list...@gmail.com wrote:
>
>>
>> Thanks Samuel and Emmanuel.
>>
>> Follow up question:  Why does
>> var('lambda',n=1)
>> fail?
>>
>
> Because the code in question tests the string actually passed in for
> whether it's a valid python identifier.
>
> Probably this is because the "n" optional argument was only added later.
> However, there's been quite a discussion on what the appropriate binding
> behaviour should be. One option would be to bind the actual returned result
> (a tuple of the constructed symbols) to a name in the current namespace.
> i.e., the result of
>
> x = SR.var('x',n=3)
>
> For that behaviour, the passed-in name would have to be a valid
> identifier. So to future-proof sage, perhaps it's better to have this
> stricter check.
>
> You can create symbols without the check: SR.symbol('lambda') works just
> fine. To create the symbols you'd like, you can do:
>
> L = (SR.symbol("lambda{}".format(i)) for i in range(3))
>
> binding them to corresponding symbols would require a little more work .
> It's basically
>
> for c in L:
> globals()[str(c)] = c
>
> which works when typed in as-is, but requires some more trickery if it is
> wrapped in a function in some module, due to the semantics of the actual
> "globals()" call in python.
>
> [in general, for anything other than direct interactive use, you should
> probably not rely on binding injections]
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/CANnG18_GP8Y0Ftx-Gt0RFM4KUd3%2B%3Dueh%3DQTBQ_jGsrAJoPKwpg%40mail.gmail.com.


Re: [sage-support] Re: 2 questions on var

2022-04-16 Thread Nils Bruin
On Saturday, 16 April 2022 at 05:37:16 UTC-7 list...@gmail.com wrote:

>
> Thanks Samuel and Emmanuel.
>
> Follow up question:  Why does
> var('lambda',n=1)
> fail?
>

Because the code in question tests the string actually passed in for 
whether it's a valid python identifier.

Probably this is because the "n" optional argument was only added later. 
However, there's been quite a discussion on what the appropriate binding 
behaviour should be. One option would be to bind the actual returned result 
(a tuple of the constructed symbols) to a name in the current namespace. 
i.e., the result of

x = SR.var('x',n=3) 

For that behaviour, the passed-in name would have to be a valid identifier. 
So to future-proof sage, perhaps it's better to have this stricter check.

You can create symbols without the check: SR.symbol('lambda') works just 
fine. To create the symbols you'd like, you can do:

L = (SR.symbol("lambda{}".format(i)) for i in range(3))

binding them to corresponding symbols would require a little more work . 
It's basically

for c in L:
globals()[str(c)] = c

which works when typed in as-is, but requires some more trickery if it is 
wrapped in a function in some module, due to the semantics of the actual 
"globals()" call in python.

[in general, for anything other than direct interactive use, you should 
probably not rely on binding injections]

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/99f5b3eb-5e57-4f3f-922c-4a907cea4ba2n%40googlegroups.com.


Re: [sage-support] Re: 2 questions on var

2022-04-16 Thread G. M.-S.
Thanks Samuel and Emmanuel.

Follow up question:  Why does
var('lambda',n=1)
fail?

I know that the name "lambda" is not a valid Python identifier, but I am
asking for "lambda0", "lambda1".

Guillermo

On Tue, 8 Mar 2022 at 19:19, Emmanuel Charpentier <
emanuel.charpent...@gmail.com> wrote:

> even more simpler :-) :
>
> sage: V=var("v", n=8)
> sage: V
> (v0, v1, v2, v3, v4, v5, v6, v7)
> sage: v2
> v2
> sage: V[2]
> v2
>
> *“Who could ask for anything more ?”*
> Le mardi 8 mars 2022 à 08:20:07 UTC+1, slelievre a écrit :
>
>> Even more practical, I find, is to name the tuple of indexed variables:
>> ```
>> sage: v = SR.var('v', n=8)
>> sage: v
>> (v0, v1, v2, v3, v4, v5, v6, v7)
>> ```
>> and to use index notation `v[k]` instead of `vk` to use the variables.
>> ```
>> sage: v[0]
>> v0
>> sage: v[7]
>> v7
>> ```
>>
>> That does not assign the variables to the names `v0` to `v7`:
>> ```
>> sage: v2
>> Traceback (most recent call last)=
>> ...
>> NameError: name 'v2' is not defined
>> ```
>>
>> If you really want to use `v0` to `v7` instead of `v[0]` to `v[7]`,
>> follow the implementation in `var` (accessed with `var??`),
>> which simply amounts to:
>> ```
>> G = globals()
>> for vk in v:
>> G[repr(vk)] = vk
>> ```
>>
>> After that:
>> ```
>> sage: v2
>> v2
>> ```
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/CANnG18_%2BFg%2B5xuwgJBN_-HH5UgGnmCwdz_3si10hgfv3HhU8tA%40mail.gmail.com.


Re: [sage-support] Re: 2 questions on var

2022-03-08 Thread Emmanuel Charpentier


even more simpler :-) :

sage: V=var("v", n=8)
sage: V
(v0, v1, v2, v3, v4, v5, v6, v7)
sage: v2
v2
sage: V[2]
v2

*“Who could ask for anything more ?”*
​
Le mardi 8 mars 2022 à 08:20:07 UTC+1, slelievre a écrit :

> Even more practical, I find, is to name the tuple of indexed variables:
> ```
> sage: v = SR.var('v', n=8)
> sage: v
> (v0, v1, v2, v3, v4, v5, v6, v7)
> ```
> and to use index notation `v[k]` instead of `vk` to use the variables.
> ```
> sage: v[0]
> v0
> sage: v[7]
> v7
> ```
>
> That does not assign the variables to the names `v0` to `v7`:
> ```
> sage: v2
> Traceback (most recent call last)=
> ...
> NameError: name 'v2' is not defined
> ```
>
> If you really want to use `v0` to `v7` instead of `v[0]` to `v[7]`,
> follow the implementation in `var` (accessed with `var??`),
> which simply amounts to:
> ```
> G = globals()
> for vk in v:
> G[repr(vk)] = vk
> ```
>
> After that:
> ```
> sage: v2
> v2
> ```
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/37dc1c01-6cab-41cd-b8e2-b3a06c4e4509n%40googlegroups.com.


Re: [sage-support] Re: 2 questions on var

2022-03-07 Thread slelievre
Even more practical, I find, is to name the tuple of indexed variables:
```
sage: v = SR.var('v', n=8)
sage: v
(v0, v1, v2, v3, v4, v5, v6, v7)
```
and to use index notation `v[k]` instead of `vk` to use the variables.
```
sage: v[0]
v0
sage: v[7]
v7
```

That does not assign the variables to the names `v0` to `v7`:
```
sage: v2
Traceback (most recent call last)=
...
NameError: name 'v2' is not defined
```

If you really want to use `v0` to `v7` instead of `v[0]` to `v[7]`,
follow the implementation in `var` (accessed with `var??`),
which simply amounts to:
```
G = globals()
for vk in v:
G[repr(vk)] = vk
```

After that:
```
sage: v2
v2
```

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/89696796-8ead-479e-9b28-1155b998b2ean%40googlegroups.com.


Re: [sage-support] Re: 2 questions on var

2022-03-06 Thread G. M.-S.
I mean, the implementation of top-level var, of course.

On Sun, 6 Mar 2022 at 23:35, G. M.-S.  wrote:

>
> Thanks, Nils.
>
> A further question is thus how to do something like
> v0,...,v*k*=SR.var('v', n=*k*)
> when *k* varies.
>
> Should I look at the implementation of SR.var?
>
> Guillermo
>
> On Sun, 6 Mar 2022 at 19:26, Nils Bruin  wrote:
>
>> On Sunday, 6 March 2022 at 09:13:42 UTC-8 list...@gmail.com wrote:
>>
>>>
>>> Beginner's questions, I guess.
>>>
>>> Some time ago, Emmanuel Charpentier wrote
>>>
>>> var("v", n=2)
>>>
>>> which gives
>>>
>>> (v0, v1)
>>>
>>> Where is this documented?  I have been unable to find keywords for var
>>> other than domain and latex_name.  Are there any others?
>>>
>>
>> This is documented on SR.var , which is slightly different from the
>> top-level "var" you are referring to. It looks like the documentation on
>> the top-level one wasn't updated when the feature was added to SR.var.
>> Since top-level var just wraps SR.var, it automatically got the feature too.
>>
>>
>>> Another question:
>>> I have learnt to write
>>> x,y,z=var('x,y,z')
>>>
>>
>> You can do that, but with the top-level var it's not necessary (this is
>> exactly where it differs from SR.var) :
>> it will inject bindings for the created symbols in the current name
>> space. This is a hack that is convenient for interactive use. In library
>> code, you must use SR.var instead, in which case you have to write
>>
>> x,y,z = SR.var('x,y,z')
>>
>> ( with just "SR.var('x,y,z')" you'd create the symbols but you wouldn't
>> bind them to anything).
>>
>> Is it possible to do the same for
>>> v0,v1,v2=var('v', n=3)
>>> without having to write explicitly the LHS?
>>>
>>
>> Yes, that already works. If you use
>>
>> var('v', n=3)
>>
>> the names v0,v1,v2 in your current scope will be bound to the newly
>> created symbols.
>>
>> There's been discussion about this when it was implemented:
>>
>> https://trac.sagemath.org/ticket/22813
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/CANnG18-qtiW4%3DYxC2RQznLt1g%2BYEa6VvQhu8byt3aiifsbWtsg%40mail.gmail.com.


Re: [sage-support] Re: 2 questions on var

2022-03-06 Thread G. M.-S.
Thanks, Nils.

A further question is thus how to do something like
v0,...,v*k*=SR.var('v', n=*k*)
when *k* varies.

Should I look at the implementation of SR.var?

Guillermo

On Sun, 6 Mar 2022 at 19:26, Nils Bruin  wrote:

> On Sunday, 6 March 2022 at 09:13:42 UTC-8 list...@gmail.com wrote:
>
>>
>> Beginner's questions, I guess.
>>
>> Some time ago, Emmanuel Charpentier wrote
>>
>> var("v", n=2)
>>
>> which gives
>>
>> (v0, v1)
>>
>> Where is this documented?  I have been unable to find keywords for var
>> other than domain and latex_name.  Are there any others?
>>
>
> This is documented on SR.var , which is slightly different from the
> top-level "var" you are referring to. It looks like the documentation on
> the top-level one wasn't updated when the feature was added to SR.var.
> Since top-level var just wraps SR.var, it automatically got the feature too.
>
>
>> Another question:
>> I have learnt to write
>> x,y,z=var('x,y,z')
>>
>
> You can do that, but with the top-level var it's not necessary (this is
> exactly where it differs from SR.var) :
> it will inject bindings for the created symbols in the current name space.
> This is a hack that is convenient for interactive use. In library code, you
> must use SR.var instead, in which case you have to write
>
> x,y,z = SR.var('x,y,z')
>
> ( with just "SR.var('x,y,z')" you'd create the symbols but you wouldn't
> bind them to anything).
>
> Is it possible to do the same for
>> v0,v1,v2=var('v', n=3)
>> without having to write explicitly the LHS?
>>
>
> Yes, that already works. If you use
>
> var('v', n=3)
>
> the names v0,v1,v2 in your current scope will be bound to the newly
> created symbols.
>
> There's been discussion about this when it was implemented:
>
> https://trac.sagemath.org/ticket/22813
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/CANnG18_zOP4UAiywXz-UbN4ok0Hwc2PMb9VoGuk64X%2BowZdUdQ%40mail.gmail.com.


[sage-support] Re: 2 questions on var

2022-03-06 Thread Nils Bruin
On Sunday, 6 March 2022 at 09:13:42 UTC-8 list...@gmail.com wrote:

>
> Beginner's questions, I guess.
>
> Some time ago, Emmanuel Charpentier wrote
>
> var("v", n=2)
>
> which gives
>
> (v0, v1)
>
> Where is this documented?  I have been unable to find keywords for var 
> other than domain and latex_name.  Are there any others?
>

This is documented on SR.var , which is slightly different from the 
top-level "var" you are referring to. It looks like the documentation on 
the top-level one wasn't updated when the feature was added to SR.var. 
Since top-level var just wraps SR.var, it automatically got the feature too.
 

> Another question:
> I have learnt to write
> x,y,z=var('x,y,z')
>

You can do that, but with the top-level var it's not necessary (this is 
exactly where it differs from SR.var) :
it will inject bindings for the created symbols in the current name space. 
This is a hack that is convenient for interactive use. In library code, you 
must use SR.var instead, in which case you have to write

x,y,z = SR.var('x,y,z')

( with just "SR.var('x,y,z')" you'd create the symbols but you wouldn't 
bind them to anything).

Is it possible to do the same for
> v0,v1,v2=var('v', n=3)
> without having to write explicitly the LHS?
>

Yes, that already works. If you use 

var('v', n=3)

the names v0,v1,v2 in your current scope will be bound to the newly created 
symbols.

There's been discussion about this when it was implemented:

https://trac.sagemath.org/ticket/22813

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/316f7db3-2c35-4766-8de1-1dbe14958943n%40googlegroups.com.