On 15 Aug, 21:30, rjf <fate...@gmail.com> wrote:
> I am pleased to learn that deficiencies in gmpy are not inherited by
> Sage, and that
> MPIR, equivalent functionally to GMP is accessible more directly.
>
> It doesn't seem that it should be a point of pride that there are 5000
> lines in Sage that include mpz_ ...
> (e.g. mpz_addmul(a,b,c) computes a=a+b*c), since one of the alleged
> advantages of
> using a higher level language like Python is be that one doesn't need
> to write out these low-level
> constructs, and can use infix arithmetic, for example.
>
> In my lisp code I provide a compiler (really, a macro-expander) that
> allows the programmer to
> use the ordinary arithmetic operations like + and *, and
> declarations, and the system chooses
> the proper mpz_ ... code or other code. Actually, the floating point
> stuff is more useful, from MPFR,
> so I picked an example that is "more complicated"..
>
> Here's a piece from a lisp program which computes the value of
> legendre polynomials,
> in which x, t0, t1, are mpfr numbers, and i is a (single-word)
> unsigned integer.
>
> (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?
How would it cope with the new proposed addadd, subadd and sumdiff
functions of MPIR?
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).
>
> 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.
Does Lisp automatically deal with the case where the (2*i - 1)
overflows? 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.
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?
>
> 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.
Sage has a very powerful collection of "arithmetics". I mean you can
multiply matrices, polynomials, group elements, all sorts of things,
with a * operator.
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?
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. 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?
>
> [the Lisp macro with-temps expands to a sequence of calls to entry
> points in the mpfr library,
> with some storage that is re-used at each invocation of this code
> segment.]
>
> RJF
Bill.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
