CYBER WEEK - EXTRA SAVINGS EVENT
TRY A FREE LESSON

Getting 'bargap' error when looping more than 44 times

Screen Link: Learn data science with Python and R projects

My Code:

import numpy as np
chi_squared_values = []

for i in range(1000):
    randos = np.random.random(32561)
    expected = len(randos) / 2
    randos[randos < 0.5] = 0
    randos[randos >= 0.5] = 1
    female_count = sum(randos)
    male_count = len(randos) - female_count
    female_diff = (female_count - expected)**2 / expected
    male_diff = (male_count - expected)**2 / expected
    chi_squared = female_diff + male_diff
    chi_squared_values.append(chi_squared)
    
plt.hist(chi_squared_values)
plt.show()

What I expected to happen:
A plot to be produced without an error.

What actually happened:
An error was produced along with a plot.

ValueError: 
    Invalid value of type 'numpy.float64' received for the 'bargap' property of layout
        Received value: -2.220446049250313e-16

    The 'bargap' property is a number and may be specified as:
      - An int or float in the interval [0, 1]

If I comment out the last line (plt.show()) then a plot is produced without error along with the three objects returned by plt.hist() (values, bins, patches). Also, if I reduce the loop from 1000 to 44 iterations, there is no ‘bargap’ error and a plot is produced. At 45 iterations and above, the error is generated.

Anyone have an idea why this is happening? It seems to be related specifically to the DQ platform as I can’t find anything related on Stack Overflow.

1 Like

Hi Mike,

It seems to be a purely DQ technical bug, as well as another one in the same lesson: you cannot download the dataset on your own computer. So it’s a real trap: no way to check it on DQ and even on your own computer :hear_no_evil: I think you’d better send a ticket about it.

1 Like

As always, thank you kindly for the reply @Elena_Kosourova! I’ll send a ticket about this now. Luckily, there is a workaround for downloading the dataset locally (it’s just a matter of modifying the URL) but I can’t recreate the bargap error locally.

1 Like

Ah, perfect, then it’s just a bug of the platform. Hopefully it will be fixed soon! :pray:

Yeah, should be an easy-enough-fix I would think … I’ve seen it once before elsewhere and recall that the bargap value was also extremely close to 0 (like this one). I wonder if it’s a classic floating point rounding error somewhere on DQ’s backend for plotting?

1 Like

Well, yes, if it’s almost zero, then it seems very plausible that it’s just a floating point rounding glitch!

I remember one crazy technical issue, which looked so simple at the beginning, that we were discussing with another learner on DQ. You can find the whole thread here. In that case, though, it was a Python-related bug, while in your case, it seems to derive from DQ’s backend.

1 Like

Thanks for pointing out this thread…it was a great read!

And just to inject some more weirdness into my original post about bargap error: a few screens after this one (screen #4 → screen #7) we are asked to perform a similar task and rather than do it the exact same way, I used a different RNG (ie I used randint()as opposed to random()) all of a sudden, no more bargap error! Below is the code I used on screen #7 that does not cause an error:

from numpy.random import randint
chi_squared_values = []
expected = 150
for _ in range(1000):
    randos = randint(0, 2, 300)
    observedF = sum(randos)
    observedM = len(randos) - observedF
    female_diff = (observedF - expected)**2 / expected
    male_diff = (observedM - expected)**2 / expected
    chi_squared = female_diff + male_diff
    chi_squared_values.append(chi_squared)
    
plt.hist(chi_squared_values)
plt.show()

While this does not cause the bargap error, it creates a different plot than that on screen #4 since the “new random data” is different. In the end, I needed to change my code to use random() but I found it interesting that using randint() to generate my random data somehow avoids the bargap error. Weird…

2 Likes

Oh, Mike, this mission seems to be full of mysteries, it makes learners feel like the great Sherlock! :sweat_smile::joy: And in Anaconda, does this code work properly?

Yes, always mysteries to be solved but that is the great thing about learning something new: we are always asking “Well, what if I do this…then what happens?” We are bound to find interesting things the more we think like this.

And yes, all is well in Anaconda and I cannot reproduce the error there at all.

1 Like

Totally agree with that, also because real-life cases in whatever sphere are always full of mysteries, they are never just like cases from a textbook.

Anyway, if it works well in Anaconda, then it’s just a bug. Let’s hope it will be solved soon.