[Pharo-users] Re: Rounding in Floats

[Konrad Hinsen]

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". If that's what you need, your choices are


1) Integers

2) Rational numbers (fractions)

3) Computable numbers (often called "exact reals", a term I find 
misleading).



Pharo has 1) and 2).


Konrad

[Pharo-users] Re: Problem installing 9.0 on MacMini M1

[David Pennington]

I transferred both of my images ( 8 and 9) across and put them in the images 
directory of a new Pharo Launcher. I now have 9.0 working on the Mac mini but 
it is still telling me that my VM is out of date. I have opened the VM window 
and updated both the 8 and 9 vm but I still get the message. I am not convinced 
that I have an M1 VM. 

How do I sort this. I am nearly there.

> On 15 Jun 2021, at 18:44, Tim Mackinnon  wrote:
> 
> Worth saying that while Brew is handy on a mac (and avoid installing it as a 
> sudo user) - you shouldn't need it do anything with Pharo either with with 
> the launcher (graphical) or via the console (command line).
> 
> Its worth checking you have properly read the download instructions on 
> pharo.org  - for command line it does say use "curl" and 
> "wget if curl not available".
> 
> For your pharo damaged question - have you tried just creating a fresh 
> directory, cd'ing into it and then running the command line instructions for 
> a fresh install. You can then make sure sure pharo works correctly command 
> line - and if so, this is then possibly a 32 vs 64 bit image difference. You 
> could investigate this - or simply create a new image and install your code 
> into it as a fresh install - which might be better anyway, while your getting 
> things sorted.
> 
> Others may have more tips for you.
> 
> Tim
> 
> On Tue, 15 Jun 2021, at 5:58 PM, Rob Sayers wrote:
>> Hi, I can't help with the Pharo specific issue, but for installing brew, you 
>> can find the directions here: https://brew.sh/ 
>> 
>> On Tue, Jun 15, 2021 at 10:16 AM David Pennington > > wrote:
>> Hi everyone. It is your favourite newbie speaking :-)
>> 
>> I have now got a new M1 MacMini which I want to configure up as a server for 
>> my Seaside apps.
>> 
>> So far, I have found that the Mac mini doesn’t have wget or brew installed! 
>> I have sorted wget but not brew.
>> 
>> Secondly, I have transferred all of my 9.0 stuff across but when I try and 
>> execute both paharo-ui or pharo (as terminal scripts) they both fail as they 
>> say that the “Paharo” is damaged and can’t be opened. You should move it to 
>> the bin.
>> 
>> I can open Pharo 9.0 directly but it tells me that the VM is too old for 
>> this image.
>> 
>> Can anyone help me please? (In words that I can understand:-)
>> 
>> David
>> 
>> 
>> -- 
>> Rob Sayers
>> www.robsayers.com 

[Pharo-users] Re: Rounding in Floats

[Esteban Maringolo]

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 precision" means "no precision is ever lost in arithmetic
> operations". If that's what you need, your choices are
>
> 1) Integers
>
> 2) Rational numbers (fractions)

> Pharo has 1) and 2).

Yeap, I'll switch to 2.

What I'm not totally convinced of is whether to store numbers as
integers (knowing beforehand the decimal precision, and converting it
to fractions when read back) or if to store them as scaled decimals
(which internally hold a fraction).

Thanks!

[Pharo-users] Re: How to get dimensions (extent) of a SpPresenter

[kmo]

Hi Esteban

Do you know when the fix for the extent problem under Gtk will be in the
image? I downloaded the latest Pharo 9 image a couple of days ago and,
though the fix was in for the extent problem in Morphic, it still didn't
work in Gtk.

Thanks.

Ken




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] Re: Rounding in Floats

