More built-in functions for basic math

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

More built-in functions for basic math

Dominique Devienne
I find that I'm often missing basic mathematical functions in the default
shell.
Many SQLite clients add many, but given that the official SQLite shell
misses
them you can't use them in views for predefined "reports" within the DB
file itself, for example.

There's [1] which is 50KB, but only a tiny part of that is for math
functions, so math functions are only a few KBs away.

Adding basic math functions and stddev, median, variance, etc... wouldn't
add much,
and they could be added to the shell at least, if deemed too big for the
amalgamation,
but given that many things can be turned on/off in the amalgamation, that
would be just
one more IMHO.

The goal here would be to move the "minimum expectations" of what can be
done with the official shell, out-of-the-box, w/o the need to resort to
.load of an extension which is not readily available in compiled form for
many non-programmer users.

And IMHO, the ability to use math functions in views is why "moving the
baseline" is necessary,
since without those being built-in, the views will just error out in the
official shell.

My $0.02, despite the upcoming chorus about lite or do-it-in-your-app
naysayers. Thanks, --DD

PS: Sure SQLite's primary use case is as an *embedded* DB, so the host-app
can add
whatever it wants/needs in terms of UDFs, but I also think the "standalone"
use of SQLite independently of the app that generated the DB file is
important, and we should raise the
bar of the minimum number of built-in functions, starting with the official
shell.

[1] https://www.sqlite.org/contrib/download/extension-functions.c?get=25
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

R Smith
I second this - Been having a hard time making basic queries with a
simple x^y function in SQL for SQLite since there is no guarantee what
the end-user's system will have it compiled-in. I can version-check or
version-enforce easily, but compile-option check or enforce is a no-go.

If we can shift the basic "Auto-included" feature set a few notches up,
we can still have hardcore minimalist users compile their own (as they
probably already do), but it would be nice to know a query running on a
standard linux or Apple OS on the included SQLite will support some
wider functions as a rule[1] without having to keep track. I realize
this will take a time to permeate through the world, but it would be
great to start asap.

[1] Yes, there are threads on this same forum where I myself kicked
against bloating SQLite with unneeded functionality as a rule, but
perhaps the definition of "needed" needs revisiting. I think good math
and string functions certainly qualify.

Cheers,
Ryan


On 2017/03/09 11:45 AM, Dominique Devienne wrote:

> I find that I'm often missing basic mathematical functions in the default
> shell.
> Many SQLite clients add many, but given that the official SQLite shell
> misses
> them you can't use them in views for predefined "reports" within the DB
> file itself, for example.
>
> There's [1] which is 50KB, but only a tiny part of that is for math
> functions, so math functions are only a few KBs away.
>
> Adding basic math functions and stddev, median, variance, etc... wouldn't
> add much,
> and they could be added to the shell at least, if deemed too big for the
> amalgamation,
> but given that many things can be turned on/off in the amalgamation, that
> would be just
> one more IMHO.
>
> The goal here would be to move the "minimum expectations" of what can be
> done with the official shell, out-of-the-box, w/o the need to resort to
> .load of an extension which is not readily available in compiled form for
> many non-programmer users.
>
> And IMHO, the ability to use math functions in views is why "moving the
> baseline" is necessary,
> since without those being built-in, the views will just error out in the
> official shell.
>
> My $0.02, despite the upcoming chorus about lite or do-it-in-your-app
> naysayers. Thanks, --DD
>
> PS: Sure SQLite's primary use case is as an *embedded* DB, so the host-app
> can add
> whatever it wants/needs in terms of UDFs, but I also think the "standalone"
> use of SQLite independently of the app that generated the DB file is
> important, and we should raise the
> bar of the minimum number of built-in functions, starting with the official
> shell.
>
> [1] https://www.sqlite.org/contrib/download/extension-functions.c?get=25
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Eric Grange
A bonus of having them defined in the core is that it avoids the minor
inconsistencies that are bound to arise in custom implementations (starting
with the name of math functions)

