[Pharo-project] Clarifying and optimizing Integer>>asFloat
It's too long for a mail, but all explained here: http://smallissimo.blogspot.com/2011/09/clarifying-and-optimizing.html Optimizing such kernel message is important - for example when reading a file of floats... Which version do you prefer ? Shall comments be that long ? Any other opinion ? Nicolas
Hello nicolas On Sep 22, 2011, at 12:17 AM, Nicolas Cellier wrote:
It's too long for a mail, but all explained here: http://smallissimo.blogspot.com/2011/09/clarifying-and-optimizing.html
Optimizing such kernel message is important - for example when reading a file of floats... Which version do you prefer ? Shall comments be that long ?
YESSSSS :) We love good comments! And comments should be close to the code else they rot. There is no problem having long nd precise comments that empower the reader.
Any other opinion ?
One important question is what is the impact of the hardware dirven solution on bit identical computation on different machine. I would do the following: use the smalltalk - bit identical idea all the times provide one methods for people knowing that they want to get faster but potentially different floats on different platform. Does it make sense? Stef
Nicolas
2011/9/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hello nicolas
On Sep 22, 2011, at 12:17 AM, Nicolas Cellier wrote:
It's too long for a mail, but all explained here: http://smallissimo.blogspot.com/2011/09/clarifying-and-optimizing.html
Optimizing such kernel message is important - for example when reading a file of floats... Which version do you prefer ? Shall comments be that long ?
YESSSSS :) We love good comments! And comments should be close to the code else they rot. There is no problem having long nd precise comments that empower the reader.
Yes, but if you implement any RFC, you generally put a reference because that is too much duplicated information... So there must be a threshold when a link becomes more clever than inlined comments. I'm glad if I'm below this threshold.
Any other opinion ?
One important question is what is the impact of the hardware dirven solution on bit identical computation on different machine. I would do the following:     use the smalltalk - bit identical idea all the times     provide one methods for people knowing that they want to get faster but potentially different floats on different platform.
Does it make sense?
Bit identical computations rely on the rounding mode which is set in hardware flags. To my knowledge, all Smalltalk dialects use the default settings and never change it. So the case of asFloat is not different from * + - / and other mathematical functions. They all rely on this setting. I see I introduced a doubt in the blog because I took a perspective of possible future extensions. But my intention was to resolve it; case of bad English style ? Now if some platforms don't adhere to IEEE754, then I think that we must first try to find a compatibility layer at VM level It's not difficult to emulate floating point arithmetic in Smalltalk - see http://smallissimo.blogspot.com/2011/08/arbitraryprecisionfloat.html (which however does not handle overflow, gradual underflow and NaN). However it's hard to do it with decent speeds... Nicolas
Stef
Nicolas
On Sep 22, 2011, at 6:20 PM, Nicolas Cellier wrote:
2011/9/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hello nicolas
On Sep 22, 2011, at 12:17 AM, Nicolas Cellier wrote:
It's too long for a mail, but all explained here: http://smallissimo.blogspot.com/2011/09/clarifying-and-optimizing.html
Optimizing such kernel message is important - for example when reading a file of floats... Which version do you prefer ? Shall comments be that long ?
YESSSSS :) We love good comments! And comments should be close to the code else they rot. There is no problem having long nd precise comments that empower the reader.
Yes, but if you implement any RFC, you generally put a reference because that is too much duplicated information... So there must be a threshold when a link becomes more clever than inlined comments. I'm glad if I'm below this threshold.
Any other opinion ?
One important question is what is the impact of the hardware dirven solution on bit identical computation on different machine. I would do the following: use the smalltalk - bit identical idea all the times provide one methods for people knowing that they want to get faster but potentially different floats on different platform.
Does it make sense?
Bit identical computations rely on the rounding mode which is set in hardware flags. To my knowledge, all Smalltalk dialects use the default settings and never change it. So the case of asFloat is not different from * + - / and other mathematical functions. They all rely on this setting.
I see I introduced a doubt in the blog because I took a perspective of possible future extensions. But my intention was to resolve it; case of bad English style ?
may be just that we are bad with numbers :) So you are saying that your solutions requires that the platform are IEEE754 so the risks is low then.
Now if some platforms don't adhere to IEEE754, then I think that we must first try to find a compatibility layer at VM level It's not difficult to emulate floating point arithmetic in Smalltalk - see http://smallissimo.blogspot.com/2011/08/arbitraryprecisionfloat.html (which however does not handle overflow, gradual underflow and NaN). However it's hard to do it with decent speeds...
Nicolas
Stef
Nicolas
participants (2)
-
Nicolas Cellier -
Stéphane Ducasse