headers
Henry Baker | 1 Jul 2012 01:34
Picon

Re: ratepsilon

1, unless ratepsilon is very, very small.

We probably need a Gaussian form of the "rationalize"" function.

I'll fiddle around with this in Lisp.

At 03:53 PM 6/30/2012, Raymond Toy wrote:
>On 6/29/12 9:50 AM, Henry Baker wrote:
>> I want to "rationalize" a complex number, but I don't want to rationalize the real & imaginary parts
separately, because this won't convert 1.0+%i*1.0e-10 into 1.
>
>What do you want 1.0+%i*1e-10 to rationalize to?
>
>Ray
Permalink | Reply | 0 comments |
headers
Henry Baker | 1 Jul 2012 21:51
Picon

Re: ratepsilon

Here's some "toy" code to play with.

(complex-rationalize (complex 1 1e-10) 1e-19) returns 1.
(complex-rationalize (complex 1 1e-10) 1e-20) returns #c(1 1e-10).

So setting ratepsilon to 1e-20 with this sort of rationalize function will do what I want.

;;; Implement Common Lisp/Maxima "rationalize" function for complex numbers.
;;; Many functions taken from "Complex Gaussian Integers for 'Gaussian Graphics' "
;;; http://home.pipeline.com/~hbaker1/Gaussian.html

(defun gaussian-integerp (z)
  ;;; Inexplicably left out of Common Lisp.
  (assert (numberp z))
  (and (integerp (realpart z)) (integerp (imagpart z))))

(defun norm (z)
  ;;; Inexplicably left out of Common Lisp.
  ;;; norm is multiplicative, i.e., norm(a*b)=norm(a)*norm(b).
  ;;; Almost as useful as abs, but less expensive to compute.
  (realpart (* z (conjugate z))))

(defun complex-floor (z &optional (d 1))
  ;;; Inexplicably left out of Common Lisp.
  ;;; This can be optimized by utilizing the "floor" remainders directly.
  (let* ((dc (conjugate d)) (dn (* d dc)) (zdc (* z dc))
	 (q (complex (floor (realpart zdc) dn) (floor (imagpart zdc) dn)))
	 (r (- z (* d q))))
    (values q r)))
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kalyanramu Vemishetty | 2 Jul 2012 04:30
Picon

Minimax Approximation

Hi all,


Maple has command "minimax" which gives minimax rational approximation.

e.g., minimax(e^x, x=0..1,5).

Is there a similar command or series of steps in maxima to get the same information?

Thanks,
kalyan
_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Permalink | Reply | 4 comments |
headers
Jérome Laurens | 2 Jul 2012 09:11
Picon
Favicon

Re: dynamically created symbol


Le 29 juin 2012 à 19:50, Stavros Macrakis a écrit :

Not sure I understand why you need multiple context names for this. Can't you use the same context name if you kill it when you're done?

When the contexts can't be shared, we must be sure that there are no name conflicts.
For example, if functionA calls functionB, and they share the same context,
then functionB cannot kill the context when called from functionA,
but can kill it when called from the main program flow.
To simplify the code, each function has its own context and kill it when done.
When functionA calls itself, we see that the context name must differ at each call.

Jérôme

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Permalink | Reply | 8 comments |
headers
Stavros Macrakis | 2 Jul 2012 15:53
Picon
Favicon
Gravatar

Re: dynamically created symbol

Seems to me that this is a flaw in the context system -- it should not be necessary to go to such trouble to make recursive contexts work correctly.

               -s

On Mon, Jul 2, 2012 at 3:11 AM, Jérome Laurens <jerome.laurens <at> u-bourgogne.fr> wrote:

Le 29 juin 2012 à 19:50, Stavros Macrakis a écrit :

Not sure I understand why you need multiple context names for this. Can't you use the same context name if you kill it when you're done?

When the contexts can't be shared, we must be sure that there are no name conflicts.
For example, if functionA calls functionB, and they share the same context,
then functionB cannot kill the context when called from functionA,
but can kill it when called from the main program flow.
To simplify the code, each function has its own context and kill it when done.
When functionA calls itself, we see that the context name must differ at each call.

Jérôme


_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima


_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Permalink | Reply | 7 comments |
headers
Barton Willis | 2 Jul 2012 16:06
Favicon

Re: dynamically created symbol

 Stavros Macrakis wrote:

> Seems to me that this is a flaw in the context system -- it should not be necessary to go to such trouble to make
recursive contexts work correctly.

Maxima has both newcontext and supcontext--I would think that using supcontext should allow recursive
contexts to work without a great deal of fuss?
Also, the user documentation  doesn't mention this, but I think newcontext and supcontext do not evaluate
their arguments---likely you need something
like

