I have another interrogation. Please take it as a student/newbie whatever question.
I think 0.1 should be considered as a ScaledDecimal so that we could write 0.1 asFraction and have 1/10...
To achieve that, there is a method that the Parser call... Number class >> readFrom: aStream which call: Number class>>readRemainderOf: integerPart from: aStream base: base withSign: sign which call: Number class>>readScaledDecimal: integerPart fractionPart: fractionPart digits: fractionDigits base: base sign: sign from: aStream ...
What's interesting as a newbie perspective is the way I found these interesting methods... - only debug "0.1 asFraction" doesn't help, because it's hapening at "parse time"... I could have searched for selector containing "scaleddecimal" with cmd+shift+w but I did not... - Instead, as I knew it was related to Parser or Scanner, I looked in these class, then find Scanner scan: aStream. So I did: Scanner new scan: ('0.0123' readStream). "and the debut it"
What these methods say is basically: 0.1234 evaluate as a Float and 0.1234s4 evaluated as a scaled decimal (because of s).
IMvHO, I think at least decimal up to say scale 4 should be a scaled decimal...
What do you think ? I have no idea of performance concerns... so I'll be pleased to have any knowledgeable insights :)
Thanks a lot
Cédrick
To achieve that,
... write it as 0.1s1
ok, so 0.1 asFraction " (3602879701896397/36028797018963968)" is no problem ;-)
The problem I have is the intention... I think everybody who writes/enters 0.1 means 1/10... and not a flotting point value...
Float to me is more a "computer" number more than the kind of number I use and I naively think, it sould be hidden in some ways to the user by smalltalk..."My instances represent IEEE-754 floating-point double-precision numbers. They have about 16 digits of accuracy and their range is between plus and minus 10^307.").
But I may be wrong and moreover I imagine such a tweak won't be without any serious consequences on existing codes and calculations.....
Cédrick
ps: I just hope I'm not introducing too much "trolls" these days... ;-)
On Feb 20, 2008, at 14:21 , cdrick wrote:
To achieve that,
... write it as 0.1s1
ok, so 0.1 asFraction " (3602879701896397/36028797018963968)" is no problem ;-)
Indeed, because it is correct.
Perhaps #asApproximateFraction is what you are after.
The problem I have is the intention... I think everybody who writes/enters 0.1 means 1/10... and not a flotting point value...
Computers generally do what you tell them, not what you mean. 0.1 does have a different meaning than 1/10 in computing land. If you mean a fraction, write a fraction. If you mean a float, write a dotted decimal. Smalltalk even has means to write fractions as decimals (0.1s1). So simply choose what you mean and write that in the language your computer understands.
- Bert -
Computers generally do what you tell them, not what you mean. 0.1 does have a different meaning than 1/10 in computing land. If you mean a fraction, write a fraction. If you mean a float, write a dotted decimal. Smalltalk even has means to write fractions as decimals (0.1s1). So simply choose what you mean and write that in the language your computer understands.
I agree but I often forget I'm in computing land with Smalltalk ;-) !
Thanks Bert
I have another interrogation. Please take it as a student/newbie whatever question.
I think 0.1 should be considered as a ScaledDecimal so that we could write 0.1 asFraction and have 1/10... ....
What you desire is admirable but no longer practical as it would break a great many existing programs. In the begriming data types were closely tied to what the hardware supported. Most early computers supported integers (small integers, not the long kind that we have in Smalltalk) and maybe some form of floating point numbers and some form of decimals. Things weren't very standard between different manufactures computers. After a while, computers supported integers, floating point numbers and IBM mainframes had packed decimal numbers (in the hardware) that are a lot like ScaledDecimal numbers, they were used a lot in COBOL.
So, most languages took 0.1 to be a floating point number. When Smalltalk came along, it followed in that tradition. Smalltalk added 0.1s1as a ScaledDecimal number and 1/10 as a fraction. They are both implemented as a mix of software and hardware and not mapped directly to hardware.
Lastly, I would point out that in Smalltalk when you say 1/10 you get an instance of a fraction and not an instruction to divide 1 by 10. Therefore, you don't need to say 0.1 asFraction or 0.1s1 asFraction to get 1/10 as an instance of Fraction.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
What you desire is admirable but no longer practical as it would break a great many existing programs.
Yep, that's a BIG problem :-)
[snip]
between different manufactures computers. After a while, computers supported integers, floating point numbers and IBM mainframes had packed decimal numbers (in the hardware) that are a lot like ScaledDecimal numbers, they were used a lot in COBOL.
So, most languages took 0.1 to be a floating point number. When Smalltalk came along, it followed in that tradition. Smalltalk added 0.1s1as a ScaledDecimal number and 1/10 as a fraction. They are both implemented as a mix of software and hardware and not mapped directly to hardware.
Interesting, Thanks :)
Lastly, I would point out that in Smalltalk when you say 1/10 you get an instance of a fraction and not an instruction to divide 1 by 10. Therefore, you don't need to say 0.1 asFraction or 0.1s1 asFraction to get 1/10 as an instance of Fraction.
This wasn't my point. I was modeling a ownership degree as 0.1 multiple, so that's ok if I use integer (1 to 10) or scaled decimal instead of floats. I just said I found weird (even if correct) 0.1 asFraction couldn't return 1/10 but that's ok... I don't especially want to push that, just wanted some insights and you gave me some... so Thank you :-)
Also, I didn't know 0.1234s4 notation before so having a unit test failing was finally a good thing. I was testing a method called remainingWeight (so basically 1 - SumOfAllSubsetWeight, hence the test of *egality*... between floats)).
Cédrick
Hi Cédrick,
I'm Glad to be of some help.
[snip] Also, I didn't know 0.1234s4 notation before so having a unit test failing was finally a good thing. I was testing a method called remainingWeight (so basically 1 - SumOfAllSubsetWeight, hence the test of *egality*... between floats)).
Cédrick
I don't know what you are working on but if you use fractions for what you are doing it would be interesting to hear about how you use them and your results. Because fractions are kept as an integer numerator and an integer denominator, they probably take up more memory than floats but less than ScaledDecimals. And because both the numerator and denominator can be large integers, fractions can be very precise. But because they are implemented in both software and hardware, then can be slow. However, many numerical functions seem to have fractions or divisions built into them. If fractions are used and the divisions not preformed until they absolutely have to be, then use of fractions could be faster than expected and may be faster than ScaledDecimals or floats. I have no proof of this but if you do anything in this area, I would love to hear about it.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
I don't know what you are working on but if you use fractions for what you are doing it would be interesting to hear about how you use them and your results. Because fractions are kept as an integer numerator and an integer denominator, they probably take up more memory than floats but less than ScaledDecimals. And because both the numerator and denominator can be large integers, fractions can be very precise. But because they are implemented in both software and hardware, then can be slow. However, many numerical functions seem to have fractions or divisions built into them. If fractions are used and the divisions not preformed until they absolutely have to be, then use of fractions could be faster than expected and may be faster than ScaledDecimals or floats. I have no proof of this but if you do anything in this area, I would love to hear about it.
I think all this is premature optimization for me :) as I'm only building an early prototype (I'm doing a start of Dempster Shafer Theory [1] implementation (actually Transferable Belief Model)... and it's won't reach a big size for a while. It allows to have an imprecise, incomplete even uncertain value for a proposition (sort of multi-valued attribute with confidence...). I use it to get expert opinion on values, it's a known technique for different captor data fusion, but in my case, it doesn't demand too much performance as the combination is not that important (compared to sensor data fusion) ;)
Talking about that, that make me remember I needed a method subsets (for Set) and didn't found one. So I implementented one which will be cool to discuss here maybe (instead of something iterative, I've hacked something with binary masks, so it's 2 methods - 2 methods that took me two days but that's the fun of Smalltalk ! :)
Cédrick
On Wed, 20 Feb 2008 18:27:09 +0100, cdrick wrote:
...
I think all this is premature optimization for me :) as I'm only building an early prototype (I'm doing a start of Dempster Shafer Theory [1] implementation (actually Transferable Belief Model)... and it's won't reach a big size for a while. It allows to have an imprecise, incomplete even uncertain value for a proposition (sort of multi-valued attribute with confidence...).
Waaah, belief and plausibility as sum over numbers; shudder; political-systems-failure through machine calculations; market-meltdown through machine calculations; poverty-for-everyone through machine calculations :( Anyways, have you compared to Pei Wang's NARS (or perhaps his "The limitation of Bayesianism"), that would be interesting [OT]. Tried to convince him that fractions are sufficient for him but he liked floats more (his early J* prototype had no system support for fractions ...).
Do you have calculations of your model's epsilon on which you base your "imprecise", "uncertain", etc ? Or do you at present (for the prototype) just stab in the dark.
I use it to get expert opinion on values, it's a known technique for different captor data fusion, but in my case, it doesn't demand too much performance as the combination is not that important (compared to sensor data fusion) ;)
...
Cédrick
Waaah, belief and plausibility as sum over numbers; shudder; political-systems-failure through machine calculations; market-meltdown through machine calculations; poverty-for-everyone through machine calculations :( Anyways, have you compared to Pei Wang's NARS (or perhaps his "The limitation of Bayesianism"), that would be interesting [OT]. Tried to convince him that fractions are sufficient for him but he liked floats more (his early J* prototype had no system support for fractions ...).
wooww interesting but late for me :(
Do you have calculations of your model's epsilon on which you base your "imprecise", "uncertain", etc ? Or do you at present (for the prototype) just stab in the dark.
I guess I just stab in the dark... I have to leave, I'll read a bit and tell you later...
Thanks a lot ;)
Cédrick
I don't know what you are working on but if you use fractions for what you are doing it would be interesting to hear about how you use them and your results. Because fractions are kept as an integer numerator and an integer denominator, they probably take up more memory than floats but less than ScaledDecimals. And because both the numerator and denominator can be large integers, fractions can be very precise. But because they are implemented in both software and hardware, then can be slow. However, many numerical functions seem to have fractions or divisions built into them. If fractions are used and the divisions not preformed until they absolutely have to be, then use of fractions could be faster than expected and may be faster than ScaledDecimals or floats. I have no proof of this but if you do anything in this area, I would love to hear about it.
I think all this is premature optimization for me :) as I'm only building an early prototype (I'm doing a start of Dempster Shafer Theory [1] implementation (actually Transferable Belief Model)... and it's won't reach a big size for a while. It allows to have an imprecise, incomplete even uncertain value for a proposition (sort of multi-valued attribute with confidence...). I use it to get expert opinion on values, it's a known technique for different captor data fusion, but in my case, it doesn't demand too much performance as the combination is not that important (compared to sensor data fusion) ;)
I don't think that this is a case of premature optimisation, so much as not considering what kinds of objects you are really working with. I used to do a lot of numerical modeling in mathematical biology, and I found that to get consistent results I had to create a Rational number class in C++ (linked to FORTRAN via a C wrapper function, which led to horrible debugging due to C++ name mangling). It seems to me that the name Fraction is a bit misleading, as 'fraction' implies division (which was horrendously slow on the hardware I used to use), whilst 'rational numbers' are indeed exact (and countable). I tend to avoid floats unless I need to use transcendental functions.
If you are looking at something that is divided into parts then rational numbers will always give better results, and as they can be implemented purely in Integer arithmetic they are rarely slow unless you are dealing with weird fractions where the numerator or denominator is greater than the machine Integer, I guess in Squeak that's if either is greater than 31 bits.
The big question is speed more important than correctness? I would always tend to go the correctness route, then look at optimisation as long as the errors introduced by the floating point processor didn't compromise correctness beyond acceptable measures.
In population ecology or epidemiological models using rational numbers avoided the annoying fractional instances (the 0.456 infected creature, or the 0.23 surviving bilbies for example) that could lead to totally meaningless results. The worst case I saw was a model of bilby population, where the model showed a sufficient population density for survival in relation to predators and resources, but the model actually was super optimistic due to its having fractional bilbies living close enough together to breed, analysis showed that the model was out by 2 orders of magnitude, and if it had been used in a real world situation the cute little critters would have disappeared from the proposed refuge within 5 years.
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
cdrick -
johnps11＠bigpond.com -
Klaus D. Witzel -
Louis LaBrunda