[sage-devel] Re: Preliminary bug [Re: Boolean expressions]

2021-05-08 Thread Emmanuel Charpentier 


Le vendredi 7 mai 2021 à 22:41:36 UTC+2, Nils Bruin a écrit :

> On Friday, May 7, 2021 at 12:37:41 PM UTC-7 emanuel wrote:
>

[ Snip... ] 

Unless you advise me not to do so (and explain why), I’ll file a ticket on 
>> this issue, propose a branch replacing those null strings with a single 
>> space, and try to break the damn thing.
>>
> I'm sure you'll succeed and discover why it was decided to strip out 
> whitespace.
>

Well, I tried and failed to break a patched version. So Trac#31796 
 await reviews...
 

> Or you could do some archaeology and see if you can find records of why 
> this was done. It looks like the change goes back to 2007:
>
> https://github.com/sagemath/sage/commit/7a2aa2c06c9fb5c21ae9c08ce31eaee60ac452a2
>

That was helpful. Thank you..
 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7c57d429-4bf4-4465-aeb8-e3057124fe9dn%40googlegroups.com.

[sage-devel] Re: Preliminary bug [Re: Boolean expressions]

2021-05-07 Thread Nils Bruin 


On Friday, May 7, 2021 at 12:37:41 PM UTC-7 emanuel wrote:

> Nor with printed code output (see above). And it’s ugly as hell…

I guess maxima can be rather unpredictable in what whitespace it inserts. 
The output that comes back is not for human consumption, but for parsing. 
With just function calls and non-alphanumeric operators, the spaces aren't 
required to separate lexical tokens.
 

> Unless you advise me not to do so (and explain why), I’ll file a ticket on 
> this issue, propose a branch replacing those null strings with a single 
> space, and try to break the damn thing.
>
I'm sure you'll succeed and discover why it was decided to strip out 
whitespace. Or you could do some archaeology and see if you can find 
records of why this was done. It looks like the change goes back to 2007:
https://github.com/sagemath/sage/commit/7a2aa2c06c9fb5c21ae9c08ce31eaee60ac452a2

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6c73d7b2-57c7-4556-9db2-390e6c5e5412n%40googlegroups.com.

[sage-devel] Re: Preliminary bug [Re: Boolean expressions]

2021-05-07 Thread Emmanuel Charpentier 


Le vendredi 7 mai 2021 à 17:54:51 UTC+2, Nils Bruin a écrit :

On Friday, May 7, 2021 at 6:07:30 AM UTC-7 emanuel wrote:
>
>> Both maxima interfaces mangle Maxima’s boolean operators *printing*.
>> The evaluation of a Maxima boolean expression gives nonsensical results 
>> in Sage. Using the pexpect interface :
>>
>> sage: ME=maxima
>>
>> sage: ME("foo: a and (b or c)")
>> aand(borc)
>>
>> This also happens in Maxima’s *printing*:
>>
>> sage: ME("print(foo)")kk
>> aand(borc)
>>
>>
>> Yup, see:
>
>
> https://github.com/sagemath/sage/blob/c27d4d6803d04a0f25377caa59de530060529c7a/src/sage/interfaces/maxima.py#L760
>
> https://github.com/sagemath/sage/blob/c27d4d6803d04a0f25377caa59de530060529c7a/src/sage/interfaces/maxima_lib.py#L410
>
> strings coming from the maxima interface are stripped of spaces.
>
Thus mangling the printed output, which becomes unparsable (by program or 
eyeball).

I guess there must be a benefit to doing so.
>
I guess that this is an instance of “hell is paved with good intents”. This 
stripping happens line 817 of maxima.py (where any occurence of any number 
of consecutive whitespace is remplaced by a 0-length string) and line 461 
of maxima_lib.py (where a zero-length string joins the representation of 
each of the result’s components).
Wanna bet that the original intent was ' ' (i. e. a single space) in both 
cases ? 

Clearly, it doesn't seem to be designed with alphanumerical infix operators 
> in mind.
>
Nor with printed code output (see above). And it’s ugly as hell…

Unless you advise me not to do so (and explain why), I’ll file a ticket on 
this issue, propose a branch replacing those null strings with a single 
space, and try to break the damn thing.

Path to this code:
>
> sage: M=sage.interfaces.maxima.Maxima() 
> sage: C=M('a and b') 
> sage: C.str?? 
> sage: C._check_valid??
> sage: M._eval_line??
>
Nice shortcut . I’ve learned something tonight…

Thank you very much.
​

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/94175578-2fcb-46c9-993d-bf46633efc39n%40googlegroups.com.

[sage-devel] Re: Preliminary bug [Re: Boolean expressions]

2021-05-07 Thread Nils Bruin 
I guess you may be able to make expressions robust against space removal by 
replacing "and" and "or" with non-alphanumeric "&&" and "||". Those can be 
recognized also in a non-space-separated string.

Something like the following seems to do the trick:

