|
01:13
sibl joined
01:26
stanrifkin left
01:33
sibl left
01:37
arkiuat left
01:42
arkiuat joined
01:49
arkiuat left
02:01
arkiuat joined
02:44
kylese left
02:45
kylese joined
03:15
kylese left,
kylese joined
03:23
vasko453558 left
03:24
vasko453558 joined
04:28
lichtkind__ joined
04:31
lichtkind_ left
04:53
Aedil joined
04:55
sibl joined
05:16
sibl left
05:27
arkiuat left
05:44
sibl joined
06:01
arkiuat joined
06:05
arkiuat left
06:23
arkiuat joined
06:32
sibl left
06:50
arkiuat left
07:04
arkiuat joined
07:09
arkiuat left
07:21
arkiuat joined
07:25
arkiuat left
07:46
arkiuat joined
07:51
arkiuat left
08:20
arkiuat joined
08:25
arkiuat left
08:45
arkiuat joined
08:50
arkiuat left
09:19
arkiuat joined
09:23
arkiuat left
09:50
arkiuat joined
09:55
arkiuat left
10:23
arkiuat joined
10:27
arkiuat left
10:50
arkiuat joined
10:55
arkiuat left
11:24
arkiuat joined
11:28
arkiuat left
11:39
librasteve_ joined
|
|||
| disbot6 | <librasteve> 0/ | 11:44 | |
| <librasteve> patrickb: sorry - was &Afk - looks like this is fine now | 11:46 | ||
|
11:52
arkiuat joined
12:00
arkiuat left,
abraxxa-home joined
12:01
abraxxa-home left
12:02
abraxxa-home joined
|
|||
| disbot6 | <librasteve> korvo: great post - thanks - I have cleaned it up a bit (mainly Wordpress markdown block are very poor so I had to split the early part into multiple markdown sections) - this is now scheduled for publishing early tomorrow am (UTC) | 12:10 | |
| <librasteve> ab5tract: you are next up so need your draft sometime tomorrow (15th) please - please let us know if that is not doable (!) | 12:11 | ||
| Geth | advent/main: 54a15d1ca9 | librasteve++ (committed using GitHub Web editor) | raku-advent-2025/authors.md Update authors.md |
12:12 | |
| disbot6 | <librasteve> generally - any ideas with what to do with the 3 empty slots 17/18/19?? | ||
|
12:26
arkiuat joined
12:31
Sgeo left
|
|||
| patrickb | librasteve_: no worries. I don't know who added a header image, but it's there. (Thanks to whoever did that!) And I realized there was a CONTRIBUTING.md that nicely explained how to do syntax highlighting. | 12:32 | |
| disbot6 | <antononcube> I think that is old, 2024 image, though. 😱 | 12:33 | |
| <antononcube> @librasteve See here : github.com/antononcube/Raku-Hilite-Simple | 12:34 | ||
|
12:34
arkiuat left
|
|||
| disbot6 | <antononcube> I made that version of "Hilite::Simple" to have different modes ("dark-mode", "solarized-light", etc.) I was thinking to do PR, but now I consider making a version in which the mode-colors are in a JSON resource file. | 12:36 | |
| <antononcube> This might not be "simple" anymore, though. (Say, according to you, who named the package.) I still think is it "simple." | 12:38 | ||
| lizmat | reminds me of the oldest settlement in our municipality: "Nieuwstadt" (translates to "new city" | 12:46 | |
| ) not entirely appropriate anymore :-) | 12:51 | ||
|
12:52
arkiuat joined
12:56
arkiuat left
|
|||
| disbot6 | <antononcube> Right! | 12:58 | |
|
13:17
ShimmerFairy left
13:20
arkiuat joined,
ShimmerFairy joined
13:46
melezhik joined
13:48
arkiuat left
|
|||
| disbot6 | <librasteve> @antononcube - you have anticipated some of the Hilite::Simple features that I would have added in - please can you add you improvements as a PR and then we can avoid Balkanizing the module repo? I think that external specify a colour map and a handful of variants would be nice. Note that the default colours (same as raku,org) are selected to be good in both dark mode and light mode. | 13:55 | |
|
14:09
arkiuat joined
|
|||
| disbot6 | <antononcube> I made the PR. The enhancements I made a most research for my 4th Raku advent article. (I.e. it is fine to reject the PR.) See the screenshot with the new functionalities: | 14:10 | |
| <antononcube> cdn.discordapp.com/attachments/633...432b6& | |||
| <antononcube> Unfortunately, GitHub does not render HTML in the READMEs... | 14:11 | ||
| <librasteve> =b | 14:13 | ||
| arkiuat | I've been poking around on raku.land, but need to ask: are there any published modules for handling significant figures? that is, eliminating false precision before results of calculations are even printed | 15:10 | |
| this would need to be I/O oriented: preserving information about precision of input data, and then applying that appropriately only on output. If there are cases where precision needs to be limited in the middle of a computation, that should probably he handled as a different case | 15:12 | ||
|
15:27
itaipu left
15:42
swaggboi joined
|
|||
| disbot6 | <antononcube> This would be nice to have. Raku has machine precision and infinite precision arithmetics, but nothing in between. | 16:08 | |
| arkiuat | well, if I can't find one, that might end up being my first addition to the ecosystem. Suggestions for naming it? | 16:18 | |
| disbot6 | <antononcube> 1. NumericPrecision(s) 2. Math::NumericPrecision 3. Math::N 4. N | 16:24 | |
| <antononcube> I think the 2nd one is best. | 16:27 | ||
|
16:33
kylese left,
kylese joined
|
|||
| arkiuat | thanks, antononcube! I like Math::NumericPrecision | 16:43 | |
|
16:43
melezhik_ joined
|
|||
| arkiuat | I'm thinking it's going to have to be a class that does Real role and overloads arithmetic operators and .round | 16:43 | |
| precision read in by .new and precision controls output of .gist and the like, and tracked in between | 16:45 | ||
|
16:47
melezhik_ left
|
|||
| korvo | arkiuat: "Sigfig" would not be awful, although maybe that's too playful. It's not informal; working scientists do say "sigfig" as an abbreviation. | 16:47 | |
| disbot6 | <antononcube> Having a function / sub numeric-precision($number, $prec) is must. Some, relevant synonyms can be made. Please, avoid quirky names. (That is Perl's land.) | 16:49 | |
| arkiuat | korvo: SigFig was what I had in mind at first, it's true | 16:58 | |
| antononcube: wouldn't that be a getter/setter method? As a setter, of course, it could only decrease precision, not arbitrarily increase it | 16:59 | ||
| perhaps Math::SigFig | |||
| or is that an example of what you meant by "quirky names" | 17:04 | ||
| disbot6 | <antononcube> Yes, it is an example of a quirky name. | 17:07 | |
| <antononcube> @arkiuat Sure, you can have a setter-getter named numeric-precision, but ultimately a sub is needed. | 17:09 | ||
| <antononcube> With suitable reasonable shorter synonyms. Say, nprec or just np. | 17:11 | ||
| arkiuat | right, sub forms of frequently used methods, as is the case for most classes that do role Real | 17:13 | |
|
17:14
stanrifkin joined
|
|||
| disbot6 | <antononcube> For example: use Math::NumericalPrecision :ALL; say <2113/39939> ==> numerical-precision(:20prec); say <2113/39939> ==> nprec(:20precision); say <2113/39939> ==> np(:20p); | 17:14 | |
| arkiuat | oh, huh, I hadn't even been thinking of overloading <> allomorph constructors | ||
| disbot6 | <antononcube> No, these Rats (in my example at least.) | 17:15 | |
| arkiuat | yes, I mentally misparsed. I'm getting it now | ||
| disbot6 | <antononcube> Meaning, <2113/39939> should be the same as Rat.new(2113, 39939). | 17:16 | |
| <antononcube> I am tempted to suggest to use just n, but that is too short. | |||
| arkiuat | right, a sub that takes a Real and a named-parameter :precision (with abbreviated aliases) and returns a Math::NumericPrecision object | ||
| which would probably also be a multi method of the constructor, or the core of it (or vice versa) | 17:17 | ||
| disbot6 | <antononcube> The problem with the examples I put is that named argument(s) "precision", "prec", and "p" ars in tautology in with the sub names. | ||
| arkiuat | For input, I was thinking more of the case where a string fed to a constructor could unambiguously encode its own precision implicitly by the usual sigfig rules, along with some extras to help with special cases such as say, 500, but with exactly two significant digits | 17:18 | |
| maybe a repurposing of scientific notation (just when fed to constructors of this type), which Raku usually uses for Num, but which we'd use to unambiguously indicate input precision for Int, Rat, and Num types | 17:20 | ||
| disbot6 | <antononcube> I assume that someone can suggest and implement, something like <2113/39939>.Num(20). | ||
| <antononcube> This might be ver self-explanatory -- coercing Numeric object into Num object using precision 20. | 17:21 | ||
| <antononcube> Yeah, I have worked with such notation in Wolfram Language / Mathematica. | 17:22 | ||
| <antononcube> E.g. : wl N[\[Pi], 20] // InputForm (* 3.1415926535897932384626433832795028842`20. *) | 17:23 | ||
| arkiuat | there would also need to be some way to flag a value as being exact (treated as infinite precision, so it doesn't drag other operands down if it just happens to be a single digit) | 17:26 | |
| korvo | antononcube: It might be worth double-checking what arkiuat is hoping for at a high level. For example, with GNU bc, if I ask for `2.4 * 5.3`, I get `12.7`. If I ask for `2.42 * 5.31`, I get `12.85`. In between, if I ask for `2.42 * 5.3`, I get `12.82`. What arkiuat wants is a way to configure that last one to be `12.8` instead. | ||
| arkiuat | I should definitely look into how Wolfram/Mathematica handles this stuff: I haven't worked with that before | 17:27 | |
| korvo, yes, exactly! (Although to be specific, what I'll personally be using this for once implemented is implementing the astronomical algorithms of Meeus 1991) | |||
| not everywhere, of course, but where its use is appropriate | 17:28 | ||
| korvo | arkiuat: I figured it was either hard-science sigfigs or money handling; those are the only two domains where this comes up. Numerical methods usually care about doing all of the intermediate work with high precision and then rounding at the end; the question is how the rounding is allowed to depend on the inputs, because we have to assume that the inputs were rounded/fuzzy too. | ||
| FWIW the best way to deal with this is with interval arithmetic, but that's not a Kahan-mindless approach; you can't have the computer automatically do it by applying a library. Kahan has quite the rant on this topic if you're interested in the numerical-methods portion of this: people.eecs.berkeley.edu/~wkahan/Mindless.pdf | 17:30 | ||
| disbot6 | <antononcube> @arkiuat Well, it can be just an Int, Ratfor infinite precision. I understand that you are suggesting another Numeric type with precision. | 17:32 | |
| <antononcube> Hmm... Let me see the inheritance chart. I might be wrong about which is sub-type of which. | 17:33 | ||
| arkiuat | infinite precision is useless if you're working with empirical measurements that are necessarily of finite precision. What I'm specifically trying to do is prevent the accidental use of noise as false precision, which is what korvo was pointing out. | 17:34 | |
| disbot6 | <antononcube> You can have a max-extra-precision constant when computing the expressions. | 17:35 | |
| arkiuat | I'm taking a look at Kahan's rant | ||
| Interval arithmetic is probably overkill for the applications I have in mind, though, and a full implementation of that approach deserves its own module | 17:36 | ||
| disbot6 | <antononcube> @arkiuat So looking at this chart: docs.raku.org/assets/typegraphs/Numeric.svg it seems that you want to design a PrecisionNumeric class that is between Numeric and Real and Complex. | 17:37 | |
| korvo | Oh, you're *implementing* implementing. Then you should know about tools like Herbie (herbie.uwplse.org/) which can quickly search for improvements to your handwritten methods. This was a lifesaver when implementing statistical methods a few years ago. | ||
| arkiuat | antononcube, I thought I was just implementing something that did the Real role, like Num and Rat and Int all do | 17:39 | |
| disbot6 | <antononcube> By all means, but you are also making such a class too, in effect. | ||
| <antononcube> Can Raku complex numbers use the role you have in mind? | 17:40 | ||
| arkiuat | if I wanted that, I'd just objects of the thing that I'm working on as the real and imaginary parts of a ComplexSigFig thingy built on top of this | 17:41 | |
| I wouldn't try to do it all in one layer | |||
|
17:41
melezhik_ joined
|
|||
| arkiuat | s/just objects/just use objects/ | 17:42 | |
|
17:45
melezhik_ left
|
|||
| disbot6 | <antononcube> I am not sure why not. You suggested it already -- you have a class that provides precision representation; that class is obtained by a role. | 17:46 | |
| <antononcube> I assume the role you have in mind extend Numeric. I.e. the but syntax can be used to construct the corresponding preicision objects. | 17:48 | ||
| arkiuat | why not? mainly because it's outside the scope of the application I have in mind, and someone else (or me) can extend the scope to that later. Scope creep is the death of volunteer projects. | 17:49 | |
| If it were Rust (and if Rust used things like Int, Rat, and Num) I'd make an enum (what Rust calls a union) of those three as the data basis. | |||
| disbot6 | <antononcube> E.g. my $a = <10/1002212> but NumericPrecision; say $a.prec(20) | ||
| arkiuat | Extending Numeric is more general than I had in mind. And really, it seems to me that trying to do this for complex numbers *would* require nothing less than the full interval-arithmetic approach | 17:50 | |
| disbot6 | <antononcube> @arkiuat Ok. The example code above (using but) is what I thought you have in mind. | 17:52 | |
| arkiuat | Not really. What I had in mind was just reading in numbers from data files (such as ephemerides) and correctly tracking their precision while computing with them, and not introducing noise into the output disguised as false precision. | 17:53 | |
| disbot6 | <antononcube> Hm... do you plan to do that via objects? If yes -- judging from what you said earlier -- then you do some sort of special representation of Numeric. | 17:57 | |
| <antononcube> Ah, there is precedent for the name "Math::N" (just published at raku.land) : raku.land/zef:martimm/Gnome::N | 18:01 | ||
| arkiuat | a more pressing concern is that I need to be able to extend whatever-it-is to correctly track precision of values that are input as babylonian formats such as HH:MM:SS or ° ′ ″ which are used interchangeably on the same kinds of data in my initial target application domain | 18:07 | |
