Yes, agree.
Some services (e.g. komoot) apparently have good data, or can work around it.
Others are struggling with lack of precision in the DEM data.
As much as I like the tweakability of BRouter, the tracks generated never give realistic elevation info.
Garmin and Strava must be sitting on a gold mine of practical DEM data based on ride and hike records. They have huge databases from mobile devices recording GPS position, speed, and pressure.
Yet it's unclear to what extent they actually use them - on freeway adjacent bike paths that have different gradients than the adjacent freeway (typically steeper), it's very clear Garmin is using data referencing the freeway.
They must be doing something that integrates user-contributed data because one quirk of their course planner[1] is an out-and-back plan along the same course will have non-coincident elevation profiles, even along trails where it can't be explained by switching sides of the road.
1: And their planner, in general, is garbage. I usually take the output file and run it through an AI system to fix it so it doesn't try to cue me to pointlessly switch to the other side of a major road and ride on the sidewalk.
If they’re sourcing some of their information from GPS data, the vertical precision for elevation is pretty poor, even if you’re using professional equipment. I’ve been being off a foot or tube is perfectly normal. You really need to use survey monumentation as controls. Also many states known invest in a statewide light R elevation program. It’s really too bad because they are so useful for planning and design.
Yeah, it's understandable that the real world is messy and user-sourced data can be very suspect.
The case I'm thinking of is the eastern end of SR-520 over Lake Washington in the Seattle area. It has hundreds/low thousands of bicycle crossings/day (so surely dozens of Garmin users/day), the background is a dammed freshwater lake with a well known elevation, and clear view of the sky. Yet the elevation data is garbage somehow.
It doesn't really matter for planning purposes as any alternative has such a huge delta but it does signal that user data isn't being utilized to refine their data set even on high volume segments.
Websites built with tons of polyfills are likely not run on these devices anyway, since they will run out of RAM before, let alone after they will only load after sone minutes because of CPU limitations on top of not being loaded because their x509 certs are outdated as well as the bandwith they support is not suitable to load MB sited pages
Actually the author is building onto my suggestion https://github.com/soasis/idk/pull/17/files which I created several years ago, but adapted a bit too fast while submitting. And yes it looks very similar to GNU nested functions, since I started tinkering with these first.
I am really not sure if all these observations mentioned in the article are 100% correct, though.
First : Code seems to be compiled with clang. On Linux with gcc the native function one is way faster than the clang one.
Second: The author does run the code on ARM64/MacOS .
At least on my ryzen CPU on Linux with gcc the "normal C code" is way faster than anything else. Not that we do not need to thing about "closure" type functionality, but one should be careful to extrapolate implementations from one compiler on one platform to the rest of the pack.
Regarding N3654 I am not sure how to benchmark it here, since C could potentially use __builtin_call_with_static_chain , but I am not sure how to write the function to use the chain for accessing the variables.
I tried to estimate N3654 it by using "tinygo" which is AFAIK using the usual Calling ABI, but it was a factor of two slower than clang. Even "go" with its very specific ABI is still much slower. I discovered this isn't representative since runtime calling costs had been totally shadowed by costs of allocations.
See my other comment in this thread with my preliminary benchmarking results. I have a patched GCC with two new builtins __builtin_static_chain and __builtin_nested_code (needs a better name), that give you the static chain pointer and the code pointer without creating a trampoline. Then I put both into a structure to simulate a wide pointer. Later I call it with __builtin_call_with_static_chain.
A trick one can do is to let it create the trampoline and then read off the two pointer from the position in the code where it is stored. Not portable and you still have the overhead for creating the trampoline, but you do not need the executable stack anymore.
I had the chance to test Moment while my Widex Evoke 440 had been in repair. They are indeed a lot better as the Evoke, sounding wise, while having only mild hearing loss. But they are still only MFI (can only connect to an iphone) and since I am migrating away from Apples ecosystem this will be a blocker.
On Android you can both install and run apps over adb. The linked article explains:
> Participating in developer verification will not affect your experience in Android Studio, the official IDE for Android app development. You will continue to be able to build and run an app even if your identity is not verified. Android Studio is unaffected because deployments performed with adb, which Android Studio uses behind the scenes to push builds to devices, is unaffected. You can continue to develop, debug, and test your app locally by deploying to both emulators and physical devices, just as you do now.
Any known CPU usage bugs have been resolved. Last time it was the cursor animation but we fixed that too. I can now compare our apps to OS provided native equivalents (we're not there yet but it is getting close!)
I know about systems who had two types of serial numbers which ought to be the same, but weren‘t because they had been programmed at different eol stages, when daylight savings time kicked in. One of the system run in utc the other in local time. Date was part of the serial.
Noob me would have guessed the "source of truth" would be whatever identifier(s) is recorded by the insurance company. Or maybe the service and maintenance agreements.
Failing that, I would have guessed some kind of (natural) compound key derived from the transfer(s) of ownership (Airplane Purchase Agreement? Bill of Sale?) noting the unique major components like airframe, interior, and engines? And maybe wings?
reply