I wish vector-argmin was named vector-min and would take a #:key [key values] argument like sort, and that a new vector-argmin actually returned the index of the minimum element (also with a #:key argument). :slightly_smiling_face:

I know it’s only a dream since that would be backward-incompatible, so it’s not going to happen before Rhombus, if ever

Instead, I guess I’ll go with vector-min-index

Seems like adding vector-min with that interface would be pretty easy

Would it be worth writing a pull request for vector-min and vector-min-index?

Refinement: like sort, take a comparator <? and a #:key [key values], and rename to vector-best and vector-best-index maybe

Seems like a good idea to me

@spdegabrielle im just playing with that rantstack thing … on glitch the auto-restart server stuff is pretty neat. Have you found a way of doing that locally? in hipster js land i think they call it “hot reloading”

I’ve not tried it locally but you have piqued my interest!

i dont think its anything im qualified to try and figure out how to do myself in racket, but erlang has been doing it for years i think

http://reactnative.dev/blog/2016/03/24/introducing-hot-reloading.html

I think this is how the DrRacket quickscripts functionality works

https://github.com/Metaxal/quickscript/tree/master\|https://github.com/Metaxal/quickscript/tree/master I

I think it uses units https://docs.racket-lang.org/guide/units.html\|https://docs.racket-lang.org/guide/units.html but I’ll admit I’m out of my depth here

I think Tony has some kind of “hot reload” package?

https://github.com/tonyg/racket-reloadable

I’d take a look at the code in Quickscript - and try it out in DrRacket yo see what the hot reloading is like

> but I’ll admit I’m out of my depth here yup me deffoo !!! i was hoping it had been done already, when ive got some more experience ill come back to it, in the meantime there are fs watchers etc :wink:

thanks though, i appreciate the consideration given :slightly_smiling_face:

You can set something up for yourself by using dynamic-rerequire but there are a few drawbacks. racket-reloadable, mentioned below uses dynamic-reqreuire under the hood but the same drawbacks apply there. koyo apps just watch the filesystem and restart the whole server on change.

https://github.com/Bogdanp/koyo/blob/763da867b5de2c6b64062045c7572a2dbe51c26f/koyo-lib/koyo/runner.rkt#L106-L113

Does racket provide access to the MPFR flags?

Could really use the “inexact” flag

What is the effect of that flag?

It is set whenever MPFR (math/bigfloat) does an operation which causes rounding

I have some need right now to know when rounding occurs, currently doing it by repeating every operation twice with different rounding modes; that’s not ideal

The MPFR binding from the math library doesn’t currently set or expose that flag, but you can call into MPFR directly, and that would affect math operations.

Is `bf-rounding-modeˋ not enough?

In case it’s useful: #lang racket/base (require ffi/unsafe math/private/bigfloat/mpfr) (define mpfr_set_inexflag (get-mpfr-fun 'mpfr_set_inexflag (_fun -> _void))) (mpfr_set_inexflag)

@popa.bogdanp super tiny/nitpicky question: Might it be better to rename the loggers with e.g. a koyo- prefix? https://github.com/Bogdanp/koyo/blob/763da867b5de2c6b64062045c7572a2dbe51c26f/koyo-lib/koyo/runner.rkt#L14-L15

I don’t think there’s any “official guidance” about this, but, since AFAIK all logger names are in one big “namespace”, two libraries could pick the same name.

@greg I’ve been asking myself the same question in every Racket project I’ve defined a logger in. So far the prefix-less versions haven’t been a problem, although I realise they can be. The one thing holding me back are the excessively long function names you get if you add a prefix

It’s probably not a big deal except in a bigger Racket ecosystem, even with names like “runner” or “watcher”.

log-koyo-runner-info is a mouthful :confused:

Yes, that situation reminds me of coding in Emacs Lisp. Basically same problem. :smile:

It’s “worse” for logging because that’s already a cross-cutting concern littering your code, and you don’t want the names to be longer. Yep.

Never mind. We all have bigger things to focus on.

Maybe someday I’ll doink around with a define-logger variant that adds a few things. Like auto-provide-ing the log-xxx-yyy definitions. Maybe something for this, e.g. a prefix that’s added for the actual logger name but some shorter name to use when logging. ¯_(ツ)_/¯

That’s what I was thinking

OTOH I just typed /shrunk instead of /shrug so maybe I won’t attempt that today. :eyes:

It might be nice to have a variant of define-logger that is able to “namespace” the loggers, but define shorthand logging functions

(define-namespaced-logger koyo runner)

=>

(define-logger koyo-runner) (define log-runner-info log-koyo-runner-info) ...

Yes.

Also I sometimes find it handy to racket/trace => a logger. If there were some with-trace syntax for locals, it could maybe help with the cross-cutting concern “littering”. Haven’t really thought it all out.

@pavpanchekha also, I think you’re the most significant user of that code, so any improvements you want to make are basically pre-approved

Thanks!

Good to know :)

It works great. Not sure about a general-purpose flags module to add to the MPFR library, but I’ll definitely think about

meanwhile, current problem conclusively solved

bf-rounding-mode allows you to change the rounding mode, but it doesn’t tell you whether rounding in fact did occur. The inex flag tells you, in effect, whether the rounding mode mattered.