From Newsgroup: alt.windows7.general

Hello all,

I have a world map using the Mercator projection, and would like to plot
some stuff on it using Latitude and Longitude.

The problem is that I can't seem to get the formule I found to spit out the correct value for Y.

-- The map :

https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Mercator_projection_Square.JPG/250px-Mercator_projection_Square.JPG

-- The formula :

Y = ln( tan(latitude) + sec(latitude) )

where "ln(...)" is log(...) / log(10)

... at least, that is what I could google about it.

where "sec(...)" is 1/cos(...)

-- The test data :

New York : Latitude = 39 (Longitude = -77)

-- Applying the formula and checking the partial results :

RadLat = DegToRad(39) -> 0.680952380952381

Temp = tan(RadLat) + 1/cos(RadLat) -> 2.09728292053088

log(Temp)/log(10) -> 0.321657020135087

Multiplying half the maps height by the above tells me that New York is
located somewhere in Canada. :-(

Can anyone tell me what goes wrong here ?

Regards,
Rudy Wieser



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/14 8:24:17, R.Wieser wrote:

Hello all,

I have a world map using the Mercator projection, and would like to plot some stuff on it using Latitude and Longitude.

The problem is that I can't seem to get the formule I found to spit out the correct value for Y.

-- The map :

https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Mercator_projection_Square.JPG/250px-Mercator_projection_Square.JPG

-- The formula :

Y = ln( tan(latitude) + sec(latitude) )

where "ln(...)" is log(...) / log(10)

... at least, that is what I could google about it.

Rather than Googling the formula, my first thought was to go back to
first principles: as the name implies, a map projection can be thought
of as being created by shining a light through the earth (globe) onto a
sheet of paper - either flat and fixed to the globe at one point, or -
more commonly - a cylinder wrapped round the globe, touching at one
circle (often the equator), and then unrolled. Once this is realised,
basic geometry should make calculation of the co-ordinates fairly simple.Unfortunately, to do this, one needs to know where the nominal light
source is. And - despite it being a _long_ article - I can't find a
statement of this in the Wikipedia article about the Mercator projection
- other that that - I _think_ - it _isn't_ the centre of the earth
(so-called "radial"), though is often thought to be (certainly Google's
AI thinks it is).
If anyone _can_ find out where the light source point is for the
Mercator projection, I'd love to know! (And it would answer Rudy's
question.)
(One other position for the light source I remember from last time I
looked into this - which was probably over 40 years ago! - is on the
opposite surface of the globe to the projection point (i. e. sort of
tracking round opposite the map "printing"); I don't think it's that,
though, as that would show the poles, though still distorted.
If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude (scaled appropriately for the map size).
Even if it isn't, this _may_ be close enough - try a few places.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

J.P. ,

First off, FYI, Paul has minimized his posting about the subject to the
Win10 group only. If you're not there already it might be a good idea to
take a peek.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude

Somewhere along the road I had a similar thought. But why than do all the formules I now have (four at the moment) all do a tan() and than wrap that
up in a log() ? There must be something to it.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/15 20:0:31, R.Wieser wrote:

J.P. ,

[John by the way :-) ]

First off, FYI, Paul has minimized his posting about the subject to the Win10 group only. If you're not there already it might be a good idea to take a peek.

I replied to the posting I did, thinking I was the only respondent -
probably in the W7 'group; I saw the other responses when I moved to one
of the other 'groups, but too late then to amend my post.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude

Somewhere along the road I had a similar thought. But why than do all the formules I now have (four at the moment) all do a tan() and than wrap that up in a log() ? There must be something to it.

[]

Indeed! But I can't think what.

Did you _try_ using just the tangent on a couple of places? Or perhaps
just a couple of latitudes, to see if the lines come out where they are
on the plot? You'd probably have to do that in the first place anyway,
to see what the vertical scale _is_; if doing that for say the ten and
forty degree lines (assuming that's what the ones on the plot are) gives different scales, then you'd know it isn't just that.
--
J. P. Gilliver
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

J.P. ,

[John by the way :-) ]

John,

I replied to the posting I did, thinking I was the only respondent -
probably in the W7 'group; I saw the other responses when I moved
to one of the other 'groups, but too late then to amend my post.

There was nothing wrong with your post or suggestion, I just thought that
you being able to see what others wrote would be beneficial to us both.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude

But why than do all the formules I now have (four at the moment)
all do a tan() and than wrap that up in a log() ? There must be
something to it.

...

Indeed! But I can't think what.

Same here. But I'm no math wizz.

Did you _try_ using just the tangent on a couple of places? Or perhaps
just a couple of latitudes, to see if the lines come out where they are
on the plot?

:-) I did so before posting to you and got a rather promising result - on
the image I provided a link to. But I have no idea if it will also work
well on an image multiple times as big (where differences will be more prominent).

iow, I'm only eyeballing the results, and have nothing to numerically
compare them with. :-|

You'd probably have to do that in the first place anyway,
to see what the vertical scale _is_; if doing that for say the ten and
forty degree lines (assuming that's what the ones on the plot are) gives different scales, then you'd know it isn't just that.

Yep, thats what I've been doing.

By the way, the lines on the image are 15 degrees apart horizontally, and
from it I assume vertically as well. This means that the highest visible
line is at 75 degrees latitude.

Ah, I just went back to the wikipedia page* and noticed that the "web Mercator" projection mentions "and clips latitudes to ~85.05# for square presentation". I'm now assuming thats about the image itself. Another assumption is that its also true for the "Mercator = Wright" projection.

* https://en.wikipedia.org/wiki/List_of_map_projections

I have to do some more experiments. Though I'm a bit afraid that a tan()-only solution will only be good enough for smaller images, where the differences (compared to the actual formule) are barely noticable. Not
really what I'm after, but will probably use it as long as I can't get the official formule(s) to work.

.... But it *does* bother me that I can't get those official ones to work.
:-(

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Thu, 1/15/2026 12:25 PM, J. P. Gilliver wrote:

On 2026/1/14 8:24:17, R.Wieser wrote:

Hello all,

I have a world map using the Mercator projection, and would like to plot
some stuff on it using Latitude and Longitude.

The problem is that I can't seem to get the formule I found to spit out the >> correct value for Y.

-- The map :

https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Mercator_projection_Square.JPG/250px-Mercator_projection_Square.JPG

-- The formula :

Y = ln( tan(latitude) + sec(latitude) )

where "ln(...)" is log(...) / log(10)

... at least, that is what I could google about it.

Rather than Googling the formula, my first thought was to go back to
first principles: as the name implies, a map projection can be thought
of as being created by shining a light through the earth (globe) onto a
sheet of paper - either flat and fixed to the globe at one point, or -
more commonly - a cylinder wrapped round the globe, touching at one
circle (often the equator), and then unrolled. Once this is realised,
basic geometry should make calculation of the co-ordinates fairly simple.

Unfortunately, to do this, one needs to know where the nominal light
source is. And - despite it being a _long_ article - I can't find a
statement of this in the Wikipedia article about the Mercator projection
- other that that - I _think_ - it _isn't_ the centre of the earth
(so-called "radial"), though is often thought to be (certainly Google's
AI thinks it is).

If anyone _can_ find out where the light source point is for the
Mercator projection, I'd love to know! (And it would answer Rudy's
question.)

(One other position for the light source I remember from last time I
looked into this - which was probably over 40 years ago! - is on the
opposite surface of the globe to the projection point (i. e. sort of
tracking round opposite the map "printing"); I don't think it's that,
though, as that would show the poles, though still distorted.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude (scaled appropriately for the map size).
Even if it isn't, this _may_ be close enough - try a few places.

https://en.wikipedia.org/wiki/Mercator_projection

[Picture] Use Download Original for best result (CoPilot output)

https://i.postimg.cc/SQLZbfvY/mercator-equation.gif

The NASA Panoply program (written in Java and requiring a Java11 JRE),
offers a menu with at least 100 different projections, and Mercator
has two (not that it matters).

I don't think there is anything mysterious about this.

And actually harnessing Panoply to do something useful,
that's almost impossible. An alternative is something called
GGPlot.

I did a PostScript print of the NASA overlap map.

No matter what you set the paper to, the coordinates of the unit
square were only 406x406 pixels (which means the picture itself sucks).

406x406 square subtract 1482 on X, 989.5 on Y

But the beauty of the PostScript, is you find this inside.
This would be drawing a piece of coastline with line segments.
PostScript supports transform matricies, so they can do anything
they want with the item once selecting a coordinate system.

1553.23376 1231.24414 moveto
1553.21582 1231.28955 lineto
1553.17749 1231.35498 lineto
1553.15955 1231.4231 lineto
1553.12134 1231.44446 lineto
1553.14038 1231.46716 lineto

I scaled that, extracted the points, didn't plot lines, just dots,
and made a pbm file (netpbm black and white). The purpose of not plotting lines, was to get less visual clutter. My picture sucks when viewing
the whole thing (it isn't dark enough). But when you zoom into pieces
of the picture, it looks dark enough then to use.

Your coordinates for NYC, where did you get those coords ???
There is an article in Wikipedia I used, complete with a tiny
map widget when you click an icon near the coord info.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

X=0.294427 Y=0.375981 merc.exe (the CoPilot program)

That means, on my 10000x10000 pixel map, I plot a dot at (2944,3760).

Now, some weirdness to throw in. GIMP measures from lower left corner.
I think the equation measures from upper left corner. Yet, when I
plotted my PBM, it was upside-down as viewed on the screen, and I
had to do a Flip-Vertical so the map read correctly. So when GIMP reads (2944,3760) off the mouse cursor as I move around, that's kinda measuring
from the upper left corner. Otherwise, I would have needed to do 10000-3760
or so. Which turned out not to be necessary.

The PBM file looks nicer when zoomed in, and that's what you're looking
at here, is just a portion of my Mercator.

[Picture] Use Download Original when buried in adverts

https://i.postimg.cc/P5vhvS3w/NYC-coord3.gif

There is still some error there. Even if I made an allowance for
a one pixel error in plotting the picture, I don't think that covers
it and I might be off two or three pixels left-right.

I think the equation is pretty close. But I'm not happy that
there is an error still there.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/16 10:8:22, Paul wrote:
[]

Your coordinates for NYC, where did you get those coords ???
There is an article in Wikipedia I used, complete with a tiny
map widget when you click an icon near the coord info.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

You used a website to work out 40 + 42/60 + 46/3600? :-)
[]

I think the equation is pretty close. But I'm not happy that
there is an error still there.

Paul

Yes, this has been a puzzle, for what seems like a simple question!
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Fri, 1/16/2026 4:59 PM, J. P. Gilliver wrote:

On 2026/1/16 10:8:22, Paul wrote:

[]

Your coordinates for NYC, where did you get those coords ???
There is an article in Wikipedia I used, complete with a tiny
map widget when you click an icon near the coord info.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

You used a website to work out 40 + 42/60 + 46/3600? :-)
[]

I am a complex person with special needs :-)

Paul

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

John,

Did you _try_ using just the tangent on a couple of places?

...

I have to do some more experiments.

After having done so, it looks like that

tan(DegToRad(Latitude)*0.78)\2.53627

gives a nice result.

Though I used 75 degree latitude as the reference for the "will the
calculated lines overlap the ones on the image?" test, causing all lower calculations to be /just/ under the lines on the image.

Re-doing it using 65 degree latitude as a reference should give a better result (75 degree just above its target, the others just below their target)

As I mentioned before, good enough to get an indication of the location
you're looking for, but it can be hundreds of miles to low (or high) ...

By the way, 0.78 is rather close to Pi/4 . Somehow that raises my suspicion that that is the actual value to be used, and my 0.78 is caused by my "that looks good" eyeballing ...

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul

Your coordinates for NYC, where did you get those coords ???

If you mean 39, -77 its probably from me.

Looking back in my docs I see I have an image of a globus wit the lat/long lines on it, mentioning 39, -77. The only problem is that it mentions Washington DC, and not New York. I've got no idea how I mixed those two up. My apologies.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

X=0.294427 Y=0.375981 merc.exe (the CoPilot program)

Is there any chance you can (re)post the used formule (just to be sure I'm using the correct one) and some intermediate results (especially the ones
fed into the tan() an log() functions) so I can verify what the formule is doing here (and spot my mistake(s)) ?

Regards,
Rudy Wieser



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/17 7:19:55, R.Wieser wrote:

John,

Did you _try_ using just the tangent on a couple of places?

...

I have to do some more experiments.

After having done so, it looks like that

tan(DegToRad(Latitude)*0.78)\2.53627

gives a nice result.

Asssuming DegToRad() just means multiply by pi / 180 ...

[]

By the way, 0.78 is rather close to Pi/4 . Somehow that raises my suspicion that that is the actual value to be used, and my 0.78 is caused by my "that looks good" eyeballing ...

Regards,
Rudy Wieser

... then the above simplifies to tan(Latitude*pi*pi/720)\2.53627, and of
course pi*pi/720 can be given as a constant.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

"Tolerating intolerance is not a virtue." - Barry Shein
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Sat, 1/17/2026 3:11 AM, R.Wieser wrote:

Paul

Your coordinates for NYC, where did you get those coords ???

If you mean 39, -77 its probably from me.

Looking back in my docs I see I have an image of a globus wit the lat/long lines on it, mentioning 39, -77. The only problem is that it mentions Washington DC, and not New York. I've got no idea how I mixed those two up. My apologies.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via
https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

X=0.294427 Y=0.375981 merc.exe (the CoPilot program)

Is there any chance you can (re)post the used formule (just to be sure I'm using the correct one) and some intermediate results (especially the ones
fed into the tan() an log() functions) so I can verify what the formule is doing here (and spot my mistake(s)) ?

Regards,
Rudy Wieser

The CoPilot response shows its equation here. And this is what
it used to write the C code for me.

[Picture] Use Download Original for best result (CoPilot output)

https://i.postimg.cc/SQLZbfvY/mercator-equation.gif

Whereas the Wikipedia reference for the same thing is here.
The USGS equation hides the 2PI part inside its R and it neglects
to include coordinate correction for plotting purposes. The USGS
form of the equation shows the "shape of the transform" and is
not the equation a practitioner needs to implement. The Copilot
equation delivers a unit square, with the center of the
map presumably being 0,0 for lat,long. The unit square itself
has a different origin, like the upper left corner. In any case,
using your calibrated eyeball, you will be able to figure out
what additional math is require to fit your plotting scheme.

https://en.wikipedia.org/wiki/Mercator_projection

Mathematics [half way down the page or so...]

A simple expression for the spherical form of the Mercator projection is:[26]

[26] https://pubs.usgs.gov/pp/1453/report.pdf (PDF page 228, stamped as "page 218")

The USGS document on its page, does not note the
agreed 85.05113 degree cutoff for latitudes (so the "globe"
is not too messy). The cutoff is encoded in the C code that CoPilot gave me.

*************************************************************************** #include <stdio.h>
#include <math.h>

/* gcc -lm -o merc.exe merc.c */

int main(void) {
double lat, lon;
const double PI = 3.14159265358979323846;

while (1) {
printf("\nEnter Latitude in degrees: ");
if (scanf("%lf", &lat) != 1) break;

printf("Enter Longitude in degrees: ");
if (scanf("%lf", &lon) != 1) break;

/* Clamp latitude to Mercator limits (plus/minus 85.05113 degrees) */
if (lat > 85.05113) lat = 85.05113;
if (lat < -85.05113) lat = -85.05113;

/* Convert longitude to X in [0,1] */
double x = (lon + 180.0) / 360.0;

/* Convert latitude to Y in [0,1] using Mercator projection */
/* The C log function is an ln(), the C log10 function is an log() */

double rad = lat * PI / 180.0;
double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

printf("Your screen data point is at X=%f Y=%f\n", x, y);
}

return 0;
}
***************************************************************************

.\merc

Enter Latitude in degrees: 40.71277778
Enter Longitude in degrees: -74.00611111
Your screen data point is at X=0.294427 Y=0.375981

And then I scaled up my graphic to 10000 x 10000
and plotted (2944, 3760). I wrote a piece of code
I call pbmplot.exe and it starts with an empty
square and adds the datapoints I extracted from the
Panoply output. The pbm graphics file format is
dead simple, and the graphics data (one hundred million
ASCII characters) is output with one printf("%s")
type statement :-) The format doesn't even need
<cr><lf> during the data phase, which I find both
amusing and practical. I bet Notepad would not
like that file :-) But GIMP opened that file just fine.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

John,

Asssuming DegToRad() just means multiply by pi / 180 ...

Well, you may use any calculation in there that you want, as long as it does the job. :-) But yes, thats what the/my DegToRad function does.

... then the above simplifies to tan(Latitude*pi*pi/720)\2.53627, and
of course pi*pi/720 can be given as a constant.

I didn't even think that far. As I said, I'm no math wizz. :-|

Regards,
Rudy Wieser



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

As I cannot get any formule to work I'm going to try this one last time.

Below are two formules for converting a lattitude on a Mercator-projection
map into a -1 ... +1 result that needs to be multiplied by half the maps-images height and subtracted from the equator (the map-images top-left
is 0,0).

I've split the calculations up into multiple parts, hoping that someone can tell me where one, or perhaps both, go awry.

-- Formule: ln( tan(latitude) + sec(latitude) )

Lat: 39
DegToRad(39) -> 0.680952
tan(0.680952) -> 0.810238
sec(0.680952) -> 1/cos(0.680952) -> 1.287045
ln(0.810238+1.287045) -> log(0.810238+1.287045)/log(10) -> 0.321657

0.321657 is *way* too high.


-- Formule: log( tan(PI/4.0 + rad/2.0) ) / (2.0 * PI)

Lat: 39
DegToRad(39) -> 0.680952
tan(PI/4+0.680952/2) -> 2.098991
log(2.098991) -> 0.741457
0.741457/(2*PI) -> 0.117959

0.117959 is *way* to low

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Mon, 1/19/2026 3:11 PM, R.Wieser wrote:

As I cannot get any formule to work I'm going to try this one last time.

Below are two formules for converting a lattitude on a Mercator-projection map into a -1 ... +1 result that needs to be multiplied by half the maps-images height and subtracted from the equator (the map-images top-left is 0,0).

I've split the calculations up into multiple parts, hoping that someone can tell me where one, or perhaps both, go awry.

