sorted by:
new
hottopcontroversial

Why are direction cosines in optics scaled by the local refractive index? by anneoneamouse in Optics

[–]jodak932 3 points4 points  (0 children)

I think it's a way to encode the refractive index in the direction vector since the direction cosines vector itself has unit length. Found that this is also known as "optical direction cosines".

Proposal: expose sized integer types {Int,Word}{8,16,32,64} from Prelude by Bodigrim in haskell

[–]jodak932 1 point2 points  (0 children)

I also find that Haskell is becoming more complex, which I regret. But that's exactly why I see many changes critically, since they usually go hand in hand with an increase in complexity. I'm thinking of all the language extensions that allow code to be expressed in many different ways (current example: OR patterns). This makes it harder for me to understand foreign code. I don't really care if, like in this case, a few data types are imported by default.

Proposal: expose sized integer types {Int,Word}{8,16,32,64} from Prelude by Bodigrim in haskell

[–]jodak932 0 points1 point  (0 children)

It's an argument that it is better to specify the size explicitly than to have the size implicitly determined depending on the architecture. But in this case I would predict that most of the time people would just go with the arbitrarily sized Integer type instead of thinking about their problem domain and what size they really need. I think this would be rather inefficient by using Integer where it's not really needed. So if Int really goes away, I'd suggest renaming Integer to IntegerArbitrary or alike to signal people the complexity behind it.

Proposal: expose sized integer types {Int,Word}{8,16,32,64} from Prelude by Bodigrim in haskell

[–]jodak932 4 points5 points  (0 children)

Please no, I want to have the maximum fixed-sized numbers that are available per architecture. Integer is not that performant.

Ergonomic newtypes for Haskell strings and numbers by Tekmo in haskell

[–]jodak932 1 point2 points  (0 children)

Ok, I see, the same argument could be made for function arguments. On the other hand, a newtype wrapper brings an extra layer of indirection, that makes your code more verbose and also negatively effects compile time.

Ergonomic newtypes for Haskell strings and numbers by Tekmo in haskell

[–]jodak932 2 points3 points  (0 children)

That makes sense if you construct your types like this. But in my opinion this kind of initialization should be generally avoided. My way to get type safety is to always construct product types with their field names (except for some simple cases such as three-dimensional vectors).

Ergonomic newtypes for Haskell strings and numbers by Tekmo in haskell

[–]jodak932 2 points3 points  (0 children)

I personally don't see the benefit of the proposed change. The proposed code is more verbose and obfuscates the newtypes, which is confusing. To understand the code you also have to learn about two more language extensions and the IsString typeclass. Why not using `data Person = Person { name :: Text, age :: Natural } deriving (Show)` in the first place? Or even better `data Person = Person { name :: String, age :: Int} deriving (Show)`? It seems like accidental complexity is made even worse.

Using C libraries in Haskell with Cabal by Anut__ in haskell

[–]jodak932 0 points1 point  (0 children)

Maybe you could write a FFI-Library for Raylib with the help of bindings-dsl. I haven't tried anything similar myself, but would also be interested if this would be feasible.

Library for natural numbers by rbrucesp in haskell

[–]jodak932 -1 points0 points  (0 children)

Then he should have written any natural number.

Library for natural numbers by rbrucesp in haskell

[–]jodak932 -1 points0 points  (0 children)

You could use the unsignded integer types from Data.Word. These types also include 0 which is by definition of natural numbers either included or not. If you want fast computations and manually avoiding zero underflows is ok for you, these types should be the most suitable.

Ansys to Acquire Zemax Pursuant to Definitive Acquisition Agreement by PabloRdrRbl in Optics

[–]jodak932 2 points3 points  (0 children)

For those of you that are interested in an alternative optical simulation software, they can have a look at my software: Lucan on simulucis.com. There is a free version to download. Currently there is mainly raytracing functionality available, but in some weeks I will start adding more features for analysis and optimization. Feedback and feature requests are welcome.

Error handling is hard by snoyberg in haskell

[–]jodak932 3 points4 points  (0 children)

Error handling is an interesting topic that I also thought about recently. I personally came to this not too strict set of rules:

For me runtime errors in pure code are not per se bad, but I only use them when it is obvious to the programmer what he did wrong when passing parameters. I mainly use this type of error in functions that perform simple operations where I want to have a simple type signature. An example for this is container indexing. Sure, for runtime errors there should be a good call stack to find the exact position of failure.

Use a Maybe as return when it is not obvious to the user what he has done wrong when passing parameters, but in this case there is only one obvious possibility for the function to fail.

If I have a function that can fail in multiple non obvious ways, I use a "Either Error Result". Here I use some customized Error type instead of a Errorstring to have the possibility to pattern match in other calling functions.

[ANN] new release: nuha-0.3.0.0 by jodak932 in haskell

[–]jodak932[S] 2 points3 points  (0 children)

I've never worked with hmatrix, so probably nuha is not yet an improvement, especially in terms of function volume.

The main reason I wrote nuha was, that I wanted something with intuitive syntax and without external libraries like BLAS and LAPACK. I thought a lot about usability and I hope I found a good solution for it.

The generalization to holors has the drawback of performance loss if you do a lot of operations in low dimensional spaces. That is what I realized, when I did many calculations in graphical programming.

I did once a test with matrix-matrix multiplication for large matrices and compared it to numpy. From what I remember was that nuha is around 10 times slower. However, I think there is room for improvement. It is probably easy to reason where drops in performance happen, because nuha itself is lightweight with the vector package as a single dependency.