On 6/29/24 03:50, Waldek Hebisch wrote:
I looks that all changes to book build are now commited, right?
Yes, I have no relevant stuff in my waiting list.
Go forward with the release.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra
On 6/29/24 09:50, Waldek Hebisch wrote:
I looks that all changes to book build are now commited, right?
I've committed everything on my side.
Unless somebody thinks that this is bad idea I will commit the
trivil change to the FriCAS book below.
Looks OK.
- Qian
After that I would like
I looks that all changes to book build are now commited, right?
Unless somebody thinks that this is bad idea I will commit the
trivil change to the FriCAS book below.
After that I would like to really do the release.
diff --git a/src/doc/htex/ug07.htex b/src/doc/htex/ug07.htex
index 87ed8dc..d61
On 6/12/24 20:52, Ralf Hemmecke wrote:
Hi Qian,
why do you need to rewrite the -eval into a pipe?
@@ -502,6 +500,6 @@ ${GEN_VIEWPORTFILES_PHT}: %.pht: %.ht
${INPUT_EXTRA_INPUT} ${SMAN} \
mobius.VIEW: ${inputsrcdir}/mobius.input
(unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
-
Hi Qian,
why do you need to rewrite the -eval into a pipe?
@@ -502,6 +500,6 @@ ${GEN_VIEWPORTFILES_PHT}: %.pht: %.ht
${INPUT_EXTRA_INPUT} ${SMAN} \
mobius.VIEW: ${inputsrcdir}/mobius.input
(unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
- FRICAS_INITFILE='' ${XVFB} \
-
On Mon, 10 Jun 2024, 21:23 Waldek Hebisch, wrote:
> On Mon, Jun 10, 2024 at 09:47:53PM +0200, Ralf Hemmecke wrote:
> > On 6/10/24 20:34, Waldek Hebisch wrote:
> > > I would like to do new release in June. I would like to include
> > Qian work on HyperDoc and the FriCAS book, that is main thing
I've updated https://github.com/oldk1331/fricas/commits/new-ps-book/
I included a new workaround in
https://github.com/oldk1331/fricas/commit/d3a777911c5a3de5461acc09379c1c13c350e625
Let me explain:
Now I don't use "sman in pipe" to generate spool files from input files.
Now the spool files ar
Qian, in commit c9fff275a09df57039b2e9646d30c4fc158744a9
"support build with pdflatex"
the removal of the commented-out-section
%\head{subsection}{Browse Options}{ugBrowseOptions}
in ug14.htex should perhaps also included in this 'fix chapter 14
"Browse"' patch.
That all is anyway independent
On Tue, Jun 11, 2024 at 09:12:53PM +0800, Qian Yun wrote:
> I can commit the patch in "[PATCH] exit HyperDoc properly" then?
Yes.
> It's not affected by 'wait_for_client_read', because it's MenuServer
> instead of SessionManager/ViewportServer.
>
> It looks like the full fix for "sman in pipe" w
Also, is the patch 'fix chapter 14 "Browse"' good to go in?
+1
Ralf
PS:
Please keep you new-ps-book branch updated (i.e. rebase it).
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop r
I can commit the patch in "[PATCH] exit HyperDoc properly" then?
It's not affected by 'wait_for_client_read', because it's MenuServer
instead of SessionManager/ViewportServer.
It looks like the full fix for "sman in pipe" will not come in
before release. I will think of some workaround to build
I'd like you to reconsider updating config/* files.
We updated them to 2014 version in 2017.
I guess you didn't like "-unknown-" in the target triplet,
so you did manual modifications to remove it.
But with newer config/* files, this is no longer a problem,
now the system will be identified as "-
On Mon, Jun 10, 2024 at 09:47:53PM +0200, Ralf Hemmecke wrote:
> On 6/10/24 20:34, Waldek Hebisch wrote:
> > I would like to do new release in June. I would like to include
> > Qian work on HyperDoc and the FriCAS book, that is main thing
> > that needs to be resolved before release.
>
> I am loo
On 6/10/24 20:34, Waldek Hebisch wrote:
I would like to do new release in June. I would like to include
Qian work on HyperDoc and the FriCAS book, that is main thing
that needs to be resolved before release.
I am looking at Qian's stuff.
Unfortunately, the new release will break the FriCAS-Al
I would like to do new release in June. I would like to include
Qian work on HyperDoc and the FriCAS book, that is main thing
that needs to be resolved before release.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
On Thu, Dec 07, 2023 at 09:19:51AM +0800, oldk1331 wrote:
> Hi Waldek, what's your holiday plan? I'll submit patches outside of
> that time frame.
I develop FriCAS inmy free time and expect to have more free time
during holidays...
--
Waldek Hebisch
--
You receive
Hi Waldek, what's your holiday plan? I'll submit patches outside of
that time frame.
- Qian
On Thu, Dec 7, 2023 at 8:43 AM Waldek Hebisch wrote:
>
> I think that we should do new release early in January next year.
> I have rather long queue of thing "in making" and it will take
> long time to f
I think that we should do new release early in January next year.
I have rather long queue of thing "in making" and it will take
long time to finish them. But I think that we have valuable
changes and should include what is ready intead of stretching
release cycle.
--
On Fri, Mar 06, 2020 at 09:25:54PM +0100, Kurt Pagani wrote:
> Good :)
>
> BTW I compiled yesterday the current rev (fresh clone). I guess the version
> dates (2018) were already wrong in the last release (1.3.5 / 3 February 2019;
> according to https://en.wikipedia.org/wiki/FriCAS)? Or asked diff
Good :)
BTW I compiled yesterday the current rev (fresh clone). I guess the version
dates (2018) were already wrong in the last release (1.3.5 / 3 February 2019;
according to https://en.wikipedia.org/wiki/FriCAS)? Or asked differently, is
there a special policy?
FriCAS Com
Trunk is now closed for release. In next days I will add
release notes, create release branch and tarballs.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe fro
On Mon, Mar 02, 2020 at 03:36:34AM +0100, Kurt Pagani wrote:
> On 29.02.2020 15:15, Waldek Hebisch wrote:
>
> > The attached diff solves TeX problem in similar but I
> > think slightly better way.
>
> Indeed, perfect (tex_rev2620.pdf). Thanks!
>
> It may also work for TeXmacs,
> > but that I d
On Sat, 29 Feb 2020 at 17:38, Ralf Hemmecke wrote:
>
> >> one need not be forced to use github/gitlab workflows of pull/merge
> >> requests. One can instead work with named branches.
> >
> > Well, for FriCAS traditional branches are of limited use. My
> > main developement flow is interactive, co
On Sat, Feb 29, 2020 at 11:02 AM Dima Pasechnik wrote:
> ...
> The projects that stick to cvs or svn suffer,
> as cvs and svn are legacy tools, and forcing
> it on contributors is counterproductive.
>
+1 for git. Please.
--
You received this message because you are subscribed to the Google Grou
>> one need not be forced to use github/gitlab workflows of pull/merge
>> requests. One can instead work with named branches.
>
> Well, for FriCAS traditional branches are of limited use. My
> main developement flow is interactive, compiling only edited
> files and loading them, while if possible
On Sat, 29 Feb 2020, 09:51 Waldek Hebisch, wrote:
> On Sat, Feb 29, 2020 at 11:01:45AM -0500, Dima Pasechnik wrote:
> > On Sat, 29 Feb 2020, 08:11 Waldek Hebisch,
> wrote:
> >
> > > On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > > > ATM master sources are in svn, so diff is
On Sat, Feb 29, 2020 at 11:01:45AM -0500, Dima Pasechnik wrote:
> On Sat, 29 Feb 2020, 08:11 Waldek Hebisch, wrote:
>
> > On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > > ATM master sources are in svn, so diff is better than pull request.
> > >
> > > When do we switch to git
On Sat, 29 Feb 2020, 08:11 Waldek Hebisch, wrote:
> On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > ATM master sources are in svn, so diff is better than pull request.
> >
> > When do we switch to git?
> >
>
> Well, some time ago I thought that I am almost ready for switch.
>
On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > ATM master sources are in svn, so diff is better than pull request.
>
> When do we switch to git?
>
Well, some time ago I thought that I am almost ready for switch.
But then Camm Maguire wrote "fetch this special gcl branch".
Give
> ATM master sources are in svn, so diff is better than pull request.
When do we switch to git?
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
On Fri, Feb 28, 2020 at 01:45:53PM -0800, Neven Sajko wrote:
> Waldek, Ralf; regarding my previous email, I should have mentioned that
> info about stack and heap limits and how to raise them should be
> documented better for users of Fricas. Probably should go into the
> INSTALL file. Do you want
On Fri, Feb 28, 2020 at 12:05:12AM +0100, Ralf Hemmecke wrote:
> On 2/27/20 10:41 PM, Kurt Pagani wrote:
>
> The problem is not the conversion to TeX, but rather a strange way of
> storing that in OutputForm.
>
> (12) -> (eq1 :: OutputForm) pretend SExpression
>
>(12) (= ((PRIME f ",,,") x)
On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
> I'd like to point out two small issues. Would be great if one or the other
> could
> be resolved in a next release:
>
> -- The (TexFormat) output of derivatives of (univariate) functions looks ugly.
> Examples:
> - http://fricas-wiki.
On Fri, Feb 28, 2020 at 07:40:22PM +0100, Kurt Pagani wrote:
> On 28.02.2020 17:58, Waldek Hebisch wrote:
> > On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
> >>
> >> The second issue concerns big files (compile or read doesn't matter):
> >>
> >>
> >> --ECL
> >> -- (1) -> )r bigfile
>
Waldek, Ralf; regarding my previous email, I should have mentioned that
info about stack and heap limits and how to raise them should be
documented better for users of Fricas. Probably should go into the
INSTALL file. Do you want a Github pull request, or something?
--
You received this message b
Thanks for the hint. Actually this was discussed several times in the forum:
https://groups.google.com/forum/#!searchin/fricas-devel/dynamic-space-size%7Csort:date
Nevertheless this might be always an option, as a last resort ;)
If it could be fixed in the code, however, then it should be done.
> The second issue concerns big files (compile or read doesn't matter):
> ...
> --SBCL
> -- >> System error:
> -- Control stack exhausted (no more space for function call frames).
> -- This is probably due to heavily nested or infinitely recursive
function
> -- calls, or a tail call that SBCL
On 28.02.2020 17:58, Waldek Hebisch wrote:
> On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
>>
>> The second issue concerns big files (compile or read doesn't matter):
>>
>>
>> --ECL
>> -- (1) -> )r bigfile
>> --
>> -- >> System error:
>> -- C-STACK overflow at size 1042432. Stack
On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
>
> The second issue concerns big files (compile or read doesn't matter):
>
>
> --ECL
> -- (1) -> )r bigfile
> --
> -- >> System error:
> -- C-STACK overflow at size 1042432. Stack can probably be resized.
> -- Proceed with caution
>
> The problem is not the conversion to TeX, but rather a strange way of
> storing that in OutputForm.
>
> (12) -> (eq1 :: OutputForm) pretend SExpression
>
>(12) (= ((PRIME f ",,,") x) (^ x n))
>
You're right, of course. The root of all evil (not all, though) in TEX is found
in OUTFORM.
On 2/27/20 10:41 PM, Kurt Pagani wrote:
> I'd like to point out two small issues. Would be great if one or the other
> could
> be resolved in a next release:
>
> -- The (TexFormat) output of derivatives of (univariate) functions looks ugly.
> Examples:
> - http://fricas-wiki.math.uni.wroc.pl/TexF
I am thinking about new release. To say the truth we have
quite long list of open bugs and it would be good to fix
some of them before release. However there is long time
from last release, we have new code that should get more
use. And most bugs probaly will require long time to fix.
For exampl
Prof. Dr. Johanneas Grabmeier wrote:
>
> no and yes:
>
> a finite group is not necessarily commutative, I only changed the
> CyclicGroup there!
>
> MRING: Yes, we need CommutativeRing !
>
Yes, only cyclic group. Commited now (I also changed infinite
cyclic group).
--
no and yes:
a finite group is not necessarily commutative, I only changed the
CyclicGroup there!
MRING: Yes, we need CommutativeRing !
Am 11.09.15 um 15:07 schrieb Waldek Hebisch:
> Prof. Dr. Johanneas Grabmeier wrote:
>> here a two little improvements/enhancements:
>>
>> I made CyclicGroup of
Prof. Dr. Johanneas Grabmeier wrote:
>
> here a two little improvements/enhancements:
>
> I made CyclicGroup of category CommutativeStar and accordingly for
> MonoidRing, if the Monoid has CommutativeStar, so we can e.g. compute
> the determinant of a matrix over a group ring of the cyclic group.
ok seems that I have forgotten that :-(
Am 11.09.15 um 09:34 schrieb Franz Lehner:
> Hello,
>
> On Fri, 11 Sep 2015, Prof. Dr. Johannes Grabmeier privat wrote:
>> also added a function monomialElements as partner of coefficients, which
>> was missing in MonoidRing.
> There is a function called 's
Hello,
On Fri, 11 Sep 2015, Prof. Dr. Johannes Grabmeier privat wrote:
also added a function monomialElements as partner of coefficients, which
was missing in MonoidRing.
There is a function called 'support' which does exactly this IIUC.
Franz
Hallo Waldek,
here a two little improvements/enhancements:
I made CyclicGroup of category CommutativeStar and accordingly for
MonoidRing, if the Monoid has CommutativeStar, so we can e.g. compute
the determinant of a matrix over a group ring of the cyclic group. I
also added a function monomialEl
Ralf Hemmecke wrote:
>
>
> currently, the aldor compilation fails for at least two reasons.
> 1) generalization of the polynomial coefficient domain
> 2) lodof2.
>
> I can probably fix (1) easily via adaptation of initlist.as, but (2)
> seems to be a bit more involved.
>
> The problem is here:
On 09/09/2015 03:25 AM, Waldek Hebisch wrote:
> I would like to do a new release in September.
Hi Waldek, hi Abhinav,
currently, the aldor compilation fails for at least two reasons.
1) generalization of the polynomial coefficient domain
2) lodof2.
I can probably fix (1) easily via adaptation o
I would like to do a new release in September. There is still
some time to include new code. In about 10 days I would like
to start release process (that is up to release allow only
critical bugfixes).
--
Waldek Hebisch
hebi...@math.uni.wroc.pl
--
You received t
I would like to make a new release sometime in June (probably in
third week of June). Things go slower than I wish and I
have several unfinished developements that would be nice
to release. But most probably will be too late. There
is temptation to wait till new things are finished. However
we
I remain strongly motivated to include something in FriCAS to provide
symbolic conjugate in Expression but I think that so far we have not
had sufficient opportunity to resolve differences of opinion on what
effect this might have on other parts of FriCAS. I am also a bit
disappointed that this do
I would like to do new release soon. There is still possibility
to include new code, but I would like to avoid longer delay and
get closer to two month cycle.
--
Waldek Hebisch
hebi...@math.uni.wroc.pl
--
You received this message because you are subscribed to th
On Friday, 19 December 2014 19:06:42 UTC, Waldek Hebisch wrote:
>
> Dima Pasechnik wrote:
> >
> > On Wednesday, 17 December 2014 16:00:03 UTC, Ralf Hemmecke wrote:
> > >
> > > >> Dima, in fact, it's not s easy with (La)TeX. It depends on how
> > > >> you see it. One way is that TeX (the
Dima Pasechnik wrote:
>
> On Wednesday, 17 December 2014 16:00:03 UTC, Ralf Hemmecke wrote:
> >
> > >> Dima, in fact, it's not s easy with (La)TeX. It depends on how
> > >> you see it. One way is that TeX (the program) is a compiler that
> > >> translates the sources (i.e. .tex, .sty, and .b
On Wednesday, 17 December 2014 16:00:03 UTC, Ralf Hemmecke wrote:
>
> >> Dima, in fact, it's not s easy with (La)TeX. It depends on how
> >> you see it. One way is that TeX (the program) is a compiler that
> >> translates the sources (i.e. .tex, .sty, and .bib, ... files --
> >> which can
On Wednesday, 17 December 2014 16:00:03 UTC, Ralf Hemmecke wrote:
>
> >> Dima, in fact, it's not s easy with (La)TeX. It depends on how
> >> you see it. One way is that TeX (the program) is a compiler that
> >> translates the sources (i.e. .tex, .sty, and .bib, ... files --
> >> which can
>> Dima, in fact, it's not s easy with (La)TeX. It depends on how
>> you see it. One way is that TeX (the program) is a compiler that
>> translates the sources (i.e. .tex, .sty, and .bib, ... files --
>> which can count as the program sources since TeX is a programming
>> language). Then the .d
On Friday, 12 December 2014 23:52:55 UTC, Ralf Hemmecke wrote:
>
> >> 1) Distributing binary + a patch without full sorces.
>
> GPL does not forbid that. GPL only says that you have to make the
> sources available in a form that they are normally build from.
> But you don't have to distribute
>> 1) Distributing binary + a patch without full sorces.
GPL does not forbid that. GPL only says that you have to make the
sources available in a form that they are normally build from.
But you don't have to distribute them together with the binary.
You don't even have to make them public, ither.
On Thursday, 11 December 2014 19:11:53 UTC, Waldek Hebisch wrote:
>
> Ralf Hemmecke wrote:
> >
> > On 10/16/2014 03:28 PM, Waldek Hebisch wrote:
>
> > > OTOH GPL causes inconvenice (some reasonable things are forbidden by
> > > GPL). At least for now BSD looks like better choice.
> >
> > M
Ralf Hemmecke wrote:
>
> On 10/16/2014 03:28 PM, Waldek Hebisch wrote:
> > OTOH GPL causes inconvenice (some reasonable things are forbidden by
> > GPL). At least for now BSD looks like better choice.
>
> Maybe BSD looks better for you, but what exactly is your fear with GPL?
> What are thoses
In section 6.21 of the 'book' we have:
"This longer notation gives you patterns that the standard notation
won't handle. For example, the rule
rule %f(c * 'x) == c*%f(x)
means for all f and c, replace f(y) by c*f(x) when y is the product of c
and the explicit variable x."
This does not work u
On 10/16/2014 03:28 PM, Waldek Hebisch wrote:
> Well, GPL was not designed to extract benefits from other people.
> Goal of GPL is to preserve freedom of software.
Right. I cannot force other people to give me their improvements.
But if they distribute anything, they have to distribute the source
On 16 October 2014 02:01, Ralf Hemmecke wrote:
>> What will be the impact on efricas and axiom-wiki of these changes?
>
> There's a patch for efricas included.
Great.
> --> Since the previous tex.spad+emacs connection did not have any
> line breaking mechanism, you should see an improvement.
r
Ralf Hemmecke wrote:
>
> On 10/12/2014 04:32 AM, Waldek Hebisch wrote:
> > Ralf Hemmecke wrote:
> >>
> >> On 09/08/2014 01:27 AM, Waldek Hebisch wrote:
> >>> If there is some code you want included in new release
> >>> please speak up.
> >>
> >> I don't know whether it must be included, but there
> What will be the impact on efricas and axiom-wiki of these changes?
There's a patch for efricas included. --> Since the previous
tex.spad+emacs connection did not have any line breaking mechanism, you
should see an improvement. I asked often enough, seemingly nobody tried.
I only care about the
On 15 October 2014 17:39, Ralf Hemmecke wrote:
> On 10/12/2014 04:32 AM, Waldek Hebisch wrote:
>>
>> Technically this looks fine. But why you create licence discontinuity
>> by putting GPL inside provided macro file?
>
> I'd love to see FriCAS under GPL.
>
As much as support open source I am rat
On 10/12/2014 04:32 AM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>>
>> On 09/08/2014 01:27 AM, Waldek Hebisch wrote:
>>> If there is some code you want included in new release
>>> please speak up.
>>
>> I don't know whether it must be included, but there was
>> https://www.mail-archive.com/fric
As you can see thing go slower than I planned. There are things
which I hoped to be able to include (mainly changes to integration
routines), but will take some time to finish. So I think
it is time stop adding new things (there are a lot of changes
already). Unless some serious problem shows up
Ralf Hemmecke wrote:
>
> On 09/08/2014 01:27 AM, Waldek Hebisch wrote:
> > If there is some code you want included in new release
> > please speak up.
>
> I don't know whether it must be included, but there was
> https://www.mail-archive.com/fricas-devel@googlegroups.com/msg07524.html
>
Technic
On Tuesday, 7 October 2014 16:08:45 UTC+2, Waldek Hebisch wrote:
>
> kfp wrote:
> >
> > Concerning GnuDraw: I'm having endorsed Fricas to a lot of people of
> which
> > there are several cygwin users (mostly -nosman). The prize for
> endorsement
> > a software is you will be asked for this
On 7 October 2014 10:08, Waldek Hebisch wrote:
> kfp wrote:
>>
>> Concerning GnuDraw: I'm having endorsed Fricas to a lot of people of which
>> there are several cygwin users (mostly -nosman). The prize for endorsement
>> a software is you will be asked for this and that, and especially plotting
>
kfp wrote:
>
> Concerning GnuDraw: I'm having endorsed Fricas to a lot of people of which
> there are several cygwin users (mostly -nosman). The prize for endorsement
> a software is you will be asked for this and that, and especially plotting
> is a popular topic (a heritage of wxMaxima). To b
On 10/01/2014 04:40 PM, Bill Page wrote:
> I have committed my changes for the texmacs interface to svn. I can
> confirm that the full build works using SBCL 1.1.11-2.1.4-suse on
> 64-bit OpenSuse 13.1. I have not tested on any non-unicode supporting
> lisps.
>
> One minor note: I can to modify
I have committed my changes for the texmacs interface to svn. I can
confirm that the full build works using SBCL 1.1.11-2.1.4-suse on
64-bit OpenSuse 13.1. I have not tested on any non-unicode supporting
lisps.
One minor note: I can to modify the 3rd line of '/usr/localbin/fricas' from:
AXIOM=
On 09/28/2014 05:12 PM, Waldek Hebisch wrote:
>> I'd appreciate to add Rioboo's code with two commits (and with the
>> URLs that I've put at the top of the file). First commit would be
>> the original code as is and the second commit with all the
>> modifications to make it run in FriCAS and beauti
Ralf Hemmecke wrote:
>
> On 09/28/2014 02:18 AM, Waldek Hebisch wrote:
> >> Look at https://github.com/hemmecke/fricas/commits/cyldec .
> >>
> >> If accepted, I'll squash the 4 commits into just one and add a ChangeLog
> >> entry.
>
> > http://www.math.uni.wroc.pl/~hebisch/fricas/cyldec.spad
> >
On 09/28/2014 02:18 AM, Waldek Hebisch wrote:
>> Look at https://github.com/hemmecke/fricas/commits/cyldec .
>>
>> If accepted, I'll squash the 4 commits into just one and add a ChangeLog
>> entry.
> http://www.math.uni.wroc.pl/~hebisch/fricas/cyldec.spad
> http://www.math.uni.wroc.pl/~hebisch/fri
Bill Page wrote:
>
> I would like to include:
>
> 1) my extensions to the TeXmacs output format to include the full
> set of symbols supported by TeXmacs
>
> https://github.com/billpage/fricas/commit/d93ead5f231ab6b29ba76ff60017fd6a9848b0e4#diff-0
Looks OK. Please commit (after making s
Ralf Hemmecke wrote:
>
> >> If there is some code you want included in new release
> >> please speak up.
>
> I've just put together the patch of Rioboo's CAD package.
>
> I had to modify #1 to +-> but otherwise no problem.
>
> Look at https://github.com/hemmecke/fricas/commits/cyldec .
>
> If
On 20 September 2014 09:19, Waldek Hebisch wrote:
>>
>> > But then you get something quite different than 'Expression'.
>>
> Bill Page wrote:
>>
>> That is not clear to me. I think it is (almost) the same.
>
> Some people say that mutivariate calculus is almost the
> same as univariate. But ther
Bill Page wrote:
>
> On 14 September 2014 18:18, Waldek Hebisch wrote:
>
> > But once you have 'abs' and 'conjugate' in 'Expression' assumption
> > that all functions are holomorphic is unsound.
>
> conjugate is sufficient since we want abs(x)=sqrt(x*conjugate(x)).
>
> We should not make the
Hi Waldek,
> ATM git is a burden for me:
> on my main machine I accidentaly deleted my old git
> installation and I hit problem installing new version.
You must have a fairly strange or old computer that a git installation
is problematic.
> So currently I need to pull repo to server and than
> t
On 14 September 2014 18:18, Waldek Hebisch wrote:
> ...
> Let me explain: Wirtinger derivatives are fine. But they form
> effectively _bivariate_ calculus. More precisely, instead
> of one complex variable we have two derivatives build from
> derivatives in two real variables.
It isn't necessa
Bill Page wrote:
>
> On 2014-09-13 10:40 AM, "Waldek Hebisch" wrote:
> >
> > I think that this is wrong way. Namely you take unsound
> > default (that is make 'D(conjugate(x), x)' equal to 0)
>
> To my knowledge Wirtinger calculus, which defines D(conjugate(x),x) =
> 0, is an accepted albeit in
On 2014-09-13 10:40 AM, "Waldek Hebisch" wrote:
>
> Bill Page wrote:
> >
> > I made a preliminary change to ElementaryFunctionStructurePackage here:
> >
> >
> > http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage
> >
> > which avoids the "Hidden constant detected" erro
Waldek,
I'm terribly sorry provoking the necessity of your exposition. The
infelicity of the expression " I wonder anyway why it's not yet included"
is obvious (by hindsight). Nevertheless, your statements are clear and
comprehensible. Nobody wants trash code included.
Concerning GnuDraw: I'm
kfp wrote:
>
> On Saturday, 13 September 2014 06:24:21 UTC+2, Bill Page wrote:
> >
> > Kurt,
> >
> > Thanks for the example output. I am glad that it works and maybe it is
> > still an argument to include gnuDraw in the next release even if we do
> > not extend the TeXmacs interface to use it e
Bill Page wrote:
>
> Waldek,
>
> With the version of FriCAS on the wiki and the most recent code for
> FunctionalSpecialFunction I get what look to me to be reasonable
> results for your examples labelled with (1), (3), (3) and (3) below.
>
> See:
>
> http://axiom-wiki.newsynthesis.org/SandBoxF
Hello Bill
On Saturday, 13 September 2014 06:24:21 UTC+2, Bill Page wrote:
>
> Kurt,
>
> Thanks for the example output. I am glad that it works and maybe it is
> still an argument to include gnuDraw in the next release even if we do
> not extend the TeXmacs interface to use it easily.
>
*By a
Bill Page wrote:
>
> I made a preliminary change to ElementaryFunctionStructurePackage here:
>
> http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage
>
> which avoids the "Hidden constant detected" error. The main idea is
> just to avoid differentiating conjugate by r
I made a preliminary change to ElementaryFunctionStructurePackage here:
http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage
which avoids the "Hidden constant detected" error. The main idea is
just to avoid differentiating conjugate by replacing it with a dummy
placeho
Kurt,
Thanks for the example output. I am glad that it works and maybe it is
still an argument to include gnuDraw in the next release even if we do
not extend the TeXmacs interface to use it easily.
I have never tried it but I thought maybe you could use the TeXmacs
gnuplot plugin?
http://www.te
On Friday, 12 September 2014 16:26:07 UTC+2, Bill Page wrote:
>
> Kurt,
>
> Could you send an example of your use of gnuDraw in TeXmacs? Perhaps
> we could encourage Waldek to include the gnuDraw code in the new
> release.
>
> Maybe we could somehow embed your tmcmd into the TeXmacs FriCAS i
Waldek,
With the version of FriCAS on the wiki and the most recent code for
FunctionalSpecialFunction I get what look to me to be reasonable
results for your examples labelled with (1), (3), (3) and (3) below.
See:
http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction#eq27
Your ex
Kurt,
Could you send an example of your use of gnuDraw in TeXmacs? Perhaps
we could encourage Waldek to include the gnuDraw code in the new
release.
Maybe we could somehow embed your tmcmd into the TeXmacs FriCAS interface.
Bill.
On 9 September 2014 06:51, kfp wrote:
>
>
> On Tuesday, 9 Septe
Thanks Waldek. As usual I appreciate your thorough look at what I
wrote for conjugate.
On 11 September 2014 07:28, Waldek Hebisch wrote:
>> > Bill Page wrote:
>>
>> The code that I wrote for conjugate assumes that operators always
>> represent holomorphic functions, while conjugate itself is expl
Bill Page wrote:
>
> On 8 September 2014 15:15, Waldek Hebisch wrote:
> > Bill Page wrote:
> >>
> >> I would like to include:
> >>
> >> 2) my code for adding conjugate to special functions
> >> http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction
> >
> > Definitions you gave
1 - 100 of 131 matches
Mail list logo
