On Sunday, January 19, 2014 9:58:08 AM UTC-8, Nils Bruin wrote:
>
> There is, as diagnosed above. It's just so trivial that the administrative
> burden of applying it to sage becomes significant by comparison, and
> dealing with admin is never attractive. There is now
>
Oops sorry. Wrong ticket n
On Sunday, January 19, 2014 1:37:07 AM UTC-8, Bernhard Spinnler wrote:
>
> It's a pity that there doesn't seem to be an easy fix for this.
There is, as diagnosed above. It's just so trivial that the administrative
burden of applying it to sage becomes significant by comparison, and
dealing with
On 05.01.2014, at 02:36, Nils Bruin wrote:
> It's an odd confluence of circumstances that makes numpy.float64 behave this
> way. The code that causes the problem is this:
>
> sage/structure/coerce.pyx:965 (cpdef canonical_coercion)
>elif y_numeric:
>try:
>sa
It's an odd confluence of circumstances that makes numpy.float64 behave
this way. The code that causes the problem is this:
sage/structure/coerce.pyx:965 (cpdef canonical_coercion)
elif y_numeric:
try:
sage_parent = py_scalar_parent(type(y))
if
On Saturday, January 4, 2014 11:29:33 AM UTC-8, vdelecroix wrote:
>
> I do not see how we can make the coercion numpy int/Sage Integer works
> if numpy is not loaded at startup time...
It seems more an issue of *ensuring* that coercion does *not* work, because
we're communicating with a non-sage
Hi Bernhard,
First of all, the command 1j in Sage produces a Sage complex number
{{{
sage: type(1j)
}}}
In order to get a Python complex, one way is to use the suffix r (like raw)
{{{
sage: type(1jr)
}}}
I mentionned Integer whereas the thread was about float but the
problem is the same: Sage n
On Saturday, January 4, 2014 8:29:33 PM UTC+1, vdelecroix wrote:
> See #13386 for a related problem.
>
>
>
> I do not see how we can make the coercion numpy int/Sage Integer works
>
> if numpy is not loaded at startup time... and it seems that we do not
>
> want it because it takes too much ti
On Saturday, January 4, 2014 2:21:29 AM UTC+1, Thierry (sage-googlesucks@xxx)
wrote:
>
> On my Sage 6.0, i first get a warning (according to
> http://sourceforge.net/projects/numpy/files/NumPy/1.5.0/NOTES.txt/view
> the message comes from numpy):
> sage: 1j / np.float64(2)
>
> /opt/sagemath/sage
See #13386 for a related problem.
I do not see how we can make the coercion numpy int/Sage Integer works
if numpy is not loaded at startup time... and it seems that we do not
want it because it takes too much time. There might be a hack using
the hash of the numpy int type. That way we can check e
Hi,
On Sat, Jan 04, 2014 at 01:03:21AM +0100, Harald Schilly wrote:
> Here is a problem maybe somebody can help with (reported on sage-support)
>
> A complex number in an arithmetic operation with a numpy float gives a
> wrong answer ... i.e. the complex part is dropped.
>
> import numpy as np
>
Here is a problem maybe somebody can help with (reported on sage-support)
A complex number in an arithmetic operation with a numpy float gives a
wrong answer ... i.e. the complex part is dropped.
import numpy as np
1j / np.float64(2)
gives 0.0
1j + np.float64(2)
gives 2.0
It works with float3
11 matches
Mail list logo
