Hrvoje Niksic <hniksic(a)arsdigita.com&gt; writes: Yes. Not really. If index ((point) etc.) is not allowed to have bignum representable as integer, XINT_COERCE_FIXNUM is not necessary. That's why I asked in previous post. I don't think people want to do something like (make-string (* 2 most-positive-fixnum) ?a) If people really want to have 2GB buffer, it's possible to implement it but they must accept some slow down. I cannot be sure about performance because obviously I did no benchmark. However, my guess is that slow down will not be severe. Every XINT will need to have one more check to signal better error when argument is bignum. This won't be a big issue since additional check is called only when XINT's argument is not a fixnum. Every XINT in numeric functions will be converted to something similar to XINT_ANY. But my sample implementation doesn't convert everything into bignum. If arguments are all fixnum and the result fits in fixnum range, all operations are performed as fixnum. I think fixnum operations won't slow down much except a few more check for bignum and a few more function call (you won't be able to call just + in C). -- Yoshiki Hayashi

Hrvoje> So you plan to disallow any bignums smaller or equal to Hrvoje> most-positive-fixnum? That never crossed my mind, Hrvoje> probably due to exposure to Python. I don't think he'd necessarily want to _disallow_ them. I may be wrong, but I seem to remember that Common Lisp assumes that bignums will be automatically canonicalized (but that might just be rationals, complex, quaternions, etc). Anyway, it's an intuitive extension of the canonicalization idea. However, I've been thinking about the annoying CCL interface for a while. There is _zero_ reason why the CCL interface is infix; it could just as easily, with some care, be a restricted Lisp dialect. (It wouldn't just be arithmetic expressions because loop control, I/O, and some complex functions are necessary.) But once you have that, you could do (setq result (declare-arithmetic (let ((i 0) (result 0)) (while (< i bound) (setq result (+ i result)) (setq i (1+ i)))))) Of course when interpreted declare-arithmetic would just eval its argument (you could even have JIT compiling, I suppose), but when compiled you could compile to CCL. The Lisp-CCL compiler could generate two kinds of exceptions, one would be errors for code that isn't legal arithmetic, and the other would simply force the compiler to restart with Emacs Lisp byte-code. In that context, it might be useful for declare-arithmetic to take an argument like :domain 'bignum (arbitrary precision arithmetic) or :domain 'fixnum (error on overflow). The current CCL interpreter neither supports bignums nor (IIRC) does bounds checks, but one can dream, right? Hrvoje> lower the fixnum size without visible penalty. (Why would Hrvoje> we want that? Perhaps to reintroduce small conses.) And BASKIN_ROBBINS_CHAR! Hrvoje> Here it would be nice to have compiler support for that, Hrvoje> so that the compiler can generate fixnum-only opcodes Hrvoje> where it can prove that fixnums are used. But that's not Hrvoje> really possible without lexical scoping, so we can forget Hrvoje> it. Way ahead of me, I see. But you could go the declaration route. Then you would only incur overhead on all-fixnum calculations, and that would be linear in the number of arguments. Presumably that would be worthwhile in many important cases. Hrvoje> With a little cleverness, the all-fixnum case might remain Hrvoje> as fast as it is now. I don't see why would have to be clever, since fixnums aren't lrecords and bignums would have to be. You'd have to decide whether you want marker conversions (eg) or bignum recognition to be faster, but that's it. Hrvoje> OK, you've convinced me. Me too. May I provisionally put "experimental bignum support by Yoshiki Hayashi" in the proposal I'm drafting for the next release? That would mean that you'd like to try to have it ready for a September release. It doesn't mean you promise (I know about the time constraints of first year grad students), you can always withdraw the proposal if you decide it's not feasible. And of course the board would decide whether to accept the proposal, I can't promise it would be in. But it looks very good so far. (N.B. "Experimental" refers to "builder must explicitly configure", not my estimate of quality / stability of the code.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Hrvoje> Internally, why not? The user will never see the Hrvoje> difference, and it allows us to retain the simple XINT Hrvoje> interface whenever we're dealing with fixnums. Because it might be more efficient to do an entire calculation in bignum (see below), then canonicalize at the end, rather than do canonicalizations at every point. Hrvoje> The declarations might work in some cases, but the speed Hrvoje> win would be questionable. Declarations win in CL because Hrvoje> once you declare A and B as fixnums, the compiler has the Hrvoje> license compile (+ A B) into a machine integer addition. Hrvoje> XEmacs interpreter is in a very different position, which But CCL is _much_ faster than the Lisp interpreter. Hrvoje> is not made any easier by the fact that due to dynamic Hrvoje> scoping anyone and anything can access the values of the Hrvoje> variables and make XEmacs crash. I don't see how. I'm talking about declaring an entire sexp as an arithmetic expression, and if the compiler detected anything that might have a side-effect on a variable used in the expression, it would refuse to optimize that expression as "pure arithmetic". You would typecheck all variable values on entry, and signal error if they weren't numerical. This could be a big win in, say, image code. If such strong checking is unacceptable, you wouldn't use the declaration. Hrvoje> Well, maybe it's trivial for you. :-) The cleverness I Hrvoje> was referring to would extend the "check that all Hrvoje> arguments are numbers logic": I don't understand your description of the logic. I thought it was something more like for (i = 0; i < nargs; i++) { if (ISA_NUMBER (arg[i]) arg[i] = XINT(arg[i]); else if (ISA_MARKER (arg[i]) arg[i] = COERCE_MARKER_TO_C_INT (arg[i]) /* ... */ else error("Argument %d can't be coerced to number", i); } So I would turn that into for (i = 0; i < nargs; i++) { if (ISA_FIXNUM (arg[i])) ; else if (ISA_BIGNUM (arg[i])) have_bignums = 1; else if (ISA_MARKER (arg[i])) arg[i] = MARKER_TO_LISP_INT (arg[i]) /* ... */ else error("Argument %d can't be coerced to number", i); } Then you do if (have_bignums) for (i = 0; i < nargs; i++) if (ISA_FIXNUM (arg[i])) /* or maybe do XINT (arg[i])? */ arg[i] = FIXNUM_TO_BIGNUM_REP (arg[i]); else arg[i] = BIGNUM_TO_BIGNUM_REP (arg[i]); Hrvoje> I assume the status of "experimentalness" can be revised Hrvoje> if the code proves to be stable and reliable? If you mean change the name to "optional feature" or something like that, sure. If you mean change the default in configure after feature freeze, no. I won't do it without the Board's explicit authorization. People who want the feature can ask for it in configure until the following release. I am shooting for a public release of new features every six months at this point. I'm hoping that if we can get a September release out, people will start to take the process seriously and I can hand over the reins to somebody else for the March 2002 release. I think that's soon enough to certify a feature proposed in May 2001 as "stable and reliable." We're seeing a lot of efficiency complaints about 21.4. It's not enough to be "stable and reliable", you also need to have a reasonable value/performance tradeoff before making a feature default to on. I took shortcuts on some features for 21.4, and I still think it was justified, knowing as little as I did at the time. But in the future I want to be more careful. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Hrvoje> I see. Here it would be nice to have compiler support for that, so Hrvoje> that the compiler can generate fixnum-only opcodes where it can prove Hrvoje> that fixnums are used. Given ELisp's tectonic speed, it's unlikely that bignum arithmetic will matter much. It sure doesn't matter enough for most interpreter based Lisp and Scheme systems bother. Hrvoje> But that's not really possible without lexical scoping, so we Hrvoje> can forget it. Huh? No. These two things don't really have anything to do with each other. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla