weird behaviour

[Ralf Hemmecke]

I must be doing something wrong, but I do not see what.

Attached you can find a minimal example that does not compile
if line (*1) is uncommented. The compiler has no problem to compile
the cases (*2) and (3).

I thought that the Join with two categories might be a problem, but no
such things appear in the FriCAS algebra sources, for example, in rec.spad.

Ralf

%%% (144) -> )co ../foobug.spad
Compiling FriCAS source code from file
/home/hemmecke/backup/git/qeta/tmp/../foobug.spad using old
system compiler.
Q1PI abbreviates package QEtaOneOverPi
------------------------------------------------------------------------
initializing NRLIB Q1PI for QEtaOneOverPi
compiling into NRLIB Q1PI

>> System error:
formatInfo

[Waldek Hebisch]

On Tue, Apr 30, 2024 at 04:12:59PM +0200, Ralf Hemmecke wrote:
> I must be doing something wrong, but I do not see what.
>
> Attached you can find a minimal example that does not compile
> if line (*1) is uncommented. The compiler has no problem to compile
> the cases (*2) and (3).
>
> I thought that the Join with two categories might be a problem, but no such
> things appear in the FriCAS algebra sources, for example, in rec.spad.

Thanks for the testcase. There was missing transformation, before
main compile in effect your program was transformed into a wrong
form (not handled by the rest of compiler). The following worked:

)abbrev package Q1PI QEtaOneOverPi
QEtaOneOverPi(C): Exports == Implementation where
C: IntegralDomain
NN ==> NonNegativeInteger
Exports ==> with
if C has OrderedRing and C has Field then -- OK
-- if C has Join(OrderedRing,Field) then -- mistransformed
kleinJInterval: (NN, C, C, C) -> Segment C
Implementation ==> add
foo(): Integer == 1

Early transformation was supposed to transform your Join into
'and' above. However, the 'and' was supposed to be transformed
in turn into:

)abbrev package Q1PI QEtaOneOverPi
QEtaOneOverPi(C): Exports == Implementation where
C: IntegralDomain
NN ==> NonNegativeInteger
Exports ==> with
if C has OrderedRing then
if C has Field then -- OK
kleinJInterval: (NN, C, C, C) -> Segment C
Implementation ==> add
foo(): Integer == 1

and this transformation happended when 'and' was explicit in the
source, but did not happen with generated 'and'. Fixed now.

BTW: Those transformations are applicable only to 'Join' within 'has'.
Existing 'Join'-s withing 'has' in the algebra where inside 'and', which
masked the problem (needed transformation happended as part of
processing of 'and' and 'if').

--
Waldek Hebisch

[Ralf Hemmecke]

> Thanks for the testcase. There was missing transformation, before
> main compile in effect your program was transformed into a wrong form
> (not handled by the rest of compiler). The following worked:
>

> if C has OrderedRing and C has Field then -- OK

> Early transformation was supposed to transform your Join into 'and'
> above. However, the 'and' was supposed to be transformed in turn
> into:

> if C has OrderedRing then if C has Field then -- OK

> and this transformation happended when 'and' was explicit in the
> source, but did not happen with generated 'and'. Fixed now

Than you for the fix. Will recompile soon.

Just an addon question. Are you saying that

if C has Join(A, B)

and

if C has A and C has B

always end up internally as

if C has A then if C has B then ...

? Sounds reasonable, but just for curiousity.

The problem actually occured, because I was looking for "OrderedField",
could not find it and so replaced it with a Join(OrderedRing, Field).

It's not totally important, but perhaps it would also make sense to
introduce "OrderedField" even though that would be a rather trivial addon.


Ralf

[Waldek Hebisch]

On Wed, May 01, 2024 at 08:22:41AM +0200, Ralf Hemmecke wrote:
> > Thanks for the testcase. There was missing transformation, before main
> > compile in effect your program was transformed into a wrong form
> > (not handled by the rest of compiler). The following worked:
> >
> > if C has OrderedRing and C has Field then -- OK
>
> > Early transformation was supposed to transform your Join into 'and'
> > above. However, the 'and' was supposed to be transformed in turn
> > into:
>
> > if C has OrderedRing then if C has Field then -- OK
>
> > and this transformation happended when 'and' was explicit in the source,
> > but did not happen with generated 'and'. Fixed now
> Than you for the fix. Will recompile soon.
>
> Just an addon question. Are you saying that
>
> if C has Join(A, B)
>
> and
>
> if C has A and C has B
>
> always end up internally as
>
> if C has A then if C has B then ...
>
> ? Sounds reasonable, but just for curiousity.

Yes. 'if' needs special handling, after ' if C has A then ...'
Spad compiler "knows" that C satisfies more conditions than
implied by original declaration. Transformations above simplify
handling of 'if'.

