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 or 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 the 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 <lsidir@gmail.com> 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 <drudru@gmail.com> 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, 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