On Aug 16, 3:30 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
..snip...
>
> > {RJF] (mpfr::with-temps (/(- (* (- (* 2 i)1) x t1) (* (- i 1) t0)) i)))
>
> That's a very interesting example. Are you saying that Lisp
> automatically divines which MPFR functions to assign to those
> operators?
no, Lisp doesn't do that automatically. The macro program I wrote,
with-temps, in the mpfr package
does that (uh, automatically?).
It assumes that the manifest constants like 1, 2, are not mpfr objects
and so compiles
in conversions. It assumes that the variables represent mpfr
variables.
>
> How would it cope with the new proposed addadd, subadd and sumdiff
> functions of MPIR?
I don't know what those functions do, but guessing that mpir_addadd
(target,a,b,c)
does target:=a+b+c,
I could change the with-temps macro to look for (+ a b c ...) and use
addadd to reduce the problem,
I suppose.
>
> I'm also curious as to why the need for temporaries in that macro. You
> can evaluate that expression with a mul, mul_ui, submul_ui and div_ui
> (or perhaps MPFR doesn't provide all those).
As I recall MPFR is all "state based" not "functional" in style (in
terms of its interface),
and I think GMP and therefore MPIR are similar.
That is, you cannot take
a:=b+c*d and convert (or compile it) into
set(a, plus(b,times(c,d))).
You have to do this:
allocate temp t1 (sometime, perhaps much earlier...)
times(t1,c,d) // t1:=c*d
plus(a,t1,b) // a := t1+b
there is a combined addmul, but you get the idea, I think. You need
some temps.
This kind of setup is equivalent to register allocation for compiling,
but you
get to allocate as many temp registers as you want, since they don't
correspond
to hardware registers anyway.
>
>
>
> > a more conventional version of this might be the "infix" version that
> > I thought
> > python / Sage programmers would use.
>
> > ((2*i-1)*x*t1) - (i-1)*t0))/i
>
> Hmm, my knowledge of python is pretty scant, but that's what I'd type.
OK, so why does Sage have 5000 lines with mpz_.... ?
If I wrote a whole suite of programs to use mpz_ or mpfr_ or
interval_ or .... programs
I would hardly ever use those programs explicitly. I would use use
ordinary operations
like +, *, etc. and have them magically macro-expanded to calls to
those library functions.
> Does Lisp automatically deal with the case where the (2*i - 1)
> overflows?
there are two places for overflow, 2*i is the first one.
mpfr_mul_ui(target1,i,2) would not overflow, since the target is a
bigfloat. [oh, by the way, I think there
is also a 4th argument which is the rounding mode, usually
*nearest*],.
The next place is
mpfr_sub_ui(target2,target1,1).
That won't overflow either.
The chance that you are interested in evaluating a Legendre polynomial
of degree 2^32 or so is pretty remote, I think.
But this particular expression would be OK.
Of course Sage has to deal with that. But I am not seeing
> any reason why you couldn't code up a macro, similar to the one your
> Lisp gives you which allows evaluation of expressions such as these in
> an optimal manner.
I agree with you entirely, which is why I asked about the 5000 lines
with mpz.
One possible answer is, "#...@#$%$, Python doesn't have macros."
>
> Does Lisp also automatically do expression simplification for you so
> that if you typed i*(x+1) - i*x that it would just evaluate i, not all
> the rest of the gunk which cancels?
Such an optimization would certainly not be automatic. Maxima might do
that.
assuming that x and i are exact quantities.
In general, the answer is not, in fact, i.
Consider if x is a floating point number 1e30 or so. then x+1 is
equal to x.
Then the expression is not i, but 0.
>
>
>
> > [RJF] But if I understand you, the Sage programmer writing directly in
> > Python has a much worse option,
> > involving something like the 7 mpfr_add, mpfr_mul, ... functions
> > calls,
> > interspersed with establishing some temporaries for intermediate
> > results.
> > Maybe some of the 5,000 lines are really a failure of python to
> > provide a convenient
> > level upon which to write code that does some "other" kind of
> > arithmetic?
>
> That's pretty waffly. What do you mean by "other" kind of arithmetic.
By "other" I mean arithmetic that is different from what is already
built in.
> Sage has a very powerful collection of "arithmetics". I mean you can
> multiply matrices, polynomials, group elements, all sorts of things,
> with a * operator.
OK, how hard is it to add another kind of arithmetic? (say, for
argument's sake
complex numbers are not built in. How hard would it be to add them?
Would you have
to write complex_add(a,b), complex_mul(c,d) etc etc?? I hope not.
But then why would you have to write mpz_..() all over the place?
>
> The original discussion was about in_place operators, which Sage does
> allow. The example William gave was:
>
> sage: n = 15
> sage: n._iadd_(5)
> 20
> sage: n
> 20
>
> I don't see any lines of mpfr_add's there, do you?
No, Sage might have in_place operators, and MPIR might have in_place
operators, but that
doesn't mean that Sage can use the in_place operators in MPIR with the
above syntax.
That might be another reason for 5000 mpz_ lines.
>
> As I said, I am very surprised to learn Lisp allows you to do such
> things without any mpfr_add's and mpfr_mul's, if that is what you
> intended.
Not only does Lisp allow it (if one has the appropriate macro code),
a sample package has been posted on my web page for a few years
along with papers describing it.
> Otherwise I don't have a clue what you are talking about.
> What "convenient level" does Lisp provide that python does not, and
> what ""other" kind or arithmetic" are you referring to?
I experimented with other kinds of generic arithmetic
supported in the same way, including, as I recall, exact rationals
with affine or projective
infinities, real intervals, complex numbers using (r, theta) notation,
polynomials in one
or more variables, quad-double floats, a kind of taylor-series
approximation to functions
that allows for automatic differentiation, etc. Programs like newton
iteration or
gaussian quadrature can be run in any of several different packages
without textual change,
with the macro expansion taking care of the details.
If this kind of thing is not possible with Python, that is, in my
view, unfortunate.
There are several papers with explanations, but perhaps the simplest
is
related to setup for QD (quad-double) arithmetic... see
http://www.cs.berkeley.edu/~fateman/papers/qd.pdf
which mentions MPFR towards the end.
http://www.cs.berkeley.edu/~fateman/papers/qd.pdf
there's a paper about automatic differentiation with AD in the title,
and one about quadrature
http://www.cs.berkeley.edu/~fateman/papers/quad.pdf
RJF
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
