@steve@discuss.systems
@steve@discuss.systems avatar

steve

@steve@discuss.systems

“Not a number expert.”
On-point like decimals.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

steve, to TVTooHigh
@steve@discuss.systems avatar

TFW #TVTooHigh but you left multiple feet of wall above it anyway. Aim higher! Do better!

#RealEstateShitposting

azonenberg, to random
@azonenberg@ioc.exchange avatar

Not sure if this is a gcc bug or some weird corner of UB or what...

But I have a packed struct containing a uint32 as the first field. I'm running on ARMv7-M so 32-bit unaligned loads are allowed (but not 64-bit).

This struct is being read directly via casting from a network RX buffer that is likely not aligned to any particular byte boundary. It's a) packed and b) has 32-bit fields in it.

So silly me assumed that gcc would generate either bytewise reads (assuming no alignment at all) or a ldr instruction (accepting that 32-bit unaligned loads are OK).

But for some reason at -O3 it generates a 64-bit read with ldrd, which promptly hard faults. I have no idea why it's doing that given that I was just __builtin_bswap32'ing a single 32-bit field.

Was able to work around the issue with memcpy, but seriously WTF? If I'm using a packed struct I'm explicitly telling the compiler not to make any assumptions about alignment because I'm directly serializing the data from somewhere. Where did it magically get the idea that my packed 32-bit field had 64-bit alignment?

steve,
@steve@discuss.systems avatar

@azonenberg @whitequark a uint32_t * by definition is suitably aligned for uint32_t (i.e. four-byte). You need to load via a pointer type with weaker alignment, or memcpy to get defined behavior.

steve,
@steve@discuss.systems avatar

@azonenberg @whitequark the loads the architecture supports are irrelevant, it’s the ABI alignment.

steve, to random
@steve@discuss.systems avatar

Greetings from the most valuable vacant lot in America.

(Alt: the grassy expanse that used to be the Vallco Mall, just across the highway from Apple Park. Vacant now for five years.)

steve,
@steve@discuss.systems avatar

@kviksilver I assume we have the secret underground circle there already

steve, to random
@steve@discuss.systems avatar

So far this evening I have cooked steak and rebuilt a carburetor. I think this is the most American I’ve ever felt.

steve, to random
@steve@discuss.systems avatar

The kids weren’t taking tick checks seriously, so I offered them a dollar for every tick they find. I will definitely not regret the perverse incentive this creates.

thomasfuchs, to random
@thomasfuchs@hachyderm.io avatar

USA! USA! USA!

steve,
@steve@discuss.systems avatar

@thomasfuchs @Naranjadia humans can’t even do this reliably! (In the general case. Here it’s laughably easy.)

steve, to random
@steve@discuss.systems avatar

But really, how would you explain how to use chopsticks to someone who has never seen them before and is setting out to learn how only by reading your book?

The lower is fixed with the base of the thumb pressing down (D in Figure 2), and the base of the index finger (U) and the thumb side of the end of the ring-finger (U’) both pressing upwards. Keep this lower chopstick there and never let it slide or roll. The upper chopstick is held in a floating position. The tip of the thumb holds it down as a fulcrum (F in Fig. 2). The tips of the index and middle fingers pinch and push on both sides of the chopstick farther down toward the food end. When the index finger pushes down harder at P (power), the tip at L (load) comes down and pinches the food against the fixed chopstick. When the middle finger presses up harder at P’, the tip is raised (to position shown by dotted lines) and the pincer is opened to make ready to get another morsel. This opening motion, when done firmly, can also separate food, such as meat or chicken, when well done. In moving the upper chopstick up and down, a slight rolling may be caused by its upper part resting on the side of the index finger. But this slight rolling makes no difference in the result. Two important conditions for effective use of chopsticks must be remembered. One is that the two lower ends must be even, that is, one must not protrude over the other. The other condition is that the two chopsticks must be in the same plane. You need not know much geometry to see that unless these conditions are met, you cannot make your two ends meet.

steve, to random
@steve@discuss.systems avatar

I’ll be in Oxford and London next month, let me know if anyone wants to say hi.

steve, to random
@steve@discuss.systems avatar

This implementation of cos(πx) and sin(πx) for Float16 came out pretty neat: https://github.com/stephentyrone/swift-numerics/blob/trig-pi/Sources/_NumericsShims/sincospif16.s

