n arity with method

n arity with method

[Damien Mattei]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

(import (rename (scheme base) (* orig*)))

(define * (make-procedure method: (lambda (x ::number y ::number) (orig* x
y))
 method: (lambda (x ::matrix y ::matrix) (multiply-matrix-matrix  x y))
 method: (lambda (x ::matrix y ::vector) (multiply-matrix-vector  x y))))

is there a way to still have * a n-arity operator with typed methods ?
because now i have this error:
(* 2 3 4)
Argument  (null) has wrong type
at gnu.mapping.CallContext.matchError(CallContext.java:185)
at gnu.expr.GenericProc.applyToConsumerGP(GenericProc.java:132)
at gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132)
at gnu.mapping.CallContext.runUntilDone(CallContext.java:586)
at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:343)
at gnu.expr.ModuleExp.evalModule(ModuleExp.java:211)
at kawa.Shell.run(Shell.java:289)
at kawa.Shell.run(Shell.java:196)
at kawa.Shell.run(Shell.java:183)
at kawa.repl.processArgs(repl.java:724)
at kawa.repl.main(repl.java:830)
the problem is that * is no more n-arity operator now

Damien

anyway there is perheaps a possibility of using a variable number of args
but i did not think it this evening.... perheaps tomorrow...

Re: n arity with method

[Damien Mattei]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

seems there is some difference in 'load' and 'import' ,the same program can
run with 'load' and not with 'import'
about the overloading of n-arity operators i find a solution in
'define-method' :

(define ⋅ (make-procedure method: (lambda (x ::number y ::number) (* x y))
 method: (lambda (x ::matrix y ::matrix) (multiply-matrix-matrix  x y))
 method: (lambda (x ::matrix y ::vector) (multiply-matrix-vector  x y))
 method: (lambda lyst (apply * lyst))))


(insert-operator! * ⋅)

kawa -d classes
-Dkawa.import.path=".:/Users/mattei/Scheme-PLUS-for-Kawa:./kawa" -C
exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa_classes.scm

i hoped to have a speed up by compiling the kawa code in .class files but
it is the same , i suppose that 'load' compile the code , ad he does it
with more easyness than 'require' , with 'load' the overloading features of
Scheme+ worked fine , not with 'require'



On Thu, Nov 16, 2023 at 11:53 PM Damien Mattei <damien.mattei@gmail.com>
wrote:

> (import (rename (scheme base) (* orig*)))
>
> (define * (make-procedure method: (lambda (x ::number y ::number) (orig* x
> y))
>  method: (lambda (x ::matrix y ::matrix) (multiply-matrix-matrix  x y))
>  method: (lambda (x ::matrix y ::vector) (multiply-matrix-vector  x y))))
>
> is there a way to still have * a n-arity operator with typed methods ?
> because now i have this error:
> (* 2 3 4)
> Argument  (null) has wrong type
> at gnu.mapping.CallContext.matchError(CallContext.java:185)
> at gnu.expr.GenericProc.applyToConsumerGP(GenericProc.java:132)
> at gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132)
> at gnu.mapping.CallContext.runUntilDone(CallContext.java:586)
> at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:343)
> at gnu.expr.ModuleExp.evalModule(ModuleExp.java:211)
> at kawa.Shell.run(Shell.java:289)
> at kawa.Shell.run(Shell.java:196)
> at kawa.Shell.run(Shell.java:183)
> at kawa.repl.processArgs(repl.java:724)
> at kawa.repl.main(repl.java:830)
> the problem is that * is no more n-arity operator now
>
> Damien
>
> anyway there is perheaps a possibility of using a variable number of args
> but i did not think it this evening.... perheaps tomorrow...
>

Re: n arity with method

[Damien Mattei]

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

when comparing speed on the first part of my program written in Scheme+ it
run in 15" with Kawa and 7" in Racket.
the speed is the same in all kawa version.
the REPL version is:
https://github.com/damien-mattei/AI_Deep_Learning/blob/main/exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa%2B.scm
the compiled classes version is:
https://github.com/damien-mattei/AI_Deep_Learning/blob/main/exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa_classes%2B.scm
the new and latest version of Scheme+ for Kawa is now tested and available
here:

https://github.com/damien-mattei/Scheme-PLUS-for-Kawa

docs are  here:
https://damien-mattei.github.io/Scheme-PLUS-for-Racket/Scheme+io.html


On Sat, Nov 18, 2023 at 12:14 PM Damien Mattei <damien.mattei@gmail.com>
wrote:

