Prompted me to learn about all the static methods char and string has. Good one.

2nd Time I Got Top answer, lets go

Fixed for both langauges.

Approved the fork.

Fixed.

You need to return a dynamically allocated array with all the index positions of the capital letters and additionally write its length into the uppercase_count pointer.

Currently you are just returning a null-pointer.

At some point, the description must have been updated as it now specifies that the input consists solely of ASCII letters, which consists only of ['A'..'Z'] ++ ['a'..'z'].

Haskell fork which updates the tests to conform to this specification.

I also saw the don't import ast or a module that depends on it message when I hadn't imported anything. In fact, you can reproduce this in one line by writing return x and getting a NameError because there is no x. So there must be something that wrongly triggers that message with Python NameErrors, at least.

It is stated that 1--1 is valid and that an unary minus is not separated by a whitespace before parentheses. Your example follow these rules.

Hi everyone, I use haskell language.

In random tests, I get a random input string
"((((94.0))-54.98))-89.28-(88.66)+-59.25+75.61+4.88/(44.42)/(79.75)*-60.81*3.72/(19.72*10.46)-58.1/(7.55)*23.37+32.0/(97.63)-(79.92*(1.71-16.82))/(--(28.95)/((55.88/(67.58))))/(69.66)+95.05*(37.3*(5.1*44.66*39.81)-17.23)*80.85+(48.43/(86.06))*(-88.39)/((32.31-31.49*32.76))"
to calc, I get a substring --(28.95), Is that right? I am not found this rule in the description.

tht s nothing. i just fixed it . But my code did pass all the tests anyway

Tests are not ideal but they are correct. It is hard to create randomized tests which catch all possible bugs. Your solution does not work for some simple test cases like this one:

( -9.21+ -8.97* -0.00+6.51+(5.50+6.81))

The expected result is 7.263867809057526 but your solution returns -915.278670000000034.

A simplified version of this test case:

( -9+ 8*0+6+(5+6))

Expected: 8, your solution: 799.087999999999965.

Dude u gotta improve the tests, 'cuz i tell ya, they’re broken! Sometimes my code passed sometimes it didn’t.also there were two cases in the fixed tests where my code gave me the right answer when tested in VSCODE, but your tests gave me a totally different answer. Note that I used the same code! To solve this issue, i had to manually handle these two cases! You gotta revise your tests guys, they’re broken!

Yes, it is always true for Java and for any sane programming language. You still need to be careful with more complicated expressions and if you use a low-level programming language like C with specific compiler flags (e.g., --ffast-math): It is possible that you get different results on different machines even if they are IEEE-754 compliant.

Historically, the original version of Java was not strict with floating-point arithmetic and it was possible to get different results on different machines (but always the same results on the same machine). That's why Java had the modifier strictfp to make sure that floating-point results are reproducible (it was removed in Java 17).

Sorry for a bit dumb question.

Does this mean that if I do something like

float a = 1.0f / 3.0f;
float b = 1.0f / 3.0f;
System.out.println(a == b);

on one machine it's always going to be true?