Main downside is probably not going to be the size, but that it reserves
more names, and may conflict with existing custom implementations.

Eric

On Thu, Mar 9, 2017 at 1:16 PM, R Smith <[hidden email]> wrote:

> I second this - Been having a hard time making basic queries with a simple
> x^y function in SQL for SQLite since there is no guarantee what the
> end-user's system will have it compiled-in. I can version-check or
> version-enforce easily, but compile-option check or enforce is a no-go.
>
> If we can shift the basic "Auto-included" feature set a few notches up, we
> can still have hardcore minimalist users compile their own (as they
> probably already do), but it would be nice to know a query running on a
> standard linux or Apple OS on the included SQLite will support some wider
> functions as a rule[1] without having to keep track. I realize this will
> take a time to permeate through the world, but it would be great to start
> asap.
>
> [1] Yes, there are threads on this same forum where I myself kicked
> against bloating SQLite with unneeded functionality as a rule, but perhaps
> the definition of "needed" needs revisiting. I think good math and string
> functions certainly qualify.
>
> Cheers,
> Ryan
>
>
>
> On 2017/03/09 11:45 AM, Dominique Devienne wrote:
>
>> I find that I'm often missing basic mathematical functions in the default
>> shell.
>> Many SQLite clients add many, but given that the official SQLite shell
>> misses
>> them you can't use them in views for predefined "reports" within the DB
>> file itself, for example.
>>
>> There's [1] which is 50KB, but only a tiny part of that is for math
>> functions, so math functions are only a few KBs away.
>>
>> Adding basic math functions and stddev, median, variance, etc... wouldn't
>> add much,
>> and they could be added to the shell at least, if deemed too big for the
>> amalgamation,
>> but given that many things can be turned on/off in the amalgamation, that
>> would be just
>> one more IMHO.
>>
>> The goal here would be to move the "minimum expectations" of what can be
>> done with the official shell, out-of-the-box, w/o the need to resort to
>> .load of an extension which is not readily available in compiled form for
>> many non-programmer users.
>>
>> And IMHO, the ability to use math functions in views is why "moving the
>> baseline" is necessary,
>> since without those being built-in, the views will just error out in the
>> official shell.
>>
>> My $0.02, despite the upcoming chorus about lite or do-it-in-your-app
>> naysayers. Thanks, --DD
>>
>> PS: Sure SQLite's primary use case is as an *embedded* DB, so the host-app
>> can add
>> whatever it wants/needs in terms of UDFs, but I also think the
>> "standalone"
>> use of SQLite independently of the app that generated the DB file is
>> important, and we should raise the
>> bar of the minimum number of built-in functions, starting with the
>> official
>> shell.
>>
>> [1] https://www.sqlite.org/contrib/download/extension-functions.c?get=25
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Jay Kreibich


The main downside is that SQLite builds on a ton of platforms, including embedded devices.  In some cases, those platforms don’t even support floating point numbers, never mind high-level math functions.  It would add a mess of new #defs.

There used to be a standard math extension that brought in a large number of statistical math functions in a consistent way.  I’m not sure what ever happened to it, but that seems like a much better approach.

 -j





On Mar 9, 2017, at 7:49 AM, Eric Grange <[hidden email]> wrote:

> A bonus of having them defined in the core is that it avoids the minor
> inconsistencies that are bound to arise in custom implementations (starting
> with the name of math functions)
>
> Main downside is probably not going to be the size, but that it reserves
> more names, and may conflict with existing custom implementations.
>
> Eric
>
> On Thu, Mar 9, 2017 at 1:16 PM, R Smith <[hidden email]> wrote:
>
>> I second this - Been having a hard time making basic queries with a simple
>> x^y function in SQL for SQLite since there is no guarantee what the
>> end-user's system will have it compiled-in. I can version-check or
>> version-enforce easily, but compile-option check or enforce is a no-go.
>>
>> If we can shift the basic "Auto-included" feature set a few notches up, we
>> can still have hardcore minimalist users compile their own (as they
>> probably already do), but it would be nice to know a query running on a
>> standard linux or Apple OS on the included SQLite will support some wider
>> functions as a rule[1] without having to keep track. I realize this will
>> take a time to permeate through the world, but it would be great to start
>> asap.
>>
>> [1] Yes, there are threads on this same forum where I myself kicked
>> against bloating SQLite with unneeded functionality as a rule, but perhaps
>> the definition of "needed" needs revisiting. I think good math and string
>> functions certainly qualify.
>>
>> Cheers,
>> Ryan
>>
>>
>>
>> On 2017/03/09 11:45 AM, Dominique Devienne wrote:
>>
>>> I find that I'm often missing basic mathematical functions in the default
>>> shell.
>>> Many SQLite clients add many, but given that the official SQLite shell
>>> misses
>>> them you can't use them in views for predefined "reports" within the DB
>>> file itself, for example.
>>>
>>> There's [1] which is 50KB, but only a tiny part of that is for math
>>> functions, so math functions are only a few KBs away.
>>>
>>> Adding basic math functions and stddev, median, variance, etc... wouldn't
>>> add much,
>>> and they could be added to the shell at least, if deemed too big for the
>>> amalgamation,
>>> but given that many things can be turned on/off in the amalgamation, that
>>> would be just
>>> one more IMHO.
>>>
>>> The goal here would be to move the "minimum expectations" of what can be
>>> done with the official shell, out-of-the-box, w/o the need to resort to
>>> .load of an extension which is not readily available in compiled form for
>>> many non-programmer users.
>>>
>>> And IMHO, the ability to use math functions in views is why "moving the
>>> baseline" is necessary,
>>> since without those being built-in, the views will just error out in the
>>> official shell.
>>>
>>> My $0.02, despite the upcoming chorus about lite or do-it-in-your-app
>>> naysayers. Thanks, --DD
>>>
>>> PS: Sure SQLite's primary use case is as an *embedded* DB, so the host-app
>>> can add
>>> whatever it wants/needs in terms of UDFs, but I also think the
>>> "standalone"
>>> use of SQLite independently of the app that generated the DB file is
>>> important, and we should raise the
>>> bar of the minimum number of built-in functions, starting with the
>>> official
>>> shell.
>>>
>>> [1] https://www.sqlite.org/contrib/download/extension-functions.c?get=25
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

--  
Jay A. Kreibich < J A Y @ K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Keith Christian-2
In reply to this post by Eric Grange
We all know this but it bears repeating:

At some point it's time to use a different database engine or offload
to other code.  Sqlite could easily burgeon to the size of the other
databases if everything asked for was included.  Where, then, would we
get a small but still functional SQL engine?

On Thu, Mar 9, 2017 at 6:49 AM, Eric Grange <[hidden email]> wrote:

> A bonus of having them defined in the core is that it avoids the minor
> inconsistencies that are bound to arise in custom implementations (starting
> with the name of math functions)
>
> Main downside is probably not going to be the size, but that it reserves
> more names, and may conflict with existing custom implementations.
>
> Eric
>
> On Thu, Mar 9, 2017 at 1:16 PM, R Smith <[hidden email]> wrote:
>
>> I second this - Been having a hard time making basic queries with a simple
>> x^y function in SQL for SQLite since there is no guarantee what the
>> end-user's system will have it compiled-in. I can version-check or
>> version-enforce easily, but compile-option check or enforce is a no-go.
>>
>> If we can shift the basic "Auto-included" feature set a few notches up, we
>> can still have hardcore minimalist users compile their own (as they
>> probably already do), but it would be nice to know a query running on a
>> standard linux or Apple OS on the included SQLite will support some wider
>> functions as a rule[1] without having to keep track. I realize this will
>> take a time to permeate through the world, but it would be great to start
>> asap.
>>
>> [1] Yes, there are threads on this same forum where I myself kicked
>> against bloating SQLite with unneeded functionality as a rule, but perhaps
>> the definition of "needed" needs revisiting. I think good math and string
>> functions certainly qualify.
>>
>> Cheers,
>> Ryan
>>
>>
>>
>> On 2017/03/09 11:45 AM, Dominique Devienne wrote:
>>
>>> I find that I'm often missing basic mathematical functions in the default
>>> shell.
>>> Many SQLite clients add many, but given that the official SQLite shell
>>> misses
>>> them you can't use them in views for predefined "reports" within the DB
>>> file itself, for example.
>>>
>>> There's [1] which is 50KB, but only a tiny part of that is for math
>>> functions, so math functions are only a few KBs away.
>>>
>>> Adding basic math functions and stddev, median, variance, etc... wouldn't
>>> add much,
>>> and they could be added to the shell at least, if deemed too big for the
>>> amalgamation,
>>> but given that many things can be turned on/off in the amalgamation, that
>>> would be just
>>> one more IMHO.
>>>
>>> The goal here would be to move the "minimum expectations" of what can be
>>> done with the official shell, out-of-the-box, w/o the need to resort to
>>> .load of an extension which is not readily available in compiled form for
>>> many non-programmer users.
>>>
>>> And IMHO, the ability to use math functions in views is why "moving the
>>> baseline" is necessary,
>>> since without those being built-in, the views will just error out in the
>>> official shell.
>>>
>>> My $0.02, despite the upcoming chorus about lite or do-it-in-your-app
>>> naysayers. Thanks, --DD
>>>
>>> PS: Sure SQLite's primary use case is as an *embedded* DB, so the host-app
>>> can add
>>> whatever it wants/needs in terms of UDFs, but I also think the
>>> "standalone"
>>> use of SQLite independently of the app that generated the DB file is
>>> important, and we should raise the
>>> bar of the minimum number of built-in functions, starting with the
>>> official
>>> shell.
>>>
>>> [1] https://www.sqlite.org/contrib/download/extension-functions.c?get=25
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Dominique Devienne
On Thu, Mar 9, 2017 at 3:05 PM, Keith Christian <[hidden email]>
wrote:

> At some point it's time to use a different database engine or offload
> to other code.  Sqlite could easily burgeon to the size of the other
> databases if everything asked for was included.  Where, then, would we
> get a small but still functional SQL engine?


Ah, here we go again :)  I knew this was coming.

First, you can always #ifdef. Have you opened the amalgamation recently,
and seen the large parts which can be enabled or disabled?

Second, those basic math functions are no more (or less) important than the
ones shipping with SQLite right now. By your argument, SQLite should ship
with none.

Third, you must have missed the evolution of SQLite these past few years
which added large parts (FTS3|4|5, FKs, CTEs, RBU, Session, JSON1, Row
Values, etc...)
which are considerably larger than a few math functions.

Last but not least, it's trivial to not use what's there and available and
easily disabled at compiled time, or ignored at runtime.
While using what's not there, and not readily available w/o developer
skills, is considerably harder. --DD
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Dominique Devienne
In reply to this post by Jay Kreibich
On Thu, Mar 9, 2017 at 3:04 PM, Jay Kreibich <[hidden email]> wrote:

> The main downside is that SQLite builds on a ton of platforms, including
> embedded devices.  In some cases, those platforms don’t even support
> floating point numbers, never mind high-level math functions.  It would add
> a mess of new #defs.
>

As Ryan already mentioned, embedded devices already disable large parts of
the code, some even remove floating-points support, so a fortiori
double-based math functions are out-of-scope. And it doesn't need to be a
bunch of #def, 1 or 2 would be plenty.


> There used to be a standard math extension that brought in a large number
> of statistical math functions in a consistent way.  I’m not sure what ever
> happened to it, but that seems like a much better approach.
>

I'm not asking for a large number of stats functions. But the 1 or 2 dozens
we all know and use. There's min(), max(), sum() and avg() and was really
surprised not to see stddev() for example. --DD
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Dominique Devienne
In reply to this post by Eric Grange
On Thu, Mar 9, 2017 at 2:49 PM, Eric Grange <[hidden email]> wrote:

> A bonus of having them defined in the core is that it avoids the minor
> inconsistencies that are bound to arise in custom implementations (starting
> with the name of math functions)
>

Yep.


> Main downside is probably not going to be the size, but that it reserves
> more names, and may conflict with existing custom implementations.


From https://www.sqlite.org/c3ref/create_function.html:
add SQL functions or aggregates ***or to redefine*** the behavior of
existing SQL functions or aggregates

The "or to redefine" means existing host-app adding their own would trump
the new built-in ones. --DD
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

James K. Lowden
In reply to this post by Dominique Devienne
On Thu, 9 Mar 2017 10:45:36 +0100
Dominique Devienne <[hidden email]> wrote:

> I find that I'm often missing basic mathematical functions in the
> default shell.

$ sqlite3 -header <<< 'select typeof(1/0) as "how many";'
how many
null

Until SQLite deals with math as math, what is the point of adding
mathematical functions?

I would be happy to be able to use SQLite for data analysis, but we
have to get the fundamentals right first.  

--jkl

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Keith Medcalf
In reply to this post by Dominique Devienne

On Thursday, 9 March, 2017 07:30, Dominique Devienne <[hidden email]> wrote:
> On Thu, Mar 9, 2017 at 3:05 PM, Keith Christian <[hidden email]>
> wrote:
 
> > At some point it's time to use a different database engine or offload
> > to other code.  Sqlite could easily burgeon to the size of the other
> > databases if everything asked for was included.  Where, then, would we
> > get a small but still functional SQL engine?

> Ah, here we go again :)  I knew this was coming.
 
> First, you can always #ifdef. Have you opened the amalgamation recently,
> and seen the large parts which can be enabled or disabled?
 
> Second, those basic math functions are no more (or less) important than
> the ones shipping with SQLite right now. By your argument, SQLite should ship
> with none.
 
> Third, you must have missed the evolution of SQLite these past few years
> which added large parts (FTS3|4|5, FKs, CTEs, RBU, Session, JSON1, Row
> Values, etc...) which are considerably larger than a few math functions.
 
> Last but not least, it's trivial to not use what's there and available and
> easily disabled at compiled time, or ignored at runtime.
> While using what's not there, and not readily available w/o developer
> skills, is considerably harder. --DD

Well, I compile my own SQLite3 Amalgamation which includes the following extensions:

from the SQLite site:

 amatch.c carray.c closure.c compress.c csv.c eval.c
 fileio.c fuzzer.c ieee754.c nextchar.c percentile.c
 regexp.c rot13.c series.c showauth.c spellfix.c
 totype.c vfsstat.c vtshim.c wholenumber.c

but not:

sha1.c   shathree.c (and perhaps a couple more)

note that fileio.c and shathree.c are inlined into shell.c, so in order to remove them I have to modify shell.c to ifdef them out when I am building.  

Extensions to the SQLite engine should be in the SQLite3.c code, not the shell.c code.  In my opinion (and worth exactly what you are paying for it) extension functions should not be incorporated into shell.c at all, but the shell should be able to detect if they are present and adjust its behaviour accordingly, if that is desired, such as the new sha3sum dot-command.  This also avoids the issue where there is something available in the shell (such as the sha3 and fileio functions) that are not available in the corresponding DLL.

and some third-party extensions:

 unifuzz.c interpolate.c sqlite_mprint.c

plus my own extensions:

 ipaddress.c    IPv4/v6 PtoN/NtoP/Collation/SubnetMembership
 sqlautobusy.c  Automatically ensures busy_timeout
 sqlfcmp.c      Proper Floating Point comparisons and Half-Even rounding
 sqlfunc.c      A bunch of running statistical functions including proper average
 sqlfwin.c      A bunch of useful Windows API functions (GetUser/SID/translation/token membership, etc)
 sqlmath.c      The entire standard gnu math library
 sqlhash.c      md2/md4/md5/sha1hard/sha2/sha3 in pure C

