[jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635958#comment-16635958
]
Benedict edited comment on CASSANDRA-11935 at 10/2/18 7:04 PM:
---
Perhaps, and perhaps this contributed to being perceived as harsh - and I am
very sorry for the opening of this discussion to have been perceived that way.
I'm hoping to follow up with a meta discussion about how we approach this
category of feature in future, so we can have a clearer definition of 'done' to
avoid this confusion in future.
was (Author: benedict):
Perhaps, and perhaps this contributed to being perceived as harsh - and I am
very sorry for the opening of this discussion to have been perceived that way.
I'm hoping to follow up with a meta discussion about how we approach this
category of feature in future, so we can have a clearer definition of 'done' -
and perhaps I jumped the gun on that.
If the community _does_ decide the feature should be changed before release, I
do think this is the right place for the follow-up to live.
> Add support for arithmetic operators
>
>
> Key: CASSANDRA-11935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Benjamin Lerer
>Priority: Major
> Fix For: 4.0
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep
> the scope as small as possible. Dates and string operations will be adressed
> in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are
> performed on different types (e.g. double + int).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635208#comment-16635208
]
Benedict edited comment on CASSANDRA-11935 at 10/2/18 9:38 AM:
---
bq. CQL is strongly typed and it has its consequences good and bad
The only requirement of strong typing here is that the behaviour is well
defined. It could upcast to a type that can store both of the operands, if we
wanted.
This behaviour is obviously database dependent. PostgreSQL, for example,
performs only lossless conversions by default - with the only implicit cast for
numbers being to their equivalent of {{decimal}} (i.e. {{numeric}} -
[link|https://www.postgresql.org/docs/current/static/sql-createcast.html])
For a database, I personally prefer this default behaviour, as it is less
surprising. We don't need extreme efficiency for these operations, since we
are incredibly inefficient elsewhere. The costs of casting and evaluating a
more precise answer are low relative to our other costs, so I don't see the
value proposition of truncating values for the user.
bq. Implementing it this way was a conscious decision.
Ok, but this is a fairly important semantic decision for the project, and you
didn't bring this up for wider discussion. So while you may have intended it,
I think the project as a whole needs to endorse this semantic before we set it
in stone with the 4.0 GA.
was (Author: benedict):
bq. CQL is strongly typed and it has its consequences good and bad
The only requirement of strong typing here is that the behaviour is well
defined. It could upcast to a type that can store both of the operands, if we
wanted.
This behaviour is obviously database dependent. PostgreSQL, for example,
performs only lossless conversions by default - with the only implicit cast for
numbers being to their equivalent of {{decimal}} ({{numeric}})
[link|https://www.postgresql.org/docs/current/static/sql-createcast.html]
For a database, I personally prefer this default behaviour, as it is less
surprising. We don't need extreme efficiency for these operations, since we
are incredibly inefficient elsewhere. The costs of casting and evaluating a
more precise answer are low relative to our other costs, so I don't see the
value proposition of truncating values for the user.
bq. Implementing it this way was a conscious decision.
Ok, but this is a fairly important semantic decision for the project, and you
didn't bring this up for wider discussion. So while you may have intended it,
I think the project as a whole needs to endorse this semantic before we set it
in stone with the 4.0 GA.
> Add support for arithmetic operators
>
>
> Key: CASSANDRA-11935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Major
> Fix For: 4.0
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep
> the scope as small as possible. Dates and string operations will be adressed
> in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are
> performed on different types (e.g. double + int).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16634224#comment-16634224
]
Benedict edited comment on CASSANDRA-11935 at 10/1/18 4:13 PM:
---
bq. Stuff involving floats or doubles is lossy
This is untrue. Only *some* things involving floats and doubles are lossy.
Integer additions/subtractions (and divisions with integer results, and some
real results) on values smaller than the significand's precision are lossless,
for instance. This means that if for {{float + int}} we used {{double}} the
operation would not be inherently lossy - in fact for a wide range of values
this would be lossless (not just integer operations). Similarly for a {{double
+ bigint}} and {{decimal}}.
The most surprising part of this behaviour, however, is that simply adding
{{0.0f}} to any value greater than {{2^24}} will result in an answer that has
changed for no readily apparent reason. The integer is immediately truncated
to its nearest float value, which is incapable of representing it.
FWIW, it might be that we are OK with this imprecision, but we should at least
consider the behaviour, and then document it clearly.
was (Author: benedict):
bq. Stuff involving floats or doubles is lossy
This is untrue. Only *some* things involving floats and doubles are lossy.
Integer operations on values smaller than the significand's precision are
lossless, for instance. This means that if for {{float + int}} we used
{{double}} the operation would not be inherently lossy - in fact for a wide
range of values this would be lossless (not just integer operations).
Similarly for a {{double + bigint}} and {{decimal}}.
The most surprising part of this behaviour, however, is that simply adding
{{0.0f}} to any value greater than {{2^24}} will result in an answer that has
changed for no readily apparent reason. The integer is immediately truncated
to its nearest float value, which is incapable of representing it.
FWIW, it might be that we are OK with this imprecision, but we should at least
consider the behaviour, and then document it clearly.
> Add support for arithmetic operators
>
>
> Key: CASSANDRA-11935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Major
> Fix For: 4.0
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep
> the scope as small as possible. Dates and string operations will be adressed
> in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are
> performed on different types (e.g. double + int).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16634094#comment-16634094
]
Jeremiah Jordan edited comment on CASSANDRA-11935 at 10/1/18 2:50 PM:
--
Stuff involving floats or doubles is lossy. Is it any more lossy than use of
floats in general? What behavior do you think we should have? I think this is
more desirable than just throwing an exception and forcing people to add casts,
as this is the cast they would add for the best resolution, and there are other
worse ways you could add casts.
was (Author: jjordan):
Any math involving floats or doubles is lossy. Is it any more lossy than
float+float=float or double+double=double? What behavior do you think we
should have? I think this is more desirable than just throwing an exception
and forcing people to add casts, as this is the cast they would add for the
best resolution, and there are other worse ways you could add casts.
> Add support for arithmetic operators
>
>
> Key: CASSANDRA-11935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Major
> Fix For: 4.0
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep
> the scope as small as possible. Dates and string operations will be adressed
> in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are
> performed on different types (e.g. double + int).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933128#comment-15933128
]
T Jake Luciani edited comment on CASSANDRA-11935 at 3/20/17 6:27 PM:
-
There is a issue with this ticket as it changes the serialization format of
Shorts from variable width to fixed. This needs to be captured in the
MessageService, CommitLog, and SSTable versions so we can properly upgrade
clusters to 4.0
was (Author: tjake):
There is a issue with this ticket as it changes the serialization format of
Shorts from variable width to fixed. This needs to be captured in the Message
service and disk version so we can properly upgrade clusters to 4.0
> Add support for arithmetic operators
>
>
> Key: CASSANDRA-11935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 4.0
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep
> the scope as small as possible. Dates and string operations will be adressed
> in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are
> performed on different types (e.g. double + int).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15676926#comment-15676926
]
Benjamin Lerer edited comment on CASSANDRA-11935 at 11/18/16 3:15 PM:
--
bq. So 100+50 is now going to be varint math?
No, :-)
If you have {{SELECT 100 + 50 ...}} the result will be an {{int}}. The patch
narrow down the type up to the {{int}} level. If a literal can fit in an
{{int}} C* will try to use the {{int}} type for the litteral. If it cannot fit
in an {{int}}, C* will use {{bigint}} or {{varint}} for the literal value.
Depending in which type it can fit in. The output type will then be the one of
the type with the higher precision. If the left operand is fitting in a
{{bigint}} and the right one in an {{int}} the result type will be a {{bigint}}.
The discussion was about the case where you have {{... WHERE pk = 1 + 1}} and
where pk is a {{smallint}} for example.
bq. It's more of a general remark that having intersecting and pretty special
rules doesn't give me the feel of a clean and well understood type system,
which give me slight concerns that some of those rules may prove annoying in
future developments.
This rule is at the end of the chain and is only used for operators. By
consequence, I hope, that if at some point, we have a better alternative, we
will be able to replace it without too much difficulties.
was (Author: blerer):
bq. So 100+50 is now going to be varint math?
No, :-)
If you have {{SELECT 100 + 50 ...}} the result will be an {{int}}. The patch
narrow down the type up to the {{int}} level. If a literal can fit in an
{{int}} C* will try to use the {{int}} type for the litteral. If it cannot fit
in an int C* will use {{bigint}} or {{varint}} for the literal value depending
in which type it can fit in. The output type will then be the one of the type
with the higher precision. So if the left operand is fitting in a {{bigint}}
and the right one in an {{int}} the result type will be a {{bigint}}.
The all discussion is about the case where you have {{... WHERE pk = 1 + 1}}
and where pk is a {{smallint}} for example.
bq. It's more of a general remark that having intersecting and pretty special
rules doesn't give me the feel of a clean and well understood type system,
which give me slight concerns that some of those rules may prove annoying in
future developments.
This rule is at the end of the chain and is only used for operators. By
consequence, I hope that if, at some point, we have a better alternative, we
will be able to replace it without too much difficulties.
> Add support for arithmetic operators
>
>
> Key: CASSANDRA-11935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep
> the scope as small as possible. Dates and string operations will be adressed
> in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are
> performed on different types (e.g. double + int).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310803#comment-15310803
]
Sylvain Lebresne edited comment on CASSANDRA-11935 at 6/1/16 6:19 PM:
--
I don't believe in doing something for CQL because SQL does it and in
particular, SQL allows pretty complicated query that we will never allow in CQL
and don't want, which imply some things are less justified in CQL. We also tend
to favor explicitness in C*/CQL.
Also, the fact we've recently added specific *explicit* syntax for such
conversion (CASSANDRA-10310) and are now saying some of it should be implicit
make me worry that we're adding stuff to the type system without a good idea of
the big picture.
Overall, I'm not convinced that _in CQL_ there will so many case where such
implicit conversion will be useful to justify adding their magic. But at the
very least, I'm pretty sure we can go far enough with operators without it and
so discussing their addition should be left to another ticket (besides, such
implicit conversions are not really specific to operators).
was (Author: slebresne):
I don't believe in doing something for CQL because SQL does it and in
particular, SQL allows pretty complicated query that we will never allow in CQL
and don't want, which imply some things are less justified in CQL. We also tend
to favor explicitness in C*/CQL. Overall, I'm not entirely that such implicit
conversions
and that justify some differences. We can certainly draw inspiration from SQL
when it make sense, but stuffs needs to be justified *for* CQL. Among other
things, we tend to favor explicitness in C*/CQL over saving a few character in
typing, and I happen to think it's a good idea. Also, the fact we've recently
added specific *explicit* syntax for such conversion (CASSANDRA-10310) and are
now saying some of it should be implicit make me worry that we're adding stuff
to the type system without a good idea of the big picture, and that worries me.
Overall, I'm not convinced that _in CQL_ there will so many case where such
implicit conversion will be necessary to justify adding their magic, but at the
very least, I'm pretty sure we can go far enough with operators without it and
so discussing their addition should be left to another ticket (besides, such
implicit conversions are not really specific to operators).
> Add support for arithmetic operators
>
>
> Key: CASSANDRA-11935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep
> the scope as small as possible. Dates and string operations will be adressed
> in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are
> performed on different types (e.g. double + int).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
