tried to do as you said, but using an extra byte set to zero before the assertion instead of checking that the user did nul-terminate as you suggested

A newer fork has just been approved, so rejected (post a suggestion on discourse if you want to draw attention on a fork/translation).

You're earing me, but you don't listen.

Yes, and you are talking but not explaining. We found each other.

You predefined all my answers; it is pointless to answer.
But I am curious what do you see in this array with your profound vision and honesty?

I don't feed the users with floats

and what is that...? ["3.6", "-3.6", "3.6", "0.0"] (answering "strings" would either be a lack of vision about the overall task or just being dishonest...)

You're earing me, but you don't listen.

I don't feed the users with floats or require floats as a return, so they are not forced to use floats.
I addded some tolerance to the validation method, according to the guide you mentioned.

Could you give an example?

>>> 360%3.6
3.599999999999991

>>> 3.6+3.6+3.6+3.6+3.6+3.6+3.6+3.6+3.6
32.400000000000006

This is exactly why the current setup isn't good (aside of the string vs int "problem"). The user is forced to deal with such a kind of non sense, just because you don't want to use something that avoids the use of floats

https://docs.codewars.com/authoring/recipes/floating-point/

We only care about a task being meaningful and well described.

Don't you think something like the word "meaningful" as a requirement for a Kata is a little bit vague and subjective?

They are faster than decimals already, and will avoid any precision problem.

Seems like fractions are slower than decimals.
Or am I missing something?

test1 = [3.6, 3.6, 3.6, 3.6, 3.6]
test2 = [Decimal('3.6'), Decimal('3.6'), Decimal('3.6'), Decimal('3.6'), Decimal('3.6')]
test3 = [Fraction('3.6'), Fraction('3.6'), Fraction('3.6'), Fraction('3.6'), Fraction('3.6')]
test4 = [Fraction(18,5), Fraction(18,5), Fraction(18,5), Fraction(18,5), Fraction(18,5)]

def average(numbers):
    return sum(numbers) / len(numbers)

%timeit average(test1)
%timeit average(test2)
%timeit average(test3)
%timeit average(test4)

636 ns ± 18.2 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)
1.76 µs ± 34.6 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)
31.1 µs ± 1.01 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)
32.9 µs ± 3.57 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

Somebody has to do this job.

You're assuming here that, somewhere in the code, there are still strings and/or floats.

To create a Decimal, you have to put something in it. Creation is that job.
I can feed the user's function with integers, but he will have to create a Fraction with them, or something else.
The creation of a Decimal or a Fraction is computing already.
Somebody has to do it, Kata's or the user's side. Which way leads to that "good practice" sign?

You can just provide/store/use anything you want.

Can I? Something just went wrong. :)

Oh btw, that is the underlying technical trap we're talking about.

Could you give an example?
I don't see that underlying technical trap for this Kata with using strings and integers as input.

We don't care about timings, there. We only care about a task being meaningful and well described. But even if we do (care about timings, I mean), you can use fractions instead of decimals. They are faster than decimals already, and will avoid any precision problem. But you then have to provide fractions, or at the very least numerator + denominator as int (otherwise, there is no point in using fractions...).

Somebody has to do this job.

