The gluon with color (|g1> + |g2> + |g8>) / √3 is just a superposition of the gluons with colors g1, g2 and g8, the same way you can make superpositions of any other particles. You are right that the choice of basis vectors is arbitrary, but that doesn't make it wrong to count the number of dimensions. It also doesn't make it fundamentally different than, say, polarizations of photons or even flavors of quarks. You can have superpositions of photon polarizations or quark flavors.
All of these are continuous properties in an n-dimensional vector space.
It's in fact the opposite: an intentional design choice to make save scumming (edit: and by extension, sharing specific rng seeds) more effective for people who like doing it. They made a similar design choice with how save/restore works, in that it resets the current encounter, which allows players a limited ability to undo/backtrack if they make a mistake.
Yeah, this is basically stochastic dithering applied to numeric floating point quantization instead of image color quantization.
This makes me wonder whether you could apply different dithering approaches to numeric computations. You cannot use diffusion or similar mehods, because you don't have information about neighboring pixels/computations. Using low-discrepancy sequences might work to reduce stochastic noise, but it could also reintroduce bias for some computations.
Making laws more explicit in important cases is valuable because it reduces uncertainty about legal interpretation. Using your example of cellphone use, under distracted driving laws the prosecution would have to prove that the specific case of cellphone use was distracting enough to be a safety hazard. With the more specific ban on cellphones, that is no longer an obstacle.
It's great that this allows passing Rust structs both as ForeignPtr and as native records with marshalling!
Some questions/ideas:
- Is there a way to generate #[hsrs::data_type] bindings for Rust library types, or do you need to create custom wrapper types for them?
- It seems like all #[hsrs::function]s are translated to return IO (since Rust functions can do arbitrary side effects). It would be great if you could (unsafely) mark functions as pure, to get pure Haskell functions without having to wrap them in unsafePerformIO.
- Both Haskell and Rust have HM type systems, so I wonder if you could also translate type classes from Rust to Haskell.
> - Is there a way to generate #[hsrs::data_type] bindings for Rust library types, or do you need to create custom wrapper types for them?
At the moment, no. I'll ad this to the list of features for 0.2, totally slipped my mind, and if I remember correctly, both napi-rs and pyo3 have support for this.
> - It seems like all #[hsrs::function]s are translated to return IO (since Rust functions can do arbitrary side effects). It would be great if you could (unsafely) mark functions as pure, to get pure Haskell functions without having to wrap them in unsafePerformIO.
I did think through this a little bit and couldn't find a good way to implement this so decided to delay it until the next release, until I come up with some better ideas.
I wanted some sort of automated mechanism to determine purity, but that, obviously, doesn't exist in Rust. There _are_ some ways to approach this -- `const fn` are pure (I think), and it would be cool if I added support for https://github.com/creusot-rs/creusot. I was thinking of walking down the AST of a function to automatically infer purity, but that seems like a whole other, order-of-magnitude larger project. I'm still not sure what to do about this (bar a simple annotation), but I'll land something for 0.2. https://github.com/harmont-dev/hsrs/issues/1
> - Both Haskell and Rust have HM type systems, so I wonder if you could also translate type classes from Rust to Haskell.
Yes!! I do think that would be quite neat and I spent a little bit of time thinking through it, but I couldn't really come up with a great use-case (at least for my needs) that justified the necessity of this feature. This _might_ (probably won't) land 0.2, but it's definitely something I'm thinking about. One of the big problems that makes this quite non-trivial is monomorphization -- it's unclear what kind of specializations of a particular generic function you want in Rust. Trait objects _should_ be able to work, but I still haven't figured out the details of all of that. https://github.com/harmont-dev/hsrs/issues/2
I think purity is something the programmer just has to annotate themselves. Any boundary between languages with different type system guarantees will always have this kind of friction - Rust to C/C++ FFI also has to deal with ownership, lifetimes and aliasing manually.
Regarding type classes, monomorphisation indeed seems like a difficult obstacle for polymorphic function. But just translating type classes and impls might not be as difficult? So going from:
trait Foo {
fn foo(&self);
}
impl Foo for Bar {
fn foo(&self) {...}
}
to
class Foo a where
foo :: a -> IO ()
instance Foo Bar where
foo :: Bar -> IO ()
foo self = ...
Monads got their name from monoids (being a monoid in the category of endofunctors). Monoids are equivalent to one-object categories, so the name uses the greek syllable "mono" for one.
I've noticed this with UI interfaces before: For example, an IBAN field which actively blocks you from entering more than the expected number of characters. Seems like a good idea - except whoever sent me their account number helpfully included spaces to separate blocks of numbers, so when I copy-paste it the last few digits get cut off. Now I not only have to delete the spaces, but also copy the missing digits again! Just make the field red and block me from submitting until I fix my input!
Does "Pharma" actually dose medication based on the Eyring equation? I'm not convinced we actually know the value of ΔG. AFAIK, the optimal biological dose is determined via dose-ranging studies during Phase I/II of clinical trials. And drug metabolism rate is measured, not derived from theoretical models.
All of these are continuous properties in an n-dimensional vector space.
reply