[Richard O'Keefe]

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 unlimited rational numbers with the scale being used for printing
purposes only.  This creates enormous confusion and I really don't see any
point in Squeak/Pharo ScaledDecimal existing at all.  There *is* point in
having fixed-point decimal numbers as they are a perfect match for SQL data
bases and several programming languages.

I've now located a PDF of the USGA Rules of Handicapping.  Wow.  128 pages.
And with all that they couldn't explain the calculations precisely.
Rounding
arrives in more than one place.  For example you might have to average the
best 1-8 of the last (as many as are available up to 20) scores and then
round
to one decimal, but it is not stated how ties are to be broken (which can
arise
for the best 2, 4, 6, or 8).  It is probably safe to assume rounding out.

Number>>roundOut
  ^self negative
 ifTrue:  [((self * 2 - 1) / 2) ceiling]
 ifFalse: [((self * 2 + 1) / 2) floor]

On Wed, 16 Jun 2021 at 02:06, Esteban Maringolo 
wrote:

> 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 handicap"
> allowance := 0.85. "85%"
> ph := (ch * allowance) roundedHandicap. "playing handicap"
>
> The #roundedHandicap is like #rounded but rounds -0.5 towards -1
> instead of toward 0.
>
> My first approach was to use fixed points, but then I hit issues where
> some results also produced "wrong" numbers (according to the
> reference), also in Pharo some ScaledDecimals compare as different
> even when they're printed as the same (which is not correct, IMO).
>
> I just tested using everything as fractions and converting to float
> (or ScaledDecimal) at the very last step and it produces the expected
> result. I'll review and convert whatever is needed (including database
> fields) to work with this. The good thing is that all the involved
> numbers only have one decimal as much.
>
> Thanks!
>
> Esteban A. Maringolo
>
> On Tue, Jun 15, 2021 at 3:48 AM Steffen Märcker  wrote:
> >
> > 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 questions
> > about floats for my students yesterday. )
> >
> > Kind regards,
> > Steffen
> >
> >
> > Konrad Hinsen schrieb am Dienstag, 15. Juni 2021 07:02:30 (+02:00):
> >
> >  > 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 right, raw,
> thing"
> >  > > (at least compared to other mainstream languages), but it still
> >  > > produces a surprise effect.
> >  >
> >  > That's the "floating point surprise" that everyone has at some point,
> no
> > matter the language and runtime system. If that surprise is a problem for
> > you, are you sure that floating-point arithmetic is what you really want?
> > Maybe your needs are better served with integers and fractions.
> >  >
> >  >
> >  > Konrad.
> >  >
> >  >
> > --
> > Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com
> > herunter.
>

[Pharo-users] Re: How to get dimensions (extent) of a SpPresenter

[Esteban Lorenzano]

Hi,
Yes, it is there.
Thing is... since cairo does not informs correctly extent of surface in x11, 
what I did is to add an extra parameter to the drawing block, as you can see in 
the example :

SpAthensPresenter>>#exampleResizing
| extent |
extent := 350@300.
self new
surfaceExtent: extent;
drawBlock: [ :aCanvas :boundingBox | | paint surface |
"Since sometimes a cairo surface does not brings the correct extent (in X11 or 
Windows,
for example), we use the bounding box of the component."
surface := aCanvas surface.
paint := surface
createLinearGradient: {
0->Color red.
1->Color green }
start: 0@0
stop: boundingBox extent.
surface clear.
aCanvas setPaint: paint.
aCanvas drawShape: (0@0 extent: boundingBox extent) ];
openWithSpec

That was tested on Wayland and x11 and it was working properly :)
Esteban

On Jun 16 2021, at 2:20 pm, kmo  wrote:
> Hi Esteban
>
> Do you know when the fix for the extent problem under Gtk will be in the
> image? I downloaded the latest Pharo 9 image a couple of days ago and,
> though the fix was in for the extent problem in Morphic, it still didn't
> work in Gtk.
>
> Thanks.
> Ken
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

[Pharo-users] Re: How to get dimensions (extent) of a SpPresenter

[Esteban Lorenzano]

boo... format lost :P