-- Formule: ln( tan(latitude) + sec(latitude) )

Lat: 39
DegToRad(39) -> 0.680952
tan(0.680952) -> 0.810238
sec(0.680952) -> 1/cos(0.680952) -> 1.287045
ln(0.810238+1.287045) -> log(0.810238+1.287045)/log(10) -> 0.321657

ln(2.097283) = 0.740643 # Via the ln() button on my calculator
# Calc is a cheap Canon F502
# http://www.datamath.org/Related/Canon/Images/F-502.jpg

0.321657 is *way* too high.

https://luckytoilet.wordpress.com/2010/11/07/notes-on-mercators-projection/

x = lambda # longitude in radians ?
# Means our plot is not a unit square, as given

y = ln( sec(theta) + tan(theta) ) # I cannot copy the equation as it is mathml
# and will only confuse matters. 1/3rd down the page,

The plot origin must not be where we think it is. Notice how in a lot
of these mathematics discussions, nobody labels a damn thing. The
range on y is 0 to some positive number. X must be in the center of
the plot, so plus and minus lambdas move to either side for us.

-- Formule: log( tan(PI/4.0 + rad/2.0) ) / (2.0 * PI)

Lat: 39
DegToRad(39) -> 0.680952
tan(PI/4+0.680952/2) -> 2.098991
log(2.098991) -> 0.741457
0.741457/(2*PI) -> 0.117959

0.117959 is *way* to low

But it is 0.5 minus that number, so 0.382 .

double rad = lat * PI / 180.0;
double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

And again, we have to evaluate the range of the equation and see how
we can fit it to the plot and make sense of it. In a previous post,
I ran merc.exe and entered some numbers to generate a range. So we
can see which direction it is moving. The Y axis seems to be down
the page on this one. I put this text into a previous post and I removed
all the distracting latitude text when making this table.

Enter Latitude in degrees: -80 Y=0.887741
Enter Latitude in degrees: -50 Y=0.660855
Enter Latitude in degrees: -30 Y=0.587425
Enter Latitude in degrees: 0 Y=0.500000
Enter Latitude in degrees: 30 Y=0.412575 \___ 39 degrees is between these two
Enter Latitude in degrees: 50 Y=0.339145 /
Enter Latitude in degrees: 80 Y=0.112259

Paul

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

ln(2.097283) = 0.740643 # Via the ln() button on my calculator

And that 0.740643 points to somewhere between the northpole and canada on an ice plate. Where I'm quite sure Washington DC isn't located.

Which was why I started to doubt that "ln()" equals "log()". But if not,
what is it ?

The plot origin must not be where we think it is.

Well, thats easy to check : Just calculate the result for a Latitude of Zero degrees. It should point at the equator.

Notice how in a lot of these mathematics discussions, nobody labels a damn thing.

Just mathematics ? A couple of weeks ago I tried to find example code for OpenSLL. I could find some, but with zero indication which version of the
DLL it was for - and it matters a *lot*. It frustrates me to no end.

0.117959 is *way* to low

But it is 0.5 minus that number, so 0.382 .

In my previous message I mentioned that I multiply the result by half the height of the map, and subtract it from the equator (again, half the height
of the map). That is the same, right ?

Actually, it isn't. :-)

Now you have shown that the log() in the formule you presented is exactly
that (and not a elog() (natural log?) ) I had some solid ground from which I could look further.

The whole problem is that your formule multiplies by the full height of the map, and my "simplified" one multiplied by *half* the maps height (and than subtracts from the equator).

When I multiplied my result by two the result was the same as what came
outof your formule.

Thank you for that. :-)

mea culpa : after noticing that my implementation of the formule didn't work
I *should* have first tried to implement it as provided. :-|


Than only one thing remains : Any idea why the first formule doesn't give
the expected result ?<whistle>

Regards,
Rudy Wieser




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 21/01/2026 19:01, R.Wieser wrote:

Paul,

ln(2.097283) = 0.740643 # Via the ln() button on my calculator

And that 0.740643 points to somewhere between the northpole and canada on an ice plate. Where I'm quite sure Washington DC isn't located.

Which was why I started to doubt that "ln()" equals "log()". But if not, what is it ?

The plot origin must not be where we think it is.

Well, thats easy to check : Just calculate the result for a Latitude of Zero degrees. It should point at the equator.

Notice how in a lot of these mathematics discussions, nobody labels a damn >> thing.

Just mathematics ? A couple of weeks ago I tried to find example code for OpenSLL. I could find some, but with zero indication which version of the DLL it was for - and it matters a *lot*. It frustrates me to no end.

0.117959 is *way* to low

But it is 0.5 minus that number, so 0.382 .

In my previous message I mentioned that I multiply the result by half the height of the map, and subtract it from the equator (again, half the height of the map). That is the same, right ?

Actually, it isn't. :-)

Now you have shown that the log() in the formule you presented is exactly that (and not a elog() (natural log?) ) I had some solid ground from which I could look further.

The whole problem is that your formule multiplies by the full height of the map, and my "simplified" one multiplied by *half* the maps height (and than subtracts from the equator).

When I multiplied my result by two the result was the same as what came
outof your formule.

Thank you for that. :-)

mea culpa : after noticing that my implementation of the formule didn't work I *should* have first tried to implement it as provided. :-|

Than only one thing remains : Any idea why the first formule doesn't give
the expected result ?<whistle>

Regards,
Rudy Wieser

I would expect most people would think that log(A) means log to base 10
of A while ln(B) is natural log of B if they were just shown without any explanation.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

EllisMorgan,

I would expect most people would think that log(A) means log to base 10 of
A while ln(B) is natural log of B if they were just shown without any explanation.

As I mentioned, I googled for what "ln()" could mean. I got information
back that different professions use "log()" to mean whatever they want it to mean. :-(

I did however find how to use "log()" to emulate "ln()" (as I showed in my first message). Alas, the result was still not near the expected one.

If you can point out what mistake(s) I made with that (first) fomule or my conversion of it I would be much obliged.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Fri, 1/23/2026 1:56 PM, R.Wieser wrote:

EllisMorgan,

I would expect most people would think that log(A) means log to base 10 of >> A while ln(B) is natural log of B if they were just shown without any
explanation.

As I mentioned, I googled for what "ln()" could mean. I got information back that different professions use "log()" to mean whatever they want it to mean. :-(

I did however find how to use "log()" to emulate "ln()" (as I showed in my first message). Alas, the result was still not near the expected one.

If you can point out what mistake(s) I made with that (first) fomule or my conversion of it I would be much obliged.

Regards,
Rudy Wieser

If you take a math course, you're taught it is as Ellis explains.

That the notation ln() is a logarithm based on the constant e = 2.71828 .

And that log() is log base 10.

*******

And just scraping a calculator web page gives a definition
with a superscript power y and a subscript base b as
a way of declaring other bases for a logarithm. For example,
in computer design, you might want a log base 2, as the
computer is binary for some things it does. You could
change the subscript to "e" or even the PI symbol if you wanted.

y
x = b ; then y = log (x); where b is the base
b

We could write

ln(x) = log (x)
e

and I'm writing it this way so plain ASCII will do the job.

But when it comes to computers and math, some languages
allow entry of natural expressions, to at least make it
kinda look like math. Fortran and C butcher math,
and C++ is a little better.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

If you take a math course, you're taught it is as Ellis explains.

Good for Ellis I suppose. How does that help me, having googled and found that different professions use those different names as they bloody wel
please ?

Also, in my very first posy I included "where ln(...) is log(...) /
log(10)", indicating that I already had the idea that "ln()" *PROBABLY* was the natural logarithm, and how to get it using the standard base-10 log().

I ALREADY TRIED THAT, and still didn't get the expected result.

A few posts back I've provided the origional formule, the replacements I had to make ( "ln()" and "sec()" ) and gave several intermediate results.

*Please* put that formule into whatever you want to use and see where the intermediate results differ from mine - so I know were the problem is and
can try to fix it.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/19 20:11:34, R.Wieser wrote:

As I cannot get any formule to work I'm going to try this one last time.

[]
There are three stages to this - I would say best sorted individually
before trying to combine them. (Stages 2 and 3 are related and might
need reversing in order.)

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*, assuming that's
where the Greenwich meridian crosses the equator. This is the one that
might or might not be just a tangent function (for latitude; for
longitude, it's just scaling and offset, see below).

2. The _scaling_ required, depending on the size of the map image. Which
again will depend on the size of the image (and may be different for X
and Y).

3. The _offsetting_ required to account for the fact that the above
point is not at 0, 0 on the image (probably offset by half the size of
the map being used, in pixels, in each direction).

I think _most_ of those contributing to this discussion know that, but
have not been making it very clear which bits of their formula(e) do what.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

The fact that there is a highway to hell and only a stairway to heaven
says a lot about anticipated traffic numbers.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Fri, 1/23/2026 4:31 PM, R.Wieser wrote:

Paul,

If you take a math course, you're taught it is as Ellis explains.

Good for Ellis I suppose. How does that help me, having googled and found that different professions use those different names as they bloody wel please ?

Also, in my very first posy I included "where ln(...) is log(...) / log(10)", indicating that I already had the idea that "ln()" *PROBABLY* was the natural logarithm, and how to get it using the standard base-10 log().

I ALREADY TRIED THAT, and still didn't get the expected result.

A few posts back I've provided the origional formule, the replacements I had to make ( "ln()" and "sec()" ) and gave several intermediate results.

*Please* put that formule into whatever you want to use and see where the intermediate results differ from mine - so I know were the problem is and can try to fix it.

Regards,
Rudy Wieser

I wrote a program, worked an example and put a dot on a map
in a posted picture. That's enough.

Paul


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

John,

There are three stages to this

...

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*

Nope. There is no rule that that center must be taken as the origin. Take the formule Paul provided for instance. It returns a result in the range of
0 to 1 .

2. The _scaling_ required, depending on the size of the map image.
Which again will depend on the size of the image (and may be different
for X and Y).

Worse : Mercator maps go from +85 to -85 latitude. That must be part of the formule (I've found several maps where the south-pole is cut off, and a bit
of the north too. iow, useless without further information).

But again no. The result of the formule *is* the scaling (in your and my usage ranging from +1 to -1, in Pauls formule case, from 0 to +1). You just apply it on whatever size Mercator-style map you have handy.

I think _most_ of those contributing to this discussion know that,
but have not been making it very clear which bits of their formula(e)
do what.

I do not need to know what all the parts of a car do, as long as I can drive it. The same goes for these two formules. Latitude goes in, something I
can apply comes out.


Though the whole problem isn't that nobody understood what you said there,
but that nobody was willing to compare the (intermediate) results I posted with what they got themselves, allowing me to locate where I made my mistake(s?).

Not when I asked for it in my first post, and not when I rather explicitily asked for it a few days back. :-(

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

I wrote a program, worked an example and put a dot on a map
in a posted picture. That's enough.

I already knew that both of those formules where expected to work, so you wasted your time in proving that your CoPilot provided one does.

*What I was asking for* was a bit of help to why my implementation of first one, than both formules refused to return a usable result. I gave you *everything* to be able to do so.

You think that what you did was enough ? How ? You did not even *try* to answer my question. :-(

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/24 8:28:44, R.Wieser wrote:

John,

There are three stages to this

...

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*

Nope. There is no rule that that center must be taken as the origin. Take the formule Paul provided for instance. It returns a result in the range of 0 to 1 .

It makes it easier to understand what's going on if done in these three
stages. And assuming we're talking of the Web Mercator image as shown at https://upload.wikimedia.org/wikipedia/commons/e/ec/Web_maps_Mercator_projection_SW.jpg,
0 degrees latitude and longitude _is_ at its centre.

2. The _scaling_ required, depending on the size of the map image.
Which again will depend on the size of the image (and may be different
for X and Y).

Worse : Mercator maps go from +85 to -85 latitude. That must be part of the

(Or 85.051129.)

formule (I've found several maps where the south-pole is cut off, and a bit of the north too. iow, useless without further information).

No, just because the map is cut off at those latitudes, that figure does
NOT have to appear in the formula. The poles _have_ to be cut off,
otherwise the map would be infinitely tall, and very distorted at the poles.

But again no. The result of the formule *is* the scaling (in your and my usage ranging from +1 to -1, in Pauls formule case, from 0 to +1). You just apply it on whatever size Mercator-style map you have handy.

The above image, according to my browser, is 2068 by 2060 pixels.

I think _most_ of those contributing to this discussion know that,
but have not been making it very clear which bits of their formula(e)
do what.

I do not need to know what all the parts of a car do, as long as I can drive it. The same goes for these two formules. Latitude goes in, something I can apply comes out.

True, if that really is all you want. As a scientist/engineer/just
enquiring mind, I don't like to blindly use a formula without knowing
what it does - or perhaps _why_.

Yes, you can drive a car without knowing what each bit does. But knowing
at least some of them will improve your longevity (wear and tear on the mechanisms), fuel economy, performance ... as you drive.

Though the whole problem isn't that nobody understood what you said there, but that nobody was willing to compare the (intermediate) results I posted with what they got themselves, allowing me to locate where I made my mistake(s?).

That is indeed one of many problems.

It would be good to see where the following points come out on e. g. the
above image, using any formula (longitude given first):
0, 0
+/- 180, 85
+/-180, -85
and some known place, such as London or New York.

Not when I asked for it in my first post, and not when I rather explicitily asked for it a few days back. :-(

Regards,
Rudy Wieser

I guess if you just want a formula that works, and _aren't_ bothered
about the three steps - the mathematical conversion from angle to linear dimension, the scaling, and the offset - then we're very different
minds. Which is of course fine; if we were all the same, it'd be a
boring world.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

We no longer make things, but sell each other consultancy on how to run consulatancies better. (Michael Cross, Computing 1999-3-4 [p. 28].)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Sat, 1/24/2026 9:16 AM, J. P. Gilliver wrote:

On 2026/1/24 8:28:44, R.Wieser wrote:

John,

There are three stages to this

...

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*

Nope. There is no rule that that center must be taken as the origin. Take
the formule Paul provided for instance. It returns a result in the range of
0 to 1 .

It makes it easier to understand what's going on if done in these three stages. And assuming we're talking of the Web Mercator image as shown at https://upload.wikimedia.org/wikipedia/commons/e/ec/Web_maps_Mercator_projection_SW.jpg,
0 degrees latitude and longitude _is_ at its centre.

2. The _scaling_ required, depending on the size of the map image.
Which again will depend on the size of the image (and may be different
for X and Y).

Worse : Mercator maps go from +85 to -85 latitude. That must be part of the

(Or 85.051129.)

formule (I've found several maps where the south-pole is cut off, and a bit >> of the north too. iow, useless without further information).

No, just because the map is cut off at those latitudes, that figure does
NOT have to appear in the formula. The poles _have_ to be cut off,
otherwise the map would be infinitely tall, and very distorted at the poles.

But again no. The result of the formule *is* the scaling (in your and my >> usage ranging from +1 to -1, in Pauls formule case, from 0 to +1). You just
apply it on whatever size Mercator-style map you have handy.

The above image, according to my browser, is 2068 by 2060 pixels.

I think _most_ of those contributing to this discussion know that,
but have not been making it very clear which bits of their formula(e)
do what.

I do not need to know what all the parts of a car do, as long as I can drive
it. The same goes for these two formules. Latitude goes in, something I >> can apply comes out.

True, if that really is all you want. As a scientist/engineer/just
enquiring mind, I don't like to blindly use a formula without knowing
what it does - or perhaps _why_.

Yes, you can drive a car without knowing what each bit does. But knowing
at least some of them will improve your longevity (wear and tear on the mechanisms), fuel economy, performance ... as you drive.

Though the whole problem isn't that nobody understood what you said there, >> but that nobody was willing to compare the (intermediate) results I posted >> with what they got themselves, allowing me to locate where I made my
mistake(s?).

That is indeed one of many problems.

It would be good to see where the following points come out on e. g. the above image, using any formula (longitude given first):
0, 0
+/- 180, 85
+/-180, -85
and some known place, such as London or New York.

Not when I asked for it in my first post, and not when I rather explicitily >> asked for it a few days back. :-(

Regards,
Rudy Wieser

I guess if you just want a formula that works, and _aren't_ bothered
about the three steps - the mathematical conversion from angle to linear dimension, the scaling, and the offset - then we're very different
minds. Which is of course fine; if we were all the same, it'd be a
boring world.

As an engineer, I run a range of values through the equation, to get
a feel for both the rate-of-change of my (broken-or-working) function
as well as the absolute displacement. When we design logic blocks that
cannot be changed, in silicon, we waste a whole month on a test bench to
test all boundaries for mis-behavior. If trig functions were involved,
that just magnifies the amount of work, because then there are lots
of ways to break a thing.

The code I got, has a "clamp" function that sets any value outside 85.051129 back to exactly 85.051129 so that the function cannot produce any
infinities by accident.

#include <stdio.h>
#include <math.h>

/* gcc -lm -o merc.exe merc.c */

int main(void) {
double lat, lon;
const double PI = 3.14159265358979323846;

while (1) {
printf("\nEnter Latitude in degrees: ");
if (scanf("%lf", &lat) != 1) break;

printf("Enter Longitude in degrees: ");
if (scanf("%lf", &lon) != 1) break;

/* Clamp latitude to Mercator limits (approximately 85.05113 degrees) */
if (lat > 85.05113) lat = 85.05113;
if (lat < -85.05113) lat = -85.05113;

/* Convert longitude to X in [0,1] */
double x = (lon + 180.0) / 360.0;

/* Convert latitude to Y in [0,1] using Mercator projection */
/* the C log function is an ln() below, the C log10 function would be a log() */
double rad = lat * PI / 180.0;
double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

printf("Your screen data point is at X=%f Y=%f\n", x, y);
}

return 0;
}

My conclusion from examining the pattern, is

(0,0) is on the upper left of the unit square
and Y is going down the page. That makes -80 near the
bottom.

Enter Latitude in degrees: -80
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.887741

Enter Latitude in degrees: -50
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.660855

Enter Latitude in degrees: -30
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.587425

Enter Latitude in degrees: 0
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.500000 <=== (0,0) is at (0.5,0.5)

Enter Latitude in degrees: 30
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.412575

Enter Latitude in degrees: 50
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.339145

Enter Latitude in degrees: 80
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.112259

Paul

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

John,

It makes it easier to understand what's going on if done in these
three stages.

It is, and its why I tried to convert Pauls CoPilot formule into one which would returne a +1 ... -1 result (and made a mistake I only much later recognised).

And assuming we're talking of the Web Mercator image as shown at https://upload.wikimedia.org/wikipedia/commons/e/ec/Web_maps_Mercator_projection_SW.jpg,

I started with the image just above it (as mentioned in my initial post).

And thats another problem (which I ignored for the time being) : which of those two where either formule for ? Can you tell ? I definitily can't.

0 degrees latitude and longitude _is_ at its centre.

For /that/ image, yes.

I don't think you noticed, but it and the one above it have a border around the map-image itself, throwing the precision off a bit. And imagine a map with un-equally sized borders. And yes, I encountered those too. Then there are the maps I mentioned earlier, which could be in a Mercator projection,
but not in a +85 to -85 latitude range.

No, just because the map is cut off at those latitudes, that figure
does NOT have to appear in the formula. The poles _have_ to be
cut off, otherwise the map would be infinitely tall, and very distorted
at the poles.

You mis-understood : I've seen maps where the top of the image is at about
+75 latitude (just above Russia), and the bottom at about -60 latitude (just below south america). Meaning that *none* of the south-pole ice is visible
on the map, and the ice-plate at +45 longitude is pretty-much cut in half.

iow, the equator of such an image is /definitily not/ at half the height of the image.

I've also found a few maps in which 0 degrees longitude was *not* in the horizontal center of the image (its left started at about -170 degrees longitude, just between the russian peninsula and canada).

I do not need to know what all the parts of a car do, as long as I can
drive
it. The same goes for these two formules. Latitude goes in, something
I
can apply comes out.

True, if that really is all you want. As a scientist/engineer/just
enquiring mind, I don't like to blindly use a formula without knowing
what it does - or perhaps _why_.

Bothering about /how/ something works is only a good use of time and energy *after* you make sure /that/ it works.

It would be good to see where the following points come out on e. g. the above image, using any formula (longitude given first):
0, 0
+/- 180, 85
+/-180, -85
and some known place, such as London or New York.

Sigh. I already gave the latitude of Washington DC. Multiple times even.
In my initial post I already provided the result and mentioned that it
pointed somewhere into canada.

But it doesn't really matter which value is plugged into the formula (as
long as its a valid one ofcourse). The only thing that I needed was someone who would repeat the calculations I provided and compare the result with the one I also gave.

I can give you the results for +85 and -85 latitude - which will ofcourse mirror each other - but those values will be of zero use to anyone - other than to be able to tell me that those results are wrong. And thats
something I already know.

Do you still want them, now you know that they would be of no real use to
you ?

One thing bothers me though : why would I need to provide results for +180
and -180 longitudes too ? The longitude isn't any part of the formule.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Sat, 1/24/2026 3:42 AM, R.Wieser wrote:

Paul,

I wrote a program, worked an example and put a dot on a map
in a posted picture. That's enough.

I already knew that both of those formules where expected to work, so you wasted your time in proving that your CoPilot provided one does.

*What I was asking for* was a bit of help to why my implementation of first one, than both formules refused to return a usable result. I gave you *everything* to be able to do so.

You think that what you did was enough ? How ? You did not even *try* to answer my question. :-(

Regards,
Rudy Wieser

Show me current code.

Have the program print out something like this.

Enter Latitude in degrees: -80 Y=0.887741
Enter Latitude in degrees: -50 Y=0.660855
Enter Latitude in degrees: -30 Y=0.587425
Enter Latitude in degrees: 0 Y=0.500000
Enter Latitude in degrees: 30 Y=0.412575 \___ 39 degrees is between these two
Enter Latitude in degrees: 50 Y=0.339145 /
Enter Latitude in degrees: 80 Y=0.112259

You can see from the output, I'm covering most of a unit square
and my output graph origin must be in one of the
corners of the unit square.

We know the equation is not valid past 85 degrees
at either end, so that range of values will
tell us whether we are covering a unit square or not.

Most of the trouble with this stuff, seems to be
with origin-of-map and origin-of-unit-square.

If we enter (0,0) for lat-long we expect to be in the middle
of the unit square. You can see my Y above is 0.5 in that case.

You can check in Wikipedia for the icon next to the
lat-long for a city, and that icon (with a good browser)
will yield a pop-up map with enough detail you can
fit it to your map data.

Paul

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

Show me current code.

Explain to me how my code would help you any better than the worked-out formule with its input, partial and full results I already gave.

Besides, the language I'm using might not be the one you know/are
comfortable with, thereby adding yet another layer to the problem.

First rule of bug-hunting : remove everything that has got zero to do with
the problem.

Have the program print out something like this.

[snip list of values]

Alright, here it is :

lat: -80 Y= -1.059456
lat: -50 Y= -0.439171
lat: -30 Y= -0.238666
lat: 0 Y= 0.000000
lat: +30 Y= +0.238666
lat: +50 Y= +0.439171
lat: +80 Y= +1.059456

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/25 9:30:57, R.Wieser wrote:

Paul,

Show me current code.

Explain to me how my code would help you any better than the worked-out formule with its input, partial and full results I already gave.

Besides, the language I'm using might not be the one you know/are comfortable with, thereby adding yet another layer to the problem.

[]
English?
One of them is a formula; two or more, though pronounced form-you-lee,
are formulae - or formulas for those who object to classical plurals.

:-)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

There are a lot of things that children should be shielded from, but
"bad language" isn't one of them.

"Honey, we shouldn't say that when other people are around because some grownups get upset about it. No, I don't know why, they just do."
- "The Real Bev", in mozilla.general 2015-6-7
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/25 11:2:38, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Ah, UK/US difference again. In UK, the form formule is 1677-1829 (https://www.oed.com/search/dictionary/?scope=Entries&q=formule),
whereas the form formula is current (https://www.oed.com/dictionary/formula_n?tab=factsheet#3817037 - which
also shows that it exists in US English).

Formula comes from the Latin formula; formule comes from the French
formule, which comes from the Latin formula.

Isn't language fun!
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

Imagine a world with no hypothetical situations...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

John,

Ah, UK/US difference again. In UK, the form formule is 1677-1829 (https://www.oed.com/search/dictionary/?scope=Entries&q=formule),
whereas the form formula is current

merriam-webster doesn't make any such distinction. Who am I going to believe
?

formule comes from the French formule,

Yes, thats what the link I posted says. And for funzels it mentions your singular "formula" as being the plural of of "formule".

Isn't language fun!

Almost as funny as math. :-(

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 25/01/2026 10:02 pm, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Dictionarys .... What would THEY know??
--
Daniel70
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 26/01/2026 2:01 am, R.Wieser wrote:

John,

Ah, UK/US difference again. In UK, the form formule is 1677-1829
(https://www.oed.com/search/dictionary/?scope=Entries&q=formule),
whereas the form formula is current

merriam-webster doesn't make any such distinction. Who am I going to believe ?

merriam-webster is Yank, isn't it??

Nuff said.

formule comes from the French formule,

Yes, thats what the link I posted says. And for funzels it mentions your singular "formula" as being the plural of of "formule".

Isn't language fun!

Almost as funny as math. :-(

Regards,
Rudy Wieser

--
Daniel70
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/26 11:13:59, Daniel70 wrote:

On 26/01/2026 2:01 am, R.Wieser wrote:

John,

Ah, UK/US difference again. In UK, the form formule is 1677-1829
(https://www.oed.com/search/dictionary/?scope=Entries&q=formule),
whereas the form formula is current

merriam-webster doesn't make any such distinction. Who am I going to believe >> ?

merriam-webster is Yank, isn't it??

Yes.

Nuff said.

Well, despite what many people think (and what many people _wish_!), the majority of dictionaries do _not_ record how language _should_ be used,
but how it _is_. As such, M-W is probably reflecting US usage; the OED
probably primarily reflects UK usage, though usually tries to record US
usage too, but would appear to be somewhat behind on this entry (or, I
haven't got beyond the paywall aspects to delve further).

(There _are_ "prescriptive" dictionaries, mainly for people learning the language as a foreigner, who have need of such.)

formule comes from the French formule,

Yes, thats what the link I posted says. And for funzels it mentions your >> singular "formula" as being the plural of of "formule".

Yes, I noticed that. I've never come across that as a plural (it's very
odd: would only make sense etymologically if the singular was formulum,
which is isn't; that isn't to say that it isn't used though!)

Isn't language fun!

Almost as funny as math. :-(

Well, I enjoy it. (Can't really help it in my family - both parents were language teachers and brother works for the dictionary.) And I do enjoy
_some_ maths (UK spelling!) too.

Regards,
Rudy Wieser

Regards, John
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

G B Shaw said: "Few people think more than two or three times a year; I
have made an international reputation for myself by thinking once or
twice a week." (quoted by "Dont Bother" [sic], 2015-8-24.)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/26 11:11:11, Daniel70 wrote:

On 25/01/2026 10:02 pm, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Dictionarys .... What would THEY know??

More than you could possibly imagine [(C) Marvin]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

We'd agreed to overlook each others' families and everything, and
get married" (The Trouble with Harry)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 26/01/2026 11:44 pm, J. P. Gilliver wrote:

On 2026/1/26 11:11:11, Daniel70 wrote:

On 25/01/2026 10:02 pm, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Dictionarys .... What would THEY know??

More than you could possibly imagine [(C) Marvin]

Hmm!! "Marvin" .... is that Marvin as in THHGTTG??
--
Daniel70
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 26/01/2026 11:43 pm, J. P. Gilliver wrote:

On 2026/1/26 11:13:59, Daniel70 wrote:

On 26/01/2026 2:01 am, R.Wieser wrote:

<Snip>

Isn't language fun!

Almost as funny as math. :-(

Well, I enjoy it. (Can't really help it in my family - both parents were language teachers and brother works for the dictionary.) And I do enjoy _some_ maths (UK spelling!) too.

As much as it grates on me, I can, sort of, accept the Yank 'Math' ... I
mean the full word IS 'MathematicS' and, if you were going to truncate
it by dropping the tail-end, then ALSO dropping the 's' makes sense
..... but it sounds so awkward!!
--
Daniel70
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2026/1/27 9:19:47, Daniel70 wrote:

On 26/01/2026 11:44 pm, J. P. Gilliver wrote:

On 2026/1/26 11:11:11, Daniel70 wrote:

On 25/01/2026 10:02 pm, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Dictionarys .... What would THEY know??

More than you could possibly imagine [(C) Marvin]

Hmm!! "Marvin" .... is that Marvin as in THHGTTG??

It would indeed; the true inheritor of Eeyore (or, Eeyore was the
ur-Marvin).

Yes, at some point in THHGTTG some vapid character (probably Zaphod)
said "Hey, d'you know what?", or something similar, and Marvin, in his
default doleful voice, replied "More than you can possibly imagine".
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

Intelligence isn't complete without the full picture and the full
picture is all about doubt. Otherwise, you go the way of George Bush.
- baroness Eliza Manningham-Buller (former head of MI5),
Radio Times 3-9 September 2011.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Tue, 27 Jan 2026 19:59:05 +1100, Daniel70
<daniel47@nomail.afraid.org> wrote:

As much as it grates on me, I can, sort of, accept the Yank 'Math' ... I >mean the full word IS 'MathematicS' and, if you were going to truncate
it by dropping the tail-end, then ALSO dropping the 's' makes sense
..... but it sounds so awkward!!

You want awkward? Try telling everyone "I won a maths debate! I won a
maths debate!" See if they look at you funny.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 28/01/2026 9:01 am, Char Jackson wrote:

On Tue, 27 Jan 2026 19:59:05 +1100, Daniel70
<daniel47@nomail.afraid.org> wrote:

As much as it grates on me, I can, sort of, accept the Yank 'Math' ... I
mean the full word IS 'MathematicS' and, if you were going to truncate
it by dropping the tail-end, then ALSO dropping the 's' makes sense
..... but it sounds so awkward!!

You want awkward? Try telling everyone "I won a maths debate! I won a
maths debate!" See if they look at you funny.

Easily done!! Much more easily done than debating the Mass of things
.... you know like having a Mass Debate!! ;-P
--
Daniel70
--- Synchronet 3.21b-Linux NewsLink 1.2