> seems there is some difference in 'load' and 'import' ,the same program
> can run with 'load' and not with 'import'
> about the overloading of n-arity operators i find a solution in
> 'define-method' :
>
> (define ⋅ (make-procedure method: (lambda (x ::number y ::number) (* x y))
>  method: (lambda (x ::matrix y ::matrix) (multiply-matrix-matrix  x y))
>  method: (lambda (x ::matrix y ::vector) (multiply-matrix-vector  x y))
>  method: (lambda lyst (apply * lyst))))
>
>
> (insert-operator! * ⋅)
>
> kawa -d classes
> -Dkawa.import.path=".:/Users/mattei/Scheme-PLUS-for-Kawa:./kawa" -C
> exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa_classes.scm
>
> i hoped to have a speed up by compiling the kawa code in .class files but
> it is the same , i suppose that 'load' compile the code , ad he does it
> with more easyness than 'require' , with 'load' the overloading features of
> Scheme+ worked fine , not with 'require'
>
>
>
> On Thu, Nov 16, 2023 at 11:53 PM Damien Mattei <damien.mattei@gmail.com>
> wrote:
>
>> (import (rename (scheme base) (* orig*)))
>>
>> (define * (make-procedure method: (lambda (x ::number y ::number) (orig*
>> x y))
>>  method: (lambda (x ::matrix y ::matrix) (multiply-matrix-matrix  x y))
>>  method: (lambda (x ::matrix y ::vector) (multiply-matrix-vector  x y))))
>>
>> is there a way to still have * a n-arity operator with typed methods ?
>> because now i have this error:
>> (* 2 3 4)
>> Argument  (null) has wrong type
>> at gnu.mapping.CallContext.matchError(CallContext.java:185)
>> at gnu.expr.GenericProc.applyToConsumerGP(GenericProc.java:132)
>> at gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132)
>> at gnu.mapping.CallContext.runUntilDone(CallContext.java:586)
>> at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:343)
>> at gnu.expr.ModuleExp.evalModule(ModuleExp.java:211)
>> at kawa.Shell.run(Shell.java:289)
>> at kawa.Shell.run(Shell.java:196)
>> at kawa.Shell.run(Shell.java:183)
>> at kawa.repl.processArgs(repl.java:724)
>> at kawa.repl.main(repl.java:830)
>> the problem is that * is no more n-arity operator now
>>
>> Damien
>>
>> anyway there is perheaps a possibility of using a variable number of args
>> but i did not think it this evening.... perheaps tomorrow...
>>
>

Re: n arity with method

[Per Bothner]

On 11/18/23 23:23, Damien Mattei via Kawa wrote:
> when comparing speed on the first part of my program written in Scheme+ it
> run in 15" with Kawa and 7" in Racket.

It is likely you can speed up Kawa quite a bit by fixing a few slow spots.
Specifically, anytime you do run-time reflection (or worse: eval/load) you're
going to lose a lot of performance. If you can replace generic arithmetic
or vector/list indexing with type-specific arithmetic/indexing that can
also make a big difference. List processing (especially if you call cons
a lot) is always going to be relatively expensive.

Profiling is probably the thing to try. I do little-to-no Java programming
these days, so I can't be any more specific with help.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: n arity with method

[Damien Mattei]

[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

yes ,indexing is overloaded ,using same procedure for vector,string,hash
table ,this take times but the slower is the infix precedence operator
algorithm that is called each time even if the formula in a loop never
change,example in:
(for-each-in (j (in-range len_layer_output)) ; line
   (for-each-in (i (in-range len_layer_input)) ; column , parcours les
colonnes de la ligne sauf le bias
       {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}})

        ; and update the bias
     {M_i_o[j 0]  <-  M_i_o[j 0] - {(- η) * 1.0 * მzⳆმz̃(z_output[j]
z̃_output[j]) * ᐁ_i_o[j]}}))

{M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}} is expanded at each 'for'
loop iteration in:

($nfx$
  (bracket-apply M_i_o j (+ i 1))
  <-
  (bracket-apply M_i_o j (+ i 1))
  -
  (*
   (- η)
   (bracket-apply z_input i)
   (მzⳆმz̃ (bracket-apply z_output j) (bracket-apply z̃_output j))
   (bracket-apply ᐁ_i_o j)))

with evaluation of $nfx$ (see code in :
https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/scheme-infix.scm)
and many bracket-apply (
https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/apply-square-brackets.scm
) even if the expression never change, the numeric computation change, but
not the symbolic evaluation of operator precedence.

This could be precomputed by Scheme+ before compilation by Kawa or any
Scheme that use Scheme+ but this is a big work i have not begin.

Damien

On Sun, Nov 19, 2023 at 6:50 PM Per Bothner <per@bothner.com> wrote:

