headers
Camm Maguire | 1 Oct 2002 07:01

Re: Re: [Maxima] Re: m68k gcl/maxima: Minor Floating point errors

Greetings!  I think its a matter of when the registers are written to
memory.  Apparently the m68k can optimize in such a way that many
intermediate results are held in registers before having to be written
out.  There is no -ffloat-store on x86.  The difference is perhaps
related to the paucity of registers on x86, and the fact that m68k
registers are *96* bits wide, AFAICR, instead of 80.  But in general,
one does get more precision on x86 FPU calculations than the strictly
64bit SSE2, for example.

Take care,

Raymond Toy <toy <at> rtp.ericsson.se> writes:

> >>>>> "Camm" == Camm Maguire <camm <at> enhanced.com> writes:
> 
>     Camm> Greetings!
>     Camm> Rick Younie <rick <at> def.debian.net> writes:
> 
>     >> Camm Maguire wrote:
>     >> > Greetings!  I have one Debian machine (m68k) which is producing very
>     >> > small numerical discrepancies on the results of the two floating point
>     >> > intensive tests in rtest8.mac:
>     >> 
>     >> Hi,
>     >> 
>     >> That rang a bell.  There's this in the gcc man page:
>     >> 
>     >> -ffloat-store
>     >> Do  not  store floating point variables in registers.  This pre-
>     >> vents undesirable excess precision on machines such as the 68000
(Continue reading)

Permalink | Reply | 0 comments |
headers
jarausch | 1 Oct 2002 09:15
Picon
Picon
Favicon

CVS (x)maxima build fails for me

Hi all,

I would appreciate some help from you.

I tried to build the current cvs version of Maxima.

I am using Linux 2.4.20-pre8, tcl/tk 8.4.0, xfree 4.2  and

1st try:  using cmucl-20020404-x86-linuxglibc22
  Maxima builds fine, but when starting xmaxima
  I have troubles:

After a while I get: "Starting maxima timed out"
double click on an expression in Maxima's Primer, I get  
Failed to eval region
Failed to eval region
    while executing
"error "Failed to eval region""
    (procedure "doInvoke" line 50)
    invoked from within
"doInvoke .browser.t1.text  <at> 109,267 "
    (command bound to event)

click on File->exit terminates the whole X11 session

-----

2nd try   lisp -v  gives

Warning:  #<Command Line Switch "v"> is an illegal switch
(Continue reading)

Permalink | Reply | 2 comments |
headers
Valerij Pipin | 1 Oct 2002 13:30
Picon

Re: CVS (x)maxima build fails for me

Hi,
I guess maxima starts well on terminal. In this case you could check the 
options of your host, in particular, the word "localhost" should be present 
in /etc/hosts. Hope this help ...
> Hi all,
>
> I would appreciate some help from you.
>
> I tried to build the current cvs version of Maxima.
>
> I am using Linux 2.4.20-pre8, tcl/tk 8.4.0, xfree 4.2  and
>
> 1st try:  using cmucl-20020404-x86-linuxglibc22
>   Maxima builds fine, but when starting xmaxima
>   I have troubles:
>
> After a while I get: "Starting maxima timed out"
> double click on an expression in Maxima's Primer, I get
> Failed to eval region
> Failed to eval region
>     while executing
> "error "Failed to eval region""
>     (procedure "doInvoke" line 50)
>     invoked from within
> "doInvoke .browser.t1.text  <at> 109,267 "
>     (command bound to event)
>
> click on File->exit terminates the whole X11 session
>
> -----
(Continue reading)

Permalink | Reply | 0 comments |
headers
offray.luna | 1 Oct 2002 13:32
Picon
Favicon

Re: Reference Manual

Hi all,

El sáb, 28-09-2002 a las 12:39, Mike Clarkson escribió:
[...] 
> > I note your Copyright on the document, with the all rights reserved
> > notice.  What impact on usage of the documents does this have? Will we
> > be able to use parts of this in other documents concerning Maxima?  
> 
> No impact - the copyright just means "don't publish this thing as a book
> without checking with me first." After all, I didn't write the content!

