Я чего то не понимаю?

select 20.0 / -2.0 / 5.0 * 3.0
select 20.0 / (-2.0) / 5.0 * 3.0

-16.666666
-6.00000

Здравствуйте, haba_haba_haba, Вы писали:

__>Я чего то не понимаю?

__>

__>select 20.0 / -2.0 / 5.0 * 3.0
__>select 20.0 / (-2.0) / 5.0 * 3.0

__>

__>-16.666666
__>-6.00000

В mysql и psql (клиент postgresql) в обоих случаях ответ "-6"

Здравствуйте, haba_haba_haba, Вы писали:

__>Я чего то не понимаю?

__>

__>select 20.0 / -2.0 / 5.0 * 3.0
__>select 20.0 / (-2.0) / 5.0 * 3.0

__>

__>-16.666666
20/((-2/5.)*3)

__>-6.00000
(20/(-2.))/5)*3

Парсер не правильно SQL-запрос разобрал видимо, думаю на стороне сервера. Такие строчки в коде лучше со скобками писать, более читаем будет.

Здравствуйте, Crackjack, Вы писали:

C>Здравствуйте, haba_haba_haba, Вы писали:

__>>Я чего то не понимаю?

__>>

__>>select 20.0 / -2.0 / 5.0 * 3.0
__>>select 20.0 / (-2.0) / 5.0 * 3.0

__>>

__>>-16.666666
C>20/((-2/5.)*3)

__>>-6.00000
C>(20/(-2.))/5)*3
Понятно как получился такой результат, не понятно почему компания с огромным опытом разработки языков программирования не смогла сделать нормальный парсер для одного из своих флагманских продуктов.

В том же экселе результат адекватный...


C>Парсер не правильно SQL-запрос разобрал видимо, думаю на стороне сервера. Такие строчки в коде лучше со скобками писать, более читаем будет.

В итоге скобками и сделал.

Здравствуйте, haba_haba_haba, Вы писали:

__> не понятно почему компания с огромным опытом разработки языков программирования не смогла сделать нормальный парсер для одного из своих флагманских продуктов.

Потому что люки круглые.

никогда с таким не сталкивался.
хотя, может и сталкивался, но у же забыл, т.к. есть дурная привычка самостоятельно скобки расставлять.

блин, я даже приоритета операций не помню...

Здравствуйте, Философ, Вы писали:

Ф>никогда с таким не сталкивался.
Ф>хотя, может и сталкивался, но у же забыл, т.к. есть дурная привычка самостоятельно скобки расставлять.

Ф>блин, я даже приоритета операций не помню...

Операции с одинаковым приоритетом — по порядку слева направо.

А тут унарный минус все им испортил.

Здравствуйте, Философ, Вы писали:

Ф>блин, я даже приоритета операций не помню...

Достаточно помнить что он может быть разный и нафтыкать скобок по фкусу

Здравствуйте, haba_haba_haba, Вы писали:

__>

__>select 20.0 / -2.0 / 5.0 * 3.0
__>select 20.0 / (-2.0) / 5.0 * 3.0

__>

__>-16.666666
__>-6.00000

По какой-то загадочной причине приоритет унарных плюса и минуса сделан в Transact-SQL таким же, как и у бинарных, т. е. ниже чем у умножения и деления. Это поведение задокументировано.

Здравствуйте, achp, Вы писали:

A>По какой-то загадочной причине приоритет унарных плюса и минуса сделан в Transact-SQL таким же, как и у бинарных, т. е. ниже чем у умножения и деления. Это поведение задокументировано.

Видимо, для поддержки натуральных дробей

Здравствуйте, haba_haba_haba, Вы писали:

__>Я чего то не понимаю?

Я вот тоже прям щас ничего не понял, только про мускуль: запрос

select * from table where integer_field = 'asdasdas'

выбирает все записи, т.е. условие всегда даёт true на нечисловых данных. В то же время

select 1111 = 'asdasd'

возвращает 0.
Поди пойми этих индусов...

Здравствуйте, mucks, Вы писали:

M>Потому что люки круглые.

потому что философы на обеде

A>По какой-то загадочной причине приоритет унарных плюса и минуса сделан в Transact-SQL таким же, как и у бинарных, т. е. ниже чем у умножения и деления. Это поведение задокументировано.

это старый баг с 7 версии. каждые пару лет очередной дев его обнаруживает

2005 год
2008 год

ответ парня из мс (2005 год):

Thank you for the report. This is a known bug that was found very late in the product cycle. At the time, we couldn't think of any repros where it would affect anything other than rounding at the time, but obviously we missed this one. Because of the late date and the requirement for difficult compat work to fix this in the current product but maintain the old behavior in compat mode, we decided to postpone it. I agree that it needs to be fixed since the behavior is very unintuitive, but the fix would be a breaking change that's not suitable for a service pack. It's unfortunate and very surprising to everyone who stumbles across it, but it's actually been this way since 7.0. This is on the radar and will hopefully be fix early in Katmai development.

Jerry
jweiler@microsoft.com
SQL Server Engine Development

Здравствуйте, alexlz, Вы писали:

A>Здравствуйте, haba_haba_haba, Вы писали:

__>>Я чего то не понимаю?

__>>

__>>select 20.0 / -2.0 / 5.0 * 3.0
__>>select 20.0 / (-2.0) / 5.0 * 3.0

__>>

__>>-16.666666
__>>-6.00000

A>В mysql и psql (клиент postgresql) в обоих случаях ответ "-6"

B Oracle тоже в обоих случаях "-6"

Здравствуйте, haba_haba_haba, Вы писали:

__>Понятно как получился такой результат, не понятно почему компания с огромным опытом разработки языков программирования не смогла сделать нормальный парсер для одного из своих флагманских продуктов.

Потому что это компания с огромным опытом разработки языков программирования до сих пор пишет парсеры руками.

Здравствуйте, haba_haba_haba, Вы писали:

__>Я чего то не понимаю?

__>

__>select 20.0 / -2.0 / 5.0 * 3.0
__>select 20.0 / (-2.0) / 5.0 * 3.0

__>

__>-16.666666
__>-6.00000

Оракл(ибо под рукой) -6 для обоих вариантов.

Здравствуйте, haba_haba_haba, Вы писали:

__>Я чего то не понимаю?

Да.