alberto-bernal

I'm trying to read a number like 189298801.0011 from a textfile into max, but it seems to have troubles already at the first moment (inmediately in the outlet of "textfile"). I suposse, max is not able to deal with such a big number; I need this because is the time information I get from another programm (plot), which needs to be converted into "normal" miliseconds to use with max.

Is there any workaround to deal with it? Or do I have to make the number reduction outside from max?

Hello,
  I'm trying to read a number like 189298801.0011 from a textfile into max, but it seems to have troubles already at the first moment (inmediately in the outlet of "textfile"). I suposse, max is not able to deal with such a big number; I need this because is the time information I get from another programm (plot), which needs to be converted into "normal" miliseconds to use with max.
  Is there any workaround to deal with it? Or do I have to make the number reduction outside from max?
  Thank you for your help,

dealing-with-big-numbers

On 30 nov. 07, at 01:50, alberto-bernal wrote:

> I'm trying to read a number like 189298801.0011 from a textfile into 

> max, but it seems to have troubles already at the first moment

Here is an example in JavaScript that reads only the first line of your 

file, not sure it can help you as your high precision float is parsed 

in 3, which may turn the rest of your patch in something rather 

    theSourceFile = new File (filename, "read");

    theLine = theSourceFile.readline (255);

    anArray = theLine.split (".", 2);

    outlet (0, parseInt (anArray[0])/1000);

    outlet (1, parseInt (anArray[0])%1000);

    outlet (2, parseFloat (anArray[1]) / Math.pow(10, anArray[1].length) );

Centre de Recherches et de Formation Musicales de Wallonie asbl

>   I'm trying to read a number like 189298801.0011 from a textfile into 
> max, but it seems to have troubles already at the first moment

Here is an example in JavaScript that reads only the first line of your 
file, not sure it can help you as your high precision float is parsed 
in 3, which may turn the rest of your patch in something rather 
complex...

outlets = 3;
function read (filename)
{
	var theLine;
	var anArray;

	theSourceFile = new File (filename, "read");

	theLine = theSourceFile.readline (255);
	anArray = theLine.split (".", 2);

	outlet (0, parseInt (anArray[0])/1000);
	outlet (1, parseInt (anArray[0])%1000);
	outlet (2, parseFloat (anArray[1]) / Math.pow(10, anArray[1].length) );

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://www.crfmw.be/max


> I need this because is the time information I get from another

> programm (plot), which needs to be converted into "normal"

> miliseconds to use with max. Is there any workaround to deal with it?

If you deal with milliseconds, it won't be such a problem as long you

keep all as a float. The precision is limited, but as long you don't

want it sample accurate, big times should work fine. (for bigger than

ca. 6 minutes you will loose sample accuracy...)

If you need double precision, it will be more complicated, you have to

keep and calculate with several numbers...

alberto-bernal schrieb:
> I need this because is the time information I get from another
> programm (plot), which needs to be converted into "normal"
> miliseconds to use with max. Is there any workaround to deal with it?

If you deal with milliseconds, it won't be such a problem as long you
keep all as a float. The precision is limited, but as long you don't
want it sample accurate, big times should work fine. (for bigger than
ca. 6 minutes you will loose sample accuracy...)

If you need double precision, it will be more complicated, you have to
keep and calculate with several numbers...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Thank you very much, Patrick and Stefan, for your help.

I could manage to round up the numbers outside from max (with plot). I don't need so much precission, integer miliseconds is enough, but Max falses the integer parts of the long decimal numbers, and that it's a problem.

Thank you very much, Patrick and Stefan, for your help.
  I could manage to round up the numbers outside from max (with plot). I don't need so much precission, integer miliseconds is enough, but Max falses the integer parts of the long decimal numbers, and that it's a problem.

> Thank you very much, Patrick and Stefan, for your help. I could

> manage to round up the numbers outside from max (with plot). I don't

> need so much precission, integer miliseconds is enough, but Max

> falses the integer parts of the long decimal numbers, and that it's a

Yes, int numbers go from -2147483648 to 2147483647. Anything outside 

can't work. The range of 32-bit floats will never give you a problem. 

Just make sure you never convert to an int...

alberto-bernal schrieb:
> Thank you very much, Patrick and Stefan, for your help. I could
> manage to round up the numbers outside from max (with plot). I don't
> need so much precission, integer miliseconds is enough, but Max
> falses the integer parts of the long decimal numbers, and that it's a
> problem.

Yes, int numbers go from -2147483648 to 2147483647. Anything outside 
can't work. The range of 32-bit floats will never give you a problem. 
Just make sure you never convert to an int...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Quote: Patrick Delges wrote on Fri, 30 November 2007 10:31

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

> can't deal with such a precision... (maybe Peter C. will like to add 

I'll just repeat the one rule of thumb: 32-bit floats give you about 6 digits accuracy. If that's enough for your purposes, you're in luck.

Quote: Patrick Delges wrote on Fri, 30 November 2007 10:31
----------------------------------------------------
> can't deal with such a precision...  (maybe Peter C. will like to add 
> some comments here...).
----------------------------------------------------

Dealing with big numbers