Opened 9 years ago
Closed 9 years ago
#11645 closed defect (fixed)
Singular does not find "gftables/9" on Solaris
Reported by:  SimonKing  Owned by:  tbd 

Priority:  blocker  Milestone:  sage4.7.1 
Component:  packages: standard  Keywords:  Singular solaris gftables install.sh 10201 
Cc:  malb  Merged in:  sage4.7.1.rc2 
Authors:  Leif Leonhardy, Jeroen Demeyer  Reviewers:  Simon King 
Report Upstream:  Fixed upstream, in a later stable release.  Work issues:  
Branch:  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
The following problem of Singular on Solaris (mark in skynet for sage4.7.1.rc1, to be precise) was found in #11431, and reported to the Singular trac server.
$ ./sage singular version ? cannot open `help.cnf` Singular for SunOS5 version 311 (31142011080223) Aug 2 2011 23:47:38 with factory(@(#) factoryVersion = 3.1.1),libfac(3.1.1,Feb 2010), GMP(4.2),NTL(5.5.2),32bit,static readline,Plural,DBM, dynamic modules,OM_NDEBUG,random=1312397091 CC= gcc O2 g fPIC pipe DNDEBUG DOM_NDEBUG DSunOS_5 DHAVE_CONFIG_H, CXX= g++ O2 g fPIC pipe DNDEBUG DOM_NDEBUG DSunOS_5 DHAVE_CONFIG_H (4.5.1) argv[0] : Singular311 SearchPath: /home/simonking/SAGE/sage4.7.1.rc1mark/local/share/singular:/home/simonking/SAGE/sage4.7.1.rc1mark/local/LIB Singular : /home/simonking/SAGE/sage4.7.1.rc1mark/local/bin/Singular BinDir : /home/simonking/SAGE/sage4.7.1.rc1mark/local/bin RootDir : /home/simonking/SAGE/sage4.7.1.rc1mark/local DefaultDir: /home/simonking/SAGE/sage4.7.1.rc1mark/local InfoFile : IdxFile : HtmlDir : ManualUrl : http://www.singular.unikl.de/Manual/311 ExDir : Path : /home/simonking/SAGE/sage4.7.1.rc1mark/local/bin:/home/simonking/SAGE/sage4.7.1.rc1mark:/usr/local/gcc4.5.1/sparcSunOSultrasparc3sunasld/bin:/usr/local/bin/sparcSunOSultrasparc3:/usr/bin:/usr/ccs/bin EmacsDir : Available HelpBrowsers: dummy, emacs, Current HelpBrowser: dummy SINGULAR / Development A Computer Algebra System for Polynomial Computations / version 311 0< by: G.M. Greuel, G. Pfister, H. Schoenemann \ Feb 2010 FB Mathematik der Universitaet, D67653 Kaiserslautern \ > ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp); ? cannot open `gftables/9` ? cannot make ring ? error occurred in or before STDIN line 1: `ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp);` ? expected ringexpression. type 'help ring;' >
That example works fine on most platforms; according to the buildbot, t2, mark and mark2 are the only exceptions.
New spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/singular3114.p12.spkg
Attachments (7)
Change History (42)
comment:1 followup: ↓ 2 Changed 9 years ago by
comment:2 in reply to: ↑ 1 Changed 9 years ago by
Replying to SimonKing:
According to the Singular manual, Singular allows all field sizes below
2^16
. Looking at the gftables directory of my installation on my linux computer, clearly there are less tables than field sizes. So, I guess that the tables are only created when needed.
I was wrong: The gftables file contains files for all prime powers greater than 1 and smaller than 2^16
that are not prime. So, that looks as if it was made at compilation time.
comment:3 Changed 9 years ago by
The following indicates that the problem is on Sage's end:
sage: singular.eval('ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp)')  RuntimeError Traceback (most recent call last) /home/simonking/SAGE/sage4.7.1.rc1mark/<ipython console> in <module>() /home/simonking/SAGE/sage4.7.1.rc1mark/local/lib/python2.6/sitepackages/sage/interfaces/singular.pyc in eval(self, x, allow_semicolon, strip, **kwds) 548 549 if s.find("error") != 1 or s.find("Segment fault") != 1: > 550 raise RuntimeError, 'Singular error:\n%s'%s 551 552 if get_verbose() > 0: RuntimeError: Singular error: ? cannot open `gftables/9` ? cannot make ring ? error occurred in or before STDIN line 39: `ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp);` ? expected ringexpression. type 'help ring;' sage: R.<a,b,c,d,e,f> = GF(9,'x')[] sage: singular(R) // characteristic : 3 // 1 parameter : x // minpoly : (x^2x1) // number of vars : 6 // block 1 : ordering dp // : names a b c d e f // block 2 : ordering C sage: singular.eval('ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp)') 'ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp);'
In other words: If one constructs a polynomial ring over a finite nonprime field and converts it into Singular, then the missing file in the gftablesfolder is created!
In other words: If nothing else helps then one could construct while Sage is built a polynomial ring over any finite nonprime field of size less than 2^16
and convert it into Singular. In that way, all gftables would be created.
That still does not explain why the field tables are not created (or copied?) in the first place, but it could be a work around.
comment:4 Changed 9 years ago by
 Cc malb added
Hi Martin,
perhaps you know about missing "gftables" in Singular.
For working with finite nonprime fields, Singular needs certain files in a folder gftables. However, these files are missing when Sage is built on Solaris.
Problem: When Singular tries to create a polynomial ring over a finite field and the table for that field is missing, then it raises an error, but it does not simply compute that table  at least not on Solaris.
However, when one has a polynomial ring over the same finite field in Sage (using libsingular) and converts it into Singular then the field table magically appears.
Questions to Martin: Did you do anything special in the Singular conversion method of libsingular polynomial rings? That's to say, do you catch errors mentioning gftables? Is there a command to create a gftable?
comment:5 Changed 9 years ago by
Actually, it is even better: The missing table is not only created when a libsingular ring is converted into Singular, but already when that ring is created. Proof:
I emptied the gftables folder and started Sage. Then:
sage: singular.eval('ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp)')  RuntimeError Traceback (most recent call last) ... RuntimeError: Singular error: ? cannot open `gftables/9` ? cannot make ring ? error occurred in or before STDIN line 25: `ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp);`
Hence, Singular does not create the table by itself.
However, creating a ring in libsingular means that the table shows up and can be used:
sage: R.<a,b,c,d,e,f> = GF(9,'x')[] sage: singular.eval('ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp)') 'ring r1 = (9,x),(a,b,c,d,e,f),(M((1,2,3,0)),wp(2,3),lp);'
So, question to Martin: How does libsingular make sure that a field table is present?
comment:6 Changed 9 years ago by
 Report Upstream changed from Reported upstream. Little or no feedback. to None of the above  read trac for reasoning.
Now I am really puzzled. On Singular trac, Hannes stated: "No, gftables are parts of the sources and will be copied during installation, but usually not computed (the program for that, a part of factory, will not be build during a standard compilation and installation)."
That gives rise to two questions:
 Why are the tables not copied to the appropriate directory on Solaris?
 How can libsingular create the missing tables?
Any clue?
I am also modifying the "reported upstream" part of the ticket. I think that meanwhile it is clear that the problem is not an upstream problem.
comment:7 followup: ↓ 9 Changed 9 years ago by
From the singular installation log on mark2:
./mkinstalldirs /home/palmieri/mark2/sage4.7.1.rc1/local/share/singular/gftables mkdir /home/palmieri/mark2/sage4.7.1.rc1/local/share/singular/gftables ./installsh c m 644 `pwd`/LIB/gftables/* /home/palmieri/mark2/sage4.7.1.rc1/local/share/singular/gftables/ make[3]: Leaving directory `/home/palmieri/mark2/sage4.7.1.rc1/spkg/build/singular3114.p9/src/Singular'
I wonder if the script installsh
is the problem.
comment:8 Changed 9 years ago by
Offlist ;) comment:
$ find /home/leif/Sage/spkgs/singular3114.p9/ name gftables print exec ls {} \; /home/leif/Sage/spkgs/singular3114.p9/src/Singular/LIB/gftables 10201 125 16 1849 2209 25 289 32768 38809 4913 529 625 7921 961 1024 12769 16129 18769 22201 256 29791 343 39601 49729 5329 63001 8 10609 128 16384 19321 22801 26569 29929 3481 4 5041 54289 64 81 11449 1331 16807 19683 2401 27 3125 361 4096 50653 57121 6561 8192 11881 1369 1681 2048 243 27889 32 36481 44521 512 58081 6859 841 121 14641 169 2187 24389 2809 32041 3721 4489 51529 59049 6889 9 12167 15625 17161 2197 24649 28561 32761 37249 49 52441 6241 729 9409
I.e., they're all (precomputed) in our upstream tree, and should get copied by some BSD install
program, cf. my reply on sagerelease.
Usually autotoolsenabled packages ship with some default / fallback install
shell script in case the system lacks one, and so does Singular:
$ find /home/leif/Sage/spkgs/singular3114.p9/ name installsh
/home/leif/Sage/spkgs/singular3114.p9/src/libfac/installsh
/home/leif/Sage/spkgs/singular3114.p9/src/installsh
/home/leif/Sage/spkgs/singular3114.p9/src/Singular/installsh
/home/leif/Sage/spkgs/singular3114.p9/src/kernel/installsh
/home/leif/Sage/spkgs/singular3114.p9/src/factory/bin/installsh
/home/leif/Sage/spkgs/singular3114.p9/src/omalloc/installsh
/home/leif/Sage/spkgs/singular3114.p9/installsh
spkg/logs/singular*.log
should show which install
actually got used:
checking for a BSD compatible install... /usr/bin/install c
(on my Linux box)
So maybe the one found on Solaris / mark etc. is broken, but configure
doesn't notice that. It might just install the first file passed to it, which would explain why just 10201
(the first in lexicographical order) is present there, as the relevant command used by Singular is
/usr/bin/install c m 644 `pwd`/LIB/gftables/* <SAGE_ROOT>/local/share/singular/gftables/
(Notice the wildcard, which is expanded by the shell.)
Furthermore, gftables/*
is the only such instance; all other files are installed by something like
for f in whatever/*; do install c [...] $f done
so IMHO this is an upstream problem, since they should either use the latter for gftables/*
as well, or make sure the install
program they use supports multiple files at once.
comment:9 in reply to: ↑ 7 Changed 9 years ago by
Replying to jhpalmieri:
From the singular installation log on mark2:
./installsh c m 644 `pwd`/LIB/gftables/* /home/palmieri/mark2/...
I wonder if the script
installsh
is the problem.
Haha, their "own"! XD
comment:10 followup: ↓ 11 Changed 9 years ago by
 Report Upstream changed from None of the above  read trac for reasoning. to Reported upstream. Little or no feedback.
For the record, I've rereported this upstream (the installation bug).
comment:11 in reply to: ↑ 10 ; followup: ↓ 12 Changed 9 years ago by
Replying to leif:
For the record, I've rereported this upstream (the installation bug).
... actually together with a patch!
If Singular accepts the patch, then it will (hopefully) be part of the next Singular release. When? Singular releases take place usually every 6 months. The last was in April. So, it will hopefully be in October.
Then, the upstream fix will be included in Sage. When? Currently, Sage has Singular311, which was released in March, 2010. So, the upstream fix will be in Sage, optimistically, in early 2012.
Hence, I'd appreciate if we could find a temporary solution in Sage. Two approaches:
 Since libsingular is able to create the missing files, we could append a section to the Sage install script that creates a libsingular ring over any finite nonprime field of order less than
2^16
.
 We could patch the current Singular spkg.
Probably, the second solution is better.
comment:12 in reply to: ↑ 11 ; followup: ↓ 13 Changed 9 years ago by
 Component changed from solaris to packages
 Owner changed from drkirkby to tbd
 Report Upstream changed from Reported upstream. Little or no feedback. to Completely fixed; Fix reported upstream
Replying to SimonKing:
Replying to leif:
For the record, I've rereported this upstream (the installation bug).
... actually together with a patch!
Yes, but had problems adding a further comment on it; looked as if they blocked me... :D (different browsers from the same machine)
If Singular accepts the patch, then it will (hopefully) be part of the next Singular release. When? Singular releases take place usually every 6 months. The last was in April. So, it will hopefully be in October.
Then, the upstream fix will be included in Sage. When? Currently, Sage has Singular311, which was released in March, 2010. So, the upstream fix will be in Sage, optimistically, in early 2012.
Haven't yet looked for other (Sage) Singular tickets, so we might already have some dealing with our current version, or even one which upgrades to a newer upstream release.
 We could patch the current Singular spkg.
In any case, we can of course apply the same patch in the next Singular spkg.
comment:13 in reply to: ↑ 12 Changed 9 years ago by
 Keywords install.sh 10201 added
 Status changed from new to needs_info
Replying to leif:
Haven't yet looked for other (Sage) Singular tickets, so we might already have some dealing with our current version, or even one which upgrades to a newer upstream release.
So far I've found #10903 (new, for upgrading Singular) and a 3114.p10 spkg (#11550), already merged into the inofficial / not yet announced Sage 4.7.2.alpha0 (among about a dozen other open tickets related to Singular).
 We could patch the current Singular spkg.
In any case, we can of course apply the same patch in the next Singular spkg.
So I could provide a p11 fixing this based on that p10.
I don't know if you plan to make further changes (to the Sage library I guess) on this ticket; if so, I can open a new ticket for the spkg. Just let me know.
P.S.: What's up with the apparently missing help.cnf
? (Cf. #11519)
comment:14 followup: ↓ 15 Changed 9 years ago by
 Report Upstream changed from Completely fixed; Fix reported upstream to Fixed upstream, in a later stable release.
Hannes confirmed it's a Singular bug, "fixed in revision 14360".
I don't know which Singular version this revision corresponds to though.
comment:15 in reply to: ↑ 14 Changed 9 years ago by
Replying to leif:
Hannes confirmed it's a Singular bug, "fixed in revision 14360".
I don't know which Singular version this revision corresponds to though.
It probably doesn't matter which: The version in Sage is strongly outdated. Singular 313 is out since April, but Sage is still using one year old Singular 311.
Anyway. My guess is that the fix will be part of Singular314. In any case, we probably ought to take care of it NOW.
Changed 9 years ago by
Plain patch to copy into Singular's spkg (patches/
) and apply from within spkginstall
.
comment:16 Changed 9 years ago by
I've just attached a copy of the patch I submitted upstream.
Note that we already patch src/Singular/Makefile.in
(with patches/SingularMakefile.in.patch
), so the two patches should be merged into one.
(We currently copy a patched file anyway.)
Changed 9 years ago by
Replaces patches/SingularMakefile.in
in the Singular spkg. (Cumulatively patched src/Singular/Makefile.in
.)
Changed 9 years ago by
Replaces patches/SingularMakefile.in.patch
in the Singular spkg. (Cumulative patch to src/Singular/Makefile.in
.)
Changed 9 years ago by
Diff between Jeroen's p11 Singular spkg from #11663 and what we would get here (with the two files replaced). For reference / review. There's no Changelog entry yet.
comment:17 followup: ↓ 21 Changed 9 years ago by
Just wondering: is there any reason for
for file in `pwd`/LIB/gftables/*; do
instead of simply
for file in LIB/gftables/*; do
comment:18 Changed 9 years ago by
 Description modified (diff)
 Milestone changed from sage4.7.2 to sageduplicate/invalid/wontfix
 Priority changed from major to blocker
 Resolution set to duplicate
 Status changed from needs_info to closed
This will be folded into #11663.
comment:19 Changed 9 years ago by
 Description modified (diff)
 Milestone changed from sageduplicate/invalid/wontfix to sage4.7.1
 Resolution duplicate deleted
 Status changed from closed to new
comment:20 followup: ↓ 22 Changed 9 years ago by
 Status changed from new to needs_review
New spkg based on the one for #11663: http://boxen.math.washington.edu/home/jdemeyer/spkg/singular3114.p12.spkg, needs review.
comment:21 in reply to: ↑ 17 Changed 9 years ago by
Replying to jdemeyer:
Just wondering: is there any reason for
for file in `pwd`/LIB/gftables/*; do
instead of simply
for file in LIB/gftables/*; do
No, that's just upstream style I didn't change because I submitted the (same) patch there in the first place. ;)
Seriously, the first one is safer since pwd
yields an absolute path.
comment:22 in reply to: ↑ 20 ; followup: ↓ 23 Changed 9 years ago by
Replying to jdemeyer:
New spkg based on the one for #11663: http://boxen.math.washington.edu/home/jdemeyer/spkg/singular3114.p12.spkg, needs review.
I don't know why you didn't just take the replacement files I attached, but for the record: It's not an upstream patch, but a patch I submitted upstream, i.e. I'm the author. ;)
If you merge this (and #11663) into Sage 4.7.1, I think we should also fix the trivial missing help.cnf
which we have to also "manually" copy with cp p
in spkginstall
's install_docs()
; just add
cp p "$SRC/Singular/LIB/help.cnf" "$SAGE_LOCAL/share/singular/" if [ $? ne 0 ]; then echo "Error copying help configuration file" exit 1 fi
there, or changed it by

spkginstall
diff r 7f9b12abe20d spkginstall
a b 356 356 357 357 install_docs() 358 358 { 359 cp p "$SHARED/singular.hlp" "$SHARED/singular.idx" "$SAGE_LOCAL/share/singular/" 359 cp p "$SHARED/singular.hlp" "$SHARED/singular.idx" "$SRC/Singular/LIB/help.cnf" \ 360 "$SAGE_LOCAL/share/singular/" 360 361 if [ $? ne 0 ]; then 361 362 echo "Error installing documentation" 362 363 exit 1
Changed 9 years ago by
comment:23 in reply to: ↑ 22 Changed 9 years ago by
Replying to leif:
... or change it by

spkginstall
diff r 7f9b12abe20d spkginstall
a b 356 356 357 357 install_docs() 358 358 { 359 cp p "$SHARED/singular.hlp" "$SHARED/singular.idx" "$SAGE_LOCAL/share/singular/" 359 cp p "$SHARED/singular.hlp" "$SHARED/singular.idx" "$SRC/Singular/LIB/help.cnf" \ 360 "$SAGE_LOCAL/share/singular/" 360 361 if [ $? ne 0 ]; then 361 362 echo "Error installing documentation" 362 363 exit 1
For convenience, since we still don't get trac notifications, I've now also attached a patch for that here: trac_11645fix_missing_help.cnf_file.patch
comment:24 followups: ↓ 25 ↓ 26 Changed 9 years ago by
It would be really kind to make the help.cnf thing a different ticket. I simply don't have the time to keep rebasing to this ticket with #11550; it is not an easy process for me.
comment:25 in reply to: ↑ 24 Changed 9 years ago by
Replying to kcrisman:
It would be really kind to make the help.cnf thing a different ticket. I simply don't have the time to keep rebasing to this ticket with #11550; it is not an easy process for me.
Well, you shouldn't rebase too early. We meanwhile have enough chaos anyway, multiplied by the fact that we still don't get trac notifications.
I gave #11663 positive review to be able to quickly base my new Singular spkg on yours after you had rebased that on Jeroen's. I asked multiple times where we can fix what or in which order.
It doesn't make sense to me to include (merge) one trivial patch, but not the other one. Permissions can btw. also trivially be fixed by the one who provides an installation, while it is harder to afterwards install some files located somewhere inside spkgs.
comment:26 in reply to: ↑ 24 ; followup: ↓ 31 Changed 9 years ago by
Replying to kcrisman:
It would be really kind to make the help.cnf thing a different ticket.
I totally agree. We cannot just keep adding new stuff here all the time. This ticket is about the much more serious issue of gftables. You are talking about "trivial patches" but I think a trivial patch for a serious issue is very different from a trivial patch for a trivial issue.
I do agree with leif about the rebasing: simply wait until the dust settles over this ticket (i.e. when I gets merged), then rebase.
I have changed the spkg just to change the wording in SPKG.txt
to:
=== singular3114.p12 (Leif Leonhardy, Jeroen Demeyer, 10 August 2011) === * Trac #11645: Fix installation of gftables on Solaris by applying a patch to Singular/Makefile.in
I also add a doctest. Both the spkg and doctest need review.
comment:27 followups: ↓ 28 ↓ 29 ↓ 30 ↓ 32 Changed 9 years ago by
Question: What is needed to do in order to test? I suppose I have to install the new spkg (on Solaris, preferably), best after deleting gftables (just to be on the safe side), and then? Should I use trac_11645fix_missing_help.cnf_file.patch as well?
comment:28 in reply to: ↑ 27 Changed 9 years ago by
Replying to SimonKing:
Question: What is needed to do in order to test? I suppose I have to install the new spkg (on Solaris, preferably), best after deleting gftables (just to be on the safe side), and then? Should I use trac_11645fix_missing_help.cnf_file.patch as well?
Or only 11645_doctest.patch after the spkg?
comment:29 in reply to: ↑ 27 Changed 9 years ago by
Replying to SimonKing:
Should I use trac_11645fix_missing_help.cnf_file.patch as well?
Probably not: Apparently that patch is part of the spkg, right?
So, it only is the doctest patch, isn't it?
comment:30 in reply to: ↑ 27 Changed 9 years ago by
Replying to SimonKing:
Question: What is needed to do in order to test? I suppose I have to install the new spkg (on Solaris, preferably), best after deleting gftables (just to be on the safe side), and then?
I guess you should at least doctest sage/interfaces/singular.py
including my newly added doctest. This should prove that the gftables
was installed. To be sure, you can then delete (or chmod 0000
) gftables and check that the doctest does indeed fail.
Should I use trac_11645fix_missing_help.cnf_file.patch as well?
No. This is a different issue.
comment:31 in reply to: ↑ 26 Changed 9 years ago by
Replying to jdemeyer:
I have changed the spkg just to change the wording in
SPKG.txt
The problem is rather unrelated to Solaris, it's just that the machines happened to have no BSD install
installed such that one of those (broken) install
scripts shipped with Singular got used.
I'd also add to Special Update/Build? Instructions that this is said to be fixed in later stable releases (but not necessarily the next one we'll upgrade to).
(Currently the patches aren't documented well; the whole spkg needs work on some followup.)
comment:32 in reply to: ↑ 27 Changed 9 years ago by
Replying to SimonKing:
Question: What is needed to do in order to test? I suppose I have to install the new spkg (on Solaris, preferably)
You can test the spkg on any machine where command v install
doesn't show anything, or by simply renaming (or chmod ax
) the installed one, usually /usr/bin/install
.
best after deleting gftables (just to be on the safe side)
Yes, of course.
comment:33 Changed 9 years ago by
 Reviewers set to Simon King
 Status changed from needs_review to positive_review
This is what I did to test, on the skynet machine mark (which is solaris and which did expose the bug). And, concerning Leif's hint:
$ command v install bash: command: install: not found
 I removed the contents of
SAGE_ROOT/local/share/singular/gftables
 I installed the new spkg. Now, gftables is filled with all files that are expected. So, that problem seems solved.
 I applied 11645_doctest.patch and did
sage br
. Then, I triedsingular.eval('ring r = (25,x),(a,b,c,d,e,f),dp')
, which worked fine and would have failed without gftables.
sage t sage/interfaces/singular.py
worked fine.
 I opened the spkg, verified that the changelog is present in
SPKG.txt
and thathg status
does not complain. It was all fine.
Since the Singular code did not change (only the gftables files were copied), I think it is enough for a positive review.
Please verify whether I correctly filled the "Author(s)" field!
Caveat
I am currently running sage t sage/rings/
, which takes painfully long on mark. The tests of the first 25 files passed, but of course if some test fails in the next few hours then I'll complain.
comment:34 Changed 9 years ago by
FWIW, the tests in sage/rings have all worked well on mark. So, no complaint from my side, there remains the positive review.
comment:35 Changed 9 years ago by
 Merged in set to sage4.7.1.rc2
 Resolution set to fixed
 Status changed from positive_review to closed
Oleksander and Hannes from the Singular team replied. Apparently, there should be tables in the folder
SAGE_ROOT/local/share/singular/gftables
(or perhaps inSAGE_ROOT/local/LIB/gftables
).In my Sage installation on mark, there is a gftables directory, but it only contains a table for the field of size 10201.
I am not sure whether the tables should already be created when Singular is built, or only when a field of a particular size is first created (I asked the Singular team a few minues ago).
According to the Singular manual, Singular allows all field sizes below
2^16
. Looking at the gftables directory of my installation on my linux computer, clearly there are less tables than field sizes. So, I guess that the tables are only created when needed.But why is Singular not able to? It seems that
SINGULARPATH
is available: