- Libraries - Haskell.org

Re: [core libraries] Rename NonEmpty.groupWith/sortWIth to *On*
by Carter Schonwald 29 Feb '20

29 Feb '20

I think I follow. Pedantic point : when you say semantics, it might be less confusing and more precise to performance tradeoffs. My English language and naive preference is to assume *With functions grammar better. Or *by. I think the *on idiom is younger relatively. Can I challenge you to reflect on what challenge you are trying to address with this proposal and if there’s a course of action that you feel improves everything but breaks no code ? And what would make the change an improvement for software using these modules already On Sat, Feb 15, 2020 at 7:36 AM Philip Hazelden <philip.hazelden(a)gmail.com> wrote: > Hi, > > > clc gets / reads libraries anyways, no need to double email : ) > > Fair enough. I tried to follow the process suggested at > https://wiki.haskell.org/Core_Libraries_Committee by emailing both lists. > I was surprised that the mail to libraries@ got rejected. No big deal, > but should that page be updated? > > > are we talking about the specifics of the implementations while stilling > having the same observable pure results, OR something different? > > For sortWith/sortOn, yeah, my proposal #3 would change performance > characteristics but not the pure semantics. > > The existing functions that we have are > > Data.List.sortOn f = > map snd . sortBy (comparing fst) . map (\x -> let y = f x in y `seq` > (y, x)) > GHC.Exts.sortWith f = sortBy (\x y -> compare (f x) (f y)) > Data.List.NonEmpty.sortWith = sortBy . comparing > > Where the first two have type signature `Ord b :: (a -> b) -> [a] -> [a]` > and the last is `Ord b :: (a -> b) -> NonEmpty a -> NonEmpty a`. > > Data.List.sortOn is implemented in a way that calls its projection > function just once per list element, but it allocates an intermediate list. > If the projection function is expensive, that'll be worth it. The style of > the functions named sortWith avoids the intermediate list, but at the cost > of calling the projection twice for each comparison; so that'll be better > if the projection is cheap. > > I bring this up because issue 12044 suggested removing `GHC.Exts.sortWith` > for being semantically the same as `Data.List.sortOn`, and the performance > question was brought up there. To be clear, I don't think it's a big deal. > > > please spell this out more concretely, i'm not able to decode what you > mean unambiguiously. Just changing the names of some functions in base in > isolation breaks code for no reason, > > My proposals #1 and #2 are just to change the names of functions, yeah. > But it's not for no reason. > > There are two problems with the current names. The smaller one, applying > to all of these functions, is that I believe the "On" pattern is more > widely used. And so if a user tries to guess what these functions will be > called, they'll most likely go for that. > > (I don't have any hard data here, admittedly. We see "On" in > Data.List.sortOn, but also many functions in Data.List.Extra like `nubOn`, > `groupOn`, `maximumOn`. Admittedly that's not in base. But I'll also note > that NonEmpty.sortWith was originally called sortOn, and the groupWith > functions were originally requested with the name groupOn; see > https://github.com/ekmett/semigroups/pull/52. So yeah, my sense is that > "On" is what most people will expect.) > > The more significant one, applying to the group functions but not to > sortWith, is that the only other function in base named `groupWith` has a > comparable type signature but different semantics. > Data.List.NonEmpty.groupWith is "group according to a projection function" > while GHC.Exts.groupWith is "sort and group according to a projection > function". If someone gets these behaviours confused, they're going to sort > when they don't intend to, or to not sort when they do intend to. Using > more consistent naming may help avoid that. > > It may be that this isn't enough reason to break code. If the committee > decides that it's not, then fair enough. > > Though, it now occurs to me that renaming `GHC.Exts.groupWith` to > `groupAllOn` or `groupAllWith` or something (in Data.List.Extra it's named > "groupSortOn"), could also help clear up the larger problem while breaking > less code. So I'll offer that possibility for consideration too. > > > > On Thu, Feb 13, 2020 at 10:17 PM Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> Hello Philip, clc gets / reads libraries anyways, no need to double email >> : ) >> >> perhaps i'm missing something, are we talking about the specifics of the >> implementations while stilling having the same observable pure results, OR >> something different? >> >> When does each have a clear performance win? >> >> at least from my native english speaker perspective, sortWith is better >> grammar. Are you describing a choice of performance characteristics >> related to *On vs *With functions? >> >> also, could you spell out which reference implementations of which >> convention enshrine which meanings you have in mind? >> >> I dont see a good reason to change the names that are provided from one >> to the other. Are you merely making the case that both styles should be >> exported from certain places, and that a particular choice of evaluation >> trade offs be enshrined by the respective naming convention? >> >> >> please spell this out more concretely, i'm not able to decode what you >> mean unambiguiously. Just changing the names of some functions in base in >> isolation breaks code for no reason, so if you are arguing for that, i'm >> gonna say nope :) >> >> On Wed, Feb 12, 2020 at 12:58 PM Philip Hazelden < >> philip.hazelden(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'm referring to these functions: `sortWith` `groupWith` `groupAllWith` >>> `groupWith1` `groupAllWith1`. >>> >>> The `On` suffix is more common for such things, and I anticipate it's >>> what most users will normally expect them to be named. >>> >>> Additionally, the name `groupWith` is potentially misleading. That name >>> is also used in GHC.Exts[1], for a function with the same type signature >>> but different semantics. `GHC.Exts.groupWith` sorts its input list, unlike >>> `NonEmpty.groupWith` or `Data.List.Extra.groupOn`. (In NonEmpty, we have >>> `groupAllWith` for group-with-sort. So we have three names, two semantics, >>> and no consistency.) >>> >>> According to https://github.com/ekmett/semigroups/pull/52, `With` was >>> chosen because: >>> >>> > The preferred vocabulary for On here is With to match the combinators >>> in GHC.Exts from the "comprehensive comprehensions" paper. That'd make it >>> so that if you use these with comprehensive comprehensions turned on and >>> RebindableSyntax turned on then you'd get these combinators. >>> >>> But I don't see anything in the docs which suggests that the >>> TransformListComp extension[2] uses these functions implicitly, or >>> interacts with RebindableSyntax[3]. So perhaps I'm missing something, but >>> my guess is this is no longer a concern. >>> >>> The case for `sortWith` is weaker, since it might trip people up but it >>> won't introduce unexpected semantics. There's also a counter argument in >>> https://gitlab.haskell.org/ghc/ghc/issues/12044. `Data.List.sortOn` >>> only computes the mapping function once for each element, while >>> `GHC.Exts.sortWith` computes it every time it does a comparison but uses >>> fewer allocations. `Data.NonEmpty.sortWith` acts like the latter. My >>> suggestion would be to replace it with a `sortOn` implemented like >>> `Data.List.sortOn`, but I also don't think it would be terrible to have >>> both, or even to just rename and leave this small inconsistency. If there's >>> no agreement on this function, I think it would be worth renaming the group >>> functions anyway. >>> >>> And so I propose, in descending order of how much I care: >>> >>> 1. Rename the group functions to be named "On" instead of "With". >>> >>> 2. Rename `sortWith` to `sortOn` In the case of `sortWith`, also >>> reimplement it as >>> >>> 3. Reimplement `sortOn` as >>> >>> sortOn :: Ord b => (a -> b) -> NonEmpty a -> NonEmpty a >>> sortOn = fmap snd . sortBy (comparing fst) . fmap (\x -> let y = f x >>> in y `seq` (y, x)) >>> >>> I assume the process here would be to leave the existing names for a >>> time with deprecation warnings, and then remove them a few versions down >>> the line. >>> >>> [1] >>> https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#v:grou… >>> [2] >>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… >>> [3] >>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… >>> >>> Best, >>> Phil >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "haskell-core-libraries" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvF… >>> <https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvF…> >>> . >>> >>

