On Fri, Apr 21, 2017 at 11:29 AM, Dima Pasechnik <dimp...@gmail.com> wrote:
>
>
> On Friday, April 21, 2017 at 3:46:03 PM UTC+1, David Roe wrote:
>>
>> Quick guess (don't have time to look at this soon): the issue could be in
>> the action discovery code, which may try creating elements of numpy.float32
>> using weird inputs. This could cause a difference between right and left
>> multiplication. One way to check if this is the source is to try converting
>> each of the polynomials from RR['x'].some_elements() into numpy.float32 and
>> see if you get the same error.
>>
>
> no, this does not give anything that looks like the error in question (no
> errors on degree 0 terms,
> "ValueError: setting an array element with a sequence." on degree >0 terms)
>
Sorry, I don't have any other ideas, and can't play around with it easily
since the standard Sage build isn't producing these errors.
David
>
>
>
>>
>> On Apr 21, 2017 05:10, "Dima Pasechnik" <dim...@gmail.com> wrote:
>>
>> On Friday, April 21, 2017 at 9:11:37 AM UTC+1, Marc Mezzarobba wrote:
>>>
>>> Dima Pasechnik wrote:
>>> > but it looks as if it might be a coercion problem.
>>> > Any ideas where to look?
>>>
>>> Not really, but it does look like the common parent
>>> discovered by the coercion system is incorrect:
>>>
>>> sage: import numpy as np
>>> sage: a = np.float('1.5')
>>> sage: b = np.float32('1.5')
>>>
>>
>>
>>> sage: get_coercion_model().common_parent(b, polygen(RR))
>>> Univariate Polynomial Ring in x over Real Field with 53 bits of
>>> precision
>>>
>>> sage: RR.coerce(a)
>>> 1.50000000000000
>>>
>>> sage: RR.coerce(b)
>>> ...
>>> TypeError: no canonical coercion from <type 'numpy.float32'> to Real
>>> Field with 53 bits of precision
>>>
>>> sage: get_coercion_model().common_parent(b, RR)
>>> <type 'numpy.float32'>
>>>
>>
>> This does not look like this is the root cause of the problem.
>> Namely, note that also
>>
>> sage: a128 = np.float128('1.5')
>> sage: RR.coerce(a128)
>> # throws the same as above TypeError, but
>> sage: a128*x
>> # does not print the numpy warning.
>>
>> what is also somewhat puzzling is
>> that while
>> sage: np.float32('1.5')*x
>> # does print the numpy warning
>>
>> sage: x*np.float32('1.5')
>> # just works (i.e. does not print the numpy warning)
>>
>> So this is a subtle combination of an apparent bug in numpy (or in clang)
>> with
>> some Sage coercion weirdness.
>> Apparently numpy's floats are coerced into RDF for the purpose of
>> dealing with polynomials, see py_scalar_to_element in
>> structure/coerce.pyx, but apparently this only happens
>> for
>> x*np.float32('1.5'), and not for np.float32('1.5')*x ?
>>
>> Dima
>>
>>
>>
>>> --
>>> Marc
>>>
>>> --
>> 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+...@googlegroups.com.
>> To post to this group, send email to sage-...@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.
>
--
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.
