On Thu, Apr 18, 2024 at 01:51:34PM -0700, 'Martin R' via FriCAS - computer
algebra system wrote:
> OK, I think I have to give up. The InputForm consists of 23 964 324
> atoms. I guess that there is no sensible way to transmit this, right?
Some more data. Using ECL on fast machine with plenty
On Thu, Apr 18, 2024 at 01:51:34PM -0700, 'Martin R' via FriCAS - computer
algebra system wrote:
> OK, I think I have to give up. The InputForm consists of 23 964 324
> atoms. I guess that there is no sensible way to transmit this, right?
Well, compress it. FriCAS internal representation is
On 18 April 2024 21:51:34 BST, 'Martin R' via FriCAS - computer algebra system
wrote:
>OK, I think I have to give up. The InputForm consists of 23 964 324
>atoms. I guess that there is no sensible way to transmit this, right?
In-memory - just how Maxima library interface is operating.
No
OK, I think I have to give up. The InputForm consists of 23 964 324
atoms. I guess that there is no sensible way to transmit this, right?
Martin
On Thursday 18 April 2024 at 21:50:57 UTC+2 Martin R wrote:
> I have now FriCAS with ECL, but I now realize that I am doing very silly
> things in
I have now FriCAS with ECL, but I now realize that I am doing very silly
things in the interface between FriCAS to sage:
* I do an unnecessary unparse of the InputForm (this runs forever on ECL,
and crashes sbcl)
* I throw the result away
* I convert the InputForm into a string using a
These are useful lisp commands, I did not know about them. This is what I
get for my Fricas installation
FriCAS Computer Algebra System
Version: FriCAS 1.3.10 built with sbcl 2.3.11
Timestamp: Wed Jan 10 09:37:52 PM CST 2024
(1) -> )lisp
Hi Waldek!
Thanks for the rapid answer!
I have:
)lisp (lisp-implementation-version)
2.1.11.debian
)lisp (sb-ext:dynamic-space-size)
1073741824
)version
FriCAS 2022-07-16 compiled at Fr 12 Aug 2022 15:17:27 CEST
I'm currently compiling the ECL version.
Unfortunately, because of the MacOS
On Thu, Apr 18, 2024 at 08:45:53AM -0700, 'Martin R' via FriCAS - computer
algebra system wrote:
> I started to look into one of the problems
> (https://github.com/sagemath/sage/issues/37813):
>
> res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x);
>
> works nicely, but
I started to look into one of the problems
(https://github.com/sagemath/sage/issues/37813):
res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x);
works nicely, but converting to InputForm (which I use to do the
translation to sage) fails. Is there a good reason for that - i.e., is
On Thu, Apr 18, 2024 at 09:21:17PM +0800, Qian Yun wrote:
>
>
> On 4/16/24 22:38, Waldek Hebisch wrote:
> >
> > Just a silly question: have you looked why the image is so big?
> > Your new image is 6.7M and bigger than scanned version (4.3M).
> > Old knot3.ps is 77k lines giving 1.1M size. At
On Wed, Apr 17, 2024 at 09:03:04AM +0200, Ralf Hemmecke wrote:
> > > Just a silly question: have you looked why the image is so big?
>
> Just a proposal. What about putting moderately sized smooth pictures into
> the book and high resolution pics at some place in the web and make to book
> only
On 4/16/24 22:38, Waldek Hebisch wrote:
Just a silly question: have you looked why the image is so big?
Your new image is 6.7M and bigger than scanned version (4.3M).
Old knot3.ps is 77k lines giving 1.1M size. At first glance
adding color to this could double or maybe triple the size.
.pdf
Currently we get mono color in postscript output of "smooth" style
3D drawings.
That's caused by "GSetForeground" before "GDrawPoint".
"GSetForeground" can only set gray scale.
Luckily the all four usage of "GDrawPoint" are all for the purpose
of generating "smooth" style image. So this change
13 matches
Mail list logo
