On Sun, 14 Jun 2015, Johan S. R. Nielsen wrote:
Say I have a ProductPoset class which takes two posets and returns a
poset representing the cartesian product (is this already in Sage?). I
might very well in "real life" research use this construction with both
sides being lattices, in which case
Jori Mäntysalo writes:
>
> I understood. But when do user have an object of class lattice and he or
> she wants to check that it is a lattice?
This could easily happen in a function that accepts any poset but can do
clever stuff when the input happens to be a lattice.
Say I have a ProductPoset
On Sat, 13 Jun 2015, Travis Scrimshaw wrote:
I would make the function which returns a list a private function and then
the public function calls the private one and converts it into a
poset/lattice as overall,
This kind of happens when "private" function is in hasse_diagram.py. It is
not mea
On Sat, 13 Jun 2015, Johan S. R. Nielsen wrote:
trust_me_i_know_what_i_am_doing=True for posets or lattices.
Such a parameter would make lots of sense, I think.
I have thinked about it. It needs some more thinking - how much should be
trusted? But at least for lattices it could just overri
Jori Mäntysalo writes:
>
>>> At least for now we don't have parameter like
>>> trust_me_i_know_what_i_am_doing=True for posets or lattices.
>
>> Such a parameter would make lots of sense, I think.
>
> I have thinked about it. It needs some more thinking - how much should be
> trusted? But at leas
On Sat, 13 Jun 2015, Johan S. R. Nielsen wrote:
At least for now we don't have parameter like
trust_me_i_know_what_i_am_doing=True for posets or lattices.
Such a parameter would make lots of sense, I think.
I have thinked about it. It needs some more thinking - how much should be
trusted?
I would make the function which returns a list a private function and then
the public function calls the private one and converts it into a
poset/lattice as overall, I don't like arguments which change the output
type (and who really wants to deal with passing them along too?).
However, another
Jori Mäntysalo writes:
> At least for now we don't have parameter like
> trust_me_i_know_what_i_am_doing=True for posets or lattices.
Such a parameter would make lots of sense, I think.
> This can be
> seen for example with C500=Posets.ChainPoset(500), and after that even
> C500.join(100,200)
On Sat, 13 Jun 2015, Johan S. R. Nielsen wrote:
I think that the default of returning a sublattice makes most sense by
far.
Yes, if we have both then this should be the default.
In case the speed difference is very significant (why would this be the
case?),
At least for now we don't have p
I think that the default of returning a sublattice makes most sense by far.
In case the speed difference is very significant (why would this be the
case?), one could add an optional argument to the function to just
return a list. Could be named "as_list = False", I guess.
Johan
Jori Mäntysalo wr
I am making functions to compute, for example, maximal sublattices or
Frattini sublattice of a lattice. It is somewhat faster to return only
list of elements instead of lattice. What you think, should the function
return
1) a sublattice, ready to use as a lattice for further computations;
user mi
On Sat, Jan 3, 2015 at 1:03 AM, Sam Rogers wrote:
> Hello everyone,
>
> I'm a high school student, and I just finished doing some research with my
> Linear Algebra professor in Finite Field Theory. Most of my research was
> conducted using Sage, and my professor recommended I look into adapting wh
Hello everyone,
I'm a high school student, and I just finished doing some research with my
Linear Algebra professor in Finite Field Theory. Most of my research was
conducted using Sage, and my professor recommended I look into adapting
what I had done into Sage itself. However, I'm not entirely
One possibility would be to wrap the call to .n() in a try-except block.
David
On Sun, May 12, 2013 at 7:03 AM, wrote:
> I think there is a conceptual problem with function returning s.
>
> Consider the following:
>
> def find_roots( func,l,r ):
> tol = 1e-10
> try:
> result = f
I think there is a conceptual problem with function returning s.
Consider the following:
def find_roots( func,l,r ):
tol = 1e-10
try:
result = find_root( func,l,r ) )
except RuntimeError:
return []
return find_roots( func,l,result-tol )+[ result ]+find_roots(
func
Hi everybody,
I am currently working on a project in which I compute cycles in
directed graph. I am wondering if it would be interesting to add some
of my code to Sage. For instance, I noticed that there is no function
computing all cycles of a given length in a graph, or a function
returning an a
Josh,
I'm at a workshop with lots of software, and am working a little with a
grad student
to possible make a SAGE interface to something called PHCpack, which is a
numerical
solver for systems of polynomial equations. Anyway, in the PHCpack manual
it says:
"The computational bottleneck i
17 matches
Mail list logo
