> If Singular moves to CMake that could seriously be a pain for us,
> since we'll likely have to add cmake as a standard package to Sage,
> which will of course involves headaches.
>
OK - thanks for the information. There would be advantages to CMake,
too, e.g. it works on lots of platforms like So
Primarily what I'm wondering is if there is already a good way to do
this, since I'm not volunteering to implement it if there isn't.
Still, I don't suppose it hurts to mention what I would like. For
polynomial rings, it would be a function along the lines of
makeSomeRing(predicate)
where pred
I think the silently wrong Grobner basis has a chance to result in
wrong papers, so that would be my top pick
http://trac.sagemath.org/sage_trac/ticket/6472
and I agree on the startup time
http://trac.sagemath.org/sage_trac/ticket/8254
--
To post to this group, send an email to sage-devel@
Is it possible to write a test that runs over all polynomial ring over
a field in Sage? This is as opposed to a test that works in a specific
ring that the test constructs. Obviously there are infinitely many
possible rings that can be constructed, so the test should run over
some representative fi
Can a standard spkg in Sage use CMake?
http://www.cmake.org/
I ask because I'm seriously considering moving from a straight make
system for Frobby to CMake, but if that is not possible for Sage then
it's a non-starter. A search of sage-devel reveals that Singular is
moving to CMake, but it isn'
Hi,
Conferences and other duties have prevented me from working on Frobby
for a while. I've gotten more time recently and am now working on a
paper on computing Hilbert series which directly involves Frobby, so
it's getting some love now, including clearing up these issues.
The spkg has Frobby v
I wanted to spark a discussion about this because I have a perception
that it has not been discussed in a non-inflammatory way, and talking
about it in a non-inflammatory way might have people come up with
ideas where otherwise they wouldn't think about it. This has been a
valuable experience for
> But as much as I know, it is highly encouraged (and AFAIK
> quite common) that people post at sage-devel or sage-combinat before
> they work on a big project or if a high-level strategic decision is to
> be made. It appears reasonable to me that this "doing things in
> public" is a good (perhaps
> In that case, could you explain what you did intend, since evidently I
> completely misunderstood you.Are you proposing creating wiki
> pages, or a survey paper, or a directory of experts or?
>
Benefiting from experience is good. From using the search, the topic
of how to do that more has no
> Your disguising a dubious claim in the form of a question: Since Sage
> developers just do the first thing that pops into their head, how can
> we find a way to fix this problem? However, implicit in the question
> is the assertion that people who implement code for Sage often do the
> "first
People have been writing mathematics software for a long time and so
people have been accumulating experiences about good ways and bad ways
to do things. I'm wondering how much Sage development is informed by
that experience and however much it is, I think it is worthwhile to
think about how to in
This is a way to do it if you already have an integral flow-solver. I
know there was some work on that during sagedays-16, which is a while
ago, so I imagine this is in Sage now, though perhaps not.
1) Of the two nodes that we want to find independent paths between,
let one be the sink and one be
> > If I have understood this correctly, and the suggestion is to use
> > Buchberger's algorithm to compute Grobner bases in Sage's symbolic
> > ring, which includes limited precision floating point numbers
>
> This is not what William meant (well, I think :). You can compute in the
> symbolic rin
Given some product of units, it can be desirable to find a nicest way
of expressing it, where nicest can mean least total degree or that
certain units are preferred or something else. This is an integer
linear programming problem, and a while ago I fell over this email by
Daniel Lichtblau (of Math
On Jul 22, 7:20 pm, William Stein wrote:
> Albrecht wrote:
> > Not, sure it is enough to add this though. Since it isn't clear what the the
> > symbolic ring is exactly, i.e. is it a field, I don't know which definition
> > of
> > a GB applies.
>
> I think one should treat it like a field for th
l 16, 9:00 am, Minh Nguyen wrote:
>
> > On Thu, Jul 16, 2009 at 11:20 PM, Bjarke Hammersholt
>
> > Roune wrote:
>
> >
>
> > > Frobby has an extensive test-suite, which includes running Frobby
> > > under valgrind to detect memory leaks, and is supp
Studio Express,
though I haven't tested it on that platform since I couldn't get GMP
to build on Windows. GMP is the only dependency Frobby has other than
a C++ compiler. The build system is make-based. I am the upstream
contact, and Frobby is licensed as GPL version 2.0 or later.
Cheers
Hi,
Singular definitely does have an issue with incorrect Grobner bases
due to overflow. I've been in contact with the Singular team, and they
do consider this to be a bug that they will fix. In general they want
Singular to either give a correct answer or give an error message, no
matter how Sin
> I very strongly agree that such a limitation is a major problem.
> The only way I can think of to deal with it, is if any such exponent
> appears, we switch to the polydict (nonsingular) representation, and
> everything gets way slower, and Groebner basis computations switch to
> a toy implement
I'd like to discuss whether limiting the size of exponents of
variables in Sage is a good way to go, and whether it is necessary to
report an error when breaking those limits. In the default polynomial
ring using Singular, Sage currently reports an exponent overflow error
when presented with a var
I heard back from Gert-Martin Greuel of the Singular team. He said he
would look into the Hilbert-related issues. He also pointing out the
limitations mentioned at
http://www.singular.uni-kl.de/Manual/latest/sing_343.htm#SEC384
In particular, I noticed these entries:
* the (weighted) degree of
Hi gsw,
Thank you for looking at the Frobby-Cython ticket. According to the
Cython FAQ, pxd files are preferred over pxi files, unless the file
has to contain code rather than just declarations. The file in
question does not have any code, so you are correct that it would be
better as a pxd file.
> Both the Frobby-Cython interface to be created,
>
The Frobby spkg in Sage is command line-based, but I should point out
that the Frobby Cython interface is on trac currently, at
http://sagetrac.org/sage_trac/ticket/6416, just waiting for a review.
Cheers
Bjarke
--~--~-~--~~
An example spkg could be included as a test the same way that examples
in documentation are now used as a test, so there need not be an issue
of the example not working. Indeed, if it is required that the
documentation is updated in tandem with the example spkg, then the
documentation will also be
Hi Georg,
I worked on a Cython interface to Frobby a few days ago, and from that
experience I'll say that your project is a great idea!
Here's one way to do it: I think it would work well to have a hands-on
guide for how to write an spkg that installs a shared library into
Sage with some simple
I did sage: upgrade() to get Singular 3-1-0, and it does precisely the
same for these inputs as 3-0-4 did.
Cheers
Bjarke
On Jun 29, 5:21 pm, William Stein wrote:
> On Mon, Jun 29, 2009 at 5:10 PM, Bjarke Hammersholt
>
>
>
> Roune wrote:
>
> > I should mention tha
Hi Nathann,
Library files contain information about what they contain. So Sage
reads all the library files it has access to (presumably this only
happens once at startup) and selects the right one.
Cheers
Bjarke
On 29 Jun., 17:27, Nathann Cohen wrote:
> Hello !
>
> Thank you for you answer tho
I should mention that CoCoALib has excellent support for computing
Hilbert series of monomial ideals, possibly at this time better than
that in Frobby. Indeed, CoCoALib is known for having the best
implementation of Bigatti Et.Al.'s algorithm anywhere (not so strange
since Anna Bigatti wrote the C
As far as I can determine, Sage does Hilbert-series only for the
grading given by the vector (1,...,1). I need Hilbert series with
respect to any vector. The optional Frobby spkg I just wrote allows to
compute this, and I'm trying to determine if this is the best way to
do this in Sage. Are there
I'm looking at sage/rings/ideal.py, and it has error messages like
"need at least one argument"
"unable to find common ring into which all ideal generators map"
"R must be a commutative ring"
The first isn't a complete sentence, and the other two aren't
capitalized and don't end with a period
How do I doctest Cython functions taking C data structures? I don't
seem to be able to construct Cython data in the doctest. E.g. suppose
I have a function
cdef foo(bar baz):
...
where bar is a Cython data structure. Is there no way to doctest this,
other than doctesting other Python-level f
In working on the Frobby interface, I needed to use the type mpz_ptr
that MPIR/GMP defines. This type is not defined for Cython in sage/
libs/gmp/types.pxd, which is the file that defines mpz_t and friends.
This is probably because mpz_ptr, while convenient, is not part of the
official GMP interfa
I quote from
http://www.sagemath.org/doc/developer/inclusion.html
which is about the inclusion procedure for new packages. The first
requirement is written as:
"The license must be a GPL version 2+ compatible license. (This will
be publicly revisited around Jan 15, 2009.)"
Whatever was dec
On Nov 12, 5:47 am, Martin Albrecht <[EMAIL PROTECTED]>
wrote:
> On Wednesday 12 November 2008, Thomas Kahle wrote:
> Looks like:
> #include
> is missing.
>
Yep, that is the case. I wonder if why my gcc didn't complain.
Cheers,
Bjarke
--~--~-~--~~~---~--~~
To
ou need
to do on binomial ideals. Then it will be more clear how well Sage
already supports what you need.
Also, Thomas, could you send me the error message you get when
building Frobby, along with information such as which OS you are
using?
Cheers
On Jun 27, 11:50 am, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
> On Friday 27 June 2008 04:59:37 am Burcin Erocal wrote:
>
> In general, the difference between
> multivariate and univariate should not matter in practice.
>
+1.
E.g. exponents() on univariate ring returns a list of int, while
exp
> This is definitely a bug since the docs explicitly say:
> "PolynomialRing(base_ring, name, sparse=False) returns a univariate
> polynomial ring; all other input formats return a multivariate
> polynomial ring." and name is by definition a string.
>
> To get a multivariate polynomial ring in 1 va
I think something that would help Sage's correctness a lot would be
code for checking that structures in Sage has the properties that
those structure ought to have. As an example consider the very general
description of coercion at
http://www.sagemath.org/doc/html/prog/node17.html
If each struct
38 matches
Mail list logo
