add concept exercise problematic-probabilities

[depial]

Here's an idea for an exercise for the rational-numbers concept. I've tried to incorporate a realish use case, but this moves it down the syllabus a bit. Some notes:

• Although vector-operations seems just as valid, the prereq is listed as loops, since this is more general.
• The tests assume that the rounding errors are consistent across Julia and OS versions (and Float64 is being used for casting).
• Basic probability is used, but also explained.
• introduction.md has been pared down quite a bit from the concept version.

I'm unsure if rounding errors will be consistent across Julia and OS versions (but it appears most modern processors are IEEE 754 compliant). In any case, for the examples which have a rounding error, I've tried to pick examples which had larger ones than average, so hopefully there's a bit of robustness against potential variation there. However, those errors were still quite small (~1e-16). There are ways to ensure a larger error, but I'm not sure it's necessary or not.

For reference, I'm running Linux 24.04 and using Julia 1.11.0

The one time we could have used all that extra testing... :D

[depial]

There is a way to rephrase the exercise to further mitigate potential rounding error inconsistencies by providing the float used as comparison as an argument to the functions. The student then would have to compare that value to their calculated rational number. This would likely take a bit of a revamp since it would make task 2 obsolete. However, I would prefer to avoid this, if possible, since I find it more instructive to have the student perform both calculations.

[BethanyG]

@depial - saw this fly past in my GH notifications. I really like this exercise! I especially like how it "forces" contemplation of why there would be rational numbers in Julia, and some of what they'd be used for. I almost think that in the final two tasks, you might want to have both the rational probability and a specific rounded decimal probability be returned when there is a mis-match ... just to re-enforce things. But that's my Python "show me" talking. 😄

It's very cool that Julia integrates rationals in as general numeric types. Python puts these in a module and forces "clean" conversion by requiring that if a float-like value is used, it's forced to a specific precision by using a Decimal type in the constructor (neither Fractions nor Decimals are fully inter-operable with the core Python numeric types). So there are warnings all over the docs about how floating point math will give you unexpected results with both Fractions (rationals) and Decimals.

On one hand, that makes the rest of the numeric types pretty easy to use for general-purpose "close enough" math. On the other? If you really do need precision, then you have to do it "all the way" and have special code. But this is also why there is Numpy. 😉

[colinleach]

Apologies, I've not had chance to go through this in detail yet (other distractions today). This afternoon...

@BethanyG, is this something you're interested in adding to the Python syllabus. The concept was merged in #3554, 18 months ago, without an exercise.

The one time we could have used all that extra testing... :D

We could run the tests as a one-off in a branch on one of our forks, it doesn't need to be in exercism/julia.

I have Linux Mint 22.1 (effectively, Ubuntu 24.04) and Win 11 systems for local testing, nothing Apple.

[BethanyG]

We could run the tests as a one-off in a branch on one of our forks, it doesn't need to be in exercism/julia.

I have Linux Mint 22.1 (effectively, Ubuntu 24.04) and Win 11 systems for local testing, nothing Apple.

I'm on an intel Mac, so could perhaps test there. I might need some setup help.

[BethanyG]

@BethanyG, is this something you're interested in adding to the Python syllabus. The concept was merged in #3554, 18 months ago, without an exercise.

Yes — this might work! But I think we'd also need the Decimals concept merged, with an exercise for that as well, since the two are interdependent for Python — at least if you are going to make rationals that come from floats. I might also go back and review the Fractions one, just to make sure we emphasize precision and the fact that you would use a rational to better represent "true" floating point values.

And since in Python you have to import the module, we might need to add some tasks around importing and converting. But this exercise is certainly a great start. 😄

aaaand ... the more I think on it, the more I think maybe we have two exercises - one for creation/conversion, and the other for "working with". Or not. Maybe we could do a series of purpose-built practice exercises for that. Lemme think a little on it as I get the Decimals stuff looked at.

[colinleach]

we'd also need the Decimals concept merged

We need to move this from a Julia PR discussion! But I'm not sure Decimals even got drafted - I looked into it, and found it ugly and confusing. Luckily, Julia shunted this topic off to a 3rd-party package.

[colinleach]

Also a bit off-topic: I've been working on the Dates & Times concept for Julia, and it reminds me why my old Python draft was huge, confusing, and impossible to merge. A bigger topic than it first appears!

[BethanyG]

We could run the tests as a one-off in a branch on one of our forks, it doesn't need to be in exercism/julia.
I have Linux Mint 22.1 (effectively, Ubuntu 24.04) and Win 11 systems for local testing, nothing Apple.

I'm on an intel Mac, so could perhaps test there. I might need some setup help.

Another thought: codespaces might have a template that would allow testing on Mac...although I doubt it. Apples OS EULA expressly forbids installation on non-apple hardware for most scenarios.

[BethanyG]

we'd also need the Decimals concept merged

We need to move this from a Julia PR discussion! But I'm not sure Decimals even got drafted - I looked into it, and found it ugly and confusing. Luckily, Julia shunted this topic off to a 3rd-party package.

Let's take this up in an Issue on the Python track. 😄 I'll make one here shortly ... or you can. Just ref this thread so we don't forget.

[BethanyG]

Also a bit off-topic: I've been working on the Dates & Times concept for Julia, and it reminds me why my old Python draft was huge, confusing, and impossible to merge. A bigger topic than it first appears!

As discussed for the Python one — the topic might benefit from breaking it down into pieces. I think we discussed maybe separating date conversion from timezones from "date math"? Can't remember anymore. But it is indeed a big-ass and complicated topic! And that doesn't even dig into "wall clock" time vs other timings. sigh.

[colinleach]

Apart from one tiny typo, this looks great!

[depial]

I almost think that in the final two tasks, you might want to have both the rational probability and a specific rounded decimal probability be returned when there is a mis-match

@BethanyG, I had considered doing something like this, or even just returning the error/discrepancy instead (with a slight modification of the story to focus on how bad the problem was rather than just fixing it). I think I went with this because, with the examples I've used here, the errors are quite small (~1e-18). I don't see why that would stop anyone from also including a rounded decimal probability though :)

Apart from one tiny typo, this looks great!

I felt this was still a bit raw, but if everyone is happy, then that's great! :)
However, I'll be opening a PR to make a slight modification to the tests to try to make them a bit more robust to system/implementation variations.