[GRASS-user] log function for SQLite

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.

I think the reference in the manual requires a source or a link to it.

Thank you, Nikos

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.

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

with further links to extensions:

https://www.sqlite.org/contrib

yes, this should go into the manual.

any manual diff available?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/log-function-for-SQLite-tp5311323p5311325.html
Sent from the Grass - Users mailing list archive at Nabble.com.

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

with further links to extensions:

https://www.sqlite.org/contrib

yes, this should go into the manual.

any manual diff available?

Not yet.

(
I can't say I didn't search (20+ minutes). There is no related "log"
result that leads to that "contrib" page from within SQLite's page
search field itself! And, in our wiki I admit I did not think about
Windows at all.
)

Cheers, Nikos

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

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.

Nikos

with further links to extensions:

https://www.sqlite.org/contrib

yes, this should go into the manual.

any manual diff available?

Not yet.

(
I can't say I didn't search (20+ minutes). There is no related "log"
result that leads to that "contrib" page from within SQLite's page
search field itself! And, in our wiki I admit I did not think about
Windows at all.
)

On Wed, Mar 8, 2017 at 9:27 AM, Nikos Alexandris
<nik@nikosalexandris.net> 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.

I think the reference in the manual requires a source or a link to it.

Here is the related changeset:
https://trac.osgeo.org/grass/changeset/63238
It went into the 7.2. release branch when we created it.

I agree that the manual needs to be expanded (link to Wiki page) in
order to explain where to get this extra library.

Related discussions:
a) https://lists.osgeo.org/pipermail/grass-dev/2014-November/thread.html#71852
b) https://lists.osgeo.org/pipermail/grass-dev/2014-December/thread.html#72596

Compilation on Windows:
http://stackoverflow.com/a/20984485/452464

Best
Markus

--
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog

On 08/03/17 11:26, Nikos Alexandris wrote:

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

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.

-1

I don't think we should start interalizing solutions to issues related to database backend choice.

Moritz

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.

We can of course integrate a log and an "sqrt" function for v.db.update,
right?

Nikos

On 08/03/17 13:17, Nikos Alexandris wrote:

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.

We can of course integrate a log and an "sqrt" function for v.db.update,
right?

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.

Moritz

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?

Note, d.vect has an "-r" flag. I want to get these values in a new
column, so I can share the vector and this sqrt-ed attribute outside of
GRASS.

Cheers, Nikos

Le 9 mars 2017 19:01:32 GMT+01:00, Nikos Alexandris <nik@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?

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

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...

Moritz

Note, d.vect has an "-r" flag. I want to get these values in a new
column, so I can share the vector and this sqrt-ed attribute outside of
GRASS.

Cheers, Nikos

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

Le 9 mars 2017 19:01:32 GMT+01:00, Nikos Alexandris <nik@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]

On Wed, Mar 8, 2017 at 11:26 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

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

For Linux:

Now also here:

https://grasswiki.osgeo.org/wiki/Build_SQLite_extension_on_Linux

1) there is still a "compile" warning for the code (no time to hunt)

This version contains three changes compared to the original version,
maybe useful?
https://raw.githubusercontent.com/seth/RSQLite.extfuns/master/src/extension-functions.c

2) The log() function does not like, naturally, 0 values. But this can
be workedaround with a where SQL clause.

To be added to the manual page.

...

(
I can't say I didn't search (20+ minutes). There is no related "log"
result that leads to that "contrib" page from within SQLite's page
search field itself! And, in our wiki I admit I did not think about
Windows at all.
)

We need more volunteers to document stuff.

Markus

On 12-03-17 11:50, Markus Neteler wrote:

On Wed, Mar 8, 2017 at 11:26 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

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

For Linux:

Now also here:

https://grasswiki.osgeo.org/wiki/Build_SQLite_extension_on_Linux

Very useful

1) there is still a "compile" warning for the code (no time to hunt)

This version contains three changes compared to the original version,
maybe useful?
https://raw.githubusercontent.com/seth/RSQLite.extfuns/master/src/extension-functions.c

2) The log() function does not like, naturally, 0 values. But this can
be workedaround with a where SQL clause.

To be added to the manual page.

...

(
I can't say I didn't search (20+ minutes). There is no related "log"
result that leads to that "contrib" page from within SQLite's page
search field itself! And, in our wiki I admit I did not think about
Windows at all.
)

We need more volunteers to document stuff.

Concerning documenting stuff, I know there has been a discussion in the past about what should go to trac and what to the wiki. Was there any conclusion or document somewhere providing some guidelines on this? In addition, is there somewhere an overview of all pages in the wiki? That could helpful for the user, but also for those wanting to contribute / check if there is anything they can contribute to. If it doesn't exist, would it be something that could be generated (easily)?

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user