Modifying function selection order

[Grégory Vanuxem]

Hello folks,

I have a little problem with function selection coded in the same package.

I have a temporary LinearAlgebra package which contains routines for say vectors and matrices with Float64 and Complex(Float64) coefficients. See link below if necessary. It's temporary because it will be splitted between Float64 and Complex(Float64) but for now this is not the point.

I need to easily/quickly create random arrays. The problem in my case is that FriCAS always chooses Complex(Float64) instead of Float64 coefficients. I began to code with Float64 so that borrows me a little.

To illustrate:

Declarations:

urand01 :   NNI -> JF64VEC

++ urand01(n) returns a uniform(0..1) Julia vector of size n.

urand01:   (NNI, NNI) -> JF64MAT

++ urand01(m,n) returns a uniform(0..1) Julia matrix of size (m,n).

urand01:   (NNI, NNI) -> JCF64MAT

++ urand01(m,n) returns a uniform(0..1) Julia matrix of size (m,n).

urand01 :   NNI -> JCF64VEC

++ urand01(n) returns a uniform(0..1) Julia vector of size n.

Where JF64VEC is a synonym of Float64 vectors whereas JCF64VEC Complex(Float64) vectors. As for matrices.

So my question is how do I force FriCAS to choose the JF64* versions first instead of JCF64* ? I tried to modify function declarations order, functions definitions order, src/algebra/exposed.lsp without success. Is it possible? It's not a big problem, I use *@Domain to switch what I need but this is annoying and I would be happy to know if/how it is possible.

Any hints?

Regards,

__

Greg

PS: I don't know why my mail is formatted like that (the black banner).

Link: https://github.com/gvanuxem/fricas/blob/jlfricas/src/algebra/jla.spad

[Grégory Vanuxem]

Waldek, *,

Thinking a little more about that, in _another context_, you explained to me, in response to a personal question, how the interpreter chooses which function to use. I guess now it may be the same "thing", isn't it? And if this is again the case I think it's a pity since end users can not modify this without modifying the interpreter which is not the aim of panAxiom (modifying the "kernel").

[Waldek Hebisch]

I is not clear what you really want. Spad compiler has its own rules.
Given JF64VEC and JCF64VEC intepreter has no way to know which one
is better, so it probably uses lexicographic order. How to
force right choice:
- you already know @Domain, that good solution
- you may use different names depending on type, for example 'urand01_rv',
'urand01_cv', etc.
- do as you planned and split the package. Expose wanted part.

I wrote about idea of partial exposure: if we could control exposure
for each function, we could mark unwanted variant as unexposed.
But ATM partial exposure is just an idea (and to that not fully
baked idea).



--
Waldek Hebisch

[Ralf Hemmecke]

> - you already know @Domain, that good solution

I would also have suggested that, but, honestly, I do not like it so
much. And usually prefer to give the interpreter other hint on how to
choose the right function.

> - you may use different names depending on type, for example 'urand01_rv',
> 'urand01_cv', etc.

This usually better. It could also make sense (if this fits your idea)
to write a package that is parametrized by the vector domain. Then you
would simply package-call the right function via the
urand01$YourPkg(JCF64VEC).

I'm not saying this is better or worse, it is just that not only the
interpreter is confused. When you will read your code in 2 years, you
will probably have a hard time to figure out from your code what the
program actually does, i.e. which function was chosen, if this is not
made more explicit. So I would say, not only help the interpreter to do
the right thing, but also the user to understand your code without
having to explicitly run it.

Ralf

[Grégory Vanuxem]

I is not clear what you really want.  Spad compiler has its own rules.
Given JF64VEC and JCF64VEC intepreter has no way to know which one
is better, so it probably uses lexicographic order.  How to
force right choice:
- you already know @Domain, that good solution
- you may use different names depending on type, for example 'urand01_rv',
  'urand01_cv', etc.

Yes, this is what I just did. It's for now the simplest way though unsatisfactory to me (urand01 vs curand01).

- do as you planned and split the package.  Expose wanted part.

I will. It's the most natural way I think and this is the Axiom way. ATM I'm working on the "back end", the LISP and C part to try to better granulate the code and juggle with the different LISP implementation specificities so pure Spad  "work" is not really my concern, but the more I'm thinking about that the more I'm thinking I'll do that first. In fact my mail was about is there a very simple way to change the interpreter selection in this case. So no. 

I wrote about idea of partial exposure: if we could control exposure
for each function, we could mark unwanted variant as unexposed.
But ATM partial exposure is just an idea (and to that not fully
baked idea).

Right now I'm on Linear Algebra stuff from the Julia team, the one available by default, and there is a "hidden" part which is more closer to the BLAS/LAPACK interface. Routines in this part are only available via package call, they are not exported. Though this is not very handy I think this  possibilty would be benefic to FRICAS. Sometimes all exported routines are  not necessary and overpopulate the global namespace. But unexposing an exposed routine I do know a language that does that. 

Anyway, thanks for your response. 

__

Greg

--
                              Waldek Hebisch

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20230524201141.kgtajvebwxo2fyop%40fricas.math.uni.wroc.pl.

[Grégory Vanuxem]

Le mer. 24 mai 2023 à 23:37, Grégory Vanuxem <g.va...@gmail.com> a écrit :

I is not clear what you really want.  Spad compiler has its own rules.
Given JF64VEC and JCF64VEC intepreter has no way to know which one
is better, so it probably uses lexicographic order.  How to
force right choice:
- you already know @Domain, that good solution
- you may use different names depending on type, for example 'urand01_rv',
  'urand01_cv', etc.

Yes, this is what I just did. It's for now the simplest way though unsatisfactory to me (urand01 vs curand01).

- do as you planned and split the package.  Expose wanted part.

I will. It's the most natural way I think and this is the Axiom way. ATM I'm working on the "back end", the LISP and C part to try to better granulate the code and juggle with the different LISP implementation specificities so pure Spad  "work" is not really my concern, but the more I'm thinking about that the more I'm thinking I'll do that first. In fact my mail was about is there a very simple way to change the interpreter selection in this case. So no. 

I wrote about idea of partial exposure: if we could control exposure
for each function, we could mark unwanted variant as unexposed.
But ATM partial exposure is just an idea (and to that not fully
baked idea).

Right now I'm on Linear Algebra stuff from the Julia team, the one available by default, and there is a "hidden" part which is more closer to the BLAS/LAPACK interface. Routines in this part are only available via package call, they are not exported. Though this is not very handy I think this possibilty would be benefic to FRICAS. Sometimes all exported routines are  not necessary and overpopulate the global namespace. But unexposing an exposed routine I do know a language that does that.

I forgot to say that in this "hidden" part it is possible to import routines, but individually. So you do not have to package call it.