- Pharo-users - lists.pharo.org

Re: Reading http post data using Zinc

by Sven Van Caekenberghe

Hi Davide, > On 16 Jun 2021, at 23:17, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> 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

June 16, 2021

Reading http post data using Zinc

by Davide Varvello

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

June 16, 2021

Re: Rounding in Floats

by 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.

June 16, 2021

Re: Rounding in Floats

by Konrad Hinsen

Sven Van Caekenberghe <sven(a)stfx.eu> 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.

June 16, 2021

Re: Rounding in Floats

by Sven Van Caekenberghe

> On 16 Jun 2021, at 16:20, Konrad Hinsen <konrad.hinsen(a)fastmail.net> 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.

June 16, 2021

Re: Rounding in Floats

by 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 <konrad.hinsen(a)fastmail.net> 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

June 16, 2021

Re: Rounding in Floats

by Esteban Maringolo

On Wed, Jun 16, 2021 at 10:52 AM Sven Van Caekenberghe <sven(a)stfx.eu> 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.00000000000001. (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

June 16, 2021

Re: Rounding in Floats

by Esteban Maringolo

On Wed, Jun 16, 2021 at 10:49 AM Richard O'Keefe <raoknz(a)gmail.com> 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.

June 16, 2021

Re: Problem installing 9.0 on MacMini M1

by 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 <david(a)totallyobjects.com> 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 <tim(a)testit.works <mailto:tim@testit.works>> 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 <http://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/ <https://brew.sh/> >>> >>> On Tue, Jun 15, 2021 at 10:16 AM David Pennington <david(a)totallyobjects.com <mailto:david@totallyobjects.com>> 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 <http://www.robsayers.com/>

June 16, 2021

Re: Rounding in Floats

by 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

June 16, 2021