5 7

Welcome emily and Cale!!
by Carter Schonwald 28 Feb '20

28 Feb '20

Let’s welcome Cale and emily! Before general announce probably good to figure out that voting for chair thing eds stepping down from. @ed: what does chairing clc entail? Also Neil somehow wasn’t on the list before so Ccing him just in case. -Carter

1 1

Is a a way to do a “Bare” state monad in modern Haskell?
by Carter Schonwald 22 Feb '20

22 Feb '20

1) we have a monad instance for (r -> ) 2) is there some way we can arrange sans newtype an instance for its state monad sibling ( /\ x . s-> (s,x)) without a type lambda or some new type or injective type families? I can definitely see that this is def not possible with h98-h2010, is this otherwise expressible? Mostly just curious if there’s some trick that’s now possible :)

2 1

Replace Random
by dominic＠steinitz.org 18 Feb '20

18 Feb '20

Hello libraries, Following a great blog [post] by @lehins, a group of us (@curiousleo, @lehins and me) are trying to improve the situation with the `random' library. @curiousleo and I have created a [resource] that tests the quality of Haskell random number generators via well known (and not so well known) test suites: dieharder, TestU01, PractRand and gjrand. The current `random' does not fare well especially with the use of the `split' function (but this is well known and the [reason] why `QuickCheck' moved from using it in [2.8] to using [tf-random] in [2.9] and latterly [splitmix] in [2.13]): see [this] for example. On the other hand, `splitmix' [passes] bigcrush[1]. The putative proposal is to replace the current algorithm in `random' with that of `splitmix'[2] and to remove the performance bottleneck by changing the interface (the current interface causes the performance infelicity by making "all of the integral numbers go through the arbitrary precision Integer in order to produce the value in a desired range") - see @lehin's blog for more details. Can anyone interested: * Create a separate issue for each concern they have (eg. range for floats (0, 1] vs [0, 1], etc.) [here]. * Submit PRs with target at the [interface-to-performance] branch (or into master if it is vastly different approach) with your suggested alternatives. If you are going to raise a concern then it might be worth reading some of the [discussions] that have already taken place. We think once we have the API flashed out, switching to splitmix will be a piece of cake and will require an addition of just a few lines of code and removal of current StdGen related functionality. For historical reasons instead of removing it we could move StdGen into a separate module with a disclaimer not to use it, but that isn't terribly important. The Random Team (@lehins, @curiousleo, @idontgetoutmuch) [post] https://alexey.kuleshevi.ch/blog/2019/12/21/random-benchmarks/ [resource] https://github.com/tweag/random-quality [reason] http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf [2.8] https://hackage.haskell.org/package/QuickCheck-2.8 [tf-random] https://hackage.haskell.org/package/tf-random [2.9] https://hackage.haskell.org/package/QuickCheck-2.9 [splitmix] https://hackage.haskell.org/package/splitmix [2.13] https://hackage.haskell.org/package/QuickCheck-2.13 [this] https://github.com/tweag/random-quality/blob/master/results/random-word32-s… [passes] https://github.com/tweag/random-quality/blob/master/results/splitmix-word32… [here] https://github.com/idontgetoutmuch/random/issues [interface-to-performance] https://github.com/idontgetoutmuch/random/tree/interface-to-performance [discussions] https://github.com/idontgetoutmuch/random/pull/1 Footnotes _________ [1] Just to clarify: both random and splitmix pass BigCrush. random fails any statistical test immediately (e.g. [SmallCrush] (https://github.com/tweag/random-quality/blob/master/results/random-word32-s…) and other even smaller ones) when a sequence based on split is used. splitmix passes Crush when split is part of the sequence, but I've seen it fail one test in BigCrush ("LinearComp"). So we should just be careful here: splitmix itself passes BigCrush and split-based sequences all pass Crush, but not all pass BigCrush. [2] `split' is already availaible as an instance: `instance Random SMGen where'.

2 3

Taking over maintainership of cautious-file (or does anyone know of an alternative?)
by Brent Yorgey 13 Feb '20

13 Feb '20

The cautious-file package http://hackage.haskell.org/package/cautious-file has not been updated by the maintainer, Robin Green, since 2013 (though there have been a few Hackage trustee updates since then). The linked source repository was hosted on patch-tag.com and no longer exists. I tried contacting the maintainer on January 25 but have not heard back. I hereby announce my intention to take over as maintainer of the package. (As a side note, as far as I know my diagrams-haddock package is the only thing on Hackage that depends on it.) Alternatively, if anyone knows of a different, actively maintained package that provides similar functionality, I'd love to hear about it! -Brent

3 3

Re: [core libraries] Rename NonEmpty.groupWith/sortWIth to *On*
by Carter Schonwald 13 Feb '20

13 Feb '20

Hello Philip, clc gets / reads libraries anyways, no need to double email : ) perhaps i'm missing something, are we talking about the specifics of the implementations while stilling having the same observable pure results, OR something different? When does each have a clear performance win? at least from my native english speaker perspective, sortWith is better grammar. Are you describing a choice of performance characteristics related to *On vs *With functions? also, could you spell out which reference implementations of which convention enshrine which meanings you have in mind? I dont see a good reason to change the names that are provided from one to the other. Are you merely making the case that both styles should be exported from certain places, and that a particular choice of evaluation trade offs be enshrined by the respective naming convention? please spell this out more concretely, i'm not able to decode what you mean unambiguiously. Just changing the names of some functions in base in isolation breaks code for no reason, so if you are arguing for that, i'm gonna say nope :) On Wed, Feb 12, 2020 at 12:58 PM Philip Hazelden <philip.hazelden(a)gmail.com> wrote: > Hi, > > I'm referring to these functions: `sortWith` `groupWith` `groupAllWith` > `groupWith1` `groupAllWith1`. > > The `On` suffix is more common for such things, and I anticipate it's what > most users will normally expect them to be named. > > Additionally, the name `groupWith` is potentially misleading. That name is > also used in GHC.Exts[1], for a function with the same type signature but > different semantics. `GHC.Exts.groupWith` sorts its input list, unlike > `NonEmpty.groupWith` or `Data.List.Extra.groupOn`. (In NonEmpty, we have > `groupAllWith` for group-with-sort. So we have three names, two semantics, > and no consistency.) > > According to https://github.com/ekmett/semigroups/pull/52, `With` was > chosen because: > > > The preferred vocabulary for On here is With to match the combinators in > GHC.Exts from the "comprehensive comprehensions" paper. That'd make it so > that if you use these with comprehensive comprehensions turned on and > RebindableSyntax turned on then you'd get these combinators. > > But I don't see anything in the docs which suggests that the > TransformListComp extension[2] uses these functions implicitly, or > interacts with RebindableSyntax[3]. So perhaps I'm missing something, but > my guess is this is no longer a concern. > > The case for `sortWith` is weaker, since it might trip people up but it > won't introduce unexpected semantics. There's also a counter argument in > https://gitlab.haskell.org/ghc/ghc/issues/12044. `Data.List.sortOn` only > computes the mapping function once for each element, while > `GHC.Exts.sortWith` computes it every time it does a comparison but uses > fewer allocations. `Data.NonEmpty.sortWith` acts like the latter. My > suggestion would be to replace it with a `sortOn` implemented like > `Data.List.sortOn`, but I also don't think it would be terrible to have > both, or even to just rename and leave this small inconsistency. If there's > no agreement on this function, I think it would be worth renaming the group > functions anyway. > > And so I propose, in descending order of how much I care: > > 1. Rename the group functions to be named "On" instead of "With". > > 2. Rename `sortWith` to `sortOn` In the case of `sortWith`, also > reimplement it as > > 3. Reimplement `sortOn` as > > sortOn :: Ord b => (a -> b) -> NonEmpty a -> NonEmpty a > sortOn = fmap snd . sortBy (comparing fst) . fmap (\x -> let y = f x > in y `seq` (y, x)) > > I assume the process here would be to leave the existing names for a time > with deprecation warnings, and then remove them a few versions down the > line. > > [1] > https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#v:grou… > [2] > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… > [3] > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… > > Best, > Phil > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe(a)googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvF… > <https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvF…> > . >

