Hi Stefan, yep, makes sense. I think monetdb is a clean architecture designed for performance. Thanks for your responses. Dru


On Mon, Nov 11, 2013 at 12:06 AM, Stefan Manegold <Stefan.Manegold@cwi.nl> wrote:
Hi Dru,

it's good to know that your solution works for you ;-)

My point was just for the records to explain the intentions
and specifics of our decimal implementation. In fact, in this
line, we never had the need to know the scale information in
MAL; at the end, the position of the decimal point is only
relevant to the human user; the MonetDB kernel and the CPU do
not (need to) know about any related semantics.

Best,
Stefan

----- Original Message -----
> Hi Stefan,
>
> Thanks.
>
> I don't use the int type anymore. MAL recognizes the CAST and coverts the
> OVER clauses to dbl.
>
> Also, at the MAL implementation level, in C, this scale info was not present.
> I think that is fine. I recognize that SQL was added to the engine and that
> BAT structures are essentially a different system.
>
> Best,
>
> Dru
>
>
> On Sun, Nov 10, 2013 at 11:12 PM, Stefan Manegold < Stefan.Manegold@cwi.nl >
> wrote:
>
>
> Hi Dru,
>
> please be aware that decimal are essential integers --- just the decimal
> point is shifted;
> however, it's shifted identically for all values in a BAT; i.e., if your
> decimal(9,4) column
> holds, say, values between 1.1 and 6789.1234, the underlying BAT holds
> integer values between
> 11000 and 67891234; thus, both ordinality and relative ratios are maintained.
>
> Best,
> Stefan
>
> ----- Original Message -----
> >
> > 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
> >
> >
> > _______________________________________________
> > developers-list mailing list
> > developers-list@monetdb.org
> > https://www.monetdb.org/mailman/listinfo/developers-list
> >
>
> --
> | Stefan.Manegold@CWI.nl | DB 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
>

--
| Stefan.Manegold@CWI.nl | DB 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