On Monday, September 22, 2014 11:37:13 PM UTC-7, Clemens Heuberger wrote:
>
> the problem is that the labels of a state could be any hashable Sage
> object.
> Thus preprocessing this single case of Frac(QQ[x]) would be quite ugly
> IMHO and
> would not address the underlying problem.
>
The Fr
I guess there are two or three solutions:
1) don't use sets
2) put big, red warnings in the documentation of your functions
3) have an optional argument to your functions that switches between sets
and safer (but slower) data structures. The documentation should be clear
about the implications.
Hi Simon,
Am 2014-09-20 um 18:47 schrieb Simon King:
> On 2014-09-20, Clemens Heuberger wrote:
>> Shall I enforce that the parent of all labels is the same (and warn the user
>> if
>> this is not the case?). Probably, I'd also allow strings as an additional
>> type
>> because this should not l
Hi Clemens,
On 2014-09-20, Clemens Heuberger wrote:
> Shall I enforce that the parent of all labels is the same (and warn the user
> if
> this is not the case?). Probably, I'd also allow strings as an additional type
> because this should not lead to conflicts.
You could pre-process the input b
Hi Simon,
Am 2014-09-20 um 16:42 schrieb Simon King:
> On 2014-09-20, Clemens Heuberger wrote:
>> So how do I work with dict and set in sage?
>
> Carefully...
> That's to say, if your dictionary keys all live in the same ring (or
> other mathematical object) then it should be fine. The fact that
Hi Clemens,
On 2014-09-20, Clemens Heuberger wrote:
> So how do I work with dict and set in sage?
Carefully...
That's to say, if your dictionary keys all live in the same ring (or
other mathematical object) then it should be fine. The fact that in your
example two equal elements of the *same* ri
Am 2014-09-18 um 16:44 schrieb Stefan:
>
> Is this behaviour intentional or is this a bug?
>
> Neither, in Sage the Python promise is necessarily broken, because math
> objects
> and equality is just too complex.
So how do I work with dict and set in sage?
I ran across the difficulty in th
Hi!
On 2014-09-18, Clemens Heuberger wrote:
> The same problem is in the Fraction Field of Univariate Polynomial Ring in u
> over Integer Ring:
>
>sage: R1 = PolynomialRing(ZZ, names=['u']).fraction_field()
>sage: (u,) = R1.gens()
>sage: a = 1/(1 - u)
>sage: b = -1/(u - 1)
>sa
Hi!
On 2014-09-18, Travis Scrimshaw wrote:
>Things like this have popped up in a few places, where doing things in a
> fraction field over ZZ behaves much better than over QQ. I feel that
> anytime we're constructing a fraction field from a ring R over a fraction
> field F, we should make
Am 2014-09-18 um 18:12 schrieb Travis Scrimshaw:
> Hey,
>Things like this have popped up in a few places, where doing things in a
> fraction field over ZZ behaves much better than over QQ. I feel that anytime
The same problem is in the Fraction Field of Univariate Polynomial Ring in u
over I
Hey,
Things like this have popped up in a few places, where doing things in a
fraction field over ZZ behaves much better than over QQ. I feel that
anytime we're constructing a fraction field from a ring R over a fraction
field F, we should make R over the ring used to construct F so reduction
> Is this behaviour intentional or is this a bug?
>
Neither, in Sage the Python promise is necessarily broken, because math
objects and equality is just too complex.
But it's unfortunate, and unnecessary, when this happens for elements of
the same ring. See this thread where a possible solut
12 matches
Mail list logo