On Jun 16 2021, at 2:27 pm, Esteban Lorenzano  wrote:
>
> Hi,
> Yes, it is there.
> Thing is... since cairo does not informs correctly extent of surface in x11, 
> what I did is to add an extra parameter to the drawing block, as you can see 
> in the example :
>
> SpAthensPresenter>>#exampleResizing
> | extent |
> extent := 350@300.
> self new
> surfaceExtent: extent;
> drawBlock: [ :aCanvas :boundingBox | | paint surface |
> "Since sometimes a cairo surface does not brings the correct extent (in X11 
> or Windows,
> for example), we use the bounding box of the component."
> surface := aCanvas surface.
> paint := surface
> createLinearGradient: {
> 0->Color red.
> 1->Color green }
> start: 0@0
> stop: boundingBox extent.
> surface clear.
> aCanvas setPaint: paint.
> aCanvas drawShape: (0@0 extent: boundingBox extent) ];
> openWithSpec
>
> That was tested on Wayland and x11 and it was working properly :)
> Esteban
>
> On Jun 16 2021, at 2:20 pm, kmo  wrote:
> > Hi Esteban
> >
> > Do you know when the fix for the extent problem under Gtk will be in the
> > image? I downloaded the latest Pharo 9 image a couple of days ago and,
> > though the fix was in for the extent problem in Morphic, it still didn't
> > work in Gtk.
> >
> > Thanks.
> > Ken
> >
> >
> >
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >
>

[Pharo-users] Re: How to get dimensions (extent) of a SpPresenter

[kmo]

Many thanks esteban - works fine now in Gtk



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] Re: Problem installing 9.0 on MacMini M1

[Clacton Server]

I am nearly there. I sorted out the curl/wget business and managed to get the 
new VM. I have installed it and everything is very quick so I am pleased.

However there are two things I am not sure of.

1. Once I close this down, I am not confident of finding it again (smile).

2. I am back with the Path issue that I mentioned a while ago. Instead of 
(FileSystem disk workingDirectory) being set at the Pharo level it is now set 
at the very top of the tree. Is this something that I am going to have to live 
with our can I reconfigure the startup to make it as it was?

David

> On 16 Jun 2021, at 12:56, David Pennington  wrote:
> 
> I transferred both of my images ( 8 and 9) across and put them in the images 
> directory of a new Pharo Launcher. I now have 9.0 working on the Mac mini but 
> it is still telling me that my VM is out of date. I have opened the VM window 
> and updated both the 8 and 9 vm but I still get the message. I am not 
> convinced that I have an M1 VM. 
> 
> How do I sort this. I am nearly there.
> 
>> On 15 Jun 2021, at 18:44, Tim Mackinnon > > wrote:
>> 
>> Worth saying that while Brew is handy on a mac (and avoid installing it as a 
>> sudo user) - you shouldn't need it do anything with Pharo either with with 
>> the launcher (graphical) or via the console (command line).
>> 
>> Its worth checking you have properly read the download instructions on 
>> pharo.org  - for command line it does say use "curl" and 
>> "wget if curl not available".
>> 
>> For your pharo damaged question - have you tried just creating a fresh 
>> directory, cd'ing into it and then running the command line instructions for 
>> a fresh install. You can then make sure sure pharo works correctly command 
>> line - and if so, this is then possibly a 32 vs 64 bit image difference. You 
>> could investigate this - or simply create a new image and install your code 
>> into it as a fresh install - which might be better anyway, while your 
>> getting things sorted.
>> 
>> Others may have more tips for you.
>> 
>> Tim
>> 
>> On Tue, 15 Jun 2021, at 5:58 PM, Rob Sayers wrote:
>>> Hi, I can't help with the Pharo specific issue, but for installing brew, 
>>> you can find the directions here: https://brew.sh/ 
>>> 
>>> On Tue, Jun 15, 2021 at 10:16 AM David Pennington >> > wrote:
>>> Hi everyone. It is your favourite newbie speaking :-)
>>> 
>>> I have now got a new M1 MacMini which I want to configure up as a server 
>>> for my Seaside apps.
>>> 
>>> So far, I have found that the Mac mini doesn’t have wget or brew installed! 
>>> I have sorted wget but not brew.
>>> 
>>> Secondly, I have transferred all of my 9.0 stuff across but when I try and 
>>> execute both paharo-ui or pharo (as terminal scripts) they both fail as 
>>> they say that the “Paharo” is damaged and can’t be opened. You should move 
>>> it to the bin.
>>> 
>>> I can open Pharo 9.0 directly but it tells me that the VM is too old for 
>>> this image.
>>> 
>>> Can anyone help me please? (In words that I can understand:-)
>>> 
>>> David
>>> 
>>> 
>>> -- 
>>> Rob Sayers
>>> www.robsayers.com 

