is 0.1 a Float or a ScaledDecimal ?

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

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Feb 20, 2008, at 11:31 , cdrick wrote:

> 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,

... write it as 0.1s1

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

> > 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... ;-)

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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 -

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

>
> 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
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

>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:[hidden email] http://www.Keystone-Software.com

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

> 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

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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:[hidden email] http://www.Keystone-Software.com

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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

[1] http://en.wikipedia.org/wiki/Dempster-Shafer_theory

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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
>
> [1] http://en.wikipedia.org/wiki/Dempster-Shafer_theory


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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 mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners