[deleted]
Stochastic gradient descent written in SQL
81–90 of 187 posts
Re: Stochastic gradient descent written in SQL
#82>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL. First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powe…
Self-proclaimed database expert here. What a database is good at depends on what you're trying to get that database to do, at least in part.
Take it into piecess, elegance and efficiency. These will correspond to a logical statement of what you're trying to do, and how quickly the database will actually do it in practice.
SQL can do some nice things in areas, making it elegant in those areas. Elsewhere it can be pretty wordy and ugly.
In efficiency, it comes down largely to how the database is implemented and that also includes the capability of the optimiser. Both of these are out of your control. In my experience trying to turn a database into a number cruncher is just not going to work.
I guess that's long way round of me saying that I don't think I agree with you!
Re: Stochastic gradient descent written in SQL
#83Earlier quoted context omitted.
Basically, but queries are not first class in SQL. You can't assign a query to a variable, or pass it as a parameter to a stored procedure, for example. This would make SQL composable: declare @x = (select * from Person) select Name from @x where Birthdate
Exactly since it declarative the style Lends itself using stored procedure calls to become composable
Furthermore, stored procedures/functions are not queries.
Re: Stochastic gradient descent written in SQL
#84>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL. First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powe…
A dbms is really it's own operating system, usually this is hosted on another operating system, one that understands the hardware.
I remember one place I worked where we had several old graybeard programmers who considered the dbms[1] the operating system, as a unix sysadmin we had some interesting discussions as I was always confused and confined by the dbms and they felt the same about unix.
1. unidata if curious, a weird multi value(not relational) database, very vertically integrated compared to most databases today.
Re: Stochastic gradient descent written in SQL
#85Earlier quoted context omitted.
with persons as (select * from Person) select Name from persons where Birthdate
Where is the assignment to a variable? Where can you construct a query using a variable in table/query position? That's the whole point of being first class and composable, a query becomes like any other value so you should be able to parameterize any query by another query assigned to a variable that may have been set inside an if-statement, or accepted as a parameter to a stored procedure. You know, the same kinds…
create table x as (select * from person);
select name from x where ...;
or even a version with lazy evaluation:
create view x as (select * from person);
select name from x where ...;Re: Stochastic gradient descent written in SQL
#86Title here is wrong. Title in article and headings in article are right: ONLINE gradient descent
It's specifically not stochastic. From the article:
Online gradient descent
Finally, we have enough experience to implement online gradient descent. To keep things simple, we will use a very vanilla version:
- Constant learning rate, as opposed to a schedule.
- Single epoch, we only do one pass on the data.
- Not stochastic: the rows are not shuffled. ⇠ ⇠ ⇠ ⇠
- Squared loss, which is the standard loss for regression.
- No gradient clipping.
- No weight regularisation.
- No intercept term.
Re: Stochastic gradient descent written in SQL
#87Incredible post. I laughed when I saw the title, snickered at the first paragraph, and then proceeded to be blown away by the rest of it. Thought I was in for a joke and instead I'm thinking about the nature of ML Ops and what it's become.
Re: Stochastic gradient descent written in SQL
#88In the comments here so far, we see a pattern we've seen before. When someone suggests doing something in SQL, there's a lot of concern about SQL being a very limited programming language where it's hard to do proper engineering. Here's I would really love to know: why is it that SQL is, to first order, the only language used to interact with databases, and SQL has about the same features as it did in the 70s? It see…
> why is it that SQL is, to first order, the only language used to interact with databases, and SQL has about the same features as it did in the 70s?
Because SQL is effectively a domain-specific language. If you added 100+ additional keywords/functions/etc., do you think it would be easier or more difficult for the average developer to build something clean with it?
I look at SQL like a pile of bricks. You don't want complicated, unicorn bricks or you won't be able to fit anything meaningful together. Experienced masons almost certainly prefer their materials to be as dumb and consistent as possible.
Re: Stochastic gradient descent written in SQL
#89Earlier quoted context omitted.
Exactly since it declarative the style Lends itself using stored procedure calls to become composable
Furthermore, stored procedures/functions are not queries.
Stored procedures can be relations. Queries are relations. Ergo, stored procedures can be queries.