The compiled size is:
32-bit versions
2017-03-08  22:01         1,623,936 SQLite3.dll
2017-03-08  22:01            94,080 SQLite3d.exe
2017-03-08  22:01         1,668,992 SQLite3s.exe

and the 64-bit version
2017-03-08  21:57         1,674,624 SQLite3.dll
2017-03-08  21:57           100,224 SQLite3d.exe
2017-03-08  21:57         1,742,720 SQLite3s.exe

which is double the size, at least, of the base SQLite3.dll (I include all the same RTREE, FTS, JSON, etc).  So adding extensions does increase the size significantly.  However, this is not going to be running on memory constrained devices either.  The APSW modules are each about 200K bigger than the base SQLite3.dll




_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Dominique Devienne
On Thu, Mar 9, 2017 at 6:05 PM, Keith Medcalf <[hidden email]> wrote:

> On Thursday, 9 March, 2017 07:30, Dominique Devienne <[hidden email]>
> wrote:
> > Last but not least, it's trivial to not use what's there and available
> and
> > easily disabled at compiled time, or ignored at runtime.
> > While using what's not there, and not readily available w/o developer
> > skills, is considerably harder. --DD
>
> Well, I compile my own SQLite3 Amalgamation which includes the following
> extensions:
>

That's a lot of extensions :).

Plus that's not what I'm proposing/asking for.
I don't want to throw the kitchen sink into the amalgamation.
Just the bare minimum (I'd be happy with just ln/log2/log10/pow/exp myself,
but a few more would seem logical). --DD
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Richard Hipp-3
In reply to this post by Keith Medcalf
On 3/9/17, Keith Medcalf <[hidden email]> wrote:
>
> note that fileio.c and shathree.c are inlined into shell.c, so in order to
> remove them I have to modify shell.c to ifdef them out when I am building.
>

Seriously?  I have no trouble loading the external fileio.c and
shathree.c extensions on top of the similar extensions that are built
into the shell.  Nothing about the shell code has to change.  What
part of that is not working for you?

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: More built-in functions for basic math

Keith Medcalf

I get complaints from the compiler about duplicate definitions of macro's and functions ...

As an aside, I am trying to walk db->aFunc as follows:

    sqlite3 *db = sqlite3_context_db_handle(context);
    Hash *h = &(db->aFunc);
    HashElem *p;
    FuncDef *d;
    char *functype;
    for (p = h->first; p; p = p->next)
    {
        d = p->data;
        functype = d->xFinalize ? "aggregate" : "scalar";
        printf("%s  %s %d %d\n", d->zName, functype, d->nArg, d->funcFlags);
        while (d->pNext)
        {
            d = d->pNext;
            functype = d->xFinalize ? "aggregate" : "scalar";
            printf("%s* %s %d %d\n", d->zName, functype, d->nArg, d->funcFlags);
        }
    }

but for functions which have both a scalar and aggregate form only the aggregate is showing up (actually, only the last version registered is showing up -- so which one shows up is scalar/aggregate is determined by which one was defined last).  

When I asked you about this you said that I simply need to register the function twice, once as an aggregate function and once as a scaler function, but it does not appear to actually keep the two different definitions.  Is this a bug or working as intended?


> -----Original Message-----
> From: sqlite-users [mailto:[hidden email]]
> On Behalf Of Richard Hipp
> Sent: Thursday, 9 March, 2017 13:08
> To: SQLite mailing list
> Subject: Re: [sqlite] More built-in functions for basic math
>
> On 3/9/17, Keith Medcalf <[hidden email]> wrote:
> >
> > note that fileio.c and shathree.c are inlined into shell.c, so in order
> to
> > remove them I have to modify shell.c to ifdef them out when I am
> building.
> >
>
> Seriously?  I have no trouble loading the external fileio.c and
> shathree.c extensions on top of the similar extensions that are built
> into the shell.  Nothing about the shell code has to change.  What
> part of that is not working for you?
>
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users