"first we are not good in math"
First, I am not criticising YOU. Pharo's weird ScaledDecimal is
Squeak's weird ScaledDecimal
and you have not changed it. Fine.
"second Pharo is what we have and we never said that it is the best
system ever"
True, but irrelevant.
"third I never saw a piece
2Decimal floats are (a) part of the IEEE 758-2008 standard for
floating-point arithmetic,
(b) implemented as part of the instruction set in IBM z/Series and
POWER computers,
(c) allowed for in the current C standard, (d) partially supported by GCC
https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Decima
Richard
As I said it thousands of times,
- first we are not good in math
- second Pharo is what we have and we never said that it is the best
system ever
we just enhanced daily
- third, I never saw a piece of code from you.
- if you want to see Pharo impr
Sven Van Caekenberghe writes:
> It would be possible (and maybe it has already been done) to
> implement/add such a decimal floating point number to Pharo. It would
> require reimplementing all operations from scratch (esp. sin/cos/tan
> log/exp and so on), it would be slow, but interesting.
Tha
> On 16 Jun 2021, at 16:20, Konrad Hinsen wrote:
>
> On 16/06/2021 15:52, Sven Van Caekenberghe wrote:
>> I am also a bit intrigued by this. Like you said: several other programming
>> languages (I tried a couple of Common Lisp and Scheme implementations) do
>> the same as Pharo, but handhel
I didn't know there were decimal floats.
Are they used elsewhere?
Esteban A. Maringolo
On Wed, Jun 16, 2021 at 11:20 AM Konrad Hinsen
wrote:
>
> On 16/06/2021 15:52, Sven Van Caekenberghe wrote:
> > I am also a bit intrigued by this. Like you said: several other programming
> > languages (I tr
On Wed, Jun 16, 2021 at 10:52 AM Sven Van Caekenberghe wrote:
>
> I am also a bit intrigued by this. Like you said: several other programming
> languages (I tried a couple of Common Lisp and Scheme implementations) do the
> same as Pharo, but handheld calculators, normal and scientific, do not.
On Wed, Jun 16, 2021 at 10:49 AM Richard O'Keefe wrote:
> The problem is that while it is possible to read the ANSI Smalltalk standard
> as requiring ScaledDecimals to be fixed point numbers (which are a kind of
> exact rational number of the form x * 10**y, x and y integers), in Squeak and
> P
On 16/06/2021 15:52, Sven Van Caekenberghe wrote:
I am also a bit intrigued by this. Like you said: several other programming
languages (I tried a couple of Common Lisp and Scheme implementations) do the
same as Pharo, but handheld calculators, normal and scientific, do not.
Handheld calculat
I am also a bit intrigued by this. Like you said: several other programming
languages (I tried a couple of Common Lisp and Scheme implementations) do the
same as Pharo, but handheld calculators, normal and scientific, do not.
I think that going for 1/10 fractions/precision is not going to help:
The problem is that while it is possible to read the ANSI Smalltalk
standard as requiring ScaledDecimals to be fixed point numbers (which are a
kind of exact rational number of the form x * 10**y, x and y integers), in
Squeak and Pharo ScaledDecimal numbers are NOT fixed-point numbers. They
are un
On Wed, Jun 16, 2021 at 9:13 AM Konrad Hinsen
wrote:
>
> On 15/06/2021 16:05, Esteban Maringolo wrote:
> > And in this particular case, it might cause issues, since the "full
> > precision" (whatever that means) must be retained when using such a
> > number to derive another one.
>
> To me, "full
On 15/06/2021 16:05, Esteban Maringolo wrote:
And in this particular case, it might cause issues, since the "full
precision" (whatever that means) must be retained when using such a
number to derive another one.
To me, "full precision" means "no precision is ever lost in arithmetic
operations"
> On 15 Jun 2021, at 16:19, Esteban Maringolo wrote:
>
> Hi Sven,
>
> I accidentally skipped this.
>
> How is this different from the GRNumberPrinter?
It is similar, but different (it does several things to produce cleaner
numbers). Basically, when I produced certain JSON with floats that
Hi Sven,
I accidentally skipped this.
How is this different from the GRNumberPrinter?
Where is the code available?
Thanks!
Esteban A. Maringolo
On Mon, Jun 14, 2021 at 6:30 PM Sven Van Caekenberghe wrote:
>
> BTW, I recently wrote my own float printer, as an experiment.
>
> NeoJSONFloatPrint
Hi Richard,
> Whether 6.7 - 2.2 gives 4.5 or something else is a subtle issue,
> starting with the fact
> that 6.7 and 2.2 cannot be represented precisely in floating-point
> format. In this particular case, the errors happen to match up.
> What you *can* rely on in Smalltalk is that (67/10) - (2
Well... fixed point numbers (aka ScaledDecimals) had their issues as well.
And in this particular case, it might cause issues, since the "full
precision" (whatever that means) must be retained when using such a
number to derive another one.
E.g. in my case:
ch := 6.7 + (32.8 - 35). "course handic
Whether 6.7 - 2.2 gives 4.5 or something else is a subtle issue,
starting with the fact
that 6.7 and 2.2 cannot be represented precisely in floating-point
format. In this particular case, the errors happen to match up.
What you *can* rely on in Smalltalk is that (67/10) - (22/10) = (9/2).
Let's j
Typo: FP should read floating point and not fixed point.
Steffen Märcker schrieb am Dienstag, 15. Juni 2021 08:47:24 (+02:00):
> Have you considered using fixed-point arithmetic? For example:
> 7.1s2 roundTo: 0.1s2
>
> The rule of thumb I stick to is to use FP only if I know the inaccuracies
> wo
Have you considered using fixed-point arithmetic? For example:
7.1s2 roundTo: 0.1s2
The rule of thumb I stick to is to use FP only if I know the inaccuracies
won't bite me. Funny enough, both 7.1 and 0.1 are already not accurately
representable as floats. (And by coincidence, I prepared exam ques
On 15/06/2021 01:03, Esteban Maringolo wrote:
Sure, but what initiated this thread was a reference to roundTo: 0.1
which produced a "wrong" output.
(9.1 + (-2.0)) roundTo: 0.1 "=> 7.1005"
7.1 roundTo: 0.1 "=> 7.1005"
However, at this point I know that Pharo "does the rig
On Mon, Jun 14, 2021 at 10:37 PM Richard O'Keefe wrote:
> For what it's worth, I expected ScaledDecimal to act like fixed point
> arithmetic, and implemented it that way in my own Smalltalk library, where
> two ScaledDecimals *do* print the same if and only if they are numerically
> exactly the s
It's not quite clear what is happening in the other systems.
Here is R
> 6.7 + (32.8 - 35)
[1] 4.5
> round(6.7 + (32.8 - 35))
[1] 4
The result *is* 4.49 but is *printed* as 4.5.
Here is Gambit Scheme
> (+ 6.7 (- 32.8 35))
4.497
> (round (+ 6.7 (- 32.8 35)))
4.
Here is astc S
Hi Sven,
> > If in Pharo [1] you do:
> > a := 6.7 + (32.8 - 35)
> > It will produce:
> > 4.497
> > Which, when rounded, will produce 4.
> But,
> a roundTo: 0.1 "=> 4.5"
Sure, but what initiated this thread was a reference to roundTo: 0.1
which produced a "wrong" output.
(9.1 + (-2.0
BTW, I recently wrote my own float printer, as an experiment.
NeoJSONFloatPrinter lowPrecision print: a.
=> 4.5
What I wanted was a human friendly, compact float printer, that tries to go for
the shortest, simplest number. It prefers integers and goes to scientific
notation when needed, while
> On 14 Jun 2021, at 22:44, Esteban Maringolo wrote:
>
> I'm coming back to this because I've been bitten by these floating
> points things again.
>
> If in Pharo [1] you do:
> a := 6.7 + (32.8 - 35)
>
> It will produce:
> 4.497
>
> Which, when rounded, will produce 4.
But,
a
I'm coming back to this because I've been bitten by these floating
points things again.
If in Pharo [1] you do:
a := 6.7 + (32.8 - 35)
It will produce:
4.497
Which, when rounded, will produce 4.
In other places [2] I do the same simple addition and subtraction it
produces 4.5, that
If you are going to use floating point numbers in any programming
language, Pharo included, you need to understand something about
them. Things like
- the relevant precision is *fixed*; a Float in Pharo is *always*
a 64-bit IEEE floating-point number, which amongst other things
means (to a
28 matches
Mail list logo
