From Bernard.Parisse at ujf-grenoble.fr  Thu Oct 19 11:00:35 2000
From: Bernard.Parisse at ujf-grenoble.fr (Parisse Bernard)
Date: Thu, 19 Oct 2000 11:00:35 +0200
Subject: strange behavior of ex constructor from string
Message-ID: <39EEB833.6A720683@fourier.ujf-grenoble.fr>

I'm currently testing the latest version of the Z-factorization code and
found some weierd results that I believe show there is a bug in
the ex constructor from a string.
You can reproduce this bug the following way:
compile the latest
ftp://fourier.ujf-grenoble.fr/pub/hp48/giac.tgz
(make install then make factor)
Try
./factor zimmer7
answer is 0
Looking in my code, it seems that the call
    args.push_back(ex(string(ss2),lst(sym)));
line 480 of polygauss.cc
pushes a 0 instead of the correct expression (i.e. what's in the zimmer7
file)
(you can check this by putting a breakpoint in factor.cc, l.27,
p it->dbgprint() prints 0)
The same call works when applied to zimmer1, zimmer2, zimmer3.
Any ideas?

Bye,
Bernard


From cbauer at student.physik.uni-mainz.de  Tue Oct 24 16:44:08 2000
From: cbauer at student.physik.uni-mainz.de (Christian Bauer)
Date: Tue, 24 Oct 2000 16:44:08 +0200
Subject: strange behavior of ex constructor from string
In-Reply-To: <39EEB833.6A720683@fourier.ujf-grenoble.fr>; from Bernard.Parisse@ujf-grenoble.fr on Thu, Oct 19, 2000 at 11:00:35AM +0200
References: <39EEB833.6A720683@fourier.ujf-grenoble.fr>
Message-ID: <20001024164408.A10151@iphcip1.physik.uni-mainz.de>

Hi!

On Thu, Oct 19, 2000 at 11:00:35AM +0200, Parisse Bernard wrote:
> Looking in my code, it seems that the call
>     args.push_back(ex(string(ss2),lst(sym)));
> line 480 of polygauss.cc
> pushes a 0 instead of the correct expression (i.e. what's in the zimmer7
> file)

That's probably because the zimmer7 file is syntactically incorrect,
containing terms like

 20734047820658568988275936059402711947017728*^286

and

 604703470567171052x^32

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/


From Bernard.Parisse at ujf-grenoble.fr  Tue Oct 24 17:08:09 2000
From: Bernard.Parisse at ujf-grenoble.fr (Bernard Parisse)
Date: Tue, 24 Oct 2000 17:08:09 +0200 (MET DST)
Subject: strange behavior of ex constructor from string
In-Reply-To: <20001024164408.A10151@iphcip1.physik.uni-mainz.de> from Christian
 Bauer at "Oct 24, 2000 04:44:08 pm"
Message-ID: <200010241508.RAA12327@mozart.ujf-grenoble.fr>

> 
> That's probably because the zimmer7 file is syntactically incorrect,
> containing terms like
> 
>  20734047820658568988275936059402711947017728*^286
> 
> and
> 
>  604703470567171052x^32

Sorry! I didn't check for a correct syntax since every time I had something
incorrect, I got Abort. I will look more carefully in the futur...
Thank you very much!

Bernard


From cbauer at student.physik.uni-mainz.de  Tue Oct 24 17:16:55 2000
From: cbauer at student.physik.uni-mainz.de (Christian Bauer)
Date: Tue, 24 Oct 2000 17:16:55 +0200
Subject: strange behavior of ex constructor from string
In-Reply-To: <200010241508.RAA12327@mozart.ujf-grenoble.fr>; from Bernard.Parisse@ujf-grenoble.fr on Tue, Oct 24, 2000 at 05:08:09PM +0200
References: <20001024164408.A10151@iphcip1.physik.uni-mainz.de> <200010241508.RAA12327@mozart.ujf-grenoble.fr>
Message-ID: <20001024171655.A11787@iphcip1.physik.uni-mainz.de>

Hi!

On Tue, Oct 24, 2000 at 05:08:09PM +0200, Bernard Parisse wrote:
> I didn't check for a correct syntax since every time I had something
> incorrect, I got Abort.

The input parser throws an exception when it encounters a syntax error. Printing
that exception might give a clue on what's wrong (OK, not in this case because
the expression is very long and all it says is 'parse error at ^').

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/


From kreckel at thep.physik.uni-mainz.de  Sun Oct 29 15:13:53 2000
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Sun, 29 Oct 2000 15:13:53 +0100 (CET)
Subject: Autoconf
In-Reply-To: <39FC2307.92F918BB@fourier.ujf-grenoble.fr>
Message-ID: <Pine.LNX.3.96.1001029140302.193A-100000@higgs.physik.uni-mainz.de>

Hi Bernard,

I just put this on the devel-list, maybe Christian or Alex have comments
on the topic (or someone else):