[Pharo-users] Re: Rounding in Floats

[Konrad Hinsen]

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 calculators use decimal floats, not binary floats. That doesn't 
remove rounding issues, but it makes conversion to and from print 
representations loss-free.



Konrad

[Pharo-users] Re: Rounding in Floats

[Sven Van Caekenberghe]

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: you got a 
division by 113 in your formula 
[https://en.wikipedia.org/wiki/Handicap_(golf)], this will give smaller 
fractions.

The problem is not the calculation (modern 64-bit floats as in Pharo are plenty 
accurate), it is how you handle results. You should just round it correctly and 
be done with it.

Note that

a roundTo: 0.01. (1e-14) still gives 4.5

it is only one step further that you hit the limit and get the ugly but correct 
result.

I assume that most calculators always use a printing precision that is lower 
than their internal precision, hence they hide this reality.

When computing with money, you would be inclined to put everything in cents 
(because you cannot divide them further). But once you start computing 
percentage discounts or taxes, you again get problems. At each of those steps 
you must make sure that no cents are lost.

> On 16 Jun 2021, at 15:19, Esteban Maringolo  wrote:
> 
> 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 precision" means "no precision is ever lost in arithmetic
>> operations". If that's what you need, your choices are
>> 
>> 1) Integers
>> 
>> 2) Rational numbers (fractions)
> 
>> Pharo has 1) and 2).
> 
> Yeap, I'll switch to 2.
> 
> What I'm not totally convinced of is whether to store numbers as
> integers (knowing beforehand the decimal precision, and converting it
> to fractions when read back) or if to store them as scaled decimals
> (which internally hold a fraction).
> 
> Thanks!

[Pharo-users] Re: Rounding in Floats

[Sven Van Caekenberghe]

> 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 handheld calculators, normal and scientific, do not.
> 
> Handheld calculators use decimal floats, not binary floats. That doesn't 
> remove rounding issues, but it makes conversion to and from print 
> representations loss-free.
> 
> 
> Konrad
> 

mmm, this is interesting.

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.

[Pharo-users] Re: Reading http post data using Zinc

[Sven Van Caekenberghe]

Hi Davide,

> On 16 Jun 2021, at 23:17, Davide Varvello via Pharo-users 
>  wrote:
> 
> Hi Guys,
> I'm posting from an http form and I'm wondering how to read data from the
> post. It seems the request should give a ZnMultiPartFormDataEntity, but I
> can't find how to use it.
> 
> Can you help me please?
> Davide
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

It depends on how the form is posted (there are two approaches).

A working example of both can be found in ZnDefaultServerDelegate>>#formTest2: 
and #formTest3:

ZnServerTest>>#testFormTest2: and #testFormTest3: exercise this functionality

Basically, you just take the entity from the request and use it.

HTH,

Sven

[Pharo-users] Re: Rounding in Floats

[Esteban Maringolo]

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 
> Pharo ScaledDecimal numbers are NOT fixed-point numbers.  They are unlimited 
> rational numbers with the scale being used for printing purposes only.  This 
> creates enormous confusion and I really don't see any point in Squeak/Pharo 
> ScaledDecimal existing at all.

I only used decimals in other platforms, and only for accounting
purposes, but to me if two scaled decimals print the same but answer
false to #= then something is wrong conceptually. I can identify the
issue, but the reasoning behind how it works, or even more, how to fix
it, is above my level.

> There *is* point in having fixed-point decimal numbers as they are a perfect 
> match for SQL data bases and several programming languages.

That's the only use I gave it.
So if we divided 10.0s1 / 3 ended up with 3.3s1 each, and we had to
calculate the rounding errors (0.1s1 in this case) to make all
balance.

> I've now located a PDF of the USGA Rules of Handicapping.  Wow.  128 pages.

That's just USGA, there is a "World System" but each "region" or local
federation does a variation of the "world system". So Belgium does one
thing, Australia another one, Argentina another one, England decided
to only take one part...  standards, they call it :-)

I Implemented a couple of them.

> And with all that they couldn't explain the calculations precisely.

Try to ask one federation how they calculate the PCC, and they won't
tell you, it's like the coca-cola formula.

>  Rounding
> arrives in more than one place.  For example you might have to average the
> best 1-8 of the last (as many as are available up to 20) scores and then round
> to one decimal, but it is not stated how ties are to be broken (which can 
> arise
> for the best 2, 4, 6, or 8).

In this computation, the tie doesn't matter, because you start with an
_already rounded_ number (called a "differential"), so it doesn't
matter if you choose 11.4 from the 5th or 11.4 from the 19th. The
rounding happens at the very end and determines a new rounded (to one
decimal) number that's going to be used in other formulas (like the
one that re-kicked this thread).

The ties in competitions are solved differently. In real tournaments
by playoff, or in amateur tournaments either by playoff or by a hole
by hole comparison. If that even happens[*], there is the option to
toss a coin to untie it.

[*] In +400 tournaments managed by my software (involving ~15000
scorecards), that never happened.


So to wrap up and bring it back to the topic, a proper ScaledDecimal
implementation would help me storing the numbers as such guaranteeing
no floating point funny thing happens, but since there is no such
thing, I'll rather build the scaled decimals manually (e.g.
ScaledDecimal fromFraction: 67/10) or not use scaled decimals and try
to use the Fractions directly wherever possible.

It's always good to learn new things.

[Pharo-users] Re: Rounding in Floats

[Konrad Hinsen]

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.

That would be an interesting experiment indeed. Either use one of the
IEEE754 decimal float formats
(https://en.wikipedia.org/wiki/Decimal_floating_point), or Douglas
Crockford's DEC64 proposal (https://www.crockford.com/dec64.html, which
strangely enough does not refer to the older IEEE standard). There are
implementations of both for various other languages that can serve as
inspiration.

Konrad.

[Pharo-users] Re: Rounding in Floats

[ducasse]

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 improve (which I doubt about) just send us 
code and tests

I’m sad that you systematically ignore any of my emails on the topic. 
You could have an impact but you prefer to hide yourselves in your tower. Good 
luck with it. 

S. 

[Pharo-users] Re: Rounding in Floats

[Esteban Maringolo]

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.
>
> I think that going for 1/10 fractions/precision is not going to help: you got 
> a division by 113 in your formula 
> [https://en.wikipedia.org/wiki/Handicap_(golf)], this will give smaller 
> fractions.

And the reasons behind why they chose 113 are still unknown, because
that number is used to get a
"difficulty coefficient", so if the course is rated a 125, then
125/113 will give you roughly a ~1.1 coefficient.
They could have used 100.

> The problem is not the calculation (modern 64-bit floats as in Pharo are 
> plenty accurate), it is how you handle results. You should just round it 
> correctly and be done with it.

> Note that
> a roundTo: 0.01. (1e-14) still gives 4.5
> it is only one step further that you hit the limit and get the ugly but 
> correct result.

I'm not doing that, and I only store the original number (which has a
fixed decimal) and the "rounded" (to no decimals) number, all
intermediate numbers are re-calculated (maybe cached) but not stored
elsewhere. What I might be doing wrong is to store the original index
as float instead of a Decimal number.

> When computing with money, you would be inclined to put everything in cents 
> (because you cannot divide them further). But once you start computing 
> percentage discounts or taxes, you again get problems. At each of those steps 
> you must make sure that no cents are lost.

And that includes adding a "rounding" item for any difference in all
invoices, orders, etc.

Regards!

Esteban A. Maringolo

[Pharo-users] Re: Rounding in Floats

[Esteban Maringolo]

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 tried a couple of Common Lisp and Scheme implementations) do 
> > the same as Pharo, but handheld calculators, normal and scientific, do not.
>
> Handheld calculators use decimal floats, not binary floats. That doesn't
> remove rounding issues, but it makes conversion to and from print
> representations loss-free.
>
>
> Konrad

[Pharo-users] Reading http post data using Zinc

[Davide Varvello via Pharo-users]

Hi Guys,
I'm posting from an http form and I'm wondering how to read data from the
post. It seems the request should give a ZnMultiPartFormDataEntity, but I
can't find how to use it.

Can you help me please?
Davide




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] Re: Rounding in Floats