sage: M=sage.interfaces.maxima.Maxima() 
sage: C=M('a and b') 
aandb
sage: M._eval_line(':lisp (displa-def mand  dimension-nary  " && ")');
sage: C=M('a and b') 
a&&b

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1280a462-2ad2-44e8-9901-832c536d729an%40googlegroups.com.

[sage-devel] Re: Preliminary bug [Re: Boolean expressions]

2021-05-07 Thread Nils Bruin 
On Friday, May 7, 2021 at 6:07:30 AM UTC-7 emanuel wrote:

> Both maxima interfaces mangle Maxima’s boolean operators *printing*.
> The evaluation of a Maxima boolean expression gives nonsensical results in 
> Sage. Using the pexpect interface :
>
> sage: ME=maxima
>
> sage: ME("foo: a and (b or c)")
> aand(borc)
>
> This also happens in Maxima’s *printing*:
>
> sage: ME("print(foo)")
> aand(borc)
>
>
> Yup, see:

https://github.com/sagemath/sage/blob/c27d4d6803d04a0f25377caa59de530060529c7a/src/sage/interfaces/maxima.py#L760
https://github.com/sagemath/sage/blob/c27d4d6803d04a0f25377caa59de530060529c7a/src/sage/interfaces/maxima_lib.py#L410

strings coming from the maxima interface are stripped of spaces. I guess 
there must be a benefit to doing so. Clearly, it doesn't seem to be 
designed with alphanumerical infix operators in mind.

Path to this code:

sage: M=sage.interfaces.maxima.Maxima() 
sage: C=M('a and b') 
sage: C.str?? 
sage: C._check_valid??
sage: M._eval_line?? 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/647d424c-4b58-4406-8985-0b98106e2373n%40googlegroups.com.

[sage-devel] Re: Preliminary bug [Re: Boolean expressions]

2021-05-07 Thread Emmanuel Charpentier 


This also happens in the .interact() manual interactions :

sage: ME.interact()

  --> Switching to Maxima <--

maxima: foo
aand(borc)
maxima: 
  --> Exiting back to Sage <--

sage: MC.interact()

  --> Switching to Maxima_lib <--

maxima_lib: foo
aand(borc)
maxima_lib: 
  --> Exiting back to Sage <--

HTH,
​
Le vendredi 7 mai 2021 à 15:07:30 UTC+2, Emmanuel Charpentier a écrit :

