Re: [sage-devel] Re: How much do we support the casual user

[William Stein]

On Mon, Apr 9, 2018 at 8:12 PM saad khalid  wrote:

> Have we come to any conclusions on what steps should be taken after this
> topic? What seems to be the concensus? Or, at the very least, could someone
> give a listing of the options we have so that we can give it a poll or
> something similar?
>


My favorite is to add a once per session warning to the the global is_prime
function the first time it receives a field element.  Absolutely no other
changes at all.


>
> On Monday, April 2, 2018 at 2:58:36 AM UTC-5, Sebastian Oehms wrote:
>>
>> Hello,
>>
>> This topic is a good example, that wrong names can be worse than wrong
>> code.
>>
>> Only the user knows what he has in mind using the adjective "prime":
>>
>> 1) prime in a "narrower sense": being a prime number
>> 2) prime in a "broader sense":  being a prime element of a unital
>> commutative ring
>>
>> Therefore, the user must have the possibility to solve this ambiguity.
>>
>> If we will do that by an optional argument (as suggested by Erik Bray),
>> then we have to fix a default! Taking the default to be 1) would prefer the
>> casual user and keep track with popular CAS.
>>
>> WolframAlpha answers the question "is 3/1 prime?" in the sense of 1) with
>> "true". If you have 2) in mind this seems to be a bug. But to be fair: The
>> result "true" matches the explanation WolframAlpha gives for the adjective
>> "prime" (namely according to 1)). If you ask "is 3/1 a prime element?" then
>> it shows you the definition of "prime element" but does not calculate any
>> thing.
>>
>> Now, Sage can calculate this, and accordingly gives the answer in the
>> sense of 2) like mathematicians would expect. Does it so, always?
>>
>> sage: is_prime(I)
>>
>> ---
>> TypeError Traceback (most recent call
>> last)
>> 
>> TypeError: Unable to coerce I to an integer
>>
>>
>> This looks as if even Sage is trying to give the answer according to 1),
>> as well!
>>
>> Nevertheless, taking 2) as default would raise less compatibility
>> problems (and seems to be the favorite in most of the contributions of this
>> thread).
>>
>> But anyway, IMHO the best thing would be to follow the suggestion of Eric
>> Gourgoulhon, solving the ambiguity by separated function names. But if the
>> name "is_prime" should survive, you will have to make a "default"-decision,
>> as well.
>>
>>
>> As a newcomer to sage-devel I cannot really say, how painful the most
>> transparent solution would be, but I think it should be taken into account,
>> too:
>>
>> Deprecation of "is_prime" as function (not as method!!! since there is no
>> ambiguity here) and replace it by two new functions "is_prime_number" and
>> "is_prime_element" (according to the corresponding Wikipedia articles). The
>> first function should try to coerce the input into ZZ and raise an error if
>> this it not possible or not positive. The second one should raise an error
>> if the input is not an element of a unital commutative ring and a warning
>> in the case the ring is a field (according to
>> https://trac.sagemath.org/ticket/25046). In cases as for the
>> SymbolicRing above a NotImplementedError should be raised.
>>
>> If you think deprecation of "is_prime()" would be to painful, then which
>> of both ("is_prime_number" or "is_prime_element") should keep the name
>> "is_prime"? I found contributions for both possibilities!
>>
>> Best,
>> Sebastian
>>
> --
> 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.
>
-- 
-- William Stein

-- 
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.

[sage-devel] Re: How much do we support the casual user

[saad khalid]

Have we come to any conclusions on what steps should be taken after this 
topic? What seems to be the concensus? Or, at the very least, could someone 
give a listing of the options we have so that we can give it a poll or 
something similar?

On Monday, April 2, 2018 at 2:58:36 AM UTC-5, Sebastian Oehms wrote:
>
> Hello,
>
> This topic is a good example, that wrong names can be worse than wrong 
> code.
>
> Only the user knows what he has in mind using the adjective "prime":
>
> 1) prime in a "narrower sense": being a prime number
> 2) prime in a "broader sense":  being a prime element of a unital 
> commutative ring 
>
> Therefore, the user must have the possibility to solve this ambiguity.
>
> If we will do that by an optional argument (as suggested by Erik Bray), 
> then we have to fix a default! Taking the default to be 1) would prefer the 
> casual user and keep track with popular CAS. 
>
> WolframAlpha answers the question "is 3/1 prime?" in the sense of 1) with 
> "true". If you have 2) in mind this seems to be a bug. But to be fair: The 
> result "true" matches the explanation WolframAlpha gives for the adjective 
> "prime" (namely according to 1)). If you ask "is 3/1 a prime element?" then 
> it shows you the definition of "prime element" but does not calculate any 
> thing.
>
> Now, Sage can calculate this, and accordingly gives the answer in the 
> sense of 2) like mathematicians would expect. Does it so, always?
>
> sage: is_prime(I)
> ---
> TypeError Traceback (most recent call last
> )
> 
> TypeError: Unable to coerce I to an integer
>
>
> This looks as if even Sage is trying to give the answer according to 1), 
> as well!
>
> Nevertheless, taking 2) as default would raise less compatibility problems 
> (and seems to be the favorite in most of the contributions of this thread).
>
> But anyway, IMHO the best thing would be to follow the suggestion of Eric 
> Gourgoulhon, solving the ambiguity by separated function names. But if the 
> name "is_prime" should survive, you will have to make a "default"-decision, 
> as well.
>
>
> As a newcomer to sage-devel I cannot really say, how painful the most 
> transparent solution would be, but I think it should be taken into account, 
> too:
>
> Deprecation of "is_prime" as function (not as method!!! since there is no 
> ambiguity here) and replace it by two new functions "is_prime_number" and 
> "is_prime_element" (according to the corresponding Wikipedia articles). The 
> first function should try to coerce the input into ZZ and raise an error if 
> this it not possible or not positive. The second one should raise an error 
> if the input is not an element of a unital commutative ring and a warning 
> in the case the ring is a field (according to 
> https://trac.sagemath.org/ticket/25046). In cases as for the SymbolicRing 
> above a NotImplementedError should be raised.
>
> If you think deprecation of "is_prime()" would be to painful, then which 
> of both ("is_prime_number" or "is_prime_element") should keep the name 
> "is_prime"? I found contributions for both possibilities!
>
> Best,
> Sebastian
>

-- 
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.

Re: [sage-devel] PEP draft to fix Python function classes

[Erik Bray]

Hi Jeroen,

Not posting on python-ideas for now since this is a more 1-on-1
message and I don't want to add to the noise there.

I've read your PEP a few  times now, and some of the discussion on
Python-ideas, and I think it all pretty much makes sense to me.  The
one thing I keep questioning is whether it makes sense to include the
descriptor functionality (i.e. __get__) on the basefunction class.  It
seems a bit strange t to me because it's a bit of tacked-on
functionality that isn't even necessarily needed by "functions"
(although we do want most functions to behave as unbound methods).
Further, it breaks backwards-compatibility for builtin_function.  I
think it's a *good* breakage because there's currently no good reason
they should behave differently from Python functions in this regard.
But it makes me wonder if there isn't a case for preserving that
backwards compatibility where necessary, while still introducing yet
another class that's like a built-in function with __get__.

I also don't like that basefunction is spelled without an underscore
(no doubt inspired by basestring), but its subclasses
(generic_function, etc.) are spelled with an underscore.  That's just
a minor nitpick.

Let me know if you want any help with the prototype implementation.
Not that I think you need help, but if you think there's some sensible
way to divvy up the work I'm happy to take part.  Perhaps we can work
on that at Cernay if you haven't already started.

On Sat, Mar 31, 2018 at 5:32 PM, Jeroen Demeyer  wrote:
> I have drafted a Python Enhancement Proposal (PEP) to unify built-in and
> Python functions:
>
> https://github.com/jdemeyer/PEP-functions
>
> This is just a draft for now, it has not officially been submitted (so there
> is no PEP number yet). Cython could benefit from this because Cython
> functions would be considered proper functions by Python. For Sage, we could
> finally get rid of all the inspect hacks. This would in particular affect
> sage.misc.sageinspect and docbuilding. Needless to say, this is a long-term
> plan: if all goes well, the PEP would be accepted for Python 3.8.
>
> For discussion of the PEP itself, please post on the python-ideas thread
> https://mail.python.org/pipermail/python-ideas/2018-March/049563.html
>
>
> Happy Easter,
> Jeroen.
>
> --
> 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.

-- 
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.

[sage-devel] Question about number_field_elements_from_algebraics (Ticket 20181)

[jplab]

Dear all,

In order to get algebraic polyhedra using the normaliz backend [1], we 
modify the function

number_field_elements_from_algebraics of qqbar.py to give embedded number 
fields and also accept a larger class of algebraic numbers, say coming from 
cyclotomic fields [2].

For example, this is now possible:

sage: UCF = UniversalCyclotomicField()
sage: E = UCF.gen(5)
sage: L. = NumberField(x^2-189*x+16, embedding=200)
sage: my_nums = [-52*E - 136*E^2 - 136*E^3 - 52*E^4, 
L.gen()._algebraic_(AA),sqrt(2)]
sage: aa_my_nums = [AA(_) for _ in my_nums]
sage: res = number_field_elements_from_algebraics(aa_my_nums,embedded=True)
sage: res
(Number Field in a with defining polynomial y^8 - 35670*y^6 + 476899047*y^4 - 
2832410271650*y^2 + 6305298701739921,
 [2310/26212773509*a^7 - 185432947/78638320527*a^5 + 
1652517502195/78638320527*a^3 - 4904676315215467/78638320527*a + 94,
  -1238/2803377488467023*a^7 + 185460719/11213509953868092*a^5 - 
2754936849443/11213509953868092*a^3 + 8180694680816975/3737836651289364*a + 
189/2,
  -1979/1887160880826*a^7 + 26472586/943580440413*a^5 - 
235822245043/943580440413*a^3 + 466325019915415/629053626942*a],
 Ring morphism:
   From: Number Field in a with defining polynomial y^8 - 35670*y^6 + 
476899047*y^4 - 2832410271650*y^2 + 6305298701739921
   To:   Algebraic Real Field
   Defn: a |--> 96.9475535136628?)
sage: res[0].gen_embedding()
96.9475535136628?


The ticket 2018 needs review and it would be nice to have the opinion of 
experts on number fields in Sage... 

For example, there is currently one failing doctest where it seems that the 
newer version is smarter, so that the test is not necessary anymore.

[1] https://trac.sagemath.org/ticket/25097
[2] https://trac.sagemath.org/ticket/20181

-- 
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.

Re: [sage-devel] Re: PY_NEW(Integer) and Integer.__new__(Integer)

[Erik Bray]

On Mon, Apr 9, 2018 at 10:27 AM, Jean-Pierre Flori  wrote:
> I thought PY_NEW was to be avoided (except for classes overriding tp_new).
> See https://trac.sagemath.org/ticket/17668 and
> https://github.com/cython/cython/wiki/FAQ#can-cython-create-objects-or-apply-operators-to-locally-created-objects-as-pure-c-code

Which is exactly what we're doing for Integer.  In the ticket you cited:

"Change this everywhere except for Integer and RealDoubleElement
classes, which use a custom hooked tp_new that Cython isn't aware of."


> On Sunday, April 8, 2018 at 9:41:17 AM UTC+2, vdelecroix wrote:
>>
>> Dear all,
>>
>> What is the status of Integer.__new__(Integer) vs PY_NEW(Integer). One
>> can find both versions in the source code
>>
>> $ grep -R "PY_NEW(Integer)" | wc -l
>> 152
>> $ grep -R "Integer.__new__(Integer)" | wc -l
>> 94
>>
>> But the doc of PY_NEW (ext/stdsage.pxd) says that we should avoid the
>> second one
>>
>>  Return ``t.__new__(t)``.  This works even for types like
>>  :class:`Integer` where we change ``tp_new`` at runtime (Cython
>>  optimizations assume that ``tp_new`` doesn't change).
>>
>> Should I change the 94 bad usage?
>>
>> Vincent
>>
>> PS: this happen to be a question from
>> https://trac.sagemath.org/ticket/24717
>
> --
> 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.

-- 
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.

[sage-devel] Re: PY_NEW(Integer) and Integer.__new__(Integer)

[Jean-Pierre Flori]

I thought PY_NEW was to be avoided (except for classes overriding tp_new).
See https://trac.sagemath.org/ticket/17668 and 
https://github.com/cython/cython/wiki/FAQ#can-cython-create-objects-or-apply-operators-to-locally-created-objects-as-pure-c-code

On Sunday, April 8, 2018 at 9:41:17 AM UTC+2, vdelecroix wrote:
>
> Dear all, 
>
> What is the status of Integer.__new__(Integer) vs PY_NEW(Integer). One 
> can find both versions in the source code 
>
> $ grep -R "PY_NEW(Integer)" | wc -l 
> 152 
> $ grep -R "Integer.__new__(Integer)" | wc -l 
> 94 
>
> But the doc of PY_NEW (ext/stdsage.pxd) says that we should avoid the 
> second one 
>
>  Return ``t.__new__(t)``.  This works even for types like 
>  :class:`Integer` where we change ``tp_new`` at runtime (Cython 
>  optimizations assume that ``tp_new`` doesn't change). 
>
> Should I change the 94 bad usage? 
>
> Vincent 
>
> PS: this happen to be a question from 
> https://trac.sagemath.org/ticket/24717 
>

-- 
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.