[GRASS-user] log function for SQLite

[Nikos Alexandris]

* Moritz Lennert <mlennert at club.worldonline.be> [2017-03-09 19:07:21 +0100]:

>
>
>Le 9 mars 2017 19:01:32 GMT+01:00, Nikos Alexandris <nik at nikosalexandris.net> a écrit :
>>
>>NikosAlexandris wrote:
>>>>>>>>> Dear list,
>>>>>>>>> where is the extension for SQLite that contains the
>>(mathematical) log
>>>>>>>>> function available to download?  As referenced in
>>>>>>>>> https://grass.osgeo.org/grass73/manuals/v.db.update.html.
>>
>>Helmut Kudrnovsky:
>>
>>>>>>>>> I think the reference in the manual requires a source or a link
>>to it.
>>>>>>>> just found something in the wiki:
>>>>>>>>
>>https://grasswiki.osgeo.org/wiki/Build_SQLite_extension_on_windows
>>
>>Nikos:
>>
>>>>>> For Linux:
>>>>>> gcc extension-functions.c -fPIC -shared -o
>>libextensionfunctions.so
>>>>>> Note,
>>>>>> 1) there is still a "compile" warning for the code (no time to
>>hunt)
>>>>>> 2) The log() function does not like, naturally, 0 values. But this
>>can
>>>>>> be workedaround with a where SQL clause.
>>>>>> Can we not integrate this into GRASS?  It feels awkward to have to
>>spend
>>>>>> so much time for a log or similar function to use in a v.db.update
>>call.
>>
>>Moritz:
>>
>>>>> -1
>>>>>
>>>>> I don't think we should start interalizing solutions to issues
>>related
>>>>> to database backend choice.
>>
>>Nikos:
>>
>>>> We can of course integrate a log and an "sqrt" function for
>>v.db.update,
>>>> right?
>>
>>Moritz:
>>
>>>You mean within the v.db.update code ? But why log and sqrt and not
>>others ?
>>>As said, I don't think we should go down that road.
>>
>>You mean to say also no in intgrating, yes, in v.db.update some
>>"common"
>>functions?  Why not?  Log and SqRt are just common functions.  We have
>>all of the basic descriptive statistics and we can do pretty much
>>everything with mapcalc.  Why not so for vector attributes, independent
>>from tha backend?
>>
>>If there is no complication in integrating in v.db.update some math,
>>then why not use all of the math functions defined in the contributed
>>library for sqlite?

Moritz

>The difficulty is not the functions as such, but the parser you need to
>interpret what the user writes.

I see.

>But hey, if you want to go down that road, go ahead. I just don't think
>that compiling the functions once for SQLite is such a hassle as to
>make worthwhile...

This is not easy for everyone though.

Nikos

[rest deleted]