I built one, tracking fleet vehicles with a custom box, using tiled maps, on behalf of Vodafone, back in 2002.
I still remember I wrote a basic trans-mercator library too!
> This is why most online mapping platforms like Google Maps or Apple Maps rely on a variation of the Mercator projection to provide directions. Using the Equal Earth projection for navigation would not be as effective as the Mercator projection.
> What the UN did was endorse the broader message that Equal Earth is a fairer projection that more equitably displays the true size of the Earth’s land
You are right about this though - it's a moral fashion. Who cares about land size on a map unless you've got the priorities and advancement of a prehistoric king? People with plenty of spare time who constantly talk in an echo chamber[0], that's who.
One of the things I discovered a while back is that even fairly crude trig approximations don't put that much error into your position, over a small enough distance.
To calculate things like straight-line range from where you are now to where you need to put a unit for an emergency, you're probably not working over an area of more than a couple of hundred kilometres radius and the error will be within a few dozen metres. And once you get within about half a k, you're driving towards the column of smoke anyway ;-)
The combination of RF electronics and then doing the signal processing in an FPGA for the timing critical stuff and the actual DSP with a raspberry pi, very interesting.
GPS - look into Gold Codes [1] and auto-correlation. GPS arrives on your device at -128dBm, give or take, while thermal noise is -111dBm at the ~2MHz sampling bandwidth used. We use the processing gain from correlating against the ~1Mchip/s gold code to extract the lower bitrate signal, so you're pulling signals from approximately 20dB below the relevant thermal noise floor.
In Y2K I built a Linux on PC104 solution with GPS, bonded dual-channel mobile 9600 baud data links, and a (slow) image feed. It was kind of special to see the data coming over the mobile network in those days: this was before mobile data using basic PSTN modem tech! Very lossy and slow, as the algorithms did not account for mobile voice compression.
Quantization compresses the model’s parameters and you lose precision in the process. My understanding from the article was that precision wasn't lost - 'It actually had higher resolution than Extended-precision floating point math!'. The point of quantization is to make the model smaller to fit into available ram. I think the OP is referring to computation which is a different beast.
You may be conflating distillation, which may be a fault of other people getting it wrong. Going from floating to fixed point doesn't change precision or size. It changes representation. For example, if all your values are between 0 and 1 or -1 and 1, you're not using the entire range of a standard IEEE float. If you instead use Q31 format, you get basically 31 instead of 23 bits of mantissa. So it's an increase in precision if and only if you can basically stretch your sub-range that you were using over a larger range of bit representations. You have to think of the total number of values. 32 bit is 4 billion. 80 bit extended precision is a lot more than that. But he didn't say I think what his fixed point bit width was. That's what matters.
Now maybe you don't need to represent 1/2^32 in precision. Maybe you just need to know to 1/8th. That's where you can quantize to a lower precision to save space.
But if you start with 32 bit float and quantize to 32 bit fixed, I struggle to think how that saves storage.
I wasn't conflating distillation. You are basically repeating what I said - you're describing quantization. The OP was talking about changing the computation. The article says the 8- and 16-bit integer approach actually had higher resolution than the floating-point approach. You said we already had quantization to do this but quantization isn't what the OP was describing.
A bit related - I tried if I can push Fable to write a Garmin map renderer that would be comparably fast (or faster) on Fenix 8 than the one they claim is possible on Fenix 9 only. I think I got very close, rendering detailed topographical vector map at over 15 fps on QEMU simulated single core simple CPU comparable to actual Fenix 8.
I built one, tracking fleet vehicles with a custom box, using tiled maps, on behalf of Vodafone, back in 2002. I still remember I wrote a basic trans-mercator library too!
Of course Mercator projection may go out of fashion soon https://www.independent.co.uk/news/world/africa/world-map-eq... :)
Hope I'm called back to update the library ;)
Probably not if navigation is involved:
> This is why most online mapping platforms like Google Maps or Apple Maps rely on a variation of the Mercator projection to provide directions. Using the Equal Earth projection for navigation would not be as effective as the Mercator projection.
> What the UN did was endorse the broader message that Equal Earth is a fairer projection that more equitably displays the true size of the Earth’s land
You are right about this though - it's a moral fashion. Who cares about land size on a map unless you've got the priorities and advancement of a prehistoric king? People with plenty of spare time who constantly talk in an echo chamber[0], that's who.
[0] https://un.org/en
I believe the library mentioned in the article should be this one https://geodyssey.github.io/overview/overview.html and here https://www.lukatela.com/geodyssey/
One of the things I discovered a while back is that even fairly crude trig approximations don't put that much error into your position, over a small enough distance.
To calculate things like straight-line range from where you are now to where you need to put a unit for an emergency, you're probably not working over an area of more than a couple of hundred kilometres radius and the error will be within a few dozen metres. And once you get within about half a k, you're driving towards the column of smoke anyway ;-)
"real-time GPS-driven moving map display"
Not the IMHO more interesting analog tech which lifts signals out of thermal noise.
That looks interesting, what technology "lifts signals out of thermal noise"?
I found this an interesting writeup on the technologies needed to receive GPS signals:
http://www.aholme.co.uk/GPS/Main.htm
The combination of RF electronics and then doing the signal processing in an FPGA for the timing critical stuff and the actual DSP with a raspberry pi, very interesting.
Thank you @squantor
DSSS, direct sequence spread spectrum, used for encoding GPS signal
Spread spectrum, it's pretty magical.
Thanks @FrankPetrilli.
GPS - look into Gold Codes [1] and auto-correlation. GPS arrives on your device at -128dBm, give or take, while thermal noise is -111dBm at the ~2MHz sampling bandwidth used. We use the processing gain from correlating against the ~1Mchip/s gold code to extract the lower bitrate signal, so you're pulling signals from approximately 20dB below the relevant thermal noise floor.
[1] https://en.wikipedia.org/wiki/Gold_code
I once worked on a handheld garmin gps that used a 386 ... not sure if it ever became a product, though. It definitely had moving map... 1MB of it.
IIRC, the Garmin eMap had a 386: https://www.gpsrchive.com/eMap/eMap.html.
I think it was one of their first models that had a map, earlier ones would just display coordinates/tracks/waypoints.
Edit: here's a teardown of an older model where you can see the CPU: https://www.eevblog.com/forum/repair/garmin-gps-12map/, and the wiki for the CPU has a clearer picture: https://en.wikipedia.org/wiki/Intel_80386EX
In Y2K I built a Linux on PC104 solution with GPS, bonded dual-channel mobile 9600 baud data links, and a (slow) image feed. It was kind of special to see the data coming over the mobile network in those days: this was before mobile data using basic PSTN modem tech! Very lossy and slow, as the algorithms did not account for mobile voice compression.
Oh how I have fond memories of Dr.Dobb's journal.
The author says:
"It used Voronoi Cells and reduced most math to 8- and 16-bit integer calculations with one or two single-precision floating-point calculations."
I wonder if it can be used to speed up LLM inference.
That's what quantization and stuff is, basically. So yes. Been done for years on all neural net types not just LLMs.
Quantization compresses the model’s parameters and you lose precision in the process. My understanding from the article was that precision wasn't lost - 'It actually had higher resolution than Extended-precision floating point math!'. The point of quantization is to make the model smaller to fit into available ram. I think the OP is referring to computation which is a different beast.
You may be conflating distillation, which may be a fault of other people getting it wrong. Going from floating to fixed point doesn't change precision or size. It changes representation. For example, if all your values are between 0 and 1 or -1 and 1, you're not using the entire range of a standard IEEE float. If you instead use Q31 format, you get basically 31 instead of 23 bits of mantissa. So it's an increase in precision if and only if you can basically stretch your sub-range that you were using over a larger range of bit representations. You have to think of the total number of values. 32 bit is 4 billion. 80 bit extended precision is a lot more than that. But he didn't say I think what his fixed point bit width was. That's what matters.
Now maybe you don't need to represent 1/2^32 in precision. Maybe you just need to know to 1/8th. That's where you can quantize to a lower precision to save space.
But if you start with 32 bit float and quantize to 32 bit fixed, I struggle to think how that saves storage.
I wasn't conflating distillation. You are basically repeating what I said - you're describing quantization. The OP was talking about changing the computation. The article says the 8- and 16-bit integer approach actually had higher resolution than the floating-point approach. You said we already had quantization to do this but quantization isn't what the OP was describing.
Please can you provide some links to intro level articles?
This seems worth the read but I didn't dig too deep https://medium.com/@sergiopr89/float-point-quantization-the-...
[dead]
[flagged]
A bit related - I tried if I can push Fable to write a Garmin map renderer that would be comparably fast (or faster) on Fenix 8 than the one they claim is possible on Fenix 9 only. I think I got very close, rendering detailed topographical vector map at over 15 fps on QEMU simulated single core simple CPU comparable to actual Fenix 8.
https://www.reddit.com/r/Garmin/comments/1vzaz4w/we_live_in_...