block([ctx : gensym("ctx")],  
   ctx : apply('subcontext, [ctx]),
   ...);

--Barton
Permalink | Reply | 6 comments |
headers
Stavros Macrakis | 2 Jul 2012 16:18
Picon
Favicon
Gravatar

Re: dynamically created symbol

newcontext/supcontext do evaluate their arguments -- try e.g. newcontext(gensym("ctx")) -- but the whole thing is silly.

Sometimes you need to name contexts, but often anonymous contexts are fine.  It looks like in most cases, all you want is something like with_local_context( ... ).  Of course, this can be written as a Maxima macro (::=) using supcontext, but if the most common use case is anonymous contexts, Maxima should support them directly.

Imagine having to name variable contexts with unique names -- including recursive ones!

              -s

On Mon, Jul 2, 2012 at 10:06 AM, Barton Willis <willisb <at> unk.edu> wrote:
 Stavros Macrakis wrote:

> Seems to me that this is a flaw in the context system -- it should not be necessary to go to such trouble to make recursive contexts work correctly.

Maxima has both newcontext and supcontext--I would think that using supcontext should allow recursive contexts to work without a great deal of fuss?
Also, the user documentation  doesn't mention this, but I think newcontext and supcontext do not evaluate their arguments---likely you need something
like


block([ctx : gensym("ctx")],
   ctx : apply('subcontext, [ctx]),
   ...);

--Barton










_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Permalink | Reply | 5 comments |
headers
Richard Fateman | 2 Jul 2012 16:33
Picon
Favicon

Re: dynamically created symbol

Looking back on this, I think that user-defined contexts are 
unnecessary, or at least should be if
definite integration does the right thing.

On 6/29/2012 12:21 AM, Jérome Laurens wrote:

...

  I have integrals like this

\int_{x=...}^{...} \int_{t=f(x)}^{...} foo(t,x) dt dx

But integrate tells me that it needs to know that f(x) is real
so I assume that x has some properties to ensure that f(x) is real
.......

We should agree that
integrate(f(t,x), t, a ,b)
  has the same meaning as

integrate(f(gensym1,x), gensym1, a, b).

If defint does its job correctly, it should do this:

generate a context in which   a<= gensym1 <=b
and then run some algorithm.

I suspect Jerome's problem disappears if the name
of the variable of integration is not re-used.  This
can be easily remedied by using subst.  Probably a
finite list of variable names can be used. If it is
confirmed that a particular name is no longer in use, it
can be re-used.  Or perhaps it is obvious from some other
source that the integration will never be nested more than
100,  then 100 names can be used.

RJF
Permalink | Reply | 3 comments |
headers
Barton Willis | 2 Jul 2012 18:59
Favicon

Re: dynamically created symbol


Richard Fateman wrote
> We should agree that
> integrate(f(t,x), t, a ,b)
>  has the same meaning as

> integrate(f(gensym1,x), gensym1, a, b).

If integration calls asksign on the integration variable, the user will be quizzed on the sign of a gensym.
And that's not nice. I know of no easy solution to this.  Maybe this could be
fixed with some special alias mechanism for asksign.  Actually  asksign should never be called on the 
integration variable of a definite integral--questions, if any, should be about
integrand parameters or limits of integration. 

--Barton
Permalink | Reply | 2 comments |
headers
Henry Baker | 2 Jul 2012 20:54
Picon

Re: ratepsilon

Over the weekend, I was playing with my toy version of complex-rationalize.

The problem in programming this function isn't the complex numbers themselves,
but what the "stopping criterion" for the continued fraction should be.

In particular, I notice that the Lisp (& probably the Maxima) version of
"rationalize" doesn't do a very good job of stopping.  For example,
the CF expansion of sqrt(2)=[1,2,2,2,2,2,...], so if the CF expansion
starts spitting out non-2's, then Houston, we have a Problem.  The
Common Lisp implementations I have (GCL, SBCL) both seem to go too far.

According to the Common Lisp manual, "rationalize" may return any rational
number for which the floating-point number is the best available approximation
of its format; in doing this it attempts to keep both numerator an denominator
small.

The Common Lisp manual further goes on to stipulate that

(float (rationalize x) x) == x

So, one might conclude that the problem isn't rationalize itself, but the
implementation of sqrt(2).

Nevertheless, I think that "rationalize" should have a second argument
to indicate the precision of the result -- e.g., |x-x'|/|x|<epsilon,
where x is the number being rationalized, and x' is the rational
approximation.

But even implementing this stopping criterion is fraught with problems.

It is possible to implement a recursive Euclidean algorithm which
is _tail-recursive_, i.e., it builds the product of 2x2 matrices
while recursing down, rather than while returning back up (this
works due to the associativity of matrix multiplication).  When
the stopping criterion is reached, the matrix (and hence the
rational approximation) has already been built and merely needs
to be returned.

But even when this is done, the programming task is hampered by
the fact that Common Lisp rationals won't allow "1/0" (one/zero). 
This is a pity, because the 1) IEEE floating point numbers already
allow such an unsigned infinity; and 2) the most perspicuous code
allows rationals of the form "1/0" to exist, because error'ing
out forces too many, and too early, tests to avoid them.
Permalink | Reply | 1 comment |

Gmane