>>>>> On Fri, 27 Oct 2000, Parisse Bernard wrote:
>>>>>[ ...talking about converting the expairseq-representation of add and mul
>>>>>to a sparse tensor representation by pulling out all of the numbers... ]
>>>>> I don't think there are efficiency problems there, maybe we loose a
>>>>> small constant factor but that's not where time is critical.
>>>>> What do you think of the idea of adding member functions to provide
>>>>> read-only access to .rest and .coeff? That would keep my code more
>>>>> readable and keep member protection.
>>>>>
>>>> On Fri, 27 Oct 2000, Richard Kreckel wrote:
>>>> Grudgingly so. We might wish to change the internal representation of add
>>>> and mul, although this doesn't seem very likely at the moment.  The .op()
>>>> access method is the preferred one.  I think that it can be done more
>>>> elegantly than what I did (and also more correctly).
>>>>
>>> On Sat, 28 Oct 2000, Parisse Bernard wrote:
>>> I'm afraid that using e.g.
>>> is_exactly_of_type(obj.op(obj.nops()),numeric)
>>> instead of obj.overall_coeff would be as well broken if you change the
>>> internal representation of add.
>>> I don't think that internal representation can be fully hidden
>>> when converting representations to another one. That's not a big
>>> issue as long as you keep all the dependant code well isolated
>>> and documented. And I believe that the most important thing for the
>>> future is code maintenance ease where readability is a key feature.
>>>
>> On Sat, 28 Oct 2000, Richard Kreckel wrote:
>> Not really.  We want to have it this way: The last one (obj.nops()-1 that
>> is) is *supposed* to be the numeric overall coefficient, if it is
>> different from the default coefficient, 0 for add, 1 for mul.  It is just
>> as in Maple, but we don't have a head part, so the counting is different.
>> But the last one returned is always the numeric part.  That's a kind of
>> contract and we are in some other pieces of code really relying on it. I
>> guess I should add checking this in the exam part...
>>
> On Sun, 29 Oct 2000, Parisse Bernard wrote:
> OK, but I'm not a Maple expert. In fact, I want to use C++ because
> there are some aspects of CAS langages that I do not like at all (and
> of course I don't want to use proprietary software anymore) like
> those you mention in your article (e.g. using list of lists to represent
> complex data structures).
> As I said before I find more natural to learn the internal structure
> of symbolic objects than to learn conventions that are not intrinsic.
> At first, it seems a better idea to have such sort of conventions and
> allow internal representation changes, but I don't believe you can
> keep this working. Algorithms, at least if you need efficient ones
> (and that's always the case for CAS algorithms), depends too much of
> the data structure. I've read in Stroustrup's book a lot of  
> recommendations about good programming that have always exceptions when
> you deal with maths.

This would still leave us with the question how to access expairseq::seq.coeff
and expairseq::overall_coeff from outside.  Is the foo.op(foo.nops()-1)
approach something one should live with or should we accept that others
expect the representation as it is and add inspector methods?  I would really
appreciate some input on this.

[ ...talking about the merits of add and mul's representation... ]
> I did not know about such a representation before reading GiNaC doc
> and source. I have experience with the HP calculator system that
> represent symbolic objects as programs to be evaluated using a
> stack (for exemple '1+x' as SYMBOL 1 identifier_X + ;).
> This kind of representation is fairly easy to evaluate but more
> difficult to split into subtrees because embedded algebraics were not
> allowed. And it does accept the + as a binary operator only. Which
> makes rather difficult to code some operations, like a+d+b+c -> a+b+c+d.
> Moreover there are a lot of operations allowed inside symbolics: /, INV,
> SQRT, SQ, ... so that early simplifications like 1/INV(x) -> x are
> much harder to code than using your representation.
> Hence I adopted your representation because it solves some of these 
> issues. I don't think you will find the need to change internal
> representation of these fundemental objects.
> The main problem I see currently is that you can not bind objects
> to a symbol (I would like to do that and I would like to be able
> to make assumptions on symbols as well). And I have to get a better
> understanding of your coding of operations like SIN, ...
> There is another problem I see with using CLN to compute e.g. 
> transcendental functions if special values are found, e.g. ATAN(1),
> because symbolic values belong to GiNaC, not to CLN (or maybe I've
> missed something).

Ah, yes.  We cannot really do much here.  Automatically, all that is
allowed is a simple evaluation if one thinks the resulting expression
is "simpler".  (In the case of atan(1) not doing so is clearly a bug and
I'll fix it right now.)  Following common jargon (eg R.J. Fateman in his
article "Symbolic Mathematics System Evaluators" in Michael Westers "CAS 
- A practical guide") we can call this process of what is done 
automatically the "evaluator".  We thought a useful convention is that
automatically only fast transformations are done: on container-objects
consisting of n things, this includes everything that goes like n*log(n)
in complexity.  Of course CLN does not have such a thing like Pi/4 because
Pi doesn't fit into one of the algebraic domains there.  So GiNaC simply 
tries to trap those arguments and give you a closed result in terms of
well-known constants, including non-nested surds.

Regards
    -richy.
-- 
Richard Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>