Great! maybe you can try the Open Resources Magazine which grants the
rigths for vervatim copies and derivated works _only_ for translations.
(May be I can help with a spanish tranlation). I know that may be this
is not a updated documentation but having the doc translated to spanish
would make easier coordinate a "multilingual" documentation efford for
the 6.0 release.

> There's a lot of work to be done cleaning up the content - Maxima is huge,
> and it's unclear to me how much of the content referes to things that
> still exist. Still, I think it's well organized and complete,
> and it's cross-referenced and indexed which is a big deal.
> 
> Mike.
> 
Yep, and what you have done is a great work, thanks a lot Mike,

Cheers,

Offray
(Continue reading)

Permalink | Reply | 501 comments |
headers
Raymond Toy | 1 Oct 2002 16:10
Picon
Picon

Re: float(%e^%e)

>>>>> "willisb" == willisb  <willisb <at> unk.edu> writes:

    willisb> fixes the float(%e^%e) problem. Have I overlooked something?
    willisb> (I suppose one might try doing something more intelligent when the
    willisb> exponent is a an integer.)

    willisb> Fixing $FLOAT doesn't fix the %e ^ %e, numer bug.

I think I've found a solution.  In simpexpt in simp.lisp, the
following form fixes the issue:

	      ((EQ GR '$%E)
	       (COND (($BFLOATP POT) (RETURN ($BFLOAT (LIST '(MEXPT) '$%E POT))))
		     ((OR (FLOATP POT) (AND $NUMER (INTEGERP POT)))
		      (RETURN (EXP (float POT))))
		     ((AND $LOGSIMP (AMONG '%LOG POT)) (RETURN (%ETOLOG POT)))
		     ((AND $DEMOIVRE (SETQ Z (DEMOIVRE POT))) (RETURN Z))
		     ((AND $%EMODE (SETQ Z (%ESPECIAL POT))) (RETURN Z))
		     ($numer
		      (return ($float (list '(mexpt) '$%e pot))))))

(Look for the lower-case stuff).  At this point POT is the exponent.
For the case where POT is an integer, we weren't converting that to a
double-float so exp was returning a single-float answer instead of
double.

The added cond case just says to numerically evaluate the expression.
Of course, we need your $float fix for this to work.  Alternatively,
without your $float fix, we can do something like
(Continue reading)

Permalink | Reply | 7 comments |
headers
Richard Fateman | 1 Oct 2002 16:41
Picon
Favicon

Re: float(%e^%e)

Looks pretty safe to me.

Historical tidbit... you may wonder how GR is mnemonic for
"base" and POT is mnemonic for "power"  as in ((mexpt) GR POT).

It turns out that the macsyma simplifer owes its roots to a
program written by Knut Korsvold in 1963 or so at Stanford University.
It seems that Knut's native language  (Norwegian?) has words
for these parts.  I don't know what they really are, but
I think they are something like  grosse  and potenz.

How much is left of Korsvold's simplifier? In terms of
actual code, it is probably a very small percentage.  The idea
of hanging the simplification tools on the property lists of
symbols (like MEXPT) was in the original code.  Korsvold's
program, called "simplify"  I think, also allowed for adding
rules.  This was eliminated in the Macsyma version by the
time I saw it in 1968.

I see there is a bug in the bibliographic reference to korsvold
in http://www.cs.berkeley.edu/~fateman/papers/simplifier.txt.
It lists Stanford AI memo #37, but dates it as 1985.
It clearly was not 1985, since that would have required time
travel. Maybe 1965?

RJF

Raymond Toy wrote:
>>>>>>"willisb" == willisb  <willisb <at> unk.edu> writes:
>>>>>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Richard Fateman | 1 Oct 2002 16:52
Picon
Favicon

Korsvold simplifier


Richard Fateman wrote:

> 
> I see there is a bug in the bibliographic reference to korsvold
> in http://www.cs.berkeley.edu/~fateman/papers/simplifier.txt.
> It lists Stanford AI memo #37, but dates it as 1985.
> It clearly was not 1985, since that would have required time
> travel. Maybe 1965?
> 
> RJF
Prompted by my own remark,
I found another reference to Korsvold, with the proper data 1965,
and so I fixed it in there.   The 1985 was, I am guessing, an OCR
error.  Revising history was never easier:)

The ACM digital library portal credits a report on this
to SIGSAC, a special interest group on security audit and control.
No doubt that didn't exist in 1966, and it is either a misprint for
SIGSAM, or possibly SIGSAM was called SIGSAC then.  (seems unlikely).
a bibtex reference to a report on the memo..
 <at> inproceedings{807963,
  author = {Knut Korsvold},
  title = {An on line program for non-numerical algebra},
  booktitle = {Proceedings of the ACM symposium on Symbolic and 
algebraic manipulation},
  year = {1966},
  pages = {1301--1314},
  }
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Amundson | 1 Oct 2002 16:59
Favicon

[Fwd: FW: Cannot compile functions if working directory contains a space]

-----Forwarded Message-----

From: "Billinghurst, David (CRTS)" <David.Billinghurst <at> riotinto.com>
To: amundson <at> fnal.gov
Subject: FW: Cannot compile functions if working directory contains a space
Date: 01 Oct 2002 09:26:06 +1000

Jim,

Can you post this to the maxima list.  My attempts are failing.

-----Original Message-----
From: Billinghurst, David (CRTS) 
Sent: Monday, 30 September 2002 5:27 
To: 'maxima <at> www.ma.utexas.edu'
Subject: Cannot compile functions if working directory contains a space

If the name of the working directory contains a space
then compile fails.  First noticed with xmaxima icon
on desktop, when the default directory is
C:\Documents and Settings\user.name\Desktop\

With "Start in:" set to "C:\J J"

(C1) f(x):=x+2;
(D1) 				 f(x) := x + 2
(C2) compile(f);

Error:  cannot be coerced to a pathname.
Fast links are on: do (si::use-fast-links nil) for debugging
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Amundson | 1 Oct 2002 16:59
Favicon

[Fwd: Testsuite interaction: declare(integrate, noun)]

-----Forwarded Message-----

From: "Billinghurst, David (CRTS)" <David.Billinghurst <at> riotinto.com>
To: amundson <at> fnal.gov
Subject: Testsuite interaction: declare(integrate, noun)
Date: 01 Oct 2002 09:26:47 +1000

Jim,

Can you post this to the maxima list.  My attempts are failing.

-----Original Message-----
From: Billinghurst, David (CRTS) 
Sent: Monday, 30 September 2002 5:29 
To: 'maxima <at> www.ma.utexas.edu'
Subject: Testsuite interaction: declare(integrate, noun)

Some tests in rtestode.mac are commented out.  They pass if
the test is run in isolation, but fail due to interference from 
previous test files.  Some cut and paste shows that files
rtest3.mac and rtest12.mac cause failures in rtestode.mac.
(The failing tests are commented out at present).

I have generated a reduced case.  Running the two line
rtest3.mac before the four line rtestode.mac ends in failure.

How does one undo a DECLARE(INTEGRATE,NOUN); ?

/* rtest3.mac */
DECLARE(INTEGRATE,NOUN);
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Amundson | 1 Oct 2002 16:59
Favicon

[Fwd: Testsuite interaction: kill does not kill compiled functions]

-----Forwarded Message-----

From: "Billinghurst, David (CRTS)" <David.Billinghurst <at> riotinto.com>
To: amundson <at> fnal.gov
Subject: Testsuite interaction:  kill does not kill compiled functions
Date: 01 Oct 2002 09:26:00 +1000

Jim,

Can you post this to the maxima list.  My attempts are failing.

-----Original Message-----
From: Billinghurst, David (CRTS) 
Sent: Monday, 30 September 2002 5:27 
To: maxima <at> www.ma.utexas.edu
Subject: Testsuite interaction: kill does not kill compiled functions 

I have followed up on some of the testsuite issues.

The first problem occurs because kill doesn't kill a 
compiled function.  If the function is redefined then it
is killed.  I see similar behaviour with gcl/windows and 
clisp/cygwin.

Should kill(f) remove a compiled function f?

(C1) f(x):=x+2;
(D1) 				 f(x) := x + 2
(C2) f(2);
(D2) 				       4
(Continue reading)

Permalink | Reply | 0 comments |

Gmane