Throughput for this scalar implementation is about 1.75ns/element on M1, which is ... tolerable. I expect that it could go somewhat faster, but this is nice and pretty tidy.

The equivalent pure Swift implementation I have takes about 2.3ns/element, largely due to not having a means to do a "convert float to integer, and just give me some don't-care value if its out of range" (which you can't spell in C either), but I already put a patch up to add the machinery that I need for it in Swift, so we'll get that straightened out and see where we stand.

steve, to random
@steve@discuss.systems avatar

Seven-year old: “sometimes I wish I were a tiger because it’s scary to tell someone that you like them but tigers can just pee to let everyone know that they’re looking for a mate.”

steve, to random
@steve@discuss.systems avatar

A slight re-organization of Priest's "Efficient Scaling for Complex Division" to make it compatible with "try to divide the dumb fast way inline, then branch to rescale only if necessary" while preserving scale invariance of rounding.

Also fixes it up to work for Float16, which the original approach does not.

Further optimization possible and pretty straightforward.

https://github.com/apple/swift-numerics/pull/289

schwa, (edited ) to random
@schwa@mastodon.social avatar

deleted_by_author

  • Loading...
  • steve,
    @steve@discuss.systems avatar

    @schwa and I’d do it again!

    steve,
    @steve@discuss.systems avatar

    @schwa … if you like % so much, you can define it?

    steve, to random
    @steve@discuss.systems avatar

    /reads about a romance author getting locked out of google docs for inappropriate content/

    “See, this is American Puritanism run amok.”

    /continues reading, gets to the bit where they write “hockey romance”/

    “You know what, Google might be right about this.”

    whitequark, to random
    @whitequark@mastodon.social avatar

    (reverse engineering something voice)
    msvcrt was a mistake
    also, c++ was a mistake

    steve,
    @steve@discuss.systems avatar

    @whitequark movfuscator, but make it SIMD

    pervognsen, to random
    @pervognsen@mastodon.social avatar

    This classic blog post resurfaced on the Rust subreddit today after someone posted that they wished ownership had been explained to them with a metaphor about pirate treasure chests.

    https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

    'But now Joe goes and writes a monad tutorial called “Monads are Burritos,” under the well-intentioned but mistaken assumption that if other people read his magical insight, learning about monads will be a snap for them. “Monads are easy,” Joe writes. “Think of them as burritos.”'

    steve,
    @steve@discuss.systems avatar

    @pervognsen @pkhuong @zwarich how many people even understand addition? https://ncatlab.org/nlab/show/carrying

    steve,
    @steve@discuss.systems avatar

    @pervognsen @pkhuong @zwarich that’s right, it’s very simple, carrying is a 2-cocycle in the group cohomology, hence a morphism of infinity-groupoids

    pervognsen, to random
    @pervognsen@mastodon.social avatar
    steve,
    @steve@discuss.systems avatar

    @pervognsen floating-point isn't the problem here, fixed-width types are. This wouldn't be any different if JS had "Int32" as its universal number type.

    steve,
    @steve@discuss.systems avatar

    @pervognsen /gleefully rubs hands while sketching out "computational real serialization format"/

    (no, no, we need something that gives us "CRAP", hmmm...)

    steve,
    @steve@discuss.systems avatar

    @pervognsen “my spreadsheet’s been loading for two days, but I can’t tell if the process is hung or not.”

    steve, to random
    @steve@discuss.systems avatar

    The world is shit, but I got to write assembly for like two hours this morning, so life is OK.

    steve,
    @steve@discuss.systems avatar

    The world if we made everyone write assembly

    steve, to random
    @steve@discuss.systems avatar

    The Two Cultures:

    Neighbor A: /invites everyone over for May-the-fourth potluck/
    Neighbor B: Sadly, i will miss out. I will be at the Venice Biennale. Next year?

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • mdbf
  • everett
  • osvaldo12
  • magazineikmin
  • thenastyranch
  • rosin
  • normalnudes
  • Youngstown
  • Durango
  • slotface
  • ngwrru68w68
  • kavyap
  • DreamBathrooms
  • tester
  • InstantRegret
  • ethstaker
  • GTA5RPClips
  • tacticalgear
  • Leos
  • anitta
  • modclub
  • khanakhh
  • cubers
  • cisconetworking
  • megavids
  • provamag3
  • lostlight
  • All magazines