Possible removals

[Waldek Hebisch]

I consider removal of rdesys.spad and cyclotom.spad after release.
Namely rdesys.spad is currently unused and unlikely to be useful
for end users. Instead of cyclotom.spad we have now cyclo.spad
which has better performance (due to better algorithm) and
more functionality.

In the future ModularDistinctDegreeFactorizer should be replaced
by newer routines (from ffact.spad). After that we should
remove moddfact.spad. Also, I expect that routines from
ffact.spad will make ddfact.spad no logner needed.

While the process is slow I am replacing Boot numeric code by
Spad. After that functions from DoubleFloatSpecialFunctions will
be no longer used. This will allow removal of DoubleFloatSpecialFunctions
and sfsfun.boot.


--
Waldek Hebisch

[Ralf Hemmecke]

I was actually looking for a simpler way to display 1D output (Format1D).

It can be easily done via

print1D x ==> display((x::OutputForm)::Formatter(Format1D))

Studying whether we can sensibly include such a function into FriCAS
(not the topic of the mail), I stumpled over "PrintPackage".

PrintPackage() : with
print : OutputForm -> Void
++ print(o) writes the output form o on standard output using the
++ two-dimensional formatter.
== add
print(x) == print(x)$OutputForm

I somehow fail to see what advantage it has. Why another "print"
function if eventually, a value of any type has to be converted to
OutputForm anyway and so print$OutputForm could be used directly?




Also the SpecialOutputPackage is somewhat useless.


(215) -> outputAsScript("foo"::OutputForm)

>> System error:
The function BOOT::|formulaFormat| is undefined.

(215) -> outputAsFortran("foo"::OutputForm)

>> System error:
The function BOOT::|dispfortexp| is undefined.

(215) -> outputAsFortran(42::OutputForm)

>> System error:
The function BOOT::|dispfortexp| is undefined.


Although DisplayPackage is used in view2D and view3D it may also be a
candidate for removal in the future.


Ralf

[Waldek Hebisch]

On Tue, May 17, 2022 at 08:50:26AM +0200, Ralf Hemmecke wrote:
> I was actually looking for a simpler way to display 1D output (Format1D).
>
> It can be easily done via
>
> print1D x ==> display((x::OutputForm)::Formatter(Format1D))
>
> Studying whether we can sensibly include such a function into FriCAS
> (not the topic of the mail), I stumpled over "PrintPackage".
>
> PrintPackage() : with
> print : OutputForm -> Void
> ++ print(o) writes the output form o on standard output using the
> ++ two-dimensional formatter.
> == add
> print(x) == print(x)$OutputForm
>
> I somehow fail to see what advantage it has. Why another "print" function if
> eventually, a value of any type has to be converted to OutputForm anyway and
> so print$OutputForm could be used directly?

IIUC the idea is that exposing OutputForm exposes several functions
which are irrelevant to printing. So, this is little helper to
make use of 'print' more tidy. Of course, one can discuss if
gain is worth the code. Here I am just trying to reverse-engineer
the rationale.

> Also the SpecialOutputPackage is somewhat useless.
>
>
> (215) -> outputAsScript("foo"::OutputForm)
>
> >> System error:
> The function BOOT::|formulaFormat| is undefined.
>
> (215) -> outputAsFortran("foo"::OutputForm)
>
> >> System error:
> The function BOOT::|dispfortexp| is undefined.
>
> (215) -> outputAsFortran(42::OutputForm)
>
> >> System error:
> The function BOOT::|dispfortexp| is undefined.

This could be easily fixed. OTOH nobody complained in several
years, so number of users must be limited...

> Although DisplayPackage is used in view2D and view3D it may also be a
> candidate for removal in the future.

Actually, there is question if we should improve it or replace. Several
folks wanted/used similar functionality in different ways. It would
be good to have single place providing needed support.

--
Waldek Hebisch

[Ralf Hemmecke]

On 17.05.22 04:41, Waldek Hebisch wrote:
> I consider removal of rdesys.spad and

OK.

> cyclotom.spad after release.

Nearly OK.

> Instead of cyclotom.spad we have now cyclo.spad which has better
> performance (due to better algorithm) and more functionality.

I already use the function cyclotomic(n)$CyclotomicPolynomialPackage in
my QEta package. It would cause unnecessary trouble / compatibility
problems if I then must have two package versions around, one for people
on FriCAS 1.3.7 and one for people that compile from the sources after
removal of that package.

Wouldn't it be an option to provide the functions in cyclo.spad under
the package name CyclotomicPolynomialPackage when you remove
cyclotom.spad so that there would be no effect on end-users?

I do not care about the other two functions

cyclotomicDecomposition : Integer -> LSUP
++ cyclotomicDecomposition(n) returns prime factors of
++ \spad{x^n - 1} over integers.
cyclotomicFactorization : Integer -> FR
++ cyclotomicFactorization(n) returns prime factors of
++ \spad{x^n - 1} over integers.

Ralf

[Waldek Hebisch]

On Tue, May 17, 2022 at 10:42:41PM +0200, Ralf Hemmecke wrote:
> On 17.05.22 04:41, Waldek Hebisch wrote:
> >I consider removal of rdesys.spad and
>
> OK.
>
> >cyclotom.spad after release.
>
> Nearly OK.
>
> >Instead of cyclotom.spad we have now cyclo.spad which has better
> >performance (due to better algorithm) and more functionality.
>
> I already use the function cyclotomic(n)$CyclotomicPolynomialPackage in my
> QEta package. It would cause unnecessary trouble / compatibility problems if
> I then must have two package versions around, one for people on FriCAS 1.3.7
> and one for people that compile from the sources after removal of that
> package.
>
> Wouldn't it be an option to provide the functions in cyclo.spad under the
> package name CyclotomicPolynomialPackage when you remove cyclotom.spad so
> that there would be no effect on end-users?

Well, as long as we have cyclotom.spad new package must use different
name. Removing package _after_ release gives reasonable transition
period: the old code will work with old versions and new release.

CyclotomicUtilities was added on January 2, so people who build from
reasonably recent sources will get it.

For CyclotomicPolynomialPackage we probably could do rename after
release, but in general removal of old package name is cleaner

> I do not care about the other two functions
>
> cyclotomicDecomposition : Integer -> LSUP
> ++ cyclotomicDecomposition(n) returns prime factors of
> ++ \spad{x^n - 1} over integers.
> cyclotomicFactorization : Integer -> FR
> ++ cyclotomicFactorization(n) returns prime factors of
> ++ \spad{x^n - 1} over integers.
>

--
Waldek Hebisch

[Waldek Hebisch]

One more algebra file to remove: ffx.spad duplicates (small part
of) functionality in ffdoms.spad.

--
Waldek Hebisch

[Ralf Hemmecke]

Agreed.

Ralf