headers
Richard Hennessy | 1 Nov 2008 01:03
Picon

Re: pw.mac

BTW Edwin, I have been away on a trip to Chicago, that is why I am just getting back to you now.  I realised a bug 
exists in the diff rules on that trip but I am back now and can start to fix it probably tomorrow.  It is a pretty 
serious bug but it may go unnoticed so it is important to let the list know there is a problem.  I just did.

Rich

----- Original Message ----- 
From: "Edwin Woollett" <woollett <at> charter.net>
To: "Richard Hennessy" <rvh2007 <at> comcast.net>
Sent: Wednesday, October 29, 2008 2:06 PM
Subject: Re: pw.mac

Hi Richard,

I like your idea of extending the capability of more Maxima functions in
dealing
with piecewise defined functions, also expressions which used abs(x), etc.
I notice that the fourie.mac package does a pretty good job with dealing
with
abs(x) expressions which I am coming to appreciate more as I finish ch. 7:
symbolic integration.

I think that contributing a preliminary version of pw.mac to the
"source/contrib" section of the
software that one downloads with Maxima would be useful. Much of the code in
"share/contrib"
are "works in progress", and some are being improved gradually by those
interested or the
original contributors.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hennessy | 1 Nov 2008 01:10
Picon

Re: pw.mac

I am changing my options to not automatically include the original messege in replies.
Permalink | Reply | 0 comments |
headers
Richard Hennessy | 1 Nov 2008 02:12
Picon

Re: pw.mac

Hi,

I accidently posted some stuff that was private, please disregard that.  Thanks,

I need to reply to this though.

"Thanks for your support and feedback.  I will do as you say and put more information about myself, how to
contact me 
and
how to make suggestions for improvements.  I don't think this will make it into Maxima source right away but
the law of
supply and demand may determine the fate of pw.mac.

"but we can choose to follow a path of reason""

