<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_08_1416202</id>
	<title>ECMAScript Version 5 Approved</title>
	<author>timothy</author>
	<datestamp>1260283320000</datestamp>
	<htmltext>systembug writes <i>"After 10 years of waiting and some infighting, <a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">ECMAScript version 5</a> is finally out, <a href="http://www.h-online.com/open/news/item/New-version-of-JavaScript-approved-878961.html">approved by 19 of the 21 members of the ECMA Technical Committee 39</a>. <a href="http://en.wikipedia.org/wiki/Json">JSON</a> is in; Intel and IBM dissented. IBM is obviously in disagreement with the decision against IEEE 754r, a floating point format for correct, but slow representation of decimal numbers,  <a href="http://developer.yahoo.com/yui/theater/video.php?v=crockford-yuiconf2009-state">despite pleas by Yahoo's Douglas Crockford</a>."</i> (About 754r, Crockford says "It was rejected by ES4 and by ES3.1 &mdash; it was one of the few things that we could agree on. We all agreed that the IBM proposal should not go in.")</htmltext>
<tokenext>systembug writes " After 10 years of waiting and some infighting , ECMAScript version 5 is finally out , approved by 19 of the 21 members of the ECMA Technical Committee 39 .
JSON is in ; Intel and IBM dissented .
IBM is obviously in disagreement with the decision against IEEE 754r , a floating point format for correct , but slow representation of decimal numbers , despite pleas by Yahoo 's Douglas Crockford .
" ( About 754r , Crockford says " It was rejected by ES4 and by ES3.1    it was one of the few things that we could agree on .
We all agreed that the IBM proposal should not go in .
" )</tokentext>
<sentencetext>systembug writes "After 10 years of waiting and some infighting, ECMAScript version 5 is finally out, approved by 19 of the 21 members of the ECMA Technical Committee 39.
JSON is in; Intel and IBM dissented.
IBM is obviously in disagreement with the decision against IEEE 754r, a floating point format for correct, but slow representation of decimal numbers,  despite pleas by Yahoo's Douglas Crockford.
" (About 754r, Crockford says "It was rejected by ES4 and by ES3.1 — it was one of the few things that we could agree on.
We all agreed that the IBM proposal should not go in.
")</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367484</id>
	<title>Yes, in Javascript</title>
	<author>pavon</author>
	<datestamp>1260297600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>There is nothing stupid about using javascript for financial calculations. More and more applications are moving to the web, and the more you can put in the client, the more responsive the application will be. Imagine a budgeting app like Quicken on the web, or a simple loan/savings calculator whose parameters can be dynamically adjusted, and a table/graph changes in response. While critical calculations (when actually posting a payment for example) should be (re)done on the server, it would not be good if your "quick-look" rounded differently then the final result.</p><p>And no, people should not be using floating point for currency, ever, and fixed-point calcualtions aren't hard. But there is more to it that "just put everything in cents"; for example, you often have to deal with rates that are given as fractions of a cent. A decimal type would make this more convenient.</p><p>Finally, I don't know if IBM's proposal is a good one. I haven't looked at it; I was just talking in generalities.</p></htmltext>
<tokenext>There is nothing stupid about using javascript for financial calculations .
More and more applications are moving to the web , and the more you can put in the client , the more responsive the application will be .
Imagine a budgeting app like Quicken on the web , or a simple loan/savings calculator whose parameters can be dynamically adjusted , and a table/graph changes in response .
While critical calculations ( when actually posting a payment for example ) should be ( re ) done on the server , it would not be good if your " quick-look " rounded differently then the final result.And no , people should not be using floating point for currency , ever , and fixed-point calcualtions are n't hard .
But there is more to it that " just put everything in cents " ; for example , you often have to deal with rates that are given as fractions of a cent .
A decimal type would make this more convenient.Finally , I do n't know if IBM 's proposal is a good one .
I have n't looked at it ; I was just talking in generalities .</tokentext>
<sentencetext>There is nothing stupid about using javascript for financial calculations.
More and more applications are moving to the web, and the more you can put in the client, the more responsive the application will be.
Imagine a budgeting app like Quicken on the web, or a simple loan/savings calculator whose parameters can be dynamically adjusted, and a table/graph changes in response.
While critical calculations (when actually posting a payment for example) should be (re)done on the server, it would not be good if your "quick-look" rounded differently then the final result.And no, people should not be using floating point for currency, ever, and fixed-point calcualtions aren't hard.
But there is more to it that "just put everything in cents"; for example, you often have to deal with rates that are given as fractions of a cent.
A decimal type would make this more convenient.Finally, I don't know if IBM's proposal is a good one.
I haven't looked at it; I was just talking in generalities.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368548</id>
	<title>Re:use fixed point instead</title>
	<author>Yaa 101</author>
	<datestamp>1260301740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>uhm, make that times 10.000, one needs 4 decimal places for correct rounding etc.</p></htmltext>
<tokenext>uhm , make that times 10.000 , one needs 4 decimal places for correct rounding etc .</tokentext>
<sentencetext>uhm, make that times 10.000, one needs 4 decimal places for correct rounding etc.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366954</id>
	<title>Re:Financial Calculations</title>
	<author>MunkieLife</author>
	<datestamp>1260295140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Doesn't everyone know not to use floating point numbers for financial calculations?  Or at least understand the limitations or faults associated with them...</htmltext>
<tokenext>Does n't everyone know not to use floating point numbers for financial calculations ?
Or at least understand the limitations or faults associated with them.. .</tokentext>
<sentencetext>Doesn't everyone know not to use floating point numbers for financial calculations?
Or at least understand the limitations or faults associated with them...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366022</id>
	<title>point in video where Crockford talks about this</title>
	<author>Anonymous</author>
	<datestamp>1260291120000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>13:51 into the video is where you want to skip to if you want to hear just this argument.  I just don't have the time for the whole 55:42 video.  Nice non-youtube player though.</htmltext>
<tokenext>13 : 51 into the video is where you want to skip to if you want to hear just this argument .
I just do n't have the time for the whole 55 : 42 video .
Nice non-youtube player though .</tokentext>
<sentencetext>13:51 into the video is where you want to skip to if you want to hear just this argument.
I just don't have the time for the whole 55:42 video.
Nice non-youtube player though.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30452592</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>aled</author>
	<datestamp>1260884940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>According to Douglas Crockford "...it's literally hundreds of times slower than the current format.".</p></div><p>This remembers me of this joke:</p><p>

-Quick, answer this: 2+2?<br>
-3<br>
-This is wrong!<br>
-What did you want? Quickness or precision?</p><p>
The thing is a fast result with the wrong answer may not be what the user wants.

Think of money transactions and floating point operations **SHUDDERS**</p></div>
	</htmltext>
<tokenext>According to Douglas Crockford " ...it 's literally hundreds of times slower than the current format .
" .This remembers me of this joke : -Quick , answer this : 2 + 2 ?
-3 -This is wrong !
-What did you want ?
Quickness or precision ?
The thing is a fast result with the wrong answer may not be what the user wants .
Think of money transactions and floating point operations * * SHUDDERS * *</tokentext>
<sentencetext>According to Douglas Crockford "...it's literally hundreds of times slower than the current format.
".This remembers me of this joke:

-Quick, answer this: 2+2?
-3
-This is wrong!
-What did you want?
Quickness or precision?
The thing is a fast result with the wrong answer may not be what the user wants.
Think of money transactions and floating point operations **SHUDDERS**
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365928</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30373844</id>
	<title>Re:Financial Calculations</title>
	<author>ToasterMonkey</author>
	<datestamp>1260290160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Who in their right mind would use javascript for financial calculations that need to be relied on?</p></div><p>Nobody will, now.  Is this a good or bad artificial limitation?  What's the latest groupthink on this, I'm out of sync with the collective.</p></div>
	</htmltext>
<tokenext>Who in their right mind would use javascript for financial calculations that need to be relied on ? Nobody will , now .
Is this a good or bad artificial limitation ?
What 's the latest groupthink on this , I 'm out of sync with the collective .</tokentext>
<sentencetext>Who in their right mind would use javascript for financial calculations that need to be relied on?Nobody will, now.
Is this a good or bad artificial limitation?
What's the latest groupthink on this, I'm out of sync with the collective.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366782</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369118</id>
	<title>Re:Calculations in cents</title>
	<author>mpilsbury</author>
	<datestamp>1260304260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How would this work if you needed to localise your application to handle some of the Middle Eastern currencies that use 1000 sub-units instead of 100?</htmltext>
<tokenext>How would this work if you needed to localise your application to handle some of the Middle Eastern currencies that use 1000 sub-units instead of 100 ?</tokentext>
<sentencetext>How would this work if you needed to localise your application to handle some of the Middle Eastern currencies that use 1000 sub-units instead of 100?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366746</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369758</id>
	<title>Re:use fixed point instead</title>
	<author>DamonHD</author>
	<datestamp>1260263880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not all currencies have two digits after the decimal point.</p><p>Rgds</p><p>Damon</p></htmltext>
<tokenext>Not all currencies have two digits after the decimal point.RgdsDamon</tokentext>
<sentencetext>Not all currencies have two digits after the decimal point.RgdsDamon</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369684</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>angel'o'sphere</author>
	<datestamp>1260263580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Do you know what the difference between a natural number, an integral number, a rational number a real number and an  irrational number is?<br>E.g. the rational number 1/3 is not perfectly describeable as a base 10 real number (0.333333333\_).<br>There are plenty (hm, I wonder if it are "finite"<nobr> <wbr></nobr>;D) base ten real numbers that can't be expressed as base 2 real numbers, one example: 0.2. It yields an periodic irrational number in base 2.</p><p>In other words, not only 0.2 is not "describable" in base 2, nor you can't calculate 0.2 + 0.2 + 0.2 + 0.2 + 0.2<nobr> <wbr></nobr>... in Base 10 this yields 1.0 (of course), in base 2 it is slightly less than 1.0. (How do you want to handle this???)<br>See: <a href="http://www.digitconvert.com/" title="digitconvert.com">http://www.digitconvert.com/</a> [digitconvert.com]<br>Unfortunately 101 (that is 5!) * 0.001100110011001100110011001100110011001100110011001101 (that is 0.2) is rounded up to 1.0 by the online calculator, well probably you now fail to see my point, but <b>exactly</b> this rounding problem <b>is</b> my point.</p><p>angel'o'sphere</p></htmltext>
<tokenext>Do you know what the difference between a natural number , an integral number , a rational number a real number and an irrational number is ? E.g .
the rational number 1/3 is not perfectly describeable as a base 10 real number ( 0.333333333 \ _ ) .There are plenty ( hm , I wonder if it are " finite " ; D ) base ten real numbers that ca n't be expressed as base 2 real numbers , one example : 0.2 .
It yields an periodic irrational number in base 2.In other words , not only 0.2 is not " describable " in base 2 , nor you ca n't calculate 0.2 + 0.2 + 0.2 + 0.2 + 0.2 ... in Base 10 this yields 1.0 ( of course ) , in base 2 it is slightly less than 1.0 .
( How do you want to handle this ? ? ?
) See : http : //www.digitconvert.com/ [ digitconvert.com ] Unfortunately 101 ( that is 5 !
) * 0.001100110011001100110011001100110011001100110011001101 ( that is 0.2 ) is rounded up to 1.0 by the online calculator , well probably you now fail to see my point , but exactly this rounding problem is my point.angel'o'sphere</tokentext>
<sentencetext>Do you know what the difference between a natural number, an integral number, a rational number a real number and an  irrational number is?E.g.
the rational number 1/3 is not perfectly describeable as a base 10 real number (0.333333333\_).There are plenty (hm, I wonder if it are "finite" ;D) base ten real numbers that can't be expressed as base 2 real numbers, one example: 0.2.
It yields an periodic irrational number in base 2.In other words, not only 0.2 is not "describable" in base 2, nor you can't calculate 0.2 + 0.2 + 0.2 + 0.2 + 0.2 ... in Base 10 this yields 1.0 (of course), in base 2 it is slightly less than 1.0.
(How do you want to handle this???
)See: http://www.digitconvert.com/ [digitconvert.com]Unfortunately 101 (that is 5!
) * 0.001100110011001100110011001100110011001100110011001101 (that is 0.2) is rounded up to 1.0 by the online calculator, well probably you now fail to see my point, but exactly this rounding problem is my point.angel'o'sphere</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367012</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>Anonymous</author>
	<datestamp>1260295380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p> <i>IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+\% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation.</i> </p><p>ECMAScript is client side, so I don't think that was the issue. Z-series is server only, and POWER6 is almost all servers - and for POWER workstations, the ability to run javascript a little bit faster has almost zero value. The more likely explanation is that IBM has its roots in business, and puts more importance into correct decimal handling than companies with their roots in other areas where this didn't matter much.</p></div><p>Since IBM has hardware IEEE 754r support and Intel does not, IBM likely has patents on one or more critical parts of the hardware implementation.  If Intel were to implement 754r on their chips, it will likely get them sued, regardless of whether or not their engineers even looked at the patents, since there may only be one reasonable way to solve the problem.  So IBM wants to drive 754r to everyone's chips and make a bunch of money in licenses and/or lawsuits.</p><p>Pretty standard business practice in the chip business.  Just look at the history between Intel and AMD.</p></div>
	</htmltext>
<tokenext>IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99 + \ % of desktop users are running .
Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware .
This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation .
ECMAScript is client side , so I do n't think that was the issue .
Z-series is server only , and POWER6 is almost all servers - and for POWER workstations , the ability to run javascript a little bit faster has almost zero value .
The more likely explanation is that IBM has its roots in business , and puts more importance into correct decimal handling than companies with their roots in other areas where this did n't matter much.Since IBM has hardware IEEE 754r support and Intel does not , IBM likely has patents on one or more critical parts of the hardware implementation .
If Intel were to implement 754r on their chips , it will likely get them sued , regardless of whether or not their engineers even looked at the patents , since there may only be one reasonable way to solve the problem .
So IBM wants to drive 754r to everyone 's chips and make a bunch of money in licenses and/or lawsuits.Pretty standard business practice in the chip business .
Just look at the history between Intel and AMD .</tokentext>
<sentencetext> IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+\% of desktop users are running.
Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware.
This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation.
ECMAScript is client side, so I don't think that was the issue.
Z-series is server only, and POWER6 is almost all servers - and for POWER workstations, the ability to run javascript a little bit faster has almost zero value.
The more likely explanation is that IBM has its roots in business, and puts more importance into correct decimal handling than companies with their roots in other areas where this didn't matter much.Since IBM has hardware IEEE 754r support and Intel does not, IBM likely has patents on one or more critical parts of the hardware implementation.
If Intel were to implement 754r on their chips, it will likely get them sued, regardless of whether or not their engineers even looked at the patents, since there may only be one reasonable way to solve the problem.
So IBM wants to drive 754r to everyone's chips and make a bunch of money in licenses and/or lawsuits.Pretty standard business practice in the chip business.
Just look at the history between Intel and AMD.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365536</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365584</id>
	<title>Re:use fixed point instead</title>
	<author>antifoidulus</author>
	<datestamp>1260289260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Hah, if you hadn't made that mundane mistake in your little scheme it would have worked perfectly, but Lumberg is on to you, you are going to federal pound-me-in-the-ass prison!</htmltext>
<tokenext>Hah , if you had n't made that mundane mistake in your little scheme it would have worked perfectly , but Lumberg is on to you , you are going to federal pound-me-in-the-ass prison !</tokentext>
<sentencetext>Hah, if you hadn't made that mundane mistake in your little scheme it would have worked perfectly, but Lumberg is on to you, you are going to federal pound-me-in-the-ass prison!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367044</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>Anonymous</author>
	<datestamp>1260295560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>Why do processors need decimal number support? </i></p><p>One reason really sticks out. Money.<br>Decimals give easy and *exact* support for currency units and their sub-units expressed in their normal x.yy form. Binary doesn't. 0.10 (for example) cannot be expressed exactly in that form in binary no matter how many decimal places you use.</p><p>Yes, you can store these amounts exactly in binary by (e.g.) multiplying by *decimal* 100. But this is not ideal since it introduces an extra step which which may be missed out and cause incorrect results with financial consequences (e.g. sum of different inputs processed through different code paths; one input is not multiplied by 100 and you end up with a plausible looking but incorrect value; and yes, this *should* be caught in testing but not all bugs are detected, and this bug *could not occur* using decimals).</p><p>Or you could use a well-tested decimal library (which is standard practice on platforms without native decimal support). Still less efficient and more error prone (wrong library version etc.) than native support.</p></htmltext>
<tokenext>Why do processors need decimal number support ?
One reason really sticks out .
Money.Decimals give easy and * exact * support for currency units and their sub-units expressed in their normal x.yy form .
Binary does n't .
0.10 ( for example ) can not be expressed exactly in that form in binary no matter how many decimal places you use.Yes , you can store these amounts exactly in binary by ( e.g .
) multiplying by * decimal * 100 .
But this is not ideal since it introduces an extra step which which may be missed out and cause incorrect results with financial consequences ( e.g .
sum of different inputs processed through different code paths ; one input is not multiplied by 100 and you end up with a plausible looking but incorrect value ; and yes , this * should * be caught in testing but not all bugs are detected , and this bug * could not occur * using decimals ) .Or you could use a well-tested decimal library ( which is standard practice on platforms without native decimal support ) .
Still less efficient and more error prone ( wrong library version etc .
) than native support .</tokentext>
<sentencetext>Why do processors need decimal number support?
One reason really sticks out.
Money.Decimals give easy and *exact* support for currency units and their sub-units expressed in their normal x.yy form.
Binary doesn't.
0.10 (for example) cannot be expressed exactly in that form in binary no matter how many decimal places you use.Yes, you can store these amounts exactly in binary by (e.g.
) multiplying by *decimal* 100.
But this is not ideal since it introduces an extra step which which may be missed out and cause incorrect results with financial consequences (e.g.
sum of different inputs processed through different code paths; one input is not multiplied by 100 and you end up with a plausible looking but incorrect value; and yes, this *should* be caught in testing but not all bugs are detected, and this bug *could not occur* using decimals).Or you could use a well-tested decimal library (which is standard practice on platforms without native decimal support).
Still less efficient and more error prone (wrong library version etc.
) than native support.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368252</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>DragonWriter</author>
	<datestamp>1260300720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Why do processors need decimal number support?</p></div></blockquote><p>To most efficiently perform tasks that people want computers to do, which more frequently means performing correct math with numbers that have an exact base-10 representation than, say, doing the same with numbers that have an exact base-2 representation.</p><blockquote><div><p>10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.</p></div></blockquote><p>Well, unless you consider that the users of computers are generally humans, and that the uses of computers are in applications defined by humans to fit human needs, which very often involves consuming base-10 input and producting base-10 output, using either operations where conversion to a base-2 approximation of the given base-10 values for internal processing and back out may produce incorrect, or at least unnecessarily imprecise, results.</p></div>
	</htmltext>
<tokenext>Why do processors need decimal number support ? To most efficiently perform tasks that people want computers to do , which more frequently means performing correct math with numbers that have an exact base-10 representation than , say , doing the same with numbers that have an exact base-2 representation.10 is just an arbitrary number humans picked because they happen to have 10 fingers .
There 's no connection between that and computers.Well , unless you consider that the users of computers are generally humans , and that the uses of computers are in applications defined by humans to fit human needs , which very often involves consuming base-10 input and producting base-10 output , using either operations where conversion to a base-2 approximation of the given base-10 values for internal processing and back out may produce incorrect , or at least unnecessarily imprecise , results .</tokentext>
<sentencetext>Why do processors need decimal number support?To most efficiently perform tasks that people want computers to do, which more frequently means performing correct math with numbers that have an exact base-10 representation than, say, doing the same with numbers that have an exact base-2 representation.10 is just an arbitrary number humans picked because they happen to have 10 fingers.
There's no connection between that and computers.Well, unless you consider that the users of computers are generally humans, and that the uses of computers are in applications defined by humans to fit human needs, which very often involves consuming base-10 input and producting base-10 output, using either operations where conversion to a base-2 approximation of the given base-10 values for internal processing and back out may produce incorrect, or at least unnecessarily imprecise, results.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754</id>
	<title>Financial Calculations</title>
	<author>Anonymous</author>
	<datestamp>1260289980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>When you have strict regulatory rules about how rounding must be done, and your numerical system can't even represent 0.2 exactly, then it is most certainly a concern. There are other solutions, such as using base-10 fixed point calculations rather than floating point, but having decimal floating point is certainly more convenient, and having a hardware implementation is much more efficient.</p></htmltext>
<tokenext>When you have strict regulatory rules about how rounding must be done , and your numerical system ca n't even represent 0.2 exactly , then it is most certainly a concern .
There are other solutions , such as using base-10 fixed point calculations rather than floating point , but having decimal floating point is certainly more convenient , and having a hardware implementation is much more efficient .</tokentext>
<sentencetext>When you have strict regulatory rules about how rounding must be done, and your numerical system can't even represent 0.2 exactly, then it is most certainly a concern.
There are other solutions, such as using base-10 fixed point calculations rather than floating point, but having decimal floating point is certainly more convenient, and having a hardware implementation is much more efficient.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369966</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>spitzak</author>
	<datestamp>1260265080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>An improvement for both ECMAScript and Scheme, could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.</i></p><p>In C I need to turn these warnings off. In perhaps 99\% of the cases where the test is something like "x == 1.0" what is being tested is <i>not</i> "did the calculation result in 1". Instead the test that is really being done is "was the earlier statement that read x = 1.0 executed".</p><p>Unfortunatly these warnings are unable to distinguish why the test is being done, and it makes programmers do some stupid things to turn off the warnings. Changing it to some approximatly\_equal() function will actually break the logic, especially for a calculation that CANNOT result in 1.0 except by the direct assignment. This is NOT uncommon!</p><p>So stop proposing ideas without actually seeing how things are done in the real world.</p></htmltext>
<tokenext>An improvement for both ECMAScript and Scheme , could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.In C I need to turn these warnings off .
In perhaps 99 \ % of the cases where the test is something like " x = = 1.0 " what is being tested is not " did the calculation result in 1 " .
Instead the test that is really being done is " was the earlier statement that read x = 1.0 executed " .Unfortunatly these warnings are unable to distinguish why the test is being done , and it makes programmers do some stupid things to turn off the warnings .
Changing it to some approximatly \ _equal ( ) function will actually break the logic , especially for a calculation that CAN NOT result in 1.0 except by the direct assignment .
This is NOT uncommon ! So stop proposing ideas without actually seeing how things are done in the real world .</tokentext>
<sentencetext>An improvement for both ECMAScript and Scheme, could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.In C I need to turn these warnings off.
In perhaps 99\% of the cases where the test is something like "x == 1.0" what is being tested is not "did the calculation result in 1".
Instead the test that is really being done is "was the earlier statement that read x = 1.0 executed".Unfortunatly these warnings are unable to distinguish why the test is being done, and it makes programmers do some stupid things to turn off the warnings.
Changing it to some approximatly\_equal() function will actually break the logic, especially for a calculation that CANNOT result in 1.0 except by the direct assignment.
This is NOT uncommon!So stop proposing ideas without actually seeing how things are done in the real world.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366348</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368624</id>
	<title>Re:Floating point numbers and decimals</title>
	<author>DragonWriter</author>
	<datestamp>1260302040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language.</p></div> </blockquote><p>In fact, I think Scheme demonstrates pretty effectively that being dynamically typed (which, not loose typing, is what JavaScript is) is entirely compatible with having an extraordinarily elegant system of numeric representation which seamless scales from exact integer representation through exact rational representation through to inexact representations.</p></div>
	</htmltext>
<tokenext>I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language .
In fact , I think Scheme demonstrates pretty effectively that being dynamically typed ( which , not loose typing , is what JavaScript is ) is entirely compatible with having an extraordinarily elegant system of numeric representation which seamless scales from exact integer representation through exact rational representation through to inexact representations .</tokentext>
<sentencetext>I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language.
In fact, I think Scheme demonstrates pretty effectively that being dynamically typed (which, not loose typing, is what JavaScript is) is entirely compatible with having an extraordinarily elegant system of numeric representation which seamless scales from exact integer representation through exact rational representation through to inexact representations.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366656</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369064</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>DragonWriter</author>
	<datestamp>1260304020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know). IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.</p></div></blockquote><p>Well, IBM isn't the only one (outside of the world of ECMAScript standards)--which is why IEEE754-2008 ("IEEE 754r") incorporates decimal floating point and other improvements to the old version of IEEE 754 that it has <i>replaced as a standard</i>.</p><blockquote><div><p>First, it won't fix the stupid programmer bug. 754r can't guarantee exactness in every situation. For instance, (large\_num+small\_num)+small\_num == large\_num != large\_num+(small\_num + small\_num).</p></div></blockquote><p>The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.</p><blockquote><div><p>Second, ECMAScript is supposed to run on different architectures. It should not depend on specific number-representaions, not for integers and certainly not for floating points.</p></div></blockquote><p>But, supporting only the old IEEE 754 standard <i>also</i> depends on specific number representations for floating points. It just depends on ones that are less convenient from an application perspective, though easier from an implementation perspective.</p></div>
	</htmltext>
<tokenext>So 754 vs 754r boils down do this : When doing arithmetic using 754 , then 0.1 + 0.2 ! = 0.3 ( as any half decent programmer should know ) .
IBM want to fix it with a new floating point format that can do exact calculations ( under certain circumstances ) with decimal numbers.Well , IBM is n't the only one ( outside of the world of ECMAScript standards ) --which is why IEEE754-2008 ( " IEEE 754r " ) incorporates decimal floating point and other improvements to the old version of IEEE 754 that it has replaced as a standard.First , it wo n't fix the stupid programmer bug .
754r ca n't guarantee exactness in every situation .
For instance , ( large \ _num + small \ _num ) + small \ _num = = large \ _num ! = large \ _num + ( small \ _num + small \ _num ) .The problem for non-stupid programmers is ( or one of them , at any rate ) that using only binary floating point prevents simple expression of calculations with simple rounding rules , when those rules are defined in terms of base-10 numbers , which is often the case in important application domains.Second , ECMAScript is supposed to run on different architectures .
It should not depend on specific number-representaions , not for integers and certainly not for floating points.But , supporting only the old IEEE 754 standard also depends on specific number representations for floating points .
It just depends on ones that are less convenient from an application perspective , though easier from an implementation perspective .</tokentext>
<sentencetext>So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know).
IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.Well, IBM isn't the only one (outside of the world of ECMAScript standards)--which is why IEEE754-2008 ("IEEE 754r") incorporates decimal floating point and other improvements to the old version of IEEE 754 that it has replaced as a standard.First, it won't fix the stupid programmer bug.
754r can't guarantee exactness in every situation.
For instance, (large\_num+small\_num)+small\_num == large\_num != large\_num+(small\_num + small\_num).The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.Second, ECMAScript is supposed to run on different architectures.
It should not depend on specific number-representaions, not for integers and certainly not for floating points.But, supporting only the old IEEE 754 standard also depends on specific number representations for floating points.
It just depends on ones that are less convenient from an application perspective, though easier from an implementation perspective.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366348</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30386162</id>
	<title>Re:use fixed point instead</title>
	<author>badkarmadayaccount</author>
	<datestamp>1260442020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How about using rational fractions, preferentially hardware accelerated? FPUs are too big and slow anyways.</htmltext>
<tokenext>How about using rational fractions , preferentially hardware accelerated ?
FPUs are too big and slow anyways .</tokentext>
<sentencetext>How about using rational fractions, preferentially hardware accelerated?
FPUs are too big and slow anyways.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368028</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366656</id>
	<title>Re:Floating point numbers and decimals</title>
	<author>Anonymous</author>
	<datestamp>1260293520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language.  Simply adding a new up for a Decimal type that gave a stronger precision number internally, or had an extra notation for a strong number's initialization could work.  IIRC, Python has a pretty decent numerics.</htmltext>
<tokenext>I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language .
Simply adding a new up for a Decimal type that gave a stronger precision number internally , or had an extra notation for a strong number 's initialization could work .
IIRC , Python has a pretty decent numerics .</tokentext>
<sentencetext>I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language.
Simply adding a new up for a Decimal type that gave a stronger precision number internally, or had an extra notation for a strong number's initialization could work.
IIRC, Python has a pretty decent numerics.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366024</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365072</id>
	<title>FP</title>
	<author>Anonymous</author>
	<datestamp>1260287040000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Frost piss</p></htmltext>
<tokenext>Frost piss</tokentext>
<sentencetext>Frost piss</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</id>
	<title>I can guess why IBM was pushing for IEEE 754r</title>
	<author>tjwhaynes</author>
	<datestamp>1260287700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>The debate over floating point numbers in ECMAScript is interesting. IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+\% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r -  its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation. I suspect that IBM will continue to push for IEEE 754r in ECMAScript, I wonder whether Intel is considering adding IEEE 754r support to its processors in the future.

</p><p>Disclaimer: I have no contact with the IBM ECMAScript folks.

</p><p>Cheers,
<br>Toby Haynes</p></htmltext>
<tokenext>The debate over floating point numbers in ECMAScript is interesting .
IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99 + \ % of desktop users are running .
Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware .
This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation .
I suspect that IBM will continue to push for IEEE 754r in ECMAScript , I wonder whether Intel is considering adding IEEE 754r support to its processors in the future .
Disclaimer : I have no contact with the IBM ECMAScript folks .
Cheers , Toby Haynes</tokentext>
<sentencetext>The debate over floating point numbers in ECMAScript is interesting.
IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+\% of desktop users are running.
Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware.
This is an area where IBM already has a hardware implementation of IEEE 754r -  its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation.
I suspect that IBM will continue to push for IEEE 754r in ECMAScript, I wonder whether Intel is considering adding IEEE 754r support to its processors in the future.
Disclaimer: I have no contact with the IBM ECMAScript folks.
Cheers,
Toby Haynes</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367326</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>Junior J. Junior III</author>
	<datestamp>1260296940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.</p></div><p>Yes there is; the human.  Humans use base-10 quite a bit, and they use computers quite a bit.  It therefore makes a great deal of sense for humans to want to be able to use base-10 when they are using computers.  In fact, it's not at all surprising.</p></div>
	</htmltext>
