By coincidence I just found that the function GCD_list
in sage.rings.integer was coded to return one for an
empty list.
Fix (needs review!) at
http://trac.sagemath.org/ticket/17257
Samuel
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To u
On Mon, Oct 27, 2014 at 5:55 AM, John Cremona wrote:
> On 27 October 2014 12:37, Nathann Cohen wrote:
>> Yo !
>>
>>> This is good argument to support (only) []-style argument for several
>>> elements. Be consistent within same program. Or in Sage terms, "Build a car,
>>> don't let it look like bi
On Mon, 27 Oct 2014, Samuel Lelievre wrote:
Here is how I would put it:
- gcd([]) is zero because
zero is the identity element for gcd
(for any x, gcd(0,x) equals x);
Understood. Thanks.
--
Jori Mäntysalo
--
You received this message because you are subscribed to the Google Groups
"s
Nathann Cohen wrote:
>
> Yo !
>
> > This is good argument to support (only) []-style argument for several
> > elements. Be consistent within same program. Or in Sage terms, "Build a
> car,
> > don't let it look like bicycle combined to tractor." :=)
> >
> > Btw, why gcd([]) returns zero? At l
On 27 October 2014 12:37, Nathann Cohen wrote:
> Yo !
>
>> This is good argument to support (only) []-style argument for several
>> elements. Be consistent within same program. Or in Sage terms, "Build a car,
>> don't let it look like bicycle combined to tractor." :=)
>>
>> Btw, why gcd([]) return
Yo !
> This is good argument to support (only) []-style argument for several
> elements. Be consistent within same program. Or in Sage terms, "Build a car,
> don't let it look like bicycle combined to tractor." :=)
>
> Btw, why gcd([]) returns zero? At least there is inconsistency with lcm([])
> r
On Thu, 23 Oct 2014, Nathann Cohen wrote:
sage: gcd([5])
5
sage: gcd([5,7])
1
This is good argument to support (only) []-style argument for several
elements. Be consistent within same program. Or in Sage terms, "Build a
car, don't let it look like bicycle combined to tractor." :=)
Btw, why
Yo !
>> You should test if "args in self" first. If your poset contains an
>> element named E=(x,y) and you want to compute join( E ) (which should
>> return E) then you raise an exception.
>
> I disagree.
>
> If you want to obtain the join of a single element E, you can use
> foo([E]), foo((E,)),
On Thu, 23 Oct 2014 13:06:00 +0200
Nathann Cohen wrote:
> > I would personally prefer the following over the above:
> >
> > def foo(*args):
> > if len(args) == 1:
> > elements = args[0]
> > else:
> > elements = args
> > ... do stuff with ele
> this reminds me of the discussion about Permutation((1,2,3)) and
> Permutation([2,3,1]). Of course, the situation is a bit different there,
> but my feeling is that it's usually better to have only one syntax.
Precisely, though the risk of misunderstanding is slightly reduced.
Nathann
--
Yo
Am Donnerstag, 23. Oktober 2014 11:11:34 UTC+2 schrieb Jori Mantysalo:
>
> On Thu, 23 Oct 2014, Nathann Cohen wrote:
>
> >> Ok. To have join(a,b,c,...) or join([a,b,c,...])?
> >
> > Hmmm.. Well, we can have both at the same time.
>
> True, but is it good for user perspective to have two ways to
> I would personally prefer the following over the above:
>
> def foo(*args):
> if len(args) == 1:
> elements = args[0]
> else:
> elements = args
> ... do stuff with elements ...
You should test if "args in self" first. If your poset contains
On Thu, 23 Oct 2014 10:38:53 +0200
Nathann Cohen wrote:
> > Ok. To have join(a,b,c,...) or join([a,b,c,...])?
>
> Hmmm.. Well, we can have both at the same time. Something like that
> should do the trick:
>
> def join(elements, *args):
> if args:
> args.append(elements)
> el
On Thu, 23 Oct 2014, Nathann Cohen wrote:
It really is not a problem either to only have this P.join(a_list) available
And it can always be later expanded to accept also another kind of args.
Btw, I noticed that there kind of is a function for this already: sum().
But not that easy to us
Hello !
> True, but is it good for user perspective to have two ways to same end?
When there is no risk of confusion I do not think that it is bad. Here
the only risk of confusion is the following:
P.join( ( (1,2), (3,4) ) )
In a poset that contains elements named (1,2), (3,4), as well as
((1,2
On Thu, 23 Oct 2014, Nathann Cohen wrote:
which says that detecting if a poset is lattice can be done on O(n^2.5).
Oh. Cool.
Now somebody should just read, understand and implement it. :=)
Ok. To have join(a,b,c,...) or join([a,b,c,...])?
Hmmm.. Well, we can have both at the same time.
Hello !
> which says that detecting if a poset is lattice can be done on O(n^2.5).
Oh. Cool.
> Ok. To have join(a,b,c,...) or join([a,b,c,...])?
Hmmm.. Well, we can have both at the same time. Something like that
should do the trick:
def join(elements, *args):
if args:
args.append(
On Wed, 22 Oct 2014, Nathann Cohen wrote:
given a Poset, how can you detect if this poset is a meet semilattice ?
For sure we need a function for that ! And it seems that this function
is exactly what join_matrix does.
Of course one can try to build a [semi]lattice and see if it works or not.
Yo !
1) Why is join() defined for join-semilattices, but join_matrix()
> "defined" for posets? (I.e. it works by giving exception if the poset is
> not join-semilattice.)
>
H...
1) I do not know why it is made like that, and I do not like the design
2) After several cycles of "a) answer q
19 matches
Mail list logo
