Beginners May 2024

beginners@lists.squeakfoundation.org

5 participants
4 discussions

Need ByteArray Interpreted as Base 10 UnsignedInt of 32 bits.
by Cody Sevier 08 May '24

08 May '24

Hello Squeakers, I have an algorithm for reading doom wads working in Pharo that I would like to convert to Squeak, however, I cant for the life of me figure out how to interpret a byte array of 4 bytes as an Unsigned Int. I see that a ByteArray IS an UnsignedIntCollection, but cant seem to figure out how to use it as such. Functional Pharo: binaryStream := wad binaryReadStream. wadType := (binaryStream next: 4) asString. numberOfDirectories := (binaryStream next: 4) uint32AtOffset: 0. byteOffsetToDirectories := (binaryStream next: 4) uint32AtOffset: 0. Semi Functional Squeak: binaryStream := (FileStream readOnlyFileNamed: aFileLocation) binary yourself . wadType := (binaryStream next: 4) asString. numberOfDirectories :=(binaryStream next: 4). ? byteOffsetToDirectories := (binaryStream next: 4). ? Thanks for your assistance! Kind Regards, Cody

3 5

Help with keyboard layout when typing a caret
by Ivan Reche 03 May '24

03 May '24

Hey there! Total newbie here. I'm playing with Squeak on my vacation and I've noticed that, whenever I try to type a caret (^), which I believe is core to using Smalltalk, Squeak will insert an interrogation mark (?) in its place. I believe it must be something related to keyboard layout, but I have no idea on how to troubleshoot and fix this. Here is a screenshot to show what's happening: [image: image.png] My keyboard layout works just fine on GNOME. Thanks in advance! My environment: OS: Linux (GNOME DE) Keyboard layout: Portuguese ABNT2 Squeak version: Squeak6.0-22104-64bit-202206021410-Linux-x64

6 10

Re: [squeak-dev] Re: Trigonometric function error
by lewis＠mail.msen.com 03 May '24

03 May '24

Here is my attempt to summarize what we have covered so far in this discussion: In trunk today, both sin and cos are implemented in terms of #primitiveSine, installed as <primitive: 56> and accessed by Float>>sin. There is no #primitiveCosine. The lack of #primitiveCosine in the interpreter plugins is the source of the unexpected behavior reported in the beginning of this thread, in which #sin produced plausible looking (but not meaningfully correct) results for sin of large values, but #cos produced inconsistent results. Neither sin or cos was meaningfully correct, but the cos result is inconsistent and confusing. We also have the available FloatMathPlugin, which supports many math functions including #primitiveSin and #primitiveCos. These are not currently used by the trunk image. In general terms, FloatMathPlugin favors correctness over performance. In this context, "correctness" refers to correct float rounding behavior (see Nicolas' earlier references). If we want to fix the inconsistency as originally reported in this thread, then a simple solution is to implement #primitiveCosine in the interpreter. If we want a more generally correct implementation, then we should use the FloatMathPlugin primitives (presumably with fallback to the earlier implementations). There may be legitimate tradeoffs between performance and correctness here. As far as I know, no one has yet measured the performance impact of using FloatMathPlugin for sin and cos in trunk. I am not an expert here, just trying to summarize the discussion so please correct me where I have this wrong. Dave On 2024-05-01 09:33, Nicolas Cellier wrote: > Moreover, > I recommend reading this advocacy for providing correctly rounded > library for a set of mathematical functions: > https://hal.science/hal-04474530/document > > Even if accuracy sounds useless as pointed out by Vanessa, this > analysis was carried in a certain context. > But maybe it's vital to deliver accurate cos(10**22) for implementing a > multi-precision library, who knows, > we just can't guess in which context a general purpose computing > environment such as Squeak will be used. > So if a state of the art implementation exists, then we'd better > integrate it. > > I personally wanted to replace fdlibm used by FloatMathPlugin with > CRLibm, but was stopped by the uncertain maintenance status... > > Nicolas > > Le mer. 1 mai 2024 à 11:44, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> a écrit : > > Vanessa is perfectly right. However, the accuracy of our cos > implementation starts to degrade sooner than necessary. > > If I compare with ArbitraryPrecisionFloat, which has a faithfully > rounded implementation, > the sine tend to agree, at least on my Mac: > > #(1 10 100 1000 10000) > collect: [:f | ((f asArbitraryPrecisionFloatNumBits: 53) sin - f sin) > asFloat]. > -> #(0.0 0.0 0.0 0.0 0.0) > > For the cosine, see how the accuracy is degrading: > > #(1 10 100 1000 10000) > collect: [:f | ((f asArbitraryPrecisionFloatNumBits: 53) cos - f cos) > asFloat]. > -> #(0.0 0.0 2.6645352591003757e-15 4.2521541843143495e-14 > 2.274846977456946e-13) > > Our naive implementation of cos prevents us to benefit from the efforts > and knowledge put in the libm... > I would recommend using the FloatMathPlugin in trunk. > Bonus: we would get reproducible Float operations across OSes. > For the time being, this is not the case, our primitives rely on > various libm implementations provided by the OS. > So the sine will deliver different results on Windows MacOS and Linux > for example... > > Nicolas > > Le mer. 1 mai 2024 à 01:40, Vanessa Freudenberg <vanessa(a)codefrau.net> > a écrit : > > 10**22 > At that magnitude, each float is more than 1,000,000 apart: > > So there's MANY MANY multiples of pi in between successive floats. > Asking the sine or cosine of that is nonsensical. > > Vanessa > > On Tue, Apr 30, 2024 at 14:24 <lewis(a)mail.msen.com> wrote: > > On 2024-04-30 10:45, dgray(a)iesl.forth.gr wrote: > When I start messing about with a new language I have a few corner > cases I try out just to see what answers I expect. > For Squeak this has been OK except for cos. > The two numbers I check are totally away from those I routinely use but > are stress tests. > (10**22) sin. -0.8522008497671888 "which is correct" > (10**22) cos. -0.8522008497671888 "gives the same as sin which is > suspicious" > (2**120) sin. 0.377820109360752 "Also correct" > (2**120) cos. 0.377820109360752 "Also the same as the sin case. I > expect -0.9258790228548379" > _______________________________________________ > Beginners mailing list -- beginners(a)lists.squeakfoundation.org > To unsubscribe send an email to > beginners-leave(a)lists.squeakfoundation.org > > Hello and welcome to Squeak! Thank you very much for reporting this, > and congratulations on a very nice bug catch. > > I think that you have identified an issue related to floating point > data conversions. I am copying the main squeak-dev list on this, where > I anticipate some lively follow up discussion. > > For follow up on squeak-dev: The cosine logic for a large integer > involves first converting the integer to a Float, then sending > Float>>cos, which answers (self + Halfpi) sin. If the receiver is a > very large floating point value, then self + Halfpi is the same as > self, and we effectively calculate sin where cos was expected. At least > I think that's what's happening, I'm sure someone will correct me > quickly if I have it wrong :-) > > Dave

1 0

Trigonometric function error
by dgray＠iesl.forth.gr 02 May '24

02 May '24

When I start messing about with a new language I have a few corner cases I try out just to see what answers I expect. For Squeak this has been OK except for cos. The two numbers I check are totally away from those I routinely use but are stress tests. (10**22) sin. -0.8522008497671888 "which is correct" (10**22) cos. -0.8522008497671888 "gives the same as sin which is suspicious" (2**120) sin. 0.377820109360752 "Also correct" (2**120) cos. 0.377820109360752 "Also the same as the sin case. I expect -0.9258790228548379"

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Beginners May 2024