Re: Implicit Casts for Arithmetic Operators

Thanks for laying this out, this really helps me respond to at least some of your concerns. Firstly, I’d like to clarify that my position is only a personal one - I don’t expect the project, or you, to necessarily have the same viewpoint. But it does mean that I don’t have to engage too closel

Re: Implicit Casts for Arithmetic Operators

> Anyway, I think we’ve been arguing very unnecessarily about this ideological > point, given that I’ve already suggested a toggle to permit users to continue > with present-day semantics should they choose. Surely this resolves your > concerns, unless you think this is intractable? Not really :)

Re: RES: RES: Implicit Casts for Arithmetic Operators

To clarify send an empty email (no subject or body) to  dev-unsubscr...@cassandra.apache.org You will then get a confirmation email with a link. Click that. Dinesh On Tuesday, November 20, 2018, 6:20:34 PM GMT+2, Michael Shuler wrote: On 11/20/18 10:15 AM, Versátil wrote: > > I alread

Re: Implicit Casts for Arithmetic Operators

This was a terribly unclear email, sorry. I was just trying to find new and interesting ways to say the same thing (that we should form our goal state from first principles only). Anyway, I think we’ve been arguing very unnecessarily about this ideological point, given that I’ve already sugges

Re: Implicit Casts for Arithmetic Operators

This is why I said the decision is ideological. We fundamentally disagree with each other, on points of principle. This also feels like it’s becoming antagonistic, perhaps through misinterpreting each other, which was far from my intent. So I will limit my reply to the only point of interpret

Re: Implicit Casts for Arithmetic Operators

On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith wrote: > We’re not presently voting*; we’re only discussing, whether we should base > our behaviour on a widely agreed upon standard. > Well, you *explicitely* asked if people though we should do a vote, and I responded to that part. Let's

Re: Implicit Casts for Arithmetic Operators

Well, to expand my glib statement, standards exist for at least two reasons that I endorse in this case: 1) They are well thought out, with a great deal more consideration than we have time to give to a problem 2) They are widely implemented, understood and used. So our users and developers ha

Re: Implicit Casts for Arithmetic Operators

Sorry, following a standard for the sake of following a standard does not make sense to me. On Thu, Nov 22, 2018 at 12:33 PM Benedict Elliott Smith wrote: > Yes. > > > On 22 Nov 2018, at 11:32, Benjamin Lerer > wrote: > > > > Then I would be interested in knowing `where we should be`. If the an

Re: Implicit Casts for Arithmetic Operators

Yes. > On 22 Nov 2018, at 11:32, Benjamin Lerer wrote: > > Then I would be interested in knowing `where we should be`. If the answer > is `ANSI SQL92` then my question is: Why? Simply for the sake of following > a standard? > > > On Thu, Nov 22, 2018 at 12:19 PM Benedict Elliott Smith

Re: Implicit Casts for Arithmetic Operators

Then I would be interested in knowing `where we should be`. If the answer is `ANSI SQL92` then my question is: Why? Simply for the sake of following a standard? On Thu, Nov 22, 2018 at 12:19 PM Benedict Elliott Smith wrote: > As I say, for me this is explicitly unhelpful, so I have no intention

Re: Implicit Casts for Arithmetic Operators

As I say, for me this is explicitly unhelpful, so I have no intention of producing it (though, of course, I cannot prevent you from producing it) For me, the correct approach is to decide where we should be, and then figure out how to get there. Where we are has no bearing on where we should be

Re: Implicit Casts for Arithmetic Operators

I would also like to see an analysis of what being ANSI SQL 92 compliant means in term of change of behavior (for arithmetics and *any features we have already released*). Simply because without it, I find the decision pretty hard to make. On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith w

Re: Implicit Casts for Arithmetic Operators

We’re not presently voting*; we’re only discussing, whether we should base our behaviour on a widely agreed upon standard. I think perhaps the nub of our disagreement is that, in my view, this is the only relevant fact to decide. There is no data to base this decision upon. It’s axiomatic, or

Re: Implicit Casts for Arithmetic Operators

I'm not saying "let's not do this no matter what and ever fix technical debt", nor am I fearing decision. But I *do* think decisions, technical ones at least, should be fact and data driven. And I'm not even sure why we're talking of having a vote here. The Apache Way is *not* meant to be primaril

