>> So I think this patch improves result for some input
>> while not make it worse for others.
>
> Yes.
So this patch is acceptable?
This improved version will speed up a little.
(Note that in ilog0, a is of higher degree than b, so we
test b first.)
diff --git a/src/algebra/irexpand.spad b/src/
>
> A note on the differnece that my patch made to mapleok.output:
>
> in1638a, in1720a, in1856a,in1863a,in1872a suffers the limit
> bug I mentioned in the other thread. Because the diff includes
> "log", which shouldn't be.
The limit problem is because of complex values. Currently
indefinite
oldk1331 wrote:
>
> (1) -> limit(atan(sqrt(1-J*z)/sqrt(J-1)),z=1,"left")
>
>+---+
> \|- J + 1
>(1) log(- --)
> +-+
>2\|J - 1
> Type: Union(OrderedCompletion(Expression(Integer)),...)
> (2) ->
A note on the differnece that my patch made to mapleok.output:
in1638a, in1720a, in1856a,in1863a,in1872a suffers the limit
bug I mentioned in the other thread. Because the diff includes
"log", which shouldn't be.
in1721a: the difference is very small, merely sqrt(I-1) vs. (I-1)/sqrt(I-1)
in2108
(1) -> limit(atan(sqrt(1-J*z)/sqrt(J-1)),z=1,"left")
+---+
\|- J + 1
(1) log(- --)
+-+
2\|J - 1
Type: Union(OrderedCompletion(Expression(Integer)),...)
(2) -> limit(asin(sqrt(1-J*z)/sqrt(J-1)),z=
>
> On Mon, Feb 6, 2017 at 9:52 AM, Waldek Hebisch
> wrote:
> > No. I was writing about handling of 'float', especially
> > the lines:
> >
> > b := ((ll.3) pretend Integer)::SF
> > _*(a, EXPT(b, e)$Lisp)$Lisp pretend INF
> >
> > b was coverted to double, but a and e were kept as integer
oldk1331 wrote:
>
> OK, I'll go over the differences caused by my patch.
> But, if "I" is changed into "%i", then the integrator goes
> into different path (integrate vs. complexIntegrate),
> and I think "I vs. %i" will have a impact on "sign".
If you want to do extra testing for this patch, you
Kurt Pagani wrote:
>
> On Monday, 6 February 2017 04:07:55 UTC+1, oldk1331 wrote:
> >
> > So Kurt, I think you can include parts from src/doc/htex/ug*,
> > because BSD is compatible with wikipedia (which is CC)?
> > Did you talked with the guy who removed your passages,
> > Diannaa?
> >
> >
On Monday, 6 February 2017 04:07:55 UTC+1, oldk1331 wrote:
>
> So Kurt, I think you can include parts from src/doc/htex/ug*,
> because BSD is compatible with wikipedia (which is CC)?
> Did you talked with the guy who removed your passages,
> Diannaa?
>
>
Yep. See https://en.wikipedia.org/wiki
> As you see second variant resolved dependence between 'exp(2*x)',
> but the first one left it in place. In am thinking how we could
> nicely make 'normalize' available for more types. One possible
> trick is to run 'map' twice, first time for side effects to collect
> list of elements, th
So Kurt, I think you can include parts from src/doc/htex/ug*,
because BSD is compatible with wikipedia (which is CC)?
Did you talked with the guy who removed your passages,
Diannaa?
On Mon, Feb 6, 2017 at 10:57 AM, Waldek Hebisch
wrote:
> oldk1331 wrote:
>>
>> BTW, what's the copy right status of
oldk1331 wrote:
>
> BTW, what's the copy right status of the Jenks book, and
> src/doc/htex/ug*?
Jenks/Sutor book prined by (IIRC) Springer was specially
edited version of those files. Presumably Springer
has exclusive copyright to all editorial changes.
The files were part of Axiom source duri
On Mon, Feb 6, 2017 at 10:44 AM, Waldek Hebisch
wrote:
> oldk1331 wrote:
>>
>> > I mean text output: diffing output before and after change I
>> > see several changes to results of 'mapleok' (those are nastly
>> > examples that cross branch cuts).
>>
>> This patch fixes 'in249a:=integrate((sin(z)/
oldk1331 wrote:
>
> > I mean text output: diffing output before and after change I
> > see several changes to results of 'mapleok' (those are nastly
> > examples that cross branch cuts).
>
> This patch fixes 'in249a:=integrate((sin(z)/(cos(z)-1))^(1/3), z=
> 0..%pi,"noPole")'
> As for other diffe
Thank you, Kurt.
In the "History" section, it's better to say "started in 1965", right?
BTW, what's the copy right status of the Jenks book, and
src/doc/htex/ug*?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscri
> On Mon, Feb 6, 2017 at 9:52 AM, Waldek Hebisch
> wrote:
>> No. I was writing about handling of 'float', especially
>> the lines:
>>
>> b := ((ll.3) pretend Integer)::SF
>> _*(a, EXPT(b, e)$Lisp)$Lisp pretend INF
>>
>> b was coverted to double, but a and e were kept as integers.
>> AFAI
On Mon, Feb 6, 2017 at 9:52 AM, Waldek Hebisch wrote:
> No. I was writing about handling of 'float', especially
> the lines:
>
> b := ((ll.3) pretend Integer)::SF
> _*(a, EXPT(b, e)$Lisp)$Lisp pretend INF
>
> b was coverted to double, but a and e were kept as integers.
> AFAICS this maxim
> I mean text output: diffing output before and after change I
> see several changes to results of 'mapleok' (those are nastly
> examples that cross branch cuts).
This patch fixes 'in249a:=integrate((sin(z)/(cos(z)-1))^(1/3), z=
0..%pi,"noPole")'
As for other differences, I shall ask first:
The "I
oldk1331 wrote:
>
> On Mon, Feb 6, 2017 at 8:43 AM, Waldek Hebisch
> wrote:
> > Well, the code is clearly written to ensure exact result
> > with integer arguments (in appropriate range). But with
> > decent Lisp it should also work with floating point values.
>
> Are you saying that with "(se
On Mon, Feb 6, 2017 at 8:43 AM, Waldek Hebisch wrote:
> Well, the code is clearly written to ensure exact result
> with integer arguments (in appropriate range). But with
> decent Lisp it should also work with floating point values.
Are you saying that with "(setf *read-default-float-format* 'do
>
> > I am not sure if this is right. AFAICS after change the code
> > will do funny things with:
>
> What's the funny thing? With or without this patch, that EXPR FLOAT
> is the same?
Well, the code is clearly written to ensure exact result
with integer arguments (in appropriate range). But w
There is classic example which just reappeard on Maxima list:
(1) -> m := matrix([[2 + sin (x), 2 + cos (x)*tan (x)], [1, 1]])
+sin(x) + 2 cos(x)tan(x) + 2+
(1) ||
+1 1+
Type: Mat
Bill Page wrote:
>
> I think there is a potential in the 'latex' routines to produce a more
> "semantic" style of LaTeX output. See for example:
>
> https://www.researchgate.net/publication/216797904_Using_LaTeX_as_a_Semantic_Markup_Format
There is potential to put more information into latex ou
On Sunday, 5 February 2017 08:55:42 UTC+1, oldk1331 wrote:
>
> It's recently created, don't know who created it, but
> it's nice to have a dedicated wikipedia page for FriCAS.
>
> https://en.wikipedia.org/wiki/FriCAS
>
I took the liberty on a whim because several people asked me why there is
oldk1331 wrote:
>
> On Sun, Feb 5, 2017 at 12:00 PM, Waldek Hebisch
> wrote:
> > Well, what is independent variable depends on point of view.
> > In particular, it changes after substitutions. So
> > IntegrationResult can know independent variable only if
> > main integration code tells it. But
On 5 February 2017 at 02:55, oldk1331 wrote:
> It's recently created, don't know who created it, but
> it's nice to have a dedicated wikipedia page for FriCAS.
>
> https://en.wikipedia.org/wiki/FriCAS
>
+1
It seems like a good start. Perhaps we could discuss here what might
be added both on that
26 matches
Mail list logo