<tokenext>Why do processors need decimal number support ?
10 is just an arbitrary number humans picked because they happen to have 10 fingers .
There 's no connection between that and computers.Yes there is ; the human .
Humans use base-10 quite a bit , and they use computers quite a bit .
It therefore makes a great deal of sense for humans to want to be able to use base-10 when they are using computers .
In fact , it 's not at all surprising .</tokentext>
<sentencetext>Why do processors need decimal number support?
10 is just an arbitrary number humans picked because they happen to have 10 fingers.
There's no connection between that and computers.Yes there is; the human.
Humans use base-10 quite a bit, and they use computers quite a bit.
It therefore makes a great deal of sense for humans to want to be able to use base-10 when they are using computers.
In fact, it's not at all surprising.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368656</id>
	<title>Re:Will this allow us a FOSS alternative to Flash?</title>
	<author>AP31R0N</author>
	<datestamp>1260302160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Could someone 'splain why i was modded down?  It's a legit question and not even snarky in its wording.</p></htmltext>
<tokenext>Could someone 'splain why i was modded down ?
It 's a legit question and not even snarky in its wording .</tokentext>
<sentencetext>Could someone 'splain why i was modded down?
It's a legit question and not even snarky in its wording.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365554</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365554</id>
	<title>Will this allow us a FOSS alternative to Flash?</title>
	<author>Anonymous</author>
	<datestamp>1260289140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Will this allow us a FOSS (competitive) alternative to Flash?</p><p>Because that would be sweet.</p></htmltext>
<tokenext>Will this allow us a FOSS ( competitive ) alternative to Flash ? Because that would be sweet .</tokentext>
<sentencetext>Will this allow us a FOSS (competitive) alternative to Flash?Because that would be sweet.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365938</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>kantos</author>
	<datestamp>1260290760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Intel does in fact have some support for BCD (note this is not IEEE 754r) in their processors using the <a href="http://en.wikipedia.org/wiki/Intel\_BCD\_opcode" title="wikipedia.org" rel="nofollow">BCD</a> [wikipedia.org] opcode, this could potentially be used to implement IEEE 754r</htmltext>
<tokenext>Intel does in fact have some support for BCD ( note this is not IEEE 754r ) in their processors using the BCD [ wikipedia.org ] opcode , this could potentially be used to implement IEEE 754r</tokentext>
<sentencetext>Intel does in fact have some support for BCD (note this is not IEEE 754r) in their processors using the BCD [wikipedia.org] opcode, this could potentially be used to implement IEEE 754r</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30380178</id>
	<title>Re:use fixed point instead</title>
	<author>jipn4</author>
	<datestamp>1259571720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough </i></p><p>Just like decimal coded numbers, you need a variable decimal point position.  And you can get that easily.</p><p><i>All in all, decimal floating-point arithmetics just makes more sense.</i></p><p>No, it is absolutely useless.  You want a bigint library and a small, simple fixed point library built on top of that.  "Decimal floating point" is totally useless.</p><p><i>(basically you may start missing local cents after two operations already).</i></p><p>Decimal representations don't ensure that your numbers add up correctly either.</p></htmltext>
<tokenext>If you provide a premade type or library class for fixed point , then two decimal places after the point is n't enough Just like decimal coded numbers , you need a variable decimal point position .
And you can get that easily.All in all , decimal floating-point arithmetics just makes more sense.No , it is absolutely useless .
You want a bigint library and a small , simple fixed point library built on top of that .
" Decimal floating point " is totally useless .
( basically you may start missing local cents after two operations already ) .Decimal representations do n't ensure that your numbers add up correctly either .</tokentext>
<sentencetext>If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough Just like decimal coded numbers, you need a variable decimal point position.
And you can get that easily.All in all, decimal floating-point arithmetics just makes more sense.No, it is absolutely useless.
You want a bigint library and a small, simple fixed point library built on top of that.
"Decimal floating point" is totally useless.
(basically you may start missing local cents after two operations already).Decimal representations don't ensure that your numbers add up correctly either.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365928</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>systembug</author>
	<datestamp>1260290700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>(...) I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.</p></div><p>According to Douglas Crockford "...it's literally hundreds of times slower than the current format.".</p></div>
	</htmltext>
<tokenext>( ... ) I 'm guessing that at best , 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754 , purely because of the data width.According to Douglas Crockford " ...it 's literally hundreds of times slower than the current format .
" .</tokentext>
<sentencetext>(...) I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.According to Douglas Crockford "...it's literally hundreds of times slower than the current format.
".
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365704</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366354</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>amicusNYCL</author>
	<datestamp>1260292380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I can understand why IBM dissented, but why did Intel?  If they have hardware support for the existing spec why would they dissent?  Is it over another issue?</p></htmltext>
<tokenext>I can understand why IBM dissented , but why did Intel ?
If they have hardware support for the existing spec why would they dissent ?
Is it over another issue ?</tokentext>
<sentencetext>I can understand why IBM dissented, but why did Intel?
If they have hardware support for the existing spec why would they dissent?
Is it over another issue?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260</id>
	<title>Re:use fixed point instead</title>
	<author>Anonymous</author>
	<datestamp>1260296520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.</p></div><p>There are several problems here.</p><p>First of all, quite obviously, having to do this manually is rather inefficient. I do not know if it's a big deal for JS (how much of JS code out there involves monetary calculations), but for languages which are mostly used for business applications, you really want something where you can write (a+b*c).</p><p>If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough - some currencies in the world subdivide into 10,000 subunits. So you need at least four.</p><p>Finally - and perhaps most importantly - while 4 places is enough to <em>store</em> any such value, it's not enough to do arithmetics on it, because you'll get relatively large rounding errors (basically you may start missing local cents after two operations already).</p><p>All in all, decimal floating-point arithmetics just makes more sense. It's also more generally useful than fixed-point (it's not just money where you want decimal).</p></div>
	</htmltext>
<tokenext>instead of using floating point for representing decimal numbers , one can of coarse easily use fixed point... for currency computations , just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.There are several problems here.First of all , quite obviously , having to do this manually is rather inefficient .
I do not know if it 's a big deal for JS ( how much of JS code out there involves monetary calculations ) , but for languages which are mostly used for business applications , you really want something where you can write ( a + b * c ) .If you provide a premade type or library class for fixed point , then two decimal places after the point is n't enough - some currencies in the world subdivide into 10,000 subunits .
So you need at least four.Finally - and perhaps most importantly - while 4 places is enough to store any such value , it 's not enough to do arithmetics on it , because you 'll get relatively large rounding errors ( basically you may start missing local cents after two operations already ) .All in all , decimal floating-point arithmetics just makes more sense .
It 's also more generally useful than fixed-point ( it 's not just money where you want decimal ) .</tokentext>
<sentencetext>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.There are several problems here.First of all, quite obviously, having to do this manually is rather inefficient.
I do not know if it's a big deal for JS (how much of JS code out there involves monetary calculations), but for languages which are mostly used for business applications, you really want something where you can write (a+b*c).If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough - some currencies in the world subdivide into 10,000 subunits.
So you need at least four.Finally - and perhaps most importantly - while 4 places is enough to store any such value, it's not enough to do arithmetics on it, because you'll get relatively large rounding errors (basically you may start missing local cents after two operations already).All in all, decimal floating-point arithmetics just makes more sense.
It's also more generally useful than fixed-point (it's not just money where you want decimal).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30421898</id>
	<title>Re:Financial Calculations</title>
	<author>Hurricane78</author>
	<datestamp>1260709320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Tell that to Verizon. ^^</p></htmltext>
<tokenext>Tell that to Verizon .
^ ^</tokentext>
<sentencetext>Tell that to Verizon.
^^</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371414</id>
	<title>Re:use fixed point instead</title>
	<author>DragonWriter</author>
	<datestamp>1260271920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>You would always use the smallest subdivision of a currency as the unit for calculations. For the US dollar you store everything as cents</p></div></blockquote><p>Except that there are all kinds of areas where units smaller than cents are required when working with US currency. If you don't believe me, try finding a gas station whose prices aren't specified in mils. The smallest subdivision for which coins are minted -- or which normal bank transactions can be conducted in -- is not necessarily the smallest unit that needs to be stored or used in calculations.</p></div>
	</htmltext>
<tokenext>You would always use the smallest subdivision of a currency as the unit for calculations .
For the US dollar you store everything as centsExcept that there are all kinds of areas where units smaller than cents are required when working with US currency .
If you do n't believe me , try finding a gas station whose prices are n't specified in mils .
The smallest subdivision for which coins are minted -- or which normal bank transactions can be conducted in -- is not necessarily the smallest unit that needs to be stored or used in calculations .</tokentext>
<sentencetext>You would always use the smallest subdivision of a currency as the unit for calculations.
For the US dollar you store everything as centsExcept that there are all kinds of areas where units smaller than cents are required when working with US currency.
If you don't believe me, try finding a gas station whose prices aren't specified in mils.
The smallest subdivision for which coins are minted -- or which normal bank transactions can be conducted in -- is not necessarily the smallest unit that needs to be stored or used in calculations.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368028</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368028</id>
	<title>Re:use fixed point instead</title>
	<author>Anonymous</author>
	<datestamp>1260299940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.</p></div><p>There are several problems here.</p><p>First of all, quite obviously, having to do this manually is rather inefficient. I do not know if it's a big deal for JS (how much of JS code out there involves monetary calculations), but for languages which are mostly used for business applications, you really want something where you can write (a+b*c).</p></div><p>It's mostly input and output routines that need to monkey with the decimal point. You can still write (a+b*c) when you are dealing with pennies or cents.</p><p><div class="quote"><p>If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough - some currencies in the world subdivide into 10,000 subunits. So you need at least four.</p></div><p>You would always use the smallest subdivision of a currency as the unit for calculations. For the US dollar you store everything as cents, for the Tunisian dinar you store everything as milims.</p><p><div class="quote"><p>Finally - and perhaps most importantly - while 4 places is enough to <em>store</em> any such value, it's not enough to do arithmetics on it, because you'll get relatively large rounding errors (basically you may start missing local cents after two operations already).</p></div><p>You could use some other fixed point arithmatic. One of the linked articles was talking about using "9E6" were the numbers are 64 bits scaled by 9 million. That sounds a bit strange, but gives you a fare number of places after the decimal point, and lets you store a lot of common fractions (1/3, 1/360, etc.) exactly.</p><p>Either that, or use floating point but make the unit the smallest subdivision of the currency in question. You lose a bit off the top end (so your national deficit can only go up to 10^306 dollars instead of 10^308 or whatever) but you can store exact representations for whole numbers of cents/pennies/milims.</p></div>
	</htmltext>
