Hi Lefteris, I acknowledged that in my post yesterday (see intermediates).
I think, over time, I will understand the internals better and implement a
more performant solution. Right now, I'm just happy that it works :-).
Best, Dru
On Mon, Nov 11, 2013 at 1:04 AM, Lefteris
Hi Dru,
your solution works but it adds one more expensive operation and that will make it slower, especially when data is big. As I mentioned earlier, another solution would be to create an implementation that is oblivious of the "display differences" between an int and a decimal.
On Mon, Nov 11, 2013 at 8:01 AM, Dru Nelson
wrote: Hi,
While thinking about this in the morning yesterday, I came up with a solution. First let me explain a bit more about the challenge.
I was implementing percentile_cont for a contract project. I added the syntax to the parser. On the backend I was using dense_rank as my initial template. Because dense_rank takes ANY_1, it would receive either a flt
int BAT. I thought i had everything working great until i worked with a decimal column. Because the decimal type is just an int type scaled, and
BAT doesn't record this, I was stuck. The window function generates a result based on the values (vs dense_rank just needing to know ordinality)
My solution was to modify the AST after the parse to inject a CAST to a dbl on the OVER portion. It was not my ideal solution, since it will force an intermediate to be created for any type that isn't a double. None the less, the MAL optimizers work correctly and the function handles all types.
Best,
Dru
On Sat, Nov 9, 2013 at 8:22 AM, Lefteris
wrote: I second that! Are you sure that you cannot come up with an alternative algorithm for your aggregation that does not need this information (and possibly be faster) ?
On Sat, Nov 9, 2013 at 11:26 AM, Stefan Manegold <
Stefan.Manegold@cwi.nl>
wrote:
Hi Dru,
the decimal scale information is only maintained in the SQL catalog and given that decimals are stored as integers in MonetDB, neither the MonetDB kernel, nor MAL usually need to know about decimals or their scale.
Hence, the question is, whether/why your aggregate functions would need to know about decimals or their scale?
Best, Stefan
Dru Nelson
wrote: HI,
I"m working on writing an aggregate in in C that is a MAL function. I've run into a problem with decimal types.
I've noticed that when I inspect the BAT inputs for various types,
or the they
are coerced to simpler types. (flt,dbl -> dbl). (int, decimal -> int). There is also no other information in the BAT structure to see the type.
I notice that a SQL select gets the type info passed in as parameters for the 'exportValue' output.
For example:
sql.exportValue(1,".","second_single_value","decimal",9,3,8,_4,"");
How can I get this type information ('decimal', etc.) passed into my function?
Dru
________________________________
developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
-- | Stefan.Manegold@CWI.nl | Database Architectures (DA) | | www.CWI.nl/~manegold | Science Park 123 (L321) | | +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list