Re: [Visualpython-users] numpy array in random

[Derek <kn...@ip...>]

Guy K. Kloss wrote:
> Hi Symion,
>
> On Wed, 21 Oct 2009 20:53:30 Symion wrote:
>   
>> I have been using Visual.random number generators and have found that the
>>  following Methods return as numpy arrays, which when Printed or Evaluated
>>  returns a list that is not separated by the usual commas.
>>
>> from visual import *
>>     
>
> Yes, this is one of the issues that I've been mentioning on the list before, 
> caused by the snowball imports that Visual is conducting under the bonnet in 
> the code (from math import *; from numpy import *).
>
> Therefore the namespace is quite "polluted" with modules that are not from 
> Visual, but that also may behave in some way unexpected, as they come from 
> different packages.
>
> In the case of random this originates from NumPy, and therefore returns 
> NumPy's ndarray structures.
>
>   
>> print visual.random.sample(5)  # floating point list with no commas
>> print visual.random.permutation(5) # Integer list with no commas
>> print visual.random.randint(1,46,5) # Integer list with no commas
>>
>> visual.safe_eval(str(visual.random.randint(1,46,5))) # generates error
>>
>> No commas between elements?!
>>     
>
> The ndarray objects are *not* lists or tuples. But they do implement the 
> methods of the iterable interface so they behave in many ways like lists. As 
> for your observation, their __str__() method is implemented to print out 
> arrays separated by blanks, and not to use commas as separators, as well as 
> other rounding style, and some truncation style on very extensive arrays.
>
>   
>> A work around is to add .tolist()
>>     
>
> Or to call the list constructor: list(a_numpy_array)
>
>   
>> visual.random.sample(5).tolist() # returns normal list of floats
>> visual.random.permutation(6).tolist()
>> visual.random.randint(1,46,5).tolist()
>> visual.safe_eval(str(visual.random.randint(1,46,5).tolist()))
>>     
>
> Be very careful what's imported, and what you're using. It might be not what 
> you expect. That's also why an "from visual import *" can be quite dangerous 
> for your own code, as their name spaces are *very* full and may mask stuff 
> you're doing yourself.
>
> Guy
>
>   
I have been following the namespace issue and the following might help 
to get a handle on things.

from visual import *
print len(dir())

Mine reads 556

If you're brave you'll print dir()!
Although this is a drawback, it is also a Gold mine of amazing, obscure, 
bizarre but quite often useful things.
But then, on the other hand I would like to be able to 'import visual' 
as a minimal system then import any modules
of my choosing. I can see the dilemma.

Symion