(
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.
)
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.
(
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.
)
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.
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?
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.
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.
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.
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...
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.
)
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)?