1 0

Fwd: add instance PrintfArg Ratio
by Dannyu NDos 10 Feb '20

10 Feb '20

---------- Forwarded message --------- 보낸사람: Dannyu NDos <ndospark320(a)gmail.com> Date: 2020년 2월 9일 (일) 오후 3:14 Subject: Re: add instance PrintfArg Ratio To: Henning Thielemann <lemming(a)henning-thielemann.de> Bugfix: instance (Integral a, PrintfArg a) => PrintfArg (Ratio a) where formatArg x f@(FieldFormat w p a s l _ c) = if elem c "gGv" then let d = " % " ++ formatArg (denominator x) (FieldFormat Nothing Nothing Nothing s l "" 'd') "" (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length d)) w, a) n = formatArg (numerator x) (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'd'}) "" in formatArg (n ++ d) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "doxXb" then formatArg (round x :: Integer) f else case p of Nothing -> error "Text.Printf.formatArg: precision not given" Just p' -> if p' <= 0 then formatArg x (f {fmtPrecision = Nothing, fmtChar = 'd'}) else if elem c "fF" then let a' = case a of Just LeftAdjust -> Nothing _ -> a digits = formatArg (truncate (x * 10 ^ p') :: Integer) (f {fmtPrecision = Nothing, fmtAdjust = a', fmtChar = 'd'}) "" (n,sig) = splitAt (length digits - p') digits in formatArg (n ++ '.' : sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "eE" then let (q,e) = log10 x sig = c : show e (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length sig)) w, a) fp = formatArg q (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'f'}) "" in formatArg (fp ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else error "Text.Printf.formatArg: bad format character" where goF _ 0 = "" goF x p = case compare x 0 of LT -> '-' : goF (negate x) p EQ -> "0" GT -> if 1 == p then show (round (10 * x) :: Integer) else let x10 = 10 * x n = truncate x10 in show n ++ goF (x10 - fromIntegral n) (p - 1) log10 x | x < 1 = let (q,e) = log10 (x * 10) in (q, e - 1) | 10 <= x = let (q,e) = log10 (x / 10) in (q, e + 1) | otherwise = (x, 0)

3 4

Performance of `count`ing a char in a ByteString
by Georg Rudoy 08 Feb '20

08 Feb '20

Hi there, tl;dr: I've noticed ByteString's `count`'s performance can be improved by a factor between 2.5 and 8 by explicitly using certain SIMD extensions, so what's the policy on those? Results of a small C benchmark (since the corresponding BS routine is implemented in C anyway) are available here ( https://github.com/0xd34df00d/counting-chars ), as well as some sample code to give the idea of what's happening (which might be incorrect/suboptimal, my SSE/AVX is rusty). I'll also put a sample input file if I manage to get git-lfs going. This change only really makes sense for large strings, but that's a somewhat common use case at least in my applications, so I wanted to gather some initial feedback, as well as ask a couple of questions and emphasize a couple of points. 1. How are SIMD extensions generally controlled? 2. Is depending on gcc OK? If so, we could leverage gcc's support of automatically generating a dispatching function that'll check cpuid for the supported extensions and call the right implementation. 3. Does BS' allocator give any guarantees on the alignment? It'd be nice to get rid of that "prefix" part that makes sure the SIMD code churns through 64-byte-aligned data. 4. Note that compiling with `-O3 -march=native` makes code effectively non-portable (at least, to CPUs lacking extensions the compiler decides to use), while the code with `-O2`, explicit SIMD versions and a dispatching function will get the best performance using the SIMD extensions available, degrading gracefully on older hardware. So, personally, when I look at that table with the results I compare the SSE4.2/AVX2 implementations against the `-O2` column. 5. Thanks Gregory Collins for mentioning PCMPESTRM somewhere — that remark sparked the desire to do some intrinsics stuff. -- Georg Rudoy

2 2

Fwd: add instance PrintfArg Ratio
by Dannyu NDos 08 Feb '20

08 Feb '20

---------- Forwarded message --------- 보낸사람: Dannyu NDos <ndospark320(a)gmail.com> Date: 2020년 2월 8일 (토) 오전 8:22 Subject: Re: add instance PrintfArg Ratio To: Henning Thielemann <lemming(a)henning-thielemann.de> In that case, here (with some bugfixes): instance (Integral a, PrintfArg a) => PrintfArg (Ratio a) where formatArg x f@(FieldFormat w p a s l _ c) = if elem c "gGv" then let d = " % " ++ formatArg (denominator x) (FieldFormat Nothing Nothing Nothing s l "" 'd') "" (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length d)) w, a) n = formatArg (numerator x) (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'd'}) "" in formatArg (n ++ d) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "doxXb" then formatArg (round x :: Integer) f else case p of Nothing -> error "Text.Printf.formatArg: precision not given" Just p' -> if p' <= 0 then formatArg x (f {fmtPrecision = Nothing, fmtChar = 'd'}) else if elem c "fF" then let n = truncate x sig = '.' : goF (x - fromInteger n) p' (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length sig)) w, a) b = formatArg n (FieldFormat w' Nothing a' s l "" 'd') "" in formatArg (b ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "eE" then let (q,e) = log10 x sig = c : show e (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length sig)) w, a) fp = formatArg q (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'f'}) "" in formatArg (fp ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else error "Text.Printf.formatArg: bad format character" where goF _ 0 = "" goF x p = case compare x 0 of LT -> '-' : goF (negate x) p EQ -> "0" GT -> if 1 == p then show (round (10 * x) :: Integer) else let x10 = 10 * x n = truncate x10 in show n ++ goF (x10 - fromIntegral n) (p - 1) log10 x | x < 1 = let (q,e) = log10 (x * 10) in (q, e - 1) | 10 <= x = let (q,e) = log10 (x / 10) in (q, e + 1) | otherwise = (x, 0) 2020년 2월 8일 (토) 오전 6:44, Henning Thielemann <lemming(a)henning-thielemann.de>님이 작성: > > On Fri, 7 Feb 2020, Dannyu NDos wrote: > > > It just is so convenient. > > > > instance (Integral a, Show a) => PrintfArg (Ratio a) where > > Why should a Printf instance be base on Show? Wouldn't it better to format > numerator and denominator using printf, too? >

1 1

Re: Break `abs` into two aspects
by Andrew Lelechenko 08 Feb '20

08 Feb '20

On Tue, 28 Jan 2020, Dannyu NDos wrote: > `abs` represents a norm, but its type is wrong There are two useful meanings of `abs`, which coincide for integers. One is a norm. Another one is to define `abs` as a mapping from a ring R to a factor ring R / U(R), where U(R) is a ring of units, and `signum` as a mapping from R to U(R) such that `abs a * signum a = a`. > This enables us to implement rings (Num) and fields (Fractional) without > concerning about norms. For example, Gaussian integers. For Gaussian integers I find convenient to define `signum z` with a codomain {1, i, -1, -I} (basically, to which quadrant does z belong?) and `abs z` with the first quadrant as a codomain. Best regards, Andrew

5 20