Re: [PATCH 2.0.18] \x upgraded

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

>>> [Ilya]
>>> But the main difference is that all the special flags are put near the
>>> memory words which contain the pertinent info, and that *all* the info
>>> contained in the special words is put out (as far as I understand).
>> [Me]
>> I'm not sure I like this: too much output, a lot of it being "trivial",
>> [at least if you need to use the function in the first place...]
>> 
>> I only use \x (or rather the underlying library function) as a debugging help
>> for pretty tough bugs, like gerepile problems affecting huge objects.
> [Ilya]
> I do not think that optimizing things for you is a viable target.  ;-)

Sure. That's why I suggested reducing even further the technical data
(addresses, explicit codewords, etc.) so as to get the useful internal
information without clobbering the screen [ After your patch, look at a
smallish matrix with coefficients in a finite field... And this is exactly
the kind of situation where you're interested in knowing whether all moduli
are in the heap, for instance. ]

Anyway, I don't strongly object since this low level function is hardly
ever needed: it's more efficient to wipe out the supposedly free part of
the stack, then inspect recursively all components, trapping SEGV and
SIGBUS along the way to quickly spot the problematic components [ such a
function is included in my private version, and will probably make its way
into the general distribution ].

Also, I got a very nice suggestion from Gerhard Niklasch: make the output
depend on DEBUGLEVEL (i.e \g settings), not outputting any hexadecimal
word by default (\g0), adding the addresses and the codewords (\g1
say), and finally the non-recursive data proper (e.g. \g2). This way,
everybody will be happy.

> Right now there is a very high threshold on modifying PARI, given that
> the vaste majority of PARI is written in C-like assembler.

This is not quite true. The code is generally lacking comments (that's an
understatement), but this is not due to minute word-by-word manipulations.
I make a distinction between 

1) basic functions that are ubiquitous and should be as fast as possible
(includes multiprecision kernel, all basic arithmetic, and part of linear
algebra), whatever the cost in code ugliness. Granted, these are hard to
modify, but are mostly the kind of functions people are not interested in
trying to improve [although many would like to see them improved :-)]

2) higher level ones, where implementation details are relatively
straightforward. Most of the number field stuff belong to the second
category [ and is generally not optimized at all ].

> Any step going in the direction of simplifying word-by-word
> manipulations is a positive thing.

Certainly, though I still believe that such manipulations are seldom
needed. In that,line of thought, it would be nice for instance to

1) remove dependences on type ordering [ occurs relatively infrequently ]

2) remove direct accesses to data words [ ubiquitous for
vector/polynomials, where it's quite logical but still dangerous, and
rare otherwise ].

3) make sure nothing depends on the way the stack is oriented, or the way
the objects are stored internally [ this is much harder, but I once had a
patch reversing the stack direction which touched relatively few places; so
it's not that hardcoded. Also, PARI has been adapted to use gmp kernel
(which has objects growing in the other direction) ... ]

Unfortunately, this involves a lot of work for little improvement on the
user's side. It would be worth it if more PARI users were interested in
developping library functions. So, it would be interesting to know if such
persons exist and what currently prevents them from contributing.

[ Unfortunately, I would guess the answer is: general lack of C programming
background, and no specific gripes. ]

    Karim.
__
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://www.parigp-home.de/