Thank you,
Melih
On 3/13/07, *Ron Wheeler* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
elibol wrote:
> Your example uses a machine which solves to a working precision.
>
> If I were to do that problem by hand, 100/3 would be 100 over 3, and
> when multiplied by 3, it would be 100.
Show the intermediate storage of 100/3 in writing. You are making
a leap
("I see a string of 3s as far as the eye can see, so I can assume that
it goes on forever") that a computer is not able to do since the can
only see to end of its mantissa and is not supposed to make guesses
about how the number might turn out if only it had more places to
store
the least significant digits.
>
> I understand working precision, and floating point arithmetic,
> however, I don't understand how the parsing algorithms differ,
> specifically, why parseDouble has greater precision than AS3
> parseFloat, and why AS1 parseFloat (up to 1.0e+63) even has greater
> precision than AS3 parseFloat.
>
"up to 1.0e+63" says nothing about precision. This is the exponent it
deals with magnitude not precision. Precision is determined by the
mantisa.
The maximum exponent allowed is determined by the hardware as is the
number of bits in the mantissa.. There are some general statements
about
what float can stand and what double can handle but no one makes any
promises about the last few bits of the mantissa.
From Wikipedia http://en.wikipedia.org/wiki/Floating_point
The arithmetical distance between two consecutive representable
floating
point numbers is called an "ULP", for Unit in the Last Place. For
example, the numbers represented by 45670123 and 45670124
hexadecimal is
one ULP. An ULP is about 10^-7 in single precision, and 10^-16 in
double
precision. The mandated behavior of IEEE-compliant hardware is
that the
result be within one-half of an ULP.
This tells you exactly what is supposed to happen - 7 digits of
information in floating point and 16 in double
and the last bit can be off by 1/2.
If you look carefully at your previous examples, you will see that
the
differences that are bothering you are in the last bits that are
carried. (count the zeroes between the 6.3 part and the "spurious" 1.)
In my simple floating point processor
100 times 4 divided by 3 is not the same as 100 divided by 3 times 4
100*4=400/3=133.33
100/3=33.33*4=133.32
You can see that the point as it relates to your issue is that the
sequence in which operations are performed makes a difference. If 2
different programmers write the same (or in your case, similar)
calculations, using floating point arithmetic, the hardware's
"guarding"
of the least significant bits may be different and the results may be
different in the last few bits.
> Leave God out of this :P
>
> Melih
>
> On 3/13/07, *elibol* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> Thank you Ron,
>
> Melih
>
>
> On 3/10/07, *Ron Wheeler* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
>
>
> elibol wrote:
> > Hmm, I understand how the first operand does not
represent
> the parsed
> > string
> > in:
> >
> > trace(6.30000000000000e+51 == 6.3e+51);
> >
> > And how what trace prints is just the string
representation
> of the
> > number...
> >
> > I guess the point of the final experiment is that the
> solution is to
> > parse
> > the float without the exponent, because the string will
> always be human
> > input, so the number would always be whatever float to
the +-
> exponent.
> >
> > Here is the Java double:
> >
> > http://people.uncw.edu/tompkinsj/133/Numbers/Reals.htm
> >
> > Shouldn't this make the as3 Number equal to the Java
Double?
> Both are
> > represented using the IEEE 754 standard.
> >
> > In Java, doubles are parsed and represented exactly up to
> 1.0e+308. This
> > goes up to the largest value the language can handle.
> >
> > In as3, Numbers lose precision at about 1.0e+32.
> Numbers lose precision when bits are generated in the
mantissa
> that go
> past the number of bits available in the hardware.
> The exponent has nothing to do with it. It is simply
stored as
> a byte at
> the front of the word.
>
> If you do some math by hand on a calculator with 2
decimal points
> 100/3 = 33.33 which when multiplied by 3 is only 99.99 so
> arithmetic
> does not work in real life
>
> 100 times 4 divided by 3 is not the same as 100 divided by 3
> times 4
> 100*4=400/3=133.33
> 100/3=33.33*4=133.32
> Submit a bug report to God.
>
> >
> > Would it make sense to build a parseDouble function
for as3?
> Could
> > that be
> > the problem?
> >
> > Do I have to do some more reading? I think so.
> >
> > kk,
> >
> > thank you Ron and Andy.
> >
> > On 3/9/07, Andy Herrman < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
> >>
> >> Oh, and this:
> >>
> >> parseFloat(n2Split[0])
> >>
> >> also adds errors. The number (6.3) probably can't be
accurately
> >> represented in float/double format, so it's not quite 6.3
> (it might be
> >> 6.3000000000000005123412, for example). So, when you then
> multiply it
> >> by the power of 10 it won't be the same as when it was
> simply parsed
> >> from the full string.
> >>
> >> -Andy
> >>
> >> On 3/9/07, Andy Herrman < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
wrote:
> >> > I think the problem here is that this:
> >> >
> >> > var n2:Number = parseFloat(n2Split[0])* Math.pow(10,
> >> parseInt(n2Split[1]));
> >> >
> >> > is not the same as doing the math. When you define
it as a
> string the
> >> > code will convert the number directly, trying to get as
> close as it
> >> > can to the value.
> >> >
> >> > However, in the code you have there you're not
doing the
> same thing as
> >> > the string. Math.pow is going to be using
floats/doubles
> in order to
> >> > calculate the power. The instant that happens you lose
> accuracy, so
> >> > before you even do the multiplication you've lost
> accuracy, so the
> >> > resulting number won't be the same. So in fact, you
aren't
> deriving
> >> > the same value. This is the problem with floats.
> >> >
> >> > Also, you try to do this to show that they should
be the same:
> >> > trace(n1);//6.30000000000000e+51
> >> > trace(n2);//6.3e+51
> >> > trace( 6.30000000000000e+51 == 6.3e+51);//true
> >> >
> >> > However, n1 != 6.30000000000000e+51.
> >> >
> >> > 6.30000000000000e+51 is simply the approximation that
> Flash uses when
> >> > converting it back to a string. It maxes out at a
certain
> number of
> >> > digits after the decimal point, so the string
> representation isn't
> >> > accurate. As your math later shows, there would be more
> digits way
> >> > back at the 36th position (where the first digit is
the 51st
> >> > position).
> >> >
> >> > I hope that helps to explain it a bit.
> >> >
> >> > -Andy
> >> >
> >> > On 3/9/07, elibol <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
> >> > > I stated the origin of the number and what I want
to do
> with it. The
> >> number
> >> > > is derived from a string using parseFloat, and it
simply
> needs to
> >> serve its
> >> > > purpose as an operand in an expression.
> >> > >
> >> > > The relevant point of this discussion is that a
hard coded
> >> assignment
> >> of
> >> > > 6.3e+51 to a Number yields different results than
> 6.3e+51 parsed
> >> from
> >> a
> >> > > string using the top level parseFloat() function
in as3.
> >> > >
> >> > > It's a matter of consistency, not precision.
> >> > >
> >> > > What I specifically mean: How the number is derived
> should not
> >> affect
> >> what
> >> > > it does. The number should simply represent the
value it's
> >> suppose to.
> >> > >
> >> > > Another experiment to elaborate on this point:
> >> > >
> >> > > var test1_str:String = " 6.3e+51";
> >> > > var n1:Number = parseFloat(test1_str);
> >> > > var n2Split:Array = test1_str.split("e+");
> >> > > var n2:Number = parseFloat(n2Split[0])* Math.pow(10,
> >> parseInt(n2Split[1]));
> >> > >
> >> > > trace(n1);//6.30000000000000e+51
> >> > > trace(n2);//6.3e+51
> >> > > trace(6.30000000000000e+51 == 6.3e+51 );//true
> >> > > trace(n1 == n2);//false
> >> > > trace(n1 == 6.3e+51);//false
> >> > > trace(n2 == 6.3e+51);//true
> >> > > trace(n1-6.3e+51);//1.32922799578491e+36
> >> > > trace(n2-6.3e+51);//0
> >> > >
> >> > > On 3/9/07, Ron Wheeler <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
> >> > > >
> >> > > > If you really have a number with 52 decimal
digits of
> precision
> >> > > > required, you can not store it in a double.
> >> > > > I believe that a double is only good for about
16-17
> digits.
> >> > > >
> >> > > > What is the origin of such a number and what do you
> want to do
> >> with
> >> it?
> >> > > >
> >> > > > You will have to write all of your own
arithmetic or
> find a
> >> package
> >> > > > designed to work with large numbers with high
precision.
> >> > > >
> >> > > > There are probably ways to deal with this but
ordinary
> float or
> >> double
> >> > > > will not do it even in JVM. You may get one
test to
> work but there
> >> is no
> >> > > > assurance that with a different sequence of
operations
> with
> >> different
> >> > > > numbers you will not get a different result
since the
> hardware is
> >> > > > throwing away the extra precision.
> >> > > >
> >> > > > Ron
> >> > > >
> >> > > > elibol wrote:
> >> > > > > Thank you Jim.
> >> > > > >
> >> > > > > To clarify the problem we are discussing, when a
> string is
> >> parsed
> >> into a
> >> > > > > number, and the string is representing a very
large
> number, the
> >> number
> >> > > > > does
> >> > > > > not yield the expected results when used in an
> operation.
> >> This is
> >> > > > > demonstrated in the first modulo experiment.
This
> issue does not
> >> exist
> >> > > > in
> >> > > > > AVM1 or JVM.
> >> > > > >
> >> > > > > "From previous data packing experiments, I've
found
> that the
> >> last
> >> nibble
> >> > > > > (4 bits) of a 64-bit Number isn't reliable
when you're
> >> casting to
> >> and
> >> > > > > from Numbers (e.g . reading 8 bytes out of a
> ByteArray into a
> >> Number or
> >> > > > > doing round-trips via the toString and
parseFloat
> methods). I'm
> >> not
> >> > > > > sure why this is the case--perhaps someone from
> Adobe can reply
> >> and
> >> > > > > speak to this particular issue."
> >> > > > >
> >> > > > > This seems relevant, as 6.3e+51 would require an
> allocation of 3
> >> 64 bit
> >> > > > > Numbers (approx. 173) to be represented, using at
> least 2
> >> sets of
> >> those
> >> > > > 4
> >> > > > > unreliable bits you've mentioned. Is this
correct?
> >> > > > >
> >> > > > > Is there a solution/technique for correctly
> representing such
> >> parsed
> >> > > > > Numbers? The subject Number will be concerned
with
> properly
> >> > > > > representing its
> >> > > > > value in order to be used in any operation
supported
> by as3.
> >> > > > >
> >> > > > > Is it impossible to write a parseFloat
function that
> would
> >> correctly
> >> > > > > parse
> >> > > > > Numbers under the new Number specification?
> >> > > > >
> >> > > > > Thank you Fumio and Jim.
> >> > > > >
> >> > > > > Note: I posted this 2 days ago and I didn't
notice
> that I got an
> >> > > > > Undeliverable error. I've been getting these
a lot.
> Not sure
> >> what
> >> the
> >> > > > > deal
> >> > > > > is...
> >> > > > >
> >> > > > > On 3/7/07, elibol <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
> >> > > > >>
> >> > > > >> To clarify the problem we are discussing,
when a
> string is
> >> parsed
> >> into
> >> > > > a
> >> > > > >> number, and the string is representing a
very large
> number, the
> >> > > > >> number does
> >> > > > >> not yield the expected results when used in an
> operation.
> >> This is
> >> > > > >> demonstrated in the first modulo experiment.
This
> issue does
> >> not
> >> > > > >> exist in
> >> > > > >> AVM1 or JVM.
> >> > > > >>
> >> > > > >> On 3/7/07, elibol <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
> >> > > > >> >
> >> > > > >> > Thank you Jim.
> >> > > > >> >
> >> > > > >> > "From previous data packing experiments, I've
> found that the
> >> last
> >> > > > >> nibble
> >> > > > >> > (4 bits) of a 64-bit Number isn't reliable
when
> you're
> >> casting
> >> to and
> >> > > > >> > from Numbers ( e.g . reading 8 bytes out of a
> ByteArray into a
> >> > > > >> Number or
> >> > > > >> > doing round-trips via the toString and
parseFloat
> >> methods). I'm not
> >> > > > >> > sure why this is the case--perhaps someone
from
> Adobe can
> >> reply
> >> and
> >> > > > >> > speak to this particular issue."
> >> > > > >> >
> >> > > > >> > This seems relevant, as 6.3e+51 would
require an
> >> allocation of
> >> 3 64
> >> > > > >> bit
> >> > > > >> > Numbers (approx. 173) to be represented,
using at
> least 2
> >> sets
> >> of
> >> > > > >> those 4
> >> > > > >> > unreliable bits you've mentioned. Is this
correct?
> >> > > > >> >
> >> > > > >> > Is there a solution/technique for correctly
> representing such
> >> parsed
> >> > > > >> > Numbers? The subject Number will be concerned
> with properly
> >> > > > >> representing its
> >> > > > >> > value in order to be used in any operation
> supported by as3.
> >> > > > >> >
> >> > > > >> > Is it impossible to write a parseFloat
function
> that would
> >> correctly
> >> > > > >> > parse Numbers under this specification?
> >> > > > >> >
> >> > > > >> > Thank you Fumio and Jim.
> >> > > > >> >
> >> > > > >> > On 3/6/07, Jim Cheng <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
> >> > > > >> > >
> >> > > > >> > > Fumio Nonaka wrote:
> >> > > > >> > > > 2 floating point numbers are NOT "close
> enough". That IS
> >> the
> >> > > > >> > > problem.
> >> > > > >> > > >
> >> > > > >> > > > var _str:String = " 1.2e+51";
> >> > > > >> > > > var n:Number = parseFloat(_str);
> >> > > > >> > > > trace(( n-1.2e+51 ) >
> >> 100000000000000000000000000000000000); //
> >> > > > >> > > true
> >> > > > >> > >
> >> > > > >> > > In ActionScript 3, the native Number
data type is
> >> internally
> >> > > > >> > > represented
> >> > > > >> > > as a IEEE-754 double-precision
floating-point
> number.
> >> Due to
> >> the
> >> > > > >> way
> >> > > > >> > > that the IEEE-754 standard defines how
the bits
> are used to
> >> > > > >> represent
> >> > > > >> > > the number, the accuracy of the mantissa
precision
> >> (always 52
> >> > > > >> bits, or
> >> > > > >> > > 16 decimal digits) changes depending on the
> exponent
> >> (always
> >> 11
> >> > > > >> bits).
> >> > > > >> > >
> >> > > > >> > > See: http://en.wikipedia.org/wiki/IEEE_754
> >> > > > >> > >
> >> > > > >> > > This is to say, the "close enough" value
that
> you need to
> >> compare
> >> > > > >> the
> >> > > > >> > > absolute difference between the two Numbers
> scales in
> >> magnitude
> >> > > > with
> >> > > > >> > > the
> >> > > > >> > > exponent. This can be particularly bad
if you need
> >> arbitrary
> >> > > > >> > > precision,
> >> > > > >> > > ( e.g. when doing financial or scientific
> calcuations), as
> >> while
> >> > > > >> > > 1.32e+36
> >> > > > >> > > is paltry compared to 1.2e+51, no one would
> want to be
> >> swindled
> >> > > > >> out of
> >> > > > >> > > 1.32e+36 dollars due to faulty floating
point
> comparisons,
> >> hence
> >> > > > the
> >> > > > >> > > need for arbitrary precision integer
libraries
> for such
> >> > > > applications
> >> > > > >> > > as
> >> > > > >> > > was recently mentioned on this list.
> >> > > > >> > >
> >> > > > >> > > Fortunately however, if you don't need this
> kind of exact
> >> > > > precision,
> >> > > > >> > > but
> >> > > > >> > > simply need to match large values originally
> parsed from
> >> strings to
> >> > > > >> > > Numbers as per your example, there is a
much
> better and
> >> easier
> >> > > > >> way to
> >> > > > >> > > compare very large Numbers in ActionScript
> 3--by inspecting
> >> them at
> >> > > > >> > > the
> >> > > > >> > > bit level following the IEEE-754
specification.
> >> > > > >> > >
> >> > > > >> > > From previous data packing experiments, I've
> found that the
> >> last
> >> > > > >> > > nibble
> >> > > > >> > > (4 bits) of a 64-bit Number isn't
reliable when
> you're
> >> casting to
> >> > > > >> and
> >> > > > >> > > from Numbers (e.g. reading 8 bytes out of a
> ByteArray
> >> into a
> >> > > > >> Number or
> >> > > > >> > > doing round-trips via the toString and
parseFloat
> >> methods). I'm
> >> > > > not
> >> > > > >> > > sure why this is the case--perhaps
someone from
> Adobe can
> >> reply and
> >> > > > >> > > speak to this particular issue.
> >> > > > >> > >
> >> > > > >> > > That being said, all you really need to
do for a
> >> nearly-equals
> >> > > > >> Number
> >> > > > >> > > comparison is a byte-by-byte comparison save
> for the last
> >> byte, in
> >> > > > >> > > which
> >> > > > >> > > case you only compare the four most
significant
> bits.
> >> If all
> >> bits
> >> > > > >> > > aside
> >> > > > >> > > from the last nibble match, the Numbers are
> close enough.
> >> > > > >> > >
> >> > > > >> > > Here's how I do it:
> >> > > > >> > >
> >> > > > >> > > <code>
> >> > > > >> > >
> >> > > > >> > > /**
> >> > > > >> > > * Compare two ActionScript 3 Numbers for
> near-equality.
> >> > > > >> > > *
> >> > > > >> > > * @param The first Number
> >> > > > >> > > * @param The second Number
> >> > > > >> > > *
> >> > > > >> > > * @return True on near-equality, false
otherwise.
> >> > > > >> > > */
> >> > > > >> > > public function closeEnough(a:Number,
> b:Number):Boolean {
> >> > > > >> > > var ba:ByteArray, i:uint;
> >> > > > >> > > if (a == b) {
> >> > > > >> > > // A is explicitly equal to B
> >> > > > >> > > return true;
> >> > > > >> > > }
> >> > > > >> > > else {
> >> > > > >> > > // A isn't exactly equal to B, so we
need to
> >> > > > >> > > // check the Numbers' bytes one byte at
a time.
> >> > > > >> > > ba = new ByteArray();
> >> > > > >> > > ba.writeDouble(a);
> >> > > > >> > > ba.writeDouble(b);
> >> > > > >> > >
> >> > > > >> > > // If any of the first 7 bytes differ, then
> >> > > > >> > > // the two values are not close enough.
> >> > > > >> > > for (i = 0; i < 7; i++) {
> >> > > > >> > > if (ba[i] != ba[i + 8]) {
> >> > > > >> > > return false;
> >> > > > >> > > }
> >> > > > >> > > }
> >> > > > >> > >
> >> > > > >> > > // Mask the last four bits out and
compare the
> >> > > > >> > > // last byte. If they match, the Numbers are
> >> > > > >> > > // close enough. The last nibble tends
not to
> >> > > > >> > > // be reliable enough for comparison, so we
> >> > > > >> > > // allow these to differ and the two Numbers
> >> > > > >> > > // still be considered close enough.
> >> > > > >> > > if ((ba[7] & 0xf0) != (ba[15] & 0xf0)) {
> >> > > > >> > > return false;
> >> > > > >> > > }
> >> > > > >> > > }
> >> > > > >> > > return true;
> >> > > > >> > > }
> >> > > > >> > >
> >> > > > >> > > </code>
> >> > > > >> > >
> >> > > > >> > > Jim Cheng
> >> > > > >> > > effectiveUI
> >> > > > >> > >
_______________________________________________
> >> > > > >> > > [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> >> > > > >> > > To change your subscription options or
search
> the archive:
> >> > > > >> > >
>
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
<http://chattyfig.figleaf.com/mailman/listinfo/flashcoders>
>
<http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
<http://chattyfig.figleaf.com/mailman/listinfo/flashcoders>>
> >> > > > >> > >
> >> > > > >> > > Brought to you by Fig Leaf Software
> >> > > > >> > > Premier Authorized Adobe Consulting and
Training
> >> > > > >> > > http://www.figleaf.com
> >> > > > >> > > http://training.figleaf.com
> >> > > > >> > >
> >> > > > >> >
> >> > > > >> >
> >> > > > >>
> >> > > > > _______________________________________________
> >> > > > > [email protected]
<mailto:[email protected]>
> <mailto: [email protected]
<mailto:[email protected]>>
> >> > > > > To change your subscription options or search the
> archive:
> >> > > > >
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >> > > > >
> >> > > > > Brought to you by Fig Leaf Software
> >> > > > > Premier Authorized Adobe Consulting and Training
> >> > > > > http://www.figleaf.com
> >> > > > > http://training.figleaf.com
> >> > > > >
> >> > > > >
> >> > > > _______________________________________________
> >> > > > [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> >> > > > To change your subscription options or search
the archive:
> >> > > >
>
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
<http://chattyfig.figleaf.com/mailman/listinfo/flashcoders>
> < http://chattyfig.figleaf.com/mailman/listinfo/flashcoders>
> >> > > >
> >> > > > Brought to you by Fig Leaf Software
> >> > > > Premier Authorized Adobe Consulting and Training
> >> > > > http://www.figleaf.com
> >> > > > http://training.figleaf.com
> >> > > >
> >> > > _______________________________________________
> >> > > [email protected]
<mailto:[email protected]>
> <mailto: [email protected]
<mailto:[email protected]>>
> >> > > To change your subscription options or search the
archive:
> >> > >
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >> > >
> >> > > Brought to you by Fig Leaf Software
> >> > > Premier Authorized Adobe Consulting and Training
> >> > > http://www.figleaf.com
> >> > > http://training.figleaf.com
> >> > >
> >> >
> >> _______________________________________________
> >> [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> >> To change your subscription options or search the
archive:
> >>
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
<http://chattyfig.figleaf.com/mailman/listinfo/flashcoders>
> >>
> >> Brought to you by Fig Leaf Software
> >> Premier Authorized Adobe Consulting and Training
> >> http://www.figleaf.com <http://www.figleaf.com>
> >> http://training.figleaf.com
> >>
> > _______________________________________________
> > [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > To change your subscription options or search the
archive:
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> <
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
<http://chattyfig.figleaf.com/mailman/listinfo/flashcoders>>
> >
> > Brought to you by Fig Leaf Software
> > Premier Authorized Adobe Consulting and Training
> > http://www.figleaf.com <http://www.figleaf.com>
> > http://training.figleaf.com
> >
> >
> _______________________________________________
> [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
>
>
