Le dim. 22 déc. 2024 à 12:56, Kurt Pagani <nil...@gmail.com> a écrit :
>
> Hmm, a delicate question on which I have no reasonable answer. However, from
> the end user perspective it might be favourable not to parametrize because
> (my experience) working in the interpreter is more comfortable without
> package calling all the time. It may also depend on whether how often one
> uses one of the types only or both in a session. From the programmer's
> viewpoint, however, parametrizing is certainly the better option -- isn't it?
> Regarding performance I couldn't say anything useful.
Hello,
In the example given the domain is parametrized and that works without
using package call like foo()JuliaMachineFloatFunctions(JF32|JF64)
but, it is needed, yes, if there are no JF32 or JF64 args to
jlApplyFunction-s, that's normal and annoying ;). In fact I am testing
right now without package parameters and clearly defined signatures,
that's easier.
>From the programmer point of view, my principal concern is to
automatically use correct parameters before calling Lisp. First this
avoid $Lisp call, and be sure to not fall in the debugger or
completely kill the process because of segmentation errors or other
things like that. So, yes, I think so also, using specialized
signatures is more practical for the users and for me if I want
to add a special function without parameters for example.
- Greg
> On Sunday, 22 December 2024 at 01:59:08 UTC+1 g.va...@gmail.com wrote:
>>
>> Hello folks,
>>
>> I am coding a sample package that performs operations on 32bit or
>> 64bit floats using my Julia interface (using libjulia).
>>
>> I wonder what is the best way to do it, I can use parameterized
>> signatures or more generically via a parameterized package. The latter
>> is not really necessary.
>> Here is a sample with a parameterized package:
>>
>> JuliaMachineFloatFunctions(R : JuliaMachineFloat) :
>> Exports == Implementation where
>> JF32 ==> JuliaFloat32
>> JF64 ==> JuliaFloat64
>> STR ==> String
>> Exports ==> with
>> jlApplyFunction : (STR, R) -> R
>> ++ jlApplyFunction(func,x)
>> jlApplyFunction : (STR, R, R) -> R
>> ++ jlApplyFunction(func,x,y)
>> jlApplyFunction : (STR, R, R, R) -> R
>> ++ jlApplyFunction(func,x,y,z)
>>
>> Implementation ==> add
>> import from String
>> if R is JF64 then
>> jlApplyFunction(func,a) ==
>> jl_dbl_function_dbl(func,a)$Lisp
>> jlApplyFunction(func,a, b) ==
>> jl_dbl_function_dbl_dbl(func,a,b)$Lisp
>> jlApplyFunction(func,a, b, c) ==
>> jl_dbl_function_dbl_dbl_dbl(func,a,b,c)$Lisp
>> else -- R is JF32
>> jlApplyFunction(func,a) ==
>> jl_flt_function_flt(func,a)$Lisp
>> jlApplyFunction(func,a, b) ==
>> jl_flt_function_flt_flt(func,a,b)$Lisp
>> jlApplyFunction(func,a, b, c) ==
>> jl_flt_function_flt_flt_flt(func,a,b,c)$Lisp
>>
>> But I can of course do not parametrize the package and use signatures like:
>>
>> jlApplyFunc : (STR, JF64) -> JF64
>> or
>> jlApplyFunc : (STR, JF32) -> JF32
>>
>> and in the implementation:
>> jlApplyFunction(func, a : JF64) ==
>> jl_dbl_function_dbl(func,a)$Lisp
>> etc.
>>
>> They are replaced (inlined) by the Lisp calls for the two coding styles.
>>
>> Example with the parameterized package above (Julia needs to perform
>> some initialization tasks at first call):
>>
>> (1) -> a:=jf64(2)
>>
>> (1) 2.0
>> Type: JuliaFloat64
>> Time: 4.03 (OT) = 4.03 sec
>> (2) -> b:=jf32(2)
>>
>> (2) 2.0
>> Type: JuliaFloat32
>> Time: 0.02 (OT) = 0.02 sec
>> (3) -> jlApplyFunction("sqrt",a)
>>
>> (3) 1.4142135623730951
>> Type: JuliaFloat64
>> Time: 0.02 (EV) = 0.03 sec
>> (4) -> jlApplyFunction("sqrt",b)
>>
>> (4) 1.4142135
>> Type: JuliaFloat32
>> Time: 0.01 (EV) = 0.01 sec
>> (5) -> % pretend SEX
>>
>> (5) 1.4142135f0
>> Type: SExpression
>> Time: 0 sec
>>
>> Any idea of the "best" way to do this? And the advantages and/or
>> inconveniences of those two coding styles?
>>
>> - Greg
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/fricas-devel/24adbee7-54aa-48d6-ac8d-449591a91ae5n%40googlegroups.com.
--
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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZXZ-jymGeyAzLa7VCw9yVW-Ds5S5wd5dpkb1nb_LvDCQ%40mail.gmail.com.
