Re: [fricas-devel] INSTALL
> Yes, that and |git repository| (we should have actual URL in > the file). We can discuss this. The |...| stuff is actually defined in conf.py. And conf.py takes input from environment variables during "make". This was done on purpose, since I want the web address not be hardcoded. It should also work when I present a website at my github fork. It would be super simple to replace |...| by an awk script. In fact, since the markup in install.rst is s simple, it would be quite easy to produce a awk script that removes |...|. > Problem is with quantity, that is actualy more > than is some other markup formats. What else is TOO MUCH? Name it! BTW, in Emacs, there is a special rstdoc mode that brings me highlighting. Vim has probably a similar mode. It is not only YOU that reads the install file. In fact, the younger generation is for whom we all do this, no? What is the intended user base of FriCAS? Researchers with age over 65? >> What you basically say is, that my conversion was work-done-for-nothing. > If you want to view it in this way. Not all things work as > expected/hoped for... Yes. But do you think that increases the amount of people working on FriCAS? >> Are you afraid of writing .rst stuff or do you think that my >> install.rst is not nicely readable as plain text? > Mainly the second, INSTALL should be readable as plain text. > It is OK to have marked up version as master source. Some > markup formats can produce decent looking plain text versions > (IIUC sphinx is supposed to produce text version, but ATM > this does not work for me so in particular I can not see > if this is good enough). Another issue is dependency. .rst > is claimend to be ligtweight, but supporting programs are > rather large... > >> I definitely want >> install.rst on the web and showing a plain text file on an otherwise >> sphinx-generated site would look very unprofessional. > > .rst pretending to be plain text is at least as unprofessional. I never said .rst is plain text (actually it is pure ASCII). But it *is* easily readable. Anyway. Offer for compromise. I write a script that computes (without sphinx) the INSTALL file from the install.rst file. Thank you, Kurt. I attach the output of pandoc --from rst --to plain install.rst > INSTALL Replacing the |...| stuff before giving install.rst to pandoc would be simple, but was not done for the attachment. Waldek, would you be satisfied with having both src/doc/sphinc/source/install.rst and INSTALL (generated from install.rst)? Both committed to the git repo? May I ask you whether you really find the attached INSTALL file easier to read than install.rst. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/54a0f2e9-4b2b-0d35-757b-25314fdcee83%40hemmecke.org. INSTALLATION GUIDE Table of Contents Quick installation FriCAS now tries to support standard GNU build/installation conventions. So if you have sources and all prerequisites, then : configure && make && sudo make install should work. The above will install FriCAS files into /usr/local/lib/fricas/ and put the fricas command into /usr/local/bin/. You can give arguments to configure to change those locations. Prerequisites Lisp To _build_ FriCAS you need _one_ of the following Lisp variants: - SBCL 1.0.7 or later (preferred) - Clozure CL (former openmcl), starting from openmcl 1.1 prerelease 070512 - ECL 0.9l or later - CLISP 2.41 or later - CMUCL - GCL version 2.6.8 works OK. If you want to try development version of GCL from git note that main branch currently is very unstable and can not build FriCAS. In the past in case of build problems the following configure line was helpful : ./configure --disable-xgcl --disable-dynsysbfd --disable-statsysbfd --enable-locbfd All Lisp implementations should give essentially the same functionality, however performance (speed) may differ quite a lot. ATM CMU CL port should be considered experimental, it received only little testing. Also CMU CL seem to have problems on some machines. By default FriCAS tries to use SBCL, since it is fast and reliable. On 64-bit AMD64 on average SBCL is the fastest one (9 times faster than CLISP), Clozure CL the second (about 1.5 times slower than SBCL), than GCL and ECL (about 3 times slower than SBCL) and CLISP is the slowest one. Note: older versions of ECL were much (about 4 times) slower, you should use newest version if you care about speed. Some computation work much faster on 64-bit machines, especially when using SBCL. X libraries (optional, but needed for graphics and HyperDoc) On Debian (or Ubuntu) install the following packages. : sudo apt install libx11-dev
Re: [fricas-devel] INSTALL
On 19.04.2021 21:26, Waldek Hebisch wrote: ... > > Mainly the second, INSTALL should be readable as plain text. > It is OK to have marked up version as master source. Some > markup formats can produce decent looking plain text versions > (IIUC sphinx is supposed to produce text version, but ATM > this does not work for me so in particular I can not see > if this is good enough). Another issue is dependency. .rst > is claimend to be ligtweight, but supporting programs are > rather large... That's true, however, there are a lot of little helpers around, e.g. Emacs Support for reStructuredText https://docutils.sourceforge.io/docs/user/emacs.html > https://pandoc.org/MANUAL.html This (usually) provides good results: pandoc --from=rst --to=plain filename.rst OTOH --from=plain --to=rst is not always what you'll expect. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b381a783-5971-3bb8-6679-e9ffdf1d8cdd%40gmail.com.
Re: [fricas-devel] INSTALL
On Mon, Apr 19, 2021 at 3:26 PM Waldek Hebisch wrote: > > On Mon, Apr 19, 2021 at 08:33:02AM +0200, Ralf Hemmecke wrote: > > ... > > I definitely want install.rst on the web and showing a plain text file > > on an otherwise sphinx-generated site would look very unprofessional. > > .rst pretending to be plain text is at least as unprofessional. > -1 I disagree. Reading .rst in a text editor looks much better to me than most people's "plain text" and of course it looks even better on a web site or in a pdf document. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94TiS%2B1vyh0d_NvLj9jDOv7OUo6c6vWx39VPC-N-RkEy2A%40mail.gmail.com.
Re: [fricas-devel] INSTALL
On Mon, Apr 19, 2021 at 08:33:02AM +0200, Ralf Hemmecke wrote: > > After more careful look at 'install.rst' I think that for now we > > should go with plain text version. Namely, unlike README, > > .rst version looks significantly worse than plain text version. > > What do you mean by "worse"? > That you have to write verbose inline stuff inside ``...``? > That verbose code has to be put indented after a :: ? > That different title lines have to be followed by some underlining? > > That is basically all of the markup I used. Yes, that and |git repository| (we should have actual URL in the file). Problem is with quantity, that is actualy more than is some other markup formats. > What you basically say is, that my conversion was work-done-for-nothing. If you want to view it in this way. Not all things work as expected/hoped for... > My concern is now that you change the current INSTALL file. > Synchronization with my install.rst will be hard since I restructured a > bit. Are you afraid of writing .rst stuff or do you think that my > install.rst is not nicely readable as plain text? Mainly the second, INSTALL should be readable as plain text. It is OK to have marked up version as master source. Some markup formats can produce decent looking plain text versions (IIUC sphinx is supposed to produce text version, but ATM this does not work for me so in particular I can not see if this is good enough). Another issue is dependency. .rst is claimend to be ligtweight, but supporting programs are rather large... > I definitely want > install.rst on the web and showing a plain text file on an otherwise > sphinx-generated site would look very unprofessional. .rst pretending to be plain text is at least as unprofessional. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210419192622.GA38221%40math.uni.wroc.pl.
Re: [fricas-devel] numerical integration of a complex function?
Hello Waldek, Thanks a lot for your response. Apologies for the delay in my reply. I will replace *Float *and not *DoubleFloat* and see if I'm still getting working solutions. I will take a look into modifying my current code to modify it. As Tobias suggested, right now I also perhaps need to take a deep dive into various methods of numerical integration to get a hang of which one might be the best for my functions. best regards, Thejasvi On Thursday, April 15, 2021 at 12:05:29 AM UTC+2 Waldek Hebisch wrote: > On Wed, Apr 14, 2021 at 02:50:49PM +0200, thejasvi wrote: > > Hello Waldek and Ric > > Thanks so much for the function and comments you sent. > > The integration works pretty fast for the example function you showed. > > > > For my own use-case, I expect to need very high precision (eg. the > > Mathematica code I'm trying to port uses 300 digits for the same model). > > Is DoubleFloat the correct Type to use? > > No, DoubleFloat is limited to about 15 digits. You need to use Float > and use something like 'digits(300)' to set precision. Note: if you > really need 300 digits of final precision, you need to set bigger > precision for intermediate calculation. > > > > Given that the target is 300 digits precision, I tried to run the > adaptive > > integration with lower and lower errors (< 1.0e-16). > > It ended up taking a much longer time (didn't complete in 3mins). Do any > of > > you have ideas on how to overcome this. > > This routine is for DoubleFloat accuracy, using it as-is you can not > get better than what DoubleFloat allows. For better accuracy you > need the following: > > - replace DoubleFloat by Float. > - provide pl and wl of sufficient accuracy (that is 300 digits for > 300 results) > - probably increase order: current version uses Gaussian kwadrature > on 9 point, which gives order 17. At first glance 75 points > looks like reasonable choice for 300 digits accuracy. > > pl are nodes of Gaussian quadrature, they are zeros of appropriate > Legendre polynomial. wl are weights. My code assumes that number > of points is odd, then 0 is one of nodes, other nodes are symmetric. > I took adantage of symmetry to remember only half of nodes and > woights. Below is code that I used to compute nodes and weights > (this one for 45 points): > > digits(70) > pn := legendreP(45, x) > sols := solve(%, 1.0e-60) > solp := map(x +-> retract(rhs(x))@Float, last(sols, 23)) > dpn := D(pn, x) > wpp := [2/((1 - xi^2)*eval(dpn, x = xi)^2) for xi in solp] > wlf := map(retract, wpp)@List(Float) > > plf := rest(solp) > > wl := wlf::List(DoubleFloat) > pl := plf::List(DoubleFloat) > > Of course, for Float the last two lines should be replaced by > assignments. Note that 'solve' needs substantial time: it > uses robust method which however is slower than Newton when > you need large accuracy. So, using 'solve' with limited > accuracy and then Newton to improve approximation may be > faster. Extra remark: you should compute nodes and weights > once and then use for all integrations with given accuracy. > > Extra remarks: > - For highly oscilatory integrals you should use specialized > method. I did not look carefuly enough at your code to know > if you can use general method (Gaussian quadrature) or > need special one > - ATM in FriCAS Bessel functions have only DoubleFloat accuracy. > Bessel functions of half-integer order are elementary, so > for fixed (and hopefuly moderate) order you can use explicit > formulas to provide your own version > > > -- > Waldek Hebisch > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/54ab9840-72ee-4263-bd0e-332c012cdaefn%40googlegroups.com.
Re: [fricas-devel] numerical integration of a complex function?
Hello Tobias,
Thanks a lot for your reply. Apologies for the delay in response.
'*Are you sure that Mathematica gives you 300 digits precision
(PrecisionGoal), and doesn't just require 300 digits working precision
(WorkingPrecision)? Do you need 300 digits precision? *' -- the relevant
part of the Mathematica notebook says *{$MaxExtraPrecision, prec} = {500,
40} , *not sure whether this is the actual precision or the 'working
precision' as this is the first time I'm handling such involved numerical
calculations.
Great idea about digging deeper into how Mathematica itself is dealing with
the problem (I guess you meant Gnu Scientific ilbrary by GSL, this also
looks like a cool package . ) - this is a generic approach which I could
then use to test how the same algorithm implemented in another package
performs.
best,
Thejasvi
On Wednesday, April 14, 2021 at 4:26:13 PM UTC+2 Tobias Neumann wrote:
>
> > For my own use-case, I expect to need very high precision (eg. the
> Mathematica code I'm trying to port uses 300 digits for the same model).
> > Is DoubleFloat the correct Type to use?
>
> > Given that the target is 300 digits precision, I tried to run the
> adaptive integration with lower and lower errors (< 1.0e-16).
> > It ended up taking a much longer time (didn't complete in 3mins). Do any
> of you have ideas on how to overcome this.
>
> Are you sure that Mathematica gives you 300 digits precision
> (PrecisionGoal), and doesn't just require 300 digits working precision
> (WorkingPrecision)? Do you need 300 digits precision? If yes, then there
> likely won't be an out-of-the-box solution,
> especially with an oscillatory integrand.
>
> *If* Mathematica is able to get you 300 digits (PrecisionGoal) by just
> using NIntegrate, you should try to figure out which
> method it uses. By default it uses heuristics to choose a good method (
> https://reference.wolfram.com/language/tutorial/NIntegrateIntegrationStrategies.html
>
> ). This is especially relevant
> for those oscillatory integrands. I would try to replicate your success
> with Mathematica by explicitly specifying the integration method with
> NIntegrate. Once you have done so, you can either find a library that
> implements that method (or implement it yourself). For example
> GSL has some routines for oscillatory integrands
>
> Best wishes,
> Tobias
>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/808de225-b00d-41fb-88b7-694356e9fd67n%40googlegroups.com.
Re: [fricas-devel] INSTALL
there is https://github.com/fricas/fricas/pull/45 - not sure whether this is what one discusses here. Needless to say, 99% of people would read INSTALL in the browser, keeping it plaintext in 2021 is out of touch with the reality. On Mon, Apr 19, 2021 at 7:33 AM Ralf Hemmecke wrote: > > > After more careful look at 'install.rst' I think that for now we > > should go with plain text version. Namely, unlike README, > > .rst version looks significantly worse than plain text version. > > What do you mean by "worse"? > That you have to write verbose inline stuff inside ``...``? > That verbose code has to be put indented after a :: ? > That different title lines have to be followed by some underlining? > > That is basically all of the markup I used. > > What you basically say is, that my conversion was work-done-for-nothing. > > My concern is now that you change the current INSTALL file. > Synchronization with my install.rst will be hard since I restructured a > bit. Are you afraid of writing .rst stuff or do you think that my > install.rst is not nicely readable as plain text? I definitely want > install.rst on the web and showing a plain text file on an otherwise > sphinx-generated site would look very unprofessional. > > Can we make a compromise that you modify install.rst content-wise and I > add/correct the respective rst markup? > > Ralf > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to fricas-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/18c57d99-083d-6276-b9fe-3ef5b8f189ef%40hemmecke.org. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq3SASc1O%3Dhw9PM6rfK0%2BXK7JDcOOz%3D%2B5S%2BA_npVkXOwvw%40mail.gmail.com.
Re: [fricas-devel] INSTALL
> After more careful look at 'install.rst' I think that for now we > should go with plain text version. Namely, unlike README, > .rst version looks significantly worse than plain text version. What do you mean by "worse"? That you have to write verbose inline stuff inside ``...``? That verbose code has to be put indented after a :: ? That different title lines have to be followed by some underlining? That is basically all of the markup I used. What you basically say is, that my conversion was work-done-for-nothing. My concern is now that you change the current INSTALL file. Synchronization with my install.rst will be hard since I restructured a bit. Are you afraid of writing .rst stuff or do you think that my install.rst is not nicely readable as plain text? I definitely want install.rst on the web and showing a plain text file on an otherwise sphinx-generated site would look very unprofessional. Can we make a compromise that you modify install.rst content-wise and I add/correct the respective rst markup? Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/18c57d99-083d-6276-b9fe-3ef5b8f189ef%40hemmecke.org.