> The problem actually occured, because I was looking for "OrderedField",
> could not find it and so replaced it with a Join(OrderedRing, Field).
>
> It's not totally important, but perhaps it would also make sense to
> introduce "OrderedField" even though that would be a rather trivial addon.

Note that _using_ OrderedField would have nontrivial cost. Namely,
Spad rules say that something has category "by assertion" and _only_
by assertion. So domain which satisfies 'Join(OrderedRing, Field)'
would not satisfy 'OrderedField'. To put this differently, from
point of view of Spad compiler after definition like

OrderedField() : Category == Joint(OrderedIntegralDomain, Field)

'OrderedField' potentially says more than the Join. In fact,
'OrderedRing' not only says that there is order on the ring,
but also asserts that multiplication is compatible with order
(definition in algebra also adds operations, but even without
extra operations 'OrderedRing' means more than Join).

So to make 'OrderedField' useful we would have to annotate algebra
with several declarations like

if C has OrderedRing and C has Field then OrderedField

BTW: For domain we can write things like

SortedExponentVector == U32Vector

which basically says that 'SortedExponentVector' is an alias for
'U32Vector'. BUT ATM this is not supported for categories.
You can write:

OrderedField ==> Joint(OrderedIntegralDomain, Field)

but this is local to a file.

--
Waldek Hebisch

[Ralf Hemmecke]

On 5/1/24 14:33, Waldek Hebisch wrote:
> OrderedField() : Category == Joint(OrderedIntegralDomain, Field)
>
> 'OrderedField' potentially says more than the Join.

Clear.

> So to make 'OrderedField' useful we would have to annotate algebra
> with several declarations like
>
> if C has OrderedRing and C has Field then OrderedField

Well, I could understand a line like

if % has OrderedRing and % has Field then OrderedField

But I would bet, in the declaration of a domain the programmer often
already knows whether or not % should export OrderedField.

If you really mean C and C would be a parameter of a domain/category,
then I agree with you, but actually also there if the parameter C
exports both OrderedRing and Field then why wouldn't it also export
OrderedField? Yes, there maybe cases where this is really so, but
shouldń't such cases be exceptions and rather maybe point to a not
perfect definition of the respective exports of C?

> BTW: For domain we can write things like
>
> SortedExponentVector == U32Vector
>
> which basically says that 'SortedExponentVector' is an alias for
> 'U32Vector'. BUT ATM this is not supported for categories. You can
> write:

I actually wonder where this might be useful.

Ralf

[Waldek Hebisch]

On Wed, May 01, 2024 at 02:47:45PM +0200, Ralf Hemmecke wrote:
>
>
> On 5/1/24 14:33, Waldek Hebisch wrote:
> > OrderedField() : Category == Joint(OrderedIntegralDomain, Field)
> >
> > 'OrderedField' potentially says more than the Join.
>
> Clear.
>
> > So to make 'OrderedField' useful we would have to annotate algebra with
> > several declarations like
> >
> > if C has OrderedRing and C has Field then OrderedField
>
> Well, I could understand a line like
>
> if % has OrderedRing and % has Field then OrderedField
>
> But I would bet, in the declaration of a domain the programmer often already
> knows whether or not % should export OrderedField.
>
> If you really mean C and C would be a parameter of a domain/category,
> then I agree with you, but actually also there if the parameter C exports
> both OrderedRing and Field then why wouldn't it also export OrderedField?
> Yes, there maybe cases where this is really so, but shouldń't such cases be
> exceptions and rather maybe point to a not perfect definition of the
> respective exports of C?

If you have a concrete domain in mind, then adding OrderedField
alone can be sufficient. But in general case we have parameters
and behaviour depends on parameters. More, thanks to inheritance
we can get interesting behaviour as composition of simpler things
OrderedRing and Field can be propagated and acted on separately.

AFAICS mathematically ordered field is exactly ordered ring
which is also a field.

Of course, ATM we only have a handful of domains which are ordered
rings, so in this specific case one or the other way is not a big
deal. But I would prefer to keep consistent style in the whole
algebra. And in general using explicit Join currently works
better.

> > BTW: For domain we can write things like
> >
> > SortedExponentVector == U32Vector
> >
> > which basically says that 'SortedExponentVector' is an alias for
> > 'U32Vector'. BUT ATM this is not supported for categories. You can
> > write:
>
> I actually wonder where this might be useful.

Well, if that worked for categories, then

OrderedField() == Joint(OrderedIntegralDomain, Field)

would be just an alias, removing all possible troubles with propagation.

Concerning 'SortedExponentVector', it allows to make sources more
general while saving me writing a piece of boilerplate.

--
Waldek Hebisch