[Richard O'Keefe]

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/Decimal-Float.html
and (e) available for most machines via the "reference implementation" in C.
The current COBOL standard basically defines its arithmetic in terms of this.
Java of course has BigDecimal.  While decimal floats became part of IEEE 754 in
2008, they were previously covered by IEEE 854.

Reverting to ScaledDecimal, let us consider the 10.0s1 / 3 example.
There is a huge problem here with no really satisfactory answer.
In my library, it currently answers 3.3s1, exactly equal to 33/10.
In Squeak/Pharo, it answers "I am really 10/3 but print me with one decimal",
so you see 3.3a1 but it *behaves* like 10.3.
In VisualAge Smalltalk you get  3.33
If it were not for the fact that the ANSI Smalltalk standard appears to
require that  /  yield a ,
I would prefer to answer 10/3.  Decimals just plain are not closed under
division (although they are closed under addition, subtraction, and
multiplication).  When it comes to scaled decimals, the ANSI Smalltalk
standard is frankly a mess.  Amongst other things, it defers the
semantics of operations on them to the Language-Independent
Arithmetic standard, which explicitly denies having anything to say about them!

I understand why my library does what it does.  I even tried to
publish a paper about it.
I understand why VisualAge Smalltalk does what it does.  (I've read
IBM/360 PrincOps.)
I do NOT understand why Squeak and Pharo do what they do, and if anyone knows
the rationale for their ScaledDecmal please tell me.

On Thu, 17 Jun 2021 at 06:29, Esteban Maringolo  wrote:
>
> 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 tried a couple of Common Lisp and Scheme 
> > > implementations) do the same as Pharo, but handheld calculators, normal 
> > > and scientific, do not.
> >
> > Handheld calculators use decimal floats, not binary floats. That doesn't
> > remove rounding issues, but it makes conversion to and from print
> > representations loss-free.
> >
> >
> > Konrad

[Pharo-users] Re: Rounding in Floats

[Richard O'Keefe]

"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 of code from you"
  That is not true.  Why, in this thread alone I contributed
#roundOut.  I have provided several
  pieces of code in this mailing list over the years. You can say that
my code is no good, or
  that you don't want it, or that you think there is a better way to
do the (admittedly small)
  things that I have provided, but if you never saw them you must have
shut your eyes.
  In addition, a snapshot of my system is available on the web for
anyone to play with.
  I shall post here when my GitHub repository is populated; I just
have to clear a few more
  things out of the local directory that I don't have the right to distribute.
  (For example, benchmarking my CSV library against NeoCSV meant having to have
  NeoCSV, but it's not mine to distribute.)


On Thu, 17 Jun 2021 at 08:45, ducasse  wrote:
>
> 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 improve (which I doubt about) just send us 
> code and tests
>
> I’m sad that you systematically ignore any of my emails on the topic.
> You could have an impact but you prefer to hide yourselves in your tower. 
> Good luck with it.
>
> S.

[Pharo-users] Zn and AWS - retrieving object versions?

[Tim Mackinnon]

Hi everyone - I’m wondering if someone knows the trick to listing object 
versions in AWS S3?

I was previously using a non-Zn library (there are a few around - but they are 
quite old and I’m not sure how much they are maintained) - however I hadn’t 
realised that Zn actually supports S3 until I read it a bit carefully and 
realised that I needed to load an extra AWS group.

So - I have a bucket that is versioned, and I wanted to read the versions of an 
object - and hopefully be able to read the contents of an older version.

I can list the contents of a bucket, but when I try to read the versions of an 
object - I get a forbidden error - which when I dig deeper gives a stranger 
explanation?

I have confirmed that the AWS CLI is able to list versions in that bucket - so 
I’m a bit confused what the issue might be?

(client := ZnAWSS3Client new)
accessKeyId: 'xxx';
secretAccessKey: ‘y';
checkIntegrity: true.

client buckets. “Works"
client keysIn: 'mtt-data’. “Works"

client at: 'mtt-data' -> 'sample.txt’. “Works"

client keysIn: 'mtt-data' query: (Dictionary with: 'versions'->nil). “Gives an 
error?”


HTTP/1.1 403 Forbidden


SignatureDoesNotMatchThe request signature we 
calculated does not match the signature you provided. Check your key and 
signing method.xxxGET


Has anyone tried doing this - I’m sure there is something really simple that I 
am missing?

Tim