> On 11/18/23 23:23, Damien Mattei via Kawa wrote:
> > when comparing speed on the first part of my program written in Scheme+
> it
> > run in 15" with Kawa and 7" in Racket.
>
> It is likely you can speed up Kawa quite a bit by fixing a few slow spots.
> Specifically, anytime you do run-time reflection (or worse: eval/load)
> you're
> going to lose a lot of performance. If you can replace generic arithmetic
> or vector/list indexing with type-specific arithmetic/indexing that can
> also make a big difference. List processing (especially if you call cons
> a lot) is always going to be relatively expensive.
>
> Profiling is probably the thing to try. I do little-to-no Java programming
> these days, so I can't be any more specific with help.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

Re: n arity with method

[Damien Mattei]

[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]

and i just realize there is even more parenthesis { } in the above
expression that the infix operator precedence analyser does not need, we
can rewrite the expression:
{M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}}

{M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - (- η) * z_input[i] *
მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}

which is :
{M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] + η * z_input[i] *
მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}

and my infix operator precedence deal well with * and + or - precedences
and the computation still give the good result:
################## NOT ##################
*init* : nc=#(1 2 1)
z=#(#(0) #(0 0) #(0))
z̃=#(#(0) #(0 0) #(0))
M=#(matrix@5942ee04 matrix@5e76a2bb)
ᐁ=#(#(0) #(0 0) #(0))
nbiter=5000
exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa.scm:131:2:
warning - no known slot 'apprentissage' in java.lang.Object
0
1000
2000
3000
4000
exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa.scm:132:2:
warning - no known slot 'test' in java.lang.Object
Test des exemples :
#(1) --> #(0.006614618861519643) : on attendait #(0)
#(0) --> #(0.9929063781049513) : on attendait #(1)
Error on examples=1.1928342099764103E-4

;-)

so many computation in deep learning just to compute NOT boolean,what a '50
light bulb computer was doing faster..... :-)

Damien



On Mon, Nov 20, 2023 at 2:51 PM Damien Mattei <damien.mattei@gmail.com>
wrote:

> yes ,indexing is overloaded ,using same procedure for vector,string,hash
> table ,this take times but the slower is the infix precedence operator
> algorithm that is called each time even if the formula in a loop never
> change,example in:
> (for-each-in (j (in-range len_layer_output)) ; line
>    (for-each-in (i (in-range len_layer_input)) ; column , parcours les
> colonnes de la ligne sauf le bias
>        {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
> მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}})
>
>         ; and update the bias
>      {M_i_o[j 0]  <-  M_i_o[j 0] - {(- η) * 1.0 * მzⳆმz̃(z_output[j]
> z̃_output[j]) * ᐁ_i_o[j]}}))
>
> {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
> მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}} is expanded at each 'for'
> loop iteration in:
>
> ($nfx$
>   (bracket-apply M_i_o j (+ i 1))
>   <-
>   (bracket-apply M_i_o j (+ i 1))
>   -
>   (*
>    (- η)
>    (bracket-apply z_input i)
>    (მzⳆმz̃ (bracket-apply z_output j) (bracket-apply z̃_output j))
>    (bracket-apply ᐁ_i_o j)))
>
> with evaluation of $nfx$ (see code in :
> https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/scheme-infix.scm)
> and many bracket-apply (
> https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/apply-square-brackets.scm
> ) even if the expression never change, the numeric computation change, but
> not the symbolic evaluation of operator precedence.
>
> This could be precomputed by Scheme+ before compilation by Kawa or any
> Scheme that use Scheme+ but this is a big work i have not begin.
>
> Damien
>
> On Sun, Nov 19, 2023 at 6:50 PM Per Bothner <per@bothner.com> wrote:
>
>> On 11/18/23 23:23, Damien Mattei via Kawa wrote:
>> > when comparing speed on the first part of my program written in Scheme+
>> it
>> > run in 15" with Kawa and 7" in Racket.
>>
>> It is likely you can speed up Kawa quite a bit by fixing a few slow spots.
>> Specifically, anytime you do run-time reflection (or worse: eval/load)
>> you're
>> going to lose a lot of performance. If you can replace generic arithmetic
>> or vector/list indexing with type-specific arithmetic/indexing that can
>> also make a big difference. List processing (especially if you call cons
>> a lot) is always going to be relatively expensive.
>>
>> Profiling is probably the thing to try. I do little-to-no Java programming
>> these days, so I can't be any more specific with help.
>> --
>>         --Per Bothner
>> per@bothner.com   http://per.bothner.com/
>>
>

Re: n arity with method

[Damien Mattei]

