Hi everybody
Working on a project that needs really long numbers. I'm sure there's a way of doing it that's obvious to those with better math brains and more experience, but I basically need to keep Pd from slipping into scientific notation.
Can anybody offer hints on how to split up really long numbers so I can keep them accurate?
Thanks in advance.
cheers dafydd
On Fri, 21 Dec 2007, Dafydd Hughes wrote:
Working on a project that needs really long numbers. I'm sure there's a way of doing it that's obvious to those with better math brains and more experience, but I basically need to keep Pd from slipping into scientific notation.
Everybody learned that at the beginning of elementary school, it's just not obvious that it's the same thing, only obvious in retrospect. When you compute one digit at a time on paper, that's pretty much the same thing that you have to do to work with long numbers that don't fit in float32.
However, you don't have to do it in base 10. Computers work with base 2, but computing many bits at once, so you could argue that you are really working in base 256 (uint8) or in base 4294967296 (uint32). For floats it's more complicated, you could do up to base 16777216, perhaps less.
But there's nothing preventing you from trying out base 10, or base 1000 or 1000000 (group digits in packs of 3 or 6 for more efficiency: 123456789 becomes list 123 456 789 or list 123 456789). There are actually some libraries for doing that (in C or Perl or other), because several uses for long digits are much better if you stick in the same base as what you are gonna use in the end (e.g. finance).
It might be easier to use another programming language to do those calculations. E.g. Ruby supports this since a long time, and Tcl has it since some preview of version 8.5. I don't know much about others, but I expect most programming languages to have a library for long ints.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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).
if you are only interested in the visual representation (e.g when displaying phone numbers) then you could convert your numbers to symbols using [makefilename %d]. if you need numbers with more than 7 digits, you would need to compose them from more than one floatnumber, since 7 decimal digits is the maximum that can be expressed with 32bit floating point. use [list-ls] from frank's list-abstractions to glue a list of symbols together.
alternatively, you could also use something like this to construct long symbols containing only digits:
http://romanhaefeli.net/very_long_number.png
roman
On Fri, 2007-12-21 at 11:38 -0500, Dafydd Hughes wrote:
Hi everybody
Working on a project that needs really long numbers. I'm sure there's a way of doing it that's obvious to those with better math brains and more experience, but I basically need to keep Pd from slipping into scientific notation.
Can anybody offer hints on how to split up really long numbers so I can keep them accurate?
Thanks in advance.
cheers dafydd
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Fri, 2007-12-21 at 19:29 +0100, Roman Haefeli wrote:
i forgot to mention, that the classes [symbol2list] and [list2symbol] are part of zexy.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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
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@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
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@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
Hey thanks Thomas
You folks are awesome.
cheers dafydd
On Dec 21, 2007 4:30 PM, Thomas Grill gr@grrrr.org wrote:
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@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
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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@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
Hans-Christoph Steiner schrieb:
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.
Exactly, it takes [list 123 0.0001(, [double 123 0.0001( or [float 123( in any of the objects' inlets and outputs something like [list 456 0.0002(. I'm thinking of open-sourcing the hr library anyway - it contains all relevant math operations, message and signal ones.
gr~~~
Thomas Grill a écrit :
I forgot to mention that vibrez_pure (http://vibrez.net/vibrez_pure)
I forgot to try pd-devel, many thanks!
I always wonder when you say large numbers and rotation...
Do you really need large numbers? I never checked if its slower to rotateXYZ to 360*100 compared to rotation to 360.
.b.
Dafydd Hughes wrote:
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@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
On Fri, 21 Dec 2007, B. Bogart wrote:
I always wonder when you say large numbers and rotation...
Do you really need large numbers? I never checked if its slower to rotateXYZ to 360*100 compared to rotation to 360.
I really wonder why Dafydd wants large numbers for rotation. I thought that it was for something that really needs large numbers. For all you can see on a display, float32 is already much more than necessary.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard a écrit :
On Fri, 21 Dec 2007, B. Bogart wrote:
I always wonder when you say large numbers and rotation...
Do you really need large numbers? I never checked if its slower to rotateXYZ to 360*100 compared to rotation to 360.
I really wonder why Dafydd wants large numbers for rotation. I thought that it was for something that really needs large numbers. For all you can see on a display, float32 is already much more than necessary.
float32 is not enough for avoiding round off errors with astronomical values, for example if we would like to use the Newton universal gravitation formula,
F = G(m1*m2)/r^2
the radius would exceed the range of affordable numbers into this computation, and then the result wouldn't be accurate, so we can not simulate Newton laws with using pd arithmetic objects only.
Cheerfull xmas and NYear.
I wish it was something as noble as gravitation, but it's just a clock which counts seconds from about 30000BC to now. It's easier to do using [mod] on the counters, but the way it's animated means it makes a smooth transition around the dial then jumps back to 0 instead of smoothly moving on. Just letting the rotation get bigger and bigger without modulo eliminates this problem, but does nasty things once the numbers get too long.
Luckily, Python can deal with much longer numbers. My solution is to do the counting and splitting in python, then have 2 clocks in Gem which are out of phase so one is rewinding with the gemhead off while the other goes smoothly to 0, then they switch. There's probably a much simpler solution.
Is any of this making sense? I'm pretty tired and I've had a couple of beers:)
Thanks everybody for the help.
cheers dafydd
On Dec 21, 2007 10:16 PM, Patrice Colet pat@mamalala.org wrote:
Mathieu Bouchard a écrit :
On Fri, 21 Dec 2007, B. Bogart wrote:
I always wonder when you say large numbers and rotation...
Do you really need large numbers? I never checked if its slower to rotateXYZ to 360*100 compared to rotation to 360.
I really wonder why Dafydd wants large numbers for rotation. I thought that it was for something that really needs large numbers. For all you can see on a display, float32 is already much more than necessary.
float32 is not enough for avoiding round off errors with astronomical values, for example if we would like to use the Newton universal gravitation formula,
F = G(m1*m2)/r^2
the radius would exceed the range of affordable numbers into this computation, and then the result wouldn't be accurate, so we can not simulate Newton laws with using pd arithmetic objects only.
Cheerfull xmas and NYear.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dafydd Hughes a écrit :
I wish it was something as noble as gravitation, but it's just a clock which counts seconds from about 30000BC to now. It's easier to do using [mod] on the counters, but the way it's animated means it makes a smooth transition around the dial then jumps back to 0 instead of smoothly moving on. Just letting the rotation get bigger and bigger without modulo eliminates this problem, but does nasty things once the numbers get too long.
FMPOV the problem is as the same as we get with gravitation computing.
did you look at wrap from zexy?
.b.
Dafydd Hughes wrote:
I wish it was something as noble as gravitation, but it's just a clock which counts seconds from about 30000BC to now. It's easier to do using [mod] on the counters, but the way it's animated means it makes a smooth transition around the dial then jumps back to 0 instead of smoothly moving on. Just letting the rotation get bigger and bigger without modulo eliminates this problem, but does nasty things once the numbers get too long.
Luckily, Python can deal with much longer numbers. My solution is to do the counting and splitting in python, then have 2 clocks in Gem which are out of phase so one is rewinding with the gemhead off while the other goes smoothly to 0, then they switch. There's probably a much simpler solution.
Is any of this making sense? I'm pretty tired and I've had a couple of beers:)
Thanks everybody for the help.
cheers dafydd
On Dec 21, 2007 10:16 PM, Patrice Colet pat@mamalala.org wrote:
Mathieu Bouchard a écrit :
On Fri, 21 Dec 2007, B. Bogart wrote:
I always wonder when you say large numbers and rotation...
Do you really need large numbers? I never checked if its slower to rotateXYZ to 360*100 compared to rotation to 360.
I really wonder why Dafydd wants large numbers for rotation. I thought that it was for something that really needs large numbers. For all you can see on a display, float32 is already much more than necessary.
float32 is not enough for avoiding round off errors with astronomical values, for example if we would like to use the Newton universal gravitation formula,
F = G(m1*m2)/r^2
the radius would exceed the range of affordable numbers into this computation, and then the result wouldn't be accurate, so we can not simulate Newton laws with using pd arithmetic objects only.
Cheerfull xmas and NYear.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
B. Bogart -
Dafydd Hughes -
Hans-Christoph Steiner -
Mathieu Bouchard -
Patrice Colet -
Roman Haefeli -
Thomas Grill