Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
well,
money
datatype is specific to Postgres and generally used for output, but not for storing financial data:a) due to implicit rounding that it does - which can lead to unexpected results during arithmetic operations
b) it is closely tied to the locale settings of the PostgreSQL server, which determine formatting (like the currency symbol and comma/decimal point usage).
c)
decimal
datatype, unlikemoney
, allows for explicit control over precision and scale (i.e., the number of digits in total and the number of digits after the decimal point).I substituted
numeric
with amoney
datatype as per the suggestion ofhobovsky
. So it is not an issue now.About money - I agree that this is quite a messy overall picture with the current display on Codewars of
numeric
datatype. I substituted it in this kata withmoney
datatype which is displayed neatly and automatically does rounding.About sorting - we need to cover the corner case of ties - and I think that it is not a problem to do it in a bit unorthodox way :)
please re-publish the solution - I updated a bit query to check second sorting criterion. thanks for providing feedback to the kata!
I updated the query and description to display this sum as a numeric datatype, rounded to 2 decimal places to avoid such discrepancie
fixed it
I rewrote the description, can you estimate how clear is it now?
I worked a lot with dutch and one of my best friends is also from ND. I almost do not know lang but just for fun learned a lot of sayings :)
We zullen dat varkentje wel even wassen :) I updated tests. Frankly, I don't think that this will be a problem because we simply filtering out records from 2023 and do not care what was before and after
added :)
If the stock price begins to rise before a gap and keeps rising after the gap, the period encompassing the gap is considered as one continuous streak. Therefore, the start_date might precede a gap, and the end_date might follow a gap, spanning the entire duration of the rising trend, including the gap.
However, for the trading_days_length, these gap days are not counted. This length represents only the actual number of trading days when the stock price was observed to be rising, excluding any non-trading days within the gap.
do not understand where your solution sometimes makes a mistake :( can you give a clue?
ah, ok :) then resolving it
I think that it works correctly. I added an edge case to cover this scenario:
I think that both your and mine query correctly take it as:
can you elaborate what should be adjusted?
jokes aside, I updated tests and description so that we can be sure that employee cannot be absent twice in one day :) thanks for the feedback!
Loading more items...