<tokenext>instead of using floating point for representing decimal numbers , one can of coarse easily use fixed point... for currency computations , just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.There are several problems here.First of all , quite obviously , having to do this manually is rather inefficient .
I do not know if it 's a big deal for JS ( how much of JS code out there involves monetary calculations ) , but for languages which are mostly used for business applications , you really want something where you can write ( a + b * c ) .It 's mostly input and output routines that need to monkey with the decimal point .
You can still write ( a + b * c ) when you are dealing with pennies or cents.If you provide a premade type or library class for fixed point , then two decimal places after the point is n't enough - some currencies in the world subdivide into 10,000 subunits .
So you need at least four.You would always use the smallest subdivision of a currency as the unit for calculations .
For the US dollar you store everything as cents , for the Tunisian dinar you store everything as milims.Finally - and perhaps most importantly - while 4 places is enough to store any such value , it 's not enough to do arithmetics on it , because you 'll get relatively large rounding errors ( basically you may start missing local cents after two operations already ) .You could use some other fixed point arithmatic .
One of the linked articles was talking about using " 9E6 " were the numbers are 64 bits scaled by 9 million .
That sounds a bit strange , but gives you a fare number of places after the decimal point , and lets you store a lot of common fractions ( 1/3 , 1/360 , etc .
) exactly.Either that , or use floating point but make the unit the smallest subdivision of the currency in question .
You lose a bit off the top end ( so your national deficit can only go up to 10 ^ 306 dollars instead of 10 ^ 308 or whatever ) but you can store exact representations for whole numbers of cents/pennies/milims .</tokentext>
<sentencetext>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.There are several problems here.First of all, quite obviously, having to do this manually is rather inefficient.
I do not know if it's a big deal for JS (how much of JS code out there involves monetary calculations), but for languages which are mostly used for business applications, you really want something where you can write (a+b*c).It's mostly input and output routines that need to monkey with the decimal point.
You can still write (a+b*c) when you are dealing with pennies or cents.If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough - some currencies in the world subdivide into 10,000 subunits.
So you need at least four.You would always use the smallest subdivision of a currency as the unit for calculations.
For the US dollar you store everything as cents, for the Tunisian dinar you store everything as milims.Finally - and perhaps most importantly - while 4 places is enough to store any such value, it's not enough to do arithmetics on it, because you'll get relatively large rounding errors (basically you may start missing local cents after two operations already).You could use some other fixed point arithmatic.
One of the linked articles was talking about using "9E6" were the numbers are 64 bits scaled by 9 million.
That sounds a bit strange, but gives you a fare number of places after the decimal point, and lets you store a lot of common fractions (1/3, 1/360, etc.
) exactly.Either that, or use floating point but make the unit the smallest subdivision of the currency in question.
You lose a bit off the top end (so your national deficit can only go up to 10^306 dollars instead of 10^308 or whatever) but you can store exact representations for whole numbers of cents/pennies/milims.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>Lord Lode</author>
	<datestamp>1260289320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.</htmltext>
