Better handle 0 and 1 in types

[Ralf Hemmecke]

Hi Waldek,

I just saw the recent commit about 0 and 1 in types.
Actually, I have not yet commented to your patch, because I first wanted
to look up how difficult/reasonable it would be to remove (Zero) and
(One) altogether.

You have probably improved type matching by your hack, which is good and
thanks for that, but what I really wonder is: Why is there a need for
(Zero) and (One) when we coudld just have 0 and 1?

Is the reason that (Zero) and (One) count as identifiers and 0 and 1 as
numbers? AFAIU, in Aldor 0 and 1 count as special identifiers.
Do you think it would be too naive to just replace (Zero) and (One) in
all of FriCAS by just 0 and 1?

Ralf

[Waldek Hebisch]

Short answer is that I do not know. I think that keeping just 0
and 1 can work, but that would require going trough all compiler
code looking for special cases and adding extra code where needed.
Alternatively, do the change and run a lot of tests to find
places that break down.

At low level 'Zero' and 'One' are Lisp symbols, so evaluating
them works like all other symbols, in particular Boot '["Zero"]'
gives function call which produces correct value. Plain 0
would need special handling. That is probably why original
authors introduced this scheme.

Let me add that I plan rather large compiler restructuring
and I hope that problems like this will then go away. But
I do not want to wait long for fix, people regularly meet
this problem.
--
Waldek Hebisch

[Ralf Hemmecke]

> Let me add that I plan rather large compiler restructuring
> and I hope that problems like this will then go away. But
> I do not want to wait long for fix, people regularly meet
> this problem.

All fine for me.

BTW, when do you plan the next release, I think I should then work a bit
on fricas.github.io till then. I wanted to add a few more example pages.
Something I postpone at the moment, because other stuff keeps me busy.

Ralf

[Waldek Hebisch]

On Mon, Mar 01, 2021 at 11:10:14PM +0100, Ralf Hemmecke wrote:
>
> BTW, when do you plan the next release, I think I should then work a bit
> on fricas.github.io till then. I wanted to add a few more example pages.
> Something I postpone at the moment, because other stuff keeps me busy.

I would like to do new release as soon as possible. But we have
quite a few open bugs, so I would like to fix at least some
of them. ATM it is hard to say how much time this will take.

--
Waldek Hebisch

[Qian Yun]

Hi,

Where is this list of open bugs? Maybe I can provide some help.

- Qian

[Waldek Hebisch]

On Tue, Mar 02, 2021 at 11:41:03AM +0800, Qian Yun wrote:
> Hi,
>
> Where is this list of open bugs? Maybe I can provide some help.
>

I have notes of things that I tried/worked on, most notes
is in Polish, but some examples should be self-explanatory.
If you want to see it I have put it at:

http://www.math.uni.wroc.pl/~hebisch/issues.txt

Largest part came from our mailing list, part from known
testsutes (Rubi and random integrals). Note: in the file
some things are just slow and some are just possible
examples to put in documentation.

Note: my list is fairly incomplete, there are reports in
the mailing list with no entry on the list.

Most nasty thing are integration failures due to messed
kernel order. We have also interpreter problems (like
one recently reported by Ralf and Johannes).

--
Waldek Hebisch

[Waldek Hebisch]

On Tue, Mar 02, 2021 at 11:41:03AM +0800, Qian Yun wrote:

> Hi,
>
> Where is this list of open bugs? Maybe I can provide some help.

For the record:

f := 3+sinh((atanh(3)-(sin(atan(4+atan(x))-3)/x))/log(4)+(x+4))+3
integrate(D(f, x), x)

produces almost 5000 lines of output.

f := (cos(4)+tan(1+x))*x*sin(4/((((x/atan(cosh(x)))/x)/3)/5))
integrate(D(f, x), x)

produces more than 32000 lines.

I am not sure if result is correct, but even if correct we
should do something to make this smaller.

--
Waldek Hebisch