Igor doesn't make this (extremely simple) wave correctly

In the table menu, select digits and set it to a larger value.  The default is to show 6 places and that is why you are getting scientific notation.

Andy

Andy, I don't think you understand. Look at the actual value getting stored in the field. It's never what I want, and this has nothing to do with scientific notation.

Even when I edit the table directly to put in the value I want, it's always off. Regardless of how many digits I display.

It is not about the table.

Each wave has a type of data it can hold. By default Make uses 32bit floating point, which is not able to hold the value you entered.

If you use a double precision wave with 64bit floating point it can hold that value. I've created that with the /D flag. The /D flag of print tells it to print more digits.

https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf is a good read on the properties of floating point computations in computers but is a bit theoretical.

Thanks, I knew it wasn't about the table since print(test[0]) returned the faulty value.

It seems like this is a massive shortcoming of Igor. With such a full feature set otherwise, you'd think it'd be either a little more context-aware in how it makes waves, or just realize that it's 2020 and I have a ton of RAM and a blazing fast processor that doesn't care about the difference between 32- and 64- bit numbers. Anyway, thanks for the suggestion. Make/d works for my purposes.

One issue with changing how it currently works is backward compatibility. You can old code to work the same way as it used to work.

I would actually favour that make would require you to use one of the type flags, so you can never use the wrong one. This should be the default for programmatic use. Not sure if that is really nice to use when used interactively from the command line.

I'm still using float for a lot of computation as even nowadays a factor of two in speed is relevant. And I do a have a mildly beefy machine.

The OP stated: "It seems like this is a massive shortcoming of Igor. "

I could almost agree with that statement but please consider this:  you are executing

The syntax tells Igor to make Single Precision wave containing one point.  OK, Igor appears to comply.  Next, your syntax tells Igor to set that one point to a value that can't be expressed in your specified numeric type (Single Precision).  This is no different than executing the command:

OK, we can stop here and consider our options:

1.  Stop and issue an alert with dire warning and do not execute the command at all.

2.  Do the best you can with the given intput.

3.  Decide that you really wanted to create a DP wave or possibly meant to use Make/L.

Igor has been using (2) for the last 30 years or so.  It might be nice if at some point down the road someone will develop a good AI that could determine exactly what the user needs.  I am not holding by breath.  In the meantime I think that current behavior is not a "massive shortcoming" but the most reasonable choice under the circumstances.