[-- Attachment #1: Type: text/plain, Size: 4766 bytes --]

and i just port the code to Guile (
https://github.com/damien-mattei/AI_Deep_Learning/blob/main/exo_retropropagationNhidden_layers_matrix_v2_by_vectors4guile%2B.scm
), which i know is based and easily interfaced with C language which is the
fastest language (except assembly)  and it is 20% slower than Kawa based on
Java...
Damien

On Tue, Nov 21, 2023 at 9:48 AM Damien Mattei <damien.mattei@gmail.com>
wrote:

> and i just realize there is even more parenthesis { } in the above
> expression that the infix operator precedence analyser does not need, we
> can rewrite the expression:
> {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
> მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}}
>
> {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - (- η) * z_input[i] *
> მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}
>
> which is :
> {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] + η * z_input[i] *
> მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}
>
> and my infix operator precedence deal well with * and + or - precedences
> and the computation still give the good result:
> ################## NOT ##################
> *init* : nc=#(1 2 1)
> z=#(#(0) #(0 0) #(0))
> z̃=#(#(0) #(0 0) #(0))
> M=#(matrix@5942ee04 matrix@5e76a2bb)
> ᐁ=#(#(0) #(0 0) #(0))
> nbiter=5000
> exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa.scm:131:2:
> warning - no known slot 'apprentissage' in java.lang.Object
> 0
> 1000
> 2000
> 3000
> 4000
> exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa.scm:132:2:
> warning - no known slot 'test' in java.lang.Object
> Test des exemples :
> #(1) --> #(0.006614618861519643) : on attendait #(0)
> #(0) --> #(0.9929063781049513) : on attendait #(1)
> Error on examples=1.1928342099764103E-4
>
> ;-)
>
> so many computation in deep learning just to compute NOT boolean,what a
> '50 light bulb computer was doing faster..... :-)
>
> Damien
>
>
>
> On Mon, Nov 20, 2023 at 2:51 PM Damien Mattei <damien.mattei@gmail.com>
> wrote:
>
>> yes ,indexing is overloaded ,using same procedure for vector,string,hash
>> table ,this take times but the slower is the infix precedence operator
>> algorithm that is called each time even if the formula in a loop never
>> change,example in:
>> (for-each-in (j (in-range len_layer_output)) ; line
>>    (for-each-in (i (in-range len_layer_input)) ; column , parcours les
>> colonnes de la ligne sauf le bias
>>        {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
>> მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}})
>>
>>         ; and update the bias
>>      {M_i_o[j 0]  <-  M_i_o[j 0] - {(- η) * 1.0 * მzⳆმz̃(z_output[j]
>> z̃_output[j]) * ᐁ_i_o[j]}}))
>>
>> {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
>> მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}} is expanded at each 'for'
>> loop iteration in:
>>
>> ($nfx$
>>   (bracket-apply M_i_o j (+ i 1))
>>   <-
>>   (bracket-apply M_i_o j (+ i 1))
>>   -
>>   (*
>>    (- η)
>>    (bracket-apply z_input i)
>>    (მzⳆმz̃ (bracket-apply z_output j) (bracket-apply z̃_output j))
>>    (bracket-apply ᐁ_i_o j)))
>>
>> with evaluation of $nfx$ (see code in :
>> https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/scheme-infix.scm)
>> and many bracket-apply (
>> https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/apply-square-brackets.scm
>> ) even if the expression never change, the numeric computation change, but
>> not the symbolic evaluation of operator precedence.
>>
>> This could be precomputed by Scheme+ before compilation by Kawa or any
>> Scheme that use Scheme+ but this is a big work i have not begin.
>>
>> Damien
>>
>> On Sun, Nov 19, 2023 at 6:50 PM Per Bothner <per@bothner.com> wrote:
>>
>>> On 11/18/23 23:23, Damien Mattei via Kawa wrote:
>>> > when comparing speed on the first part of my program written in
>>> Scheme+ it
>>> > run in 15" with Kawa and 7" in Racket.
>>>
>>> It is likely you can speed up Kawa quite a bit by fixing a few slow
>>> spots.
>>> Specifically, anytime you do run-time reflection (or worse: eval/load)
>>> you're
>>> going to lose a lot of performance. If you can replace generic arithmetic
>>> or vector/list indexing with type-specific arithmetic/indexing that can
>>> also make a big difference. List processing (especially if you call cons
>>> a lot) is always going to be relatively expensive.
>>>
>>> Profiling is probably the thing to try. I do little-to-no Java
>>> programming
>>> these days, so I can't be any more specific with help.
>>> --
>>>         --Per Bothner
>>> per@bothner.com   http://per.bothner.com/
>>>
>>