Re: 22- polgalois()

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

On Wed, 12 Jun 2002, Igor Schein wrote:
[...]
>    new_galois_format = 0 (off)
>   ***   bug in GP (Segmentation Fault), please report

That's bad. I'll look into it.

> I see that with debug 64bit binaries on both Solaris and HPUX.
>
> BTW, all other boolean variables don't contain underscore.  Purily
> from aesthetical viewpoint, is there a reason to introduce one with
> them?

1) it's more readable.

2) it gets the same name as the library variable [ for which underscores
are the common practice since I don't like the NewGaloisFormat alternative ]

3) I thought there might be a group of new backward compatibility toggles
with much finer control than 'compatible' would allow. There are quite a
large number of independent things I'm not at all happy with, which I would
like to change, but which would definitely break compatibility.

With underscores, they would stand out more. They also would share a common
prefix since I want them as expressive as possible, and we want readline (or
our favourite text editor) to help.

If they get too numerous it might be better to implement them as bit vectors,
so that they would show like, e.g

  new = galois_format, polred_flags, semi_colon_separator, no_string_concat,
        fun_needs_paren, bit_operators

You'd be expected to set them once and for all in a gprc, or when designing
a script tuned for a particular environment.

Some explanations:

* polred_flags: look at the current polred/polredabs, flags have the same
meaning but different values. The bug was introduced 4 years ago, and now
it's documented behaviour... [ That's why Ilya's mneumonic patch is so
interesting. Had no time to include it yet, also I wanted to change slightly
the syntax. And let the function parse the mneumonic string, not the
analyzer, to be gp2c-friendly ]

* semi_colon_separator: would remove the possibility to use ':' to separate
instructions. It is absurd to allow two different characters to separate
expressions. Besides, gp2c has picked them to denote (optional) types to
generate more efficient code. So gp could support scripts written for gp2c by
discarding :anystring as a comment.

* no_string_concat: to disable automatic concatenation within strings, which
breaks gp2c, and is not that useful  [ requires forbidding Str(,1) and
introducing a new routine to expand environment variables ]

* fun_needs_paren: to remove the fact that a function without mandatory
elements can be written without parentheses [ fun instead of fun() ], which
is ugly, and prevents us from using the same identifiers as variables and
functions at the same time.
(19:58) gp > f=1
%1 = 1
(20:11) gp > f(x)=x
  ***   unused characters: f(x)=x
                            ^----
* bit_operators: currently & and &&, | and || have the same meaning, hence
we can't have the standard bit operators ( well, ^ would be a problem )

There are certainly a few more, which don't come to mind right now. Add your
pet peeves here...

    Karim.

P.S: It's all quite cumbersome ( and I'd rather be designing mathematical
algorithms, than bothering about interfaces which I myself don't need ), but
I don't see any other way without disgruntling a large number of people ( I
know. I hate it when other groups change their interfaces and suddenly I need
to cope with lots of weird problems after an inconspicuous upgrade, when I
was perfectly tuned to the environment minutes before )

-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas
--
PARI/GP Home Page: http://www.parigp-home.de/