Re: Implicit Casts for Arithmetic Operators

I can’t agree more. We should be able to make changes in a manner that improves the DB In the long term, rather than live with the technical debt of arbitrary decisions made by a handful of people. I also agree that putting a knob in place to let people migrate over is a reasonable decision. Jon

Re: Implicit Casts for Arithmetic Operators

The goal is simply to agree on a set of well-defined principles for how we should behave. If we don’t like the implications that arise, we’ll have another vote? A democracy cannot bind itself, so I never understood this fear of a decision. A database also has a thousand toggles. If we absolu

Re: Implicit Casts for Arithmetic Operators

On Tue, Nov 20, 2018 at 5:02 PM Benedict Elliott Smith wrote: > FWIW, my meaning of arithmetic in this context extends to any features we > have already released (such as aggregates, and perhaps other built-in > functions) that operate on the same domain. We should be consistent, after > all. >

Re: RES: RES: Implicit Casts for Arithmetic Operators

On 11/20/18 10:15 AM, Versátil wrote: > > I already requested as you said and it did not help. And I NEVER asked to > enter into this discussion. Please request to withdraw my email | | | | | | | | | | \/\/\/\/\/\/\/\/\/\/ > > -

RES: RES: Implicit Casts for Arithmetic Operators

2018 14:12 Para: dev@cassandra.apache.org Cc: dev-unsubscribe-versatil=versatilengenharia.com...@cassandra.apache.org Assunto: Re: RES: Implicit Casts for Arithmetic Operators On 11/20/18 9:53 AM, Versátil wrote: > > PLEASE TAKE MY EMAIL FROM THIS SHIT !! FYI, mailing list subscription

Re: RES: Implicit Casts for Arithmetic Operators

On 11/20/18 9:53 AM, Versátil wrote: > > PLEASE TAKE MY EMAIL FROM THIS SHIT !! FYI, mailing list subscriptions (and unsubscriptions) are self-serve. In general, you subscribed yourself, so you are responsible to unsubscribe. The email address to do so is appended to every plain text message to t

Re: Implicit Casts for Arithmetic Operators

FWIW, my meaning of arithmetic in this context extends to any features we have already released (such as aggregates, and perhaps other built-in functions) that operate on the same domain. We should be consistent, after all. Whether or not we need to revisit any existing functionality we can fig

RES: Implicit Casts for Arithmetic Operators

PLEASE TAKE MY EMAIL FROM THIS SHIT !! -Mensagem original- De: Michael Burman [mailto:y...@iki.fi] Enviada em: terça-feira, 20 de novembro de 2018 13:51 Para: dev@cassandra.apache.org Assunto: Re: Implicit Casts for Arithmetic Operators Yep, that's a good approach. - Micke O

Re: Implicit Casts for Arithmetic Operators

Yep, that's a good approach. - Micke On Tue, Nov 20, 2018 at 5:12 PM Ariel Weisberg wrote: > Hi, > > +1 > > This is a public API so we will be much better off if we get it right the > first time. > > Ariel > > > On Nov 16, 2018, at 10:36 AM, Jonathan Haddad wrote: > > > > Sounds good to me.

Re: Implicit Casts for Arithmetic Operators

Hi, +1 This is a public API so we will be much better off if we get it right the first time. Ariel > On Nov 16, 2018, at 10:36 AM, Jonathan Haddad wrote: > > Sounds good to me. > > On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith > wrote: > >> So, this thread somewhat petered out. >

Re: Implicit Casts for Arithmetic Operators

Sounds good to me. On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith wrote: > So, this thread somewhat petered out. > > There are still a number of unresolved issues, but to make progress I > wonder if it would first be helpful to have a vote on ensuring we are ANSI > SQL 92 compliant for o

Re: Implicit Casts for Arithmetic Operators

So, this thread somewhat petered out. There are still a number of unresolved issues, but to make progress I wonder if it would first be helpful to have a vote on ensuring we are ANSI SQL 92 compliant for our arithmetic? This seems like a sensible baseline, since we will hopefully minimise surp

Re: Implicit Casts for Arithmetic Operators

I think we do, implicitly, support precision and scale - only dynamically. The precision and scale are defined by the value on insertion, i.e. those necessary to represent it exactly. During arithmetic operations we currently truncate to decimal128, but we can (and probably should) change this

