Re: Bignum support

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."