[PD] Long long numbers

Hans-Christoph Steiner hans at eds.org
Sat Dec 22 20:22:41 CET 2007


It seems that it would be useful to create a defacto standard for  
long numbers.  It could just be a list of two floats:

[87891234 987234.23(

or maybe a special selector:

[long 87891234 987234.23(

I imagine this lib has something like that.

.hc


On Dec 22, 2007, at 3:37 AM, Thomas Grill wrote:

> I forgot to mention that vibrez_pure (http://vibrez.net/vibrez_pure)
> contains a high-resolution math library (hr) with many objects that  
> use
> two-float lists to represent double precision numbers. There are both
> message and signal objects. If double precision (about 15 decimal
> digits) is enough for you, this might be something. The installer
> packages are for OSX and Windows.
> gr~~~
>> Hi Dafydd,
>> attached is an archive of a few abstractions and a small Python  
>> helper
>> script which uses the Python decimal module for calculation of large
>> numbers with py/pyext in pd.
>> Have a look at test.pd  - it's pretty self-explaining. It's been a
>> while since i used this and i just realized that the re-conversion of
>> the numbers into pd symbols or lists doesn't deliver all digits for
>> really large results... but i'm pretty sure this is easy to fix by
>> some precision argument to the Decimal type (the conversion is in the
>> _.py script, function any2dec)
>>
>> gr~~~
>>
>> PS. I think this requires Python version >= 2.4
>>
>>
>> Dafydd Hughes schrieb:
>>> Thanks for your help, Mathieu and Roman
>>>
>>> As it turns out, while I don't want to perform calculations so  
>>> much, I
>>> do need to translate these long numbers into rotations in Gem, so I
>>> need them more or less intact.
>>>
>>> Looks like it's Python for the crunching then.
>>>
>>> Thanks again!
>>>
>>> cheers
>>> dafydd
>>>
>>> On Dec 21, 2007 3:14 PM, Mathieu Bouchard <matju at artengine.ca>  
>>> wrote:
>>>
>>>> On Fri, 21 Dec 2007, Roman Haefeli wrote:
>>>>
>>>>
>>>>> i assume, you don't want to perform calculations with these big
>>>>> numbers.
>>>>> or better i should say, i hope, because this wouldn't be  
>>>>> possible (at
>>>>> least with pd on 32bit machines).
>>>>>
>>>> Everything is possible. Try this:
>>>>
>>>>    ruby -e "p 3**33333"
>>>>
>>>> If you don't have explicit support for unlimitedly long numbers  
>>>> in a
>>>> given
>>>> programming language, you can always add it by yourself in some  
>>>> way, by
>>>> performing the carries by yourself. For example, it takes N^2 plain
>>>> multiplications to compute multiplication of two numbers of N  
>>>> digits
>>>> each,
>>>> if you do it the obvious way. One such "digit" can actually be a
>>>> bunch of
>>>> digits in the base that you'd use if you'd be doing it on paper.  
>>>> For
>>>> example, Ruby does it using 32 bits as being one "digit" relatively
>>>> to the
>>>> way it's done (see also my other mail in this thread). It's best to
>>>> make
>>>> it fit with the processor or programming language. If Ruby didn't
>>>> have it
>>>> and I wanted to add this feature to Ruby, I'd probably make my
>>>> digits only
>>>> 30 bits each or perhaps even 15 bits, for speed and RAM reasons  
>>>> (the
>>>> way
>>>> numbers are allocated in the specific case of Ruby).
>>>>
>>>>
>>>>   _ _ __ ___ _____ ________ _____________ _____________________ ...
>>>> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
>>>>
>>>
>>>
>>>
>>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>>
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war  
on terrorism.        - retired U.S. Army general, William Odom






More information about the Pd-list mailing list