<tokenext>Why do processors need decimal number support ?
10 is just an arbitrary number humans picked because they happen to have 10 fingers .
There 's no connection between that and computers .</tokentext>
<sentencetext>Why do processors need decimal number support?
10 is just an arbitrary number humans picked because they happen to have 10 fingers.
There's no connection between that and computers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371404</id>
	<title>Re:Floating point numbers and decimals</title>
	<author>Anonymous</author>
	<datestamp>1260271860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Every chunk of 10 bits corresponds to 3 decimal digits, that's actually quite optimal. Using 1000 out of 1024 possibilities, it's a very dense representation and hardware implementations (Power) are reasonably fast. And with 34 decimal digits of precision (in the 128 bit format), you can represent US public debt down to the cent with room to spare.</p><p>Don't forget that financial computations do not need as many operations as image processing, you don't need to compute several of them for every pixel on the display, and decimal representation gives you the right precision and saves a lot on decimalbinary conversion for display (libc's routines to convert between ASCII and IEEE-754 binary FP are over 1000 lines long, and calls external functions for multi-precision arithmetic.<br>In financial computations, you typically have to display every step, so the conversion routines to human readable form are often the dominant computation cost. Converting from IEEE-754r to a string is trivial, and ends up saving CPU time and power.</p></htmltext>
<tokenext>Every chunk of 10 bits corresponds to 3 decimal digits , that 's actually quite optimal .
Using 1000 out of 1024 possibilities , it 's a very dense representation and hardware implementations ( Power ) are reasonably fast .
And with 34 decimal digits of precision ( in the 128 bit format ) , you can represent US public debt down to the cent with room to spare.Do n't forget that financial computations do not need as many operations as image processing , you do n't need to compute several of them for every pixel on the display , and decimal representation gives you the right precision and saves a lot on decimalbinary conversion for display ( libc 's routines to convert between ASCII and IEEE-754 binary FP are over 1000 lines long , and calls external functions for multi-precision arithmetic.In financial computations , you typically have to display every step , so the conversion routines to human readable form are often the dominant computation cost .
Converting from IEEE-754r to a string is trivial , and ends up saving CPU time and power .</tokentext>
<sentencetext>Every chunk of 10 bits corresponds to 3 decimal digits, that's actually quite optimal.
Using 1000 out of 1024 possibilities, it's a very dense representation and hardware implementations (Power) are reasonably fast.
And with 34 decimal digits of precision (in the 128 bit format), you can represent US public debt down to the cent with room to spare.Don't forget that financial computations do not need as many operations as image processing, you don't need to compute several of them for every pixel on the display, and decimal representation gives you the right precision and saves a lot on decimalbinary conversion for display (libc's routines to convert between ASCII and IEEE-754 binary FP are over 1000 lines long, and calls external functions for multi-precision arithmetic.In financial computations, you typically have to display every step, so the conversion routines to human readable form are often the dominant computation cost.
Converting from IEEE-754r to a string is trivial, and ends up saving CPU time and power.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366024</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365714</id>
	<title>Re:JSON is in!?</title>
	<author>SharpFang</author>
	<datestamp>1260289860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A parser of superset of JSON was in Ecmascript. With no direct, simple or easy way to limit it to the JSON set. This is mostly OK (if dangerous) if Ecmascript is on the receiving end.</p><p>OTOH in order to generate/send JSON, things get more complicated. The usual communication is asymmetric: client-&gt;server: HTTP GET/POST, server-&gt;client: JSON. Now it would be possible to keep a symmetric connection. And accepting JSON as a standard will protect from a lot of script insertion vulnerabilities, when "JSON" could contain  code appended after the closing brace.</p></htmltext>
<tokenext>A parser of superset of JSON was in Ecmascript .
With no direct , simple or easy way to limit it to the JSON set .
This is mostly OK ( if dangerous ) if Ecmascript is on the receiving end.OTOH in order to generate/send JSON , things get more complicated .
The usual communication is asymmetric : client- &gt; server : HTTP GET/POST , server- &gt; client : JSON .
Now it would be possible to keep a symmetric connection .
And accepting JSON as a standard will protect from a lot of script insertion vulnerabilities , when " JSON " could contain code appended after the closing brace .</tokentext>
<sentencetext>A parser of superset of JSON was in Ecmascript.
With no direct, simple or easy way to limit it to the JSON set.
This is mostly OK (if dangerous) if Ecmascript is on the receiving end.OTOH in order to generate/send JSON, things get more complicated.
The usual communication is asymmetric: client-&gt;server: HTTP GET/POST, server-&gt;client: JSON.
Now it would be possible to keep a symmetric connection.
And accepting JSON as a standard will protect from a lot of script insertion vulnerabilities, when "JSON" could contain  code appended after the closing brace.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365208</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369470</id>
	<title>Re:use fixed point instead</title>
	<author>angel'o'sphere</author>
	<datestamp>1260305760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So, are you sure you really understand the difference between a floating point and a fixed point numbers?<br>Would you care to point out lets say 3 of the advantages of each and 3 of the disadvantages of each? Feel free to intermix math dis-/advantages with implementation dis-/advantages<nobr> <wbr></nobr>...</p><p>Man oh man, if you ever had implemented a fixed point math lib you would know that it lacks dozens of features a floating point implementation gives you (for a trade off, ofc).</p><p>angel'o'sphere</p></htmltext>
<tokenext>So , are you sure you really understand the difference between a floating point and a fixed point numbers ? Would you care to point out lets say 3 of the advantages of each and 3 of the disadvantages of each ?
Feel free to intermix math dis-/advantages with implementation dis-/advantages ...Man oh man , if you ever had implemented a fixed point math lib you would know that it lacks dozens of features a floating point implementation gives you ( for a trade off , ofc ) .angel'o'sphere</tokentext>
<sentencetext>So, are you sure you really understand the difference between a floating point and a fixed point numbers?Would you care to point out lets say 3 of the advantages of each and 3 of the disadvantages of each?
Feel free to intermix math dis-/advantages with implementation dis-/advantages ...Man oh man, if you ever had implemented a fixed point math lib you would know that it lacks dozens of features a floating point implementation gives you (for a trade off, ofc).angel'o'sphere</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365704</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>tjwhaynes</author>
	<datestamp>1260289860000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.</p></div><p>Clearly you've never dealt with an irate customer who has spent $$$ on your software product, has created a table using "REAL" (4-byte floating point) types and then wonders why the sums are screwing up. IEEE754 can't accurately represent most fractions in the way that humans do and this means that computers using IEEE 754 floating point give different answers to a human sitting down with pen and pencil and doing the same sums. As humans are often the consumer of the information that the computer spits out, making computers produce the correct results is important.

</p><p>There are plenty of infinite precision computing libraries out there for software developers to use. However, they are all a lot slower than the 4, 8 or 10 byte floating point IEEE 754 calculations which are supported directly by the hardware. Implementing the IEEE 754r calculations directly on the CPU means that you can get close to the same performance levels. I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.

</p><p>Cheers,
<br>Toby Haynes</p></div>
	</htmltext>
<tokenext>Why do processors need decimal number support ?
10 is just an arbitrary number humans picked because they happen to have 10 fingers .
There 's no connection between that and computers.Clearly you 've never dealt with an irate customer who has spent $ $ $ on your software product , has created a table using " REAL " ( 4-byte floating point ) types and then wonders why the sums are screwing up .
IEEE754 ca n't accurately represent most fractions in the way that humans do and this means that computers using IEEE 754 floating point give different answers to a human sitting down with pen and pencil and doing the same sums .
As humans are often the consumer of the information that the computer spits out , making computers produce the correct results is important .
There are plenty of infinite precision computing libraries out there for software developers to use .
However , they are all a lot slower than the 4 , 8 or 10 byte floating point IEEE 754 calculations which are supported directly by the hardware .
Implementing the IEEE 754r calculations directly on the CPU means that you can get close to the same performance levels .
I 'm guessing that at best , 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754 , purely because of the data width .
Cheers , Toby Haynes</tokentext>
<sentencetext>Why do processors need decimal number support?
10 is just an arbitrary number humans picked because they happen to have 10 fingers.
There's no connection between that and computers.Clearly you've never dealt with an irate customer who has spent $$$ on your software product, has created a table using "REAL" (4-byte floating point) types and then wonders why the sums are screwing up.
IEEE754 can't accurately represent most fractions in the way that humans do and this means that computers using IEEE 754 floating point give different answers to a human sitting down with pen and pencil and doing the same sums.
As humans are often the consumer of the information that the computer spits out, making computers produce the correct results is important.
There are plenty of infinite precision computing libraries out there for software developers to use.
However, they are all a lot slower than the 4, 8 or 10 byte floating point IEEE 754 calculations which are supported directly by the hardware.
Implementing the IEEE 754r calculations directly on the CPU means that you can get close to the same performance levels.
I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.
Cheers,
Toby Haynes
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371106</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>Anonymous</author>
	<datestamp>1260270420000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Do you know what the difference between a natural number, an integral number, a rational number a real number and an irrational number is?
E.g. the rational number 1/3 is not perfectly describeable as a base 10 real number (0.333333333\_).
There are plenty (hm, I wonder if it are "finite"<nobr> <wbr></nobr>;D) base ten real numbers that can't be expressed as base 2 real numbers, <b>one example: 0.2. It yields an periodic irrational number in base 2.</b></p></div>
</blockquote><p>

You should learn the definition of an irrational number yourself. From the definition of a rational number, you get that real number is rational if and only if any radix representation of it is finite or periodic.  Whether a number is rational or irrational does not depend on the radix representation at all. You're essentially saying that that 0.2 is rational and irrational, which is nonsense.<br> <br>

Of course, the point you were trying to make is correct (in one base, the radix representation of some rational number is finite, in others it's infinitely periodic), but 0.2 is most definitely not irrational.</p></div>
	</htmltext>
<tokenext>Do you know what the difference between a natural number , an integral number , a rational number a real number and an irrational number is ?
E.g. the rational number 1/3 is not perfectly describeable as a base 10 real number ( 0.333333333 \ _ ) .
There are plenty ( hm , I wonder if it are " finite " ; D ) base ten real numbers that ca n't be expressed as base 2 real numbers , one example : 0.2 .
It yields an periodic irrational number in base 2 .
You should learn the definition of an irrational number yourself .
From the definition of a rational number , you get that real number is rational if and only if any radix representation of it is finite or periodic .
Whether a number is rational or irrational does not depend on the radix representation at all .
You 're essentially saying that that 0.2 is rational and irrational , which is nonsense .
Of course , the point you were trying to make is correct ( in one base , the radix representation of some rational number is finite , in others it 's infinitely periodic ) , but 0.2 is most definitely not irrational .</tokentext>
<sentencetext>Do you know what the difference between a natural number, an integral number, a rational number a real number and an irrational number is?
E.g. the rational number 1/3 is not perfectly describeable as a base 10 real number (0.333333333\_).
There are plenty (hm, I wonder if it are "finite" ;D) base ten real numbers that can't be expressed as base 2 real numbers, one example: 0.2.
It yields an periodic irrational number in base 2.
You should learn the definition of an irrational number yourself.
From the definition of a rational number, you get that real number is rational if and only if any radix representation of it is finite or periodic.
Whether a number is rational or irrational does not depend on the radix representation at all.
You're essentially saying that that 0.2 is rational and irrational, which is nonsense.
Of course, the point you were trying to make is correct (in one base, the radix representation of some rational number is finite, in others it's infinitely periodic), but 0.2 is most definitely not irrational.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369684</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365208</id>
	<title>JSON is in!?</title>
	<author>Anonymous</author>
	<datestamp>1260287640000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>JSON was *always* in Ecmascript. It's just object literal notation, a shorthand way of instantiating an object with properties.</p></htmltext>
<tokenext>JSON was * always * in Ecmascript .
It 's just object literal notation , a shorthand way of instantiating an object with properties .</tokentext>
<sentencetext>JSON was *always* in Ecmascript.
It's just object literal notation, a shorthand way of instantiating an object with properties.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</id>
	<title>use fixed point instead</title>
	<author>StripedCow</author>
	<datestamp>1260287520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.</p><p>and if you're afraid that you might mix up floating point and fixed point numbers, just define a special type for the fixed-point numbers, and define corresponding overloaded operators... oh wait</p></htmltext>
<tokenext>instead of using floating point for representing decimal numbers , one can of coarse easily use fixed point... for currency computations , just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.and if you 're afraid that you might mix up floating point and fixed point numbers , just define a special type for the fixed-point numbers , and define corresponding overloaded operators... oh wait</tokentext>
<sentencetext>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.and if you're afraid that you might mix up floating point and fixed point numbers, just define a special type for the fixed-point numbers, and define corresponding overloaded operators... oh wait</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366746</id>
	<title>Calculations in cents</title>
	<author>tepples</author>
	<datestamp>1260294060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>When you have strict regulatory rules about how rounding must be done, and your numerical system can't even represent 0.2 exactly, then it is most certainly a concern.</p></div><p>The numerical system in use at my employer includes a fixed-point representation of money. All money values are assumed to be fractions with a denominator of exactly 100.</p></div>
	</htmltext>
<tokenext>When you have strict regulatory rules about how rounding must be done , and your numerical system ca n't even represent 0.2 exactly , then it is most certainly a concern.The numerical system in use at my employer includes a fixed-point representation of money .
All money values are assumed to be fractions with a denominator of exactly 100 .</tokentext>
<sentencetext>When you have strict regulatory rules about how rounding must be done, and your numerical system can't even represent 0.2 exactly, then it is most certainly a concern.The numerical system in use at my employer includes a fixed-point representation of money.
All money values are assumed to be fractions with a denominator of exactly 100.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366782</id>
	<title>Re:Financial Calculations</title>
	<author>MunkieLife</author>
	<datestamp>1260294240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Who in their right mind would use javascript for financial calculations that need to be relied on?</htmltext>
<tokenext>Who in their right mind would use javascript for financial calculations that need to be relied on ?</tokentext>
<sentencetext>Who in their right mind would use javascript for financial calculations that need to be relied on?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367874</id>
	<title>Re:use fixed point instead</title>
	<author>molecular</author>
	<datestamp>1260299220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.</p></div><p>and let all hell break loose when someone forgets to multiply / divide by 100, like happened here: <a href="http://entertainment.slashdot.org/story/09/11/25/1448218/Moving-Decimal-Bug-Loses-Money" title="slashdot.org" rel="nofollow">http://entertainment.slashdot.org/story/09/11/25/1448218/Moving-Decimal-Bug-Loses-Money</a> [slashdot.org]</p></div>
	</htmltext>
<tokenext>instead of using floating point for representing decimal numbers , one can of coarse easily use fixed point... for currency computations , just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.and let all hell break loose when someone forgets to multiply / divide by 100 , like happened here : http : //entertainment.slashdot.org/story/09/11/25/1448218/Moving-Decimal-Bug-Loses-Money [ slashdot.org ]</tokentext>
<sentencetext>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.and let all hell break loose when someone forgets to multiply / divide by 100, like happened here: http://entertainment.slashdot.org/story/09/11/25/1448218/Moving-Decimal-Bug-Loses-Money [slashdot.org]
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366694</id>
	<title>Re:Financial Calculations</title>
	<author>Anonymous</author>
	<datestamp>1260293760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's still phenomenally stupid to make JAVASCRIPT of all languages use a slower and less precise (!) number format because somebody may want to do financial calculations and doesn't understand floating point math enough to use fixed point math for that purpose.</p></htmltext>
<tokenext>It 's still phenomenally stupid to make JAVASCRIPT of all languages use a slower and less precise ( !
) number format because somebody may want to do financial calculations and does n't understand floating point math enough to use fixed point math for that purpose .</tokentext>
<sentencetext>It's still phenomenally stupid to make JAVASCRIPT of all languages use a slower and less precise (!
) number format because somebody may want to do financial calculations and doesn't understand floating point math enough to use fixed point math for that purpose.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368792</id>
	<title>Re:use fixed point instead</title>
	<author>DragonWriter</author>
	<datestamp>1260302700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.</p></div></blockquote><p>Of course, you still have to use floating point operations (or horrible, case-by-case workarounds) if you are doing anything other than addition and subtraction, and multiplication by integer values, even if the representation you use for the inputs and results is fixed-point, and you'll have to convert the results of the floating point operations to and from your fixed-point representation. When you don't have very specific rounding rules for the operations, this isn't problematic, but the more specific the rules you have, the more cumbersome this will be, particularly if the rules are based on base-10 representation (as the often are in real world uses) and the floating point representation is base-2.</p><p>If you have use a base-10 floating point system (representation and operations) with good support for rounding the ways you need to start with, you can express the operations you want performed on the numbers more directly in your code.</p></div>
	</htmltext>
<tokenext>instead of using floating point for representing decimal numbers , one can of coarse easily use fixed point... for currency computations , just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.Of course , you still have to use floating point operations ( or horrible , case-by-case workarounds ) if you are doing anything other than addition and subtraction , and multiplication by integer values , even if the representation you use for the inputs and results is fixed-point , and you 'll have to convert the results of the floating point operations to and from your fixed-point representation .
When you do n't have very specific rounding rules for the operations , this is n't problematic , but the more specific the rules you have , the more cumbersome this will be , particularly if the rules are based on base-10 representation ( as the often are in real world uses ) and the floating point representation is base-2.If you have use a base-10 floating point system ( representation and operations ) with good support for rounding the ways you need to start with , you can express the operations you want performed on the numbers more directly in your code .</tokentext>
<sentencetext>instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.Of course, you still have to use floating point operations (or horrible, case-by-case workarounds) if you are doing anything other than addition and subtraction, and multiplication by integer values, even if the representation you use for the inputs and results is fixed-point, and you'll have to convert the results of the floating point operations to and from your fixed-point representation.
When you don't have very specific rounding rules for the operations, this isn't problematic, but the more specific the rules you have, the more cumbersome this will be, particularly if the rules are based on base-10 representation (as the often are in real world uses) and the floating point representation is base-2.If you have use a base-10 floating point system (representation and operations) with good support for rounding the ways you need to start with, you can express the operations you want performed on the numbers more directly in your code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30370244</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>Bigjeff5</author>
	<datestamp>1260266580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.</p></div><p>But 754r doesn't solve that, it simply mitigates it like anybody who understands the floating point problem already does.  It cannot actually solve the problem, because ALL calculations done on a computer are done in binarey - there is no way around it.  That the conversion is made in the CPU (FPU more specifically) doesn't change the fact that a conversion must be made and the errors are carried over.</p><p>The problem that some people have with doing this is it hides the problem, instead of accentuates it.  Now even fewer programmers, especially new programmers, are aware there is a problem.  They will simply think "I'm not ever converting out of decimal, so these calculations will always be correct" instead of being aware of the fact that the processor is simply doing some binary&gt;decimal error mitigation for you, and problems can and will still crop up.</p><p>It isn't even floating point any more, it's decimal, so they may even have a hard time researching a well documented problem when something does come up.</p><p>It's the difference between recognizing a problem as soon as it crops up (because you ran into another FP problem and learned FP's pitfalls) instead of waiting for hours, days, or weeks learning how to correct it.</p><p>You know the old saying: Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.  Well, 754r is giving programmers fish instead of teaching them to fish, and it'll bite them in the ass 10 times harder (though 1/10th as often) when you can't figure out the problem because you have no idea there IS one (other than the fact that this one, particular calculation or another is always verifiably wrong).</p></div>
	</htmltext>
<tokenext>The problem for non-stupid programmers is ( or one of them , at any rate ) that using only binary floating point prevents simple expression of calculations with simple rounding rules , when those rules are defined in terms of base-10 numbers , which is often the case in important application domains.But 754r does n't solve that , it simply mitigates it like anybody who understands the floating point problem already does .
It can not actually solve the problem , because ALL calculations done on a computer are done in binarey - there is no way around it .
That the conversion is made in the CPU ( FPU more specifically ) does n't change the fact that a conversion must be made and the errors are carried over.The problem that some people have with doing this is it hides the problem , instead of accentuates it .
Now even fewer programmers , especially new programmers , are aware there is a problem .
They will simply think " I 'm not ever converting out of decimal , so these calculations will always be correct " instead of being aware of the fact that the processor is simply doing some binary &gt; decimal error mitigation for you , and problems can and will still crop up.It is n't even floating point any more , it 's decimal , so they may even have a hard time researching a well documented problem when something does come up.It 's the difference between recognizing a problem as soon as it crops up ( because you ran into another FP problem and learned FP 's pitfalls ) instead of waiting for hours , days , or weeks learning how to correct it.You know the old saying : Give a man a fish and you feed him for a day ; teach a man to fish and you feed him for a lifetime .
Well , 754r is giving programmers fish instead of teaching them to fish , and it 'll bite them in the ass 10 times harder ( though 1/10th as often ) when you ca n't figure out the problem because you have no idea there IS one ( other than the fact that this one , particular calculation or another is always verifiably wrong ) .</tokentext>
<sentencetext>The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.But 754r doesn't solve that, it simply mitigates it like anybody who understands the floating point problem already does.
It cannot actually solve the problem, because ALL calculations done on a computer are done in binarey - there is no way around it.
That the conversion is made in the CPU (FPU more specifically) doesn't change the fact that a conversion must be made and the errors are carried over.The problem that some people have with doing this is it hides the problem, instead of accentuates it.
Now even fewer programmers, especially new programmers, are aware there is a problem.
They will simply think "I'm not ever converting out of decimal, so these calculations will always be correct" instead of being aware of the fact that the processor is simply doing some binary&gt;decimal error mitigation for you, and problems can and will still crop up.It isn't even floating point any more, it's decimal, so they may even have a hard time researching a well documented problem when something does come up.It's the difference between recognizing a problem as soon as it crops up (because you ran into another FP problem and learned FP's pitfalls) instead of waiting for hours, days, or weeks learning how to correct it.You know the old saying: Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.
Well, 754r is giving programmers fish instead of teaching them to fish, and it'll bite them in the ass 10 times harder (though 1/10th as often) when you can't figure out the problem because you have no idea there IS one (other than the fact that this one, particular calculation or another is always verifiably wrong).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369064</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368914</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>DragonWriter</author>
	<datestamp>1260303240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>According to Douglas Crockford "...it's literally hundreds of times slower than the current format.".</p></div></blockquote><p>Presumably, that's comparing execution speed in environments with hardware support of the old standard, but using software-only for the new standard.</p></div>
	</htmltext>
<tokenext>According to Douglas Crockford " ...it 's literally hundreds of times slower than the current format .
" .Presumably , that 's comparing execution speed in environments with hardware support of the old standard , but using software-only for the new standard .</tokentext>
<sentencetext>According to Douglas Crockford "...it's literally hundreds of times slower than the current format.
".Presumably, that's comparing execution speed in environments with hardware support of the old standard, but using software-only for the new standard.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365928</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366660</id>
	<title>Re:Financial Calculations</title>
	<author>iluvcapra</author>
	<datestamp>1260293580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>If you know someone that is using IEEE floats or doubles to represent dollars internally, reach out to them and get them help, and let them know that just counting the pennies and occasionally inserting a decimal for the humans is much, much safer!<nobr> <wbr></nobr>;)</htmltext>