Re: Implicit Casts for Arithmetic Operators

Hi, >From reading the spec. Precision is always implementation defined. The spec >specifies scale in several cases, but never precision for any type or >operation (addition/subtraction, multiplication, division). So we don't implement anything remotely approaching precision and scale in CQL wh

Re: Implicit Casts for Arithmetic Operators

If it’s in the SQL spec, I’m fairly convinced. Thanks for digging this out (and Mike for getting some empirical examples). We still have to decide on the approximate data type to return; right now, we have float+bigint=double, but float+int=float. I think this is fairly inconsistent, and eith

Re: Implicit Casts for Arithmetic Operators

Hi, I agree with what's been said about expectations regarding expressions involving floating point numbers. I think that if one of the inputs is approximate then the result should be approximate. One thing we could look at for inspiration is the SQL spec. Not to follow dogmatically necessaril

Re: Implicit Casts for Arithmetic Operators

Hi, I'm not sure if I would prefer the Postgres way of doing things, which is returning just about any type depending on the order of operators. Considering it actually mentions in the docs that using numeric/decimal is slow and also multiple times that floating points are inexact. So doing some m

Re: Implicit Casts for Arithmetic Operators

As far as I can tell we reached a relatively strong consensus that we should implement lossless casts by default? Does anyone have anything more to add? Looking at the emails, everyone who participated and expressed a preference was in favour of the “Postgres approach” of upcasting to decimal f

Re: Implicit Casts for Arithmetic Operators

I think you're conflating two things here. There's the loss resulting from using some operators, and loss involved in casting. Dividing an integer by another integer to obtain an integer result can result in loss, but there's no implicit casting there and no loss due to casting. Casting an integer

Re: Implicit Casts for Arithmetic Operators

Hi, I would like to try to clarify things a bit to help people to understand the true complexity of the problem. The *float *and *double *types are inexact numeric types. Not only at the operation level. If you insert 676543.21 in a *float* column and then read it, you will realize that the valu

Re: Implicit Casts for Arithmetic Operators

Thanks for starting this discussion. I’m definitely in the lossless camp. I’m curious of the performance impact of choosing lossless vs lossy. Dinesh > On Oct 2, 2018, at 10:54 AM, Benedict Elliott Smith > wrote: > > I agree, in broad strokes at least. Interested to hear others’ positions. >

Re: Implicit Casts for Arithmetic Operators

+1 on Postgres approach. In the last 5 years I’ve seen people move from Oracle and SQL server to some variant of Cassandra or Postgres and other new tech is also more likely to support Postgres (Cockroach..) I don’t care either way. It really depends on what you are storing. Rahul Singh Chief E

Re: Implicit Casts for Arithmetic Operators

Thanks for bringing this up, it definitely needs to be discussed. Last surprise is difficult here, since all major databases have their own way of doing things and people will just assume that their way is the right way. On that note, some people will be surprised no matter what we do. I'd rathe

Re: Implicit Casts for Arithmetic Operators

I agree, in broad strokes at least. Interested to hear others’ positions. > On 2 Oct 2018, at 16:44, Ariel Weisberg wrote: > > Hi, > > I think overflow and the role of widening conversions are pretty linked so > I'll continue to inject that into this discussion. Also overflow is much > wor

Re: Implicit Casts for Arithmetic Operators

Hi, I think overflow and the role of widening conversions are pretty linked so I'll continue to inject that into this discussion. Also overflow is much worse since most applications won't be impacted by a loss of precision when an expression involves an int and float, but will care quite a bit

Re: Implicit Casts for Arithmetic Operators

This (overflow) is an excellent point, but this also affects aggregations which were introduced a long time ago. They already inherit Java semantics for all of the relevant types (silent wrap around). We probably want to be consistent, meaning either changing aggregations (which incurs a cost

Re: Implicit Casts for Arithmetic Operators

Hi, I think we should decide based on what is least surprising as you mention, but isn't overridden by some other concern. It seems to me the priorities are * Correctness * Performance * User visible complexity * Developer visible complexity Defaulting to silent implicit data loss is not ideal

Implicit Casts for Arithmetic Operators

CASSANDRA-11935 introduced arithmetic operators, and alongside these came implicit casts for their operands. There is a semantic decision to be made, and I think the project would do well to explicitly raise this kind of question for wider input before release, since the project is bound by the