((in response to a remark I made in another private email.)

"Yes and that is what my family objects to."

(my reply above)

I any case that is all I will say about this accidental post.  I have turned off automatic addition of original
text in 
replies.

Thanks,

Rich
Permalink | Reply | 0 comments |
headers
Richard Hennessy | 1 Nov 2008 02:55
Picon

Re: New Maxima

"Most potential
< users don't want to deal with downloading maxima and it's gui
< wxmaxima separately. The command line maxima makes the user feel like
< it's some ancient DOS program and inherently inferior to Mathematica
< or any other CAS."

I wrote a program in 1978-79 that does output like Maxima's display2d=true just like command line Maxima
uses.  I was a 
second year sophomore at the time, so it is not rocket science.  Certainly some people think that is
adaquate, but I 
like wxMaxima much better.  Let's not bash all of Maxima because of it's inclusion of this old style of
output.  The GUI 
interface is available for people like you.

So what exactly is your problem?

Rich
Permalink | Reply | 0 comments |
headers
Richard Hennessy | 1 Nov 2008 03:56
Picon

Re: Maxima Digest, Vol 27, Issue 67

"'2D mathematical input' - I greatly prefer a 1D-style input, where I
don't have to remember keystrokes to support super- and subscripts,
rational dividers and the rest - I prefer that Maxima then gives me a 2D
representation of what I have entered as a check."

I think this 2d input is a valid point.  I don't like Mathematica very much, but I do like the "esc sometext esc"
style 
of 2d input.  I would put that in as a feature request for wxMaxima.

Rich
Permalink | Reply | 0 comments |
headers
Barton Willis | 1 Nov 2008 19:13
Favicon

Re: sign or conjugate bug

-----maxima-bounces <at> math.utexas.edu wrote: -----

>Thus, I have implemented code to extend $sign to give full support for
>complex
expressions. I have already posted some results on this mailing list. See:
>[Maxima] Complex mode for $sign. Perhaps, we should come back to the
>suggested code and implement full support for complex expressions.
>
>Dieter Kaiser

I looked at the patch file, but I didn't test it. Two questions:
Does this code pass the test suite; does this code fix any known
bugs in the test suite?

It seems that you put a great deal of time into this code; assuming
the patch doesn't break anything that you know of, maybe you should
go ahead an commit it. Over time, things like this get lost or go out
of date.

The sign code has many weaknesses (there are 11 out of 89 failures in
rtest_sign). Also, it's not easy to tell when a weakness is actually a
bug (I don't understand the algorithms in compar.lisp). The sign code
even fails for some linear assumptions. Ouch.

Till then, I think I can work around this bug.

Thanks for the work on a possible solution.

Barton
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dieter Kaiser | 1 Nov 2008 19:35
Picon

Re: sign or conjugate bug


-----Ursprüngliche Nachricht-----
Von: willisb <at> unk.edu [mailto:willisb <at> unk.edu] 

< I looked at the patch file, but I didn't test it. Two questions:
< Does this code pass the test suite; does this code fix any known
< bugs in the test suite?

I have designed a solution which do not change any of the behaviours of Maxima,
but gives gives the possibility to test complex epressions correctly. I have
achived this by using a flag to switch the $sign function in a complex mode. If
you use this $sign function in complex mode a lot of known problems vanish. But
also a lot of the code of Maxima depends on incorrect or not complete answers of
$sign.

< It seems that you put a great deal of time into this code; assuming
< the patch doesn't break anything that you know of, maybe you should
< go ahead an commit it. Over time, things like this get lost or go out
< of date.

< The sign code has many weaknesses (there are 11 out of 89 failures in
< rtest_sign). Also, it's not easy to tell when a weakness is actually a
< bug (I don't understand the algorithms in compar.lisp). The sign code
< even fails for some linear assumptions. Ouch.

I have done a very detailed analysis of the code of $sign. So I have learned
that this code is designed for real values. There are some hacks for complex
values, but that it is not enough to do good mathematic with complex values.

The fails are not bugs but restrictions of the code of $sign.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dieter Kaiser | 1 Nov 2008 19:51
Picon

Re: sign or conjugate bug

Here is my old positing concerning the sign-shift extension:

I have done some work on the code of $sign in compar.lisp to look for more
support of Complex expressions and have added some code for debugging. By the
way I have detected that we have a known bug in this code SF [1045920] "a>1 and
b>1, is a+b>2?". I think that it is not really a bug but a missing feature. The
routine signsum does not take into account the shift of an interval by the given
rules for symbols.

We can get more correct results adding the shift of the values (+1 for a and +1
for b) to the left side of the equation and do compare (-2)+(+2)+a+b>0. This can
be generalized with a routine which takes all known numerically bounds of the
symbols and substitute them into the expression. I have writen a subroutine
sign-shift:

(defun sign-shift (expr)
  (do ((l ($facts) (cdr l))
       (e expr)
       (flag) (fact) (num))
      ((null l) (if flag ($expand e) expr))
    (setq fact (car l))
    (cond 
      ((or (eq (caar fact) 'mgreaterp)
           (eq (caar fact) 'mgeqp))
       (cond
         ((and (symbolp (cadr fact))
               (not (member (cadr fact) '($%pi $%e $%gamma $%phi)))
               (mnump (caddr fact))
               (setq num (caddr fact))
               (not (zerop1 num))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hennessy | 1 Nov 2008 20:46
Picon

Re: New piecewise package in development

Okay, the bad news is that diff cannot be trusted.  The answer may look right to some users but it is not,
especially 
for complicated expressions.  The good news is that integrate works fine and I have discovered nothing at
all wrong with 
it.

The diff function cannot be fixed easily but it can be fixed, it is a mathematical reasoning error on my part
and the 
fix requires writing a lot of currently non-existent code.  But it will get done sometime over the next week
or so I 
hope.  I don't expect any problems.  Patience is a good thing.  I have to introduce the diracdelta functional
in order 
to make this work, currently I have been trying to avoid that, but it can't be done any other way that I know of
(or 
want to).  The solution is to define and make use of a new pw.mac function diracdelta(x).  That will work.

The problem can be shown to exist easily by considering the the following two identities.

integrate(diff(expr,x),x) == expr + C

and

diff(integrate(expr,x),x) == expr

They don't both work.  Try it on a complex expression like this one.  I have suppresed the output.

(%i4) f:[-10, -(x^2-25)/15, -5,  -15/3*sin(3*x), 0, x^2/6, 5, -(8*x-65)/6, 10];

(%i18) radcan(pw(f,x));
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Hennessy | 1 Nov 2008 22:31
Picon

Re: New piecewise package in development

Actually other CAS's can work with unitstep and diracdelta so if they can get it right so can I.  

Rich
Permalink | Reply | 5 comments |

Gmane