<tokenext>If you know someone that is using IEEE floats or doubles to represent dollars internally , reach out to them and get them help , and let them know that just counting the pennies and occasionally inserting a decimal for the humans is much , much safer !
; )</tokentext>
<sentencetext>If you know someone that is using IEEE floats or doubles to represent dollars internally, reach out to them and get them help, and let them know that just counting the pennies and occasionally inserting a decimal for the humans is much, much safer!
;)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366024</id>
	<title>Floating point numbers and decimals</title>
	<author>Anonymous</author>
	<datestamp>1260291180000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>Floating point numbers are a mess if you want to deal with currencies - rounding errors are guaranteed.

</p><p>That said, look at IBM's 754r standard: unpacking a 128-bit number in chunks of 10-bits? That's got to be the ugliest thing I've seen in a long, long time. A triple-bagger. Implementing that in software will be painfully slow - implementing it in hardware will be a gigantic kludge of dedicated circuitry.

</p><p>This is an area where ECMAscript pays the price for not being a strongly typed language. The only solution in the ECMAscript framework is to use a decimal library. Awkward, but that's life.</p></htmltext>
<tokenext>Floating point numbers are a mess if you want to deal with currencies - rounding errors are guaranteed .
That said , look at IBM 's 754r standard : unpacking a 128-bit number in chunks of 10-bits ?
That 's got to be the ugliest thing I 've seen in a long , long time .
A triple-bagger .
Implementing that in software will be painfully slow - implementing it in hardware will be a gigantic kludge of dedicated circuitry .
This is an area where ECMAscript pays the price for not being a strongly typed language .
The only solution in the ECMAscript framework is to use a decimal library .
Awkward , but that 's life .</tokentext>
<sentencetext>Floating point numbers are a mess if you want to deal with currencies - rounding errors are guaranteed.
That said, look at IBM's 754r standard: unpacking a 128-bit number in chunks of 10-bits?
That's got to be the ugliest thing I've seen in a long, long time.
A triple-bagger.
Implementing that in software will be painfully slow - implementing it in hardware will be a gigantic kludge of dedicated circuitry.
This is an area where ECMAscript pays the price for not being a strongly typed language.
The only solution in the ECMAscript framework is to use a decimal library.
Awkward, but that's life.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365536</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>teg</author>
	<datestamp>1260289080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p> <i>IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+\% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation.</i> </p><p>
