Problems setting palette

I am trying to change the palette in pyROOT. However, it seems I cannot get proper effects, doing more or less the same thing as in ROOT:

import ROOT
f = ROOT.TFile("tmphisto.root")
h = f.Get("pdm")
import numpy as np
a = np.array([0], dtype=np.int32)
ROOT.gStyle.SetPalette(52, a)

The effect are a little bit random, but it seems that from 0 to 3 colors appear on the palette axis on the right, the rest is white. I wonder if the passing of colors to the palette is correct, but I know no other way.

Of course, in the above script, 2nd and 3rd line have to be adjusted to open own file and own 2D histogram.

Which means it is fine with the normal ROOT ?

If you repeat the same, but C version of command in CINT of ROOT 5.34, it works as it is supposed to.

I mean I have a proper greyscale palette.


why int32, rather than the system int?


I am not sure how to set the types that are not in numpy for numpy array. Anyway, I tried also with array.array and ‘i’, the result was the same.


still not following. Looking at the doc of SetPalette(), to get a grey scale, ncolors should be set to 52, and the array given should be set to null. So ‘ROOT.gStyle.SetPalette(52)’ should do the trick. By providing an array, ncolors is interpreted as the size of the array, which in reality is 1, not 52.


Work, thanks. Honestly, I did not get that

means setting colors to NULL. In this case, 0 and Null are the same in C++, but not the same in Python.


no, they do mean the same thing. What you did in python has this C++ equivalent:int* n = new int[1]; n[0] = 0; gStyle->SetPalette(52, n);whereas the C++ code you actually used was probably:gStyle->SetPalette(52, 0);
Now, PyROOT will not except that literally, but it will accept this:gStyle.SetPalette(52, nullptr)with ‘nullptr’ being borrowed from C++11 already. (It just also happens that the ‘0’ is redundant, as it is the default, so not providing an argument is the easiest use.)

Whether to allow the integer ‘0’ as a (typename*)0 in PyROOT is one of them philosophical thingies. I think the nullptr construct is elegant. It can also be coded up explicitly using the and/or construct to make explicit whether code will allow passing null pointers:some_call( value and value or nullptr )
Hope that clears things up.