> Both maxima interfaces mangle Maxima’s boolean operators *printing*.
> The evaluation of a Maxima boolean expression gives nonsensical results in 
> Sage. Using the pexpect interface :
>
> sage: ME=maxima
>
> sage: ME("foo: a and (b or c)")
> aand(borc)
>
> This also happens in Maxima’s *printing*:
>
> sage: ME("print(foo)")
> aand(borc)
>
> but the structure has correctly been interpreted :
>
> sage: ME("untree(x) := append([part(x, 0)], maplist(lambda([u], if atom(u) 
> then u else untree(u)), x))")
> untree(x):=append([part(x,0)],maplist(lambda([u],ifatom(u)thenuelseuntree(u)),x))
> sage: ME("untree(foo)")
> ["and",a,["or",b,c]]
>
> This happens also in the maxima_calculus interface :
>
> sage: MC=maxima_calculus
> sage: MC("foo")
> foo
> sage: MC("foo: a and (b or c)")
> aand(borc)
> sage: MC("print(foo)")
> aand(borc)
> sage: MC("untree(x) := append([part(x, 0)], maplist(lambda([u], if atom(u) 
> then u else untree(u)), x))")
> untree(x):=append([part(x,0)],maplist(lambda([u],ifatom(u)thenuelseuntree(u)),x))
> sage: MC("untree(foo)")
> [\"and\",a,[\"or\",b,c]]
>
> This suggests that the problem may exist in the common parent class 
> Maxima_abstract. Whose code is (yet) impenetrable to me. nOne also notes 
> that this problem also affects "normal" Maxima output (including code, 
> whose whitespace is removed (Yuk !).
>
> Is this problem worth a ticket by itself or should it be tackled in the 
> implementation of Sage logical functions ? In the former case, how to file 
> the "right" informative ticket ?
> ​
> Le vendredi 7 mai 2021 à 00:26:59 UTC+2, Nils Bruin a écrit :
>
>> On Thursday, May 6, 2021 at 12:23:57 PM UTC-7 emanuel.c...@gmail.com 
>> wrote:
>>
>>>
>>>  There is no pexpect involved there at all; you really need to make a 
>>> separate maxima instance to get an interface based on that.
>>>
>>> Huh ?
>>> From maxima_calculus? :
>>>
>>> Only one instance of this interface can be instantiated, so the user 
>>> should not try to instantiate another one, which is anyway set to raise an 
>>> error:
>>>
>>> What do you mean ?
>>> ​
>>>
>> maxima and maxima_calculus are instances of different classes:
>>
>> sage: a=maxima(1) 
>> sage: type(a) 
>>  
>> sage: b=maxima_calculus(1) 
>> sage: type(b) 
>>  
>>
>> You can make multiple instances of the type "maxima", since those are 
>> honest pexpect interfaces to another process. That's not true for 
>> maxima_lib. I don't think there are any cases left in the calculus and SR 
>> code that would instantiate a maxima interface: they all talk to the 
>> (unique) maxima_lib interface, which is NOT pexpect based.
>>
>> It does look like the default "maxima" interface still does have some of 
>> the maxima_calculus specific initialization to it (which surprised me a 
>> bit):
>>
>> sage: A=sage.interfaces.maxima.Maxima() 
>> sage: A("domain") 
>> real 
>> sage: maxima("domain") 
>> complex 
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/85febb2a-40e0-4ea2-828c-ee4ca978a01bn%40googlegroups.com.

[sage-devel] Re: Preliminary bug [Re: Boolean expressions]

2021-05-07 Thread Emmanuel Charpentier 
This also happens in the `.interact()` manual interactions :

```
sage: ME.interact()

  --> Switching to Maxima <--

maxima: foo
aand(borc)
maxima: 
  --> Exiting back to Sage <--

sage: MC.interact()

  --> Switching to Maxima_lib <--

maxima_lib: foo
aand(borc)
maxima_lib: 
  --> Exiting back to Sage <--
```

HTH,

Le vendredi 7 mai 2021 à 15:07:30 UTC+2, Emmanuel Charpentier a écrit :

> Both maxima interfaces mangle Maxima’s boolean operators *printing*.
> The evaluation of a Maxima boolean expression gives nonsensical results in 
> Sage. Using the pexpect interface :
>
> sage: ME=maxima
>
> sage: ME("foo: a and (b or c)")
> aand(borc)
>
> This also happens in Maxima’s *printing*:
>
> sage: ME("print(foo)")
> aand(borc)
>
> but the structure has correctly been interpreted :
>
> sage: ME("untree(x) := append([part(x, 0)], maplist(lambda([u], if atom(u) 
> then u else untree(u)), x))")
> untree(x):=append([part(x,0)],maplist(lambda([u],ifatom(u)thenuelseuntree(u)),x))
> sage: ME("untree(foo)")
> ["and",a,["or",b,c]]
>
> This happens also in the maxima_calculus interface :
>
> sage: MC=maxima_calculus
> sage: MC("foo")
> foo
> sage: MC("foo: a and (b or c)")
> aand(borc)
> sage: MC("print(foo)")
> aand(borc)
> sage: MC("untree(x) := append([part(x, 0)], maplist(lambda([u], if atom(u) 
> then u else untree(u)), x))")
> untree(x):=append([part(x,0)],maplist(lambda([u],ifatom(u)thenuelseuntree(u)),x))
> sage: MC("untree(foo)")
> [\"and\",a,[\"or\",b,c]]
>
> This suggests that the problem may exist in the common parent class 
> Maxima_abstract. Whose code is (yet) impenetrable to me. nOne also notes 
> that this problem also affects "normal" Maxima output (including code, 
> whose whitespace is removed (Yuk !).
>
> Is this problem worth a ticket by itself or should it be tackled in the 
> implementation of Sage logical functions ? In the former case, how to file 
> the "right" informative ticket ?
> ​
> Le vendredi 7 mai 2021 à 00:26:59 UTC+2, Nils Bruin a écrit :
>
>> On Thursday, May 6, 2021 at 12:23:57 PM UTC-7 emanuel.c...@gmail.com 
>> wrote:
>>
>>>
>>>  There is no pexpect involved there at all; you really need to make a 
>>> separate maxima instance to get an interface based on that.
>>>
>>> Huh ?
>>> From maxima_calculus? :
>>>
>>> Only one instance of this interface can be instantiated, so the user 
>>> should not try to instantiate another one, which is anyway set to raise an 
>>> error:
>>>
>>> What do you mean ?
>>> ​
>>>
>> maxima and maxima_calculus are instances of different classes:
>>
>> sage: a=maxima(1) 
>> sage: type(a) 
>>  
>> sage: b=maxima_calculus(1) 
>> sage: type(b) 
>>  
>>
>> You can make multiple instances of the type "maxima", since those are 
>> honest pexpect interfaces to another process. That's not true for 
>> maxima_lib. I don't think there are any cases left in the calculus and SR 
>> code that would instantiate a maxima interface: they all talk to the 
>> (unique) maxima_lib interface, which is NOT pexpect based.
>>
>> It does look like the default "maxima" interface still does have some of 
>> the maxima_calculus specific initialization to it (which surprised me a 
>> bit):
>>
>> sage: A=sage.interfaces.maxima.Maxima() 
>> sage: A("domain") 
>> real 
>> sage: maxima("domain") 
>> complex 
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/338fed45-b377-42c3-b19d-f46bc46a26c7n%40googlegroups.com.