ECMAScript is client side, so I don't think that was the issue. Z-series is server only, and POWER6 is almost all servers - and for POWER workstations, the ability to run javascript a little bit faster has almost zero value. The more likely explanation is that IBM has its roots in business, and puts more importance into correct decimal handling than companies with their roots in other areas where this didn't matter much.</p></htmltext>
<tokenext>IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99 + \ % of desktop users are running .
Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware .
This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation .
ECMAScript is client side , so I do n't think that was the issue .
Z-series is server only , and POWER6 is almost all servers - and for POWER workstations , the ability to run javascript a little bit faster has almost zero value .
The more likely explanation is that IBM has its roots in business , and puts more importance into correct decimal handling than companies with their roots in other areas where this did n't matter much .</tokentext>
<sentencetext> IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+\% of desktop users are running.
Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware.
This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation.
ECMAScript is client side, so I don't think that was the issue.
Z-series is server only, and POWER6 is almost all servers - and for POWER workstations, the ability to run javascript a little bit faster has almost zero value.
The more likely explanation is that IBM has its roots in business, and puts more importance into correct decimal handling than companies with their roots in other areas where this didn't matter much.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366348</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>roemcke</author>
	<datestamp>1260292380000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know). IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.</p><p>Personally a see two problems with this:</p><p>First, it won't fix the stupid programmer bug. 754r can't guarantee exactness in every situation. For instance, (large\_num+small\_num)+small\_num == large\_num != large\_num+(small\_num + small\_num).</p><p>Second, ECMAScript is supposed to run on different architectures. It should not depend on specific number-representaions, not for integers and certainly not for floating points.</p><p>In my opinion, the right thing to do is to look at Scheme. Scheme has two numeric types, exact and inexact, and leaves it to the implementation to choose what internal representation to use (normally integer or some rational number for exact numbers, and floating point for inexact). If a function can can make an exact calculation with exact numbers as input, it returns an exact number, otherwise it returns an inexact number.<br>The important here is that when the programmer needs exact calculations (for instance monetary calculation with fractional parts), he specifically chooses exact numbers and leaves it to the language-implementation to figure it out how to represent the numbers in memory.</p><p>There is only one minor problem with the scheme-way, it doesn't discourage the use of inexact numbers when it is obvious that the programmer is a moron. An improvement for both ECMAScript and Scheme, could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.</p></htmltext>
<tokenext>So 754 vs 754r boils down do this : When doing arithmetic using 754 , then 0.1 + 0.2 ! = 0.3 ( as any half decent programmer should know ) .
IBM want to fix it with a new floating point format that can do exact calculations ( under certain circumstances ) with decimal numbers.Personally a see two problems with this : First , it wo n't fix the stupid programmer bug .
754r ca n't guarantee exactness in every situation .
For instance , ( large \ _num + small \ _num ) + small \ _num = = large \ _num ! = large \ _num + ( small \ _num + small \ _num ) .Second , ECMAScript is supposed to run on different architectures .
It should not depend on specific number-representaions , not for integers and certainly not for floating points.In my opinion , the right thing to do is to look at Scheme .
Scheme has two numeric types , exact and inexact , and leaves it to the implementation to choose what internal representation to use ( normally integer or some rational number for exact numbers , and floating point for inexact ) .
If a function can can make an exact calculation with exact numbers as input , it returns an exact number , otherwise it returns an inexact number.The important here is that when the programmer needs exact calculations ( for instance monetary calculation with fractional parts ) , he specifically chooses exact numbers and leaves it to the language-implementation to figure it out how to represent the numbers in memory.There is only one minor problem with the scheme-way , it does n't discourage the use of inexact numbers when it is obvious that the programmer is a moron .
An improvement for both ECMAScript and Scheme , could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality .</tokentext>
<sentencetext>So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know).
IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.Personally a see two problems with this:First, it won't fix the stupid programmer bug.
754r can't guarantee exactness in every situation.
For instance, (large\_num+small\_num)+small\_num == large\_num != large\_num+(small\_num + small\_num).Second, ECMAScript is supposed to run on different architectures.
It should not depend on specific number-representaions, not for integers and certainly not for floating points.In my opinion, the right thing to do is to look at Scheme.
Scheme has two numeric types, exact and inexact, and leaves it to the implementation to choose what internal representation to use (normally integer or some rational number for exact numbers, and floating point for inexact).
If a function can can make an exact calculation with exact numbers as input, it returns an exact number, otherwise it returns an inexact number.The important here is that when the programmer needs exact calculations (for instance monetary calculation with fractional parts), he specifically chooses exact numbers and leaves it to the language-implementation to figure it out how to represent the numbers in memory.There is only one minor problem with the scheme-way, it doesn't discourage the use of inexact numbers when it is obvious that the programmer is a moron.
An improvement for both ECMAScript and Scheme, could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30370940</id>
	<title>Re:use fixed point instead</title>
	<author>Anonymous</author>
	<datestamp>1260269700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>In a recent project of mine, I needed very high levels of application-specific clock accuracy over long periods with thousands to millions of iterations. This was my first time developing a major project, and with that freedom came the thought "Why not use an integer representation?"</p><p>In both my application and with currency apps, you're going to have a level of inaccuracy regardless of whether it's floating point or integer-based. One of the key differences is that with integer-based representation the level of inaccuracy is much more immediately apparent -- with a quick formula, I was able to mathematically describe precisely the level of accuracy maintained over a precise amount of time. With floating-point, almost everyone simply does hand-waving. Even the more careful engineers will follow a set of guidelines to try to maintain accuracy, but I doubt many of them will mathematically prove the limitations of the accuracy of their floating-point algorithms which is relatively easy to do with integer-based values.</p><p>The question I would have is how well-defined are the range of values needed for representation? The more well-defined they are, the more inclined I'd be to argue for floating point. In this particular case, you'd have to ask what the largest currency value it is that they want to be able to represent. If they know the number, define the format such that excess digits go to the right of the decimal point and you'll be able to derive accuracy levels for various operations and combinations of operations. In my case, I had a well-defined range of clocks speeds that allowed me to maintain effective accuracy (i.e., output kept completely accurate) with running times over a year while most use cases would involve running the app for less than fifteen minutes.</p></htmltext>
<tokenext>In a recent project of mine , I needed very high levels of application-specific clock accuracy over long periods with thousands to millions of iterations .
This was my first time developing a major project , and with that freedom came the thought " Why not use an integer representation ?
" In both my application and with currency apps , you 're going to have a level of inaccuracy regardless of whether it 's floating point or integer-based .
One of the key differences is that with integer-based representation the level of inaccuracy is much more immediately apparent -- with a quick formula , I was able to mathematically describe precisely the level of accuracy maintained over a precise amount of time .
With floating-point , almost everyone simply does hand-waving .
Even the more careful engineers will follow a set of guidelines to try to maintain accuracy , but I doubt many of them will mathematically prove the limitations of the accuracy of their floating-point algorithms which is relatively easy to do with integer-based values.The question I would have is how well-defined are the range of values needed for representation ?
The more well-defined they are , the more inclined I 'd be to argue for floating point .
In this particular case , you 'd have to ask what the largest currency value it is that they want to be able to represent .
If they know the number , define the format such that excess digits go to the right of the decimal point and you 'll be able to derive accuracy levels for various operations and combinations of operations .
In my case , I had a well-defined range of clocks speeds that allowed me to maintain effective accuracy ( i.e. , output kept completely accurate ) with running times over a year while most use cases would involve running the app for less than fifteen minutes .</tokentext>
<sentencetext>In a recent project of mine, I needed very high levels of application-specific clock accuracy over long periods with thousands to millions of iterations.
This was my first time developing a major project, and with that freedom came the thought "Why not use an integer representation?
"In both my application and with currency apps, you're going to have a level of inaccuracy regardless of whether it's floating point or integer-based.
One of the key differences is that with integer-based representation the level of inaccuracy is much more immediately apparent -- with a quick formula, I was able to mathematically describe precisely the level of accuracy maintained over a precise amount of time.
With floating-point, almost everyone simply does hand-waving.
Even the more careful engineers will follow a set of guidelines to try to maintain accuracy, but I doubt many of them will mathematically prove the limitations of the accuracy of their floating-point algorithms which is relatively easy to do with integer-based values.The question I would have is how well-defined are the range of values needed for representation?
The more well-defined they are, the more inclined I'd be to argue for floating point.
In this particular case, you'd have to ask what the largest currency value it is that they want to be able to represent.
If they know the number, define the format such that excess digits go to the right of the decimal point and you'll be able to derive accuracy levels for various operations and combinations of operations.
In my case, I had a well-defined range of clocks speeds that allowed me to maintain effective accuracy (i.e., output kept completely accurate) with running times over a year while most use cases would involve running the app for less than fifteen minutes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366490</id>
	<title>Re:I can guess why IBM was pushing for IEEE 754r</title>
	<author>LWATCDR</author>
	<datestamp>1260292860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Is IEE754r a superset of 754? If couldn't it be used on hardware that supports it as an option?<br>Also what does ARM support? Some Arm cores now have FPUs and that is an important architecture for Mobile and is going to be a big percentage of the systems running ECMAScript in the future.</p></htmltext>
<tokenext>Is IEE754r a superset of 754 ?
If could n't it be used on hardware that supports it as an option ? Also what does ARM support ?
Some Arm cores now have FPUs and that is an important architecture for Mobile and is going to be a big percentage of the systems running ECMAScript in the future .</tokentext>
<sentencetext>Is IEE754r a superset of 754?
If couldn't it be used on hardware that supports it as an option?Also what does ARM support?
Some Arm cores now have FPUs and that is an important architecture for Mobile and is going to be a big percentage of the systems running ECMAScript in the future.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365714
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365208
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366024
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369470
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368914
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365928
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30370940
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366022
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368656
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365554
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367326
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366490
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367012
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365536
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367484
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366656
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366024
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30421898
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366660
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367044
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30380178
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30386162
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368028
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371106
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369684
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366354
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365584
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30452592
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365928
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371414
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368028
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366694
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30373844
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366782
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366348
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369758
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369118
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366746
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365938
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368548
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367874
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_08_1416202_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30370244
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369064
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366348
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_08_1416202.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365938
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365536
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367012
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366022
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366354
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366490
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366348
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369064
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30370244
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369966
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365610
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365754
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367484
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366782
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30373844
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366746
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369118
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366694
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366660
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30421898
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366954
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369684
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371106
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368252
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367326
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367044
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365704
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365928
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368914
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30452592
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_08_1416202.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366024
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371404
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30366656
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368624
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_08_1416202.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365208
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365714
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_08_1416202.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365168
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365584
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367874
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369758
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30367260
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30370940
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368028
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30371414
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30386162
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30380178
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30369470
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368548
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368792
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_08_1416202.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30365554
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_08_1416202.30368656
</commentlist>
</conversation>