No. You're assuming here that, somewhere in the code, there are still strings and/or floats. But that's a wrong assumption. You can just provide/store/use anything you want. Hence... something more meaningful and that will avoid potential problems ;) (floating points errors vs string comparison. Oh btw, that is the underlying technical trap we're talking about).

Thanks, I missed the separations, sorry about that, corrected.

Ok, this explanation is much better.
Are we talking about the code implementation time issue?
For me, it is either you (Kata) putting the fuel in the saw and giving it to me, or you hand me both, and I put it in the saw.
Somebody has to do this job.
I think 10 miles walking analogy is not applicable here because we do the same function call in both cases.

As far as I understand, Decimals are precision variables and therefore occupy more space in memory (String "3.6" and Decimal("3.6") are about two times different). Hence, we won't win any implementation time by using them instead of strings, integers, or floats.
Users may gain some implementation time on their side if we do the conversion to Decimal on the Kata side, but only in case they decide to use Decimals for this Kata.

Computing operations with Decimals takes ten times longer than with floats.
Converting Strings to Decimals takes two times longer than to Floats.
So, if users can complete the Kata with floats, it would be more time efficient.
Therefore I don't want to force the users to use Decimals;
I want to give them raw data and let them decide on how to compute it better.

I cannot say more on the topic because it's not a technical problem. Yes, technically what you did can perfectly work. But that doesn't mean it's appropriate. You need to take a step back. If I ask you to chop wood, I can give you an empty chain saw and the fuel in a separated "tank" and send you walking 10 miles in the forest with both, and only there you fill the chain saw. That works. But is that meaningful/practicle? Nope. That's the exact matter here.

(note: beware of § "non separations" whithout empty lines between them)

Why did you resolve this topic?

What particular issue was not resolved?

I did, tho. Anyway.

If you mean the inconsistency topic, then you did not.
You are just stating the obvious things:
They are different types, they will be converted to other types, and operations will be done on them.
With all my respect, it doesn't prove to me that it is not a good practice. What is the problem with it exactly?
Do you have any materials about it I can read?
I expected something like this:
Using these types of variables together is inconsistent in this Kata BECAUSE:
This will lead to a TypeError if the variables provided by your test are: ...
OR: there rules about it here ...

Don't get me wrong; I want to improve the Kata, but if I implement all the suggestions blindly, I won't learn anything and will copy the problem in the future.

you didn't explain why.

I did, tho. Anyway.

Cheers

Why did you resolve this topic?

Ok, authoring a kata IS HARD, and it looks like I am a horrible Kata maker.
Your thumb-down sign message was received.
Apart from that learning point, I can't filter out any particular issues.
You claimed some points are not showing good practices, but you didn't explain why.
I can't distinguish one from the other without a tangible reason or an example.

First, keep in mind that AUTHORING IS HARD. Way more than you seem to think.

Yes. Otherwise, why create the kata in the first place?

You didn't understand me. I'm saying that the context of the task, when given, must make sense for the reader. Currently, the given information is too much sparse and regular users won't understand the context/task properly. Again, a picture that isn't obviously matching the inputs has to be properly explained, one way or another.

Your point about nonograms or so is valid, except for one thing: nobody wants to have to research just to understand the context of a 6 kyu.

I simply can't switch my vision to yours.

That's part of my initial statement (of this message): as an author you are the one who should make that effort (not the effort of understanding my way of thinking, but the effort of trying to walk in the shoes of any user crossing path with your kata. And I can tell you that, for now, your kata description is very confusing).

Searching on your side what is problematic is actually what will make you better at authoring kata / specifying and explaining tasks (ie. IRL also). Aside of that, I review already a lot of kata everyday, fix a lot of kata when I feel like it, and I confess that your general way of acting is not encouraging me to be more precise in any way (in your previous kata you hoped for the obviously wrong way to resolve a problem, and here, I don't feel like you're actually trying to understand what I say or why).

The first argument is a list of strings; the second is an integer. I don't see any inconsistency here.

• Those will be used together at some point/in some ways.
• Those are NOT compatible datatypes for the operations that will be done with them
• So, one of them (if not both) must be converted to something else

Direct consequence of this is: the current specs: do not make sense / are suboptimal / aren't good practice / aren't showing a good example / ... (pick your weapon ;) )

but why MUST I use them in this Kata? Why can't the Strings be used here?

To make for a good/qualitative kata. Again, showing good practices / well thought specifications / ... (pick your weapon ;) )

Again, authoring a kata IS HARD. For now, the specs of your kata are suboptimal, as well as its description.

Cheers